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.
30 Min
6 Hours
80%
High
Problem encountered in the main application impacting direct business service to customers, affecting revenue, impacting legal requirements or the related application functionality is completely un-available
60 Min
3 Business Days
75%
Medium
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.
6 Business Days
90%
9 Business Days
90%
Low
Response Time
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 individual
1 Business Day
Resolution Time
Committed Resolution
Emergency On Call Support – Only for “Very High” 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 t o the respective consultant
Notes
The above SLAs will be applicable within the Se rvice Window measured over a p eriod of 3 months. SLAs shall be applicable for L&T MFF Business hours under support window, except for “Very High” severity level. All product related problems/bugs are outside the scope of this SLA. Nevertheless in case of product failure, L&T Infotech shall strive to keep the operations running within the limitations imposed by the product failure. Time taken by external agencies in resolving incidents is e xcluded from the SLA. Failures in non L&T Infotech managed infrastructure are not in the scope of the services.
Any change in severity level of notifications shall be done with intimation and discussion 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 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 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 Reports
Monthly
Project Manager/ Project Leader
None
Engagement / SLA Review
Quarterly
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 basis 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
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 Techn ical lead of TDC
Build
Configuration Document (CD)
Functional Consultant
CD is uploaded in KM Portal for future reference
Release to QA server
Transport Request hardcopy to Basis team
Functional Consultant
Needs approval from QL/PL/TL
Hardcopy is signed
Release to PRD 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.
