Kcs overview for detroit 2010
•Download as PPTX, PDF•
2 likes•995 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kcs overview for detroit 2010
Similar to Kcs overview for detroit 2010 (20)
More from IT Service and Support
More from IT Service and Support (20)
Recently uploaded
Recently uploaded (20)
Kcs overview for detroit 2010
- 1. Knowledge Management in Service Management:A KCSSM Overview KCS is a service mark of the Consortium for Service Innovation
- 2. Do you successfully leverage 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?
- 4. Content created in preparation of demand
- 5. Knowledge is verified, validated, and published
- 6. Knowledge is an optional resource
- 8. Knowledge Engineering Demand Knowledge is Published Redundancy X –Incident Z $ Rework X –Incident Y $ Return Time X – First Incident Knowledge Engineering Queue $ Investment
- 9. Dynamic Knowledge Management Demand Knowledge is Trusted 1. Knowledge immediately available for reuse. $ Return Rework and redundancy eliminated 3 2 1 – First Incident 2. Validation based on demand Time 3. Compliance review based on demand $ Investment
- 11. Evolve content based on demand and usage
- 12. Develop a KB of our collective experience to-date
- 14. Research began in 1992
- 15. Promoted by HDI in 2003
- 16. Compliments and enhances ITILSimple premise: To capture, structure, and re-use support knowledge KCS is a service mark of the Consortium for Service Innovation
- 17. The Concepts of KCS KCS 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 Reasons you Need KCS 10. 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!
- 20. Increased support capacity 22% - >100%
- 21. Improved time to proficiency months to weeks
- 22. Efficient creation of content to enable web self-help
- 24. More confidence
- 25. Reduced training timeIncreased customer satisfaction
- 27. Nortel Networks
- 28. Motorola
- 29. 3Com
- 30. Unisys
- 32. Intel
- 33. Network App.
- 34. BMC Software
- 35. QAD
- 36. SGI
- 38. Abbot Labs
- 39. JP Morgan Chase
- 40. Sanofi-Aventis
- 41. VeriSign
- 42. Pepsi Co.
- 44. Microsoft
- 45. EMC
- 46. Mosaix
- 47. Compaq
- 48. Novell
- 49. HP
- 50. Oracle
- 51. Legato
- 53. Solve Capture in The workflow Leadership Structure For reuse Performance Assessment Searching Is creating Content Vitality Knowledge Just-in-time Solution Quality Workflow Evolve KCS Processes
- 54. The KCS Solution Concept Customers Integrating the experience of the three stakeholders Company Analysts
- 56. Capture information about the environment
- 60. Improves readability of the solutions
- 63. Windows 98
- 64. Compaq PresarioResolution: 1. Download latest driver for Network Card 300X from 3Com www.3com.com/drvrs/NIC 2. Follow the installation instruction on the 3Com site.
- 65. Problem Question Error Message Symptoms Keywords Environment Application Hardware Cause Resolution Resolution Detail Links to Related Info ID Number Title Abstract / Summary Meta Data Audience Categorization Create Date/Time Modified Date/Time Author / Modified By Source History Information Structured Knowledge
- 67. The description of a problem is valuable
- 69. Modify solutions based on usage
- 70. Flag It or Fix It
- 73. MAN
- 74. OWL
- 75. PIG
- 76. RAT
- 77. RAY (Fish)
- 78. ROO
- 79. YAK
- 80. ZHO (cross between a Yak & Cow)ANT APE AUK (Bird) BAT BOA BOY BUG CAT COD (Fish) COW DOG DOE EEL ELK EWE FLY HEN HOG SNAKE JAY (Bird) KID
- 87. Feedback system
- 88. Integration of subjective measure with objective measures
- 89. Outcomes/results are distinct from leading indicators/activities
- 92. Define the organizational purpose and objectives
- 93. Support and encourage good performance and deal with inadequate performance
- 95. Solve Capture in The workflow Leadership Structure For reuse Performance Assessment Searching Is creating Content Vitality Knowledge Just-in-time Solution Quality Workflow Evolve KCS Processes
- 96. How does KCS Align with ITIL?
- 97. KCS and ITIL KCS ITIL Developed by the Consortium for Service Innovation, a non-profit member based organization in the United States in 1992 Designed to improve support operations of member companies Contributed to by senior support practitioners from global corporations Developed by the United Kingdom’s Office of Government Commerce (OCG) in the 1980’s Intended to improve management of IT services in the UK Central Government Contributed to by expert IT practitioners around the world 1-23
- 98. KCS and ITIL Similarities KCS and ITIL are similar in that both: Were developed to improve service management effectiveness and efficiencies Are based on process and not technology Claim that knowledge management is a required process within service management Continue to evolve and mature Are acknowledged as best practices 1-23
- 99. KCS and ITIL Differences 1-23
- 100. ITIL Service Knowledge Management System Presentation Layer Knowledge Processing Layer Service Knowledge Management Base Information Integration Layer Data and Information Sources and Tools Source: Service Transition, Pg. 151
- 102. Created an all encompassing Service Knowledge Management System
- 103. Promotes the benefits of KM
- 104. Defines knowledge inconsistently and terminology is not aligned
- 105. Provides some high level requirements
- 106. Lacks a strategy for integrating KM
- 107. Requires metrics be defined and monitored
- 108. Does not define metrics or how to evaluate them
- 109. Defines the purpose for KM
- 110. Lacks how to guidance for KM
- 112. Forget the business goals and only focus on KM Too many states in the workflow Converting legacy data Selecting versus inviting Focusing on laggards Communications plan is too short Pilot team not broad enough Setting goals on activities Over engineering Recognize the Ditches Expanding to fast Content standard too complex Random scoring too rigid Picking the wrong coach Lack of coaching support Inconsistent coaching practices Lack of reports Not adjusting Performance Assessment Managers telling instead of motivating
- 113. DISCUSSION We don’t have a KM system, how can you get started now? We have a KM system, what should we do now?
- 114. Where to learn more… HDI’s Knowledge Management Foundations: KCS Principles workshop HDI’s Knowledge-Centered Support Fundamentals HDI Webinar Archives HDI Focus Book: Knowledge Management Maturity Model www.serviceinnovations.org
- 115. Knowledge Management in IT Service Management:A KCSSM OverviewRick JoslinExecutive Director, Certification & Trainingrjoslin@thinkhdi.com KCS is a service mark of the Consortium for Service Innovation
Editor's Notes
- 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.
- 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.
- 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.