For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
The Itil Community Forum: Forums
ITIL :: View topic - Metrics -Percentage accuracy of the KEDB
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Fri Feb 20, 2009 6:54 am Post subject:
Dchell
This one puzzles me.. Why should there be a KPI for a KEDB
The Known Error DB should be 100% accurate - as it should be based on errors identified in YOUR own environment. ( my take that is.)
While there is things like Technet for microsoft products, etc etc for oracle, linux, unix etc; their respective known error / knowledge DB should not be part of yours - unless the issue is found in your environment.
the way I view a Known error DB, is that for each service that is created, there is a KEDB - so to speak.
And as people use the service (the users) and they complain. (incidents) and these get solved (incident / problem / chaneg & release) or fixed ( (again), there will be some that cant be fixed or the cause gets known and it is just not worth fixing.. gets into the KEDB
Or certain activities / actions - have predictable outcomes / reasons
like compaq machines, keyboards, microsoft o/s etc etc etc, certain video / graphic cards and specfic systems etc
if you are asking what % of the problems / incidents get into / solved via the KEDB - it depends on your environment....
oh yes...being the twisted type I am... I dont have to post the stupid thing I did on your last post ... because
you obviously rtm and think it would be great to see it bounce off my head (grin)
Does this help at all or am I not getting what you mean _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Well I thought it was the % of the problems / incidents get into / solved via the KEDB and if they were accurately documented - which would be very subjective or we would have to create rules around what and how they should be posted.
I'm curious as to what ITIL authors were thinking when they suggested this - because they should include either a formula or how you would go about measuring something subjective.
Now mgmt feels that they want to measure the information that gets into the KEdb because they are afraid that if it's not useful information - then people won't use it . Cultural Change issue. So if this is what ITIL is really referring to then I would love to see how others are measuring this.
Joined: Oct 13, 2006 Posts: 116 Location: South Africa
Posted: Fri Feb 20, 2009 7:39 am Post subject:
I think the ITIL authors were thinking - we have to put in a good number of KPIs - let's brainstorm as many as we can. Yes, they should have made it more precise e.g. with a formula.
But at least it's enough to make people think.
An inaccuracy in a KEDB could be (a) a KE in the DB that's inaccurate or (b) a KE that should be in the DB but isn't.
(a) how could a KE be inaccurate? ... Maybe it's not a ROOT cause. But you won't find that out in an audit, only by exception if somebody finds it doesn't fix the symptom. Maybe the workaround doesn't work around. Again - you can't really audit that. Or maybe there was a spelling or formatting error, or the KE just lacks documentation - you can audit that, but I would call it quality not accuracy.
(b) could be measured by problems closed with no KE records.
It will probably be much more valuable to have a KPI on number of incidents closed at 1st/2nd line by reference to the KEDB.
Well the KEDB is 100% accurate... or it isn't. I don't see this data as subjective.
Verification (internal audit) activities can find inaccuracies in workarounds as they're being used. Oops, there's a step missing. Oops, this works for ABC app version 2.1 but not for 2.2. Oops, Security Management made us remove such-and-such utility.
Useful? I supposed it'd be good for the Problem Manager to know that of only 2% of the KEDB had to be changed/updated in this 6 month period and to consider process improvement when that number changes to 10%.
Number of incidents solved using which workarounds in the KEDB? Maybe just give them the old 80/20 rule. 80% of anything (the incidents) is fixed by 20% of something (the workarounds).
I personally doubt whether many organizations are at that level of maturity with their KEDB. What I mean by that is I suspect where organizations have adopted ITIL aligned Problem Management, they are just glad to have a KEDB without feeling the need to implement KPIs to measure it's effectiveness/efficiency.
In the tool we use there is a Knowledge Management module where knowledgebase articles are registered and presented, allows the analyst to register a "hit" against a knowledgebase document (or a Known Error if you prefer) so they a simple query lets the Problem Manager know how many times any particular document has been used to resolve an incident.
This is a basic way of measuring the effectiveness of individual docs and a bit more rumaging around gives you some idea of how much the KEDB is being used (or how effective it is with regard to incident resolution).
That's good enough for us at the moment and we are a major offshore private bank with thousands of end users.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum