A few weeks ago I blogged over at The ITSM Review on 7 Benefits of Using a Known Error Database (KEDB).
I was wondering — do you have a Known Error Database? And are you getting the maximum value out of it?
The concept of a KEDB is interesting to me because it is easy to see how it benefits end users. Also because it is dynamic and constantly updated.
Most of all because it makes the job of the Servicedesk easier.
It is true to say that an effective KEDB can both increase the quality and decrease the time for Incident resolution.
I thought it would be fun to follow up with some ideas for an implementation of a Known Error Database within ServiceNow. Our default configuration* has a basic model for Known Error but you can make a lot of improvements in your installation.
*We have a swear box in the Application Development team for people that say "Out of the box" - we're a cloud company, right?
I wasn't going to release an update set for the features shown here but feel free to get in touch if you have any questions. This is fairly easy stuff and can be integrated into your instance with minimum effort.
Storing the Known Error and Workaround data
As I said in my ITSM Review blog post, the KEDB is talked about as if it were a separate tangible component, distinct from the Problem database.
This isn't an entirely incorrect way of thinking; people that are mainly involved in the Incident Management process interact with Known Errors in their search for a Workaround.. they might not interact with the full Problem record.
BUT - Lets not overcomplicate things by creating a separate table for the KEDB. Fundamentally the Known Error lifecycle - from its publishing to it's retirement - follows that of the Problem.
We are going to create new attributes on the Problem record to store our Known Error and Workaround and a few more besides.
Start by personalising your Problem form layout and adding a new Form Section titled Workaround
The Known Error and Workaround fields are HTML.
The Workaround available and Candidate for KEDB fields are True/False
The Known error KB field is a reference to the kb_knowledge table.
This leaves our Problem form looking like this:
Q. Why is the form section called Workaround and not Known Error. My problem might not have a Workaround
A. This is absolutely true - A Problem might be causing multiple incidents but not have a possible Workaround. Loss of power in a remote office is my best example of a Problem that cannot be easily "worked-around".
There is a lot of value in publishing a Known Error before we even start working on the Workaround. Having the Known Error out there allows Incident Owners to start associating Incidents to this Problem.
It also helps to start gauging the relative priority of your new Problems. One that has 10 incidents associated against it (and rising!) needs a Workaround more than a Problem that has 1 incident.
You should watch "Practical Problem Management" by Stuart Rance on the subject of "leading with the Workaround style of Problem Management"
So we might have a Problem record with the Known Error field completed and the Workaround empty.
There is also value in publishing a Known Error record with a Workaround that reads There is no known Workaround for this Problem
How is this helpful? Well - if we have researched the Known Error, found the cause and there really is no good Workaround this is valuable information. It stops someone on another shift spending time re-working the same issue.
You might also have some dangerous workarounds that you don't want Incident Owners to use. Stating that there is no Workaround is sometimes a good thing to do.
So - why is the form section called Workaround? Simply because that is the focus of the KEDB and when we look at the form we want Problem Owners to be thinking about the Workaround and how to publish into the KEDB.
Now that we have a data model to store our Known Errors and Workarounds we can start to enter data.
You might already have customised your Problem form to add things like Steps to reproduce or Confirmation steps. The Known Error field doesn't replace these at all. This is the place to describe the problem from the customers point of view.
Here you can describe error messages, conditions, the classes of user that might be affected and so on.
The Workaround field is HTML so you can add screenshots and format the content to be readable.
Lets pretend for the moment that we want to publish the Known Error as soon as possible to allow Incident Owners to correlate Incidents against the Problem.
Publishing the Known Error
The Known Error Database is essentially information stored as new fields in our Problem table. What we are going to do now is take this data and generate a Knowledge Article from it.
Publishing Known Errors into your Knowledge Base has a couple of benefits:
- It's a logical place to keep it!
- You can take advantage of text search
- It appears alongside other types of Knowledge like HOWTO documents
- You can use comments and ratings
- You can search Knowledge from the Incident form
We are going to take the Known Error and Workaround field and build a KB article which will be published into the Knowledge Base.
You need a new UI action for this on the Problem table named Publish Known Error KB
The code looks like this:
createKnowledge();
function createKnowledge() {
var new_kb = new GlideRecord('kb_knowledge');
new_kb.topic = 'Known Error Database';
new_kb.workflow_state = 'published';
new_kb.article_type = 'text';
new_kb.short_description = current.number + ": "+ current.short_description;
new_kb.text = "<h2>Known Error:</h2>" + current.u_known_error +"<h2>Workaround:</h2>"+ current.u_workaround
+ "<BR><h2>Problem:</h2><b>Number: </b><a href='problem.do?sys_id="+current.sys_id+"'>"+current.number+"</a><BR><b>Opened at: </b>"+current.opened_at+"<BR><b>Opened by: </b>"+current.opened_by.name;
new_kb.insert();
current.u_known_error_kb = new_kb.sys_id;
current.update();
action.setRedirectURL(current);
gs.addInfoMessage('Knowledge article created: ' + "<a href='kb_view.do?sys_kb_id="+new_kb.sys_id+"'>"+new_kb.number+"</a>");
}
(Kudos to Vincent Hoang from our AppDev team who wrote this for our implementation)
We added a condition to the UI action to avoid showing the button on an already published Known Error/Problem.
current.u_known_error_kb == '' || current.u_known_error_kb == null
Once the Known Error is written lets publish it to the KEDB.
And lets check out the resulting Knowledge Article....
There's nothing to do to enable Incident Owners to find this Known Error record when dealing with new Incidents. Next to the Short Description field on all tasks you can see the Search Knowledge field.
Getting the word out there - Notifications and LiveFeed
Now that we have a Known Error we want to let people know. There are lots of people that would benefit from this information - end users that might be interested in the Workaround, Technical experts that recognise the problems and could help provide a Workaround.
You can use the boring old email notification system to let people know. Or you could integrate your Known Error Database into Live Feed to start a social conversation about new errors and possible fixes
(Apologies for the redacted screenshot)
Republishing the Known Error when the Problem changes
You want your Known Error record to stay up-to-date. So when the Workaround is written or the Known Error is refined users are searching for the best information.
For this you want a Business Rule on the Problem table that runs on update and rewrites the body of the Known Error KB article.
Additionally - you don't really want people to locally update that Knowledge Article (otherwise you'll be overwriting their changes) so add an ACL based on the Knowledge Article category to set the record to read-only (or a data policy if you prefer).
We also added an informational message for people trying to alter the generated Knowledge article
Publishing the Workaround
Now that we update the KB article every time the Problem is updated publishing the Workaround to users is as simple as completing the field on the Problem form and hitting save.
Because we might want to publish There is no Known Workaround for this Problem there is a checkbox labelled Workaround available which allows us to track those published articles that don't have a valid Workaround.
Measuring performance on your KEDB process
We know that publishing Known Errors quickly is important to correlate Incidents. And that publishing Workarounds improves the Incident Management quality and response time.
Now that we have a data model on our Problem table to track Known Errors creating some SLAs is easy.
You can create SLAs to enforce that:
- A Known Error record for P1 Problems is published within 4 hours
- A workaround for P2 Problems is made available in 2 days
... and so on.
Finishing off
Two last considerations - When the Problem is closed the Known Error is no longer relevant as you have removed the root cause from your system.
You could either delete the Known Error KB article with a business rule that test the Problem state. But it is kinder to just retire the article and that way you don't lose the Knowledge ratings and comments.
Also - you might not need to create Known Error records for every single Problem. We created a Candidate for KEDB field to track Problems that we don't have Known Errors published for (yet). Those that want to could drive a task creation from this field to get someone to create the Known Error and publish it.
In Summary
ServiceNow has all the right components to build a pretty impressive Known Error Database - what are you waiting for??
