Incident Management & ITSM
The Cool Kid Acronym
By Evan Stos
In our work lives, and increasingly so in our personal lives, acronyms reign supreme. GRC, ITIL, ERM, ISO, BCDR, PCI, BBQ, LOL…they’re everywhere now. As I get older, I find myself Googling them more and more; FWIW stands for, “For what it’s worth,” and BTW (by the way)…you’re welcome.
In the wonderful world of GRC, there are always new acronyms popping up—the latest one getting a lot of buzz in our industry is IT Service Management, or “ITSM” for short. Picture, for a moment, that GRC is a high school lunchroom, with all of its various acronyms sitting at their respective tables. Suddenly, the lunchroom doors burst open and a loud record scratch is heard. ITSM then comes strutting in, wearing a leather jacket and sunglasses while rock music plays in the background, and everyone can’t help but pay attention. Also, I can answer the question you’re asking yourself: Yes, all of this happens in slow motion.
Ok, so maybe it isn’t exactly like a high school comedy movie from the 1980s, but its close. Regardless, from what I’ve seen over the past year or so, that’s how the industry views ITSM right now.
So, what exactly is ITSM, you ask? The strict definition is something along the lines of this: “All the activities involved in designing, creating, delivering, supporting and managing the lifecycle of IT services.” A huge part of ITSM is Incident Management, or IM for short (yay, acronyms!). Within the context of ITSM, the purpose of IM is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible. Having a well-defined IM process is crucial, as most incidents come without warning, and many can be shocking not only for an organization, but for its customers as well.
Here are my abridged CliffNotes of a typical IM process: The first and most important step in Incident Management is reporting (logging) of the incident. Next, incidents must be prioritized by leadership based on their level of business impact; handling simpler incidents should be optimized through a fairly (or completely) automated process, while more complex issues must be investigated and assigned to the proper personnel. In some extreme situations, a Disaster Recovery plan (or “DRP” for short…what, you thought I was done with the acronyms?!) may be utilized to resolve an incident. Finally, once a resolution has been determined and reviewed by management, the incident can be closed. The overarching activity happening throughout all of the aforementioned steps at one point or another is communication—automated or otherwise—of when the incident is logged, it’s current status, when it’s resolved, etc.
Having a platform that provides the ability to quickly and intuitively log and subsequently manage incidents is essential to the overall ITSM process. Hopefully, you’ve all learned something today—until my next blog, I’ll TTYL.