FCA PPIM AR.1.1 Problem Management 2020 Clean Execution

Release AR.1.
1 FCA Problem Management Policies and Procedures Interfaces

Updated Date: 09/09/20 Process Interface Manual FCA ITEM, FCA US LLC
IBM Strategic Outsourcing Delivery
Chapter 3 of PPIM
Problem Management
Process Interface
FCA ITEM, FCA US LLC and IBM
Document Owner: Paola Martinelli
Owner : Alberto Vaira
Document Name: FCA PPIM Problem Management
Document Release: AR.1.1
Last Modified on: September 9,2020

Master version of document is stored in: Pag. 1 of 34
Amended and Restated Master Service Agreement Common Repository
ANY HARDCOPY VERSIONS OF THIS DOCUMENT ARE FOR REFERENCE ONLY Status: Clean Execution
IBM, FCA ITEM, FCA US LLC Confidential
Release AR.1.1 FCA Problem Management Policies and Procedures Interfaces

Table of Contents
1 Introduction..................................................................................................................................... 3
1.1 Document Structure................................................................................................................. 3
2 Problem Management..................................................................................................................... 5
2.1 Description.............................................................................................................................. 5
2.2 Scope...................................................................................................................................... 5
2.3 Problem Management Interface Procedures...........................................................................5
2.3.1 Problem Management Interface.......................................................................................... 5
2.3.2 Escalate and Report on Problems.....................................................................................11
2.4 Policies and Guidelines......................................................................................................... 13
2.4.1 Formal RCA Policies......................................................................................................... 13
2.4.2 RCA Investigation and Documentation Guidelines............................................................14
2.4.3 Problem Priority................................................................................................................. 16
2.4.4 Escalation.......................................................................................................................... 17
2.4.5 Problem Accountability...................................................................................................... 17
2.4.6 Unresolved Problem Policy...............................................................................................18
2.4.7 Problem Analysis Completion versus Closure...................................................................18
2.4.8 Extension of Problem Closure Target Date.......................................................................18
2.4.9 Misdirected Problem Assignments....................................................................................19
2.4.10 Related Processes........................................................................................................ 19
2.5 Referenced Documents......................................................................................................... 20
2.6 Document Control.................................................................................................................. 20


1.Introduction
1.1. Document Structure

Figure 1 depicts the document structure for the Policies and Procedures Interface Manual (PPIM), for
the FCA ITEM and FCA US LLC outsourcing contract.

Process 1 TOC
Provides lists of
Introduction process interface
and Overview documents, reports,
appendixes and
Process 4
customer-specific
Change
Process annexes
Management
Interface
documents
Process n
Appendixes
Each process interface
document includes:
A generic process Annexes
description, roles and
responsibilities
Customer interface
information and C1 C2
policies to support B1 B2
customer interactions A1 A2
that are common to the
FCA
two Master Customers
ITEM FCA US
Annex documents specify customer-specific requirements (for example: Focal

Points, Critical Applications, linkage to customer-specific Operating
Procedures).
Figure 1. PPIM document structure
PPIM chapters consist of two key document types:

PPIM consists of two key document types:

 Process-specific interface documents that define roles and policies for consistent
interactions between IBM and the participating Customers in the FCA ITEM and FCA US
LLC Outsourcing Contract. Process interface documents contain procedures and policies
that are common to all two Master Customers.
 Annex documents, defining Customer-specific information, such as focal points, for use by
each process.
The Problem Management chapter of the PPIM describes the procedures and policies for the Customer
and IBM interactions. The word “Customer” refers to FCA ITEM and FCA US LLC, which are the two
participating Customers in the outsourcing contract.

2.Problem Management
1.
2.
2.1. Description
Problem Management is responsible for managing the lifecycle of all problems. The primary objectives
of Problem Management are to prevent problems, resulting Incidents from happening and to minimize
the impact of Incidents that cannot be prevented.
There are 2 types of Problem Management:
1. Proactive Problem Management
2. Reactive Problem Management
Both types utilize root cause analysis techniques and may initiate Requests For Change (RFCs). The
reactive type focuses on developing the knowledge base and workarounds to improve Incident
resolution. The proactive type focuses on initiating improvements and preventing Incidents (currently
the common Knowledge Database is not populated).
FCA ITEM, FCA US LLC and IBM use the Customer Service Management Tool (also known as Drive
IT) as Problem Management Tool.
English language is the only language allowed within the Customer Service Management Tool due to
the international nature of the support; exceptions are only allowed for Local Customer Contract (like
Cloud Specific Service Agreement) or specific regional requirement (like LATAM).
2.2. Scope
The scope of Problem Management includes all services and components described in the Exhibit-1 of
the Amended and Restated MSA contract and all the Local Service Agreement signed under the MSA
unless otherwise specified.
This scope includes but is not limited to the following:

 Mainframe Infrastructure and Systems Management
 Midrange Systems Management Designated Services

 Midrange Infrastructure On Demand Designated Services
 Midrange Infrastructure Full Box Optional New Services
 Platform Management
 Storage and Backup Designated Services
 Messaging Designated Services
 Data Center and Facilities (EMEA DCSA)
 Cloud Operation Services
2.3. Problem Management Interface Procedures
1.
2.
2.1.
2.2.
2.3.
2.3.1. Problem Management Interface

Figure 2 depicts the Problem Management Interface process flow and the related interactions
between the Customer and IBM personnel.

Figure 2. Flow diagram for the Problem Management Interface process
Table 1 provides the summary for Customer and IBM interactions, consisting of key required actions,
interfacing roles, interaction methods, and the organization involvement for the Problem Management
process. The Organization Involvement column is used to specify the organization involvement for the
key required actions, (R=Responsible, I=Informed, C=Consulted, S=Supportive).
Table 1. Interface summary for Problem Management
Interface Key Required Interfacing Roles Method Organization

flow # Action
Involvement
Customer IBM Customer IBM
PM101 Submit ITIL Requester Problem Problem R I

Problem Analyst record
Request (Customer
Service
Management
tool)


flow # Action
Involvement
PM102 ITIL Requester Problem Problem I R

Return
Analyst record
incomplete or
(Customer
duplicate
Service
requests
Management
tool)
PM103 ITIL Requester Problem Meeting, R C

Provide
Analyst Email or
additional
Problem
details, if
record work
needed
notes
PM104 Provide/Update Problem Focal Problem Meeting, I R

the RCA report Point Owner Email or
Problem
record work
notes
PM105 Review RCA Problem Focal Problem Meeting/ R I

report; provide Point Owner
feedback and Email and
Acceptance or Problem
Rejection. record
(Customer
Service
Management
tool)
PM106 Provide/Update Problem Focal Problem Meeting, I R

the Solution Point Owner Email or
Plan Problem
record work
notes
PM107 Review Problem Focal Problem Meeting/ R I

Solution Plan Point Owner
added to the Email and
RCA report; Problem
record

flow # Action
Involvement
provide (Customer
feedback and Service
Acceptance or Management
Rejection. tool)
PM108 Initiate Problem Focal Problem Meeting/ I R

requests for Point Owner Email
Customer
actions
PM109 Provide Problem Focal Problem Meeting/ R I
Confirmation Point Owner Email
for completed
actions
PM110 Communicate Problem Problem Meeting/ I R
the Solution Owner Email
Plan Focal Point
completed
PM111 Provide Problem Problem Meeting/ R I
Confirmation Owner Email
for Solution Focal Point
Plan
completed
Table 2 outlines the step-by-step narrative for the Problem Management Interface flow diagram.
Table 2. Narrative for the Problem Management Interface process flow

Responsible Step Description

Customer 1 Create Problem Request
For all P0 and P1 Incidents the Customer Service Management tool creates
the Problem Record automatically (with New Status).
Ideally the Assignment should be done automatically, but as long as not
all fields are filled automatically on Customer Service Management tool,
this is handled:
 In FCA NAFTA/LATAM by the Customer Problem Manager
 In FCA EMEA the assignment is managed by IBM, as per
agreement between the parties.
Create a Problem Record for Root Cause Analysis (RCA). A Problem record
may also be initiated by IBM internal processes such as Incident
Management.
IBM 2 Accept or Assign Problem Record
A Problem record requiring RCA is required based on Formal RCA Policies.
(See 2.4.1)
A Problem record may also be initiated by IBM internal processes such as
Incident Management.


IBM 3 Determine Root Cause, Resolution and Workaround
Investigate and conduct a Root Cause Analysis to determine the cause of the
Problem.
Record workaround to expedite resolution of related incidents in Customer
Service Management Tool.
Starts investigation of the root cause considering the following:
- 5 Why’s investigation, including (but not limiting to) the following:
- Symptoms
- Threads (for example, patterns of occurrence, user
environments)
- Exception events
- Operational monitoring data
- Change information
- Operational documentation
- Configuration information
- Trend analysis
Identify factors that contributed to the Problem and document them as the
Root Cause Analysis results, including findings from the Problem data
analysis, explanations of contributing factors and an indication of the
probable cause(s).
Document the known error information (including the Incident and its root
cause) within the Problem Record
Review the results of the analysis with the appropriate parties; for
example, affected service owners
Notify the appropriate parties if the results of the analysis of root cause are
applicable elsewhere
Investigate possible resolutions for the Problem to select potential
resolutions.
Determine if a workaround/solution can be created and record the findings
in the Problem Record. If a new workaround is needed by the Incident and
Major Incident Management process to restore service, document a new
workaround in the Problem Record and communicate findings to the
Incident Management.
Identify action items that prevent or minimize future incidents from
reoccurring by eliminating the original cause. Identified action items may

Customer 4 Provide Input as Needed
Provide additional information and details to support IBM during the Root
Cause Analysis and resolution activities upon request.
IBM 5 Develop/Update RCA
Develop RCA, Identifying and involving any Customer or Customer third
parties resources that may be required for the RCA completion. Produce
RCA documentation for Customer acceptance. Update RCA document on the
Customer Service Management Tool and send it to the agreed Distribution list
Customer 6 Review RCA; Prepare Feedback & Provide Customer Acceptance or

Rejection
Review RCA, identify concerns and prepare feedback, supply the resources
needed for the RCA completion.
Provide RCA acceptance or rejection on the Service Management Customer
tool.
RCA acceptance on Customer Service Management tool: the RCA task
record status changes to “Close Complete” and Problem Record Status
changes to “Solution Plan Analysis”.
RCA rejection on Customer Service Management tool: the Problem record

status remains “Root Cause”.
If the RCA needs to be re-worked then the Customer rejects the Root Cause
and Supplier will develop the RCA and then resubmit to Customer for review.
If the Parties agree that the RCA is “Root Cause Not Found”. The supplier
documents the data as much as possible within the Root Cause Task and
then submits the Root Cause for Customer approval. The Problem Record will
then enter the Solution Plan phase.
IBM 7 Develop and provide Solution Plan

Develop the Solution Plan, identifying any actions may be required including
Customer’s actions. Based on the Customer feedback, update the Solution
Plan.
Update the Solution Plan on the Customer Service Management Tool and
submit for Customer approval.


Customer 8 Review Solution Plan; Prepare Feedback & Provide Customer
Acceptance or Rejection
Review the Solution Plan and provide approval, which may require Customer’s
activities.
Provide Solution Plan acceptance or Rejection on the Service Management

Customer tool.
Solution Plan acceptance: update on Customer Service Management tool the
Solution Plan task record status became “Close Completed” and Problem
Record Status with status “Verification”.
If the Solution Plan needs to be re-worked then the Customer rejects the
Solution Plan and Supplier will develop another Solution Plan and then
resubmit to Customer for review.
Once the Parties agree on the final Solution Plan then the Customer will
approve the Solution Plan. The Problem Record then moves to verification
status.
IBM 9 Verification State Activities: Customer resource needed?
If Yes, initiate required actions or requests to be completed by Customer.
If No, initiate required actions or requests to be completed by Supplier.
f No, proceed with the Solution Plans actions that do not require Customer
Resource if present.
Approved Solution Plan may require initiating requests to other IBM

processes, for example Change Management or Capacity Management.
(For policy on extension of the target closure date, see 2.4.8.)
Customer 10 Confirm Completed Customer Actions

If Customer actions are requested, provide confirmation to the initiating
process.


IBM 11 Complete Solution Plan Tasks
Monitor and complete the Solution Plan Tasks.
When Solution Plan is completed, and the Customer Confirm the Completion
in the Customer Service Management tool sets the Verification Task in status
“Close Complete”.
Solution Plan Tasks may include change records which are required to be
completed prior to the closure of the Verification Tasks.
Customer 12 Confirm Solution Plan Completed

Verify and approve the completeness of the Solution Plan and mark
verification task “Complete”, if confirmed.
If Solution Plan is not completed, then step back to #9.
IBM/Customer 13 Close Problem Record
The Problem Owner will process the records once both parties agree on
closure and closure codes.
The closure codes and descriptions are below:
o Successful - Root cause was successfully defined, solution tasks were

defined and completed.
o Root Cause Not Found - After analysis, teams are unable to
determine root cause. Solution Tasks (such as monitoring) should still
be defined if possible.
o Cancelled - This is an invalid problem record or a duplicate.
o Solution Not Feasible - Solution may not be within reason (expensive
or lengthy).
o Solution Not Found – Parties not find a solution.
o Partially Resolved - Root cause was defined but only partially
resolved; an example might be when there is a new, large project
starting soon that will replace the hardware or application.
(For related policies on Problem Analysis versus Problem Closure see 2.4.7.)
Modify the Problem Record Status to “Closed” and set the appropriate Close
code.

2.3.2. Escalating and Reporting on Problems

Figure 3 depicts the Escalating and Reporting on Problems flow diagram and the related interactions
between the Customer and IBM personnel.
Figure 3. Flow diagram for the Escalating and Reporting on Problems
Table 3 provides the summary for Customer and IBM interactions, consisting of key required actions,
interfacing roles, interaction methods, and the organization involvement for the Problem Management
process. The Organization Involvement column is used to specify the organization involvement for the
key required actions, (R=Responsible, I=Informed, C=Consulted, S=Supportive).
Table 3. Interface summary for Escalate and Report on Problems

flow # Action
Involvement
Customer IBM Custome IBM

r
PM201 Submit escalation Customer IBM Email/Meeting R I

request Focal Point
Integrated
Service
Manager
(SM)
PM202 Provide status Customer IBM Email/Meeting I R

report Focal Point Integrated
Service
Manager
(SM)
PM203 Provide feedback Customer IBM Meeting/Email R C

on the report Focal Point Integrated
Service
Manager
(SM)
PM204 Notify Requester Customer IBM Email I R

of completed Focal Point Integrated
actions and Service
schedule Manager
(SM)
Table 4 outlines the step-by-step narrative for the Escalating and Reporting on Problems process
flow.
Table 4. Narrative for the Escalate and Report on Problems

Customer 1 Submit Escalation Request
Identify those Problem records that require immediate action (via escalation)
contact the IBM ISM.
IBM 2 Investigate and track Progress of Problem Records
Review progress of Problem records by comparing their status against
expected targets and planned actions.
IBM 3 Escalation Required?
Determine if escalation is needed to address the lack of progress.
 If Yes, proceed to Perform Internal Hierarchic or Functional Escalation
as Needed
 If No, proceed to Produce Problem Reports


IBM 4 Perform Internal Hierarchic or Functional Escalation as Needed
Perform the appropriate hierarchic escalation (to levels of management) or
functional escalation (to subject matter experts) to confirm the undesirable
conditions are addressed so as to continue the Problem investigation or
known error resolution.
IBM 5 Perform Necessary Actions
Perform the appropriate action to expedite progress of the Problem record.
Engage relevant individuals/groups and key stakeholders where required.
Determine the urgency of each required action. These actions may be one, or
more, of the following:
 Correct the Problem priority
 Submit a priority reassessment to related processes (e.g. Change

Management)
IBM 6 Produce Report

Produce a status report on the Problem ticket, planned actions and target
timeframe.
Customer 7 Receive and Review Problem Reports
Receive and review the status reports and provide feedback.
IBM 8 Receive and Address Feedback
Address Customer feedback.
IBM 9 Notify Requester as Needed
Notify Requester of completed and planned actions.
Customer 10 Receive Notification
Receive notification of completed and planned actions.
2.4. Policies and Guidelines

Table 5 provides the list of policies that are used for IBM and Customer interactions throughout the
Problem Management process.

Table 5. Policies for interactions throughout the Problem Management Process
Policy # Section # Description

1 Error: Reference source Error: Reference source not found
not found
2 Error: Reference source RCA Error: Reference source not found
not found
3 2.4.3. Problem Priority
4 2.4.4. Escalation
5 2.4.5. Problem Accountability
6 Error: Reference source Unresolved Problem Policy
not found
7 2.4.7. Problem Analysis Completion versus Closure
8 2.4.8. Extension of Problem Closure Target Date
9 2.4.9. Misdirected Problem Assignments
1.
2.
2.1.
2.2.
2.3.
2.4.
2.4.1. Formal RCA Policies

A Formal RCA is an escalation step after the Root Cause Analysis referenced in the Problem
Management.
Criteria

A Formal Root Cause Analysis is required for:

 Incidents classified as P0 and P1 with unknown root cause
 Incidents that have led to IBM invocation of Major Incident Process, (For more information,
see Figure 4. Flow diagram for the Handle Critical Situation of PPIM Incident Management
Process)
 Special requests based on trend analysis, Service Level reviews or Problem analysis
requested by the business
 Failed Changes causing unplanned Customer outage
 Unauthorized Change
 Missed Service Level Agreement

Entitlement
The following roles can initiate a request for formal RCA:
 Customer Senior Focal Point
 Integrated Solution Manager (ISM)/Supplier Delivery Service Executive (SDSE)
Formal Documentation
The Formal RCA Documentation consists of a report, which includes but is not limited to the following
information:
 Problem Record identification #
 Incident/Change Record identification #
 Monitoring Event
 Detailed timeline of the Incident
 Affected Customers
 Customer impact
 Root Cause Analysis (5 Why’s)
 Contributing factors
 Completed Actions items
 Solution Plan (Actions to be approved and scheduled)

Expected Completion Date
Table 6 shows the Customer expected timeframe for Formal RCA completion.
For any P0 P1 IBM is requested to provide an RCA with the analysis of the issue root cause.

In case the analysis shows that the root cause is not in IBM scope, IBM shall at least provide in the
RCA a description of why the root cause is not under IBM responsibility.
Table 6. Expected RCA completion target date
Problem ID Characteristic Target Completion Date

1 Service commitment related P0 & P1 4 business days starting from the
incidents moment in which the activities are
assigned to IBM assignment group
2 Customer requests not related to P0 and 5 business days starting from the
P1 incidents moment in which the activities are
assigned to IBM assignment group
Any delay in the expected RCA target completion date is documented with appropriate business rational
and requires Customer’s agreement.
2.4.2. RCA Investigation and Documentation

Guidelines
Root cause is defined as the underlying or original cause of an incident or problem and once
eliminated or altered, will minimize or prevent the recurrence of incidents and problems.
Root Cause Analysis (RCA) is a structured activity performed to identify the root cause using the most
suitable technique or methodology. The parties have identified the 5 Why’s Methodology as the best
practice for Root Cause Analysis.
The results of a root cause analysis must be documented in the problem record on Customer Service
Management tool.
The Problem Owner will review and accept the results prior to communicating the information to
relevant parties.
Where root cause analysis was performed however the underlying cause of a problem could not be
identified, the assigned owner is to establish a mitigation plan or preventative measures to reduce the
impact of the unresolved problem so as to:
▪ Capture additional data to assist with root cause identification
▪ Prevent or minimize future incidents
If no workaround or root cause is found determine whether additional effort is required to be spent in
investigating the Problem.
The 'Five Whys' is the preferred method for root cause analysis. Take each presumptive cause and
ask 'why' continuously until you exhaust that line of questioning. The answer to the last ‘why’ should be
the root cause of the problem.
Why #1... why did the problem happen?
Why #2 ... why did #1 happen?
If there are multiple presumptive causes, you should complete the 'five whys' for each one.
Contributing factor(s) alone would not have caused the problem but are important enough to need
corrective action to improve the quality of process. They could also be items that made problem
determination or recovery more difficult.
Ask these questions to determine whether the Root Cause has been discovered or is it just a
Contributing Factor.
Root Cause? Contributing Factor?

If this item is fixed, will Yes No
it prevent the problem
from recurring?
Did this item delay No Yes
restoration of service
or recovery?
Did this item delay No Yes
problem
determination? Or
make it more difficult?
2.4.3. Problem Priority

Problem Priority is determined by the Incident Priority and Problem classification is based on Impact
and Urgency:
 Impact: the extent to which the Problem affects agreed-to or expected service levels
 Urgency: the speed with which the Problem needs to be resolved

Problem Priority can be modified based on the Parties approval.

Table 7 and Table 8 show the impact and urgency levels and characteristics, considered to classify
problems.
Table 7. Problem impact characteristics
Impact Characteristics
High  Problem detected pro-actively to prevent P0 or P1 Incidents
 The problem is related to reported P0 or P1 Incidents
Medium  Problem detected pro-actively to prevent P2 Incidents
 The problem is related to reported P2 Incidents
Low  Problem detected pro-actively to prevent P3 Incidents
 The problem is related to reported P3 Incidents
Table 8. Problem urgency characteristics
Urgency Characteristics
High  Related Incident/s highly likely to recur
Medium  Related Incident/s likely to recur
Low  Related Incident/s not likely to recur
Table 9 depicts 4 classification levels for Problem Priority, based on the assessed impact and urgency
levels:
 0 Critical
 1 High
 2 Medium
 3 Low

Table 9. Problem Priority matrix
IMPACT
Problem Priority calculation
High Medium Low
URGENCY High 0 1 2
Medium 1 2 3
Low 2 3 3
While priority 2 and 3 problem records may be created as part of a Continual Improvement cycle, the
Error: Reference source not found are applied to Priority 0 and Priority 1 problems.
2.4.4. Escalation
The objective of escalation is to provide additional attention and visibility to issues that have exceeded
predefined criteria, including but not limited to:
 Formal RCA not completed by the expected target date
 Planned action items are not scheduled or completed in accordance to the approved
Resolution Plan
 Problem is incorrectly prioritized
2.4.5. Problem Accountability

For each Problem Record, accountability must be established, so as to effectively manage a problem
through its lifecycle irrespective of geographical and/or organizational boundaries.
Accountability is established by assigning a problem record to the appropriate Problem Analyst/Support
Group.
There is only one accountable party for the resolution of a problem record at any given time, and that is
the problem analyst to which it is currently assigned.
▪ The problem analyst support group’s Manager, or a delegated queue manager, is accountable for the
Problem Records in the support group’s queue that are pending assignment to an individual Problem
Analyst (currently unassigned)
▪ Problem Record resolution accountability remains with the assigned Problem Analyst through closure
of that Problem Record, or until it is reassigned
Where accountability disputes cannot be resolved within service delivery teams and need to be
assigned to Customer Resolver Group, then the dispute is escalated to the Problem Manager for
guidance in resolving it.

Where the Problem Manager is unable to resolve assignment disputes for cross service provider
problems and/or for Customer Services providers, the Executive Governance Team from both parties
should be engaged to solve the assignment issue.
Problem Record accountability:
▪ The Problem Manager is accountable to monitor, track, and communicate / report on problems from
creation to closure
▪ The Problem Owner for a RCA is responsible for driving the RCA investigation across stakeholders,
and for completion of the RCA
▪ The assigned Problem Analyst is accountable and has the responsibility for determining &
documenting the Root Cause of a Problem as well as perform resolution activities & Problem Record
updates from assignment to re-assignment/closure
▪ The assigned Problem Analyst is responsible to invoke other processes (i.e. change management)
and engage other Problem Analysts/support groups to perform parallel activities, as required. Action
items may be assigned to other groups for completion, based on the analysis of the issue. Agreement
and acceptance of action item ownership is obtained from a group before preventative actions can be
assigned to that group.
▪ The accountability for the coordination of the resolution activities between multiple Problem
Analyst/support groups is that of the currently assigned Problem Analyst
Where a Third Party (i.e. Supplier or another Service Provider) is engaged in parallel activities and does
not have direct IT Service Management tool access, then the responsibility for ensuring updates to the
problem record remains with a support group that owns the relationship with the Third Party.
2.4.6. Unresolved Problem Policy

A problem remains unresolved where:
▪ The root cause of a problem was investigated but the underlying cause was not identified. Note:
Mitigation plans (including capturing of data), preventative measures, or workarounds may have been
put in place
▪ Root cause is identified, and a solution has been proposed, however the feasibility for implementing
the solution is not viable and an agreement is reached between Customer Liaison and IT Customer not
to resolve the known error and the ongoing risk is accepted by the IT Customer (business owner)
Where the problem remains unresolved a problem record may remain open for an agreed amount of
time. In some cases, the problem record may remain open indefinitely. This is to ensure any future
(recurring) incidents are identified, matched and tracked against the associated problem.

Unresolved problems must be reassessed prior to closure to identify where:
▪ Additional information has been captured to assist with root cause determination
▪ Incident count related to that problem has increased
▪ Existing Impact, urgency and priority of problem has changed
▪ Proposed solutions require reconsideration
Problem Owner must document the assessment outcome in the problem record.
Unresolved problem records that have remained open for a defined period of time (recommended
target: the agreed timing of the Solution Plan) will be reassessed by the Problem Owner for closure, in
consultation with the Customer Liaison. Problems with no recurring incidents or problems with no
possible resolution may be closed. Document the obtained approval from the Customer Liaison prior to
closing the problem record.
2.4.7. Problem Analysis Completion versus Closure

The analysis of a Problem is considered complete when:
 Root Cause of Problem has been identified
 All actions as defined as part of the RCA are implemented
 The problem record content has been validated, with all activities documented and known
error updated
 The resolution of the problem is confirmed by the problem owner
Completed Problem Records which have been closed with a code of successful and the solution plan
has been implemented should prevent any repeated incident related to the root cause.
Once a record has been closed any recurrence of the same or similar problem must be recorded as a
brand new problem and a relationship is established.
A problem record may be cancelled only where it was opened by mistake or duplicate records.
Prior to cancellation the reason must be documented in the problem record.
In case above listed criteria for problem record closure is not met, please follow unresolved problem
policy.

2.4.8. Extension of Problem Closure Target Date

If the permanent resolution cannot be achieved by the planned target date, the approved target date
can be extended. However, the rational for extending the target date must be documented.
Some appropriate examples for extending the Problem resolution and the closure target date are:
 Limited availability of hardware (e.g.: parts on order)
 Delay in development and release of software solution

For extension on an existing Customer approved date, the Customer must be informed and
Customer agreement must be obtained.
2.4.9. Misdirected Problem Assignments

If a misdirected Problem Record is received, the assignment error is reported to the Problem
Manager. It is the responsibility of the Problem Manager to reassign the Problem to the correct
group or request to the Customer the reassignment to a Customer Group.
2.5. Related Processes

Table 10 identifies the interfaces of the Problem Management process.
Table 10. Interfaces for the Problem Management process
Process Relationship
Availability Management Requests an RCA for availability issues
Capacity Management Requests an RCA for capacity issues
Request for Change is generated by Problem Management to
Change, Release and
deploy a Problem resolution and remove the root cause of an
Deployment Management
error
Provides relationship and status information to resolve Problems
Configuration Management
and identify other CIs that may need replacement or other action.
Provides information about how services have performed to help
Event Management Problem Management determine how to proactively resolve
Problems and errors before they occur

Process Relationship
Incident and Major Incident Requests RCA and workarounds from Problem Management to
Management restore service and avoid major outages
Provides Incident records used to identify Incident trends and
groups of related Incidents for proactive Problem Management
IT Process Governance
Establishes, maintains and improves the process as well as the
and Seven Step
related measurements and reports
Improvement
IT Service Continuity Problem Management often resolves Problems before they
Management. become major outages, avoiding invocation of ITSCM plans
Knowledge Management Manages knowledge bases that may be used by the process.
Demand Management Handles requests that require a proposal or nonstandard requests
(Work Request) for new or changed IBM services.
Service Level Management The proper resolution of Problems affects service levels
2.6. Referenced Documents

Table 11. Referenced documents
Document Document Title

Number
Not Applicable Drive IT GS Problem Management Process
2.7. Document Control

Summary of Changes
Table 12. Summary of changes
Rev Date Author Nature of Change

AR. April, 19 Elena Sigot Master Service Agreement Amended and
1.0 Restated (between FCA US LLC, FCA ITEM
and IBM) signature
AR. September, Paola Martinelli MSA AR Amendment #2 signature
1.1 20

Document Approvers
Table 13. Document approvers
Rev # Review Approval

Review by Approved by
Date Date
AR.1.0 April, 19 FCA ITEM PPIM May,19 Alberto Vaira (IBM Global DPE)
Focal Point: Giorgio Cagliera (Contract Manager FCA
Cristina Ulivi, FCA ITEM)
US PPIM Focal
Sandra Betanzos (Contract Manager FCA US
Point: Jeffrey
LLC)
Polcyn
AR 1.1 October,20 FCA ITEM PPIM October,20 Alberto Vaira (IBM Global DPE)
Focal Point: Silvia Giorgio Cagliera (Contract Manager FCA
Caffaratti, FCA US ITEM)
PPIM Focal Point:
Sandra Betanzos (Contract Manager FCA US
Holli Olejarczyk
LLC)
Document Signature
The Document has to be signed via Formal Correspondence
Document Review Plans

Necessary reviews and updates to this document are defined as follows:
 Following a regularly scheduled review for the PPIM
 As required to correct or enhance information content
How to Find the Latest Revision of this Document

The latest revision of this document may be obtained as follows:
 Amended and Restated Master Service Agreement Common Repository
 Master Customers Personnel: Contact the IBM Project Office for FCA ITEM and FCA US
LLC
Document Distribution and Notification:

 The original signed controlled copy is maintained by the IBM regulatory services
organization.
 Printed copies are for reference only and are not controlled.
 Obtain and use only the current, approved document.

End of Problem Management

Glossary
If the Glossary item is from ITIL model, a “ITIL® V4 Glossary” label is included for copyright purpose.
Term Definition
Configuration A Component that needs to be managed in order to deliver an IT Service.
Item (CI) Information about each CI is recorded in a Configuration Record within the
Configuration Management System and is maintained throughout its Lifecycle
by Configuration Management. CIs are under the control of Change
Management. CIs may include IT Services, hardware, software, buildings,
people and formal documentation such as process documentation and SLAs.
(ITIL® V4 Glossary)1
Escalation An activity that obtains additional resources when these are needed to meet
service level targets or Customer expectations. Escalation may be needed
within many IT service management processes but is most commonly
associated with Incident and Major Incident Management, Problem
Management and the management of Customer complaints. There are two
types of escalation, functional escalation and hierarchic escalation. (ITIL® V4
Glossary)
Fix An action that permanently solves an Incident or Problem. (ITIL® V4 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 are used to assign priority. (ITIL® V4 Glossary)
Incident An unplanned interruption to an IT service or a reduction in the Quality of an IT
service. Failure of a Configuration Item that has not yet impacted service is
also an Incident, for example, failure of one disk from a mirror set. (ITIL® V4
Glossary)
Incident Record A record containing the details of an Incident. Each Incident Record
documents the Lifecycle of a single Incident. (ITIL® V4 Glossary)
Knowledge A logical database containing the data used by the service Knowledge
Base Management System. (ITIL® V4 Glossary)
The database used to identify, create, distribute, share and enable users with
knowledge learned by others. Known workarounds, fixes and experience share
the wealth of known success.
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

Term Definition
Major Incident The highest category of impact for an Incident. A Major Incident results in
significant disruption to the business. (ITIL® V4 Glossary)
Local policy determines the criteria for declaring an Incident a Major Incident.
Operational An agreement between an IT service provider and another part of the same
Level organization. An OLA supports the IT service provider's delivery of IT services
Agreement to Customers. The OLA defines the goods or services to be provided and the
(OLA) responsibilities of both parties. For example, there could be an OLA
 Between the IT service provider and a procurement department to obtain
hardware in agreed times
 Between the Service Desk and a support group to provide Incident

resolution in agreed times
(ITIL® V4 Glossary)
Service Delivery An IBM role, the first focal point for the quality of service delivery
Manager (SDM)


FCA PPIM AR.1.1 Problem Management 2020 Clean Execution

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FCA PPIM AR.1.1 Problem Management 2020 Clean Execution

Uploaded by

Copyright:

Available Formats

Release AR.1.

1 FCA Problem Management Policies and Procedures Interfaces

IBM Strategic Outsourcing Delivery

Document Owner: Paola Martinelli

Owner : Alberto Vaira

Document Name: FCA PPIM Problem Management

Document Release: AR.1.1

Last Modified on: September 9,2020

Master version of document is stored in: Pag. 2 of 34

1.1 Document Structure................................................................................................................. 3

2.3 Problem Management Interface Procedures...........................................................................5

2.3.1 Problem Management Interface.......................................................................................... 5

2.3.2 Escalate and Report on Problems.....................................................................................11

2.4 Policies and Guidelines......................................................................................................... 13

2.4.1 Formal RCA Policies......................................................................................................... 13

2.4.2 RCA Investigation and Documentation Guidelines............................................................14

2.4.3 Problem Priority................................................................................................................. 16

2.4.5 Problem Accountability...................................................................................................... 17

2.4.6 Unresolved Problem Policy...............................................................................................18

2.4.7 Problem Analysis Completion versus Closure...................................................................18

2.4.8 Extension of Problem Closure Target Date.......................................................................18

2.4.9 Misdirected Problem Assignments....................................................................................19

2.4.10 Related Processes........................................................................................................ 19

2.5 Referenced Documents......................................................................................................... 20

2.6 Document Control.................................................................................................................. 20

Master version of document is stored in: Pag. 3 of 34

Master version of document is stored in: Pag. 4 of 34

1.1. Document Structure

Master version of document is stored in: Pag. 5 of 34

Annex documents specify customer-specific requirements (for example: Focal

Figure 1. PPIM document structure

PPIM chapters consist of two key document types:

Master version of document is stored in: Pag. 6 of 34

PPIM consists of two key document types:

Master version of document is stored in: Pag. 7 of 34

This scope includes but is not limited to the following:

 Midrange Systems Management Designated Services

Master version of document is stored in: Pag. 8 of 34

 Midrange Infrastructure On Demand Designated Services

 Midrange Infrastructure Full Box Optional New Services

 Storage and Backup Designated Services

 Messaging Designated Services

 Data Center and Facilities (EMEA DCSA)

 Cloud Operation Services

2.3. Problem Management Interface Procedures

2.3.1. Problem Management Interface

Master version of document is stored in: Pag. 9 of 34

Figure 2. Flow diagram for the Problem Management Interface process

Table 1. Interface summary for Problem Management

Interface Key Required Interfacing Roles Method Organization

Customer IBM Customer IBM

PM101 Submit ITIL Requester Problem Problem R I

Master version of document is stored in: Pag. 10 of 34

Interface Key Required Interfacing Roles Method Organization

Customer IBM Customer IBM

PM102 ITIL Requester Problem Problem I R

PM103 ITIL Requester Problem Meeting, R C

PM104 Provide/Update Problem Focal Problem Meeting, I R

PM105 Review RCA Problem Focal Problem Meeting/ R I

PM106 Provide/Update Problem Focal Problem Meeting, I R

PM107 Review Problem Focal Problem Meeting/ R I

Interface Key Required Interfacing Roles Method Organization

Customer IBM Customer IBM

PM108 Initiate Problem Focal Problem Meeting/ I R