Enable and Configure the ASM KB
It only takes about 5-10 minutes to enable and configure the KB in ASM, however some planning beforehand is important.
ASM Knowledge Base Architecture - Effective Planning
The ASM KB is linked throughout the system to calls/tickets CMDB Items and throughout the Self-service portal and the Core and Nano applications. The ASM KB follows the ITIL principles of Knowledge Management.
Planning your Knowledge Management program will take longer than setting it up. ASM makes configuration easy. It is wise to plan ahead how your KB will be configured as making changes later, depending on the change, could mean going in and touching every article to update it.
You will need to plan the following before you begin setting up your Knowledge Base:
Will it be available to the portal? In whole or in part?
Do I want to enable Knowledge Matching on the portal? In Core? and in NANO?
Who will be my editors?
Who will be my authors/contributors?
Do I want to set a default review period on all articles or can some exist in perpetuity?
What would I like my email templates to look like?
How will I measure? What are my Key Performance Indicators and statistics?
What is my taxonomy going to look like?
Who is the Audience(s)?
Will I want to integrate to any other external repositories? There are several ways:
Logic Apps
Web hooks
Import
API
DB Connector
Enable Knowledge Management
If Moderation is enabled, only Article Statuses (Draft, In Review, Published, etc...) that are marked as moderated will be visible on the Portal or in Core and NANO.
KB Types - What kinds of Articles Will the KB Hold?
Knowledge Articles should be created for the decision or actions to which they lead
Knowledge Centered Support (KCS) are based on experience – Provides historical perspective to recognize familiar patterns of old solutions and apply them to new situations and events
FAQ are based on truth – Knowing what works and what doesn’t work – the difference between the theoretical and the practical
Abstracts deal with complexity – The more you know the better your decision will be
Known Issues deal with transient and/or long-running problems – That may or may not have a workaround
Keywords and Text Retrieval - Getting the Right Content to the Right Users
Building a Taxonomy
A taxonomy is a "knowledge organization system." It is a set of words that have been organized into a "vocabulary" to facilitate the storing and retrieving of items from a repository.
Your taxonomy will do the following:
Classify
Characterize
Identify
Name
ASM maintains the taxonomy through Key Words you will assign to the articles themselves. For example:
A software company wishes to build a taxonomy of releases and capabilities to make searching for articles easier; They would create key words to attach to articles such as:
Release 4
Release 4.1
Release 5
Release 5.1
Release 5.1.2
Configuration
Reports
Administration
User Security
Standard Operating Procedures
Emergency Procedures
etc...
What Keywords would you assign to an article that is relevant to all releases and pertains to User Security?
Answer: The article would get the User Security keyword.
Why wouldn't we link all the releases?
Answer: Primarily, because of the maintenance overhead. We can assume if no releases are linked then the article applies to all of them. In this example, we would list specifically a release only if its relevance is an outlier, such as a Known Error that might only apply to Release 5.1.2.
Best Practice
Keep your taxonomy (keywords) relevant but concise. You should not need a list of 100 or more key words. The taxonomy at Alemba, for example, contains a list of all of our modules/capabilities and where relevant, a specific release number. Nothing more.
To Add Key Words - Build your Taxonomy
Knowledge Profiles - Define your Audience(s)
Most organizations have two audiences. Internal staff and Self Service Portal Users, or "Public" users. In reality you have many layers in each of these two main audiences, but essentially you will have internal-only knowledge and knowledge that is appropriate for all audiences.
ASM uses Knowledge Profiles to define the audience for articles. Once you have articles with a Profile assigned, you can grant access to the content by Profile in the Knowledge Base Security Role for Analyst's and in the Self Service Portal Role for your users.
Best Practice
Since you will control access to articles using Knowledge Profiles, it is best to keep this list short, and obvious to authors and contributors what each one is so that as they write articles they can select the appropriate audience. At Alemba, for example we only have two Knowledge Profiles: Public and Internal
Article Security - Content Access
Profiles and Content Access
Your KB is controlled with Role Based Access Security. You will define what article statuses are published to the Portal and in the Self Service Portal Security Role, you will further define the Profiles (audience) for the content. In this way you can control 1) if the article is even available to the portal, and 2) who on the portal can see it. For example, you may simply have 1 profile; Public. Or, you may have a Public profile meaning everyone can see it and you may have another profile "Public SuperUsers" where you reserve access for your more technically inclined users.
Use caution creating Knowledge Profiles. These profiles define the audience of the article and you should always work from the lowest common denominator approach. Usually you will see something like the following:
Internal
Public
Every security role in your system must have knowledge profiles granted and maintained. This can become onerous of you have created a taxonomy here. Many organizations lose control of their KB by implementing a complex set of Profiles.
Knowledge Matching
Knowledge matching looks dynamically at the content of the ticket based on filters, calculates a search score, and then suggests articles for the Analyst or User to try.
To calculate the Search Score of an article, ASM first calculates a raw score for each of the articles found. These raw scores are then compared and used to determine the final search score for the article that is seen in the Search Score field of the search results. This is how the scores are calculated:
The raw score is calculated by collecting the number of times a word used in a search appears in the article. The resulting value is then divided by the total number of words in the article.
The knowledge article with the highest raw score is then assigned a Search Score of 100%.
All subsequent knowledge articles are assigned a Search Score based on the percentage value of the raw score to the highest article's raw score.
Tips for getting your article seen and used - Key words used in the article. It is best to use the same words a customer or analyst would likely use when searching in order to float your article up on the list and make it relevant.
Knowledge Matching for Analysts
In ASM, you can setup matching Knowledge for Analysts by IPK Status. This means you do not have to have it on every kind of ticket. You may want, for example, to only have it on Incidents.
Select ≡ > Admin > System Administration.
The System Administration window appears.
In the Explorer pane, expand IPK Management.
Select IPK Statuses to open the window. The statuses are displayed, along with their details. You can adjust the column widths if required.
Select the status you want to enable matching knowledge.
Complete the details.
Knowledge matching in NANO
Use the Matching Knowledge panel and Matching Calls panel to see knowledge articles and calls similar to the current call that may contain solutions or valuable information. Calls and Knowledge Articles are matched on the Type, Service, and Configuration Item of the call being worked on by the analyst in Nano.
Self Service Portal Knowledge Matching - Suggested Knowledge
Suggested Knowledge promotes knowledge articles to users during call logging to achieve faster solutions for users and reduced workload for the Service Desk.
Turn on Suggested Knowledge in System Administration to display relevant knowledge articles to users while they complete call submission forms in the Self Service Portal. The list of displayed knowledge articles is based on the data entered into the submission form fields, with the most relevant articles at the top. Users can review suggested knowledge article details without leaving the submission form. If the article solves the issue they can acknowledge this by selecting Solved! Close my call. This action increments the Help Factor rating of the knowledge article, and automatically closes the call they were logging.
Knowledge Article Screens
Out of the box, ASMs knowledge Submission screens are preconfigured. However, more often than not, analysts are confused as to what information to put and where to put the information. This increases the workload for the Knowledge Management Team and since the whole point is to capture tacit knowledge and make it explicit - it is wise to make that as easy as possible for your authors.
You can add text to the screens to help the analysts understand what information should be entered and how.
Setup ChatBot with Knowledge
ASM Self Service has a virtual analyst/chatbot capability that allows customers to interact with the bot before deciding the next course of action. i.e. Did the bot resolve their issue or do they need to seek further advice from an analyst through a chat session or direct through a ticket form?
Any transcripts through the bot or through analyst chat sessions are fully written to incident records. In order to set up the Chat Bot Service, first you will need to connect to the Microsoft Azure Portal and then publish the Knowledge Base.
Knowledge Ratings
You can define and create knowledge entry ratings and scores. These scores are displayed on all knowledge entries, and Analysts or Users who read a knowledge entry can assign a score to it. However, you can set an option whereby only editors can see a particular rating. The score is attributed to the author/contributor of the entry.
Knowledge Status
Is the article viewable? You can define statuses that can be associated with knowledge entries, such as Draft or Reviewed. A status is set for a knowledge entry when it is created.
Knowledge Status controls the availability of the article whereas Knowledge Profiles control the access to articles.
Managing your Knowledge Base
For more information on how to manage the KB After it has been enable and configured, please see:
