Downloaded 63 times
Uploaded byIT Service and Support
Kcs overview for detroit 2010
This document provides an overview of knowledge management best practices using the Knowledge-Centered Support (KCS) methodology. It discusses how KCS has evolved from traditional knowledge engineering approaches to become integrated into the problem-solving workflow. Key aspects of KCS include capturing knowledge as a byproduct of solving problems, evolving knowledge based on demand, and developing a collaborative knowledge base. The document outlines the KCS framework and processes and how they align with and enhance the ITIL framework for service management.
More Related Content
Similar to Kcs overview for detroit 2010
![KCS-Brochure[1]](https://cdn.slidesharecdn.com/ss_thumbnails/6e78203a-ccc9-4bdc-a048-c0b30f1b997f-161026100925-thumbnail.jpg?width=640&height=640&fit=bounds)
Kcs overview for detroit 2010
- 1. Knowledge Management inService Management:A KCSSM OverviewKCS is a service mark of the Consortium for Service Innovation
- 2. Do you successfullyleverage knowledge?Share the following information:What percentage of incidents reported are actually logged in your service management system?What percentage of incidents engaged a knowledge base?What is the percentage of success when searching knowledge?
- 3. Knowledge Management BestPracticesThe old way:Dedicated knowledge management team
- 4. Content created inpreparation of demand
- 5. Knowledge is verified,validated, and published
- 6. Knowledge is anoptional resource
- 7. Knowledge is someoneelse’s responsibilityKnown as Knowledge EngineeringFollows a manufacturing processThe Support Demand CurveDemandTime
- 8. Knowledge EngineeringDemandKnowledge isPublishedRedundancyX –Incident Z$ ReworkX –Incident Y$ ReturnTimeX – First IncidentKnowledge Engineering Queue$ Investment
- 9. Dynamic Knowledge ManagementDemandKnowledgeis Trusted1. Knowledge immediately available for reuse.$ ReturnRework and redundancy eliminated321 – First Incident2. Validation based on demandTime3. Compliance review based on demand$ Investment
- 10. Knowledge Management BestPracticesThe new way:Create content as a by-product of solving problems
- 11. Evolve content basedon demand and usage
- 12. Develop a KBof our collective experience to-date
- 13. Reward learning, collaboration,sharing and improvingKnown as Knowledge-Centered Support (KCS)Developed by the Consortium for Service Innovation
- 14.
- 15. Promoted by HDIin 2003
- 16. Compliments and enhancesITILSimple premise: To capture, structure, and re-use support knowledgeKCS is a service mark of the Consortium for Service Innovation
- 17. The Concepts ofKCSKCS is a methodology and a set of practices and processes that focuses on knowledge as a key asset of the support organization.KCS is not something we do in addition to solving problems…KCS becomes the way we solve problems
- 18. Top Ten Reasonsyou Need KCS10. Need to respond and resolve problems faster 9. Problems becoming more complex 8. Giving different answers to the same question 7. Support analysts suffering from burnout 6. Little time for training 5. Answering the same questions over and over 4. Opportunity to learn from customers’ experience 3. Need to improve first contact resolution 2. Enable web based self-help 1. You must lower your support costs!
- 19. Tangible BenefitsOperational efficiencyImprovedtime to resolve 30% - 60%
- 20. Increased support capacity 22% - >100%
- 21. Improved time toproficiency months to weeks
- 22. Efficient creation ofcontent to enable web self-help
- 23. Identification/elimination of rootcauses Increased job satisfactionLess redundant work
- 24.
- 25. Reduced training timeIncreasedcustomer satisfaction
- 26. Who Has Investedin KCS?Lucent
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
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.