Knowledge Management Best Practices within Service Management

Editor's Notes

• #5: There are two categories of incidents that occur in support environments. The first are those that occur once or periodically, which we will call “infrequent”. The second are those that we call “repeatable” or “frequent”. In most support environments there is a general rule of thumb that 80% of all incidents are generated by 20% of all problems. It is these 80% where knowledge management can have a big impact.When a new change is implemented into the environment, such as a product release, we can predict that the support center will see an increase in incidents for a period of time. This is generally 30 to 60 days. The Support Demand Curve has two axis: demand – the number of incidents received in a given period of time, and time. When the support center receives a repeatable incident for the first time, we start the curve. We then begin to see this incident more frequently for a number of days and then the frequency or demand will begin to reduce. Ultimately if the problem is not removed from the environment, we will continue to see it reported to the support center but on a less frequent period of time. If we map the demand for support for this problem over time we end up with a curve that looks like the bell curve.
• #6: Let’s look at the impact knowledge management has as incidents are reported to the support center. The When the first incident is reported it is an unknown problem. The analyst must do work to solve the problem. They are then expected to capture the knowledge and report it to the Knowledge Engineering team. The new knowledge is submitted to the knowledge engineering queue. The Knowledge Engineers have the responsibility to validate and verify that the problem has been properly documented and the resolution is correct. Once they have completed their task, they publish the knowledge to the knowledge base for reuse.In most environments the time it takes for new knowledge to be processed and then published is measured in days or even weeks. By the time the knowledge is published, the demand curve will have been missed. Consider this from business view point. The knowledge engineering process is an investment that the company is making. The return is then collected through the reuse of that knowledge after it is published. So what is happening while the knowledge is in the queue? When the next incident is reported to the support center, an analyst will search the knowledge base and not find it because it has not been published yet. While this is a now a known problem to the organization, the analyst assumes that it is an unknown problem and must do work to solve the problem. This is actually rework which as a cost to the organization. Once the analyst solves the problem, he or she submits the knowledge to the knowledge engineering queue. Unknowing to the analyst, this problem was already submitted and they just submitted a redundant solution. This process continues until the knowledge engineers publish the known problem in the knowledge base. During this time, the knowledge queue is getting longer with work that the knowledge engineers should not be doing, only adding to the delay in publishing new knowledge.Because this model has the delay in publishing new knowledge, the organization is working inefficiently and the return on investment for knowledge is low.
• #7: Now let’s look at the same scenario following the Knowledge-Centered Support methodology.After the first incident is reported the analyst contributes the new knowledge directly to the knowledge base for reuse by other analysts. This makes the known problem visible so that other analysts do not do rework. However, this knowledge has not been validated or verified. So the trust level is low. We will mark this knowledge as “Draft”As additional analysts interact with the Draft knowledge, they are responsible for ensuring that the resolution is correct before providing it to the customer. If they identify any errors or omissions in the knowledge, they are responsible to correct it before giving it to the customer and for correcting it in the knowledge base. In this methodology, we are letting the customer demand drive the need to review the knowledge just-in-time instead of the just-in-case model of knowledge engineering. And most importantly, we have eliminated the rework for resolving the same problem.Once we have evidence of demand, such as 3 or 4 reuses of the same knowledge, we can then elect to submit the knowledge to a compliance process for review. Since we are allowing demand to drive the items that are sent to the compliance process, only those problems that are repeatable are receiving the additional investment. This means that 80% of the problems are not being reviewed because the demand is not there and therefore the return will not be there as well. We have just reduced the workload in the compliance process by 80%. In addition, we have also removed the redundancy from this workload for an additional savings. Furthermore, the validation of the resolution will have already been completed by the 3 or 4 analysts that reused the solution before it was sent to the compliance process. Once the solution or knowledge goes through thru the compliance process, the knowledge will be marked as either Approved or Published. Both imply that the company trusts the knowledge to be correct. The knowledge would be marked Approved if it is for internal use. This lets the analyst know that the customer cannot see the knowledge via a self-service portal and that they can trust it. The knowledge would be marked “Published” if the knowledge is now available for customer self-service as well as analyst use.
• #16: When capturing knowledge as a by-product of resolving an incident, the analyst is not asked to perform additional work, only to do the activities that they should have been already been doing. Consider the information that the analyst is expected to capture in an incident or case record. The incident record can be organized into five sections.Administrative Information—this includes the name of the customer, contact information, record id, date, time, and impact, urgency, and priority of the situation.Problem—the problem or question the customer is calling about, the symptoms of the problem, and what the customer is trying to do/achieve. Environment—the product or service the problem relates to.Resolution—what was done by the analyst to resolve the problem or answer the question, which includes the detailed steps taken or the actual answer provided to the customer.Incident History—everything the analyst and customer did prior to resolving the problem and closing the incident. This includes information about various phone calls, e-mail messages, tests tried, escalations followed, and more.Capturing this information is part of a standard operating procedure for a support center. It is necessary to ensure that the information is captured in the structured format and according to the quality guidelines for the Problem, Environment, and Resolution fields to assure there is a findable and usable solution. The task that remains relates to making this solution searchable by others. The information captured in the incident record must be recorded in the knowledge base.
• #18: Learning Objective:Structured knowledge improves readabilityComplete thoughts are easier to read and capture then complete sentencesMost support analysts capture information in an incident record from their point of view. They author sentences in order to describe the situation and to tell the story. Reading this information can be laborious. When the same incident is captured using a structured format it is easier to read and understand. And the focus is now on complete thoughts, not complete sentences.