Written by Graham Furnis
Outside of the ITIL books and courses, I’ve been asked this question over and over again "What really is event management?"
You’ll come across the Event Management process flow when reading through the ITIL books. This is understandable by itself, stating: an Event happens, is detected in some way, in turn triggers an appropriate alert, which then is received and initiates further assessment and action. But is this really Event Management?
The scenario just described is too late for “management”, as the event has already happened, the alerts have been sent, and people are busy assessing and taking actions according to pre-defined procedures. As well, there is typically no central point of control with a dedicated Event process team and manager who receives and manages all alerts. Monitoring is usually distributed across the organization. Sure, some may find their way to Incident and the Service Desk, but this is only a small portion of the total.
So the question remains: where and what is the bulk of Event Management activity taking place? The answer is found at the front and back end of Operations.
At the front end, Event Management is linked to the Service Design Phase, especially when considering availability, continuity, capacity and security objectives for Services and their underlying Components. This is where we define our combined control objectives top-down. The more critical the Service, the more critical are the components that form key points of failure. These key components would likely be chosen to design Event Monitor and Control objectives and methods.
A critical decision in the Design Stage is to decide specific component attributes, their measures and their threshold levels. Typically we decide on unusual and exception threshold targets where alerts are generated for assessment – all else we accept as normal. To finish we add the pre-defined business rules that guide the actions of people receiving the alerts. So making good design decisions from the start is critical for Event Management success in Operations. But there’s more…
Event Management is dynamic; not static. Setting Event objectives, thresholds, and business rules needs to be continually assessed and improved. Thresholds that are set too low may trigger too many unnecessary alerts and support actions - negatively affecting staff productivity. Thresholds that are set too high may NOT trigger important negative events early enough, thus leading to Service disruption – negatively affecting customer productivity and laying waste to the Event design effort in the first place. Therefore, in Operations, Event Management is busy continually reviewing the appropriateness of Event monitoring and control results. Where necessary, changes are made to improve the effectiveness of Event monitor and control design, activities and objectives.
My last comment concerns scope. In a perfect world it makes sense to establish Event monitor and control for all infrastructure components. The issue in doing this is cost! It takes time, skills, budget and technology to design and instrument monitoring tools and methods across the organization. And the more you have, the more you have to maintain (as described above), and therefore the more time and costs accumulate. Here’s where Event Management ties into the Strategic Phase… What can we afford? What are the priorities? What are the resource and capability requirements internally? What external help is needed?
Event Management doesn’t typically focus on managing events when they occur; the focus of its activities typically starts early in Strategy and Design and follows up with continual reassessment. Something to consider!
Graham Furnis is fully immersed and passionate in providing ITSM solutions. He is a business-driven IT professional with 20+ years of technology and management experience. He is certified as an ITIL Manager and Expert as well as an accredited instructor.