At a certain stage of development of your IT structure, there may be a question about the organization of the Knowledge Base (hereinafter KB) for both IT employees and business users. The implementation of this undertaking can have both a positive effect and can cause a serious headache for all participants in the project: from the business that finances it, and from the project manager who coordinates the implementation. In this post I will try to reveal a few points that we faced, as well as give a few recommendations.
The process of creating a knowledge base can be considered from the point of view of fundamentally different structures in the organization: for IT users, for business, both of them simultaneously.
KB for IT and business.')
If you decide that KB is relevant for the entire organization, then it is worth securing moral and financial support from business representatives and technical directors. This will help your project to receive a proper guarantee and in the future will allow you to avoid unpleasant incidents related to a misunderstanding of goals or, at a lower level, dissatisfaction with the quality of the articles submitted.
•
Try to responsibly approach the elements of the interface and the choice of environment for development . Search tool is important. If this element does not work well, there will be little point in such a database: a base so that you can find something in it! Do not underestimate this item. When there are thousands and thousands of articles in your organization, the problem will be felt more and more;
•
Use clear categorization . Those categories that will be understood by IT staff, can absolutely say nothing to the business user. Try to combine categories reflecting the names of business processes and subcategories that are understandable to us;
•
System selection . The point is no less important, since it will be more convenient for the user to work with KBs from the environment in which they will have questions. Perhaps the best solution would be the system of maintaining user requests. Think about the means of combining Incident and Knowledge Management;
•
Do not rush to open the database for users . Even the best and most interesting solution can permanently alienate users from themselves, if it consists of 10 articles. Prepare in advance. To get started, write articles on those issues that you consider the most relevant;
•
Delimit IT KB from KB for users . And not to hide from them what they should not see. User articles should pay more attention. This is the style of presentation, and the rejection of the use of IT slang and abbreviations. Make sure that everything that you post can be technically used by the user;
•
Use a system of control and moderation of articles before publication. One head it's good, but two better. It will relieve from incompetent knowledge and annoying blots;
•
Claims for articles . Implement the ability to add entries for articles of specific content. It’s better for users to know what they need and what they don’t;
•
Write documentation on how to use the remedy and try to provide intensive support at first.
Practice shows that users in general have a positive attitude to the idea of ​​creating an IT knowledge base, however, you should not make a replacement for technical support out of it, at least at first, you should not even think about it. Present a tool as an additional channel for solving problems and advertise it. For example, having solved a problem orally or on paper, it makes sense to document it in KB and send a link to the user.
KB for IT.Using KB inside an IT structure can be useful in many cases.
• Training new employees;
• Transfer of current knowledge to those who are not a deep specialist in the field;
• Sharing knowledge with related IT departments.
At this stage, you may have a completely different kind of problem than the one that is potentially possible for a business.
• “
Why do I need KB once and I already know everything and will easily explain it to the user .” This is a very common question that came to us from KB users and authors. Writing articles takes time that the employee wants to spend on something else that is equally useful in his opinion. It is possible to oblige a person to do anything, but it is unlikely that there will be a good effect in the form of quality articles. Try to convey to people not so much that the tool will help someone, but that it will be useful to him personally, and this is, above all, saving time: to communicate with users and with not so competent colleagues. For example, having five minutes now, and having spent them writing an article, we will save it when there are no five minutes to clarify the problem / functionality;
•
Failed technical implementation . An important point that can easily ruin the idea. Try to make the facility convenient. If a text editor is built in there, get it to work flawlessly. If writing articles is inconvenient, they will not write;
•
Monitoring . Try to follow not only how many articles are written and who personally does it, but also check their relevance. Add view view and feedback functionality. Allow the user to leave comments on the articles. Create multiple reports. Try to monitor the appearance of duplicates. The probability of their occurrence with the growth of the base will also grow.
In general, everything related to KB should not be implemented hastily. You can spend a lot of time and money on technical implementation and not achieve the effect due to minor bugs and sufficient bugs. And the purpose of such systems is to reduce the number of contacts with supporting structures. Of course, the number of pitfalls is significantly more than I indicated in the article, but the described ones are the most important.
I am ready to listen to your comments and I will be glad if you share your experience.