How to improve your ITIL processes?

Measuring is knowing, but without real understanding no use.

I just read a good article which sums it all up: “Before you can improve a process, you have to understand the current process. You have to get out from behind the desk and walk the process …”

So we are not talking about only knowing but also about understanding. “… how a process currently works is often very different from how you think it is (or should be) working.”

I want to deliver you the following takeaways as important steps you should take before you start improving processes:

1. About processes, control and truths – The very first thing you have to do is accept that no one really knows what is going on and how people perform their work, neither workers nor managers. Regardless of what you think you know, the work really getting done, and how it gets done, is different.
2. Workflow: what is real and what imaginary? – The only way to actually discover what is really getting done is to get up from behind the desk, walk out of the office, and literally walk around, observe, and take notes. You cannot practice ITIL from behind a desk. This sounds simple, but as in many things, the doing is not so straightforward. To practice ITIL you have to walk the process, literally. Keep in mind that your goal is to collect and model the existing process as it works today; not what you imagine it ought to be, but rather the actual tasks and workflow in place.
3. Walk the walk – It takes time to learn the workflow with the right accuracy and detail.  You need to capture the “who, what, when and where” of the process, and should skip the “how and why” to start with.
4. Than model the workflow – Based on the new info you will probably be surprised about the actual work and time involved. Now you are ready to map your processes with ITIL standards and to my opinion other best practices and your own experiences.

Be aware of:

• It takes work, time and attention to detail
• Get up and leave your office!
• Accept that you don’t really know what is going on, but that you are heading for an exciting journey
• It’s sometimes difficult to observe unbiased
• During your analysis your goal is documentation, not improvement
• Improvement in: the time it takes to do things. You should capture how long it takes to perform the work before you can answer the question “should this be changed”. That’s an important measure (consider our start-up reports on actual duration)
• The value of an accurate process model cannot be underestimated. You cannot improve anything without understanding it first.

Read on

http://www.itsmsolutions.com/newsletters/DITYvol6iss32.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+DoITYourself+%28Do+IT+Yourself+%28DITY%29+Feed%29

Martijn

If you remember, the way it generally works is that the Process Guy is the alpha – he’s the one with a problem to solve that is related to process. Often the organization wants to get a handle on some real qualitative data about IT performance – either for budgetary reasons or for lofty ambitions like ITIL and continuous improvement. The Process Guy brings the Tech Guy in to establish a) that trying to get that data out of ServiceCenter or Service Manager is going to be like divorcing Cheryl Cole - painful, drawn-out and expensive, and b) that SMI Suite will remove all the pain, time and some of the money.

At some point in this sales cycle, the Budget Guy shows up, because despite the very low cost of SMI Suite, neither the Process Guy or Tech Guy has any spending power – it simply isn’t a function of their role to sign off on more than a few bucks worth of software.

In some ways the Budget Guy is interesting because he’s the first person we’ve met in the organization whom we don’t have to convince – the Process Guy and the Tech Guy’s advocacy and belief in SMI Suite does far far more to convince the Budget Guy than anything we could say to him. But still, the introduction of the Budget Guy into the proceedings is far from a gimme.

After all, he wouldn’t be doing his job – and wouldn’t be entrusted with signoff on budget – if he didn’t at least do some due diligence. Sometimes this takes the form of fact-checking and re-checking everything that has already been discussed and agreed upon with the Process and Tech guys, but more often than not, the Budget Guy wants to look at the bigger picture.

He’s usually happy to take at face value that SMI Suite can, technologically, do what it promises if the Tech Guy says so, and he also understands, with the Process Guy’s advocacy, that SMI Suite will unlock the door to satisfying certain business needs – like the need to have accurate data about ITSM activities.

But he will almost always question the business benefit of all this. To use a rather labored metaphor, identifying a new type of spot welder that allows workers to weld three times as many bits of steel together as they could before, and is five times safer, and costs half as much to run as the old type, is all well and good… but not much use if you run a day-care facility.

Luckily for us, the business benefits of SMI Suite are pretty universal, so long as the organization in question runs an IT helpdesk and uses HP ITSM software. And, of course, each company we deal with is individual, so the benefits that are applicable change from organization to organization, but when we start to talk about improving helpdesk efficiency by accurately benchmarking and constantly remeasuring response times, or we talk about cutting costs based on accurate workload metrics, the Budget Guy usually takes an interest.

Next time: the Department Head

Tom