SLA

 

1.1.1

Service Level Agreements

The table below details SLA's based on severity levels. Service Level Agreement for SAP Application – Attended Support

Severity Level

Description

Very High

The loss of major services with disastrous business impact. This could be the loss of a critical resource to an entire business division or complete non-availability of SAP application At period ends or specific functionality critical to business may be termed as severity 1 by L&T MFF IT in agreement with support team. E.g. Cheque printing at month-end.

Response Time

Resolution Time

Committed Resolution

30 Min

6 Hours

80%

60 Min

3 Business Days

75%

6 Business Days

90%

9 Business Days

90%

Problem encountered in the main application impacting direct business service to High

Medium

Low

customers, affecting revenue, impacting legal requirements or the related application functionality is completely un-available

Problem is encountered in non-critical or supporting application of the business 1 Business Day process and the related functionality is not available or available through a work-around.

A low severity call is one which does not affect the business, such as a loss of availability of a non-critical function for an

1 Business Day

individual

Emergency On Call Support – Only for “Very High” severity  severity  

Very High

Outside the standard support window emergency on-call made available (Reporting using standard call-out numbers)

2 Hours

6 Hours

Service Level Agreement for SAP Application Security Support

80%

 

Existing Users

Role changes or additional authorization to existing users

1 Business Day

2 Business Days

75%

New Users

Application access to new users

1 Business Day

2 Business Days

75%

As this is a SAP Support Project, majority of the work will be of resolving messages. The user reports the message to solution manager. The Consultant picks up the message, in absence of the same the help desk administrator will analyze the message and forward the same to t o the respective consultant

Notes  



The abov above e SLAs will be applicable within tthe he Serv Service ice Window measured over a period of 3 mont months. hs.



   



   





SLAs level. shall be applicable for L&T MFF Business hours under support window, except for “Very High” severity All product related problem problems/bugs s/bugs are outside the scope of this SLA SLA.. Neverthele Nevertheless ss in case of product failure failure,, L&T Infotech shall strive to keep the operations running within the limitations imposed by the product failure. Time taken by ex external ternal agencies in resolving incidents is excluded from the SLA. Failures in non L&T Inf Infotech otech m managed anaged infras infrastructure tructure are not in the scope of the services.

 Any change in severity severity level of notifications shall be done with intimation and disc discussion ussion with end-user.

Enhancements Enhancements will be classified into minor, medium and major based on the efforts estimates. Enhancements with less than 24 hours (or 3 person days) of efforts will be termed as minor and between 24 hours to 56 hours (3 to 7 person days) of efforts will be termed as medium. A major enhancement is defined as a user request that pertains to an additional feature or functionality and one which cannot be termed as a problem with the existing system and takes between 56 to 80 hours (7-10 (7 -10 person days) of effort per enhancement Any enhancements beyond 80 hours of efforts will be classified as Projects and will be handled separately. Minor enhancements will be handled in same manner as carried out currently. All the minor enhancement requests will be submitted to the CCB for its approval. All approved requests (subject to maximum monthly cap) will be developed, tested and moved through production following the regular reg ular process. For handling major enhancements, L&T Infotech proposes a monthly release model. The monthly identification and approval of the enhancements to be carried out and the subsequent development and monthly release of these enhancements highlight the model. The picture below depicts this model.

Acceptance Criteria Following reporting and review frequency is suggested to ensure visibility for all stake holders

Review / Meeting

Frequency

Responsibility

Acceptance Criteria

Notification status

Online

Available Online

None

 

through Solution Manager Notification Ageing analysis

Weekly

Available Online through Solution Manager

None

CCB Meeting

Monthly

Project Manager/ Project Leader

None

Operations Review / SLA

Monthly

Project Manager/

None

Reports Engagement / SLA Review

Quarterly

Project Leader Delivery Head

None

Contract Review

Annual

Delivery Head

None

Developed Objects

As per Need

Project Manager/ Project Leader/ Technical Leader

User Acceptance Form

Problem Message- Initial Response to the user

As per Need

Respective module Consultant

As per SLA norms and recording in Case history

Problem Message- Provide solution to the message

As per Need

Respective module Consultant

Resolution time as per SLA norms User Acceptance

Note: Technical Developments ABAP related / Basis work will be carried out through Technical Delivery Center (TDC). TDC-Service Delivery Model will be the basi basiss for carrying out all the Technical Work. Functional Support

Phase

Deliverables / Activity

Responsibility

Acceptance Criteria

Remarks*

Requirement

Requirement Gathering (RG) form

User

RG form should be duly approved by CCB

Requirement

Logic Confirmation (LC) form

User

LC form should be duly approved by CCB

Analysis  Analysis 

Functional Specifications (FS)

Functional Consultant

RG filled by user. Should give details required to start a development LC form is filled by FC & needs to be approved by User & CCB FS is send to the Technical Techn ical lead of TDC

Build  Build 

Configuration Document (CD)

Functional Consultant

CD is uploaded in KM Portal for future reference

Release to QA server  server 

Transport Request hardcopy to Basis team

Functional Consultant

Needs approval from QL/PL/TL

Hardcopy is signed

Release to PRD server  server 

Transport Request hardcopy to Basis team

Functional Consultant

Needs approval from PL / PM

Testing

Test Cases to be attached in KM Portal

Functional Consultant

Hardcopy is signed. Acceptance received from User through mail. Unit Test cases will be prepared subjected to availability of test data. On demand by the User for speeding up the testing in QA, the same will be attached in KM Portal

 

Testing

Acceptance Note (AN) from User in KM Portal Manager

User

AN should be approved by CCB

Require to Release a Development to PRD server. This also validate that the deliverables under the change requested in the development meet customer requirements.

Acceptance Criteria

Remarks*

Technical Support

Phase

Deliverables / Activity

Responsibility

Analysis

Analysis of Requirement

Technical Consultant

Analyze the technical feasibility of the notification Contact FC for better understanding of thee scope/requirement if required & update query log

Design

WIMS Creation

Technical Consultant

Create a WIMS in Darpan.

Design

Technical Specification Document

Technical Consultant

Peer review done by other Technical team member

This document is uploaded in KM Portal.

Design

Unit Testing Plan Document

Technical Consultant

Peer review done by other Technical team member

This document is uploaded in KM Portal.

Build

Coding & Testing

Developer

Peer review done by other Technical team member

In SAP System.

Case closure

After successful testing Once the Development is handover to Functional Consultant for testing.

Developer

WIMS Closure

Close the WIMS in Darpan.