About Incident Management
Incident Management includes any event which disrupts, or which could disrupt a service. This includes events communicated directly by users through the Service Desk or an interface from Event Management to Incident Management tools.
Goal
The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within SLA limits.
Objectives
The objectives of incident management are:
Definitions
Field | Description |
---|---|
Input Value |
Impact is determined by how many personnel or functions are affected. There are three grades of impact: 3 - Low – One or two personnel. Service is degraded but still operating within SLA specifications. 2 - Medium – Multiple personnel in one physical location. Service is degraded and still functional but not operating within SLA specifications. It appears the cause of the incident falls across multiple service provider groups. 1 - High – All users of a specific service. Personnel from multiple agencies are affected. Public-facing service is unavailable. The impact of an incident will be used in determining the priority for resolution. |
Incident |
An incident is an unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Failure of any Item, software or hardware, used in the support of a system that has not yet affected service is also an Incident. For example, the failure of one component of a redundant high-availability configuration is an incident even though it does not interrupt the service. An incident occurs when the operational status of a production item changes from working to failing or about to fail, resulting in a condition in which the item is not functioning as it was designed or implemented. The resolution for an incident involves implementing a repair to restore the item to its original state. A design flaw does not create an incident. If the product is working as designed, even though the design is not correct, the correction needs to be in the form of a service request to modify the design. The service request may be expedited based on the need, but it is still a modification, not a repair. |
Incident Repository |
The Incident Repository is a database containing relevant information about all Incidents whether they have been resolved or not. General status information along with notes related to activity should also be maintained in a format that supports standardized reporting. |
Priority |
Priority is determined by combining the incident’s impact and severity. For a full explanation of the determination of priority, refer to the paragraph titled Priority Determination. |
Response |
Time elapsed between the time the incident is reported and the time it is assigned to an individual for resolution. |
Resolution |
Service is restored to a point where the customer can perform their job. In some cases, this may only be a work around solution until the root cause of the incident is identified and corrected. |
Service Agreement |
A Service Agreement is a general agreement outlining services to be provided, as well as costs of services and how they are to be billed. A service agreement may be initiated between Virima Inc and another agency. A service agreement is distinguished from a Service Level Agreement in that there are no ongoing service level targets identified in a Service Agreement |
Service Level Agreement |
Often referred to as the SLA, the Service Level Agreement is the agreement between Virima Inc and the customer outlining services to be provided, and operational support levels as well as costs of services and how they are to be billed. |
Service Level Target |
Service Level Target is a commitment documented in a Service Level Agreement. Service Level Targets are based on Service Level Requirements. They are needed to ensure that the IT Service and meets the original Service Level Requirements. |
Severity |
Severity is determined by how much the user is restricted from performing their work. There are three grades of severity: 3 - Low - The issue prevents a user from performing some of their duties. 2 - Medium - The issue prevents the user from performing critical time-sensitive functions. 1 - High - A service, or a major portion of a service, is unavailable. The severity of an incident will be used in determining the priority for resolution. |
Related Topics