Wednesday, 16 November 2016

How to choose KM technology

I have had a few conversations recently which make me worry about the way people choose KM technology. 

One was with an organisation who decided to get rid of all the old in-house technology which supported their Communities of practice, and replace it with Yammer.  Then there were three separate conversations with different clients who recognised the need for KM technology, did a Google search, and picked three or four vendors to provide demonstrations.

"What is the problem?", you might well ask.

The problem is that in every case the vendor, or the technology, was chosen without a proper use case or set of requirements, and all three companies face the possibility, or even the probability, of ending up with technology which won't do the job. 

Take the first company. The community software was built in-house, and it had a really nice set of community-management features. It was linked to the company expertise directory, it allowed people to join and leave the community at will, it allowed conversation threads to be opened and closed, and tagged to various knowledge topics, and it prompted a search of existing discussions before asking a new question. Over the years the exchange of knowledge using this software had saved the company hundreds of millions.

So why were they changing to Yammer - a software with far less functionality? Because "the IT policy is not to maintain software in-house".  Yammer would be maintained by Microsoft, and this was all part of the IT policy of getting rid of in-house software. But the result was replacing professional community software which was tailored to the way people worked, with software which, frankly, wasn't. However the IT people making the decision did not understand the functionality required.

If you want an analogy, I would be going  saying to a Farmer "We are going to get rid of your tractor, so you don't have to maintain it yourself. in the future you can use Uber. Just call for a vehicle when you need it, and all the maintenance will be taken care of for your". Unless you realise that a Uber taxi doesn't do the work of a John Deere tractor, you might think this was a wise decision. Similarly Yammer doesn't do the same job that was done by the  industrial community workshore it will replace.

Take the other three companies. They wanted Knowledge Management software, so they went looking for it, with the help of Google. However unless you define the functionality carefully, this approach falls into the sweetshop trap. All of the software sounds great, all of the vendors tell you it fits all your needs, and the risk is you choose based on superficiality, rather than core functionality.

An the truth is, that different KM software does different tasks in different contexts. 

  • There is content management software
  • There is search software
  • There is software for building article databases for contact centres
  • There is software for community discussion
  • There is software for social microblogging
  • There is wiki software, for co-creation of content
You can find examples of software that is great at each of these tasks, but few that can do more than one or two, and none of them can do tasks they were not designed for. 

However one of the companies was looking a contact centre software as a community of practice tool, and another was looking at content management software to support a contact centre.

Choosing the right technology is important. Technology is one of the four pillars of knowledge management, and the success of your KM program can hang on a good technology choice. 

Here is how to choose your KM software.

Firstly define your use cases. 

There is more than one use case in knowledge management, and you will require more than one KM software to satisfy those use cases. The main cases are;
  • Management and curation of content
  • Version control and document management
  • Co-creation of documents (eg wikis)
  • Building a community of practice through discussion and Q$A
  • Finding documented knowledge
  • Finding undocumented knowledge
  • Publishing ideas for comment
  • Management of lessons
Decide your cases, and define the functionality that will satisfy these cases.

Select vendors that offer solutions to these cases, and test the vendor offerings against your functionality reaquirements.

Be aware that you probably need solutions from more than one vendor, no matter what they promise you to the contrary.

Here is how Schlumberger did it

Schlumberger, one of the worlds leading KM companies, approached Technology selection in this way.

Firstly, they defined exactly what the business needed from their Knowledge Management technology. In KM terms, they divided these needs into 4 groups;

  • Connecting people to solutions 
  • Connecting people to information 
  • Connecting people to communities of practice 
  • Connecting people to people 

Secondly, they bought technology which does each required job, and only that job, and does it well. If no technology was available that did the job well enough, they built it in-house. 

Thirdly, they stuck with that technology over time, provided it still did the job well. People were familiar with it, so they stuck with it.

 Finally (and this seems so rare nowadays, that I want to emphasise it), if they bought new technology which had optional functionality that duplicated an existing tool, they disabled that functionality. As an example, they brought in SharePoint as an ECM tool, and SharePoint comes with the "MySite" functionality, which can be used to build a people-finder system. Schlumberger had a people-finder system already, and to introduce a second one would be crazy (if you have two systems, how do you know which one to look in?). So they disabled MySite.

If you need to plough a field, then buy a tractor. If you need  a short term car ride in an unfamiliar city, then use Uber.  Define your needs, then look for solutions.

No comments:

Blog Archive