IT Knowledge Base in your company
At a certain stage in the development of your IT structure, the question may arise about organizing the Knowledge Base (hereinafter KB) for both IT employees and business users. The implementation of this venture can have both a positive effect and can cause a serious headache for all project participants: from the business that finances it, and from the project manager coordinating the implementation. In this article I will try to reveal a few points that we encountered, as well as give some 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 at the same time.
KB for IT and business.
If you have decided 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 get the proper guarantee and in the future will help to avoid unpleasant incidents associated with a misunderstanding of the goals or, at a lower level, dissatisfaction with the quality of the submitted articles.
• Try to be responsive to the elements of the interface and the choice of environment for development . Search tools are important. If this element will not work well, then there will be little sense in such a base: a base so that you can find something in it! Do not underestimate this point. When your organization has thousands and thousands of articles, the problem will be felt more and more;
•Use clear categorization . Those categories that will be understandable to the IT worker can say absolutely nothing to the business user. Try to combine categories that reflect the names of business processes and subcategories that we understand;
• System selection . The item is no less important, since it will be more convenient for the user to work with KB from the environment in which he will have questions. Perhaps a good solution would be a system for maintaining user requests. Think of a combination of Incident and Knowledge Management;
• Do not rush to open the database for users. Even the best and most interesting solution can push users away from itself for a long time if it consists of 10 articles. Get ready in advance. To get started, write articles on those issues that you think are most relevant;
• Distinguish IT KB from KB for users . And not in order to hide from them what they should not see. User articles should be given more attention. This style of presentation, and the rejection of the use of IT slang and abbreviations. Make sure that everything that you publish can be technically used by the user;
• Use a system to monitor and moderate articles before publication. One head it's good, but two better. This will eliminate incompetent knowledge and annoying blots;
• Applications for articles. Realize the ability to add applications for articles of specific content. Users better know what they need and what not;
• Write documentation on how to use the tool and try to provide intensive support at first.
Practice shows that users generally have a positive attitude towards the idea of creating an IT knowledge base, however, it is not worth making a replacement for technical support from it, at least at first you should not even think about it. Present the tool as an additional channel for solving problems and advertise it. For example, having solved the problem verbally or on paper, it makes sense to document it in KB and send the link to the user.
KB for IT.
Using KB inside an IT structure can be useful in many cases.
• Training new employees;
• Transfer of relevant knowledge to those who are not deep specialists in the field;
• Exchange of knowledge with related departments of IT.
At this stage, you may have a completely different kind of problems than those that are potentially possible for the business.
• “ Why do I need KB since I already know everything and will easily explain to the user". This is a very common question that came to us from users and authors of KB. Writing articles takes time that the employee wants to spend for something else, no less useful in his opinion. It is possible to oblige a person to do something, but it is unlikely that this will have 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, first of all, saves time: communicating with users and with not so competent colleagues. For example, having five minutes now, and spending them on writing an article, we will save it when there are no these five minutes to explain the problem / functionality;
• Failed technical implementation. An important point that can easily ruin an idea. Try to make the tool 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 monitor not only how many articles are written and who does it personally, but also check their relevance. Add the functionality of view counters and feedbacks. Allow the user to post comments on articles. Create some reports. Try to monitor for duplicates. The likelihood of their occurrence with the growth of the base will also increase.
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 flaws and annoying 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 greater than I indicated in the article, but those described are the most important.
I am ready to listen to your comments and I will be glad if I share my experience.
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 at the same time.
KB for IT and business.
If you have decided 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 get the proper guarantee and in the future will help to avoid unpleasant incidents associated with a misunderstanding of the goals or, at a lower level, dissatisfaction with the quality of the submitted articles.
• Try to be responsive to the elements of the interface and the choice of environment for development . Search tools are important. If this element will not work well, then there will be little sense in such a base: a base so that you can find something in it! Do not underestimate this point. When your organization has thousands and thousands of articles, the problem will be felt more and more;
•Use clear categorization . Those categories that will be understandable to the IT worker can say absolutely nothing to the business user. Try to combine categories that reflect the names of business processes and subcategories that we understand;
• System selection . The item is no less important, since it will be more convenient for the user to work with KB from the environment in which he will have questions. Perhaps a good solution would be a system for maintaining user requests. Think of a combination of Incident and Knowledge Management;
• Do not rush to open the database for users. Even the best and most interesting solution can push users away from itself for a long time if it consists of 10 articles. Get ready in advance. To get started, write articles on those issues that you think are most relevant;
• Distinguish IT KB from KB for users . And not in order to hide from them what they should not see. User articles should be given more attention. This style of presentation, and the rejection of the use of IT slang and abbreviations. Make sure that everything that you publish can be technically used by the user;
• Use a system to monitor and moderate articles before publication. One head it's good, but two better. This will eliminate incompetent knowledge and annoying blots;
• Applications for articles. Realize the ability to add applications for articles of specific content. Users better know what they need and what not;
• Write documentation on how to use the tool and try to provide intensive support at first.
Practice shows that users generally have a positive attitude towards the idea of creating an IT knowledge base, however, it is not worth making a replacement for technical support from it, at least at first you should not even think about it. Present the tool as an additional channel for solving problems and advertise it. For example, having solved the problem verbally or on paper, it makes sense to document it in KB and send the link to the user.
KB for IT.
Using KB inside an IT structure can be useful in many cases.
• Training new employees;
• Transfer of relevant knowledge to those who are not deep specialists in the field;
• Exchange of knowledge with related departments of IT.
At this stage, you may have a completely different kind of problems than those that are potentially possible for the business.
• “ Why do I need KB since I already know everything and will easily explain to the user". This is a very common question that came to us from users and authors of KB. Writing articles takes time that the employee wants to spend for something else, no less useful in his opinion. It is possible to oblige a person to do something, but it is unlikely that this will have 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, first of all, saves time: communicating with users and with not so competent colleagues. For example, having five minutes now, and spending them on writing an article, we will save it when there are no these five minutes to explain the problem / functionality;
• Failed technical implementation. An important point that can easily ruin an idea. Try to make the tool 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 monitor not only how many articles are written and who does it personally, but also check their relevance. Add the functionality of view counters and feedbacks. Allow the user to post comments on articles. Create some reports. Try to monitor for duplicates. The likelihood of their occurrence with the growth of the base will also increase.
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 flaws and annoying 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 greater than I indicated in the article, but those described are the most important.
I am ready to listen to your comments and I will be glad if I share my experience.