POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
Strategy Statement for Operational Level Agreements
Author: Paul W Martin
Development Co-ordinator
Sponsor: Nick Embling
Service Development Manager
Authoriser: Mark Haynes
T/Head of Business Service Management
4© Consignia plc 2001
The contents of this document must not be reproduced (wholly or in part) used or
disclosed without the written permission of Consignia plc. This copyright applies to
all forms of storage and reproduction in which this information may be embodied
including without limitation magnetic storage, computer printout, and visual
display.
Business Service Management Page 1 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
0. DOCUMENT CONTROL
0.1 VERSION HisTORY
Version Dated Change Details
A 26/04/2000 Informal internal review within BBM
B 01/07/2001 Updated with comments received during
the formal BSM document review
1 04/09/2001 First issued version following Quality
Assurance the document contains minor
changes of names and job titles.
0.2. = DOCUMENT REFERENCES
Ref. Title Version Reference
Number
1 Service Management Framework 0.1 CSPOL005
2 Business Service Management 1.0 CHE/CCC/002
Document Library
3 Service Configuration Management I 1.0 CFG/APR/002
Process
4 Business Service Management 1.0 CHE/CCC/003
Document Review and Change
Procedure.
5 Service Improvement management I 1.0 SIP/APR/001
Process
0.3 DISTRIBUTION LIST
Name Title Team
Don Grey Head of BSM BSM.
Nick Embling Service Development Manager BSM
Steve Turnbull Planning Manager BSM.
Julian White Service Operations Manager BSM
Liz Tuddenham Supplier and Service Support Manager _I BSM
Mark Haynes T/Head of BSM., Network Business BSM
Support Manager
David Hulbert Business Continuity Manager BSM
Kevin Lenihan Service Quality Manager BSM
Louise Bentley Business Configuration Manager BSM
Bernadette O’ Donnell Service Implementation Manager BSM.
Iain Blood Horizon Liaison Manager BSM,
Business Service Management
Page 1 of 9
File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
0.4 DOCUMENT AND CHANGE CONTROL
The BSM Change Control Team is responsible for maintaining and changing all the
documentation created in Business Service Management. For further information on
existing documentation and procedure please contact the Change Control Manager.
0.5 GLOSSARY
Ref. Description
AIS Application Interface Specification
AP Automated Payments
APS Automated Payment Service
BET Business Environment Team
BS Business Systems
BSM. Business Service Management
cl Configuration Item
CIT Change Implementation Team
CMDB Configuration Management Database
HSRF Horizon Service Review Forum
LFS Logistic Feeder Service
LWPs Local Working Procedures
MBCIs Major Business Continuity Incidents
MI Management Information
NBSC Network Business Support Centre
OBC Operational Business Change
OSG Outlet Systems Group
OP/TIP Operational Transaction Information Processing
RDS Reference Data System
SLA Service Level Agreement
TIS Technical Interface Specification
TP Transaction Processing
Business Service Management Page 2 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
0.6 CONTENT
0. DOCUMENT CONTROL...
0.1 VERSION HisTory.
0.2 DOCUMENT REFERENCES.
0.3 DISTRIBUTION LIST... seen
0.4 DOCUMENT AND CHANGE CONTROL...
0.5 GLOSSARY.
0.6 CONTENT...
1. INTRODUCTION...
BONN
TD PURPOSE. nncnnennenninenens
1.2 SCOPE...
1.3 OBJECTIV!
2. STRATEGY...
3. ROLE OF BSM.
4, STANDARD OLA FORMAT......cccssecsseeesee
5. STANDARD OLA CONTENTS. ....csseesseees
5.1 SCOPE...
5.2 CONTRACTUAL OBLIGATIONS..
5.3 OWNERSHIP...
5.4 DOCUMENT CONTROL AND RELEASE MANAGEMENT.
5.5 OBJECTIVES...
5.6 SERVICE MANAGEMENT.
5.7 MEASUREMENTS.
5.8 SERVICE REVIEW
Business Service Management Page 3 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
1. INTRODUCTION
1.1. BACKGROUND
There is currently no PON policy regarding the use or content of OLAs although
they have existed in OSG for some years and a number have been produced within
Horizon during the last 18 months under BSM guidance.
ICL Pathway are keen to develop formal operational agreements and this is an
opportunity for PON to reach agreement in a number of areas and provide a degree
of comfort across the Horizon system.
OLAs are widely used within the IT community and are recognised as an industry
standard.
The objective of OLAs is to underpin and support service levels as agreed in SLAs.
OLAs should relate closely to the associated SLAs and reflect the framework of
SLAs.
OLAs are non-contractual documents (e.g. like a‘gentlemen’s agreement’) which
describe how a service or system will operate at an operational level and are
regarded as working documents.
1.2 SCOPE
The current remit of BSM is focussed on managing the Horizon system and the short-
term strategy should be confined to the implementation and operation of OLAs
across the end to end Horizon service.
In the long -term a consistent approach to the implementation and management of
OLAs could be applied to support all interfaces both internal and external to PON.
1.3. PURPOSE
The purpose of this document is pull together the different strands and outline
current thinking on the subject and propose a strategy for BSM’s future involvement
and recommendations as to the standard format and content of OLAs which could
be adopted within the wider PON area.
The document should be regarded as a discussion paper for agreement and
acceptance by the BSM lead team.
2. STRATEGY
The long-term aim should be to ensure that the operation of the end to end process is
supported with the appropriate agreements. Where necessary this will include
interfaces between PON and other suppliers (i.e. BS). Where interfaces exist but
there is no SLA in operation, generally this would be where there is not an
Business Service Management Page 1 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
automated service to be delivered, an OLA should be in place.
In some cases ad-hoc agreements have been reached to manage interfaces and, where
appropriate, these should be brought into line with the overall OLA strategy.
All such agreements should be subject to reporting and review at an appropriately
review forum constituted within the Service Management Framework (ref.1)
The short-term aim will be to ensure that at the very least all SLAs within Horizon
are supported by OLAs and any related interfaces (i.e. internal to PON) are also
covered by OLAs. Proposals for the short term strategy;
« Agree BSM strategy and standard format
¢ Broker joint approach and agreement on format etc. with ICL Pathway
¢ Establish database of existing OLAs. OLAs to be regarded as configuration items
(CIs) and stored on the Configuration Management database. Copies of the OLAs
to be held in the BSM Change Management document library.
¢ Ensure sign-off of existing OLAs
¢ Bring existing OLA’s into line with the agreed format as and when they are
revised
¢ Back-fill OLAs in key services as directed by HSRF
¢ Ensure join-up of OLA s, end-to-end, across critical processes
¢ Broker strategy and OLA content within PON
« Agree BSM Role
¢ Raise profile of OLAs within PON
3. ROLE OF BSM
The role of BSM so far has been to initiate and facilitate the production of OLAs in
key areas (i.e. RDS, TP, APS, LFS). There are issues around ownership, review and
document control which this document attempts to clarify.
Recommendations for BSM involvement are;
¢ Identify requirement for OLAs and information on related SLAs via Service
Review
¢ Facilitate production of OLAs
¢ Ensure agreements conform to BSM processes
¢ Ensure that OLAs are compatible with the requirements of the end-to-end service
¢ Ensure that OLAs join-up across boundaries/ interfaces where the relationship is
complex (i.e. RDS/TP/OSG/ICL Pathway, AP Clients)
Administer OLAs from BSM Document library [Ref. 2]
OLAs to be registered as Configuration Items [Ref. 3]
Facilitate review process
Provide MI where available from current processes to the operational review
forum as requested.
e Advise PON on OLA structure and policy
Business Service Management Page 2 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
4, STANDARD OLA FORMAT
The following pages contain the proposed format and content in detail.
The main recommendations in brief are;
© Ownership and approval authorities to be clearly defined
« Scope to be based on service specification
¢ OLAs to be Configuration Items
¢ OLAs to be kept in BSM Library and subject to BSM document standards [Ref. 2 &
4].
¢ BSM disciplines applicable to the OLA to be detailed
« Agreed measures to be included where desirable
¢ Regular reviews to be performed via Service Review forums
5. STANDARD OLA CONTENTS
Objective
An effective OLA should provide both parties with a clear view of the requirements
and responsibilities needed to support the service, facilitate a consistent approach to
managing the interface, furnish improved knowledge of future requirements,
facilitate better forward planning, promote co-operation and support service
improvement activities.
The OLA will form the basis on which both parties will develop local working
procedures (LWPs).
The OLA should be drawn up in the form of a document against a standard OLA
model. The content should be kept simple and free from too much technical detail
which would normally be covered by other documents i.e. TIS, AIS, Interface
Specifications etc. As with SLAs nothing should be agreed that cannot be measured
and the effectiveness and efficiency of the OLA should be reviewed on a regular
basis.
5.1 SCOPE
The scope will be largely derived from the service specification and clearly delineate
which service or system is being described, where the boundaries of that service lies,
which parties are involved in delivering and maintaining the service and the current
configuration to which the OLA will be applied. The duration of the OLA and any
exclusions from the agreement should also be included.
Business Service Management Page 3 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
5.2. CONTRACTUAL OBLIGATIONS AND OTHER RELATED DOCUMENTS
The OLA should detail the practical arrangements that have been agreed between
the parties concerned for delivering and maintaining a service or system.
The agreements contained within an OLA would not be deemed as affecting or
adding to existing contractual obligations. OLAs would not normally be regarded as
contractual documents.
Reference should be made to any contractual documents that apply to the service or
system i.e. SLAs, AIS, TIS.
Other documents that are linked to the OLA should also be referenced together with
a description of the nature of the link and any other appropriate Cls.
In more complicated areas it may be useful to list related documents in a table and
include this as an appendix to the OLA.
5.3. OWNERSHIP
The owner of the OLA will normally be the service provider primarily responsible
for delivering the system or service. The owner will be responsible for the
production, and review of the OLA document and ensuring that all relevant parties
are involved in the process.
The owner will also need to ensure that the document is signed-off by the relevant
parties and authorised at the appropriate level.
5.4 I DOCUMENT CONTROL AND RELEASE MANAGEMENT
OLAs will be regarded as Configuration Items and copies will be held in the BBM
document library. They will need to conform to the OLA model and BSM document
standards.
The documents will be subject to the change control process as applied by the BBM
Library [Refs., 2 & 4].
Control of versions, version history, release and distribution of new versions etc. will
be carried out by BSM Library on behalf of the owner.
55 OBJECTIVES
Provide a consolidated summary of the day to day operational and support
arrangements for delivering and maintaining the service as described in the ‘Service
Specification’. This section should include a brief description of the nature and
purpose of the service, key deliverables and quality targets.
Service Times - an outline of the normal processing cycles. (Usually in the form of a
diagrammatic representation), availability of service including maintenance times if
applicable, deadlines/ windows and any flexibility within the schedule which might
be agreed, availability of support (i.e. technical staff, help desks etc.) and
contingency arrangements. Where appropriate, information on file and data
Business Service Management Page 4 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
specification and location should also be described.
Clarify roles, responsibilities and contact points. Assign ownership of primary
activities. Details should be included of any help desks, expert domains and
technical support groups.
Facilitate the development of LWPs.
Take advantage of any service improvements which may arise (Ref. 5)
5.6 SERVICE MANAGEMENT
Agreement should be made and documented in line with the Service Management
Framework describing how BSM disciplines will be implemented, specifically:
¢ Incident Management - describe rules for reporting, recording and resolving
incidents across the interface. Normally the incident handling arrangements will
be detailed in the form of a table or matrix which will form an appendix to the
OLA and be reviewed and updated in the same way.
¢ Problem Management - summarise arrangements for reporting and resolving
problems and detail interaction of the various expert domains.
¢ Change Management - Outline which areas will be subject to change control and
how this will be managed and which teams are likely to be involved i.e.
Operational Business Change (OBC), Change Implementation Team (CIT) etc.
¢ Configuration Management - OLAs, together with their relationships to other CIs
to be stored on the CMBD.
¢ Business Continuity - details of contingency arrangements, system and system
data recovery, Disaster Recovery and the management of Major Business
Continuity Incidents ( MBCIs) via the appropriate Crisis Management Team (e.g.
Horizon Crisis Management Team.).
¢ Supplier Performance Management - The how, who and when of reporting
against the SLA (see ‘Measurement’ and ‘Review’)
5.7 MEASUREMENTS
Measurements as outlined in the SLA should form the basis for measuring the
efficiency of the OLA. Other measures may be developed and agreed to support the
OLA but these will not be contractual. As with SLAs nothing should be agreed
within the OLA that cannot be measured. Reporting against the measurements
which are independent from the SLA measures will also need to be agreed and
documented within the OLA.
5.8 SERVICE REVIEW
Review of the performance of the OLA should be carried out an operational forum.
Within Horizon, review forums have been set up under the Service Management
Framework [Ref. 1] and at these meetings the performance of the SLA and associated
Business Service Management Page 5 of 9 File Name: MPR_APR_SLA002v1.doc
POL00394060
POL00394060
Document 04/09/2001 Document Type: —L/001
Date:
Version: 1 Ref. Number: MPR/SLA/002
OLAs should be reviewed. Each forum has been organised around specific SLAs
and the attendees have a responsibility to ensure the performance of the
service/system. Part of this will be to review performance measures, instigate and
agree the production of OLAs, review the efficiency and content of OLAs and agree
the format and production of any management reports. The review forums are held
ona regular basis and conform to a generic Terms of Reference.
Similar arrangements should be applied to OLAs that fall outside Horizon.
Business Service Management Page 6 of 9 File Name: MPR_APR_SLA002v1.doc