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 Committed
Description Response Time Resolution Time
Level Resolution

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
Very High 30 Min 6 Hours 80%
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.

Problem encountered in the main application

impacting direct business service to
High customers, affecting revenue, impacting 60 Min 3 Business Days 75%
legal requirements or the related application
functionality is completely un-available

Problem is encountered in non-critical or

supporting application of the business 90%
Medium 1 Business Day 6 Business Days
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
Low availability of a non-critical function for an 1 Business Day 9 Business Days 90%
individual

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

Outside the standard support window

emergency on-call made available (Reporting
Very High using standard call-out numbers) 2 Hours 6 Hours 80%

Service Level Agreement for SAP Application Security Support

Existing Role changes or additional authorization to
1 Business Day 2 Business Days 75%
Users existing users

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 the respective consultant

Notes
 The above SLAs will be applicable within the Service Window measured over a period 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 excluded 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 regular 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 None
through Solution
Manager
CCB Meeting Monthly Project Manager/ None
Project Leader
Operations Review / SLA Monthly Project Manager/ None
Reports Project Leader
Engagement / SLA Review Quarterly Delivery Head None
Contract Review Annual Delivery Head None
Developed Objects As per Need Project Manager/ User Acceptance Form
Project Leader/
Technical Leader
Problem Message- Initial As per Need Respective module As per SLA norms and recording in
Response to the user Consultant Case history
Problem Message- Provide As per Need Respective module Resolution time as per SLA norms
solution to the message Consultant 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 / Responsibility Acceptance Criteria Remarks*

Activity
Requirement Requirement Gathering User RG form should be duly RG filled by user. Should give
(RG) form approved by CCB details required to start a
development
Requirement Logic Confirmation (LC) User LC form should be duly LC form is filled by FC &
form approved by CCB needs to be approved by User
& CCB
Analysis Functional Specifications Functional FS is send to the Technical
(FS) Consultant lead of TDC
Build Configuration Document Functional CD is uploaded in KM Portal
(CD) Consultant for future reference

Release to Transport Request Functional Needs approval from Hardcopy is signed

QA server hardcopy to Basis team Consultant QL/PL/TL

Release to Transport Request Functional Needs approval from PL / Hardcopy is signed.

PRD server hardcopy to Basis team Consultant PM Acceptance received from
User through mail.
Testing Test Cases to be Functional Unit Test cases will be
attached in KM Portal Consultant 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) User AN should be approved by Require to Release a
from User in KM Portal CCB Development to PRD server.
Manager This also validate that the
deliverables under the change
requested in the development
meet customer requirements.

Technical Support

Phase Deliverables / Activity Responsibility Acceptance Criteria Remarks*

Analysis Analysis of Requirement Technical Analyze the technical
Consultant feasibility of the
notification
Contact FC for better
understanding of thee
scope/requirement
if required & update query
log
Design WIMS Creation Technical Create a WIMS in Darpan.
Consultant
Design Technical Specification Technical Peer review done by This document is uploaded
Document Consultant other Technical team in KM Portal.
member
Design Unit Testing Plan Technical Peer review done by This document is uploaded
Document Consultant other Technical team in KM Portal.
member
Build Coding & Testing Developer Peer review done by In SAP System.
other Technical team
member
Case After successful testing Developer WIMS Closure Close the WIMS in Darpan.
closure Once the Development is
handover to Functional
Consultant for testing.