Is ITIL KEDB so important or should we always look broader?

A discussion on LinkedIn prompted me to comment that KEDB is a subset of knowledge management for service desk. I think it is important to take a broader view and provide access to more general information about solutions to incidents and resolutions to requests, not just workarounds to known errors. I've seen folk micro-design that one bit without considering a more generally useful system. I never quite understood why ITIL seems fixated on KEDB, giving it a disproportionate amount of attention vis-a-vis the more general support knowledgebase. Thoughts?


KE are the controllable part of knowledge management

Hi Skep! In my opinion the knowledge management has one great big issue: it is almost impossible to manage and to do right for a large company (I expected you to treat knowledge management like a CMDB, with great skepticism).

So what you should do is let integrated knowledge management be a vision and work an manageable chunks of coherent knowledge. One of them is the cluster of "known errors - workarounds and solutions" (btw. why would someone need a solution without an error? There are enough vendors of solutions in search of an issue!). This knowledge is easily managed, since it has a direct link to problem management. There is even a process to remove unneeded knowledge (implementing a solution removes the problem & removes the workaround). Perfect to generate high-quality knowledge.

Another part is service fulfilment. There you need knowledge to build standard service requests, which is usually modelled in a kind of workflow. That type knowledge is not exactly incompatible with KE knowledge, but is managed in completly different way. Service design should be in charge of these. Yes a good (integrated) knowledge management can manage such differences, but the usual mess I see is incabable of process / workflow logic.

So please skep, do not keep people away from the fruitfull path of the known error to lead them into the jungle of pure knowledge management ;-) .

Marc -

little islands

I disagree that request fulfilment solutions differ markedly from incident solutions - they should all be managed by the same process from the same repository. Error Control is just one more feeder/updater.

I am even more skeptical of SKMS as the uber-repository of all knowledge than I am of CMDB/CMS.
Here's how I depicted SKMS (or rather BKMS: Bottomless Knowledge Management System) in my satirical book Introduction to Real ITSM


The central foundation of all Real ITSM spending and staff utilisation is the Bottomless Knowledge Management System, or BKMS. This system stores not only the IT objects that IT happens to have a record of, but also:
• Parking lot utilisation statistics
• User health records and personal files (useful for troublesome users)
• Real-time sports results (for obvious reasons)
• Growth rates and mortality of office plants
• Transactional data from decommissioned systems, just in case
• Cubicle dimensional data
• Supplier satisfaction surveys
• The Guinness Book of Records
…and in fact all data that can be found regardless of its relevance to services.

I'm not skeptical of the activity (DEFINITELY not a process) of knowledge management any more than I am of configuration management. Let's not equate the activity with the geek super-tool.

There are hundreds of solutions without an error. For there to be a KE is the exception not the rule. It broke, we fixed it = solution without ever passing through KE.

KM doesn't have to be a jungle if approached sensibly, i.e. not as a SKMS - I entirely agree it should be done in chunks - I just think KE is too small a chunk. The greater danger is little islands of solution knowledge. I'm enough of a fan of KCS to want service desk operatives to have one source of all resolution/solution/KE knowledge

Size does matter

In small to medium size environments this may be OK. Then you would have a single source containing this knowledge. In larger organisations you tend to have the request fulfillment within workflow environments, where fulfilling the service request X is done by selecting workflow X and it triggers the 5 different departments required to do X. In this case the knowledge is in the flow (who does what type of knowledge).

Additionally I tend to be more carefull with service requests due to my history in outsourced services. There the service provider will only provide the predefined requests and will charge for all others, so just documenting a new way of fulfilling a service request in your knowledge db (what is KCS btw, wikipedia lists it as Kansas City Southern Railway) should not establish a new type of service request...

So maybe we both can be right, the chunk has to be the right size of the organization you are working with. Hey, we again found a good reason for people to use their brains ;-)

Knowledge Centred Support

yes I'm a train nut, in fact a fan of American railroading - some jaded observers will say there had to be one thing I like about the USA but that would be exaggeration :) Just like ITIL, the fact that I am a vocal critic does not mean I am against the thing.

But in this case KCS is Knowledge Centred Support, a useful tool for improving support. It has developed a bit of a following here and the ideas seem good ones.

BTW, SP doesn't mean Service Provider, it means Southern Pacific Railroad: big, dirty, rough, dogged, inventive, gritty, sprawling, hardnosed, opportunist, tough and effective - my kinda business.

KFC ehm KCS - Thanks

So combining your two passions would be to deliver better knowledge support to the chinese track layers for back in the old days (just gotta invent a time machine, should be no problem).

Interesting to see that HP is into KCS, I have worked for them & with them and never knew...

Thanks for pointing me to the interesting direction.

** UPDATE **

Just went through the intro presentation on KCS and I can only find things about sollutions & problems. To me this seems to be a way of doing problem management with probably improved knowledge capturing. Where does the service request type of knowledge come in?

problem is not a problem

Read problem = question. A customer asks a question which might be a real problem or a service request or just a request for information. Support searches for a solution which matches the question. If there is no solution, you need to create one.


first searching before diagnosing

yes the knowledge is produced by problem mangement but it results in better incident management. To me it is the end result of a discipline for Level 1 of first searching before diagnosing that is the good bit, that and the principle that reuse drives review.

The subject was new to the authors

It seems that the concepts of Knowledge Management were new to the authors of V3. Many practitioners are far ahead in this field. The KCS model, see is pretty good. KE's are just a small part of support knowledge. The point is to have knowledge tools which helps support to be able to answer all the questions customers ask.


The difference between a

The difference between a KEDB and a knowledgebase of tips and incident resolutions is that items on a KEDB are issues that could be fixed but won't be for the foreseeable future. The reasons vary but essentially boil down to money and the willingness of the business to fund the improvement or solution. In other words these are service risks that the business accept and own but IT manage. Thus it's worth being able to recognise these and report on them if required.
Of course the typical ITIL mistake that many seem to make is see the words database and think that they need a new separate product or tool. A pragmatic solution could be to have your Knowledgebase and tag the known errors and include the information you need to manage them if that sounds like it might work for you. If you design it well you just have one tool but have 'followed' ITIL's guidance on all those points.

mean time to fulfilment

yes understand the distinction. And agree with aroos that KEDB needs special Error Control sub-process to maintain the Known Error data.

Disagree with telepilot that a solution knowledgebase might confuse the issue. KE is a specialised form of solution. The overall solution db should be designed and developed. Start with KEDB if you wish but do it in the context of broader benefits. in fact I think there are much easier places to start. Standard resolution scripts for simple incidents and requests are much easier to set up and maintain, will quickly contribute to more first call resolutions and/or reduced mean time to fulfilment*, and will lay the groundwork for the more complex KEDB and Error Control later.

* my own more generalised term for both MTRS for incidents and result delivered for other requests. yet another example of why ITIL should have treated incidents as one subclass of more generalised requests - MTRS is too specific a term

KEDB is so easy to set up in

KEDB is so easy to set up in any SM tool.
Set 2 flags / fields
1) Workaround Exists Yes - No
2) Root Cause Known - Yes No
If both = yes then set Known Error field = Yes
Create a view in the tool to filter on Known Error = yes and status not = Closed (and other status to be omitted)

How much did that cost? And it is integrated into the SM tool. Be sure to have detailed how known errors actually get to a resolved / closed state.
You can also find the problems where workarounds exist by filtering on fields 1 & 2.

I agree that standard resolution scripts for simple incidents and requests are generally much easier to set up and maintain and are more useful.

Knowledge Management is much more than this and is much broader than ITIL. Indeed in many organisations the need comes from needing business knowledge and these powerful KM systems can dwarf what IT uses for KM.

The hard part is setting it up in the people

You're winding me up, right? "so easy to set up in any SM tool." ANY process is easy to set up in a tool. The hard part is setting it up in the people. You read me often enough Mark to know glib tool-talk like that is a red rag to me :)

Skep, Maybe I should have


Maybe I should have stated "... In my experience ..." and mentioned that I have done this in numerous SM tools of all shapes and sizes. The key behavior to change is to get the 2 fields checked and once done the Known Error is automatically set and a view presents the list of KE's etc. But there are ways to do that.

It works and with very little overhead. Granted that this is a very basic way to achieve a KEDB but has been tried & tested (by me and in one case an ISO auditor).

It is not a tool centric solution per se, but just helping organisations use what they have to achieve something that should be really quite simple.

Have I managed to put away the red rag?

much more to this

So the error is always updated when the final solution is found. And level 1 staff always look for KEs before wasting time trying to diagnose. And they all know how to search KEs. And new staff orientation includes familiarisation with KEDB. And the quality of the description and keywords is such that it gets easily found. And that quality is there because there is peer review of the decription and keywords, and staff who find mistakes report them and get them corrected. And the KEDB is inlcluded in audits and reporting and trend analysis. And staff get rewarded for the quality and amount of their contributions to the KEDB. And people care about the quality of the KEDB because they see the value. And several years after implementing the flags it still works and staff have faith in it and continue to use it... There is so much more to this than a couple of flags

Still waving the red flag I guess

What I am saying is that the 'foundation of KEDB' can be easy to put in place i.e. the KEDB. Some basic design, tool update and automation can do it -Basic details on managing the KEDB can be created and ownership of the KEDB should be assigned.

Yes, I agree "there is so much more to this than a couple of flags" - but would you not agree that sometimes a simple approach / platform is needed in order to build on and be able to address that which you mention? I am talking about organisation that neither have the money, understanding, buy-in etc. in order to do a full KEDB or anywhere close - so best approach is to start small, instill the idea, benefits and value of the KEDB and over time address the points you have made.

In one organisation all the points you made were addressed in practice - but it was all based on the simple flags built into the existing SM system that had reporting capabilities and was part of an over all CSI programme with KEDB ownership assigned and quality checks in place etc.

lying derelict

I've too often seen unused flags and codes and fields and forms and instructions and procedure manuals lying derelict years or even months after implementation... Installing something doesn't change the people using it. Successful technology/artifacts/CIs/things are like the tip of the iceberg - vastly more investment went into procedure change and culture change than went in to installing the visible object.

Me too. All I am saying is

Me too. All I am saying is that there is an easy, quick and cheap way to provide a basic KEDB. That's it.

Therefore any investment or resources put by for KEDB can be used for the other areas such as people, culture and change in regards to the KEDB.

Installing something doesn't change the people using it - Fully agree. Does KEDB need more that just the technology solution - yes it does, a lot more.

That is Error Control

That is the V2 Error Control sub-process. It is useful and I cannot understand why they had to leave it out. A sub-process is more than a database.

In V3 KEDB is a a part of SKMS. The problem is that Know Error management needs to be controlled but Knowledge Managament has to be more flexible. New knowledge is created all the time. Useless knowledge will be forgotten.

Knowledge bases

Many thanks for that.serviceinnovation-link, looks like good stuff I havent seen before. Regarding KEDB as a subset of "true" knowledge-bases, my take is that having a holistic view on KM in the operational parts of ITIL would do the framework a disservice, as it is often too difficult to easily explain the value on an operational level (this is how it will work, this is the value we derive etc.) and it would confuse a fairly operational portion of the ITIL textbooks. In the consulting I've done, the KEDB actually often ends up being the seed for a more broader KM approach. Without that experience of seeing something actually work you will often meet too much change resistance if you ask people to start documenting everything, for potential benefits further down the line

Syndicate content