Definition of knowledge management (KM)

Knowledge management (KM) seeks to treat knowledge as a valuable resource by establishing processes for capturing, developing, sharing, and effectively using organizational knowledge.

KM models typically employ a database of knowledge (i.e., "knowledge base") for storing the organizational knowledge. This knowledge base (KB) may have multiple tiers or pools of knowledge for the purposes of limiting the audience of particular articles within KB.

Definition of Knowledge-Centered Service (KCS)

Knowledge-Centered Service (KCS), formerly Knowledge-Centered Support, is a particular methodology and a set of practices and processes for implementing knowledge management in the best manner possible. Its basic premise is that service organizations should center their processes around knowledge. KCS is not something that service organizations add to the process by which they solve problems; KCS becomes the way they solve problems.

Development of KCS began in 1992 by the Consortium for Service Innovation, a non-profit alliance of service organizations (Yahoo, Microsoft, HP, Cisco, HDI, etc.).

Benefits of KCS

The benefits are as follows:

• Organization never has to solve the same problem twice
• Increase first call resolution
• Reduce escalations, transfers, repeated calls, and on-site visits
• Reduce training time
• Reduce cost of service
• Leverage customer self-service by empowering customers to help themselves
• Increase customer satisfaction
• Increase employee satisfaction and productivity

How KCS relates to ITIL

KCS compliments the ITIL framework by providing a strategy for capturing, structuring, and reusing knowledge within the service organization.

Knowledge management is defined as a required process in ITIL. However, ITIL is a framework, not a methodology. It describes the organization of tasks but isn't prescriptive about how to do them. By contrast, KCS focuses on particular aspects of service delivery—in particular, the integration of knowledge into the workflow—and is much more specific about what staff and organizations should do. In this way, KCS "plugs in" to the ITIL framework, providing specific guidance for organizations, especially in what ITIL calls incident management, but also with problem, change, release, deployment, and service level management.

The two loops of KCS

The KCS model has a Solve Loop and an Evolve Loop, and each one has four components.

Solve Loop - Involves all members of the service organization, from management to frontline support.

Capture

Knowledge is created as a by-product of solving problems. That knowledge should be:

• captured in the context of the customer, using their perception of the request/incident and using their vocabulary. This is critical to the findability and usability of the article later.
• captured immediately, as we help the customer. It is not something we do at a later time, because:
  • it's more difficult to do later (we get busy, forget, tend to delegate it to someone else, etc.),
  • doing it immediately makes the knowledge available for others to use, and
  • as time goes on, we lose the customer's vocabulary and context, and we tend to put things in our own words/context.
• made available immediate as a draft to the widest audience possible.

Capturing knowledge in the service workflow means that:

• knowledge may be messy, and that's OK, because:
  • knowledge shared verbally is sometimes messy;
  • employees are going to share knowledge anyway (verbally, by email, etc.), so they should be allowed to share knowledge in a structured format where everyone can benefit, where management and knowledge experts can "massage" the knowledge to make it more credible/accurate, and where the knowledge can eventually be published to the customer portal where customers can directly benefit;
  • messy knowledge available now to customers and support agents is preferable to perfect knowledge six months from now. Customers and agents need knowledge now.

A good rule of thumb: "Ninety percent of what we know should be in the knowledge base within 90 minutes."

Structure

Knowledge should be structured in a way that makes using the knowledge base consistent and easier. Ideally, the structure of a knowledge document and a customer's request/incident should be similar, allowing knowledge captured during the service process to easily be exported from the service management system to the knowledge management system.

Reuse

We should search the KB early in the service process, and we should search often after that. The more we view and use the KB content, the more likely we will notice areas which need improvement as we compare the KB content to what we execute during the service process.

Improve

As we reuse the KB content and notice areas which need improved, we should either fix the content ourselves (ideal) or flag the content for someone else to fix. At a minimum, of these two things should happen when content needs improved in some way.

A useful acronym for remembering to execute the Solve Loop is UFFA (pronounced oof'-uh):

Use It - If the knowledge article we used to resolve the customer's request/incident is in the KB, then we simply use it.

Fix It - If the article we used to resolve the customer's request/incident is in the KB but needs improved in some way, then we either immediately fix it ourselves, or immediately…

Flag It - for someone else to fix.

Add It - If the article we used to resolve the customer's request/incident is not in the KB, then we immediately add it.

The Solve Loop ensures that demand and usage drive content.

Evolve Loop - Implemented by the organization and its leaders on an ongoing basis. The Evolve Loop supports the Solve Loop.

Content health

The organization should ensure that either an individual or a team is spending time on the health of the content in the KB. Ways of accomplishing this are:

• Keep abreast of new service rollouts or being involved in the change management process for existing services.
• Add value-added content such as videos or resolution wizards (decision trees).
• Spend time on high-impact topics (e.g., "top ten calls to the service desk").
• Watch metrics. Consider the search terms that the audience is using. Consider the articles on which audience members are clicking "Yes, this was helpful."

Process integration

Process integration should make the Solve Loop as seamless as possible. Effort should be spent on making additions/edits to the KB easier, not more difficult. A good way to do this is by ensuring that busy support personnel do not have to spend time on redundant data entry. For instance, a button may be placed in the IT service management application to convert a customer incident into a KB article instantly. Such KB tools should operate at the speed of conversation so that personnel can add/edit KB content during the service workflow with the click of a button or two. Technology should not be a roadblock.

To ensure that individuals can add/edit articles in the knowledge base in the workflow when KCS is initially rolled out, management/supervisors should ensure that their subordinates have ample time between calls/on-site visits to focus on knowledge improvement. Once support personnel get accustomed to the KCS concepts, wrap-up time and time between on-site visits can be returned to normal.

Performance enhancement

If knowledge is our focus and our service is knowledge-centered, then part of employee performance reviews should include a review of their contribution to the knowledge effort, and job descriptions should clearly define the person's responsibilities in keeping the KB up-to-date.

The focus should be on outcomes, not activities. For instance, a bad approach (focusing on activities) would be to say, "Agents must add at least three articles per week to the KB." Such an approach will ensure that many poor quality articles are created simply for the purpose of fulfilling a quota.

When reviewing performance, a better approach (focusing on outcomes) is to look at something such as, "How many articles did Agent X create on which lots of customers clicked, 'Yes, this was helpful,'?" Some companies following KCS calculate an "UFFA Percentage", which is the number of times the support person followed UFFA divided by the number of requests/incidents/interactions they worked.

If performance in contributing to knowledge is going to be reviewed, then the organization must have clearly-published standards on what constitutes a high-quality article. Instructions, templates, and style guides should be written and made readily available.

Some organizations establish roles, such as:

• KCS Contributor (as an analogy, equivalent to a junior driver or licensed teenage driver)
• KCS Coach (equivalent to a licensed adult driver or parent driver)
• KCS Specialist (equivalent to a police officer, driver's education instructor, or a driver with specialized skills)
• KCS Coordinator (equivalent to a judge)

Leadership & communication

Management should be reminding employees frequently of the vision of KCS and how it helps customers, the company, and each team member personally. KCS is not only a methodology; it involves a team of people from executives all the way down to the person answering the phone on the front line. Viewing KCS as just a "system" that we implement and walk away from will ensure failure.

KCS is a culture. It can't be simply a statement on the wall that everyone is expected to follow. It has to be driven from every level of the organization from the time a new employee is trained, through how job success is evaluated, through how upper management communicates.

Passive buy-in on the part of management is not enough for a successful KCS implementation; they must actively support it through persistent articulation and advocacy. It also requires a commitment of resources and budget.