Technique 5.2: KCS Article State

Article Confidence

To manage the readiness of a KCS article, we use article confidence to indicate where it is in its life cycle. All articles, regardless of the confidence we have in them, are worth sharing in case someone else is dealing with the same new issue.  As the article is resolved and then reused, we gain confidence in its quality.  Knowledge is never complete; it continues to evolve as it is used. Within this evolution, the KCS article life cycle is non-linear—KCS articles may move through the various qualities in many different ways.

• WIP - Work in Progress
• Not Validated
• Validated
• Archived

WORK IN PROGRESS (WIP)— the article does not include a resolution; the problem or question and some information about the environment has been captured but the resolution is not yet known. This is sometimes referred to as a "framed" article.

• Having WIP articles in the knowledge base helps us avoid duplicate work. This is especially true in moderate to highly complex environments where the resolution of issues often takes days or weeks. WIPs inform other knowledge workers that the issue is being worked on if they encounter a similar request. This visibility to work in progress promotes collaboration across the organization.

• WIPs are temporary. Generally they should become either Not Validated, Validated, or they should be deleted. If the issue is never resolved and the request is closed because it was abandoned by the requestor, the responder needs to decide if anything of value has been captured in the article.  If the request is no longer being worked and there is nothing of value in the article, then it should be deleted.   

• WIP helps responders manage pending work (as the name implies). WIPs give us an easy way to identify and manage incomplete articles in the KB.

NOT VALIDATED — the article is complete in that the article has a resolution, but we are not confident in the structure or content due to lack of feedback, others' use of the article, or because the article may not be structured or written in a way that complies with the content standard.  For example, the article may have been created by a KCS Candidate who does not yet have the skills to validate an article. 

• Not Validated gives us a way to capture the collective experience of the organization and distinguish between those articles we have confidence in (Validated) and those we don't (Not Validated). This allows knowledge workers to capture and share all their experiences.  

• Confidence - The Not Validated designation supports the concept of "capture everything." If the issue is worth answering or solving for the requestor, it is worth having in the KB. It also supports the concept of "sufficient to solve."  People are often hesitant to capture all of their experiences as articles in the KB if they are not confident in the resolution. Not Validated provides a way to indicate, "here is what I did in this situation, but I have not been able to validate the resolution or answer." 

• Efficiency - Let reuse of Not Validated articles be the review and drive the article life cycle.  Reviewing all Not Validated articles creates overhead and expense that produces very little value.

• The users of the KB who have visibility to Not Validated articles need to understand that Not Validated articles should not be used unless the article is relevant to the situation they are working on, and they have confidence in the resolution. Judgment is required.

• KCS Candidates (people learning the KCS Practices) can only create and modify Not Validated articles, which are then reviewed by a KCS Coach.

VALIDATED—The article is considered complete and reusable, and we are confident in it. The article is being worked by a licensed KCS user (KCS Contributor, Publisher, KDE or Coach) or by a KCS Candidate and it has been reviewed by their Coach.  The criteria to designate an article as validated are: 

1. Confidence - Responder confidence can be the result of confirmation from the user that the resolution worked, or the problem was recreated and the responder was able to validate the resolution, or, simply based on their experience, the responder is confident in the resolution.

2. Compliance with the content standard - The article is compliant with the content standard, written in the context of the requestor.

ARCHIVED—Archiving an article from the knowledge base is normally done only when the article is defined as having no value.  Archiving an article is better than deleting it. If an article has been linked to a request, you will not want to delete the actual article from the knowledge base as it will result in a broken link between the knowledge base and the system of record, incident, or ticketing.  A common method to remove the article from a searchable knowledge base is to set it to Archived.  The article is logically deleted from the knowledge base so that it will no longer be presented in a search results or browse function.  It can still be viewed from a previously linked incident or by an advanced search function that includes archived knowledge articles.

The confidence, audience, and governance fields are stored as part of the KCS article metadata. As an article evolves and is used, reviewed, and enhanced, the article state is updated. The article confidence affects the trust users place in its accuracy. Article confidence is extremely important and frequently referenced by the users of the knowledge; therefore technology should make the article confidence visible to the users.

An article can move through from the Not Validated to Validated qualities several times throughout its life cycle. The process will vary depending on:

• The KCS maturity of the organization
• The usage of the KCS article
• The license level of the person interacting with the article

Due to this dynamic, we may want to keep a copy of an article as it existed when we delivered it to a specific requestor. If we are supporting a mission-critical product or process, there are often regulatory compliance requirements that mandate capturing the situation exactly, noting the KCS article recommended, and explaining why. The exact KCS article can be preserved by copying a snapshot into the incident or by having version control for articles in the knowledge base.

Article Audience: Who Gets to See What

To manage who can see which KCS articles, we use article audience. As an organization, you may decide that you want to control what an external customer or an unidentified requestor has access to.  Business rules can then be established based on both article audience and article confidence.  You may decide that only Validated articles that you have confidence in can be visible to Partners and Customers.  As the article is designated as Validated and the reuse of that article has reached a certain threshold, it may become visible to a given audience.  Or, as the KCS implementation matures, the audience may expand.

• Internal
• Within a Domain
• Partners
• Customers
• Public

 

INTERNAL -  Only an audience internal to an organization will be able to see the article.  Note: anything with wider visibility than Internal is referred to as External.

WITHIN A DOMAIN - A group associated with a particular product domain, topic, job function, department etc.

PARTNERS - Someone who is not an employee but acts as a trusted extension of the organization.

CUSTOMERS - Customers or users of our products or services .  These articles typically are made accessible via a web-based self-service portal for registered users. 

PUBLIC -The KCS article is intended for anyone unidentified in the public domain. A common practice is to have this article optimized and indexed for a publicly available search appliance like Google.

Demand-based audience and confidence can be achieved by using these attributes in conjunction with reuse.

• Early in the KCS adoption, External, Validated articles become visible based on reuse.  Demand drives our attention to those articles that have value and therefore should be made visible to external users (customers, end-users, or partners). This demand-driven migration of articles should be temporary, replaced by the just-in-time publishing model of a mature KCS environment.  Unfortunately, organizations often get stuck in the "make External only after internal reuse" phase and as a result sub-optimize the benefits of KCS. Patterns of reuse external to the organization are different than patterns of reuse internally. While we are learning to do KCS, demand or reuse is a reasonable way to know what should be published.  However, to fully capitalize on what we know internally, we must make a high percentage of that available externally, and quickly.  This is why the "make External after reuse" model should be a temporary practice on the KCS journey. 
• In a mature KCS environment (Optimize and Innovate), we use the 90/0 goal: we should share most of what we know externally as quickly as we can.  90% of the articles in the KB should be available at or before the time of case closure. This will increase use of and success with self-service.

In the Optimize and Innovate phase of KCS transformation, we should have lots of KCS Publishers and we should be making judgments on moving Not Validated or Validated articles to become visible outside the organization as we create or reuse articles. The judgment to set the article audience is based on our confidence in the resolution and adherence to the the content standard.  In Optimize and Innovate, most articles created would be in Validated state with audience set to External.

A KCS Publisher can modify a Validated article.  Those who are not yet KCS Publishers, but who notice that the article does not comply with the KCS content standard, or otherwise requires enhancement, correction, updating, or improvement, should flag the article and mark it as Not Validated for review by a KCS Publisher (who may also be a Coach or a Knowledge Domain Expert).  Some KM technologies allow those who are not yet KCS Publishers to edit an unpublished version of the document while the current version stays on the web; this is desirable as it removes rework by the KCS Publisher, who need only approve the changes. In general, articles that have been published to the web should not be removed from the website if they have been flagged, although if the knowledge developer feels a Published article poses an active risk of harming customers, he or she should escalate the issue to a Coach or Knowledge Domain Expert immediately.

As we find and use KCS articles, we should improve them; reuse is review. As "flag it or fix it" becomes part of the culture, we are taking responsibility for the content that we interact with. This dynamic ensures the content being used is constantly being reviewed and improved. As the KCS articles improve and are validated through use, they should become visible to a broader audience and eventually be made visible externally. Early on in the KCS adoption process, organizations implement the concept of migrating content to be visible to customers through a variety of demand-driven techniques (mentioned above). In a mature KCS environment, a high percentage of content publishing is happening in real-time or just-in-time. (See case studies for examples of just-in-time publishing in action.)

To manage article audience, and thus appropriate levels of security for the knowledge, we recommend creating an Article State Matrix (example shown). This reference document maps the audiences (internal, partners, external) against the KCS article attributes that affect visibility (state, knowledge domain, special considerations) and defines access rights.

As the KCS practices mature in the organization, a just-in-time model for external visibility should be adopted, so that a high percentage of knowledge workers are licensed to make articles externally visible without review. This level of maturity takes time to develop and is most appropriate when the KCS workflow and content standard (discussed next) are well understood and have become second nature for the responders. Just-in-time external publishing requires people to make good judgments about technical and content accuracy. If they are licensed and confident in the article's accuracy, they should make it visible to the largest audience externally. If they are not confident in the article's accuracy, they should request a technical review.  Judgment is required.

Article Governance: Who Can Create or Modify

Article governance is an attribute of an article that allows you to control sensitive, critical, or regulated information. Not all articles have the same requirement for compliance reviews. Some articles are based on the collective experience of those who use the articles. Other articles have policy or legal information that require tight control. 

The governance attribute used in conjunction with KCS Roles enables us to manage articles and their state specific to the compliance requirement.

The two governance attributes that allow us to distinguish the collective experience articles from those that have compliance requirements are:

• Experience Based
• Compliance Based

Experience Based - The Experience Based attribute is the most open level of governance, and control is a function of being a member of the community and having an identity.  Sign-in is required.  The number of people with this level of rights and privileges will be very large; they can create and modify articles with the Collective attribute.  The individual's KCS license level defines their rights and privileges in setting the audience attribute (Internal, Partner, External) and the confidence attribute (Not Validated, Validated) 

Compliance Based - The Compliance Based attribute is restrictive, in that only designated individuals or specific groups of individuals can create and modify articles with the Compliance attribute. These articles contain information that describes policy, regulatory, or legal information. While everyone should be able to comment on all types of articles, not everyone can create or modify articles with the Compliance attribute.

KCS Stagnation

The flow or movement of articles through the life cycle states is an important indicator of the health of the KCS system. This is not to say all articles should necessarily move through the life cycle states, as reuse should be the driver of what moves and what doesn't.  Not Validated articles that have never been reused, or that we don't have confidence in, should stay Not Validated; Not Validated articles are okay.  However, articles that are being reused or that we have confidence in must eventually make it to Validated and visible outside of the organization (if appropriate).

Many organizations who do a great job at Adopting in Waves and Building Proficiency will realize significant operational improvement, and then the system slowly dies. People lose interest, participation rates drop off, and the benefits decline.  The common underlying theme in these scenarios is KCS stagnation: the flow of articles stops. By this we mean the organization has not created a self-service mechanism, or the rate at which articles are getting made available outside the organization is not sufficient to support success with self-service. The primary motivation for people to create and maintain the knowledge base is the promise of reducing redundant work - not solving the same problem over and over.  If articles are not visible externally, or there is no effective self-service model, the responders will not see a change in the ratio of known vs. new issues they are working on. They will lose interest in the KCS practices. The flow of articles through the states is critical for the sustainability of the KCS practices.