Article state is comprised of three metadata fields: article confidence, article audience (formerly known as article visibility), and article governance. The confidence of an article tells us about the level of certainty we have in the article's structure and content. The article audience adds an additional layer of control that allows you to create business rules allowing different access to different audiences. The article governance is another level of segmentation by subject matter. The KCS Roles or licensing model indicates which users have demonstrated the competence to create quality articles and the judgment to make them visible to the appropriate audience.
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
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:
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.
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.
Following are a few examples of quality transitions.
Work in Progress (WIP)
- A WIP is created at or near the point in time the first search is done on the issue
- A WIP becomes a Not Validated if:
- The article is complete but created by a KCS Candidate (KCS I)
- The article is complete, created by a KCS Contributor or Publisher but confidence in the resolution is low
- A WIP becomes Validated if:
- The article is being worked by KCS Contributor, KCS Publisher, or Coach, they have confidence that the article resolved their issue, and it complies to the content standard.
- It is important to note that WIP articles should exist only while the issue is being worked on, or when the associated incident is open. When the incident is closed, the WIP should either be deleted because an existing article was found that resolved the issue, or the article should be updated with the resolution and moved to Not Validated or Validated based on the KCS license level and confidence in the resolution. If the problem is not resolved and the incident is closed, as a general rule, the WIP should be deleted or set to Archive. An exception to consider in dealing with unresolved issues and WIP articles is the situation where there is valuable, reusable information that has been captured in the WIP. For example, this can occur if a diagnostic process was documented in the article. In this case, set the article into the appropriate confidence setting based on license level and confidence in the content in the article.
Not Validated, Validated
- Not Validated becomes Validated if the article is being worked/reused by a KCS Contributor, KCS Publisher, or Coach, they have confidence and validation from the requestor that the article resolved their issue, and the article complies to the content standard.
- Any article can become Archived when the objective is to remove the article from the searchable knowledge base without physically deleting it.
- An archived article can be restored to any other confidence setting should it be discovered the article was prematurely archived.
All of the above approaches align with the fundamental KCS Principle of a demand-driven process. Demand drives our attention to the articles that have value. Do not review articles for the sake of review, as they may never be reused. If we are reviewing articles in absence of demand, we are not doing KCS. The only exceptions to this rule are when a Coach and a KCS Candidate are working together, or when the KDEs do Evolve Loop assessments of clusters, patterns, trends, and the new vs. known analysis.
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 - 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 (Phases 2 and 3), 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 (Phase 4), we use the 90/90 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 externally immediately or within 90 minutes. This will increase use of and success with self-service.
In Phase 4 of KCS adoption, 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 Phase 4 - Maximizing, 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 (Phases 2 and 3), 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 on the KCS Academy website 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. 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.
Options for Transition
Again: to fully capitalize on what we know internally, we must make a high percentage of that available externally, and quickly. In some environments, while we are learning to do KCS, demand or reuse is a reasonable way to know what should be published. However, making articles externally visible based on reuse should be temporary, replaced by the just-in-time publishing model of a mature KCS environment. If you must do it:
- In some organizations, a Validated article becomes External automatically when the reuse count is hit. The philosophy here is the article has been used and therefore reviewed a couple of times, so it is sufficient to be External.
- The "conveyor belt model." Some members have had success with a conveyor belt model of automatically making articles External. Once an article has been reused three times internally, a timer starts for that article and it will be External in five days. People in the organization can opt-in to review the article or pull the article off the conveyor belt by changing the state or audience at any point during the five-day period. The article will be External when the timer expires, whether or not it is Validated.
Remember that patterns of reuse external to the organization are different than patterns of reuse internally. Requestors will persue resolutions for many issues through a self-service mechanism for which they would never open an incident. This is why the "make External after reuse" model should be a short-term practice on the KCS journey.
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 - 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.
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 in Phases 2 and 3 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.
The Time Value of a KCS Article
KCS proposes that knowledge base content is different and should be managed differently from other types of technical content, such as documentation, white papers, or manuals. Knowledge is dynamic and needs to be created, managed, and delivered for just-in-time accuracy and freshness. One justification for this is that the value of support knowledge begins to diminish 30 days after the issue is first discovered. Unfortunately, many non-KCS organizations take 60-90 days or more to document and release new articles. This is an expensive proposition that misses a major portion of the content's window of opportunity.