Incident Management Basics Still Matter
IT service management (ITSM) is constantly evolving, and over the 20 or so years that the term has been in common use, the scope has grown and spread considerably. The initial tight operational focus of the early ITIL® days has spread to address strategy and design as mainstream ITSM topics. Ongoing efforts are being made to combine ITIL with initiatives like DevOps to strengthen and broaden the value delivered to organizations.
This is all good stuff, and proper progress; but now and again it is good to recall that this brave new world must be built on solid ITSM foundations. Despite (or maybe because of) the years of progress, we need to make sure we get those basics right, so it is worthwhile looking back at some original concepts and confirm we still use them as a basis for our core ITSM approach.
Yes to Incident Management, Because Incidents Still Happen
IT services are becoming ever more reliable. This is good, not least because lives (literally!) now depend on everyday IT services supporting our travel, medical care, justice, and more. Things can – and do – go wrong though, and we still need a good process and sound procedures to capture and remedy them when they happen. This brings me to incident management and why it’s worthwhile to re-examine the fundamentals of incident management on which we’ve built our modern procedures, tools, and technology. For me, those fundamentals are: (1) dealing with the issue precisely once and (2) ensuring users can ask questions without already needing to know the answer. Let me explain…
Deal with Issues Precisely Once
We should never leave an issue unaddressed, nor should we duplicate our efforts by having several people working separately on the same issue. That’s the principle behind the precisely once fundamental I am talking about here. Effectively this means that when issues are detected – via a call to the service desk or within self-service and automation technology – two things should happen:
- They are recorded within a maintained system – that is they’re captured and kept safe.
- The symptoms, location, and other relevant details are compared with existing errors, problems, and incidents for matches. And if a match is found, then this new occurrence is linked with the existing one(s).
If this is delivered successfully, then we’ll neither lose issues nor have multiple efforts separately attempting to deal with the same underlying issue. That is:
- No call can be ignored: it is in the system and will be reported on until it is picked up and dealt with.
- Duplication doesn’t happen because the symptom matching means recurrences are identified and allocated to whoever is already dealing with the issue.
At this level, we can:
- Guarantee to clients that their issue will not be missed.
- Deliver efficiency in dealing with multiple occurrences.
Asking Questions without Needing to Already Know the Answers First
The service desk concept is at the heart of incident management, as it gives us a single point of contact that listens to our concerns and ensures we get support from the right place. Critically, it doesn’t leave it to the end users to know which particular kind of expertise they need to help them get working again. Meaning, they don’t need to know what kind of issue they have – just that they have one. The service desk and the incident process will work that out, allowing users to get issues registered and dealt with immediately, without them having to categorize themselves. And this is super important because the users don’t necessarily know how the technology works, only how they use it.
The service desk’s first-line support role is essential, therefore, to an effective incident management process. And, in addition, it is perfectly placed to match new calls with previously logged ones, and thereby ensure that we don’t allow duplication of efforts. Repeat instances are matched and sent to the support staff already dealing with the investigation.
The user calls that single contact point and, with a few key questions, it is established what should be done, and by whom.
As with most of ITSM, this is everyday practice interpreted for the work environment. Think about visiting your doctor; you don’t debate with yourself over what kind of medical specialist you need. Instead, you go to your general practitioner and you appreciate, and trust, their skill in establishing how to best deal with your issues.
Nowadays, rather than talking to service desk people every time, this logic is as likely to be built into our software tools and delivered through a self-service portal.
People, Process, and Technology
All this should show us one more thing that has not changed, which is the intimate interdependency between the people (IT and customer people), the process, and the technology. They all have to be effective. We see more and more technology providing us with the interface but we still need people to keep that technology asking, and answering, the right questions.
Your sophisticated modern integrated ITSM support tool is exactly that – a tool for helping you. Sometimes it is easy to get distracted by all the clever and cool features though. Taking the time out to check the basics, and ensuring that you are still inputting and maintaining that basic required information is time and effort well spent.
This is one more example of the power of ”getting back to basics” – it’s a theme I’ve focused on a lot in my blogs here and on the SysAid blog, and probably will continue do so. You can read some amazing ideas about that wider range of basics here. Enjoy!
