A major step toward KCS adoption embraces the distinctive, real time way knowledge is created and shared. Rather than being documented after the fact, KCS articles are created as part of the problem-solving process and immediately made visible to others. The capture process is integral to the problem-solving process: from the first customer descriptions of their issue to the final resolution, the article is built along the way. Even if a resolution is not yet known, the KCS article is visible to others, especially others working in the same product area. In this way, knowledge becomes a by-product of problem solving instead of an onerous and time-consuming additional step. If we are creating articles after the case is closed, we have missed the point and we are not doing KCS!
The integration of the knowledge base into the problem-solving process (search early, search often) greatly reduces the likelihood that we are working on issues that are already solved or are in the process of being solved. Searching is a form of capture.
The just-in-time theme in KCS is one of the things that differentiate it from a knowledge engineering approach. A knowledge-engineering process is characterized by subject matter experts (or technical writers) who review incidents and write articles in a process that is disconnected from the problem-solving process. This kind of an "after the fact" process is expensive, slow, and lacks the critical element of "context of use." The only way we have found to effectively capture context is in the moment of use; context cannot be recreated after the fact. Once we know the answer, it is hard to ask the question in a way that reflects not knowing the answer. Context is as important as content.
A research project on diagnostic skills was conducted with a medical doctor and an auto mechanic, both of whom were known to be very good at diagnosing issues in their respective fields. They were asked to write down how they diagnose a problem. They did. Then, the research team observed each of them diagnose issues in a real-life environment. Neither of them followed the procedure they wrote down. They both took cues from the situation and tapped into tacit knowledge to improvise a diagnostic process. They could not access that tacit knowledge to write down the process used in a real situation without the context of that situation. As Dave Snowden of Cognitive Edge says, "We don't know what we know until someone asks us." Most of us cannot provide all the information we have or know until we are asked the right question.
Problem solving is a creative process. It relies on experience, instinct, context, and the successful processing of multiple variables or inputs at once. This implicit information and our ability to link it to tacit knowledge is difficult to explain and it cannot be accessed or extracted if we try to recreate it in the absence of demand.
Tacit information becomes explicit in conversations, often in response to a question or in the context of the need for information. Therefore, when problem solving, we need to capture the information in the moment. We need to ensure that we capture the customer's context - their perception of the issue - as well as tacit knowledge as it become explicit in the process of solving the problem. This links what we know with the customer experience and creates a relevant and complete (findable and usable) picture of the issue.
Clarifying questions help to draw out and validate details that improve the success of problem solving. Searching the knowledge base can reveal similar situations and prompt clarifying questions that can validate or eliminate known issues. Finding similar issues helps us remember what know.
By capturing context-rich information from the beginning, the whole problem-solving and article creation process becomes easier and more effective. When another customer reports a similar problem, we will be better able to relate to the customer's experience and find relevant KCS articles quickly.