Content Health begins with the article structure. A well-defined, simple structure is a fundamental element of KCS. A consistent structure contributes to both findability and readability of articles. The goal of KCS is to capture the organization's collective experience, or knowledge, in the form of articles.
Articles capture what we have learned in responding to a request. The article content is the reusable part of the experience and should not include information that is specific to the requestor such as company names or contact information for people, entitlement, or specific locations. That information should be kept the system of record for interaction. For support organizations, this event specific information is kept in the case or incident management system.
KCS articles are more than just the question and the answer. The article connects the requestor's context with the responders experience and resolution and information that is valuable to the organization.
KCS is a modular approach to knowledge. Ideally, KCS articles are a page or less in length. A given situation may use multiple articles to get to the resolution. KCS articles often contain links to other other articles or more reference information that already exists in other databases.
The right structure ensures that KCS articles in the knowledge base are findable and usable by the intended audience. Identifying the intended audience is important because the audience defines the context for the KCS article. Ideally, the audience we are serving should be involved in creating and giving feedback on the articles. Unfortunately, not many organizations actually enable this.
One of the key goals of KCS is to capture the context of the issue: the description of the needs and perspective of the requestor, in their own terms. To achieve both broad reuse and relevance, the reusable context for a given situation is contained within the KCS article, in its own section.
We have found that a simple, single structure works best. And, this same structure can serve many different needs including:
These are the four basic, common elements or fields of a KCS article:
Metadata - The article also contains a collection of attributes that describe a variety of things about the article. Some of these attributes are added by the knowledge management system automatically, like dates, time stamps, versions, reuse counts ,and the identity of the knowledge worker(s) that created or have modified the article. Other attributes are explicitly set by the knowledge worker as the article is created and used. This includes the visibility, quality, and governance attributes.
Here again we must reiterate the "keep it simple" idea. Resist the temptation to over-engineer the the structure or the number of templates or the metadata fields. Make it as simple as possible and then try it. Evolve the structure, templates, and metadata based on the organization's experience. We have a tendency to want to make these things everything they could be in anticipation of the many ways we might use them. Don't do it! Use the principle of Demand Driven or, if you like, an Agile approach. Design it to be good enough to start and then plan to iterate on it: improve it based on experience.
Leaders should note that structuring KCS article content requires a change in behavior for the knowledge worker. There is a learning curve as the knowledge workers learn to capture and structure in their workflow. They have to learn to distinguish the event-specific content (the event itself) from the reusable content (what we learned from the event). Coaching is crucial at this stage as that is how we promote and create new habits. This represents an investment. However, as the Solve Loop practices become second nature and we capture our collective experience as articles in the knowledge base, reuse quickly increases and create activity decreases. The time invested in coaching to get "over the learning curve" will be more than compensated for by the time saved in the improved request-resolution process.
The resolution contains the answer to the question, a workaround, or a fix to the problem. If the resolution contains a multi-step procedure, it improves article readability if we number the steps.
Sometimes the resolution requires authorized access, special tools or skills that the user or audience may not have. If the audience for the article does not have the access or resources to complete the resolution, the resolution should provide instructions like "contact your support center for assistance in resolving this issue." The support center should have access to a restricted field in the article (which the user cannot see) that provides the steps to resolve the issue. It is a good idea to have an article that the user can find to indicate the issues known. Including guidance for obtaining service in the resolution field of the externally visible article can help the requestor contact the support center and provide relevant information to the responder to minimize diagnosis.
Adding an "Internal Resolution" field in the knowledge article provides a place to capture a resolution that requires assistance. The "Internal Resolution" field is not visible to requestors even on externally visible articles. This a technology requirement for your knowledge management tool. If we don't have that capability, we can create a separate article that is flagged as "internal use only" and linked to the externally visible article.
As we mentioned above, the Cause field is optional as not all issues have a cause (or the cause may not be known). For example, "how-to" articles never have a cause, unless you'd like to point out that the requestor didn't read the instructions or manual.
If the cause of an issue is known, it should be added to the knowledge article. This can be used to distinguish between two knowledge articles with the same issue description which are actually two different problems. For example an issue of "I can't print" may be due to the printer being out of paper, out of ink, paper jam, or a number of other potential causes, each requiring a different resolution. When searching the knowledge base and multiple articles are found with similar issues, the cause within each article can be used to verify which problem exists for this reported issue.
An additional strategy of value to consider is to add an additional field related to the Cause field, called "Cause Test." In the "Cause Test" field will be the procedure or description of how to validate the cause. The requestor or responder can then use this test to confirm that the issue they have matches the knowledge article and will then have confidence that the resolution will address the issue. For example, a cause of "out of paper" may include a cause test describing how to check the paper level in the printer.
Throughout this document, we have talked mostly about KCS articles presented as text. However, for certian audiences and for certain types of knowledge, multimedia proves to be far more effective than text. Many of the Consortium members are including pictures or screen shots, animation, voice and short videos as knowledge articles or as resolution to an article. Visual images can bridge language gaps and overcome translation issues. Voice and audio clips are also increasingly common, both for ease of comprehension and for compliance with increasing regulatory requirements for accessibility. As more organizations pursue self-service, multimedia formats can be very beneficial in speeding resolution and improving the user's experience. But again, it depends on your audience. The nature of the knowledge should dictate when and where multimedia makes sense.
The KCS methodology and processes remain the same, but the knowledge base and delivery tools may need to be adjusted to accommodate multimedia content.