sample sla based on itil
DESCRIPTION
An example of ITIL SLA in SCMS solutionTRANSCRIPT
SCMS_SLA_R01
1
Supply Chain Management System
Service Level Agreement
Author/Editor: abcd
Major Contributors: abcd
abcd
Original Issue Date: 1 April 2009
Revision: R01
SCMS_SLA_R01
2
Service Level Agreement
Table of Contents
1. Document Purpose .................................................................................................. 4
2. Document Objectives ............................................................................................... 4
2.1. Reference Documents ..................................................................................... 5
2.2. Document Control ............................................................................................ 5
2.3. Acceptance ...................................................................................................... 6
3. Service or Requirement Description ......................................................................... 7
3.1. Service Level Agreement Approach ................................................................. 7
3.2. SLA updating considerations ........................................................................... 8
3.3. Business Processes Supported ....................................................................... 8
3.4. Target User Base ........................................................................................... 11
4. Service Levels ........................................................................................................ 11
5. Service Hours ........................................................................................................ 14
6. Geographical Scope ............................................................................................... 14
7. Infrastructure .......................................................................................................... 15
7.1. Desktop ......................................................................................................... 15
7.2. Application ..................................................................................................... 16
7.3. Database ....................................................................................................... 17
7.4. Hardware ....................................................................................................... 18
7.5. Data ............................................................................................................... 19
8. Stakeholder Scope ................................................................................................. 19
9. Activity Scope ........................................................................................................ 21
9.1. Configuration ................................................................................................. 23
9.2. Consulting ...................................................................................................... 23
9.3. Defect Management....................................................................................... 23
9.4. Disaster Recovery ......................................................................................... 23
9.5. Documentation ............................................................................................... 24
9.6. Preventative Maintenance.............................................................................. 24
SCMS_SLA_R01
3
9.7. Project Support .............................................................................................. 24
9.8. Reactive Maintenance ................................................................................... 24
9.9. Reporting ....................................................................................................... 25
9.10. User Administration........................................................................................ 25
10. Key Performance Indicators ............................................................................... 25
11. Service Level Agreement supporting Procedures .............................................. 26
12. Reporting ........................................................................................................... 27
13. SLA Exclusions and Prerequisites ..................................................................... 28
14. Commercial ....................................................................................................... 28
15. Appendix ........................................................................................................... 29
SCMS_SLA_R01
4
1. Document Purpose
The purpose of this document is to describe the Service Level Agreement between Company h and Company q & Company r for supporting the Supply Chain Management system.
2. Document Objectives
This document aims to understand the requirements from the business users of the SCMS solution as specified in terms of Availability, Request Response times, Incident Response times and support timing. The SLA further describes the translation of the requirements into measurable infrastructure targets.
Since the SCMS solution is complex in nature and the effective support of the solution spans across multiple stakeholders, consideration is made of the effect these stakeholders can have in supporting various components of the SCMS solution.
The document further describes the measurement methods to account for the targets specified by business users.
In order to effectively support the SCMS solution there is a requirement for standardised procedures (Section 11). These procedures will be defined in this document and described at a high level. Each procedure identified in this document will be fully described in a separate document.
The document highlights the prerequisites for full SLA support and areas that are not considered as part of the current SLA scope (Section 13).
The document assumes that both Company q and Company r will opt for support through an SLA approach.
SCMS_SLA_R01
5
2.1. Reference Documents
REFERENCE DOCUMENTS
Document No Subject
GPR_User Access Request_A05
User Access Procedure
2.2. Document Control
REVISION HISTORY
REV DATE DESCRIPTION
R01 28 Feb 2009
First draft Issued for Review
SCMS_SLA_R01
6
2.3. Acceptance
APPROVALS
Name Organisation Designation Signature Date
SCMS_SLA_R01
7
3. Service or Requirement Description
3.1. Service Level Agreement Approach
The approach used in creation of Service Level Agreements described in this section. Figure 3.1 below indicates the conceptual model used in creation of the SLA. Targets (Service Level Objectives (SLO)) are defined by the Company q and Company r business with regards to Availability, Incident Criticality and Support timing for the main business processes enabled by the SCMS solution. The business SLOs are grouped according to the main business functions performed by the users of the SCMS solution. The business functions are discussed in more detail in section 3.3.
Figure 3.1 : SLA approach
Once the business functions are fully understood their associated SLO targets are mapped to the infrastructure making up the SCMS solution. The infrastructure consists of the software, hardware, databases, data and networks that collectively make up the SCMS solution. The infrastructure is described in more detail in section 7.
For a successful support program it is necessary to understand the scope of the different stakeholders in supporting the SCMS solution. Section 8 describes the stakeholder involvement in more detail.
Clear procedures are required to successfully deliver consistent support. Section 11 describes the necessary procedures in more detail.
SCMS_SLA_R01
8
3.2. SLA updating considerations
Since the SCMS solution is built to enable a continually evolving and dynamic environment, it is necessary to realize that the Service Level Agreements to support the solution needs to change periodically to reflect the change in business. The Service Level agreement makes provision to periodically change the targets, infrastructure and service levels.
Initially it is advisable to review the SLA’s formally bi-annually and make the adjustments to the infrastructure, targets and service levels contained in this document.
3.3. Business Processes Supported
Table 3.1 (Company q) and Table 3.2 (Company r) shows the main business functions against which the service targets will be measured. The service targets for each of the business functions of Company q and Company r are measured according to a specific Availability and Incident Handling requirement.
For Company r 8 business functions have been identified and for Company q 7 business function has been identified. Each of the business function have expected support time specified.
Availability and Incident targets are given in terms of priority codes. The priority codes are described fully in section 4.
SCMS_SLA_R01
9
Table 3.1 : Business Service Level Objectives - Company q
Business Service
Levels Description
Support
Timing
Availability
Priority
Business
Impact of
not
meeting
Availability
SLO
Incident
Priority
Long Term Planning
Ad-hoc Long-term
planning, Yield
Modelling
07:30 –
15:30 on
Working
Days 3 Low 3
Annual Delivery Plan
Creation of an approved
ADP. Revised ADP
according to changing
business needs
07:30 –
15:30 on
Working
Days, 24
hours a
day for
specified
times 1 High 1
90 Day Schedule
Creation of an approved
90DS. Revise according
to changing business
needs and operational
requirements
07:30 –
15:30 on
Working
Days 1 High 1
By-Products Lifting
Schedule
Creation of an approved
By-Products Lifting
Schedule. Revise
according to changing
business needs and
operational requirements
07:30 –
15:30 on
Working
Days
1 High 2
Planning, Scheduling
& logistics
Daily scheduling
operations, such as
Optimisation, Scenario
testing and What if
analysis
07:30 –
15:30 on
Working
Days 1 High 2
Fleet Management -
Operational
Daily Fleet scheduling.
Ship to Shore, Fleet
Tracking
07:30 –
15:30 on
Working
Days 1 High 2
Fleet Management -
Management
Ad-hoc Fleet
management. Agent
interfacing, Vessel
Performance, Invoicing,
Bunker Planning
07:30 –
15:30 on
Working
Days 3 Low 3
SCMS_SLA_R01
10
Table 3.2 : Business Service Level Objectives - Company r
Business Service
Levels Description
Support
Timing
Availability
Priority
Business
Impact of
not
meeting
Availability
SLO
Incident
Priority
Long Term Planning
Ad-hoc Long-term
planning, Yield
Modelling
07:00 to
15:00 on
Working
Days 3 Low 3
Annual Delivery Plan
Creation of an approved
ADP. Revised ADP
according to changing
business needs
07:00 to
15:00 on
Working
Days 2 High 2
90 Day Schedule
Creation of an approved
90DS. Revise according
to changing business
needs and operational
requirements
07:00 to
15:00 on
Working
Days 1 High 1
By-Products Lifting
Schedule
Creation of an approved
By-Products Lifting
Schedule. Revise
according to changing
business needs and
operational requirements
07:00 to
15:00 on
Working
Days 1 High 1
Planning, Scheduling
& logistics
Daily scheduling
operations, such as
Optimisation, Scenario
testing and What if
analysis
07:00 to
15:00 on
Working
Days 1 High 1
Sales Gas Delivery
Schedule
Creation of an approved
Sales Gas Lifting
Schedule. Revise
according to changing
business needs and
operational requirements
07:00 to
15:00 on
Working
Days 1 High 1
Fleet Management -
Operational
Daily Fleet scheduling.
Ship to Shore, Fleet
Tracking
07:00 to
15:00 on
Working
Days 1 High 1
Fleet Management -
Management
Ad-hoc Fleet
management. Agent
interfacing, Vessel
Performance, Invoicing,
Bunker Planning
07:00 to
15:00 on
Working
Days 3 Low 3
SCMS_SLA_R01
11
3.4. Target User Base
The target user base of this SLA corresponds with the identified and trained users of the SCMS solution. This includes users of the Company q Business Scheduling department Company q Shipping department and the Ras Laffan Terminal Operator department.
For Company r this includes users from the Shipping and Planning & Scheduling departments.
For the Ras Laffan Port this includes users of the Seaberth and HarbourView Applications. Additionally this includes users of HarbourView from Nakilat.
The breakdown of user counts per company is given in Table 3.3
Table 3.3 : User - Company Breakdown
Company User Group User Count
Company r 16
Company q 16
Ras Laffan Terminal Operator 6
Ras Laffan Port 43
Nakilat 30
Total 111
As part of this SLA, Company h will keep an accurate log of active users of the SCMS solution, their location and the installed applications in use for each user. The change in user access levels, adding new users and change of security models are governed by an access request procedure (GPR_User Access Request_A05).
4. Service Levels
This section of the SLA document describes the priority numbers indicating the expected targets for the business functions in more detail. The targets for each of the business functions are given in terms of availability and incident handling expectation.
Availability targets are given across three priority levels in terms of percentages. Availability of the portions of the SCMS solutions applicable to a business function are calculated as a whole and comprises of the infrastructure components in terms of Applications, Hardware, Databases, Networks and Data flow elements such as interfaces. Availability is measured as the (“total available time per month” – “total unplanned downtime”) / “Total Time available in a month” for each of the infrastructure groupings and expressed in terms of percentage availability. For example assume there is 8.5 * 21 = 178.5 working hours in a month (“Total Time available in a month”). Now assume there was collectively 2 hours downtime across all databases. This equates to 178.5 – 2 = 176.5 “total unplanned downtime”. The availability measure for the Database infrastructure components is then 176.5 / 178.5 = 98.9%. Similarly a availability figure is calculated for each infrastructure group. The percentage figures for the infrastructure
SCMS_SLA_R01
12
groupings is then multiplied to give the total availability figure for the specific business function being measured. The multiplied figure is then measured against the priority level expected for the business function. The priority figures are given in Table 4.1.
Table 4.1 : Availability Service Levels
Availability Categories
Priority Code Category Business Criteria Availability Level %
1 Platinum
Users using the system
extensively during this
time frame >= 90%
2 Gold
Moderate use of the
system during this time
frame >= 85%
3 Silver
No or very little users
accessing the system
during a certain time
frame >= 80%
Incident targets are measured on two dimensions namely response time and restoration times. Again incident service levels relate to the business service levels according to priority codes specified. Each priority code is associated with an expected response time and expected restoration time. Incident targets takes account of response and restoration times (solving of user queries) of user calls as well as response and restoration times when breaks to the solution occur affecting the specific business function being measured. The service level % indicates the amount of incidents per month being serviced within the indicated response and restoration time.
The incident priorities are given across five levels and are displayed in Table 4.2.
Each of the incident priorities specifies rules for restoration (urgency) and how the incident is scheduled once the incident is identified. The incident priority is also classified in terms of the impact definition. For example an incident of priority 1 (critical) needs attention immediately at the expense of any other support activity in process at the time of incident occurrence. The impact of priority one incidents is normally incidents that impact business functions across multiple companies. A typical example would be a total failure of Business Hiway or site network times between the companies going out of sync. Priority two incidents are also very serious in nature and have the same expected restoration requirements but the impact is lower, in the sense that the impact of the incident is related to one company only. An example would be a total failure of CDP or a network switch not functioning at one of the main user locations.
SCMS_SLA_R01
13
Table 4.2 : Incident Service Levels
Priority
Code
Category Restoration
Speed
Rules
Incident
Management
Rules
(Urgency)
Impact
Definition
Response
Time
Restoration
Time
Service
Level
%
Example
1 Critical Immediate
Action, Per
SLA
Target
Restoration
Time
Takes
precedent
over any
other support
activity
Global
Impact
(Cross
Company
and Cross
Application)
and multiple
users
<= 1
Hour <= 8 Hours
>=
90%
Total failure
of Business
Hiway or
site network
times
between the
companies
going out of
sync.
2 High Immediate
Action, Per
SLA
Target
Restoration
Time
Takes
precedent
over any
other support
activity but
lower
stakeholder
involvement
Multiple
Applications
with
multiple
users within
the same
company
<= 1
Hour <= 8 Hours
>=
90%
Total failure
of CDP
OPCO or a
network
switch not
functioning
at one of the
main user
locations
3 Medium Action on
same day,
per SLA
target
Takes
consideration
of
maintenance
actions
Single
Application
affecting
multiple
users
<= 8
Hours
<= 16
Hours
>=
90%
Failure of
Fleet
Manager
4 Low Action on
same day,
per SLA
target
Takes
consideration
of scheduled
changes and
maintenance
actions
Single
Application
affecting a
single user
<= 8
Hours
<=
24Hours
>=
90%
One user
have issues
using his/her
TurboRouter
application
5 Request Plan and
schedule
on FIFO
basis
Handled
through the
request
fulfilment
process
Low impact
or affecting
a single user
<= 8
Hours
<= 40
Hours
>=
90%
How do I?
type
questions
coming from
one user
SCMS_SLA_R01
14
5. Service Hours
Service Hours for this SLA are 07:30 to 15:30 for Company q and 07:00 to 15:00 for Company r (Qatar – GMT+3:00) on Working Days. This is aligned to the Support Timing specified within the Business Service Level Objectives. Qatari national and religious holidays are not considered as Working hours. Christmas and the 1st of January are also excluded from Working days.
If there is a special case where Company q or Company r might require support outside of the specified working hours, an official request must be made to Company h Program Management in advance, typically two weeks.
6. Geographical Scope
The Support Engineers and Manager will be available for customer access through permanent site presence. For instance Company h will ensure that there is always a support engineer available at the main Company r and Company q SCMS user locations. Currently the sites are Company r tower for Company r users and Salam Tower for Company q users. It is known that other sites exist where users reside such as the AB shipping villa, RLTO users located in Ras Laffan and Port users located in Ras Laffan. The support engineers will be available to these sites as needed.
To enable the movement of the support engineers to most effectively assist users the support team needs the following infrastructure to be in place and fully working.
Permanent Gate passes.
Adequate Work Environment including sufficient desk space. At least three permanent desks at each of the main sites in Doha and one desk at the Port for port users and AB Ras Laffan for RLTO users. The AB shipping villa can be serviced from the main offices in Doha.
Landline access for the support engineers at their desks with international access.
Active User accounts for access to the internet via company wireless networks.
Computers residing on Company (RG/AB/QP) network, with valid accounts to enable support activities to be carried out by support personnel.
SCMS_SLA_R01
15
7. Infrastructure
This section describes the infrastructure components making up the SCMS solution. In supporting this solution, two broad categories of support are evident and must be considered. The first portion is support of the end-users through assisting in resolving queries, handholding in the use of the system, consulting and solving business related problems through the use of the SCMS solution.
The second portion is performed directly on the system components, through proactive and reactive maintenance of the infrastructure components to ensure the required availability and integrity of the solution. This further involves activities in changing the solution to suit new business requirements. The infrastructure components discussed in the rest of this section explains the configuration baselines in terms of infrastructure assets and how the assets are mapped to the business functions.
To align the business function to the infrastructure components a mapping is needed. The mapping is described in the following sections of Application, Database, Hardware and Data. The full infrastructure mapping is added as an attachment to this document.
7.1. Desktop
The desktop infrastructure represents the installation and usage of client side applications on the user computers. Desktop infrastructure keeps track of the users of the SCMS solution and what applications they are using and the associated access levels per user. Table 7.1 shows an extract of the user – application mapping.
Table 7.1 : Extract User - Application Mapping
SCMS_SLA_R01
16
7.2. Application
The application infrastructure components represent all the software used to build the SCMS solution. The mapping shown in Table 7.2 displays whether specific software applications are used when performing the associated business functions. This mapping is used to give the scope of each business function in terms of the application layer.
Table 7.2 : Extract Application Mapping
SCMS_SLA_R01
17
7.3. Database
The database infrastructure components represent all the databases in use by the SCMS solution. Table 7.3 maps databases to business functions.
Table 7.3 : Extract Database Mapping
SCMS_SLA_R01
18
7.4. Hardware
The hardware infrastructure components represent all the servers in use by the SCMS solution. Table 7.4 maps hardware servers to business functions.
Table 7.4 : Extract Hardware Mapping
SCMS_SLA_R01
19
7.5. Data
The data infrastructure components represent the flow of data within the SCMS solution. This includes interfaces between the applications and databases. Table 7.5 maps the SCMS interfaces to business functions.
Table 7.5 : Extract Data Mapping
8. Stakeholder Scope
This section describes the roles and responsibilities for support of the infrastructure components. The support of the infrastructure components falls within the domain of different stakeholder groups. The grouping of the responsibility levels is done consistently according to the infrastructure methodology grouping, i.e. Desktop, Hardware, Application, Databases and Data components. For each of the infrastructure group’s specific high level responsibility areas are defined. The Roles and Responsibility mapping is then done against the responsibility areas and is shown in Table 8.1 for Company q and Table 8.2 for Company r. The mapping of roles to responsibility areas is done according to principle of accountability or major responsibility. It is realized that most of the responsibility areas will involve activities from multiple stakeholder roles, but accountability will reside with the group specified in the matrix.
For Company q four stakeholders groups are defined. Company h support which consists of the support engineers and manager, AB networks who is responsible for IT networks, hardware and infrastructure at Company q, AB system support who operates the Company q IT helpdesk and SCMS / HAS support which runs support activities for the SCMS / HAS project at Company q.
SCMS_SLA_R01
20
Table 8.1 : AB Roles and Responsibilities
AB Support R & R ABL Support
AB Networks
AB System Support
SCMS / HAS Support
Desktop
Device X
Networks X
IT Support X
SCMS Support X
SCMS Access X
User Tracking X
Hardware
Servers X
Networks X
Operating System X
Patch Management X
Hard Disk / SAN X
Antivirus X
Application
Server Side X
Client Side X
Backup X
Upgrades X
Restore X
Database
DB Administration X
Backup X
Restore X
Data
SCMS Interfaces X
Exchange X
SCMS External Interfacing X
Internet X
Data Content X
At Company r three stakeholder groups are identified. The first group is Company h support consisting of the support engineers and manager, the second is the Helpdesk which is responsible for running the IT helpdesk at Company r and the third is the IT SCMS Support group. IT SCMS support is a group which consists of multiple persons from different IT functions specifically brought together to govern the IT aspects of the SCMS solution at Company r.
SCMS_SLA_R01
21
Table 8.2 : RG Roles and Responsibilities
RG Support R & R ABL Support Helpdesk IT SCMS Support
Desktop
Device X
Networks X
IT Support X
SCMS Support X
SCMS Access X
User Tracking X
Hardware
Servers X
Networks X
Operating System X
Patch Management X
Hard Disk / SAN X
Antivirus X
Application
Server Side X
Client Side X
Backup X
Upgrades / Software releases X
Restore X
Database
DB Administration X
Backup X
Restore X
Data
SCMS Interfaces X
Exchange X
SCMS External Interfacing X
Internet X
Data Content X
9. Activity Scope
This section describes typical activities that are performed by the support team. The activities are categorized into logical groupings to enhance tracking and reporting of performed activities. The activity groupings are further used in effort calculation and the activity groupings are allocated to each business function according to the Service Level Objective expectations and the count of Infrastructure assets described in section 7.
Table 9.1 gives an overview of the allocation of activity effort per Service Level Objective. Each of the activity groups will have an impact on the SLA targets in terms of availability and Incident handling. The following table also classifies the activity groups against the relevant SLA as described in section 4.
SCMS_SLA_R01
22
Table 9.1 : SLO - Activity Allocation
SCMS_SLA_R01
23
The following gives a high level explanation of the activity groups identified in Table 9.1 and used within the SLA.
9.1. Configuration
Configuration deals with changing system configuration. This is defined as changes performed on the infrastructure components. Configuration is also additions, changes and removal of models such as CDP and RPMS. Configuration also deals with changing of system parameters such as contained within the Common System Identifiers document.
Configuration is performed mostly as part of project activities. To ensure higher speed of configuration change delivery support will cover smaller configuration activities. If configuration activities are less than 40 man-hours in duration the configuration is covered under support, other wise it is performed as part project activities and governed by the project rules.
9.2. Consulting
Consulting deals with activities when dealing with users, through fielding calls, advising on the usage of planning models and advising on system usage. Further consulting deals with user handholding to enhance formal training.
Master data management is another activity covered under consulting. This includes tasks performed for instance during common system identifier activities. Activities are collating information, comparing information between systems and documentation, facilitation and gathering of requirements and sharing information between users, project teams and solution partners.
Consulting further performs Data Content Verification such as comparing data between systems, for example POIS/RTIS with CDP, CDP with HAS, SEABERTH and HarbourView.
9.3. Defect Management
Defect Management deals with the handling of product defects. The support team logs defects and escalates the defects to the product shops. The support team will through collaborative efforts obtain work-arounds or new software fixes to resolve software defects.
9.4. Disaster Recovery
Disaster recovery deals with the ability to recover the SCMS system from disasters encountered through failure of one or more of the infrastructure levels discussed earlier. These are done through good a practice of backup and restore management. The support team collaborates with company IT departments to ensure that backups are done regularly and correctly according to a predetermined schedule. The support team will in partnership with the company IT teams perform restore testing quarterly. This is done to verify that backups are taken correctly and will be valid should recovery from backup be required.
SCMS_SLA_R01
24
In the future, disaster recovery will be part of the SCMS solution. When the DR system is in place the support team will work to ensure the availability of the DR system, ensure the DR system is synchronized with the production environment and produce the necessary procedures and testing methodologies to support the DR systems. The DR system is mentioned as future DR activities but is not currently in scope for support.
9.5. Documentation
To effectively support the SCMS solution documentation are required. Documentation activities include the write and upkeep of procedural and administrative documents. Procedural documents contain reference on how to perform tasks and include checklists and maintenance actions. Administrative documents refer to workflows for performing tasks such incident handling, change handling and user communication. Admin procedures include the upkeep of templates used in performing the procedures.
Section 11 describe the different types of procedures in more detail.
Further documentation is required when doing change requests and includes the documenting of test plans, back out plans and other change related documentation.
The documentation activity also covers ad-hoc documentation performed by the support group as requested by RG and AB. The SLA documents are an example of ad-hoc documentation.
9.6. Preventative Maintenance
Preventative Maintenance activities are performed to ensuring availability of the SCMS solution as required by the targets set for each business function. The maintenance activities are performed on the infrastructure components discussed earlier. According to the availability targets maintenance tasks are identified and scheduled. The tasks are performed daily, weekly or monthly as required. The identified tasks have checklists to ensure consistency in performing the tasks. Typical tasks include patch management, interface monitoring and checking, service monitoring, logging on to servers and reviewing log files etc.
9.7. Project Support
The activities covered in project support are delivered by the support team to enhance the project teams to accomplish their tasks. This includes providing information regarding the current state of the SCMS configuration, managing the remote connection activities of the project teams, facilitating change requests on behalf of the project teams, providing system backups for testing enhancement and changes at the partner locations. The support team further fulfills all sorts of requests for the partners. The support team does final on site testing for changes and enhancements performed by project teams.
9.8. Reactive Maintenance
Reactive Maintenance covers the activities to repair the SCMS solution after failure. This covers the activities performed during Incident and Problem Management procedures, such as Incident tracking through helpdesk functions, finding work-arounds for failures, performing Root Cause Analysis to resolve and prevent issues.
SCMS_SLA_R01
25
9.9. Reporting
These activities cover the measurement and reporting of the status of support organization. This includes the building, measurement and reporting of KPI’s against the Service Targets specified earlier. Reporting will be done on weekly and monthly basis. Key Performance Indicators and Reporting are covered in more detail in section 10 and section 11.
9.10. User Administration
User Administration deals with support aspects of security and access management. This is done through collaboration with company IT departments. User Administration include tasks such as new user configuration, changes in user access, configuration and changes to application security models, keeping track of user base and application installations. These activities further keep track of user access approvals and procedures.
10. Key Performance Indicators
To measure the targets set out per business function a set of Key Performance Indicators are developed. The targets are measured in terms of Availability and Incident restoration. These measures are compared against the expected level of performance. An average is then taken of the Availability, Response and Restoration measurements, for each business function. This average gives the KPI for each business function.
The KPIs are measured and reported over a monthly interval for each business function.
The Availability target considers the individual availability levels of infrastructure groupings namely Application, Database, Hardware, Data and Network. The measurement is accomplished by taking the total work hours in a month and subtracting the total amount of downtime of each of the infrastructure groupings. For example consider there was 20 working days in a month. This equates to 170 working hours. Should there be 2 hours downtime in a month on the collection of databases for a specific business function, the database availability measure would be approximately 99%. Every month similar availability measures are collected for each of the infrastructure groupings. The availabilities of the infrastructure groupings in then multiplied to give the achieved availability measure. This achieved availability measure is compared to the target expectation. Although all the infrastructure components are measured only the infrastructure groupings controlled by the support group are considered for the KPI calculation. The groups controlled by the support team are the application group and the data group. Hardware, Databases and Network the responsibility of the company IT groups.
The incident measures are calculated according to the speed of response and speed of restoration of infrastructure failures as well speed of response and restoration of user calls.
The Availability and two incident measured are then averaged to calculate a SLA KPI for each business function. By comparing the SLA KPI to the expected target penalties on not meeting the service expectation can be enforced. Penalties are discussed further in the Commercial section. See Table 10.1 and Table 10.2 for examples of KPIs per business function for Company q and Company r.
SCMS_SLA_R01
26
Table 10.1 : AB KPI example
Table 10.2 : RG KPI example
11. Service Level Agreement supporting Procedures
To effectively support the SCMS solution and achieve the performance targets a collection of administrative and works procedures are required. This section lists the procedures required and maintained as part of the support activities.
These procedures are updated, refined and maintained through the life of SCMS support. Overtime additional procedures can be developed to better cater for support needs. Table 11.1 lists the procedures for effective support delivery.
SCMS_SLA_R01
27
Table 11.1 : Support Procedures
Procedure Criteria
Communication When and how to communicate to users, Project teams, Communication rules, email templates etc.
Call Handling Call handling workflow, escalations, status levels etc.
Change Handling
When is change necessary? What is our approach to handle system change? How does this process align to the Programme Change Management process? Rules for using formal change process.
Release Handling
Testing criteria, How to perform tests, obtaining customer signoff. Testing Templates. Rollout plan to production, utilising QA systems
Incident Handling How are incidents handled, escalated? Incident categorisation and priority levels.
RCA Handling
Procedure for handling Root Cause Analysis and Problem Resolution. This includes templates, rules for deciding when to do formal Problem resolution etc.
User Request Tracking
Managing user access levels, application security models, adding and removing user access to SCMS solutions
Maintenance Procedures
Preventative Maintenance plans and schedules. Procedures for doing activities on application level, i.e. CDP, TurboRouter etc.
Master Data management Procedures for changing and managing master data such as Common System Identifiers (CSI)
12. Reporting
Reporting is done according to two time frames namely weekly and monthly.
Weekly reporting will be based on more real time data, such as activity reporting. Activity reporting gives an overview of activities for the past week, issues encountered, activities for the next week, basic statistics such as amount of calls received or closed and call age analysis. Activity reporting also gives a description of weekly highs and lows.
Monthly reporting focuses more on statistics, trends and performance against SLA targets. Monthly reporting forms the basis for SLA penalty calculation.
From time to time it will be required that specific reports are given to requesters (Program, Users, and other stakeholders) to gain a deeper understanding of certain support activities. These reports will be developed on an ad-hoc basis according to requirements.
SCMS_SLA_R01
28
13. SLA Exclusions and Prerequisites
Specific areas are not covered as part of support, because it falls outside of support scope or it does not form part of the current infrastructure. This section describes these areas in more detail.
Quality Assurance and Disaster Recovery systems – At the time of writing of this document the QA and DR systems has not been implemented and has been omitted from support estimation, because the infrastructure components have not been defined.
IT accountability areas – Areas such as support for hardware (Servers, Operating Systems), networks (Bandwidth, Redundancy, Security) and client computer support which forms part of normal IT activities are not considered for this SLA. Over time when IT groups have developed respective SLAs for these areas, it may be added to the measurement of the SLA targets. The support activities does cover the collaboration with IT groups to ensure a stable SCMS solution, but the formal measurements are not considered. Ideally from a User perspective IT conformance to the SLA targets are a prerequisite.
SCMS boundaries - This covers areas where the SCMS solution is dependent on data but these data providers do not from part of the solution scope. This included systems from third party providers such as POIS/RTIS, HAS, SAP, Vessel Satellite tracking providers and data expectations from other Ras Laffan companies such as Dolphin, Pearl and Oryx. The SLA scope only includes the infrastructure falling within the direct boundary of the SCMS solution. The support team will help in facilitating end to end data flow, but measurement of components outside of the direct onsite SCMS infrastructure components are excluded from SLA performance.
14. Commercial
The commercial proposal is based on two layers, namely
Support effort based on cost drivers (Activity Drivers) as shown in Table 9.1
Infrastructure
o Benefits Guardianship / Annual License Fees
o Management
o Software Support Agreements with third party partners
o Support Tools
The full commercial section of this document will be delivered separately.
SCMS_SLA_R01
29
15. Appendix
Infrastructure – SLO Mapping