1. KCS I
1.1. Range of Knowledge - Describe / Explain / Demonstrate
1.1.1. Call / incident management and knowledge management functions
1.1.1.1. Identify where pieces of information belong
1.1.1.1.1. Customer name, contact, contract/entitlement, severity level are all call/incident related
1.1.1.1.2. Problem description, relevant environment information, the answer/fix to the problem and cause information are reusable and go in the knowledgebase
1.1.2. Knowledge and the purpose of a Knowledgebase
1.1.2.1. Knowledge is actionable information; it is a collection of data that describes activities that will produce a desired outcome
1.1.2.2. The knowledgebase complements the support analyst’s experience, use of a knowledgebase requires judgment and skill, and a support analyst should never deliver a solution to a customer that they do not understand.
1.1.2.3. A knowledgebase is the collection of experiences to-date of the organization, at any point in time it represents the best understanding of what we have collectively learned.
1.1.3. The concept of a “solution”
1.1.3.1. A solution is:
1.1.3.1.1. The name we use for the knowledge object
1.1.3.1.2. The place we capture the problem solving experience
1.1.3.1.3. Solutions contain the problem description as experienced by the customer, information about the environment in which the problem occurred, answers, fix or work-around for the problem, and the cause of the problem
1.1.3.1.4. Solutions have a life cycle, at the outset they may only contain a description of the problem (work in progress), when the problem is resolved they contain the fix/answer and the cause (verified)
1.1.3.1.5. Solutions are dynamic; they are constantly being updated through use. “A solution is complete when it is obsolete”
1.1.4. KCS, the workflow and the Structured Problem Solving process
1.1.4.1. KCS is a problem solving methodology that includes searching and updating a knowledgebase.
1.1.4.2. Capture individual experiences in solving problems to create a collective / organizational memory
1.1.5. Capturing the customer’s experience in the workflow
1.1.5.1. Literal element of the structured problem solving process
1.1.6. Capturing the customer experience, in their terminology is critical for future find ability
1.1.7. Searching techniques
1.1.7.1. First capture customer perspective and search using customer language
1.1.7.2. Use your own words to refine the search
1.1.7.3. Queries, looking for criteria fit, date range, created by, status
1.1.7.4. Natural language searching
1.1.7.5. Associative searches
1.1.7.5.1. Keyword searching and Boolean commands
1.1.7.6. Browsing
1.1.8. Content structure
1.1.8.1. The power of context Identify good content structure
1.1.8.1.1. In the context (vocabulary) of the target audience
1.1.8.1.2. Correct - Separate problem content from environment content
1.1.8.1.3. Concise - complete thoughts, not complete sentences
1.1.8.1.4. Clear - independent thoughts, not multiple thoughts
1.1.8.1.5. The goal is findable, usable solutions
1.1.9. When to initiate a search
1.1.9.1. Gathering sufficient information a description of the problem and a few words/phrases about the environment
1.1.9.2. Search early, search often, this ensures you are not working on a problem that has already been solved
1.1.10. When to STOP searching
1.1.10.1. When the search statements have been refined; the problem statement is complete and we have collected 2 -3 characteristics about the environment that are believed to be relevant. If at this point the search response is not providing anything that appears relevant then it is time to move into the analysis phase of problem solving
1.1.11. Concepts of the content standard and solution structure
1.1.11.1. Basic types of content
1.1.11.1.1. Problem description – symptoms, unexpected results, error messages, goal or description of what they are trying to do. The resolution answers/resolves the problem description
1.1.11.1.2. Environment – products involved (hardware, software, and networks) release or version, recent changes to the environment. The environment statements do not change when the problem is resolved
1.1.11.1.3. Resolution – the answer to the question, a work-around, circumvention or by-pass, fix
1.1.11.1.4. Cause – background reasons for the problem or question (optional)
1.1.12. The concept of reuse and the value of tracking reuse
1.1.12.1. Reuse of solutions in the knowledgebase drives
1.1.12.1.1. Identification of content that should be made available to a wider audience
1.1.12.1.2. Identification of issues that need to be addressed by product or application development
1.1.12.1.3. Identification of process failures
1.1.13. Structured Problem Solving (SPS)
1.1.13.1. Key elements of the Structure Problem Solving Process
1.1.13.1.1. Manage the call/conversation; deal with the administrative elements at the beginning (call initiation) and end of the call (wrap up). This will allow focus on the cuser’s objective of problem solving
1.1.13.1.2. The SPS process [admin….Literal .... Diagnostic …. Research …admin]
1.1.13.1.3. The SPS process involves application of a methodology for collecting, organizing, and analyzing details which develops a constructive outcome. The end-point should be an understanding of the situation and a resolution or answer
1.1.14. The dynamics of solution reuse
1.1.14.1. Reuse of solutions is generally a good thing, however:
1.1.14.1.1. Low levels of reuse can be an indicator that the solutions are not findable due to structure issues or problems with the search algorithms
1.1.14.1.2. High levels of reuse can be an indicator that the sources of the exceptions are not being removed from the environment
1.1.15. Create a new solution Vs. reuse an existing one
1.1.15.1. Two key points about creating a new solution Vs.. updating an existing solution
1.1.15.1.1. Solution creation should occur when a unique entity is required to address a set of circumstances not yet documented in the KB
1.1.15.1.2. A newly created solution may or may not be complete, but it adds value to the knowledge-sharing process
1.1.16. Solution meta data and concepts of the solution life cycle
1.1.16.1. Solution creation involves adding attributes to a solution that help organize the KB content, control visibility, and facilitate assessing the value of solution entities. Managing both data and metadata is required for effective solution creation
1.1.17. Understands the organizational value of KCS, can explain the benefits of sharing knowledge Benefits to each of the three stakeholders
1.1.17.1. Analysts – less redundant work, recognition for problem solving skills, individual learning and the learning of others. Confidence in working on new areas/technologies
1.1.17.2. Users – speed, accuracy and consistency of answers
1.1.17.3. Organization – cost savings through operational efficiencies, increased customer loyalty
2. All of the KCS I competencies plus the following: Topic KCS II - Range of Knowledge Describe / Explain / Demonstrate
2.1. Solution quality
2.1.1. Consistently creates solutions that do not require rework (based on performance in the environment)
2.1.2. Collective ownership “if you find it/use it, you own it”. It is critical that the users of the knowledge take responsibility for what they see and use in the knowledgebase – If a solution is unclear they should “fix it or flag it”
2.1.3. Solution review processes in the workflow and random sampling
2.1.4. Concepts of findability and usability, criteria for a good solution; key things to look for;
2.1.4.1. Correct – words and phrases are in the right place (problem Vs.. environment)
2.1.4.2. Clear - single thoughts not compound thoughts
2.1.4.3. Customer requirements are speed and accuracy
2.2. Improve, modify concepts
2.2.1. The balance of diversity and consistency; problems should be described in as many ways as customers will experience them, the environment should be described in a standard/consistent way
2.2.2. Sensitivity to personal preferences and style differences vs.. good statement structure and the quality requirements that support "use ability" and "find ability" (the concept of good enough)
2.2.3. Ideally, there should be one solution per problem. However, this is not an absolute and the criteria should be developed based on experience in the environment. Some exceptions that need to be considered are:
2.2.3.1. Context – two solutions may exist for the same problem but are targeted at different audiences (novice vs.. expert)
2.3. Managing Solution Visibility
2.3.1. Solutions that are reused are candidates for a larger audience; they should be moved closer to the user
2.3.2. It is important that not everyone be able to see everything that is in the knowledgebase, visibility should be appropriate to the audience
2.4. Concepts of context
2.4.1. Context – vocabulary and technical perspective/capability of different solution audiences
2.4.2. Solutions are created in the context of a specific audience
2.5. Fix / answer description format and context of the audience
2.5.1. Balance between completeness and usability/brevity
2.5.2. Using numbered steps to describe a resolution process
2.5.3. Must be in the vocabulary and technical perspective/capability of the target audience (context)
2.6. Don’t over generalize – solution should evolve through use and should be specific to the experience of solving a customer’s problem. Generally, attempts should not be made to extend solutions to cover all possible situations that might occur. Solution extension should be based on demand.
2.7. Capture in the workflow and Structured Problem Solving
2.7.1. The value of capture in the workflow:
2.7.1.1. Capturing the customer context, if not done during the conversation it will be lost.
2.7.1.2. Capturing the problem and some environment information in the workflow enables the “search early, search often” practice. This reduces the risk of spending time solving a problem that has already been solved.
2.8. Relevant Vs.vs.. unrelevant statements
2.8.1. The need for judgment in reviewing solutions, customers will often provide information that has no relevance to the situation.
2.9. Issues of redundancy
2.9.1. A certain level of redundancy and diversity in a knowledge practice is healthy. Redundancy becomes a problem only when it adversely affects the findability and usability of the content
2.9.2. Examples of acceptable redundancy
2.9.3. Solutions for the same situation but for different target audiences
2.9.4. Solutions that capture wholly different experiences but have the same resolution
2.9.5. The content standard should describe the criteria for unwanted redundancy and as redundant solutions are found they should be merged into one
3. KCS II
4. KCS III
4.1. Publisher All of the KCS II competencies plus the following:
4.1.1. Topic Knowledge Domain Expert Range of Knowledge Describe/Explain/Demonstrate
4.1.2. Concept of Coach
4.1.2.1. best practices expert
4.1.2.2. Change analyst
4.1.2.3. Support and encourage learning
4.1.2.4. Provide constructive feedback on work habits and solutions created
4.1.2.5. Participate with other Coaches on developing improvements to the workflow, the content standard and lifecycle, and identifying requirements for the infrastructure (tools/technology)
4.1.2.6. Monitor leading indicators (activities) for individuals – solution creation, reuse and modify
4.1.2.7. Goal of the coach
4.1.2.7.1. move people along the workflow so that they can consistently create solutions that do not need review or rework
4.1.3. Infuence Skills
4.1.3.1. Fundamental principles of motivation for people – the 2 top motivators for people are a sense of achievement and recognition
4.1.3.2. Respect for the support analysts and the learning process
4.1.3.3. Mindful of the feelings of the support analysts
4.1.3.4. The power and benefit of collaboration – sharing what we each know gives us access to what we all know
4.1.4. SolutionLifecycle
4.1.4.1. Solutions are intended to capture the collective experience of the organization and ultimately the customer.
4.1.4.2. A solution has a lifecycle because at its inception it will only contain the question or problem that has been identified, it must be designated as a “work-in-progress” so its visibility is limited
4.1.4.3. Capturing everything in the knowledgebase enables collaboration independent of space and time
4.1.5. Solution quality
4.1.5.1. Criteria for reviewing solution quality
4.1.5.1.1. the balance of speed and accuracy with solution “beauty”,solutions need to be good enough to be found and useful