While everybody wants to use knowledge databases, nobody wants to populate them and the majority of people do not share their knowledge in a formal environment. To chat or email is much easier than to create an article or correct an existing one in a corporate knowledge base or wiki. The challenge, then, is how to motivate people to share knowledge – especially if those same people are competing with each other in, for example, sales departments. How can we solve this problem? Maybe can we develop a motivation program? A special bonus for each wiki article that is created? Or can we automate the process somehow?
The diagram above shows the process of knowledge management. It starts from identifying a knowledge item, before fixing and formalizing it in a standard view. Next, we decide which place is the best to store that knowledge to ensure all engaged people can see it. This, however, prompts another problem in knowledge management: how to notify business users properly and how to say things like “Pay attention to this document, it’s very important!” or “This document is also important, but nothing special”.
Using knowledge is the next step in the process. All engaged people should have an opportunity to provide feedback. Was the item useful for them? Do they have a suggestion to improve it? Last but not least is the process of actualizing knowledge. Everybody, and especially new business users who have just started working in the area, should be able to trust the knowledge and use it in their work. If they cannot, then the item should be reviewed or put into the archive.
In the industrial field, for example, many different documents are linked to one piece of equipment. These can include tender documentation, purchase orders, operation manuals and repair documentation. But what happens when something goes wrong during operations? More often than not, you open a document and see a phrase like “If your equipment doesn’t work, please call the manufacturer”. There are many reasons why things go wrong. To find the exact reason you’ll probably have to wait until someone visits your premises and solves the problem. While they will explain to your engineers what happened, over time your engineers can either forget the solution or simply leave your company, leaving new engineers or engineers from another office unaware of how to solve the problem. And so, the story repeats.
So how can you move that hidden knowledge into a standard solution that everybody can access? Let’s suppose that an engineer from one shift didn’t notify his colleague from another shift about a problem with launching a new gas turbine. The second engineer read all the relevant manuals and tried to follow them, but was unable to solve the problem on his own. Eventually, he emailed his colleague to ask how he had solved the problem. His colleague replied and from there everything worked fine. But what are the chances of the problem appearing again tomorrow? And will anybody know what to do? That’s why we need to fix, classify and publish this knowledge.
The diagram above shows the seven questions that need to be answered to use hidden knowledge. We should know where to find the information sources, understand the information we gather, and know how to structure and store it. Finally, we need to know how to share and actualize knowledge, and how we can find it in future.