Let’s talk about incident categorization. I recently had the pleasure of acting as track chair at the IT500 (IT in the Park) conference in Edinburgh. A role that’s good in terms of giving you involvement but one that also has two disadvantages – or at least I thought they were disadvantages until one turned into an advantage in Edinburgh.
The first is that you have to sit up front on the stage all day, being very visible and watching the audience rather than the presenter. The other – and the one that gave me the lucky break – is that you don’t get to choose which talks you attend. Instead having to be there for the whole of your assigned track.
So luckily for me, because I suspect instead of doing what I would usually do – going to listen to Claire Agutter and Paul Wilkinson in their late afternoon sessions – I was up on the stage introducing Tim Ingham of Lincoln University and Simon Kent of Sollertis Software and their talk entitled “Convergence – the Story of Strategic Business Relationship Management (BRM) and IT Operations at the University of Lincoln.”
I wasn’t sure exactly what it would cover but it turned out to totally nail something I have been “banging on about” in courses and presentations for the last 20 years – incident categorization. In fact, Tim did the whole presentation, from the University’s perspective, with Simon as the supplier involved sitting in the audience to cope with any technical questions. Which seemed right, since it’s the University that delivers and benefits from the initiative, and while tools are important in making things happen, this was – at heart – about what the University wanted and then managed to achieve.
Incident categorization – one incident category isn’t enough
I’ve always held the view that a single category for incidents in incident categorization doesn’t work, arguing for what I call opening and closing categories:
- The opening category relates to what the user is unable to do, the reason they have called, and should relate to the service involved. Without this being collected and recorded the service manager can’t be aware of how their service is performing from the user and customer perspective.
- The closing category, the one that IT support traditionally collects – recording the presumed underlying cause – and typically expressed as something like hardware, software, network, or user incompetence.
Knowing how many faults are hardware or software (even if you get it right) helps second line engineers, but it doesn’t give IT service management (ITSM) operations a picture of what business factors are at risk from IT failures.
Of course, this approach is simplistic and relies on building knowledge of the services within the incident capture process – both service desk people and technology. The ideal would be linking incidents directly to the relevant business process with a means to capture and articulate the actual and potential business damage.
They’ve only gone and done it!
What Tim showed in his presentation went beyond my ideas and formally linked BRM data with incident categorization capture and reporting. It looks simple enough – and that simplicity is part of its power. There was one little box on the incident capture screen, opening a link through to the range of business processes supported across the organization.
A quick look down the drop-down list lets the service desk analyst link the ticket to the business process affected. The smart bit is that the list comes directly from the data generated and maintained by their BRM process. It isn’t an Operations take but the definitive BRM one that is routinely maintained via the ongoing BRM process and dialogue.
At last – service management from IT
Sorry if I get excited about little things such as incident categorization – but for me this is just about the first case study I’ve seen showing actual service management within operations. Most of the time we see approaches driven by the processes set out in ITIL, COBIT, ISO/IEC20000, etc. However, this time the University is focused on what’s happening to their services. You would expect – logically and semantically – service-focused service management to be the norm, but yet it isn’t. So this talk looks like progress to me.
Real service management rests on an organization linking how they support services with a genuine and updated awareness of what those services are, and how they affect business goals. And I was just so pleased to see how this is now happening for the University.
For me, the key practical business measure for ITSM in an organization is “damage” – how much damage IT has caused. It isn’t perhaps the most optimistic perspective, but then no one ever called me optimistic and meant it.
To understand the damage that IT incidents and failures cause we must be able to link through to the business services affected. Maybe – in theory – a comprehensive configuration management system (CMS) will tell us that, but going directly for the link between effective BRM and call capture seems so obviously a more reliable and practical option. I loved the University of Lincoln’s approach and I’m looking forward to seeing Tim’s next update presentation on how this approach is delivering real benefits.
Have you tried anything with incident categorization similar to the University of Lincoln? If so I’d love to hear what you achieved.
Ivor Macfarlane
In 23 years working for the UK government, Ivor Macfarlane moved from forestry to ITSM via prisons, warehousing, and training. In 1999 he became an ITSM consultant and trainer, as a freelancer and directly for companies. He was an author for ITIL (versions 1, 2 & 3), ISO20000 and ITSM library and an ITIL examiner since 1991. An active contributor to social media and blogs, he is well known at ITSM events and has presented around the world (40 countries so far and on every continent except Antarctica). In addition to his work as an independent consultant, he also works alongside ITSM.Tools as an Associate Consultant.
