MJN Incident-Major Incident Management PM V4.0.pdf

8/19/2019 MJN Incident-Major Incident Management PM V4.0.pdf

1/39

Mead Johnson & Company and IBM Internal Use Only

©IBM 2012

Unless otherwise marked, the printed version of this document is an uncontrolled copy.This document’s effective status cannot be assured beyond the day it is printed.

IBM Service Delivery

Mead Johnson Nutrition

Procedures ManualIncident / Major Incident Management

Document Owner: Boski Rai

Editor: Paulette Tollefson

Document Number: PPM-SVCMGT-MJN-1015

Document Revision Number: 4.0

First Issuance Date : 01 Sep 2012

Effective Date : 30 Days from Last Approval Date


2/39

Version 4.0 Incident / Major Incident Management

First Issuance Date: 01 Sep 2012 PPM-SVCMGT-MJN-1015 Mead Johnson Nutrition

Page 2 of 39


©IBM 2012


Table of Contents

1 Document Control............................................................................................................... 3 1.1 Preface.......................................................................................................................... 5

2

Incident / Major Incident Management............................................................................... 7

2.1

Description .................................................................................................................... 7

2.2 Scope............................................................................................................................ 8 2.3 Objectives...................................................................................................................... 9 2.4 Roles and Responsibilities........................................................................................... 11 2.5 Process Flow and Narrative......................................................................................... 15 2.6 Policies........................................................................................................................ 28 2.7 Interface Information.................................................................................................... 36 2.8 Glossary ...................................................................................................................... 37


3/39


4/39



Page 4 of 39


©IBM 2012


• Mead Johnson Nutrition Personnel: Contact the IBM Project Office for Mead Johnson Nutrition

Document Distribution and Notification

The original signed controlled copy is maintained by the IBM regulatory services organization.


5/39



Page 5 of 39


©IBM 2012


1.1 Preface

This section of the Procedures Manual (PM) provides customer interfaces for requesting and obtaining in-scope services associated with the outsourcing agreement. This document is intended to be used by IBM,

the IT service providers responsible for providing required services.The Procedures Manual Exhibit does not require amendments in order to make changes, therefore in theevent a conflict or inconsistency exists between the Procedure Manual Exhibit and the Agreement, theterms and conditions of the Agreement shall apply unless otherwise specifically stated herein.

1.1.1 How This Document Is Organized

This document is organized into the following elements:

• Document Control provides information about changes, document change approvers, reviewplans, how to find the latest version of the document, and document distribution.

• The Preface provides information about for whom this process is intended and how thisdocument is organized.

• Incident / Major Incident Management may include the following elements that explain servicesand interfaces:

Description

Scope (including Related Processes)

Objectives

Roles and Responsibilities

Process Flow and Narrative

Policies

Interface Information

Glossary


6/39



Page 6 of 39


©IBM 2012


1.1.2 Referenced Documents

Document Number Document Title

Not Applicable Refer to the Document Mapping Matrix for related documents

PPM-ASSET-MJN-1004 Asset Management

PPM-SVCMGT-MJN-1036 Change / Release / Deployment Management

PPM-SVRSYS-MJN-1008 Configuration Management

PPM-SVCMGT-MJN-1012 Event Management

PPM-SVCMGT-MJN-1017 IT Process Governance and Management System

PPM-SVRSYS-MJN-1018 IT Service Continuity Management

PPM-KNOW-MJN-1019 Knowledge Management

PPM-SVCMGT-MJN-1022 Problem Management

PPM-ENDUSR-MJN-1024 Request Fulfillment / Service Desk

PPM-SVCMGT-MJN-1027 Service Level Management


7/39



Page 7 of 39


©IBM 2012


2 Incident / Major Incident ManagementThis section provides an overview of the services and interfaces related to Incident / Major IncidentManagement for Mead Johnson Nutrition (MJN).

2.1 Description

The Incident / Major Incident Management process focuses on the restoration of a service affected by realor potential interruptions which may have an impact upon the quality of that service. Major IncidentManagement is designed to work in parallel with Incident Management to facilitate the recovery of standardservice operation as quickly as possible when it is disrupted by Incidents which cause severe disruption orextreme impact.

Incident / Major Incident Management is utilized by various functional groups to manage and minimize theimpact of Incidents affecting the availability and services through analysis, tracking, resolution, andprevention of Incidents impacting managed Information Technology (IT) resources.

From the ITIL® V3 Glossary:

Incident Definition: “An unplanned interruption to an IT service or a reduction in the quality of anIT service. Failure of a Configuration Item that has not yet impacted service is also an Incident, forexample, failure of one disk from a mirror set.”

Major Incident Definition: “The highest Category of Impact for an Incident. A Major Incidentresults in significant disruption to the Business.”

Problem Definition: “A cause of one or more Incidents. The cause is not usually known at the timea Problem record is created, and the Problem Management process is responsible for furtherinvestigation.”

Known Error Definition: “A Problem that has a documented root cause and a workaround.” (Note:It remains a known error until it is permanently fixed by a Change.)

The Incident / Major Incident process recovers standard service operation as quickly as possible. It may bethat as a result of Incident analysis and resolution, the Incident cause is discovered. If this is not the caseand if further investigation is justified in respect of cost and effort, then Problem Management is initiatedand a Problem record is created. Problem Management investigates a Problem and the root cause of theProblem. The status of a Problem is transformed to “known error” when both the root cause is known and aworkaround or permanent resolution has been identified. Refer to the Problem Management PM for furtherdetail.


8/39



Page 8 of 39


©IBM 2012


2.2 Scope

Incident Management includes the following activities:

• Opening an Incident record

• Performing entitlement (typically performed within the Request Fulfillment / Service Deskprocess)

• Updating the Incident record to reflect the current status of the Incident

• Assigning the Incident to an Incident resolver

• Identifying severity of the Incident

• Analyzing the Incident and performing Incident determination

• Implementing a workaround or resolution for the Incident to perform recovery of the service(through Change / Release / Deployment, as required)

• Updating the Incident Knowledge Base to assist with future Incident and Problem investigation

and diagnosis

• Closing the Incident record

• Monitoring Incident (request) queues to provide resolution for Incidents within committedservice levels, reprioritizing, reassigning and escalating as necessary

• Addressing day-to-day service delivery issues that impact the resolution of Incidents withincommitted service levels

• Analyzing completed Incidents and process measurements and reports, conducting trendanalyses, and identifying and documenting process improvement requirements and processconformance issues

• Providing management of Incidents from start to finish for anything in-scope of service delivery,

such as hardware, software, tools, reports• Providing a method in which Incidents are reported by users or discovered within the IT

organization by automation or people

• Handling (automatically or with human assistance) of system events that have been identifiedas Incidents by the Event Management process

• Participating in the procedures defined for handling Major Incidents

• Initiating Problem Management when the root cause of the Incident has not been identified

• Working with other processes to implement the workaround or resolution for the Incident, forexample, Change / Release / Deployment, System Support; Incident Management monitorsand records the progress and results of the solution implementation

Major Incident includes the following activities:• Customizing / maintaining the Major Incident Management plan

• Coordinating recovery from a Major Incident

• Participating in Incident and Problem resolution


9/39



Page 9 of 39


©IBM 2012


2.2.1 Related Processes

The Incident / Major Incident Management process may have the following relationships to other processes.

• The resolution of Incidents may involve the approval and implementation of Changes usingChange / Release / Deployment Management.

• When a fault is detected by Event Management, an Incident record is created in the IncidentDatabase, even if the event or Incident is to be handled by Event Management. Once theevent or Incident has been resolved, the Incident record is closed.

• Problem Management looks at groups of related Incidents to determine if there is a root causeto those related Incidents. It is also invoked in parallel to assist with recovery from the MajorIncident if required; and to investigate the Problem which is the unknown underlying root causeof one or more Incidents, then implement a resolution for the Problem.

• Request Fulfillment is the user-facing process for the Service Desk. When a user contact isrecognized as an Incident, it is routed to Incident / Major Incident Management by contactingthe Service Desk.

• Incident / Major Incident Management may use information from Asset Management,Configuration Management and Problem Management to resolve Incidents.

• The resolution of Incidents is important to the management of service levels in Service LevelManagement, which manages service expectations for each process.

• IT Process Governance and Management System manages the establishment and ongoingmaintenance and improvement of the process as well as the process measurements andreports.

• Knowledge Management manages knowledge bases that may be used to resolve Incidents.

2.3 Objectives

The objectives of Incident Management are to:• Recover standard service operation from Incidents as quickly as possible to minimize disruption

to the business caused by an Incident

• Resolve Incidents within committed Service Level Agreements (SLAs)

• Minimize the duration and impact of service outages associated with an Incident

• Reduce the number of Incidents to an acceptable risk at an acceptable cost by engaging theProblem Management process where required to perform a root cause analysis and helpprevent reoccurrence of the Incidents

• Assist MJN to minimize the impact to its business during an Incident (business impactmitigation)

•

Minimize Incident life cycles: Automate tasks wherever possible

Optimize time and effort spent resolving Incidents

Maximize productivity of resources


10/39



Page 10 of 39


©IBM 2012


Monitor and measure the process

The objectives of Major Incident are to:

• Classify an Incident as a critical business impact and invoke Major Incident activities

• Handle Major Incidents effectively in order to minimize their business impact

•

Execute appropriate communication activities (notification and escalation) for the duration ofthe Major Incident

• Reduce the cycle time for service restoration of critical business impact Incidents by:

Clearly assigning ownership of the Incident

Providing adequate resources/skills to work on the Incident


11/39



Page 11 of 39


©IBM 2012


2.4 Roles and Responsibilities

The roles involved in the Incident / Major Incident Management process and the responsibilities associatedwith those roles, are listed below.

Please note:

• Responsibilities may include, but are not limited to, those listed for each role.

• Roles are meant as logical groupings of tasks. They are not intended to match particularorganizational structures or formal job roles.

• Several roles may be performed by the same individual provided proper segregation of duties ismaintained.

• A role may be split up among several individuals.

2.4.1 Requester

The Requester role is responsible for reporting the Incident. Specific responsibilities may include:

• Submitting a request for Incident resolution

• Providing additional Incident information if required

• Receiving confirmation of Incident resolution and completion

• Receiving notification of Incident record closure

2.4.2 Incident Owner

An Incident Owner is responsible for an individual Incident. The Incident Owner oversees the handling of

the Incident, bringing in analysts and specialists as needed to handle the Incident. The Incident Owner mayperform the Incident Analyst role. The Incident Owner is responsible for seeing that analysts and specialistsbring the Incident to a close. Specific responsibilities may include:

• Overseeing activities related to the assigned Incident

• Determine the Incident severity and priority

• Being responsible for the overall handling of a specific Incident

• Determining which Configuration Items (CIs) are involved in the Incident

• Bringing in appropriate analysts/specialists as needed

• Verifying that the Incident is resolved and closed

2.4.3 Incident Analyst

The Incident Analyst is typically a 2nd level (or higher) support professional and subject matter expert. Thisrole is responsible to quickly provide a good analysis of an Incident, determine what is required to restore


12/39



Page 12 of 39


©IBM 2012


the service, and initiating the appropriate action to restore the impacted service as soon as possible.Incidents are typically assigned to the Incident Analyst by the Service Desk in Request Fulfillment. Specificresponsibilities may include:

• Performing Incident determination

• Creating a workaround

• Initiating a Change request or Problem ticket

• Executing a workaround, if applicable

• Installing a permanent fix for the Incident

• Executing a resolution, if applicable

• Escalate and coordinate support groups and third-party providers until Incidents are resolved

• Updating the Incident reporting system with resolution information

• Providing effective resolution to the Incident in accordance with the priority service level

• Updating the closure portion of the Incident record

• Identifying resolved Incidents as candidates for inclusion in the operational documentation

2.4.4 Incident Manager

The Incident Manager is responsible for the quality and integrity of the Incident / Major IncidentManagement process and is the interface to the other process managers. Specific responsibilities mayinclude:

• Verifying post-review of severity 1 Incidents

• Chairing the Incident and Problem review meetings

• Following defined escalation path when needed, as defined in the escalation policy

• Notifying the participants in the Incident / Major Incident Management process when standards

and procedures are not being followed

• Rerouting misdirected Incidents that have not been handled in a timely manner

• Responding to the Incident Analysts regarding escalation issues in a timely and appropriatefashion

• Identifying Incidents which need special attention or escalation

• Coordinating day-to-day execution of the process

• Identifying and implementing changes to the process

• Identifying exceptions and deviations, as well as management of these situations

•

Communicating new and changed policies• Verifying the standards and procedures are being followed

• Notifying the participants in the process when standards and procedures are not being followed

• Facilitating the resolution of issues with items not complying with the process


13/39



Page 13 of 39


©IBM 2012


• Identifying and implementing process improvement

• Acting as focal point for process, communicating with clients, service providers, andmanagement

• Following defined escalation path when needed, as defined in the escalation policy

• Overseeing day to day process administration

• Overseeing completeness and integrity of information collected to conduct daily operations

• Monitoring measurements and targets to improve process effectiveness and efficiency

• Being responsible for evaluating the performance of the process

• Assisting in the auditing of the process for compliance with documented procedures

• Defining those parts of the Process Framework not defined by the Process Owner

2.4.5 Incident Management Process Administrator

The Incident Management Process Administrator supports the Incident Manager by managing records,

tracking action items, and providing process-related reports.

Refer to the IT Process Governance and Management System process for further responsibilities.

2.4.6 Incident / Major Incident Management Process Owner

The Incident / Major Incident Management Process Owner is accountable to senior management for theproper design, execution, and improvement of the process, but does not run the day-to-day operation of theprocess.

Refer to the IT Process Governance and Management System process for further responsibilities.

Roles related to Major Incident Management:

2.4.7 MJN Major Incident Focal / Distribution

The MJN Major Incident Focal / Distribution is responsible for receiving notifications and interfacing with theMajor Incident Manager as required during a Major Incident.

2.4.8 Major Incident Manager

The Major Incident Manager has overall responsibility for verifying that Service Level Agreements orObjectives are achieved by managing the impact of Major Incidents. Tasks in this role may be performed asappropriate by team members such as the Resolver Group Manager, Business Recovery Manager (BRM),and Service Delivery Manager (SDM). Specific responsibilities may include:

• Managing Major Incidents


14/39



Page 14 of 39


©IBM 2012


• Tailoring and maintaining the Major Incident framework

• Participating in the Problem Management activities as needed: to find and alleviate the rootcause and to verify that objectives for availability of services are met (Refer to the ProblemManagement process for more details):

Participating in post Major Incident follow up via Post Incident Review on Major Incidents

Participating in the Root Cause Analysis for problems that affect services (as required)

• Collecting Major Incident measurement data for reports, as needed

• Providing communications to service delivery teams

2.4.9 Major Incident Owner

The Major Incident Owner has overall responsibility for managing recovery from a Major Incident. This roleis typically performed by the IBM Business Recovery Manager. Specific responsibilities may include:

• Managing and owning the Major Incident through service recovery

• Reviewing classification of the Incident as a Major Incident

• Determining and handling the scope of the Major Incident

• Driving, assessing and handling the recovery plan

• Assembling a team of resolver groups (other levels of support and across platforms asrequired) if additional support is required within the allowable time

• Confirming that internal notification and escalation activities are executed

• Facilitating conference bridges, as needed

• Handling Incident determination activities

• Confirming that the Incident Analyst (resolver) contacts the Requester to confirm that theservice has been restored to their satisfaction

• Making service restoration/recovery decisions (engaging the service delivery organization asrequired)

• Reviewing that the progress of the Major Incident recovery and relevant times are documentedin the associated Major Incident communication record(s)

• Participating in Major Incident reviews

2.4.10 Major Incident Recovery (SWAT) Team

The Major Incident Recovery (SWAT) Team is responsible for doing Incident determination (for MajorIncidents for which the probable cause/recover plan is not determined within the first 15 minutes).Specific

responsibilities may include:

• Convening periodic SWAT / Service Recovery Team meetings

• Providing Incident status for MJN callback

• Assembling Service Recovery Team


15/39



Page 15 of 39


©IBM 2012


• Consolidating the integrated recovery plan

2.4.11 IT Service Continuity Management Team

The IT Service Continuity Management Team may be called upon to assist during a Major Incident outage,

particularly if there is an IT continuity situation. The Continuity Team then assumes ownership of theIncident and executes the IT Continuity Plan in place for that location. The team is comprised of severalroles that execute and manage the recovery of the service. See the IT Service Continuity Management PMfor further responsibilities of this team.

2.5 Process Flow and Narrative

The following Incident Management and Major Incident flows illustrate the interfaces between theRequester and service provider personnel. Further details are outlined in the narrative following the flows.


16/39



Page 16 of 39


©IBM 2012


2.5.1 Handle Incident, Flow 1 of 2

Yes

Incident Management: Handle Incident

1

Identify an

Incident

3

Classify Incident

and Provide InitialSupport

7 Assign to Incident

Analyst Workgroup

8Investigate

Incident

9

Additional

Information

Required?

11

Diagnose Incident

5

Major Incident

Needed?

No

15

Resolve Incident

or Implement

Workaround to

Recover Service

10

Provide Required

Information

Yes

No

6

Handle Major

Incident –

Flow 2

16

Resolution /

Workaround

Successful?

17

Permanent

Resolution

Needed?

18

Problem

Management

No

4

Resolution /

Workaround

Available?

No

Yes

Yes

14

Change /

Release /Deployment

Management

Yes12

Root Cause /

Workaround

Development

Needed?

13

Change /

Release /

Deployment

Management

Needed?

No

No

22

Update and Close

Incident Record

Yes

Yes

Yes

19

Workaround

Developed for

Incident?

Yes

Parallel

Paths

23Knowledge

Update

Needed?

24

Knowledge

Management

End

Yes

No

EndNo

20

Obtain

Concurrence to

Close Incident

Record

20

Concur to

Close Incident

Record?

No

2

Identify and Log

Incident

A

A

No


17/39



Page 17 of 39


©IBM 2012


2.5.2 Handle Major Incident, Flow 2 of 2


18/39



Page 18 of 39


©IBM 2012


2.5.3 Handle Incident Narrative

Objectives: ▪ Resolve Incidents that occur in the Service Delivery environment▪ Minimize the duration and impact of service outages▪ Reduce the number of Incidents to an acceptable risk▪ Minimize Incident life cycles

Roles: Primary Roles:

▪ Requester▪ Incident Owner▪ Incident Analyst▪ Incident Manager

Related Roles:

▪ Incident Management Process Administrator▪ Incident / Major Incident Management Process Owner

Prerequisites: Reported Incident

Inputs: Inputs may include but are not limited to:

▪ Incident record▪ Incident impact▪ Incident activity data▪ Incident communication to Requester▪ Incident information▪ Incident resolution plan▪ Problems and known errors▪ Workaround / fix▪ Configuration information▪ MJN input▪ Event

Controls: ▪ Incident / Major Incident Management framework▪ SLAs, OLAs, and UCs

Outputs: Outputs may include but are not limited to;

▪ Resolved Incident▪ Updated Incident Knowledge Base▪ Asset data updated▪ Change request▪ Configuration item (CI) data update information▪ Communication to Requester▪ Incident information▪ Incident resolution plan▪ Workaround/ fix


19/39



Page 19 of 39


©IBM 2012


The Handle Incident narrative includes the steps outlined below.

Role Step Description

Requester 1 Identify an Incident

The Requester can be a user, a support person, process, or an automatedtool that identifies the Incident.

When an Incident is identified by a user, the initial Requester entitlement andservice entitlement are done by the Service Desk in the Request Fulfillment process which manages the initial user contact with the service provider.

IncidentAnalyst

2 Identify and Log Incident

Create an Incident record using the available information about the Incident.Include information provided by the Requester.

Incidents may come from many processes, which may include but are notlimited to:

▪ Request Fulfillment / Service Desk▪ Event Management▪ Security Management▪

Change / Release / Deployment Management▪ Problem Management▪ Other

Entitlement for Incident records directly entered by service delivery teams ismanaged by controlling access to the Incident tool.

Log the Incident even if it may be subsequently rejected.

▪ Log Incident according to associated policies.

Control Point: Submitted Incident record

IncidentOwner

3 Classify Incident and Provide Initial Support

Capture contact details and log relevant information and description of theIncident.

Categorize the Incident severity according to the Incident / Major IncidentManagement framework to provide guidance in handling the Incident.

Search for matching Incidents. If this is a duplicate Incident, handle accordingto the framework, such as closing the Incident record or attaching it to amaster record.

Identify the impact and urgency of the Incident, which are used to set theIncident priority. The impact includes determining what CIs are affected by theIncident or its resolution. The priority may be changed as needed during thelifecycle of the Incident. Identify the appropriate Incident model to follow, if oneexists.

If a resolution is available in the Knowledge Base, document the servicerecovery plan in the Incident record.

Control Point: Incident severity and classification in Incident record

IncidentOwner

4 Resolution / Workaround Available?

▪ If Yes, proceed to Change / Release / Deployment Required? ▪ If No, proceed to Major Incident Needed?


20/39



Page 20 of 39


©IBM 2012



IncidentOwner

5 Major Incident Needed?

Do the Major Incident process steps need to be followed?

▪ If Yes, proceed in parallel to Handle Major Incident Flow 2 and Assignto Incident Analyst Workgroup

▪ If No, proceed to Assign to Incident Analyst IncidentOwner

6 Handle Major Incident, Flow 2

Proceed to the second part of this flow.

Initiate Handle Major Incident flow, which is used to notify appropriatepersonnel and service providers of Major Incidents. These steps areperformed in parallel with those in Flow 1 (Handle Incident).

Control Point: Major Incident activities documented in Incident record

IncidentOwner

7 Assign to Incident Analyst Workgroup

Review the assignment of the Incident record and assign the Incident recordto the appropriate Incident Analyst workgroup. If the Incident record has beenincorrectly assigned, reassign it to the appropriate group, if known, or work

with the Incident Manager to reassign. Classify the Incident record based oninformation provided by the Requester.

Control Point: Workgroup assigned in Incident record

IncidentOwner

8 Investigate Incident

Receive the Incident and assign to a specific Incident Analyst.

Interpret the Incident conditions and symptoms documented in the Incidentrecord to:

▪ Determine the probable cause▪ Identify possible solutions▪ Verify Incident record assignment

The Incident Owner is responsible for the Incident through resolution. If the

initial assignment of the Incident was incorrect, the Incident Owner isresponsible for the Incident until a new Incident Analyst accepts the Incidentresponsibility. If it is necessary to reassign the Incident record, the IncidentOwner is accountable for callback commitments made. While the analyst isresponsible for performing the work, it is ultimately the Incident Owner whomaintains the responsibility for that Incident. The Incident Owner can do oneof the following:

▪ Reassign the Incident directly to a new Incident Analyst within the samegroup using a warm transfer

▪ Reassign the Incident to a new support group using a warm transfer,especially in the event the Incident record is approaching its Incidentresolution target date

▪ Consult with the Incident Manager, or the Service Desk to determine

where to reassign the Incident recordTimely reassignment is essential to meet service restoration targets.

If, after analysis, it is determined that the severity is misclassified, otheroperations may be initiated, for example: Major Incident execution for Severity1 Incidents.


21/39



Page 21 of 39


©IBM 2012



IncidentOwner

9 Additional Information Required?

▪ If Yes, proceed to Provide Required Information ▪ If No, proceed to Diagnose Incident

Requester 10 Provide Required Information

Provide additional information that is required to the Incident Analyst.Proceed to Additional Information Required?

IncidentAnalyst

11 Diagnose Incident

Identify the failing component and diagnose the cause of the Incident. Usingthat information, identify the proper recovery procedure to minimize theimpact. Update the Incident record with the complete findings and actions,including date and time for contacts made and actions taken.

If root cause is known, document the root cause findings in the Incidentrecord.

If a resolution or workaround to resolve the Incident is available in theKnowledge Base, document the resolution plan, document in the Incident

record. Include details of people involved, actions, testing and recoveryactivities), risk and impact implications and change requirements. Coordinatechanges with the Incident Manager as needed. Where possible, test to seethat the resolution plans works, especially for complex resolution plans.

If a resolution or workaround is not available, create a workaround if possibleand document in the Incident record for update of the Knowledge Base.

Control Point: Diagnosis documented in Incident record

IncidentAnalyst

12 Root Cause / Workaround Development Needed?

Is further root cause analysis or development of a workaround needed torestore service from this Incident?

▪ If Yes, proceed to Problem Management ▪ If No, proceed to Change / Release / Deployment Management

Needed?

Incident

Analyst

13 Change / Release / Deployment Management Needed?

Is Change / Release / Deployment Management needed for implementation ofthe available resolution or workaround?

▪ If Yes, proceed to Change / Release / Deployment Management ▪ If No, proceed to Resolve Incident or Implement Workaround to

Recover Service

Incident

Analyst

14 Change / Release / Deployment Management

Submit a Change Request (RFC) and invoke the Change / Release /Deployment Management process to control implementation of the resolutionor workaround, per policy.

Control Point: Submitted Change record referenced in Incident record


22/39



Page 22 of 39


©IBM 2012



IncidentOwner /

IncidentAnalyst

15 Resolve Incident or Implement Workaround to Recover Service

If a resolution is available in the Knowledge Base, document the servicerecovery plan in the Incident record

Resolve the Incident or implement a workaround to recover the service as

quickly as possible.

Update the Incident Record with actions taken and results.

Update Knowledge Bases as needed.

Note: Additional work may later be required later to implement a permanentresolution.

Control Point: Resolution actions documented in Incident record

Incident

Analyst

16 Resolution / Workaround Successful?

▪ If Yes, proceed to Permanent Resolution Needed? ▪ If No, proceed to Problem Management

Incident

Analyst

17 Permanent Resolution Needed?

▪

If Yes, proceed in parallel to Problem Management and ObtainConcurrence to Close Incident Record▪ If No, proceed to Obtain Concurrence to Close Incident Record

IncidentAnalyst

18 Problem Management

Submit a Problem record to invoke Problem Management process forsituations which may include:

▪ Root cause has not been determined and needs root cause analysis▪ Workaround is not available and could not be created by Incident resolver

team; further research is needed to develop a workaround▪ Workaround was not successfully implemented▪ Resolution was not successfully implemented▪ Permanent resolution is needed for an underlying Problem that could

cause similar Incidents, needing further investigation and preventative

action to be permanently removed from the environmentControl Point: Submitted Problem record referenced in Incident record

Incident

Analyst

19 Workaround Developed for Incident?

Was a workaround developed in the Problem Management process which isneeded to restore service for this Incident?

▪ If Yes, proceed to Diagnose Incident▪ If No, proceed to End

Incident

Owner /IncidentAnalyst

20 Obtain Concurrence to Close Incident Record

Obtain concurrence from the Requester that the Incident was resolved. Referto Requester Concurrence policy.

Control Point: Concurrence documented in Incident record per policy

Requester 21 Concur to Close Incident Record?▪ If Yes, proceed to Update and Close Incident Record ▪ If No, return to Diagnose Incident


23/39



Page 23 of 39


©IBM 2012



IncidentOwner /

IncidentAnalyst

22 Update and Close Incident Record

Fill in missing information needed for closing the Incident record. Reclassifythe Incident based on the resolution, if needed, and retain the original detailssuch as category. If known errors are found that are related to the Incident,

indicate those errors. Document the resolution so the information can be usedin another Incident or Problem.

Close the Incident record, and post updates or new resolutions to the IncidentKnowledge Base. (Note: In most cases, Incidents are closed when theservice is restored. Details may vary by account.)

If there are duplicate Incident Records related to the same Incident, closethose records as well. The Incident may have been created from one or moreevents, which are also closed as needed.

Send information to the Requester, indicating that the Incident has beenclosed. Provide satisfaction survey to Requester if required. Notify otherinterested parties of Incident closure, as needed.

Control Point: Updated and completed Incident record

IncidentAnalyst

23 Knowledge Update Needed?

▪ If Yes, proceed to Knowledge Management▪ If No, proceed to End

Incident

Analyst

24 Knowledge Management

Invoke the Knowledge Management process to add new information or reviseexisting knowledge in the knowledge base.

The Handle Incident flow is complete.


24/39



Page 24 of 39


©IBM 2012


2.5.4 Handle Major Incident Narrative

Objectives: To resolve Major Incidents that occur in the service delivery environment

Roles: Primary Roles:

▪ MJN Major Incident Focal / Distribution▪ Major Incident Owner▪ Incident Analyst▪ Major Incident Manager▪ Major Incident Recovery (SWAT) Team

Related Roles:

▪ IT Service Continuity Management Team

Prerequisites: Reported Incident

Inputs: Inputs may include but are not limited to:

▪ Description of outage▪ Incident classified as a Major Incident▪ Incident records▪ Major Incident plan▪ Major Incident policies and standards▪ Records of events surrounding the handling of an Incident▪ Documentation of unrecorded Problems associated with the Incident

Controls: Authentication from the Service Management

Outputs: Outputs may include but are not limited to:

▪ Resolved Major Incident▪ Voice status messages updated▪ Alerts to stakeholders▪ Business impact mitigation planning▪ Closed Alert▪ Documentation of required process changes▪ Incident report▪ Recovery from Major Incident▪ Completed root cause analysis▪ Service providers notified of Major Incident▪ Service restored▪ Updated alerts▪ Updated Incident records▪ Updated Major Incident plan▪ Automated service outage message deleted▪ Whiteboard status message updated▪ Knowledge updates


25/39



Page 25 of 39


©IBM 2012


The Handle Major Incident narrative includes the steps outlined below.


Major IncidentManager

1 Receive Notification of Major Incident and Assign MI Owner

Receive notification, typically from:

▪ Request Analyst, Incident Analyst, or Operations Analyst who hasopened an Incident record

▪ Automated tool that sends information directly to a 2nd

level resolver▪ Incident Owner who determines that the Incident is a Major Incident

Proceed in parallel to:

▪ Coordinate Recovery from Major Incident▪ Perform Major Incident Notification▪ Identify / Develop Recovery Plan

Major IncidentOwner

2 Coordinate Recovery from Major Incident

Manage the Incident determination and Incident recovery activities, whichmay include the following:

▪ Determine scope of Major Incident▪ Assemble Major Incident Recovery (SWAT) Team to increase the focus

of determination▪ Confirm appropriate staff are working on the Incident to minimize the

duration▪ Assemble service recovery team

Control Point: Major Incident communication record

MJN Major

Incident Focal/ Distribution

3 Receive Communication about Major Incident

Receive ongoing communications related to the Major Incident.

Major IncidentManager

4 Perform Major Incident Notification

The following are requirements during the course of a Major Incident to keepthe appropriate support teams and management updated regarding the

status/progress of the Incident:▪ Verify that MJN is notified and kept up to date with the resolution of the

Incident▪ Verify that internal management is notified and kept up to date with the

progression of the Incident▪ Verify that there is escalation for additional resources/visibility at

prescribed intervals▪ Verify that details of the Incident determination/Incident recovery are

documented.


Proceed to Major Incident Resolved?


26/39



Page 26 of 39


©IBM 2012



Major IncidentOwner /

IncidentAnalyst /

Major IncidentRecovery

(SWAT) Team

5 Identify / Develop Recovery Plan

Develop a recovery plan to assist in the recovery from the Major Incident.

Control Point: Recovery plan documented in Incident record

Major Incident

Owner /

IncidentAnalyst /


(SWAT) Team

6 Major Incident Resolved?

Continually track the status of the Major Incident and determine if the MajorIncident has been resolved. (The Major Incident is considered resolved whenthe viability of the bypass or service restoration has been ascertained and theIncident has been documented, reviewed, and recorded in the Incidentrecord.) Note: While the three roles can perform the tasks, it is ultimately theresponsibility of the Major Incident Owner to confirm these tasks areaccomplished, from beginning to end.

▪

If Yes, proceed to the following parallel paths: Notify Distribution that Major Incident Was Resolved Update Record, Close Major Incident

▪ If No, return to the following parallel paths: Coordinate Recovery from Major Incident Perform Major Incident Notification Identify / Develop Recovery Plan

Major Incident

Manager7 Notify Distribution that Major Incident Was Resolved

Verify that MJN is made aware of the resolution.


MJN MajorIncident Focal

/ Distribution

8 Receive Notification of Resolution

Receive final notification that the Major Incident was resolved.

Major Incident

Owner /

Incident

Analyst /


(SWAT) Team

9 Update Record, Close Major Incident

Update the record with actions taken and contacts made.

Close the Major Incident activities, such as, close down communicationbridges and perform communication related activities.

Note: While the three roles can perform the tasks, it is ultimately theresponsibility of the Major Incident Owner to confirm these tasks areaccomplished, from beginning to end.


IncidentAnalyst /

Major Incident

Recovery(SWAT) Team

10 Is Problem Mgmt Required?

▪ If Yes, proceed to Problem Management ▪ If No, proceed to End.


27/39



Page 27 of 39


©IBM 2012



Major IncidentManager /


IncidentAnalyst /

Major Incident

Recovery(SWAT) Team

11 Problem Management

Invoke the Problem Management process to perform the Major IncidentReview, which is intended to prevent the recurrence of related Incidents andto promote the continuous improvement of service delivery. The objectives

are:▪ Clearly identify the root cause of the Problem▪ Identify process/procedure compliance issues and/or deficiencies▪ Provide timely information regarding the known error and its resolution▪ Confirm action items are identified and logged▪ Propagate knowledge learned to other platforms and teams▪ Update Knowledge Bases, as needed

Control Point: Submitted Problem record referenced in Incident record

The Handle Major Incident flow is complete.


28/39



Page 28 of 39


©IBM 2012


2.6 Policies

2.6.1 Incident Prioritization PolicyAn important aspect of logging every Incident is to agree and allocate an appropriate prioritization code asthis determines how the Incident is handled by both support tools and support staff. Prioritization cannormally be determined by taking into account both the urgency of the Incident and the level of impact tothe business.

The following table shows an effective example for calculating both urgency and impact and arriving at anoverall priority.

BUSINESS IMPACTUse this matrix

to calculate the priority of an Incident High Medium Low

High Top High Medium

Medium High Medium LowURGENCY

Low Medium Low Low

2.6.2 Severity Definition Policy

The severity of an Incident is based on the criteria shown in the table below. The severity may bedowngraded during the life of an Incident if it is determined that the original business impact wasoverestimated. The severity may be upgraded if the original business impact was underestimated or theIncident situation has become business critical.

The Incident Resolver documents the business justification for modifying the severity in the Incident record.

If a change in severity results in an increased resolution time, the Incident Analyst notifies the Requesterand documents the notification in the Incident record.

The severity of an Incident is based on the following criteria:

Severity Characteristics ResponseTime

ResolutionTime

1

Severe

Business

Impact

▪ Critical System, network or key application outage withcritical impact on service delivery affecting multiple endusers.

▪ Affects customer’s critical business functions, including: selling making or buying of product, critical sites (plants, global, region or country

headquarters),

progress of clinical trials Environmental, Health and Safety compliance close of financial books completion of a scheduled payroll, bonus, or

sales commission run response to regulatory authorities

30 minutes 3 hours


29/39



Page 29 of 39


©IBM 2012


Severity Characteristics ResponseTime

ResolutionTime

response to subpoenas planned product launch

▪ Impact on business partner connection affecting multiplepartners

▪ Impacts one or more service level commitments.▪ Reassignment is communicated / agreed directly.

2

Major

BusinessImpact

▪ Key component, application, critical end user machine ornetwork is down, degraded, or unusable affecting multipleend users.

▪ Potential critical impact on service delivery including: request from key customer or account interruption in critical data flow multiple business functions across multiple sites non-critical sites (for example, sales office) impact on financial audit critical end user equipment

▪ Impact on business partner connection affecting limited

partners▪ Service performance degradation; service delivery

impacted.▪ Reassignment is communicated / agreed directly

1 hour 6 hours

3

Minor

BusinessImpact

▪ A component, minor application or procedure is down,unusable, or difficult to use. Some operational impact, withonly limited impact on service delivery.

▪ Incidents that degrade service but do not prevent deliveryof service.

▪ Limited to a minor application, component or procedure▪ Potential exposure to ability to delivery of service.▪ Scattered customers affected.▪ Reassignment is communicated / agreed directly

4 hours 12 hours

4Minimal

or NoBusiness

Impact

▪

Component, procedure, not critical to customer isunusable. Alternative is available; deferred maintenance isacceptable.

▪ No impact to service.▪ No production affected.▪ Individual customer affected.

1 business day 2 businessdays

• Incidents with systems or components that are not supported 24x7 are not worked on oranalyzed immediately during a weekend or holiday period, and cannot be classified as Severity1 Incidents.

• By definition, a Severity 1 Incident cannot apply to a single user. By exception, if a Severity 1 isdemanded for a single user, the user reporting the Incident needs to be available 24x7 until the

Incident is resolved. Otherwise, the Incident is reclassified according to the appropriatedefinition within the process.

• MJN will be notified for inappropriate requests for high severities.

• If a Severity 1 Incident has been incorrectly assigned to a resolver group, the resolver groupreassigns the Incident to the appropriate Incident Analyst and initiates a warm transfer.


30/39



Page 30 of 39


©IBM 2012


2.6.3 Incident Logging Policy

Incidents are logged and date/time stamped, regardless of whether they are raised through a Service Desktelephone call or whether automatically detected via an event alert.

The information needed for each Incident is likely to include:• Unique reference number

• Incident categorization (often broken down into between two and four levels of sub-categories)

• Incident urgency, impact and prioritization

• Date/time reported

• Name/ID of the person and/or group recording the Incident

• Method of notification (such as telephone, automatic, e-mail, in person)

• Contact details - name/department/phone/location of user

• Backup Contact for severity 1 or 2 Incidents

• Description of symptoms

• Incident status (active, waiting, closed, and so forth)

• Related Configuration Items

• Support group/person to which the Incident is assigned

• Activities undertaken to resolve the Incident

• Resolution date and time

• Closure category

• Closure date and time.

Note: If Service Desk and/or support staff visit the customers to deal with one Incident, they may be askedto deal with further Incidents ‘while they are there’. It is important that if this is done, a separate IncidentRecord is logged for each additional Incident handled – to verify that a historical record is kept and credit isgiven for the work undertaken.

2.6.4 Incident Assignment Policy

Assignment of Incidents follows a forward progression with the objective to resolve the ticket as quickly aspossible minimizing customer lost productivity. Tickets are not reassigned back to a previous resolver groupbut always progressed forward unless specific conditions exist. For an explanation of those conditions seethe Incident Reassignment Policy.

Where the resolver group cannot be identified by the Incident Owner or Analyst, it is necessary to contactthe Service Desk or service management for guidance on which resolver group is assigned the Incident.


31/39



Page 31 of 39


©IBM 2012


2.6.5 Incident Reassignment Policy

Ownership of an Incident may be reassigned by the assigned support group where there is:

• Insufficient detail to fulfill the Incident

• An inaccuracy in the Incident record such as incompatible or conflicting data

• An incorrect assignment, as the ownership is outside the scope of responsibility of the assignedsupport group. In this instance the ticket is assigned to the correct support group not back tothe previous support group minimizing customer impact

Before reassignment by the owning support group can occur the Incident is updated to indicate the rejectreason and then either:

• Reassign the Incident to the correct support group

• Where correct support group is unknown, contact the Incident Manager or Major IncidentManager (for Major Incidents) to establish an appropriate owner before reassignment.

Verbal notification accompanies reassignment to verify no further delays are experienced.

Where ownership disputes occur, the assigned support group escalates to the Incident Manager or Major

Incident Manager (for Major Incidents).To avoid unnecessary ownership rejections, each technical support group reviews and verifies theassignment information and specific data requirements held by the Service Desk.

The Service Desk, upon receipt of the communication, amends the relevant templates and scripts to verifycorrect assignment and ownership occurs first time.

2.6.6 Incident Pending Policy

An Incident record is changed to pending status (stopping of the SLA clock) when one of the followingevents occurs:

• The required information from the end user is unavailable

• The information/materials/facilities are required from non-IBM support

• The services are dependent upon the action of the account/customer or a customer vendor

Resolver Group Leaders manage “Pending” tickets to verify proper handling of the records

2.6.7 Requester Concurrence Policy

Customer Concurrence is required on Severity 1 and 2 Incident records. Severity 3 and 4 Incidents arecompleted through automation. Customer communication is documented in the Incident record.

Note: Customer concurrence is an attempt to contact MJN via telephone, pager, or electronic mail. TheIncident record is updated in the closure text documenting the contact with MJN.

MJN Not Available to Concur: In the event MJN is not available to provide concurrence and confirmresolution of the Incident and, reasonable attempts to contact the customer based on severity guidelineshave been made (via telephone, pager, electronic mail), the Incident record is closed, Attempts to contactthe customer are documented in the Incident record and sent via email (when possible).


32/39



Page 32 of 39


©IBM 2012


2.6.8 Escalation Policy

Escalation provides additional attention and visibility to issues that have exceeded predefined criteria suchas SLAs, including:

• Incident record does not contain pertinent data

• Incident record was not represented at the Incident meeting, if applicable

• Incident record was not resolved within the service resolution target time

• Incident record was not closed within targeted time

Escalation consists of a series of warnings:

• The first warning will be issued to the Incident Owner

• The second warning will be issued to the Incident Owner and their first line manager

• The third warning will be issued to the Incident Owner and their first and second line managers

2.6.9 MJN Unplanned System Outage Escalation PolicyEscalation of an unplanned system outage includes these tasks.

Responsible: Team responsible for performing the identified taskTiming: The target start time for the identified task, shown as an offset in minutes from zero. Minute zerorepresents the time when a Sev1 incident is created.Task: Activity to be performed as part of incident resolution and communication

Step Responsible TIMING

(ASAP, no later

than:)

Task

1 Multiple Hour 0 IMPACT Online Service Desk incident ticket opened

Triggered by one of these events:

- Monitoring alert sent to IBM Operator console

- Service Desk contact by user

- AMS or Technical Team response to ticket assigned to their queue

Ticket severity to be determined by incident contact person

- Instructions assume Sev 1

2 Service Desk + 5 mins Ticket assigned to, or IBM Operations otherwise contacted, for initialtriage (Verbal or Sametime dialog)

3 Service Desk +10 mins Update IMPACT banner (if MJN impact clear from incident reporter)

4 Service Desk +10 mins Update IVR message (if MJN impact clear from incident reporter)5 IBM

Operations +10 mins Assign ticket to appropriate resolver group

6 IBM Operations +15 mins Contact resolver group on-call person (Verbal or Chat dialog)


33/39



Page 33 of 39


©IBM 2012



(ASAP, no later

than:)

Task

7 IBM Operations +20 mins Open IBM Oneview incident record for IBM internal escalation

8 Resolver +30 mins Problem determination and resolution in progress

9 IBM +30 mins Duty Manager engaged for incident management (Technical Bridgeand/or Chat Initiated)

10 IBM Duty Mgr. +35 mins Notify IBM BRM / SDM / DPE

11 IBM Duty Mgr. +40 mins IBM Business Recovery Manager engaged

12 IBM Duty Mgr. +45 mins IBM Service Delivery Manager engaged

13 IBM BRM orSDM +50 mins

Notify MJN Application Contact via phone. Escalate to Contact1, 2,3 until reaching an individual.

14 MJN Appl.Contact +55 mins Perform additional MJN notification / escalation

15 IBM BRM +60 mins IBM Oneview Executive Alert distributed (IBM DPE / PE / etc.)

16IBM BRM +60 mins

Distribute Mead Johnson Outage Notification ("Custnote") via emailand mobile devices

17IBM SDM +65 mins

MJN/IBM Mgmt. Bridge call initiated (provide outage information,confirm impact, resolution collaboration)

18 Service Desk +75 mins Update IMPACT banner

19 Service Desk +75 mins Update IVR message

20IBM BRM +120 mins


21IBM BRM +180 mins


22 IBM BRM +240 mins Distribute Mead Johnson Outage Notification ("Custnote") via emailand mobile devices

23IBM BRM +300 mins

Distribute Mead Johnson Outage Notification ("Custnote") via emailand mobile devices (Hourly)

24 MJN Appl.Contact Upon Resolution Confirm resolution and end of outage

25IBM BRM Upon Resolution

Distribute Mead Johnson Outage Notification ("Custnote") via emailand mobile devices (Resolution)

26Service Desk Upon Resolution Remove outage from IVR message

27Service Desk Upon Resolution Remove outage from IMPACT banner

28 Resolver Upon Resolution Create IMPACT Problem ticket to drive Root Cause Analysis

29Resolver Upon Resolution Change IMPACT Incident ticket status to Resolved

30Resolver Upon Resolution

If an Emergency Change was performed, create a ClearQuestchange ticket then add ClearQuest ticket number in the External


34/39



Page 34 of 39


©IBM 2012



(ASAP, no later

than:)

Task

Reference number in the IMPACT incident ticket.

31MJN Upon Resolution Notify MJN Executives of Outage and Resolution

2.6.10 Technical Bridge Call Guidelines Policy – Used forMajor Incidents

• The technical bridge call should be restricted to only technical resources that are requiredfor the resolution of the Major Incident and the account team.

• Everyone joining the Technical Bridge call should announce and a roll call should bemaintained.

• To facilitate communication in a global support environment a technical Sametime chatmay be open. If there is a technical chat open, updates from the chat should be provided tothe IBM/MJN Management bridge calls at regular intervals.

• Many major incidents do not require a technical bridge and are handled via Sametime chator other methods of communication.

2.6.11 IBM/MJN Management Bridge Call Guidelines Policy –Used for Major Incidents

• The SDM will facilitate the Management Bridge call after being engaged by a BRM.

• Account team should be on the technical call and/or in the technical chat if open to obtainupdates for the customer call.

• Updates should be provided by the BRM to the SDM manager on the technical bridge call.

2.6.12 IBM Third Party or Supplier Ownership for IncidentsPolicy

Throughout the Incident / Major Incident Management process, an IBM Third Party or Supplier may becomeinvolved. Engaging or assigning ownership to an IBM Third Party or Supplier is dependent on their accesslevel within the Service Management tool.

There are various levels of access:

• Full access,

• Restricted access (for example, read only),


35/39



Page 35 of 39


©IBM 2012


• No access.

Where full access is granted, an IBM Third Party or Supplier adheres to the Incident / Major IncidentManagement process and policy where ownership of an Incident record has been assigned.

Where an IBM Third Party or Supplier does not have direct (full) access to the Service Management tooland no automated bridging facility is in place, the record ownership and the responsibility for verifyingupdates to the Incident record remains with the support group that owns the relationship (acting on behalf ofthe IBM Third Party or Supplier).

The support group interacts with an IBM Third Party or Supplier to obtain information such as:

• Corresponding tool reference identifiers, including the level of impact and urgency applied(allocated severity)

• Progress updates relating to parallel activities or work performed

• Issues including delays to service recovery, and functional or hierarchic escalations performed

2.6.13 Knowledge Management Policy

The Service Desk provides and updates a list of frequently asked questions (FAQ) regarding the servicesthat focus on improving self-help, documenting repetitive Incidents and solutions, and helping improve firstcall resolution at the Service Desk. Refer to the Knowledge Management PM for further details.

2.6.14 Incident / Major Incident Framework Policy

The Incident / Major Incident Management framework is developed and maintained to meet the needs ofthe account regarding Incidents and Major Incidents. The framework may include but is not limited to thefollowing activities:

• Defining severity classification schemes

• Identifying resolution targets

• Creating tables identifying teams to be assigned, by system or service

• Defining Major Incident criteria

• Defining local management alert criteria/procedure

• Defining executive alert criteria/procedure

• Defining MJN alert criteria/procedure

• Defining escalation procedure

• Defining service restoration notification procedure

• Tailoring/maintaining the Major Incident plan


36/39



Page 36 of 39


©IBM 2012


2.7 Interface Information

Interface Information describes both MJN-initiated interfaces with IBM and IBM-initiated interfaces with MJNassociated with the Incident / Major Incident Management process.

2.7.1 For Hardware Incidents

For supported hardware products, Incidents that cannot be resolved by the Service Desk are routed to theappropriate hardware service provider to resolve.

Incidents with non-supported hardware products are handled on a commercially reasonable efforts basis.

2.7.2 For Software Incidents

For software Incidents, the following support levels apply:

• Level 1

Call management and Incident determination at the Service Desk. Level 1 support managescalls through resolver groups to completion; Incidents are not necessarily resolved at theService Desk.

• Level 2

Referral to local expertise; either on-site personnel or more specialized support at the ServiceDesk take the call and manage to resolution.

• Level 3

Referral to IBM or external expert (such as Microsoft). Resolution is beyond capability of Level1 or Level 2 support and is handled by subject matter experts.

The Service Desk makes every effort to resolve software Incidents remotely, but may occasionally dispatcha software technician to your office.

For Incidents with MJN Line-of Business (LOB) applications, the Service Desk routes the Incident to theappropriate MJN resolver group.

Incidents with non-supported software products are handled on a commercially reasonable efforts basis.


37/39



Page 37 of 39


©IBM 2012


2.8 Glossary

Term Definition

BRM Business Recovery ManagerConfiguration Item(CI)

A Component that needs to be managed in order to deliver an IT Service.Information about each CI is recorded in a Configuration Record within theConfiguration Management System and is maintained throughout its Lifecycle byConfiguration Management. CIs are under the control of Change Management. CIsmay include IT Services, hardware, software, buildings, people, and formaldocumentation such as process documentation and SLAs. (ITIL® V3 Glossary)

1

Escalation An activity that obtains additional resources when these are needed to meet servicelevel targets or customer expectations. Escalation may be needed within many ITservice management processes, but is most commonly associated with Incident /Major Incident Management, Problem Management and the management ofcustomer complaints. There are two types of escalation, functional escalation and

hierarchic escalation. (ITIL® V3 Glossary)Fix An action that permanently solves an Incident or Problem. (ITIL® V3 Glossary)

Impact A measure of the effect of an Incident, Problem, or Change on business processes.Impact is often based on how service levels are affected. Impact and urgency areused to assign severity. (ITIL® V3 Glossary)

Incident An unplanned interruption to an IT service or a reduction in the Quality of an ITservice. Failure of a Configuration Item that has not yet impacted service is also anIncident, for example, failure of one disk from a mirror set. (ITIL® V3 Glossary)

Incident Record A record containing the details of an Incident. Each Incident record documents theLifecycle of a single Incident. (ITIL® V3 Glossary)

Knowledge Base A logical database containing the data used by the service Knowledge Management

System. (ITIL® V3 Glossary)

The database used to identify, create, distribute, share and enable users withknowledge learned by others. Known workarounds, fixes and experience share thewealth of known success.

Major Incident The highest category of impact for an Incident. A Major Incident results in significantdisruption to the business. (ITIL® V3 Glossary)Local policy determines the criteria for declaring an Incident a Major Incident.

MJN Mead Johnson Nutrition

1 ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government

Commerce, and is Registered in the U.S. Patent and Trademark Office


38/39



Page 38 of 39


©IBM 2012


Term Definition

Operational LevelAgreement (OLA)

An agreement between an IT service provider and another part of the sameorganization. An OLA supports the IT service provider's delivery of IT services tocustomers. The OLA defines the goods or services to be provided and theresponsibilities of both parties. For example there could be an OLA

▪

Between the IT service provider and a procurement department to obtainhardware in agreed times▪ Between the Service Desk and a support group to provide Incident resolution in

agreed times

(ITIL® V3 Glossary)

PgMS A management system - a comprehensive set of integrated policies, plans andprocesses - to deliver solutions to IBM Global Services clients. The ProjectExecutive and the Business Office team operate the Program Management Systemto control all aspects of a services contract.

Post IncidentReview

A Post Incident Review following a Major Incident to confirm that records have beenclosed, root cause is understood, notifications have been sent, knowledge baseshave been updated, and lessons learned have been gathered.

Priority A category used to identify the relative importance of an Incident, Problem orchange. Priority is based on impact and urgency, and is used to identify requiredtimes for actions to be taken. (ITIL® V3 Glossary)

Problem A cause of one or more Incidents. The cause is not usually known at the time aProblem record is created, and the Problem Management process is responsible forfurther investigation. (ITIL® V3 Glossary)

ProceduresManual

The Procedures Manual (PM) describes the interfaces between Requesters andservice providers, along with roles, responsibilities, and policies.

Process A structured set of activities designed to accomplish a specific objective. A processtakes one or more defined inputs and turns them into defined outputs. A processmay include the roles, responsibilities, tools and management controls required to

reliably deliver the outputs. A process may define policies, standards, guidelines,activities, and work instructions if they are needed. (ITIL® V3 Glossary)

ProcessFramework

The foundation for management and continual improvement of the process,including the policies, procedures, organizational roles and responsibilities andother information under which the process operates to meet its mission and goals.

The Incident / Major Incident Management process framework includes data itemssuch as:

▪ Severity classification schemes▪ Resolution targets▪ Tables identifying teams to be assigned by stem or service

Recovery Returning a Configuration Item or an IT service to a working state. Recovery of anIT service often includes recovering data to a known consistent state. After

recovery, further steps may be needed before the IT service can be made availableto the users (restoration). (ITIL® V3 Glossary)

Recovery Plans Plans to recover and restore service.


39/39



Page 39 of 39

Term Definition

RegulatoryDatabase

The database used for creation of individual profiles, tracking of training and on-linestorage and maintenance of controlled documentation supporting regulatedaccounts. May also be referred to as the Americas Regulatory Documentation(ARD) database.

Restoration Taking action to return an IT service to the users after repair and recovery from anIncident. This is the primary objective of Incident / Major Incident Management.(ITIL® V3 Glossary)

SDM Service Delivery Manager

Service LevelAgreement (SLA)

An agreement between an IT service provider and a customer. The SLA describesthe IT service, documents service level targets, and specifies the responsibilities ofthe IT service provider and the customer. A single SLA may cover multiple ITservices or multiple customers. (ITIL® V3 Glossary)

Severity The Severity of an Incident is determined by the impact to the users or the business.The Severity levels for Mead Johnson™ Nutrition are:

▪ Severity 1: Severe Business Impact (Major Incident)▪

Severity 2: Major Business Impact▪ Severity 3: Minor Business Impact▪ Severity 4: Minimal or No Business Impact

UnderpinningContract (UC)

A contract between an IT service provider and a third party. The third party providesgoods or services that support delivery of an IT service to a customer. TheUnderpinning Contract defines targets and responsibilities that are requ