
Knowledge bases are a popular tool that companies use to solve various tasks, such as reducing the burden on support services. The idea sounds beautiful: why constantly answer the same questions when you can simply describe these solutions and refer to them. However, in practice, everything is not so simple, and everyone is faced with situations where the knowledge base hangs dead weight and does not bring any benefit to anyone.
We are talking today about how to avoid this with Dmitry Plotnikov, consultant for SharePoint and Office 365, Microsoft MVP, who created knowledge bases for many large companies.
')
What kind of knowledge bases are there?
In general, in different cases the concept of “knowledge base” may differ, but there are not so many options for the technical implementation of such a database: from a simple document to more complex hierarchical structures. They can be fully automated, supported by the community or specific employees of the company. But the essence is the same: information is stored there, which needs access to solve certain tasks.
What do you need to think about before starting work on creating such a base?
In developing a knowledge base, it is necessary first of all to decide what information will be in the database (about products, services, etc.), who will use it (employees or, conversely, customers and users), whether it will be transmitted and, if so, then how.
It is important to understand: it is not enough just to create a knowledge base and start entering information into it. In recent years, in different areas there has been a real oversupply of information, the same problem exists in business. If a company is big enough or its products are popular, then in a short time the knowledge base will grow significantly, many articles will appear in it, and it will be very difficult to navigate in all this diversity. Therefore, at the design stage of the knowledge base, you need to think about how content search and classification will be implemented in it.
What mistakes often make when creating such products?
Very often, when creating a knowledge base, its possible size is not taken into account, as a result, many problems arise. In a huge database it is very difficult to find something, and if the developer did not take care of the search engine in advance, this tool simply becomes useless.
Whether to create a tool independently or on the basis of existing ones? This is a difficult question, definitely difficult to answer here. Many of these solutions do not imply any serious customization - the same Confluence can only be taken and started to use, in fact, as it is. In practice, such bases very quickly become useless, since all the problems associated with this are greatly expanded and manifest themselves.
The other extreme is the creation of your own systems from scratch or on the basis of technologies that are not very suitable for the knowledge base. In the course of one of the projects in which I participated, we took SharePoint as the basis, and already on top of the wiki engine built in there, they “twisted” the recognition and search systems. Initially, SharePoint was not particularly designed to create knowledge bases, but the corporate infrastructure of customers was strongly tied to this technology. As a result, the decision turned out really difficult, albeit effective.
Unfortunately, in my practice, there were almost no cases where a balance could be achieved: knowledge bases are always either too simple and soon become useless, or they become very complex - and, although they are useful, it is not easy to create and maintain them.
And how to minimize possible problems?
Perhaps the main thesis: the knowledge base is a product that real people should support. Hoping that we can create a base that will then live on its own is the wrong approach.
For example, the MSDN resource from Microsoft is, in fact, a powerful knowledge base containing technical documentation. Her main problem: because of the huge volumes of stored content, it is almost impossible to find something specific there. This fact was one of the advantages of the Stack Overflow resource: at one time there were very common threads in which people shared links to specific articles with MSDN, - in fact, this was the only way to find what was needed there.
Microsoft had other attempts to create a knowledge base. Another project was named the TechNet Wiki, and its idea was to bring the user community to the database. It was assumed that people themselves would write articles, place tags in them, and so on. This approach proved to be much more efficient than the fully automated MSDN database.
Can you talk about some interesting project to create a knowledge base in which you managed to participate?
In one of our projects we developed a knowledge base for a large customer who needed to optimize the work of the support service. Wiki engine of the base itself was integrated with the corporate PBX. In order to speed up customer service, this system implemented a combination of speech recognition and information search in the database using keywords. If during the conversation the operator and the user pronounced certain "keywords", the base should automatically produce relevant articles.
It sounds serious, but in modern knowledge bases, more advanced approaches are also used - for example, Ontology Search, which allows you to create entire hierarchies of nested, dependent on each other tags and appropriately get more accurate results when searching through articles.
In conclusion, can you formulate three main tips for developing high-quality knowledge bases?
Yes, of course, here are my tips:
- Someone must answer for the knowledge base, otherwise it will die quickly.
- For small projects, you can get by box solutions, but you need to understand that this will not work on large volumes.
- The most important thing in the knowledge base is the ability to search. At the very beginning, it may not be necessary, but over time, the performance of the system will be determined precisely by the quality of the search.
Useful habrastaty on topic: