Finding Low Hanging Value within the ITIL Framework

I have written a few posts on our ‘ITIL Lite’ implementation, or more accurately, ‘ITSM Lite’.  We have looked at the ITIL framework and broken out the pieces that provide immediate value while avoiding creating something so ‘big’ that it is unwieldy for a medium sized organization.  Here are some thoughts on minimal implementations. 

INCIDENT MANAGEMENT

This one is fairly obvious.  Open items need to be captured somewhere for resolution.  The value is clear – if we don’t capture this information somewhere items fall through the cracks, fingers are pointed, etc. 

SERVICE REQUEST MANAGEMENT

Similar to above, however, I feel that Service Requests are an extension and expression of the value IT brings to the organization.  I would much rather say we had 1,125 Incidents and 1,500 Service Requests last month than say we had 2,625 IT issues.  Issues are often perceived as 'things are always broke'.  I have written previously in regard to how you might split Incidents and Service Requests using a single multi-tiered Category field.  This is valuable if you are using a lightweight tool or simply do not want to add complexity by introducing 'one more field'.  Multiple related Incidents become Problems; multiple related Service Requests identify areas for process improvement and/or automation.  Volumes provide a metric to measure cost of existing mechanisms vs. cost of improvement.  Easy examples - How many password resets per month justify the cost of a self-service product?  How many requests for Application X justify virtualized packaging and automated provisioning? 

PROBLEM

To me the immediate value in Problem is an attempt to eliminate an age old challenge – the “I will just do this for now and come back and fix it later” mentality.  Great – you have successfully resolved an Incident, however, you have identified a Problem and made a mental note.  Capturing this Problem provides for future accountability and identification to other staff members.  Value proposition #2 is that any known workarounds are documented and accessible by others with no need to receive the information by word of mouth alone.  This populates your Knowledge system - next.

 KNOWLEDGE

Knowledge is Power.  Doh.  This is a no brainer.  A good tool that makes standard documents, Incident History, and Problem History searchable is indispensable.  

CHANGE MANAGEMENT

I don’t have metrics on this one but I can tell you that without a doubt the following three things have occurred:

Our downtimes have been reduced dramatically.

Our collaboration and communication have increased.  Folks are in the loop and know what to expect.

Finger pointing is reduced and staff accountability is at an all-time high.

CONFIGURATION MANAGEMENT

Or as many have pointed out - Asset Management.  Pick your spots.  In most cases my thoughts are Servers/Network Infrastructure ONLY.  The clear Change history is extremely valuable and can instantly be referenced in the event of a downtime.  An Inventory/Management TOOL is nice for desktops, however, tracking CMDB type Changes on these devices simply cannot be justified in a smaller environment.

Enjoy.  I welcome any comments.