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 audience management
- KCS article state categories
- Search arguments are preserved as the basis for a new KCS article
- Reporting and metrics
To find out which vendors' products are verified or to get a detailed list of all the requirements, visit the KCS Academy web site.
Integration of Workflow and Technology with CRM, IM, and Other Tools
Ideally, technology enables the problem solving process in the Solve Loop at the speed of conversation, or real-time. Responders become more proficient at the process and solve problems faster by using the experiences of the entire 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 (a knowledge worker's 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 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 started with this "ideal" user interface. This level of integration should not be viewed as a requirement to start out; 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 five or ten minutes and the level of redundant work is very high. That is, responders are resolving the same issue over and over again. In this environment the workflow described above does not make sense. Responders 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 responder 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 responder 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 responder 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.
- Eliminate the notion of separate tools: the integration of case management, knowledge management, and collaboration functionality.
- Make it easy and obvious for the responders 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 responders' 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 responders, 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 responders 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
Again, 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 integration. Don't feel you cannot start on the KCS journey unless you have what is outlined here. This represents the ideal—something to aspire to as your adoption and technology infrastructure mature.
Integration With Web Portals and Online Processes
While there are compelling benefits from the adoption of KCS internally, even more value can be created by delivering articles directly to the users via self-service mechanisms. We have learned, however, that self-service users follow a different workflow. The self-service workflow takes advantage of easy access, the presence of online communities, and economies of scale.
Although the self-service 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 the design is the idea of "no dead ends." If a user starts the problem solving process using the self-service knowledge base but does not find anything helpful, it is important to allow them to easily move from the self-service path to the assisted path. A "click to submit" or "click to chat" button should take them from self-service mode to the assisted mode and preserve the content of their earlier searches, including the documents they have reviewed. This seamless, logical transition improves the user's experience and encourages future use of the self-service path because it is the path of least resistance and best results.