Supply Chain Management System Service Level Agreement
Author/Editor: Author/Editor: abcd Major Contributors: abcd abcd
Original Issue Date: 1 April 2009 Revision: R01
SCMS_SLA_R01
1
Service Level Agreement Table of Contents 1.
Document Purpose .................................................................................................. 4
2.
Document Objectives Objectives ............................................................................................... 4
3.
2.1.
Reference Documents ..................................................................................... 5
2.2.
Document Control ............................................................................................ 5
2.3.
Acceptance Acceptance ...................................................................................................... 6
Service or Requirement Requirement Description ......................................................................... 7 3.1.
Service Level Agreement Approach Approach ................................................................. 7
3.2.
SLA updating updating considerations considerations ........................................................................... 8
3.3.
Business Processes Processes Supported Supported ....................................................................... 8
3.4.
Target User Base........................................................................................... 11 11
4.
Service Levels........................................................................................................ 11
5.
Service Hours ........................................................................................................ 14
6.
Geographical Geographical Scope............................................................................................... 14
7.
Infrastructure Infrastructure.......................................................................................................... 15
8.
7.1.
Desktop ......................................................................................................... 15
7.2.
Application Application ..................................................................................................... 16
7.3.
Database ....................................................................................................... 17
7.4.
Hardware ....................................................................................................... 18
7.5.
Data ............................................................................................................... 19
Stakeholder Stakeholder Scope ................................................................................................. 19
9. Activity Scope Scope ........................................................................................................ 21 9.1.
Configuration Configuration ................................................................................................. 23
9.2.
Consulting Consulting...................................................................................................... 23
9.3.
Defect Management....................................................................................... Management....................................................................................... 23
9.4.
Disaster Recovery ......................................................................................... 23
9.5.
Documentation Documentation............................................................................................... 24
9.6.
Preventative Preventative Maintenance.............................................................................. Maintenance.............................................................................. 24
SCMS_SLA_R01
2
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
3
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
4
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
5
2.3. Acceptance APPROVALS
Name
Organisation
Designation
SCMS_SLA_R01
6
Signature
Date
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
7
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
8
Table 3.1 : Business Service Level Objectives - Company q
Business Service Levels
Description
Long Term Planning
Ad-hoc Long-term planning, Yield Modelling
Annual Delivery Plan
90 Day Schedule
By-Products Lifting Schedule
Planning, Scheduling & logistics
Fleet Management Operational
Fleet Management Management
Support Timing 07:30 – 15:30 on Working Days 07:30 – 15:30 on Working Days, 24 hours a day for specified times
Creation of an approved ADP. Revised ADP according to changing business needs Creation of an approved 90DS. Revise according to changing business needs and operational requirements Creation of an approved By-Products Lifting Schedule. Revise according to changing business needs and operational requirements Daily scheduling operations, such as Optimisation, Scenario testing and What if analysis
07:30 – 15:30 on Working Days
Availability Priority
Business Impact of not meeting Availability SLO
Incident Priority
3
Low
3
1
High
1
1
High
1
1
High
2
1
High
2
1
High
2
3
Low
3
07:30 – 15:30 on Working Days
07:30 – 15:30 on Working Days 07:30 – 15:30 on Working Days
Daily Fleet scheduling. Ship to Shore, Fleet Tracking Ad-hoc Fleet management. Agent interfacing, Vessel Performance, Invoicing, Bunker Planning
07:30 – 15:30 on Working Days
SCMS_SLA_R01
9
Table 3.2 : Business Service Level Objectives - Company r
Business Service Levels
Long Term Planning
Annual Delivery Plan
90 Day Schedule
By-Products Lifting Schedule
Planning, Scheduling & logistics
Sales Gas Delivery Schedule
Fleet Management Operational
Fleet Management Management
Description
Support Timing
Availability Priority
Business Impact of not meeting Availability SLO
Ad-hoc Long-term planning, Yield Modelling
07:00 to 15:00 on Working Days
3
Low
3
07:00 to 15:00 on Working Days
2
High
2
07:00 to 15:00 on Working Days
1
High
1
07:00 to 15:00 on Working Days
1
High
1
07:00 to 15:00 on Working Days
1
High
1
1
High
1
1
High
1
3
Low
3
Creation of an approved ADP. Revised ADP according to changing business needs Creation of an approved 90DS. Revise according to changing business needs and operational requirements Creation of an approved By-Products Lifting Schedule. Revise according to changing business needs and operational requirements Daily scheduling operations, such as Optimisation, Scenario testing and What if analysis Creation of an approved Sales Gas Lifting Schedule. Revise according to changing business needs and operational requirements Daily Fleet scheduling. Ship to Shore, Fleet Tracking Ad-hoc Fleet management. Agent interfacing, Vessel Performance, Invoicing, Bunker Planning
07:00 to 15:00 on Working Days 07:00 to 15:00 on Working Days 07:00 to 15:00 on Working Days
SCMS_SLA_R01
10
Incident Priority
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 Company r Company q Ras Laffan Terminal Operator Ras Laffan Port Nakilat Total
User Count 16 16 6 43 30 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
11
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
1
2
3
Category
Business Criteria
Availability Level %
Platinum
Users using the system extensively during this time frame
>= 90%
Gold
Moderate use of the system during this time frame
>= 85%
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
12
Table 4.2 : Incident Service Levels
Priority Code
Category
Restoration Speed Rules
Incident Management Rules (Urgency)
1
Critical
Immediate Action, Per SLA Target Restoration Time
Takes precedent over any other support activity
2
3
4
5
High
Medium
Low
Request
Immediate Action, Per SLA Target Restoration Time
Action on same day, per SLA target Action on same day, per SLA target
Plan and schedule on FIFO basis
Impact Definition
Global Impact (Cross Company and Cross Application) and multiple users
Takes precedent over any other support activity but lower stakeholder involvement
Multiple Applications with multiple users within the same company Takes Single consideration Application of affecting maintenance multiple actions users Takes consideration of scheduled Single changes and Application maintenance affecting a actions single user Handled through the request Low impact fulfilment or affecting process a single user
SCMS_SLA_R01
13
Response Time
Restoration Time
Service Level %
<= 1 Hour
>= <= 8 Hours 90%
<= 1 Hour
>= <= 8 Hours 90%
<= 8 Hours
<= 16 Hours
<= 8 Hours
<= 8 Hours
<= 24Hours
<= 40 Hours
Example
Total failure of Business Hiway or site network times between the companies going out of sync. Total failure of CDP OPCO or a network switch not functioning at one of the main user locations Failure of Fleet Manager
>= 90%
>= 90%
>= 90%
One user have issues using his/her TurboRouter application How do I? type questions coming from one user
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 1 st 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
14
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
15
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
16
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
17
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
18
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
19
Table 8.1 : AB Roles and Responsibilities
AB Support R & R Device Networks IT Support Desktop SCMS Support SCMS Access User Tracking Servers Networks Operating System Hardware Patch Management Hard Disk / SAN Antivirus Server Side Client Side Application Backup Upgrades Restore DB Administration Database Backup Restore SCMS Interfaces Exchange Data SCMS External Interfacing Internet Data Content
ABL Support
AB Networks
AB System Support X
SCMS / HAS Support
X X X X X X X X X X X X X X X X X X X X X X X 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
20
Table 8.2 : RG Roles and Responsibilities RG Support R & R Device Networks IT Support Desktop SCMS Support SCMS Access User Tracking Servers Networks Operating System Hardware Patch Management Hard Disk / SAN Antivirus Server Side Client Side Application Backup Upgrades / Software releases Restore DB Administration Database Backup Restore SCMS Interfaces Exchange Data SCMS External Interfacing Internet Data Content
ABL Support
Helpdesk X X X
IT SCMS Support
X X X X X X X X X X X X X X X X X X X X X 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
21
Table 9.1 : SLO - Activity Allocation
SCMS_SLA_R01
22
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.
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
23
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
24
9.9. Reporting These activities cover the measurement and reporting of the status of support organization. This includes the building, me asurement 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
25
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
26
Table 11.1 : Support Procedures
Procedure Communication Call Handling
Change Handling
Release Handling Incident Handling
RCA Handling
User Request Tracking
Maintenance Procedures Master Data management
12.
Criteria When and how to communicate to users, Project teams, Communication rules, email templates etc. Call handling workflow, escalations, status levels etc. 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. Testing criteria, How to perform tests, obtaining customer signoff. Testing Templates. Rollout plan to production, utilising QA systems How are incidents handled, escalated? Incident categorisation and priority levels. Procedure for handling Root Cause Analysis and Problem Resolution. This includes templates, rules for deciding when to do formal Problem resolution etc. Managing user access levels, application security models, adding and removing user access to SCMS solutions Preventative Maintenance plans and schedules. Procedures for doing activities on application level, i.e. CDP, TurboRouter etc. Procedures for changing and managing master data such as Common System Identifiers (CSI)
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
27
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
28
15.
Appendix
Infrastructure – SLO Mapping
SCMS_SLA_R01
29
