Sunteți pe pagina 1din 29

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

1

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

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

User Access Procedure

Request_A05

2.2. Document Control

REVISION HISTORY

 

REV

DATE

DESCRIPTION

R01

28 Feb

First draft Issued for Review

2009

SCMS_SLA_R01

5

2.3. Acceptance APPROVALS Name Organisation Designation Signature Date
2.3.
Acceptance
APPROVALS
Name
Organisation
Designation
Signature
Date

SCMS_SLA_R01

6

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.

functions are discussed in more detail in section 3.3. Figure 3.1 : SLA approach Once the

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

 

Impact of

not

meeting

Business Service

Support

Availability

Availability

Incident

Levels

Description

Timing

Priority

SLO

Priority

   

07:30

     

Ad-hoc Long-term

15:30 on

planning, Yield

Working

Long Term Planning

Modelling

Days

3

Low

3

   

07:30

     

15:30 on

Working

Days, 24

Creation of an approved ADP. Revised ADP according to changing business needs

hours a

day for

specified

Annual Delivery Plan

times

1

High

1

 

Creation of an approved 90DS. Revise according to changing business needs and operational requirements

07:30

     

15:30 on

Working

90 Day Schedule

Days

1

High

1

 

Creation of an approved By-Products Lifting Schedule. Revise according to changing business needs and operational requirements

07:30

     

15:30 on

Working

By-Products Lifting

Days

Schedule

1

High

2

 

Daily scheduling operations, such as Optimisation, Scenario testing and What if analysis

07:30

     

15:30 on

Planning, Scheduling & logistics

Working

Days

1

High

2

   

07:30

     

15:30 on

Fleet Management - Operational

Daily Fleet scheduling. Ship to Shore, Fleet Tracking

Working

Days

1

High

2

 

Ad-hoc Fleet management. Agent interfacing, Vessel Performance, Invoicing, Bunker Planning

07:30

     

15:30 on

Fleet Management - Management

Working

Days

3

Low

3

SCMS_SLA_R01

9

Table 3.2 : Business Service Level Objectives - Company r

       

Business

 

Impact of

not

meeting

Business Service

Support

Availability

Availability

Incident

Levels

Description

Timing

Priority

SLO

Priority

   

07:00 to

     

Ad-hoc Long-term

15:00 on

planning, Yield

Working

Long Term Planning

Modelling

Days

3

Low

3

 

Creation of an approved ADP. Revised ADP according to changing business needs

07:00 to

     

15:00 on

Working

Annual Delivery Plan

Days

2

High

2

 

Creation of an approved 90DS. Revise according to changing business needs and operational requirements

07:00 to

     

15:00 on

Working

90 Day Schedule

Days

1

High

1

 

Creation of an approved By-Products Lifting Schedule. Revise according to changing business needs and operational requirements

07:00 to

     

15:00 on

By-Products Lifting

Working

Schedule

Days

1

High

1

 

Daily scheduling operations, such as Optimisation, Scenario testing and What if analysis

07:00 to

     

15:00 on

Planning, Scheduling & logistics

Working

Days

1

High

1

 

Creation of an approved Sales Gas Lifting Schedule. Revise according to changing business needs and operational requirements

07:00 to

     

15:00 on

Sales Gas Delivery Schedule

Working

Days

1

High

1

   

07:00 to

     

Daily Fleet scheduling. Ship to Shore, Fleet Tracking

15:00 on

Fleet Management - Operational

Working

Days

1

High

1

 

Ad-hoc Fleet management. Agent interfacing, Vessel Performance, Invoicing, Bunker Planning

07:00 to

     

15:00 on

Fleet Management - Management

Working

Days

3

Low

3

SCMS_SLA_R01

10

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 monthfor 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

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

12

Table 4.2 : Incident Service Levels

Priority

Category

Restoration

Incident

Impact

Response

Restoration

Service

Example

Code

Speed

Management

Definition

Time

Time

Level

Rules

Rules

%

(Urgency)

1 Critical

 

Immediate

Takes

       

Total failure of Business Hiway or site network times between the companies going out of sync.

Action, Per

precedent

Global

SLA

over any

Impact

Target

other support

(Cross

Restoration

activity

Company

Time

and Cross

Application)

and multiple

<= 1

>=

users

Hour

<= 8 Hours

90%

2 High

 

Immediate

Takes

       

Total failure of CDP OPCO or a network switch not functioning at one of the main user locations

Action, Per

precedent

SLA

over any

Multiple

Target

other support

Applications

Restoration

activity but

with

Time

lower

multiple

stakeholder

users within

involvement

the same

<= 1

>=

company

Hour

<= 8 Hours

90%

 

3 Medium

Action on

Takes

Single

     

Failure of

same day,

consideration

Application

Fleet

per SLA

of

affecting

Manager

target

maintenance

multiple

<= 8

<= 16

>=

actions

users

Hours

Hours

90%

4 Low

 

Action on

Takes

       

One user

same day,

consideration

have issues

per SLA

of scheduled

Single

using his/her

target

changes and

Application

TurboRouter

maintenance

affecting a

<= 8

<=

>=

application

actions

single user

Hours

24Hours

90%

 

5 Request

Plan and

Handled

       

How do I? type questions coming from one user

schedule

through the

on FIFO

request

Low impact or affecting a single user

basis

fulfilment

<= 8

<= 40

>=

process

Hours

Hours

90%

SCMS_SLA_R01

13

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

7.1 shows an extract of the user – application mapping. Table 7.1 : Extract User -

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

scope of each business function in terms of the application layer. Table 7.2 : Extract Application

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

by the SCMS solution. Table 7.3 maps databases to business functions. Table 7.3 : Extract Database

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 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

to business functions. Table 7.5 : Extract Data Mapping 8. Stakeholder Scope This section describes the

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

 

ABL

AB

AB System

SCMS / HAS Support

AB Support R & R

Support

Networks

Support

 

Device

   

X

 

Networks

 

X

   

Desktop

IT Support

   

X

 

SCMS Support

X

     
 

SCMS Access

X

     

User Tracking

X

     
 

Servers

 

X

   

Networks

 

X

   

Hardware

Operating System

 

X

   

Patch Management

 

X

   
 

Hard Disk / SAN

 

X

   

Antivirus

 

X

   
 

Server Side

X

     

Client Side

X

     

Application

Backup

 

X

   

Upgrades

X

     

Restore

 

X

   
 

DB Administration

     

X

Database

Backup

 

X

   

Restore

 

X

   
 

SCMS Interfaces

X

     

Exchange

 

X

   

Data

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

20

Table 8.2 : RG Roles and Responsibilities

 

ABL

   

RG Support R & R

Support

Helpdesk

IT SCMS Support

 

Device

 

X

 

Networks

 

X

 

Desktop

IT Support

 

X

 

SCMS Support

X

   
 

SCMS Access

X

   

User Tracking

X

   
 

Servers

   

X

Networks

   

X

Hardware

Operating System

   

X

Patch Management

   

X

 

Hard Disk / SAN

   

X

Antivirus

   

X

 

Server Side

X

   

Client Side

X

   

Application

Backup

   

X

Upgrades / Software releases

X

   

Restore

   

X

 

DB Administration

   

X

Database

Backup

   

X

Restore

   

X

 

SCMS Interfaces

X

   

Exchange

   

X

Data

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

21

Table 9.1 : SLO - Activity Allocation

Table 9.1 : SLO - Activity Allocation SCMS_SLA_R01 22

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.

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, 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

25

Table 10.1 : AB KPI example

Table 10.1 : AB KPI example Table 10.2 : RG KPI example 11. Service Level Agreement

Table 10.2 : RG KPI example

Table 10.1 : AB KPI example Table 10.2 : RG KPI example 11. Service Level Agreement

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

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

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