Sometimes people don’t understand ITIL and IT Service Management concepts simply because they’ve never experienced the concepts in an IT environment, and that disconnect won’t allow them to “get it.” Through my 8+ years of ITIL training, I’ve often referred back to my days of waiting tables in a restaurant to understand the concepts. Using that model, I invite you to join me as I begin a series called Café ITIL.
Many people love to cook, and they assume they will enjoy running a restaurant, because it gives them the opportunity to do what they love. New restaurants open all the time. It is one of the top categories for new businesses. However, it is also one of the top categories for failed businesses. Similarly, techies and technical managers assume that if they like and understand computers, they can do just fine at managing IT for a business. Unfortunately, because they are not a stand alone business, it is not easy to tell when an internal IT department fails.
We’ll take a look at ITIL v3 concepts and processes and try to gain an understanding of them as if we were opening a new restaurant chain, Café ITIL. Hopefully, this will help shed some light on how we can improve how IT departments are managed. If it helps you create your business plan for a new restaurant, so be it.
I welcome your comments and insights as we go through this series.
? What other comparisons do you make when you’re thinking of ITIL concepts?
A server admin goes to the doctor and says "doctor every time I do this... it hurts". And the doctor says "take a couple of aspirin". That server admin is quite likely to feel the pain over and over again. We expect our doctors to find the cause and fix that. Our customers and users expect the same of us in IT.
Just like a physician, technology professionals deal routinely (and sometimes not so routinely) with issues that ‘hurt’ their customers and users. In the effort to simply return the device or application back to the normal operating state, the label is not important. Some teams get very good at dealing with these issues and become comfortable that they can fix it, should it break. The better we are at 'fixing it', the less we think of the symptom versus the cause. This results in spending most of the effort on the symptoms and not the cause or vice versa.
Each week I explain to a new group of IT professionals that an incident is the symptom and a problem is the cause. And it matters because when you want to improve, you must pick your targets carefully. If we sort the issues out into incidents versus problems, we begin to treat them differently because in fact they are very different, if inextricably linked. If we further look for some practices like ITIL that have worked well for others, we can improve how we deal with both. And that makes the ‘patient’ much happier with our efforts.