Saturday, May 29, 2010

Tools and Processes

It is nothing new to state that the business process needs to be nailed down before the tool is selected. Let’s be honest, you could implement ITIL on paper if you were so inclined. I wouldn’t recommend this. In our case a certain amount of gravity existed around a particular piece of software so we are doing things a bit backwards. Luckily for us the tool is extremely capable and we are confident that the ship is pointed in the general direction of success.

We are, what I would consider to be, a medium sized organization. We manage approximately 800 desktop PCs and a wide variety of clinical and business services. The resources simply do not exist to implement ITIL in its entirety and thus the focus on an ITIL-Lite type approach.

Incident is the big one – everyone is going to implement Incident. Hell, everyone probably already does Incident in one form or another but they want to implement Incident better. Incident. I just like writing it.

Read through the yellow book and Change is top of mind. Most IT shops in the small-medium space that I have observed do an absolutely horrific job of change management. Lack of change management tends to equate to excess unplanned downtimes and rabid finger pointing. Right now we tend to fan our revolvers in the general direction of improvement but the discipline just isn’t there.

I think from here there is a confusing roundabout and everyone takes a different road. Do we separate Service Requests from Incidents? Do we implement Problem Management? Do we tackle Configuration Management and the CMDB? Create a user facing Service Catalog? Over here we settled on Incident, Service Request, Problem, and Change. A light enough version of a Service Catalog is defined to wrap Services into our record definitions.

Incident: We know we can do this better.

Service Request: Kind of. We want the reporting visibility but will still handle this within our Incident process.

Problem: We are done lying to ourselves by stating, “We’ll go back and fix it up later.” Guilt sucks.

Change: We might be in Montana but showing up at the saloon with our six shooters is no longer acceptable.

Configuration Management was just too much too soon. We are already taking an enormous bite and at this point I am just not seeing an operational or financial payback of doing a full CMDB. If we go down this road later we’ll likely start with servers and network gear and leave desktops and mice out of the picture.

Why does this matter? The decisions you make now are going to dictate how you define categories and address the concept of Services. They are going to dictate your initial reporting capabilities.

No comments: