Article states are a key part of the KCS methodology. They help us manage visibility of articles so the right people are seeing the right things. The state of an article tells us something about our collective experience with that article, as well as indicating a level of confidence in the article's structure and content. The state used in conjunction with the KCS roles defines the visibility or licensing model.
To manage the readiness of KCS articles we use states to indicate where they are in the life cycle. 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 states in many different ways.
The article states are:
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.
WIPs are temporary. Generally they should become Draft, Approved, or Published, or they should be deleted. If the issue is never resolved and the incident is closed because it was abandoned by the customer, the Support Analyst needs to decide if anything of value has been captured in the article. If the issue is no longer being worked and there is nothing of value in the article, then it should be deleted.
The WIP state helps Support Analysts manage pending work (as the name implies). WIPs give us an easy way to identify and manage incomplete articles in the KB.
DRAFT— 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 customer feedback, other Support Analyst's use of this KCS 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 (see information about the KCS licensing model in Practice 7, technique 1) but not yet reviewed by a KCS Coach.
The Draft state gives us a way to capture the collective experience of the organization and distinguish between those articles we have confidence in (Approved and/or Published) and those we don't (Draft)
Confidence - The Draft state supports the concept of "capture everything." If the issue is worth answering or solving for the customer, it is worth having in the KB. It also supports the concept of "sufficient to solve" (good enough). Support Analysts are often hesitant to capture all of their experiences supporting customers as articles in the KB if they are not confident in the resolution. The Draft state provides a way for Support Analysts to indicate, "here is what I did in this situation, but I have not been able to validate the accuracy."
Efficiency - Let reuse of the Draft articles be the review and drive the article life cycle. Reviewing all draft solutions creates overhead and expense that produces very little value.
The users of the KB who have visibility to Draft articles need to understand that Draft 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 Draft articles, which are then reviewed by a KCS Coach.
APPROVED—the KCS article is considered complete and reusable. We have confidence in the resolution and it complies with the content standard. The article has been created by a licensed KCS user (KCS Contributor, Publisher, KDE or Coach) or it has been reviewed by a Coach.
The Approved state gives users an indication of confidence (judgment is still required)
Early in the KCS adoption (Phases 2 and 3), Approved articles are candidates to become published based on reuse.
In a mature KCS environment (Phase 4), we should have lots of KCS Publishers and we should be making judgments on moving Draft or Approved articles to Published as we create or reuse articles. The judgment to publish an article is based on our confidence in the resolution and our assessment of the article's compliance with the content standard. In Phase 4, Leverage, most articles created would either be in Draft (low confidence) or Published. Approved articles would be those flagged for "internal use only" (not eligible for publication)
PUBLISHED—the KCS article is ready for use outside of the support organization, typically by customers or end-users.
Published articles are compliant with the content standard, written in the context of the audience they are visible to, and we have a high level of confidence in the resolution.
Early in the KCS adoption (Phase 2 and 3), articles become candidates to be Published 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 "publish only after internal reuse" phase and as a result sub-optimize the benefits of KCS. Patterns of reuse in customer self-service 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 "publish after reuse" model should be a temporary practice on the KCS journey.
In Phase 4 of the adoption we use the 90/90 goal: we should share most of what we know with customers as quickly as we can. 90% of the content in the KB should be available to customers in 90 minutes. This will increase customer use and success with self-service.
A KCS Publisher can modify the article while it is published. 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 or move it into Rework status for review by a KCS Publisher (who may also be a Coach or a Knowledge Domain Expert). Some 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.
Depending on the situation, there are a few additional states a KCS article may go through. Some are specific to the business such as compliance review for environments with regulatory requirements. These organizations will need to define article states that are unique to their environment. We do not cover this situation here.
Three common optional states that support the "flag it or fix it" practice are Technical Review, Compliance Review, and Rework. Companies find that making the distinction between these three states can be valuable because the audience that can handle the Rework state is much larger (KCS Publishers and Coaches) than the audience that is required to deal with Technical Review (subject matter experts), and Compliance Review. Making the distinction can help eliminate bottlenecks in the article life cycle.
TECHNICAL REVIEW— We have created a KCS article, or we are reusing an article and we are not confident in its accuracy or completeness. This most often relates to the resolution or cause sections, but it can apply to any part of the article. Technical Review is a way to flag an article for review by a subject matter expert or specialist.
The Technical Review state supports the "flag it or fix it" behavior
Anyone who needs technical help can put an article into the Technical Review state
Notes should be added to the article by the person putting the article in a Technical Review state to explain why they would like it reviewed
COMPLIANCE REVIEW— We have created a KCS article, or we are reusing an article and we are not concerned that the article contains sensitive data or may not satisfy business requirements to enable moving the article to the Published state. This most often relates to the resolution or cause sections, but it can apply to any part of the article. Compliance Review is a way to flag an article for review by a subject matter expert or specialist.
The Compliance Review state supports the "flag it or fix it" behavior
Anyone who suspects that an article does not comply with business requirements can put an article into the Compliance Review state.
Notes should be added to the article by the person putting the article in a Compliance Review state to explain why they would like it reviewed
REWORK— We are reusing a KCS article that does not comply with the KCS Content Standard and we do not have a license to put the article back into its current state. Rework is a way to request a review by a person authorized to fix the article, such as a KCS Contributor, KCS Publisher, or KCS Coach.
Rework should trigger the attention of a Coach or a KCS Publisher to review the article for structure and compliance to the content standard
While anyone can put an article in the Rework state, it is generally intended for use by those who are not licensed to modify an article in its current state. For example, a KCS Contributor cannot modify a Published article and put it back in a Published state. The KCS Contributor should make the needed change (reuse is review) and put it in a Rework state for review by a KCS Publisher or Coach, who after review would put the article back into a Published state.
Rework can also be used to manage the workflow between a KCS Coach and the KCS Candidates he or she is coaching. For example, if a Coach reviews a Draft article that a KCS Candidate created or modified, they could use Rework to comment on the structure of the article and have the KCS Candidate fix any standards compliance issues the Coach has noted. (Coaches should not be fixing their KCS Candidates' articles but rather providing feedback so the KCS Candidate can fix it)
The person putting the article in a Rework state should add notes to explain why they would like it reviewed.
The Technical Review, Compliance Review, and Rework states are considered optional. Not everything needs to go through a Review state. KCS articles should only go through the Technical Review state when there is a lack of confidence in the accuracy of the article; it is a judgment call on the part of the Support Analyst. KCS articles should be put into a Compliance Review state if the content contains questionable sensitive information or does not meet business requirements to enable the article to be published. Similarly, articles do not have to go through a Rework state. Rework is how we flag an article if there are questions about the article's compliance to the content standard, and we are not licensed put the article back into its current state. In general, articles should improve with use and a licensed, confident Support Analyst would make the necessary updates. This is one reason we want as many Analysts licensed at the Publisher level as possible.
The life cycle stateis part of the KCS article metadata. As an article evolves and is used, reviewed, and enhanced, its state is updated. The state of the article affects the trust users place in its accuracy. Article states are extremely important and frequently referenced by the users of the knowledge; therefore technology should make the article state easily visible to the users.
ARCHIVE—Archiving an article from the knowledge base is normally done only when the article is defined as having no value. Archive is better than deleting an article. When an article has been linked to an incident, 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 ticketing system. A common method to remove the article from a searchable knowledge base is to move it to the Archive state. 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.
An article can move through the various states 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 Support Analyst
Due to this dynamic, we may want to keep a copy of an article as it existed when we delivered it to a specific customer. 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 state transitions.
A WIP is created at or near the point in time the first search is done on the issue
A WIP becomes a Draft if:
The article is being created by a KCS Candidate (KCS I)
The article is created by a KCS Contributor or Publisher but confidence in the article is low
A WIP becomes Approved if:
The article is being worked by KCS Contributor and they have confidence in the resolution and it complies with the content standard
A WIP becomes Published if:
The article is being worked by a KCS Publisher or Coach and they have confidence in the solution and it complies with the content standard
It is important to note that WIP articles should exist only while the problem is being work on, or when the associated case is open. When the case 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 Draft, Approved, or Published state based on the Support Analyst's KCS license level and confidence in the resolution. If the case is closed and the problem is not resolved, as a general rule, the WIP should be deleted or moved to a Archive state when the case is closed. 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 the Support Analysts should put the Article into the appropriate state based on their license level and confidence in the content in the article.
Draft, Approved, Published
Draft becomes Approved if:
The article is being worked/reused by a KCS Contributor (KCS II) and they have confidence in the resolution
Draft becomes Published if:
The article is being worked/reused by a KCS Publisher or Coach, they have confidence in the resolution, and it complies with the content standard (this process is the norm when an organization is in Phase 4, Leverage, of their KCS adoption)
Draft becomes Published if:
The article is reused x times by any KCS licensed user. The number (x) of reuses varies by organization; three seems to be the norm. (This process is typical when an organization is in Phase 2 or 3 of the KCS adoption)
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 state should it be discovered the article was prematurely archived.
Variations on the theme
In some organizations the article is published automatically when the reuse count is hit. The philosophy here is the article has been used and therefore reviewed a couple of times (probably by different Support Analysts) and it is good enough to be published.
Some organizations trigger a review by a KCS Publisher or Coach when the reuse count is hit.
The "conveyor belt model." Some members have had success with a publishing model that uses the concept of a conveyor belt. Once an article has been reused x times internally, a timer starts for that article and it will be published in five days. Support Analysts in the organization can opt-in to review the article or pull the article off the conveyor belt by changing the status at any point during the five-day period. The article will be published when the timer expires, whether or not it is reviewed.
Rework, Technical Review, and Compliance Review
Draft, Approved or Published articles can be put into a Technical Review state by any KCS level if:
They don't understand the article
They don't believe the resolution is technically correct or complete and they are not certain about how to fix/improve it (technical accuracy)
They are confident in the improvement to the article but they are not licensed to create/modify articles in their current state
Draft, Approved or Published articles can be put into a Rework state.
This state is generally used by KCS Candidates or KCS Contributors to flag something they cannot fix and keep in its current state
It may also be used by a Coach to indicate that a KCS Candidate needs to fix something in their article
Draft, Approved or Published articles can be put into a Compliance Review state by any KCS level if:
They discover potentially sensitive data within the article
They believe the content does not satisfy business requirements that allow it to be shared directly with customers
They are confident in the improvement to the article but are they are not licensed to create/modify articles in their current state
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.
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 published outside to customers and partners. 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 website for examples of just-in-time publishing in action.)
The life cycle state of the KCS article, in combination with the license of the person who is searching, determines its visibility. All organizations have a small set of articles that should never be shared outside the company. These articles include things like bugs in security or issues that require deep or proprietary technical understanding. These articles are tagged with an attribute of "internal use only" that overrides the visibility implied by the KCS article state.
To manage article visibility, and thus appropriate levels of security for the knowledge, we recommend creating a Visibility Matrix. This reference document maps the audiences (internal, partners, customers) against the KCS article attributes that affect visibility (state, knowledge domain, special considerations) and defines access rights.
In the beginning of a KCS adoption, article reuse counts, or demand, help us identify the KCS articles that should be migrated closer to the customer by publishing them to a self-service mechanism. In Phases 3 and 4 of the KCS adoption, reuse counts have the added benefit of assuring a certain amount of review through reuse, increasing our confidence in the KCS articles' technical accuracy and structure.
As the KCS practices mature in the organization, a just-in-time publishing model should be adopted, so that a high percentage of the Support Analysts are licensed to publish 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 Support Analysts. Just-in-time publishing requires Support Analysts to make good judgments about technical accuracy. If they are confident in the article's accuracy and licensed they should publish. If they are not confident in the articles accuracy they should request a technical review. Judgment is required.
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. Draft articles that have never been reused, or that we don't have confidence in, should stay in a Draft state; Draft articles are ok. However, articles that are being reused or that we have confidence in must eventually make it to Published.
Many organizations do a great job in Phases 2 and 3, realize significant operational improvement, and then the system slowly dies. Support Analysts 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 customer self-service mechanism, or the rate at which articles are getting Published is not sufficient to support customer success with self-service. The primary motivation for the Support Analysts to create and maintain the knowledge is the promise of reducing redundant work by not solving the same problem over and over. If articles are not getting published, or there is no effective self-service model, the Support Analysts 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 life cycle states is critical for the sustainability of the KCS practices.
A tenet of KCS is 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.
HP and Dell both conducted studies that produced a rediscovery curve of this shape.