Over the years, I have had the pleasure of working with clients to help them get started with the elusive goal of utilizing knowledge management within their ITSM processes. Why do I say elusive? I think one thing that is commonly forgotten is the knowledge data itself.
Yes, Techport Thirteen is highly skilled at application customization, and yes, we have experience as to which processes seem to work best in different types of organizations. But, we can't write your knowledge records for you.
Most ITSM products offer some kind of knowledge base creation utility... where flagged incident tickets can be scraped for data elements, like title, description, and resolution. These elements can then be mapped to your knowledge management tables. Index these newly populated tables, add in a search function, and you too can be rolling with KM in an instant.
Hold up. What I have described is just what the software sales teams will tell you. Let's get real.
Chances are good that your incident tickets are not written consistently. For example... I bet that in the past, your firm has had an email problem or two. When the related incident tickets were created over time, they probably had the following Brief Descriptions... "Email down", "User is reporting unable to use email", "Can't send emails", "Email", "E-mail", "eMail", "Bob said that his email is not working even though it is working ok for Joe". When it comes time to pick an incident ticket for your new knowledge base, as a respresentative of common email troubles, which ticket do you choose, so that it shows properly in your future KM search results? And is the related resolution clear and concise, or is it as different as the Brief Descriptions are per incident in the examples above?
My head is beginning to hurt. Building a valuable knowledge base is harder than most think.
The most successful Knowledge Management deployment project I've ever been a part of, was one that had three key questions already answered, before we even started discussing how the ITSM tool would be customized:
- What type of issues are we going to include in the knowledge base? - It is always best to start small with a narrow scope, see how it goes, and then expand in the future. The concept of mass incident-data importing is too much too soon. Think about starting with desktop and mobile device issues first, and maybe move on to specific applications after that.
- Who is going to be responsible as the subject matter expert (SME) for the types of issues we are going to include in the knowledge base? - This is the most important question to be resolved in my opinion. If you are going to train your service desk reps to use the knowledge base for say, desktop issues, than the related knowledge articles for desktop incidents need to be accurate, clear and concise. Only a SME responsible for desktop-related issues can decide what is best. This person therfore needs to be recruited up front, having bought in to the project concept completely, trained, and already working on their knowledge articles. Over time, this SME will maintain their knowledge data as technologies and solutions change. Want to be successful with your Knowledge Management project? Recruit and retain good subject matter experts.
- In what format will the knowledge be captured? - I am not talking about about text verses HTML. I am talking about clearly stating the issue with the correct keywords for search indexing, and then clearing stating the resolution, and possibly listing steps or screen captures that a service desk rep can easily follow. A knowledge base is only as good as its data... we all know that, but if that data is hard to read or search, or hard to use in general, then the best data in the world becomes a nuissance.
If you have these three questions answered, you will know the issues you are going to cover, who is going to write and maintain the related knowledge base, and how that person is going to format their knowledge articles. Once you have some data ready, you can start to train your service desk reps.
Keep in mind that we haven't gotten to the knowledge management application yet. You can start writing knowledge articles in a document writer, like MS Word or Google Docs, way before your tool discussions begin. The sooner the better actually.
The rest is just building the knowledgement management module within your ITSM application to enforce how these tasks are going to consitently happen over time. For a skilled, software partner like Techport Thirteen, this is the easy part. The knowledge engineering work up front is the challenge.
But, let's say you are a small organization with a relatively small service desk interaction volume. You probably only have a few service desk reps working at any one point in time. If so, then recruiting and retaing SME's is going to be tough. You probably wear enough hats as it is already, and adding "Knowledge Management Coordinator" to your role is going to be tough to include. If only there was a way to outsource the task of writing knowledge articles to get your organization started in knowledge management. I was very pleased to learn that Techport Thirteen partner, KnowledgeBroker (KBI), can perform this task for you.
Per the KBI website, "In addition to prepackaged support, KnowledgeBroker writes and reformats support content for individual companies on an outsourced basis. We then export the content for easy import and publishing in your Help Desk System. Advantages to the KBI approach include instant KnowledgeBase development, very cost effective solutions, a process for developing support content, and a standardized template to accelerate and validate follow-on development in-house." Very nice.
If your head hurts too when thinking of starting down the path of building your knowledge base, it is always good to know that you have an option for assistance. Getting started is hard, and sometimes an experienced friend can be of great assistance to get things rolling.
Learn more about KnowledgeBroker, Inc. and how their products can compliment your ITSM tool by downloading Techport Thirteen's KBI brochure:
Have additional questions about knowledge management or about KnowledgeBroker's solutions? We are here to help.