Fujitsu Services
Process Details
POA Customer Service Problem Management
Company-in-Confidence
FUJ00079953
FUJ00079953
Ref: CS/PRD/021
Version: 6.0
Date: 29/07/05
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Originator & Dept:
Contributors:
Internal Distribution:
External Distribution:
Approval Authorities:
POA Customer Service Problem Management Process Details
Process Definition
N/A
This describes the Customer Service Problem Management
Process
APPROVED
Graham Mockridge - Service Transformation Manager.
Deirdre Conniss — Service Management Consultant
Nikki Hawkins, Mike Warren
Peter Thompson, Alex Kemp, Carl Marx, Tony Wicks, Mike
Woolgar,
Dean Felix,
Mockridge, Mick Lait, Mike Warren, Nikki Hawkins,
Tan Daniel,
Julie Welsh, Graham
Mik
Peach, Graham Welsh, John Budworth, Mike Stewart, Janet
Reynolds
(See PA/PRO/010 for Approval roles)
Name Position Signature Date
Carl Marx Service Management Team
Manager
Dave Baldwin Director Customer Services
Company-in-Confidence Page: I of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
0.0 Document Control
0.1 Document History
Version No. I Date Reason for Issue Associated
CP/PinICL
1.0 05/11/97 ICL Pathway Problem Management Process
11 16/04/98 Update
1.2 25/05/98 Update
13 19/07/98 Update
14 03/12/98 Update
1.5 02/04/99 Update
1.6 29/07/99 Updated following internal review and
comments
2.0 26/08/99 Stored in PVCS as “Version Complete”
2.1 15/05/00 Updated following a review of the CS Problem
Management Operation
3.0 13/11/00 Updated with comments from version 2.1, and
developed for approval.
3.1 19/11/01 Updated following annual process review, and
incorporation of the CS divisional alert process.
40 27/11/01 Updated with comments from review of version
3.1 and developed for approval
41 05/11/04 Updated with a complete rewrite of the Process
after workshops within the POA Support
Groups. To support the change in Post Office
Business for On-Line Services
5.0 20/01/05 Updated following internal review and
comments
5.1 7/4/05 Updated with new ITIL template and taking into
account new HSD and Problem Management
structure
5.2 5/5/05 Updated in light of comments, particularly in
reference to respective roles of IMT and PI.
Also two new types of problem resolution
identified.
6.0 02/08/05 For Approval
Company-in-Confidence Page: 2 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
0.2 Review Details
Review Comments by :
Review Comments to: I Deirdre Conniss
Mandatory Review Authority Name
Service Management Team Manager Carl Marx
Director Customer Services Dave Baldwin*
Business Service Manager Richard Brunskill
Service Delivery Team Manager Nikki Hawkins*
Optional Review / Issued for Information
Service Support Team Manager Peter Thompson
Network Service Manager Alex Kemp*
Business Continuity Manager Tony Wicks *
Service Delivery Team Manager Nikki Hawkins
Service Delivery Manager Mike Woolgar*
Service Delivery Manager Mike Stewart
Service Delivery Manager Dean Felix
Service Delivery Manager Julie Welsh
Service Delivery Manager Tan Daniel*
System Support Centre Manager Mik Peach*
Operations Manager Mick Lait
Head of Call Centres Commercial & PS Martin Croucher
Service Delivery Manager (Ops) Tan Cooley
Service Introduction Manager Graham Welsh
CS Release Manager John Budworth
CS Administration Manager Janet Reynolds
( * ) = Reviewers that returned comments
0.3. Associated Documents
Reference Version I Date Title Source
CS/IFS/008 POA/POL Interface I pvCs
Agreement for the Problem
Management Interface
Company-in-Confidence Page: 3 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
CS/PRD/074 POA Incident Management I pycs
Process
PA/PRO/001 Change Control Process PVCS
CS/QMS/001 Customer Service Policy I pycs
Manual
CS/PRD/122 POA Major Incident I pycs
Communication Process
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 Abbreviations/Definitions
Abbreviation Definition
cI Configuration Item
CMDB Configuration Management Database
cP Change Proposal
CSIP Continuous Service Improvement Plan
FAD Identifying code for a Post Office branch
HSD Horizon Service Desk
IMT Incident Management Team
KEL Known Error Log
MBCI Major Business Continuity Incident
MSU Management Support Unit
PI Problem Initiator
PM Problem Manager
PO Post Office
POA Post Office Account
POL Post Office Limited
PRB Problem Review Board
SDMs Service Delivery Managers
SDU Service Delivery Unit
SLA Service Level Agreement
SLT Service Level Target
SRF Service Review Forum
Ssc System Support Centre (Team responsible for 3“ line support applications)
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 4 of 47
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
0.5 Changes in this Version
Version Changes
6.0 Changes resolving typos plus making minor corrections.
0.6 Changes Expected
Changes
Changes following peer review. Further development of reporting.
Company-in-Confidence Page: 5 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
0.7 Table of Contents
1.0 INTRODUCTION...
1.1 PURPOSE.
1.2 OBJECTIV!
1.3. PROCESS OWNER...
2. SCOPE..
2.30 OUTPUTS...
2.4 CONTROL MECHANISMS.
2.5. SERVICE Hours..
3.0 RISKS AND DEPENDENCIES.
4.0 PROCESS FLOW. Al
4.1 LEVEL I PROBLEM MANAGEMENT PRO
42 LEVEL 2 PROBLEM MANAGEMENT PRO
4.2.1 Step 1a : Problems initiated from incident management.
4.2.2 Step 1: Problem Identification, Recording and Classification.
4.2.2 Step 2: Problem Investigation and Diagnosis.
4.2.3 Step 3: Decision on whether to resolve.
4.2.4 Step 4a: Impact minimal therefore resolution not cos
4.2.5 Step 4b: Impact not minimal but resolution not cost justifiable....... .
4.2.6 Step 4c: Problem needs linking to a release and can be deferred to the next major release........25
4.2.7 Step 4d: The problem needs linking to a release and should be resolved as soon as possible.....28
4.2.8 Step 4e: Resolution of problem is release independent but there is a potential impact on release... 30
4.2.8 Step 4f: Resolution of Problem is release independent and wholly financed by Customer Services 33
4.2.9 Step 4g: Resolution of problem requires expenditure from POL.... sees
4.2.10: Step 4h: Resolution of Problem requires action by POL.
4.2.10 Step 5: Problem Closure...
4.2.10 Step 6: Tracking and Monitoring of
4.2.11 Step 7: Trend Analysis..........
5.0 REPORTING ON THE PROBLEM MANAGEMENT PROCESS.
5.1 PURPOSE.
5.2 REPORT LIST.
APPENDIX A: CURRENT SCOPE OF SDM (PROBLEM MANAGER)
RESPONSIBILITY...
Problems and Errors...
APPENDIX B: TERMS OF REFERENCE OF PROBLEM REVIEW BOARD............ 45
B1: COMPOSITION...
B2: PURPOSE OF THE PROBLEM REVIEW BOARD.
B3: FREQUENCY. .....ceceeeeseseee
APPENDIX C MATRIX FOR ASSESSING BUSINESS IMPACT...
Company-in-Confidence Page: 6 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
APPENDIX D RULES FOR THE PI.
1.0 Introduction
1.1 Purpose
The purpose of this document is to define the process for Problem Management of the POA
environment. For the purpose of this document a Problem is defined as:
“The unknown underlying cause of one or more Incidents.”
1.2 Objectives
The primary goal of the Problem Management process is to minimise the adverse effect on the
business of Incidents and Problems caused by errors in the PO environment, and to proactively
prevent the recurrence of Incidents, Problems and errors. Problem Management focuses on
finding the root cause of Incidents, creating Known Errors and resolving these via the Change
Management process.
1.3 Process Owner
The owner of this process is the Service Delivery Team Manager. Responsibility for individual
problems is allocated to the specific Service Delivery Manager most affected by the problem,
who will act thereafter as the Problem Manager. The table in Appendix A shows the current
scope of each Service Delivery Manager’s responsibility. Where a problem spans several
services, and relates to the customer view of the service, the Problem Manager will be the
Service Delivery Team Manager. If there is no immediately obvious Service Delivery Manager
to manage a Problem, then the Service Delivery Team Manager will nominate the individual.
2. Scope
2.1. General
The process covers both the reactive and proactive functions of Problem Management.
The scope of the reactive function is from identification of a Problem to its closure and
includes root cause analysis, initiation of change requests and the provision of management
information to Fujitsu and POL. Note that a problem may be closed without being resolved,
where the resolution is judged not to be cost effective.
The scope of proactive Problem Management includes trend analysis, subsequent identification
and resolution of Problems and management of the Problem Management process itself.
Care needs to be taken within POA to distinguish a “Problem” from a “Major Incident”, since
old procedures controlled Major Incidents by defining them as Problems. Every Major
Incident will have a Problem record raised for it but this is only to ensure that the underlying
Company-in-Confidence Page: 7 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
cause of the incident is thoroughly aired and any recommendations from the Major Incident
report applied over time. Problems are handled essentially off-line and may take many days to
resolve. Incidents are handled quickly, the aim being to restore the customer’s service as soon
as possible.
2.2 Inputs
The inputs to this process are:
© Problem record initiated by the Service Desk following identification that no record exists
on the Knowledge datastore (KEL) for the specific circumstances associated with an
incident.
e Problem record raised by the Service Delivery Manager as the result of a direct request
from POL e.g. during monthly reviews or on the telephone. Note that the problem
management process interface for POL raised problems is covered in ref [1] .
¢ Problem record raised by the Service Delivery Manager as the result of a direct request
from an SDU, apart from Service Desk, who have noticed a trend which needs
investigation.
© Statistics for trend analysis
e Request for management information from Problem records
¢ Outputs from performance metrics where, for example, the SLT is at risk.
2.3, Outputs
The outputs from this process are:
A closed Problem
An entry in the KEL
A workaround
A permanent solution where commercially feasible
Contribution to a Continuous Service Improvement Plan (CSIP)
A CP and business case for proposal
A Problem referred to POL or a third party
An available Service or Component
Analysis of a trend report and recommendations for proactive change
Management Information
Proactive feedback and advice to users
Other proactive actions to reduce the number of Incidents
eoerereec ee ece ee
2.4 Control Mechanisms
The measures that apply to this service are:
e¢ Number and impact of similar Incidents occurring after a Problem is recorded before a
resolution or workaround is available
¢ Total number of Incidents reported to the Service Desk
¢ Caseload of Problem Managers.
¢ No of Problems by SDU, service and application
Company-in-Confidence Page: 8 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
2.5 Service Hours
Although a problem may be identified at any time, the management of problems is essentially
conducted during office hours i.e. 09:00 to 17:30 Monday to Friday excluding Bank Holidays.
3.0 Ri
s and Dependencies
3.1 Risks
The following define the risks to the successful delivery of the process:
e Break in the communications chain to third parties. Mitigation is to invoke escalation
procedures
e Resistance by parties to carry out pro-active recommendations to reduce number of
Incidents. Mitigation is to escalate to senior management
¢ Commercial constraints. These would need to be analysed on an individual basis to decide
on the most commercially acceptable option
e Increased business and operational impact through lack of Problem progress updates to
POL.
Unavailability of sufficient support unit staff
Unavailability of sufficient tools for problem diagnosis
Non-availability of KEL or call management systems
The provision of inadequate staff training
Unavailability of systems for evidence gathering
Loss of any infrastructure component which links support systems to the live estate
eoceceee
3.2. Dependencies
This process is dependent on:
e Effective routing of Problems to SDUs and third parties
e Effective escalation procedures within Fujitsu, POL and third parties
e POL acceptance of feedback, contributing to end user education and reduced Incident
rates
e Effective collaboration diagnosis between SDU’s and third parties
Company-in-Confidence Page: 9 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
Problem database implemented within 2 physical
databases. Powerhelp holds the main Problem
database, which will have an entry for every
problem. PEAK (primarily for software problems)
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.0 Process Flow
4.1 Level 1 Problem Management Process
I KEV/HSDOne I}
Problem Identification,
lap! Recording & Classification
Problem Investigation I
Tracking & and Diagnosis trend
Monitoring of Problem re Analysis
Problems “> Database 1, Decision on whether to I ysl
+> resolve
"I Problem resolution (5 >I
possible types)
> Problem Closure <>
KEL datastore is a reference point
holds detailed information on error investigation
and diagnosis and root cause analysis.
for HSD, primarily relating to
software known errors and prepared
for them by SSC team. HSDOne is a
further KEL to which HSD have
added other information required by
HSD agents
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 10 of 47
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Version: 6.0
Company-in-Confidence Date: 29/07/05
FUJ00079953
FUJ00079953
4.2 Level 2 Problem Management Processes
4.2.1 Step 1a: Problems initiated from incident management
Responsible: Service Desk(IMT) and Problem Initiator (PI)
An incident is raised and there is no KEL entry for the symptoms. It is
sent to an SDU for root cause analysis. Multiple occurrences of the
incident start to occur. A call is raised against which to link all further
occurrences of the call : the Master FAD call (Detailed incident
Management procedures)
1
IMT alert Problem Initiator to existence of potential problem. N.B.
Chronologically this should occur when the call is sent to the SDU. In
practice where there are a number of calls being received on this
particular topic, the master FAD call may be raised before the problem
is alerted. There is no dependency between the Incident and Problem
Management processes. The call will be alerted as a potential
problem as soon as possible but it is the resolution of the incident
which takes priority.
Go to
Step 2
This section is not part of the Problem Management Process. It is part of the detailed
Procedures associated with the Incident Management Process. It is included to link the two
processes.
Company-in-Confidence Page: 11 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.2 Step 1: Problem Identification, Recording and Classification
Responsible: Service Desk, SDU’s, Service Management, POL
Input
from 1A
( spu» SDMs (pot) ( Problem) Rules for
XN . - Initator __I problem
creation
Create
problem record
v
I Alert SDM to existence of potential problem
¥
SDM (Appropriate Problem Manager) approves
creation of problem Notify SDM of
Problem
SDM requests PI to create problem OR creates Creation
problem themselves and alerts PI to creation of
problem.
vy vw
Go to Go to
Step 2 Step 2
Steps
1.1 A Problem may be initiated by the following:
e The Problem Initiator (PI) noting that a multiple Incident has occurred.
e The IMT noting that there is no KEL entry to cover the specific
circumstances of an incident and alerting the PI
e The Service Delivery Units may identify Problems, from either noting that a
multiple Incident has occurred or that the root cause of an Incident is
required, following the restoration of a service after applying a temporary
workaround.
e Problems may be identified following an analysis of trends by SDUs, the
Service Desk, Service Delivery Managers etc., which require the underlying
cause to be found.
e Either POL or Fujitsu Service Management may become or be made aware
of situations which identify a Problem.
Tf contacted by the IMT, the PI will use the Rules to determine whether it is
appropriate to raise a problem. If in doubt the PI should contact the Service
Delivery Manager and request approval to raise a Problem by telephone. On
Company-in-Confidence Page: 12 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
receipt of approval or when the issue conforms to the rules for Problem raising, the
Problem Initiator will raise a Problem record.
If POL wish a problem to be raised, they will discuss initiation with the Service
Delivery Manager and on acceptance of the problem, the Service Delivery
Manager will raise a Problem record and notify the PI that they have done so.
Alternatively they may contact the PI and request them to raise it on their behalf. .
If the SDU (including 3" party suppliers) wish to raise a problem, they will discuss it
with the appropriate Service Delivery Manager, who will create the Problem
record on their behalf or ensure that the PI does so.
Note that care needs to be taken on the definition of a problem and its title, as this will
be crucial in determining further occurrences of it. For example, ifa series of
branches have a problem where SLT targets for breakfix are exceeded due to poor
quality spares, it is important that the incident is identified as being a problem with
the SPARES not with BRANCHES failing SLT targets for speed of turnaround.
Note also that the Problem Initiator is normally co-located with the IMT team. In the
event of the PI’s illness or absence, that role will be performed someone from the
CS Administration team.
Company-in-Confidence Page: 13 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services
FUJ00079953
FUJ00079953
POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
The Problem is classified by assigning a severity level according to urgency and
impact. While the Incident is open, the severity will match that of the Incident.
However, if the Problem has been raised to provide the underlying cause of an
Incident to which a temporary workaround has been applied, the severity may
be lower. Note also that “MBCTI” and “Major Incident” relate to classifications
of incidents. However they are included here, as such incidents should always
generate an examination of root cause and determination of action to prevent
recurrence.
Note that once a problem reference has been generated and is available to
attach to, HSD should attach the Master FAD call to the Problem record.
Further occurrences should continue to be attached to the Master FAD call.
There is no target for the creation of the Problem Record, attachment of the Master
FAD call to the Problem record. However it is expected that all the steps will be
completed within one working day of the problem record being created.
Severity I Importance I Definition
MBCI e System outage which prevents the supply of one or more
services to a number of post offices
Major e A system outage which has the potential, if not resolved, to
Incident lead to an MBCI
A Critical e BUSINESS STOPPED, a Post Office down, unable to
process any business.
B Major e BUSINESS RESTRICTED, a Post Office restricted in its
ability to transact business, e.g. one counter down.
Cc Medium e NON-CRITICAL, a Post Office working normally but with a
known disability, e.g. an interim solution (workaround) has
been provided.
D Low e INTERNAL, an internal HSD/SMC problem, e.g. a help desk
PC or a phone set inoperable.
Note that neither MBCI nor Major incident is reflected in Powerhelp or PEAK. Such a status
is simply the trigger for the process steps outlined in ref [5]
Problems identified outside normal office hours
The PI only provides the service 09:00 to 17:30. Any potential problems identified outside
those hours should be communicated to the PI or the SDM at the earliest possible time i.e. the
next working day.
Company-in-Confidence Page: 14 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.2 Step 2: Problem Investigation and Diagnosis
Responsible: Service Delivery Managers, SDU’s, POL, third parties
From
Step 1
SDM Collects Business Impact of Problem, consulting POL,as
appropriate
SDM decides what alert triggers he/she wants and updates KEL
(Frequency provided by IMT attaching new occurrences to the Master
FAD call)
SDUs collect technical data on problem and perform root cause
analysis. This may be at the explicit request of the SDM or on their
own initiative. The SDM monitors progress on PEAK.
1
SDUs and other parties diagnose root cause and define outline
resolution
l
Go to
Step 3
Steps
2.1 The SDM identifies the initial business impact of the problem and decides what he wants
as triggers for alerting. For example, for one problem he might want to know as soon as
there was a recurrence. With another, he might only want to be notified when there were
12 in one day. The SDM should update the KEL to provide this information for the IMT.
Note that if this information is not provided, the IMT will not notify any surge in incident
occurrence. Note also that the business impact may change over time if more incidents
occur, as a direct result of the underlying problem not being fixed. IMT will continue to
link any new occurrences to the Master FAD call, as they occur. They will also contact
the PI, if the triggers set by the SDM on the KEL are tripped. The SDM will consult POL
as appropriate. In some cases, this may not be necessary (the business impact of an MBCI
is to some extent pre-determined). However the SDM should always consult POL, where
the problem has an impact on the daily working practices of Post-masters or relates to a
“Problem Branch”.
Company-in-Confidence Page: 15 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Business impact is measured against the following parameters:
e Total number of incident calls associated with the problem
e¢ Whether the problem is disabling a specific outlet or preventing it from trading and
whether there are alternatives to that branch in the locality.
e Whether the problem is disabling a high performance outlet or preventing it from
trading
e Whether the problem is disabling a nation-wide service or affecting a specific
service over a distinct geographical area
e Whether there is a workaround, which enables the Post Master to circumvent the
problem without affecting his business flow. Note that the workaround must be
acceptable to the Post Master. In this context, a workaround, which disables the
counter for 5 minutes, is unlikely to be acceptable
e Whether the problem is likely to bring POL HQ into disrepute e.g. articles in the
Press, Postmaster has contacted M.P.
Note that the above parameters are intended to provide RELATIVE Business impact. It is not
intended to imply that a single disabled outlet, where there are alternatives, can be left disabled
indefinitely. Business Impact is defined in more detail in Appendix C
2.2 Details of the Problem are gathered by the responsible SDU or third party from wherever
is relevant, e.g. Incident Management, the person logging the Incident, the CMDB, other
SDUs. The information is then used to diagnose the problem and find the root cause. If
difficulties are encountered, the SDU escalates the issue to the SDM. The work done to
establish root cause may be performed at the explicit request of the SDM, in which case,
updates may be applied directly to the Problem record by the SDM. It may also be
performed on their own initiative by the SDU, because for example, they need the
information to resolve the incident. The SDM will monitor the PEAK system to view
progress and summarise the information on the problem record on Powerhelp.
2.3 From this investigation the SDU decides what would be required for a permanent
resolution, including the following information:
© Root cause analysis of the problem
© One or more permanent resolutions to the problem
¢ Outline indications of the resource required for each resolution option,
which may be expressed in financial terms or human resource terms but
should be readily convertible to financial impact.
e Impact on the SDU to resolve the problem
e Estimated impact on the user: Note that this is not a duplicate of the
business impact already collected. It provides a technical view of what the
user will be able or unable to do.
e Estimated impact on operations
Company-in-Confidence Page: 16 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
e Risk of applying resolution to problem (risks identified for each option, if
there are more than one)
© Cost of not-resolving a problem
¢ Cost of conformance as opposed to non-conformance
¢ Suggested best time for implementation: e.g. in relation to releases or
operational exercises already planned with which this change could
coincide. With application code, this will always be a Release reference.
e Any other relevant information e.g. this component becomes redundant in
six months time, therefore less incentive in fixing problem.
Note that it is possible for a problem to be resolved without going through a formal process of
agreement to resolve e.g. root cause analysis is quickly established, resolution is clear and
simple, business impact is severe and a testing environment is immediately available for the
resolution to be tested. In such cases, there is no need for the SDM to do more than record
this on the Problem record.
2.4. Subject to the above, the SDM will make an assessment, which will cover the
following areas:
¢ Severity and Business impact of the problem
© Cost of the resolution
¢ Risk of the technical solution
e Impact if any on POA implementation programmes
e If relevant, long term viability of the solution e.g component shortly to
become redundant.
e Whether the problem needs to be fixed immediately or in the medium to
long term.
Company-in-Confidence Page: 17 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.3 Step 3: Decision on whether to resolve
Responsible: Service Delivery Manager
Escalation Route: Problem Review Board
From
Step 2
; Y Service Delivery
Expenditure or Team Manager
issues? » submits problem to
7 7 Problem Review
- N Board
Problem Review Board
rs ‘
SDM Decides on makes decision
Outcome
¥ ¥
Y v ¥ ¥ v y v
Go to Go to Go to Go to Go to Go to Go to I Go to I
Step 4a’ \Step 4b Step 4c’ \Step 4d’ \Step 4e’ \ Step 4f Step 4g Step
4h
Steps
3.1 At this point, the SDM decides whether or not he believes the problem must be
resolved. He should take into account the business impact and in particular any
input provided by POL PM. POL PM should always be consulted where the
SDM’s judgement is that the problem needs to be resolved but should be
deferred to the next major release rather than being resolved immediately.
There are seven possible outcomes:
.
.
.
major release
on release e.g. contention for test rigs.
Impact of problem is minimal, therefore resolution is not cost justifiable
Impact of problem is not minimal but resolution is not cost effective
The problem is release connected and should be resolved in a specific
The problem is release connected and should be resolved immediately
The problem itself is release independent but resolving it has an impact
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 18 of 47
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
3.2
33
3.4
e The problem is entirely release independent and can be financed entirely
by Customer Services.
e The resolution of the problem requires financing by POL
e The problem requires action by POL to resolve it.
The SDM may also identify at this point, that the proposal needs the explicit
support of senior management within Customer Services. The following list is
not exhaustive but indicates where escalation is appropriate:
¢ Resolution of the problem requires capital expenditure to be allocated
e Resolution of the problem may require a delay to a release
e POL have requested urgent resolution to a problem, but indications are that
the resolution cannot be fitted into the next release
¢ POL have requested resolution of a problem but the SDM’s judgement is
that the resolution is not cost effective
e Significant investment by POL is required to resolve a problem, there is
evidence that they are unlikely to approve it and there is a knock-on effect
on POA Operations
The SDM will prepare a formal assessment of the problem, including the elements
defined at Paragraph 2.3.and pass the problem to the Service Delivery Team
Manager, who will submit it to the Problem Review Board, whose Terms of
reference are described in Appendix B. They will decide on the most appropriate
action. In addition to the above, this may include tabling the problem at the SRF
for further high-level discussion with POL.
If the SDM has a problem which requires urgent resolution and where expenditure
will need to be authorised by the Problem Review Board, he/she should escalate to
the Service Delivery Team Manager and he/she will make a decision on whether it
is appropriate to convene a special meeting of the Problem Review Board to
discuss the issue.
Company-in-Confidence Page: 19 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services POA Customer Service Problem Management Ref:
Process Details
Version:
Company-in-Confidence Date:
CS/PRD/021
6.0
29/07/05
FUJ00079953
FUJ00079953
4.2.4 Step 4a: Impact minimal therefore resolution not cost justifiable
Responsible: Service Delivery Manager
Escalation: Problem Review Board
From To
St Step
ep 3
3
LL?
MZ
SDM contacts originator
Y
Y
More
information?
N
v
Make problem dormant
¥
Further Y > IMT link occurrences to
occurrences? Master FAD call
N
¥
Re-examine problem during major release or quarterly review
v
N
Problem redundant
Y
Go to
Step 5
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 20 of 47
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps
4.1 SDM contacts the originator of the problem and lets them know their decision (or the
Problem Review Board’s decision if it has been escalated). It is possible that this will result in
the discovery of information, which would make it more important to resolve the problem. In
such a case, the SDM may either decide to go ahead with the resolution based on the new
evidence or re-submit it to the PRB, if it was their decision not to proceed with it.
4.2 The problem will become dormant, i.e. it will be monitored but no active steps will be
taken to resolve it. The following events need to take place, before the SDM can leave it:
e Ifthe problem is also registered on the PEAK system as an error, the SDM will ensure
that the PEAK record has been updated with a progress indicating that the problem
record is now only being monitored. . No other updates should be made on the subject
of resolving it.
e The SDM will decide what frequency of incidents will cause the dormant problem to
be re-activated and ensure that this is documented on the KEL record. This is expected
to vary widely from problem to problem.
New incidents, which are occurrences of the problem will be attached to the Master FAD call
as they occur and before being closed.
4.3 Before each major release the problem will be examined to determine if it is no longer
relevant. If there are no major releases within a year, the problem should be examined at least
quarterly and assessed for closure.
Company-in-Confidence Page: 21 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
FUJ00079953
FUJ00079953
4.2.5 Step 4b: Impact not minimal but resolution not cost justifiable
Responsible: Service Delivery Manager, POL Problem Manager
Escalation: Problem Review Board
aan To
tep 3 Step
v a
SDM contacts POL
v
Acceptable not to
resolve?
Ff Y
Make problem dormant
«
ao IMT link
7 ° Y .I occurrences to
Further occurrences? > Master FAD
call
N
¥ ¥
Re-examine problem during major release or quarterly
review
v
N
Problem
redundant
Company-in-Confidence Page: 22 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps
4.1 SDM contacts POL Problem Manager and discusses with them the relative importance of
business impact over cost justification. If POL Problem Manager does not agree to let the
problem go unresolved, the SDM should refer it to the Problem Review Board.
4.2 Providing that POL Problem Manager agrees, the problem will become dormant ie. it will
be monitored only. No active steps will be taken to resolve it
The following events need to take place, before the SDM can leave it:
e Ifthe problem is also registered on the PEAK system, the SDM will ensure that the
PEAK record has been updated with a progress indicating that the problem record is
now dormant. No other updates should be made on the subject of resolving it.
© The SDM will decide what frequency of incidents will cause the dormant problem to
be re-activated and ensure that this is documented on the KEL record. This is expected
to vary widely from problem to problem.
New incidents, which are occurrences of the problem will be attached to the Master FAD call
as they occur and before being closed.
4.3 Before each major release the problem will be examined to determine if it would no longer
apply. If there are no major releases within a year, the problem should be examined at least
quarterly and assessed for closure.
Company-in-Confidence Page: 23 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
POA Customer Service Problem Management Ref: CS/PRD/021
Fujitsu Services
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.6 Step 4c: Problem needs linking to a release and can be deferred to the
next major release.
Responsible: Service Delivery Manager
Escalation: Problem Review Board
From
To Step 3
Step ~ More cy
Sr o—
3 occurrences?
SDM Y cp \N
CP SF required? Link occurrenées to
oT. Master FAD call
Change
Management
approval process I
y I SDM agrees way forward with
N cp Y Service Introduction Manager
_ approved t
2
Service Introduction Manager monitors
release to ensure required problems
included. Alerts SDM of any issues.
y
SDM resolves issues
Development, testing and Release Management
Process for releases
Go to
Step 5
Company-in-Confidence Page: 24 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps
4.1 If the resolution requires a change in the fundamental design of the software or the
introduction of new hardware/software/ functionality, a CP will be required. The SDM
should prepare and sponsor the CP on behalf of Customer Services , using the
information already collected.
4.2. The SDM will liaise with the Service Introduction Manager to ensure that the
resolution is included in the next release and supply him/her with all the necessary data
on the business impact of the issue. Issues associated with inclusion of the resolution in
the next release should be escalated to the Problem Review Board.
4.3 The SDM is responsible for a list of problems, relating to his/her area of
responsibility. This list should include the business impact for each problem and the
release to which it is attached. The Problem Manager has the responsibility of ensuring
that the Service Introduction Manager has access to the list.
4.4 It is the responsibility of the Service Introduction Manager to alert the SDM’s to
any potential issues with the resolution of problems being taken out of releases
Subject to the agreement of the specific SDM, the Service Introduction Manager may
negotiate on his/her behalf on the inclusion or otherwise in a release. It remains the
responsibility of the SDM to ensure that the resolution to a particular problem is
included in a release, if that is the business requirement.
4.5 It is the responsibility of the SDM to:
e Record on the Problem database, which release the resolution has been
allocated to
e Ensure that the Service Introduction Manager for that specific release is aware
that a new problem resolution has been included in the release by the
development team.
N.B. Where a problem with application code is a “late entrant” to a release, it is possible that a
later release will already be in preparation and therefore the Service Introduction Manager for
the later release will have to be notified too.
4.6 The progression and implementation of the change will follow the normal Change
Management and Release Management Processes.
4.7 While development is pending, the problem record will stay open. Any further
occurrences of the problem reported as incidents, should be linked to the Master
FAD call by the IMT before they are closed, so as to keep a frequency record.
4.8 When the resolution is implemented, the following tasks will be performed:
e KEL record will be amended to record that a resolution of the problem is
being implemented and the expected completion date of the
implementation.
Company-in-Confidence Page: 25 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
e The originator of the problem (unless it has been originated by IMT) is
informed that a resolution to the problem has been implemented
e The problem record is updated to show that a resolution to the problem
has been implemented.
e An estimate is made by the SDM as to how long a problem record should
remain open before being permanently closed. As a general rule this will
be three months after the resolution has been applied. In cases where the
problem relates to a specific event e.g change of time-zones or resilience
in the event of high order comms failure due to poor weather, it may be
necessary to leave the problem open longer. It is also open to the SDM to
decide that the problem can be closed earlier.
Company-in-Confidence Page: 26 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.7 Step 4d: The problem needs linking to a release and should be
resolved as soon as possible.
Responsible: Service Delivery Manager
Escalation: Problem Review Board
To ae m
te
Step 7 P , Y
3 More
+” occurrences?
n Oo
>?
y I Link
a. occurrences to
SDM alerts RMF that urgent change in pipeline Master FAD
and establishes sensible timescales call
y
; N :
Y r
Issues preventing~
N
ired?
implementation ?.~” CPrequired? >
ft
SDM raises CP
Change
Management
‘ Y
CP approved? >
v
Development, testing and Release
Management Process for R releases
v
Go to
Step 5
Company-in-Confidence Page: 27 of 47
©Copyright Fujitsu Services Limited 2004
FU.
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
FUJ00079953
IJ00079953
Steps
4.1 If the resolution specifically relates to a software fault, the SDM will liaise with
the Release Management Forum to ensure that the resolution is included in the
next R release. It is expected that this will be via the SSC Team Manager, who
will present the business impact provided by the SDM to the RMF. Where the
SDM wishes to do so, they may attend the RMF in person. The SDM’s will be on
the circulation list for RMF minutes. Issues associated with inclusion of the
resolution in the next R release should be escalated to the Problem Review
Board.
4.3 If the resolution requires a change in the fundamental design of the software or the
introduction of new hardware/software/ functionality, a CP will be required. The
SDM should initiate the CP on behalf of Customer Services, using the information
already collected.
4.4 While development is pending, the problem record will stay open. Any further
occurrences of the problem reported as incidents, should be linked to the Master
FAD call before being closed, so as to keep a frequency record.
4.5 Development and implementation of the resolution will follow the Release
Management Process. The Release Manager should escalate to the relevant SDM if.
there is any issue, which is likely to prevent the resolution of the problem being
delivered in expected timescales.
4.6 When the resolution is implemented, the following tasks will be performed:
e KEL record will be amended to record that a resolution of the problem is
being implemented and the expected date of completion of
implementation
¢ The originator of the problem is informed that a resolution to the problem
is being implemented
e The problem record is updated to show that a resolution to the problem is
being implemented.
Company-in-Confidence Page: 28 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.8 Step 4e: Resolution of problem is release independent but there is a
potential impact on release
Resolution: Service Delivery Manager
Escalation: Problem Review Board
From
To Step 3
Step More
a
3 t Ny occurrences?
Y
Problem Review Board reserve
funding and resources including
Project Manager
Link
Service Introduction Manager brokers occurrences to
issue on behalf of Problem Manager Master FAD
I call
N
CP required?
YY
SDM raises CP I
Change Management
approval process
.
CP approved?
Y
¥
Project Planning, Project Implementation run via
Release Management Process
Go to
Step 5
Company-in-Confidence Page: 29 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps
4.1 An example of this type of issue is where the resolution is release independent but
requires testing on a test rig, which is already fully booked for testing on a major
release and therefore the testing may impact release plans. If the resolution requires a
change in the fundamental design of the software or the introduction of new
hardware/software/ functionality, a CP will be required. It is important that any issue
affecting release is aired and resolved before substantial steps are taken to implement
The SDM may prepare and sponsor the CP on behalf of Customer Services , using the
information already collected but should not submit it into PVCS until any potential
clashes for resources are resolved.
4.2. The Service Introduction Manager will broker any issues on behalf of the Problem
Manager and/or Project Manager. Prior to the CP, it may not be possible to get a
formal commitment to resolve the issue but the change should not be proceeded with
unless the issue has been informally resolved with those people who have the power to
make the resolution work. Particularly where the resolution involves out of hours
work , the person owning the human resource must be consulted to confirm that the
resolution is acceptable to them.
4.3 The SDM will liaise with the Service Introduction Manager to ensure that the
dependency is resolved and supply him/her with all the necessary data on the business
impact of the problem. Any issues associated with this should be escalated to the
Problem Review Board.
4.4 It is the responsibility of the Service Introduction Manager to alert the SDM’s to
any potential issues with the resolution of the problem. The progression and
implementation of the change will follow the normal Change Management and Release
Management Processes.
4.5 While development is pending, the problem record will stay open. Any further
occurrences of the problem reported as incidents, should be linked to the Master
FAD call by the IMT before they are closed, so as to keep a frequency record.
4.6 When the resolution is implemented, the following tasks will be performed:
e KEL record will be amended to record that a resolution of the problem is
being implemented and the expected completion date of the
implementation.
e The originator of the problem, unless originated by the PI is informed that
a resolution to the problem has been implemented
e The problem record is updated to show that a resolution to the problem
has been implemented.
e An estimate is made by the SDM as to how long a problem record should
remain open before being permanently closed. As a general rule this will
be three months after the resolution has been applied. In cases where the
problem relates to a specific event e.g change of time-zones or resilience
Company-in-Confidence Page: 30 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
in the event of high order comms failure due to poor weather, it may be
necessary to leave the problem open longer. It is also open to the SDM to
decide that the problem can be closed earlier.
Company-in-Confidence Page: 31 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.8 Step 4f: Resolution of Problem is release independent and wholly
financed by Customer Services
Responsible: Problem Review Board, SDM, Project Manager (if not SDM)
Escalation: Problem Review Board
From
Step 3
To tep
Y
Step More
3 TN occurrences?
Problem Review Board reserve
funding and resources including - +
- Link
Project Manager
occurrences to
y Master FAD
call
CP required? —
N
Y
SDM raises CP
Change Management
approval process
N - Y
—— CP approved?
Project Planning, Project Implementation run via
Release Management Process
Go to
Step 5
Company-in-Confidence Page: 32 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps:
4.1 Problem Review Board allocates resource and defines a Project Manager to own
implementation project (who may be the SDM).
4.2 The SDM should initiate any required CP on behalf of Customer Services , using
the information already collected.
4.3 Project Manager (if they are separate individuals) reports back to SDM on
progress of project.
4.4 Change Management and Release Management process is followed.
4.5 Project Manager manages implementation.
Company-in-Confidence Page: 33 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services
POA Customer Service Problem Management
Process Details
Company-in-Confidence
Ref: CS/PRD/021
Version: 6.0
Date: 29/07/05
FUJ00079953
FUJ00079953
4.2.9 Step 4g: Resolution of problem requires expenditure from POL
Responsible: Service Delivery Manager
Escalation: Problem Review Board
To appropriate
Step 4 to
create CP (opt)
and develop/
implement.
Consult with Account Manager and agree approach
From
Step 3
¥
¥
I Discuss proposal with POL
y
Y
~<_ POL agree in principle? ~~
yN
Escalate to Problem Review Board
¥.
_ FJto finance? _
N
¥
Put problem into monitor status
¥
Review on regular cycle to determine if still relevant.
x
N
Problem ~
redundant?
Y
y
Go to
Step 5
NON
More
occurrences?
:
Link
occurrences to
Master FAD
call
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 34 of 47
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps:
4.1 The SDM should alert the Account Manager to the issue and agree an approach to
POL. This may involve:
e Gaining agreement with the POL budget holder via the Service Review Forum
or via the SDM’s personal contacts within POL.
e Gaining agreement with the POL budget holder via the Account Manager’s
regular contacts
Note in each case, the agreement with POL at this stage is likely to be without
prejudice, and no development work should start until POL have formally confirmed
via acceptance of the CP that they are prepared to finance the work.
4.2. If POL agrees to the expenditure, the SDM should initiate any required CP on
behalf of Customer Services , using the information already collected and following
approval, the CP will be submitted to POL for an order following the standard change
management procedure.
4.3. If POL indicates that they are not prepared to finance the work, the SDM should
refer the request back to the Problem Review Board. They may decide the following:
e Request for POL to finance should be escalated
¢ The work should be financed by Fujitsu (in which case, the problem falls into
one of the preceding categories of Step 4)
e The problem should be closed ( go to step 5)
4.4 Escalation should be to Service Management Team Manager initially and thence to
Customer Services Director. On conclusion of negotiations with POL, the
following outcomes are possible:
¢ Work should be financed by Fujitsu (in which case, the problem falls into one
of the preceding categories of Step 4)
e Problem should become dormant but be monitored for its ongoing impact.
4.5. While the financing of the resolution is being discussed, occurrences of the
problem will continue to be collected by HSD and the SDM will use the ongoing data
to inform all parties on the business impact of the problem.
Company-in-Confidence Page: 35 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
FUJ00079953
FUJ00079953
4.2.10: Step 4h: Resolution of Problem requires action by POL
Responsible: Service Delivery Manager
Escalation: Problem Review Board
From
Step 3 L
¥.
N More
occurrences?
Raise Problem with
POL
v Y
Add to Master FAD
call
¥
por WN
Resolution too
slow?
“I
Escalate to Problem
Review Board
v
POL resolve
problem
Dotted line indicates that process
Go to I is managed via Problem
Step 5 Management Interface process
- with POL
Company-in-Confidence Page: 36 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Steps:
4.1. SDM should contact the POL Problem Manager and raise a Problem with POL. The
process is documented in reference [1].
4.2. Pending resolution of the problem, occurrences will continue to be collected via HSD
and the SDM will use this ongoing data to inform the discussion with POL.
4.3. If the SDM judges that the progress made by POL in resolving the problem is slow
in relation to its business impact, then the SDM should escalate the issue to the Service
Delivery Team Manager, who will bring it before the Problem Review Board.
4.4, The SDM is the primary contact point for any POL implementation plans. If any such
plans impact POA release plans, the SDM is responsible for letting the Release Manager
or the Service Introduction Manager know (depending on the nature of the impacted
change).
Company-in-Confidence Page: 37 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services
FUJ00079953
FUJ00079953
POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.10 Step 5: Problem Closure
Responsible: SDM
From
Step
A(x)
a
SDM confirms all complete
SDM closes problem
¥
More N
occurrences?-
Y Stop
¥
Open new problem and link occurrences to it
Steps:
5.1 Problem Manager confirms that the following is true:
KEL record has been updated in accordance with events
Resolution has been applied (if that was the decision)
Planned pilot period has passed since time of resolution
Originator (unless IMT) has been informed that the resolution has been
implemented.
PEAK record is fully updated and closed.
5.2 Problem Manager closes problem record.
5.3 If following problem closure, there are further occurrences, a new problem should
be raised, which is linked to the old one.
Company-in-Confidence Page: 38 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
4.2.10Step 6: Tracking and Monitoring of Problems and Errors
Responsible: Problem Managers, Service Desk(IMT), Lead Problem Manager
The PI raises Problem records on Phoenix on the instructions of the Problem
Managers or following rules. All open Problems are clearly visible to all
Service Desk agents to enable them to check incoming Calls against existing
Problems. In the majority of cases, a frequency pattern is expected to develop.
The IMT will monitor for an increase in frequency pattern (see Step 7) . Each
problem will have a specific trigger associated with it, for alerting to the PI. If
this trigger is tripped, the PI will alert the SDM by telephone.
In the case of changes in the frequency pattern of an existing problem, the
SDM will feed the information into the business impact rating of the existing
problem as appropriate. The SDMs are however responsible for managing their
list of Problems and ensuring that they are regularly progressed.
The Service Delivery Team Manager is responsible for the overall Problem
Management process and confirming that the Problem records are properly
managed.
4.2.11Step 7: Trend Analysis
Responsible: Service Desk
Trend Analysis is performed on the statistics obtained from Call, Incident and
Problem records. Once any of the following trends are observed, the IMT will
contact the PI to alert them to the possibility of a Problem.
e Deteriorating SLA performance
¢ Deteriorating Customer Satisfaction
e Unexplained increases in Call volume
e Change in frequency pattern of incidents associated with a specific
problem
The PI will alert the SDM. If the SDM confirms that he/she would like a
Problem created, PI then creates the Problem record.
DN: Note that the SDM’s comment on this area was that the IMT are not geared to
monitor against these parameters. Initially they will only be able to monitor against
rules defined in the KEL relating to increases in call volumes or change in frequency
pattern.
Company-in-Confidence Page: 39 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services
FUJ00079953
FUJ00079953
POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
5.0 Reporting on the Problem Management Process
5.1
Purpose
The purpose of the reports produced on the Problem Management process is as
follows:
5.2
To enable the Process owner to monitor the effectiveness of the process.
To enable the Process owner to monitor that changes made to improve the
effectiveness of the process have had the desired effect.
To enable the Problem Manager to prove at need to Senior management how
the process is operating.
Report List
The list of reports to be generated specifically for the Problem Management owner
each month is as follows:
By originating group (i.c. POL, IMT or SDU), list of problems opened during
the month and list of problems closed during the month, together with a count
of each category (Report to show Originating group, Problem identifier, date
problem opened, Problem Business Impact Type (Ordinary, Arising from
Major Incident, Arising from MBCI), Date Problem closed. (Not yet
available)
By SDM and by priority, how long did it take to perform problem life-cycle
changes (Not yet available)
By SDM, caseload statistics, showing all problems which have been open
during the reporting period, sorted by date of opening of problem. (Report to
show SDM Name, problem identifier, date problem opened, date problem
closed, date of last update and current status of problem)
By SDM caseload statistics showing for each day during the reporting period,
how many problems they had open.
List of problems which have led to breaches in SLA targets over the reporting
period and which have been open during the reporting period. (Report should
include Problem Identifier, SDM, date problem opened and date problem
closed. There should be a nil return if none have been raised)
List of problems alerted as a result of trend analysis by IMT. (Report should
present a nil return if none have been raised over reporting period.)
List of problems, which have been passed to support groups as new problems
by the SDM but which are in fact duplicates of existing problems. (Report
should include Problem identifier of new problem and Problem identifier of Old
problem together with their respective opening and closing dates. Report
should include a nil return if none have been raised)
Company-in-Confidence Page: 40 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
e Any problems where it has been found necessary to re-open the problem after it
was supposed to be resolved. (Report should provide a nil return if none have
been raised)
e Any problems which have been the subject of customer complaints. (Report
should provide a nil return if none have been raised.)
The Problem Management owner is expected to take the information supplied and
investigate it. This is an essential step given the potential variables, since some
problems can rightly be analysed quickly and resolved, while others require significant
effort to perform root cause analysis and these differences are not readily established
by SDM or problem type. Following investigation, the Problem Manager will
determine which items are significant and forward a reduced report to Senior
Management.
DN: It is expected over time that the analysis above will lead to the development
of targets against which performance of the SDMs and the support groups in
resolving problems (as opposed to incidents) can be measured and improved.
Once these targets are in place, it will be necessary to create a reporting
mechanism which records performance against targets and also monitors the
progress of any improvement plans.
Company-in-Confidence Page: 41 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management —_Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Appendix A: Current scope of SDM (Problem Manager) responsibility
DeliveryFunction High Level Overview Primary Owner Secondary Owner Operational Review
Responsibilities
On-Line Services To ensure that every post office branch can I Mike — Stewart I} GRO I Mike Woolgar I;°7~*"-**"""""I On-Line services ORF
complete on-line transactions through the I Mike Woolgar I}. Mike Stewart
maintenance of the communications network I (Bracknell) (Bracknell)
within the post office branch, the Energis/BT
domains, the Fujitsu Services data centres and
the links to each of the financial institutions.
N.B. This does not __ include
communications where the post office
branches are within the OBC (Branch)
environment or branch hardware related G RO
issues. ' H
Data Transfer I To ensure complete and timely data transfer I Ian Daniel Dean Felix I} I TIP ORF, AP ORF, LFS
Services between Fujitsu Services and POL FS (via SAP I (Bracknell) (Bracknell) ORF, POL FS ORF
hosting & applications), TPS, APS clients
and LFS (SAPADS)
With responsibility also for AP Client
takeon, and AP EDG.
Chris Bourne
(Crewe)
Operational Business I To ensure all changes to the post office branch I Denise Miller
Change network in respect of: new branch opening, I (Crewe)
branch relocations, branch refurbishment,
branch closure, branch expansion — or
contraction and specific OBC (Branch)
chargeable services, are completed in a timely
and effective manner
Company-in-Confidence Page: 42 of 47
©Copyright Fujitsu Services Limited 2004
Fujitsu Services
POA Customer Service Problem Management
Process Details
Company-in-Confidence
Ref: CS/PRD/021
Version: 6.0
Date: 29/07/05
FUJ00079953
FUJ00079953
Engineering Services I To ensure all post office branch hardware I Dean Felix —_—_— Julie Welsh Non specific but by invite as
faults are rectified by repair or replacement I (Bracknell) i (Bracknell) required to any ORF
within the agreed service level targets i G RO
Operational Business I To ensure all Post Office Ltd and internal I Dave Wilcox I I Kevin Reference data RDORF
Change — (Reference I Fujitsu reference data is validated and I (Bracknell) 1 McKeown
data) distributed to post office branch and counters I 0s Aileen — Davis
as required in accordance with the agreed (Bracknell)
implementation date and related service level
targets.
Also with responsibility for the ICON service.
Branch To resolve specific issues in connection with I Nick Crow
branches
Company-in-Confidence
©Copyright Fujitsu Services Limited 2004
Page: 43 of 47
Fujitsu Services POA Customer Service Problem Management Ref:
Process Details
Version:
Company-in-Confidence Date:
FUJ00079953
FUJ00079953
CS/PRD/021
6.0
29/07/05
Appendix B: Terms of reference of Problem Review Board
B1: Composition
The following individuals are ex officio members of the Problem Review Board:
.
.
Director Customer Services
Service Management Team Manager
Service Delivery Team Manager (also the lead Problem Manager)
Service Support Team Manager
Horizon Next Generation
Service Introduction Manager
SSC/Application Support Manager
B2: Purpose of the Problem Review Board
The purpose of the Problem Review Board is to act as a escalation point and decide as
follows: .
Bearing in mind relative availability of resources and the business
problem whether a problem should be resolved.
impact of the
Allocate resource to resolution, where it is requires specific resource from Customer
Services
Individual members of the Problem Review Board may be tasked with escalating resolutions
within SI, where required.
B3: Frequency
The Problem Review Board will meet at least once per month but may meet more frequently.
Company-in-Confidence P:
©Copyright Fujitsu Services Limited 2004
rage: 44 of 47
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Appendix C Matrix for assessing Business Impact
Matrix to be defined. May be replaced by service support database. Pending that
definition, SDM should use SRRCs to assess business impact.
Company-in-Confidence Page: 45 of 47
©Copyright Fujitsu Services Limited 2004
FUJ00079953
FUJ00079953
Fujitsu Services POA Customer Service Problem Management Ref: CS/PRD/021
Process Details
Version: 6.0
Company-in-Confidence Date: 29/07/05
Appendix D Rules for the PI
Routine rules are as follows. Note that the PI can be asked to ignore them and raise problems
if the SDM desires:
A Problem should ALWAYS be raised by PI for an MBCI. However note that the
Problem record is intended for examination of root cause analysis, which in the case of
the MBCI is frequently established through specific meetings e.g Technical Bridge and
War Rooms. Therefore information on the Problem record will tend to be initially at
least, a summary of the root cause plus agreed actions to prevent recurrence.
A Problem should NOT be raised by PI, when there are higher than usual failures of
hardware in the branches, except at the explicit request of the Service Delivery Team
Manager. This is because there are established procedures under Availability
Management for these statistics to be evaluated.
A Problem should NOT be raised where an incident has been sent to the SDU (term
includes SSC) because the required workaround to resolve the incident can only be
performed by the SDU. Such a problem would be a duplicate.
A Problem should ALWAYS be raised where an error record (PEAK) has been sent to
a SDU for root cause analysis. (Note that there is a possibility here that a PEAK which
was sent to a SDU to establish a WORKAROUND might be mistaken for a problem.
At this stage it is still an INCIDENT. If in doubt, raise the Problem record and check
back later. If on inspection the original incident PEAK record was permanently closed
on return from the SDU (thereby closing the Powerhelp incident record) close the
problem record down. )
Problems requested by 3" parties i.e. SDU ‘s, POL should only be raised on the system
with the explicit permission of or at the request of the SDM for that service (or their
line manager)
Company-in-Confidence Page: 46 of 47
©Copyright Fujitsu Services Limited 2004