Technology is a critical enabler for KCS. It would be possible to follow the process of KCS using paper and pencil, but only if there were no more than two people engaged in the same room at the same time and they agreed on a filing system! Once there are more than two people participating, or we want to collaborate across different locations, we need technology. It supports the scaling of the processes to multiple people in multiple locations who are most likely working at different times. Technology and the KCS methodology allow us to collaborate independent of space and time.
KCS can be enabled with many different technologies. The Consortium has developed a KCS Verified program to help in the tool selection process. Software products become KCS Verified by demonstrating support for the following sample criteria:
An article object and search engine
Supports distinction between problem content and environment content
Search engine granularity
Search problem content against problem content
Search environment content against environment content
Ability to link/point/relate incidents to KCS articles and KCS articles to incidents
KCS article visibility management
KCS article state categories
Search arguments are preserved as the basis for a new KCS article
Reporting and metrics
Functions at the speed of conversation
To find out which vendors' products are certified or to get a detailed list of all the requirements, visit the KCS Academy web site at www.thekcsacademy.net.
Ideally, support technology enables the problem solving process in the Solve Loop at the speed of conversation, or real-time. Analysts become more proficient at the process and solve problems faster by using the experiences of the entire support organization and minimize rework.
To achieve this "speed of conversation" goal, the tools being used must be integrated to enable a seamless workflow where interaction with the knowledge base and KCS article creation are integrated with problem solving. For example, an ideal integration between a knowledge management system and an incident management system might include the following capabilities:
Search the knowledge base using information in the incident record to launch or refine the search
Link an existing KCS article to an incident and to retrieve information from the KCS article, such as the resolution, to populate the incident record. Linking can occur with two types of knowledge: reference information and resolution/fix information. Reference information is information found in reference materials such as service manuals or installation manuals. The specific sentence or paragraph must be findable by the search engine, the information must be accessible by the audience being served, it must be in the context of the audience being served, and it must be in a maintained repository.
View a KCS article that has been linked to an incident, and vice versa
Modify existing KCS articles in the process of reuse ("reuse is review") based on the KCS licensing model
Create a KCS article in the knowledge base from information in the incident record
Collaborate with the subject matter experts who are relevant to the problem and quickly contact them through email or chat
The following is a prototype of a Support Analyst's view, or user interface, to the system. The typical service environment we see has an application user interface that most often demands the users' behavior align to the needs of the application. For organizations in a position to adapt the user interface, we are instead proposing a user interface that aligns more directly to the needs of the user.
The optimal environment has a tight integration between incident management and knowledge management systems such that users do not have to move between applications. However, most of the KCS adoptions have not had the luxury of starting with this kind of tight integration. Success has been achieved with very crude integrations. Don't feel you cannot start on the KCS journey unless you have what is outline here. It is the ideal—something to aspire to as your adoption and technology infrastructure mature.
Eliminating the notion of separate tools; the integration of case management, knowledge management and collaboration functionality.
Make it easy and obvious for the Support Analysts to do the right thing
Minimize context switching, screen changes/application changes - create "a single pane of glass" or a "one page interface" that has the functionality needed for the majority of the incidents (don't waste real estate on seldom used functionality).
Align with and support the Support Analysts' problem solving process
Capitalize on all that is known and already entered (no duplication of work)
Integrate what is known from all/multiple sources
About the customer, the account, entitlement, the product and the problem/question
We can have the best tools and user interfaces in the world but... if we don't understand why and how to use them it won't matter. A good user interface must be complimented with good measures (based on outcome and value creation not activity), understanding and buy-in on the part of the Support Analysts and coaching to support behavior change.
Five things that influence behavior (in no particular order):
The tool - functionality, navigation, integration - make it really easy to do the right thing
Measures - how are people measured
Recognition and reputation - ego food
Understanding - the extent to which the Support Analysts understand WIIFM (what's in it for me) as well as the bigger picture: what's in it for the company and the customers.
Coaching - peers who are trusted change agents and role models
The closed incident captures the KCS article, in the form of Problem, Environment and Resolution, as it was given to the customer—a snapshot of the KCS article. The KCS article continues to evolve as it is reused.
No support organization that has adopted KCS has had this "ideal" user interface. This level of integration should not be viewed as a requirement to get started; many have created great benefit with little or no integration between their incident management and knowledge management applications. However, sustainability of the KCS practices requires that the users see continuous improvement in the level of integration. The KCS Coaches and Knowledge Domain Experts should provide requirements to the owners of the user interface to promote continuous improvement in the design and functionality of the infrastructure.
The workflow below shows how an individual resolution might unfold.
The workflow above is offered as an example; it is a place to start the design. Every organization will have variations. The workflow designed must consider the tools being used and the nature of the products and customers being supported.
The two key considerations in designing the workflow are complexity and volume. High complexity and low volume environments typically have longer resolution times and more frequent use of the knowledge base throughout the problem solving process. The workflow above is an example of a medium to high complexity environment. In a low complexity, high volume environment the average resolution times may be 5 - 10 minutes and the level of redundant work is very high. That is, Support Analysts are resolving the same issue over and over again. In this environment the workflow described above does not make sense. Support Analysts are not going to search for an answer in the knowledge base that they already know and use every day and can resolve in a matter of minutes. However, we still want to know how often issues are being resolved and we need a way to notify a Support Analyst if there is new information about the issues or resolution.
Organizations that deal with frequently used and widely known resolutions will often create a "quick click" list or a favorite list of articles. This is most effective when the list is unique to each user although it can be done at a team level. The "quick click" feature enables the Support Analyst to record, with a single click, the fact that this issue was handled again. The click increments the use count for the article. This is critical information to capture as it is used in the Evolve Loop to identify patterns of reuse.
Also, clicking the article creates an opportunity to offer the Support Analyst the latest information about that article through a pop up window or by opening the article. This should only be done to communicate changes in what is known about the issue and once the new information becomes widely known the "pop up" feature for that article should be turned off.
While there are compelling benefits from the adoption of KCS internally, even more value can be created by delivering articles directly to the customer via web-based self-help. We have learned, however, that web users follow a different workflow. The web workflow takes advantage of easy access, the presence of online communities, and economies of scale.
Although the online workflow is different from the traditional call flow, the technology used for the portal must integrate seamlessly with and support the process of submitting a request for assistance to the support center (an incident). A key point in portal design is the idea of "no dead ends." If a web user starts the problem solving process using the web-based knowledge base but do not find anything helpful, it is important to allow them to escalate. A "click to submit" or "click to chat" button should take them from self-help mode to the assisted mode of support and preserve the content of their earlier searches, including the documents they have reviewed. This seamless, logical transition improves the user's experience on the web and reinforces future use of the web as the path of least resistance and best results.