Incident Management Process at the Catholic University of America - Essay Example

The incident life cycle involves the discovery and listing, grouping and preliminary intervention, inspection and analysis, solution and revival, incident closure, incident ownership, follow-up and evaluation, tracking, and communication.

To avoid IT business disruptions as a result of system failures, it is important to plan and implement programs to optimize IT service management. This begins with the analysis and alignment of the current and future business requirements and appropriate IT services provided. More serious incidents must be given precedence/priority where there are a number of incidents to be dealt with at the same time, where the user must be consulted and reference made to the Service Level Agreement (SLA). To prioritize, the urgency and impact of the incident on the user and the business must be evaluated (Office of Government Commerce 31).

An incident that may not be resolved by first-line support staff should be escalated to more expertise or authority. This could be either functional (horizontal) or Hierarchical (vertical) escalation. 

1. Listing of Accepted Incidents

Any section of the IT infrastructure may cause incidents to happen including computer operations, networking, service desk itself, procedures, etc but these are usually reported by users. Detection systems can however be used to trap events taking place with the IT infrastructure. Incident management is related to other processes such as configuration management, problem management, change management, service level management, availability management, and capacity management (Office of Government Commerce 33).

2. Incident Grouping and Preliminary Intervention

This involves grouping the incidents in some identified criteria. Services related to the incident are identified with due regard to the SLA. A support group is selected if support staff cannot resolve the incident issue; a support group is determined as part of functional escalation and based on incident categorization. An aspect of timelines here is critical involving informing the affected business user about the estimated amount of time expected to resolve the issue, with due updates on progress also provided. Incidents are also matched to determine whether similar ones occurred previously, thus helping on diagnosis and solution turnaround.

3. Solution and Revival

Following an incident resolution, a record is made in the system for a Request for Change (RFC) submission to change management where necessary or/and appropriate. The RFC should usually lead to a solution (Office of Government Commerce 35).

4. Closure

With a solution in place, the incident is routed back to the service desk by the support group. The service desk then informs the user to check if indeed the incident has been resolved thereby closing the incident and the incident record updated to show the final category and priority, affected users, and components that have been identified as causes of the incident. If the user is not comfortable with the solution, the process can be reinitiated at the appropriate stage. 

5. Incident Monitoring and Evaluation

The service desk needs to undertake progress monitoring of the incident and inform the user about the status to get feedback, which might be useful for status change.

The whole incident management process yields report to various target groups at different levels for different functions. These groups include the incident manager, IT line manager, service level management, and process managers of other service management processes. For the incident manager, the report will bring out the variances with the SLAs, unavailable process links as well as monitor the process to identify the patterns. For the IT manager, the report is useful to control the support group area and could contain information on the progress of solving out incidents as well as incident turnaround time within the groups. In terms of service level management, the report informs on the quality of services given while reports to customers should contain details of whether the service level promises in the service level management have been met. To other service management processes, the report would contain plenty of information including but not limited to not only the number of incidents reported and recorded but also those that have been resolved and those to which no solution has been given. A successful incident management process should have an up to date CMDB used to estimate impact and urgency of incidents, a knowledge base to help in incident recognition and availability of solutions, an adequate automated system useful for recording, tracking, and monitoring incidents, and close liaison with service level management for appropriate priorities and resolution times.

Performance indicators are used to assess process performance and should be reported regularly by the incident manager in order to bring out trends. Such parameters could include number and frequency of incidents, the proportion of resolved incidents in line with SLA objectives, the average time to resolve incidents, fraction of incidents solved by first-tier support, per unit cost of incident resolution on average, and a number of proper escalations of incidents depending on priority, technicality, and urgency. Also, to ensure the success of the incident management process, there should be a clear demarcation of responsibilities that are linked with the process activities.