SERVICE MANAGEMENT, SIAM, SMAAS07 October
Zombie service management - Do you want to be effective or productive?
About Incident Categorization
A zombie idea is a proposition that has been thoroughly refuted by analysis and evidence, and should be dead — but is still walking among us. In the service management world, just once in a while you will meet some of those nasty creatures. In this blog I try to explain how to recognize and ultimately kill them.
I regularly travel to Africa; I love the continent and hence love to go there. However, one of the things that gets me really wound up is the bureaucracy. The irritation already starts just before the plane lands, when I have to fill in the so-called ‘passenger’s card’. This form consists of 2 parts, the first part of which is for customs and immigration and the second part for the ‘Ministry of Tourism’. Exactly the same information as in part 1 is asked for in this second part: name, first name, place of birth, occupation, etc.
Because I detest repetition, one day I filled in something different as occupation: ‘SM coach’, (which of course stands for ‘‘service management coach”). Since then I’ve been making it a sport to keep it original. I landed in Burkina Faso as an “Oceanographer”, in Ghana as a “Prosector”, in Congo as a “Whiskey ambassador” and in Ethiopia as a “Pet Psychic” and I’ve never been questioned about it before. On the other hand, personally, I do have some questions. Why is it that all these African countries present you with exactly the same form and with exactly the same questions? Who was it that invented it and why has each country copied this? And who the hell ever does anything with it? Secretly, I hope that someone at the Congolese Ministry of Tourism annually makes a graph of tourists and their occupation to discover that last year there was a 'whiskey ambassador’ amongst them. And why for that matter, has no one in these countries asked why this is not done away with? The probable reason: abolishing the form would mean that the people who collect, punch, count, classify, type out the forms in Excel and report about them, would no longer be productive - and would anyone want that?
When Incident Categorization becomes a Total Waste of Time
ITIL tells us that we should classify incidents; and if you want to classify then you need a classification. This has given rise to the most ingenious incident classification systems, main categories, sub categories, sub-sub categories and sub-sub-sub categories. With incident registration (or incident closure) you then need to say that your incident is of the category “PC->Laptop->hardware->mouse” or “mail->mailbox-> storage”. And at the end of the month the service delivery manager makes a nice little report with the incidents per incident category and everyone’s happy, right?
The problem is that these classifications just don’t work - at all. Over time, nobody will even bother to fill them in correctly, with the exception of the authors who are the only ones that truly understand the classification and complete these very meticulously. The others always fill in the same categories or have the idiosyncratic trait of perversely selecting from the most eccentric categories. That pattern is readily apparent in the reports: there are always the same meaningless categories on top, with a strong preference for categories of the type 'other'. And yet those responsible continue to report monthly on the basis of that data. Not in order to define actions - everyone knows that the data are not suitable for this - but because it gives a feeling that they have everything under control and that people are thus productive. And as is also the case in African ministries of tourism, no one dares to question this ‘Total Waste of Time’.
Systems have to be Productive, People Effective
In the 21st century, systems have to be productive whereas people on the other hand should be effective. Should we stop classifying incidents? No, but in a good process model and with a properly configured tool, this is done indirectly. The fact is that in such systems your work is service oriented. Incident Registration therefore starts with the selection of the service. For example, you select the ‘Mail’ service. Then you will need to answer the question what part of your service is affected, let’s call it the Service Infrastructure. In the example of the mail service it could be the ‘Mail Antivirus Servers’. This information is required to know to which team you need to assign the ticket (a good ITSM tooling will make the assignment for you). And finally, the engineer at the close of the incident, will select the configuration item that was the cause of the incident, in our example it could be the "Expurgate AntiVirus" software. All of this takes place in a natural and necessary process of analysis and diagnosis in order to bring the ticket to the appropriate individuals and to detect the solution. This doesn’t create any additional overhead and these data, which you can take action on, are relevant for reporting. If it appears that the number of incidents in the mail service increases and that this increase is due to the Expurgate service infrastructure, then the mail service owner knows what he has to do.
If it doesn’t bother you to manage your ITSM processes in the typical ‘African-ministry-of-tourism style’, continue to use your complex Incident Categorization model. If this bureaucracy bothers you but your ITSM tooling doesn’t support services and service infrastructures, just get rid of your tooling, there are some excellent ITSM toolings out there that fully support the above concept. So let the 21st century begin now and throw away those complex incident categories to become effective rather than productive.
Read more? Check out part 1 Zombie service management
About the author:
Wouter Wyns is a senior Service Management consultant at InfraVision with strong project management and business consultancy skills. His purpose is to help customers achieve their targets through creativity, quality and enthusiasm.