![]() ISO 20000 requirements on major incident management are short, but demanding: agreement, separate procedure, responsibility and review. It is one of the rare occasions where ITIL is strict in terms of definition: it MUST be agreed on. Business and IT have to agree on what constitutes a major incident. It affects a large number of users, depriving the business of one or more crucial services. In theory, a major incident is a highest-impact, highest-urgency incident. If you need a tool that will help you manage incidents, here is the list of Free tools for ITSM that you may try, and use for free. Service Desk, as a function of the Incident Management relies on known error database and workarounds provided. Once root cause has been identified, problem is referred as known error, and is registered in Known Error Database (KeDB). But in a case where seriousness of the incident is great, or avalanche of similar incidents are recorded, Problem Management process steps in and takes over the search for the root cause. ![]() In such cases, root cause is apparent, and resolution is simple as repairing faulty part, or applying a workaround. ![]() Incidents are generally results of errors or malfunctions within IT equipment. Read this blog post for more information: All About Incident Classification. Details about time frames in which each level of priority is expected to be resolved is part of Service Level Agreement (SLA). In such scenario, this incident is categorized as moderate priority – 3. In example, we may have high impact incident (high level – 1) affecting whole finance department, but low urgency (low level – 3) because they use that service only on the end of the fiscal year which is 6 months away. Impact is the effect incident has on a business, and Urgency basically defines time business (or customer) is ready to wait for resolution. And we prioritize incidents by Impact vs. In order to effectively manage incidents, we need to have means to prioritize them, because they rarely appear only one at the time. Reports about incidents may come from Service Desk (by call, e-mail, web), event management or directly by technical staff, but all of them have to be recorded, time stamped and contain sufficient data in order to be properly managed. ITIL Incident Management, as part of ITIL Service Management, is responsible for incident identification, logging and categorization. For an example, single failed disk drive within mirrored array is not causing any interruptions, but there is a service degradation in terms that risk of data loss has increased, and that’s why such event is also considered as an incident. Any event that disrupts or could disrupt a service itself is within the scope of incident management. So once incident happens, and they will, primary goal of ITIL Incident Management is to restore service as quickly as possible in order to minimize the business impact. ITIL Incident Management OverviewĪny unplanned interruption or service degradation is, according to ITIL, considered as incident. Major incident management is one of them, and due to its significant impact and visibility, it deserves a few more words. ![]() Being one of the most elaborated key functions, there are a number of issues we could address in depth. Various authors have discussed Incident Management here on several occasions.
0 Comments
Leave a Reply. |