KCS Adoption

KCS Roles: What do we do with our existing knowledge authors and editors?

We are looking to adopt KCS and we are wondering what we do with our exiting Knowledge Authors and Editors?

[Answered by Greg Oxton, 1 August 2017]

This is a common question/challenge for organizations who are moving from the traditional waterfall model for KM (knowledge from very few for the use of many) to the more dynamic KCS model (knowledge from many for the use of many).  The role the existing authors and editors play in KCS really depends on the individuals: their skills and flexibility. Some become KCS Coaches (if they understand the content standard and can deal with the "good enough” concept), some move to work on more formal documentation, some look after high-value self-service content and self-service pages. If they have subject matter expertise in a domain, they may become KDEs and focus on the high-value articles and/or complex issues.

KCS v6 makes the distinction between experience-based articles and compliance-based articles (see the Article Governance section in the Practices Guide). In environments that have compliance-based articles (policy, legal, or regulatory content), if the existing authors have the appropriate authority they may look after the compliance-based content.

KCS articles compliment more formal documentation.  See the Content Continuum in the KCS Practices Guide for more information on this concept.

Should we mass migrate existing content into a new knowledge base?

We are implementing KCS with a new tool, and one of the questions we have is about migrating content from the old knowledge base to the new one. I am trying to argue against mass migration, and am looking for examples of why mass migration is a bad idea.

[Answered by Greg Oxton, 18 August 2017]

Based on our members' experience over the past 20 years, we are adamant: do not mass migrate legacy content into a new KCS KB!

We have had lots of members spend lots of money doing a mass migration of legacy content into a new KCS KB only to find that it messes up findability. We have never seen this work (I mean, never).

There are a number of issues with a mass migration, but the primary one relates to the search engine index. When content that is in different structures and different context is indexed together, it greatly diminishes findability. When the content structure and context is consistent, it improves findability. So keep the legacy content around, but in a separate repository, indexed separately. Make it searchable, and if people find interesting content in the legacy KB, they should create a KCS article from the legacy content (put it in the context of the requestor and in the KCS structure). You will find that less than 10% of the legacy content is ever used and that after about 3-6 months no one is searching the legacy stuff because all the useful content has been pulled into the KCS KB. This is a demand-driven approach to migrating legacy content. It is efficient and it works.

You can, if you have reuse counts/indicators on the legacy content, review the top 100 or so legacy articles that have been used in the past 6-12 months and create KCS articles from them. Or, ask your support engineers to bring their 5-10 most frequently used legacy articles to the KCS training and create KCS articles from those legacy articles as part of the training. This seeds the new KCS KB with some useful articles; just be sure that people are searching before creating in the new KB to avoid creating duplicates!

See Dealing With Legacy Data in the Practices Guide for more information. 

How does KCS affect case closure codes?

[Answered by David Kay, 11 September 2017]

We like to say, there are only two types of case (or incident) closure codes: those that are too general to be useful, and those that are too specific for people to use them properly.

When Responders are linking (or otherwise indicating reuse) accurately and consistently, link reporting gives you all of the benefits of case closure codes with only a fraction of the pain.

So, KCS can either eliminate case closure codes, or reduce them to a small number that might explain why the Responder didn't reuse knowledge: the customer never responded, we don't know what fixed the issue, a simple transaction, etc.  If you do this, you can drop these cases from your Link Rate (f/k/a Participation Rate) calculation.

KCS doesn't make all case metadata go away, but we've found that simplifying the case documentation can be a powerful WIIFM for Responders, and case closure codes are a good place to start.

What are good names to simplify and easily explain validation status?

We are looking for best practices on a simple but effective execution of validation status.

What are good names to simplify and easily explain validation?  We were thinking of using:

• External - Validated
• Internal - Validated
• Not Validated
• But there is confusion among the engineers that "validation" should mean external... so we were thinking of:
• External - Validated
• Internal Only
• Not Validated

But then this would only give us visibility into validated external articles. We do not want to have MANY statuses to choose from and slow the process or confuse. Therefore, we are looking for best practices on a simple but effective execution of validation status?