According to notable definitions, an incident is not an incident until it causes an issue. Yet if people are aware of conditions that will inevitably cause an issue, they should treat it as an incident anyway, right? This is proactive incident management in action. In a post for IT Chronicles, Michael Keelig elaborates on its value.
Preventing Fires
In Keelig’s estimation, people sometimes take the ITIL definition of incidents further than ITIL’s stewards had intended. The wording used can be implied to mean that incident management is entirely reactive in nature, and so people rigidly adhere to that idea. But a little common sense and a willingness to think outside the four (presumed) walls of ITIL shows that proactive incident management is very much possible and should be conducted. In fact, ITIL even acknowledges this:
Remember the version 2 definition of an incident, which included the words “any event which disrupts, or which could disrupt, a service”? The part in bold should be pretty clear in telling you that the expectation would be for you to address now – before service is disrupted – any event that could/will impact you if you wait (recall that in ITIL-speak, an event is “any change of state that has significance for the management of a configuration item (CI) or IT service”). And by the way, that “or which could disrupt a service” verbiage is still in there – they just moved it to SO 4.2.2.
Getting proactive about finding and fixing areas of worry incurs an appreciable time bomb element. Yes, incident management must be robust enough to resolve the incidents that arise, but to preserve the most business value, incident management should be similarly robust in its abilities to stop incidents from happening at all. You can view the original post here: https://www.itchronicles.com/itil/proactive-incident-management-important/
