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.

Featured Resource:

Incident Management

Onspring empowers you to identify incidents and manage them to resolution. Our cloud-based solution gives you visibility, clarity and control across the incident life cycle. Download our Data Sheet to learn how we can help you manage incidents from a variety of data sources.

Incident Management Software Solution Brief

Like What You’ve Read? Subscribe for More

Join the Onspring Insights newsletter for monthly updates from our blog. You may unsubscribe at any time.

NOTE: By submitting this form, you confirm that you agree to our Privacy Policy.

NOTE: By submitting this form, you confirm that you agree to our Privacy Policy.