Integration Incident Management Process

Version: 1.0
Date 2006-10-02

Project:BaseLine / Version: 1.0
Document:Integration Incident Management Process.doc / Date:2006-10-02

Table of Contents

1Introduction

1.1Purpose

1.2Audience

1.3Version history

1.4Reference documents

2Problem Management process

2.1Process Overview

2.2Process details

2.3Roles and responsibilities

1 Introduction

1.1 Purpose

The Integration Incident Management Process document describes a structured way to handle problems related to a WebSphere integration platform.

The process should be used to help ensure that the appropriate activities are performed and that the appropriate people are involved in the process.

1.2 Audience

This document is meant for Application owners, IT staff at Customers and concerned parties such as service suppliers to the integration platform.

1.3 Version history

Version / Date / Description/comments / Responsible
0.90 / 2006-10 / First version / Zystems by Semcon

1.4 Reference documents

Document name / Issued by
Incident Report / Zystems by Semcon

2 Incident Management process

The Incident Management process spans from an incident connected to the integration platform occurs to the incident being resolved or a new integration demand (change) is identified.

2.1 Process Overview

2.1.1 Responsible

Operation manager

2.1.2 Input

The following objects are input to the process:

  • An incident identified by an initiator

2.1.3 Output

The following objects are output from the process:

  • Resolved incident or new integration demand (change)

2.2 Process details

Step 1 – Report incident

Application, Monitoring or Integration Center detects an incident and reports it to Global Helpdesk (SPOC).

Step 2 – Register and assign incident

SPOC registers and assigns an incident. The incident is assigned to 2nd Line Integration Support if the incident can be connected to the integration platform by the initiator. An incident could be registered by the 2nd Line Integration support when it is discovered during monitoring.

Step 3 – Receive and analyze incident

2nd Line Integration Support analyzes and informs the initiator.

Step 4 – Decision if the incident is an Integration Platform problem

After 2nd Line Integration support has analyzed the incident they decide if it is an integration platform problem or not. If it is not an integration platform the incident will be reassigned to SPOC and the initiator will be notified.

Step 5 - Look for solution

2nd Line Integration support will try to solve the incident. If it is not possible they will escalate it to 3rd Line support or Third party Product support and the initiator will be notified.

Step 6 – Resolve incident

If a solution is available 2nd line Integration support will resolve the incident and inform the initiator.

Step 7 – Close incident

When the incident is solved 2nd Line Integration support will document the solution and close the incident and the initiator will be notified.

3rd Line Integration Support

If a certain product knowledge or certain knowledge about a specific integration solution is needed the incident will be reassigned to 3rd Line Integration Support. They will provide 2nd Line Integration Support with a solution and then 2nd Line Integration Support implements the solution, reports the solution and closes the incident. If the incident cannot be solved it will be escalated to problem management or if the problem is a product error it will be escalated to third party product support.

If the analysis shows that it is not an Integration Platform incident it will be reassigned to SPOC.

Product related incident

If an incident is related to the product it will be reported to the Third Party Product Support. They will provide 2nd Line Integration Support with a solution and then 2nd Line Integration Support implements the solution, reports the solution and closes the incident.

Change Management

If an incident analysis results in a need for a change of the integration platform the problem ends up in the Change Management Process. The incident will be closed by 2nd Integration Line support and information will be sent to the initiator.

Problem Management

If an incident cannot be solved within 2nd Line or 3 rd Line Integration support it will be escalated to Problem Management. They will provide 2nd Line Integration support with a solution. If the problem demands a change the problem will be forwarded to Change Management.

2.3 Roles and responsibilities

Role / Description / Responsibility
IC / Integration Center / - Central function for integrations for the customer
Initiators / Application Owner or IT staff representing Application Owner, Monitoring or IC / - Initiate incidents related to application integration
Global Helpdesk (SPOC) / Help Desk function / - Receive incident reports from initiators
- Register and assign all incidents
2nd Line Integration Support / Team within Operation unit working with daily support of the integration platform / - Receive, analyze and resolve incidents
- Reassign incidents to other support organizations or 3rd Line Integration Support
- Report product related incidents to Third party product support
3rd Line Integration Support / Team within Operation unit with certain product knowledge and/or knowledge about a specific integration solution / - Receive and analyze incidents
- Provide 2nd Line Integration Support with solutions
Change Management / Change Management will take care of changes in the platform / - Takes care of changes in integrations and infrastructure
- Creates deploy packages
Problem Management / Problem Management will look for a permanent solution for the integration platform. / - Analyze the problem
- Provide solution to 2nd Line Integration support
- Escalate problem to Change Management
Third Party Product Support / Support for the actual software installed on the integration platform / - Support of software
- Provide 2nd Line Integration Support with product related solutions

1 (7)