KM Connect vs KM Collect

One of the things that I have learned is important in KM is awareness of the Connect – Collect spectrum; not just technically but the cultural implications too.

Any thoughts or feedback on this most welcome.

In simple terms there are two ways of getting knowledge from one person’s head to another’s. They can either communicate it directly eg face to face or perhaps via online discussion – or, secondly, write it down so that others can find / access it and read it later on. The former is KM Connect and the latter KM Collect.

KM Connect is very effective but not very efficient or scalable, not least in large organisations – imagine if the only way to communicate knowledge in an organisation was this way. It works extremely well when it takes place, but you wouldn’t want this to be the only approach to sharing knowledge to one / many people(s).

KM Collect is more involved as it depends on people writing knowledge down (in a form that is designed to be easy to access and understand by readers, which people often forget), and then make it searchable and accessible. It works across large organisations including different timezones, but it is less effective than KM Connect.

So which do we need? The answer is both.

It seems to me that KM has at times favoured one over the other (eg North American organisations held the view some years ago that KM Connect was all you needed – but later they moved from that to more of a balance).

Hence, any KM Plan for an organisation as a whole, or sub—parts of it, need to make sure they cater for both ends of the Connect – Collect spectrum

What I found working for different types of culture was that some had a natural bias to one end of the spectrum, while others preferred the opposite. For example, aid workers and teachers had more of a natural preference to KM Connect and, on the whole, found approaches to documented processes and their maintenance harder to do (I remember being told, “we are people people and like to talk to each other, all that fiddly stuff around processes and procedures isn’t really what motivates us even if we understand why it’s necessary.”). Engineers in contrast find it easier to do KM Collect while Communities are less natural to them (“you mean we actually have to talk to each other?!” was one memorable comment made to me).

The point is whichever the natural bias is, the organisation needs to move towards the middle of the spectrum and achieve a balance of both KM Connect and Collect to achieve the full KM system that delivers the benefits (eg good corporate memory, risk mitigation, enhanced innovation etc etc).

Once this balance is recognised, then it’s a case of diagnosing where the gaps are and ensuring that both ends of the spectrum are supported and maintained for all key knowledge areas of the organisation. If all areas use the same frameworks to diagnose the gaps and how to solve them then they can share hints and tips for what works and what doesn't across the organisation - this is the value from a common set of KM frameworks owned and maintained by assigned KM Managers.