Production Support-Team Communication Nov 9 2009

IBM Global Business Services
Catalyt NA Production Support
© Copyright IBM Corporation 2009

Catalyst NA Production Support
Production Support in Global

Pooling Model

Global Production Support
Delivery Model
Pooling of Global Delivery
Uniform Methods, Tools and Processes
Service Measurement – SLAs, KPIs, CSAT
Managed Services, flexibility in Resource Management
Process Driven, Plug and Play
Committed Productivity Improvements – Do More with Less (reduce waste)
Pricing Model
Outcome Based Pricing
The Results and its Quality counts
Pay for a Service, as you Use
Its not Rocket Science but Plain and Simple Common Sense
3 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – What’s changing

Green Goblin – We are who we choose to be... now, CHOOSE – SpiderMan
Uncle Ben – With great power, comes great responsibility – SpiderMan
Peter – Not everyone is meant to make a difference. But for me, the choice to lead an ordinary life is no longer an
option – SpiderMan
What’s Changing ??
Nothing Really … People are Same, it’s same old SAP and the Processes … are Not
Changing but Maturing, to deliver better Value and Service to Kraft. We are actually
Transforming …
And as we Mature, We need a Shift in our Mindset and Behavior, We need Discipline, We
need to earn Trust at each and every interaction with the Customer
Most Importantly, We need to – Do the Right Thing, the Right Way at the Right Time.

Global Production Support – What’s changing

Peter – Not everyone is meant to make a difference. But for me, the choice to lead an ordinary life is no longer an
option – SpiderMan
What’s Changing ??
We are Re-Organizing ourselves based on the Services, we deliver

Production Support Service
Enhancement Service
Project Implementation / Deployment
It’s not Re-Organizing the Team but Re-Organizing the “Outcome”, the Services Delivered,
Who delivers What

Global Production Support – Processes

Time Claim in ILC
Categorization of Requests
Severity of Requests
Service Measurements in SM7
Enhancements (BPM / NRT)
Overview of Support Process – SM7
On Call Support
Expense Claim
Green Goblin – We are who we choose to be... now, CHOOSE – SpiderMan Uncle Ben – With great power, comes great responsibility – SpiderMan
Peter – Not everyone is meant to make a difference. But for me, the choice to lead an ordinary life is no longer an option – SpiderMan

Global Production Support – Time Claim

Approval
Workitem Description Needed
Time spent by Functional and Technical Teams, in
Production Support - RIR resolving a RIR No
Production Support - RTN RFC resolving a RTN RFC No
Production Support - RFI resolving a RFI No
Time spent by BI Team or other Team in monitoring
Production Support - Batch Jobs/BI Data Load Monitoring Batch Jobs / Data Loads No
Account Id (W5D1i)
Time spent on LIS Support or any other non Catalyst

Production Support - Miscellaneous Support - for RIRs, RTN RFCs, RFIs No
Time spent on Training, Cutover / Go-Live Support,

Production Support - Without Support Request Testing. Approval from Ramesh / Sanjeev needed Yes
Time spent by Functional and Technical Teams on Non

Routine RFCs, CRFs - not for Solution Delivery /
Non Routine RFC - Enhancements Deployment Team dedicated to Release / Delivery Cycle No
Management Hours Time spent by PMO on Excel sheets :-) Yes
Time spent on Knowledge Transition / Hypercare

Defects by the Functional / Technical Team - not for
Solution Delivery / Deployment Team dedicated to
Release / Delivery Cycle. Approval from Ramesh /
Hypercare / Transition Sanjeev is needed Yes
Time that is unutilized, do not use this for recording
Non Productive Hours- Idle Time training hours No
Approved Management Initiative Time only when approved by Ramesh / Sanjeev Yes


Time Claim in ILC - Book your Time where you spend your Time
A Person may be delivering more than one type of Service during a month and with such a
large team engaged on Kraft, it becomes very important to claim your time in an accurate
fashion on different Services that you are delivering. Remember, one of the basic PBC
objectives is timely and accurately claiming your time in ILC, which will facilitate accurate
reporting and billing.
• Inspite of the advise on claiming to the right claim code, people have claimed their time on
“Approved Management Initiative”
• Any One and Every One working on Kraft NA should reconcile their hours in ILC and PWA
upto Sep 30.
• From Oct 1, people booking their time on W5D1i should not book their time in PWA
• However, as usual, all hours in WQHKI should sync up with PWA, approval for overtime
needs to be approved by Kraft
• Everyone needs to work and book 45 hours in W5D1i, from Oct 1 onwards. Any time in
excess of 45 hours needs to be approved by Ramesh / Sanjeev


• People on Business Visa will continue to claim on Business Visa WorkItem, not on W5D1i
• Total Hours in a week is 45 hours (including Business Visa Workitem)
• No work should be performed without any SR, valid exception:
• Batch Job / Data Load monitoring
• Non Catalyst Support, LIS
• STC Team, still in Hypercare. STC Team, please book your time under "Non Routine
RFC - Enhancements“
• Please do not book your time on UKABHIG / W5NPE codes after 30-Sep.
• Please move your hours from these codes to W5D1i
• No SR No Work – Functional and BI Team should always have a ticket for their work, even for
a Non Production Issue
• Technical Team – should only be working on IBM managed tickets
• Technical Team – If working on non IBM managed tickets, should ask for a ticket in their
name


• Time claimed on “Enhancement” Workitem is the Actual Time and should tally with the
Estmates provided for the Enhancement
• For the Month of October, there is a difference of more than 50% in the Hours of
Estimate and the Hours claimed on “Enhancement” Workitem, WHY ??
• This difference can be drilled down to the Enhancement Request / Person.
• Either we are not able to estimate correctly or we booked wrong hours on
“Enhancement” Code
• This has an impact on the Revenue
• If there is any change in Scope or if the Estimate seemed to increase then please revise
the Estimate

Global Production Support – Categorization of Requests

• It is very important to categorize the Support Requests into the right category of RIR, RTN
RFC, RFI, NRT RFC, ROS.
• Having the Right Category of the Support Requests provides the Right Information on the
Health of the SAP System and its usage
• Having the Right Category influences the Metrics – SLA, KPI and CSAT
• RIR: Request for Incident Resolution. Bug/Missing configuration. Functionality that was
previously working, but is now broken. An RIR should only be used to track an unresolved
issue occurring in the production environment
• RIR should not need change to the Functional Specification / CSD
• If the RCA for a RIR does not need a Design Change then the Change should be
handled in the same RIR
• If the RCA for a RIR needs a Design Change than a new NRT RFC should be requested
for


• RTN RFC: Routine Request for Change. The customization activities provides for minor
new configuration or custom development updates, additions, and deletions up to 24 hours
each within existing modules and/or functionality that are already in production. Support
Requests directly related to the application of software updates from the software vendor will
be addressed within this feature (e.g. OSS notes).
• Needs change to a Functional Specification / CSD
• NRT RFC: Non Routine Request for Change. A NRT RFC is a RFC which is:
• More than 24 hours of effort
• Less than 24 hours of effort but is a Design Change
• Should not exceed 200 hours of effort
• RFI: Request For Information. “How to . . . . .” requests
• Any Investigation should not be carried out in a RFI Request, please create a NRT RFC
for that


• ROS: Request is Out of Scope.
• Misrouted Tickets, NOT resolved by IBM Team
• Duplicate Tickets
• Reopened Ticket for Rework

Global Production Support – Severity of Requests

• Critical: Critical system, product, or component failure that disables a major function of the
business. Significant number of users or business functions impacted. There is no business
workaround identified. Examples: Production/manufacturing is halted, unable to ship product,
etc.
• High: Major system, product, or component failure that impacts service level and affects a
major function of the business. Large number of users impacted.
• Medium: Problem impacts client’s ability to complete daily work and therefore affects daily
service level. Several users impacted.
• Low: Problem has resulted in limited loss of functionality. Work can be completed using
alternative methods and there is no impact to daily service levels. Low number of users
impacted.
• The Severity of Requests can be challenged if it does not conform with the above definitions
• Discuss with your Track Lead or Kraft Support Lead when downgrading the Severity of the
Requests
• The Right Category and the Right Severity determine the Right SLA

Global Production Support – SLAs

• “Time to Respond” is the time from when a SR (RIR, RTN RFC, RFI, NRT RFC)
assigned to Production Support Team to when receipt is confirmed by the Consultant.
• The Consultant will monitor the queues for any new SRs and will acknowledge receipt of the
Support Request by sending an email to the user to acknowledge receipt of the Support
Request
• Acknowledgement email need not be sent for Batch Jobs
• A copy of the email will be pasted into the log of the Support Request
• “Time to Respond” will therefore be calculated as the time from when a Support Request is
assigned to Production Support to when the acknowledgment email is sent to the user.


• “Time to Propose a Solution” is the time from when a Request for Incident Resolution
(RIR) is assigned to Production Support Team to when a solution is proposed to the
user.
• Proposal of a solution is deemed to have taken place when one of the following scenarios
occurs
• A workaround is accepted by the business. In this scenario the RIR will be subject to Root
Cause Analysis (RCA) by opening a Problem Record in Problem Management Module.
• A bug fix is required to resolve the issue and a workaround is accepted by the business. In
this scenario a Change Record needs to be opened to implement the bug fix.
• A workaround is not necessary nor a Change Request needed. In this scenario the RIR will
be resolved by the Consultant


• “Time to Provide a Solution” is the time from when a Request for Incident Resolution
(RIR where a bug fix is required) or a RTN RFC is assigned to Production Support
Team to when the solution is ready for the business to test.


• “Time to Close (RFI)” is the time from when a Request For Information is assigned to
Production Support Team to when the information has been supplied to the requester
and the status changed to ‘completed’.

Global Production Support – KPIs

• “Aged Support Requests” is the number of Support Requests which remain Open (i.e.
do not have a status of “completed” or “closed”) beyond a specified period of time.
• The number of Aged Support Requests will be reported within the following categories:
• Open 1 – 30 days
• Open > 90 days


• “Support Requests Requiring Rework” will report on the number of Support Requests
requiring additional rework following implementation into the production environment.


• This measurement is relevant only to RIR Support Requests which are in Problem
Management. “Time to Provide a Root Cause Analysis” is the time from when a
Request for Incident Resolution (RIR where a workaround is accepted by the business),
is assigned to Production Support to when the Root Cause Analysis has been
completed.


• “Percent Support Requests Managed by IBM” is the number of Support Requests
completed by the IBM measured as a percentage of the total number of Support
Requests completed within the same reporting period.


• “Time to Provide an Estimate (NRT RFC)” is the time from when a Non-routine RFC is
prioritized by the BPM, Business Process Owner, Reference Group and assigned to
IBM Team to when an estimate of the effort required to complete the change is issued
to Kraft. Target – 2 Business Weeks
• Working with appropriate teams (e.g. DEV and BI teams) an estimate of the effort required to
meet requirements will be prepared and presented to Kraft. The estimate will include:
• Requirements Gathering
• Analysis
• Design / Prototype
• Configuration
• Development
• Unit Testing
• Promote to Production
• Documentation / Admin


• “Schedule Variance for NRT RFC” When Non Routine RFC is approved by Kraft and
the estimate is accepted, a delivery date will be agreed. An ‘on time’ Non Routine RFC
will be unit tested and available in the User Acceptance Test environment within three
business days (+/- 3 days) of the scheduled delivery date.


Service Measurement Definition SR Category (included) SR Category (excluded)
Open 1 - 30 days “Aged Support Requests” is the number of Support Requests which RIR, RTN RFC, NRT RFC, RFI NRT RFC
Open 31 - 60 days remain Open (i.e. do not have a status of “completed” or “closed”)
beyond a specified period of time.
Open 61 - 90 days
Open > 90 days
SRs requiring rework “Support Requests Requiring Rework” will report on the number of RIR, RTN RFC, RFI NRT RFC
Support Requests requiring additional rework following
implementation into the production environment. These requests will
be identified when the request is reopened after initial closure by the
requestor.
Time to Complete RCA This measurement is relevant only to RIR Support Requests which RIR, RTN RFC, RFI NRT RFC
are passed to Problem Management. “Time to Provide a Root
Cause Analysis” is the time from when a Request for Incident
Resolution (RIR where a workaround is accepted by the business),
is assigned to Production Support to when the Root Cause Analysis
has been completed
KPI
% SRs managed by IBM “Percent Support Requests Managed by IBM” is the number of RIR, RTN RFC, RFI NRT RFC
Support Requests completed by the Supplier measured as a
percentage of the total number of Support Requests completed
within the same reporting period.
Time to Provide an Estimate “Time to Provide Estimate” is the time from when a Non-routine NRT RFC RIR, RTN RFC, RFI
RFC is prioritized by the BPM and assigned to the Non-routine
service line to when an estimate of the effort required to complete
the change is issued to Kraft.
Schedule Variance When Non Routine RFC is approved by Kraft and the estimate is NRT RFC RIR, RTN RFC, RFI
accepted, a delivery date will be agreed. An ‘on time’ Non Routine
RFC will be unit tested and available in the User Acceptance Test
environment within three days (+/- 3 days) of the scheduled delivery
date.

Global Production Support – CSAT

• End User Satisfaction Survey (Monthly)
• Stakeholder Satisfaction Survey
• All the above Metrics (SLAs / KPIs / CSAT) attract a penalty for non
compliance. It is critical to follow the process and adhere to the
committed targets for these metrics
• The Right Category and the Right Severity determine the Right SLA
• Non Compliance with these processes impacts the Revenue. You
and your Actions have a direct bearing on the Revenue

Global Production Support – SLA Targets

Service Measurements - Gold Application
SR Classification Severity Time to Respond (from the time SR Time to Propose a Solution (from Time to Provide a Solution (from Time to Close (from the time SR
Category is assigned) the time SR is assigned) the time SR is assigned) is assigned)
95% within 15 Minutes 95% within 1 Hour

Critical
100% within 30 Minutes 100% within 2 Hours
High 95% within 30 Minutes 95% within 2 Hours
Problem Ticket Medium 95% within 2 Business Hours 95% within 12 Business Hours
(Ticket closed as 100% within 4 Business Hours 100% within 16 Business Hours
"Completed NA NA
Problem
Management")
Low 95% within 8 Business Hours 95% within 32 Business Hours
100% within 16 Business Hours 100% within 40 Business Hours
Critical 95% within 15 Minutes 95% within 1 Hour 95% within 3 Hour
100% within 30 Minutes 100% within 2 Hours 100% within 4 Hours
RIR Change Ticket High 95% within 30 Minutes 95% within 2 Hours 95% within 12 Hours
(Ticket closed as 100% within 60 Minutes 100% within 4 Hours 100% within 16 Hours
"Completed NA
Medium 95% within 2 Business Hours 95% within 12 Business Hours 95% within 40 Business Hours
Change
100% within 4 Business Hours 100% within 16 Business Hours 100% within 48 Business Hours
Management")
Low 95% within 8 Business Hours 95% within 32 Business Hours 95% within 64 Business Hours
100% within 16 Business Hours 100% within 40 Business Hours 100% within 80 Business Hours
Critical 95% within 15 Minutes 95% within 1 Hour
Trouble Ticket High 95% within 30 Minutes 95% within 2 Hours
(Ticket closed as 100% within 60 Minutes 100% within 4 Hours
"Completed", NA NA
Medium 95% within 2 Business Hours 95% within 12 Business Hours
"Closed", "Closed
Mail")
Low 95% within 8 Business Hours 95% within 32 Business Hours

Global Production Support – SLA Targets
Service Measurements - Gold Application

SR Classification Severity Time to Respond (from the time SR Time to Propose a Solution (from Time to Provide a Solution (from Time to Close (from the time SR
Category is assigned) the time SR is assigned) the time SR is assigned) is assigned)
Routine None 95% within 8 Business Hours 95% within 64 Business Hours
(Description starts 100% within 16 Business Hours 100% within 80 Business Hours
with "RTN")
RFC NA NA
Non Routine None 95% within 8 Business Hours
(Description starts 100% within 16 Business Hours
with "NRT") NA
Regular None 95% within 8 Business Hours 95% within 64 Business Hours
(Description starts 100% within 16 Business Hours 100% within 80 Business Hours
RFI with "REG") NA NA

Global Production Support – SLA Measurements in SM7
Service Measurement Definition SR Category (included) SR Category (excluded)
Time to Respond "Time to Respond” is the time from when a Support Request (RIR, RIR, RTN RFC, NRT RFC, RFI None
RFC & RFI) is assigned to Production Support to when receipt is
confirmed by a Team Member
Time to Propose a Solution "Time to Propose a Solution” is the time from when a Request for RIR (Problem / Change RIR (not in Problem / Change
Incident Resolution (RIR) is assigned to Production Support to Management) Management, RTN RFC, NRT
when a solution is proposed by a Team Member. RFC, RFI
SLA Time to Provide a Solution "Time to Provide a Solution” is the time from when a Request for RIR (Change Management), Routine RIR (not in Change Management),
Incident Resolution (RIR where a bug fix is required) is assigned to RFC NRT RFC, RFI
Production Support to when the solution is ready for the business to
test.
Time to Close "Time to Close (RFI)” is the time from when a Request For RIR (not in Problem / Change RIR (in Problem / Change
Information is assigned to Production Support to when the Management) Management), RTN RFC, NRT
information has been supplied to the requester and the status RFC, RFI
changed to ‘completed’

Global Production Support – SLA Measurements in SM7

SLA Measurements HOW Incident / Problem / Change Records should look like
Resolution
QCD
SR Incident Code - Problem Change Change
Classification Measurement Start Trigger Stop Trigger Comments Corrective Variable 1 Variable 2
Category Status Incident Status Status Reason
Action
Closed
Incident is opened and SM7 Incident status changes to Work in Customer
Time to Respond RIR
Status is "Open" "Work in Progress" Progress Communication
Trouble Ticket
according to the
Incident is opened and SM7 Incident status changes to
Time to Close Closed leave blank RIR actual solution
Status is "Open" "Closed"
provided
Incident is opened and SM7 Incident status changes to Work in Customer

Time to Respond RIR
Status is "Open" "Work in Progress" Progress Communication
Corrective Actions
Corrective Actions field is
Time to Propose Incident is opened and SM7 field is located Work in Change Request INCIDENT
Change Ticket set to "Change Request RIR Open
RIR Solution Status is "Open" under the Progress Opened RESOLUTION
Opened"
Action/QCD tab
CHANGE
Time to Provide Incident is opened and SM7 Build Phase in Change Work in INCIDENT
Suspend leave blank RIR WAITING UAT REQUEST
Solution Status is "Open" Request is completed Progress RESOLUTION
OPENED
Incident is opened and SM7 Status changes to "Work Work in Customer

Time to Respond RIR
Status is "Open" in Progress" Progress Communication
Problem Ticket Corrective Actions

Corrective Actions field is PROBLEM
Time to Propose Incident status changed to field is located Problem Ticket
set to "Problem Ticket Closed RIR TICKET Open
Solution "Work in Progress" under the Opened
Opened" OPENED
Action/QCD tab

Time to Respond RFC-RTN MAINTENANCE
RFC Routine
Time to Provide Incident is opened and SM7 Build Phase in Change
Suspend leave blank RFC-RTN WAITING UAT MAINTENANCE
Solution Status is "Open" Request is completed

RFC Non Routine Time to Respond RFC-RTN MAINTENANCE

Time to Respond RFI
RFI
Time to Close
Incident is opened and SM7
Status is "Open"
Status changes to
"Closed"
Closed leave blank RFI
INFORMATION
PROVIDED

Global Production Support – Enhancement

• Enhancement Process (Interim)
• All the BPM Requests should have a corresponding NRT in SM7
• All the NRTs should:
• Be responded to – Time to Provide a Response
• Should be Estimated – Time to Provide an Estimate (2 Business Weeks)
• Should be Delivered on Time – Schedule Variance
• Bhushan is managing all the Enhancements
• All the NRTs should be estimated and an approval from Kraft Support Lead before
commencing work on it


• Estimation is different from Duration
• Try to be reasonable in estimating the Enhancements
• All Functional / ABAP / BI effort needs to be estimated
• Estimating Templates for Functional / ABAP / BI Teams to be used
• All Estimates to use standard estimating guideline and consolidated into Kraft Specific
Format
• Along with Estimate, you need to provide the Scheduled Delivery Date (preferably first
transport after the period end close). Refer the Package Dates


• Estimate includes all effort needed for:
• Analysis Phase
• Requirements Gathering
• Analysis
• Design / Prototype
• Development Phase
• Configuration
• Development
• Unit Testing
• Documentation / Admin
• Testing Phase
• Promote to Production


• Most (almost all) of the NRT will include a “Z” / Custom Development. Please use the
following estimating guidelines for coming up with Estimate of Development Phase.
• Include the effort of ABAP Team (standard estimating matrix available)
• Include the effort of BI Team (standard estimating matrix available)
• Include the effort of Xi Team (standard estimating matrix available)
• Include effort for Functional Specification (standard estimating matrix available)
• Include effort for Functional Configuration (standard estimating matrix available)
Estimation Guideline
Estimation Template


Estimation Template for NRT Requests
Phase Activity Kraft IBM Other External Total Notes
Develop Functional Specification - Include requirements gathering, confirmation of solution, prototyping if needed,
etc (ABAP / BI Team may in some cases be involved in the Analysis and
Analysis therefore their effort should be included as well)
Complete Configuration/CSD - Configuration effort in Sandbox / Development Environment

Security Development - Development Effort from Security Team Team
Tech Spec / Dev / UTP (SD) - Development Effort from ABAP Team Team (Technical Specification /
Development Development and Unit Testing)
Tech Spec / Dev / UTP (BI) - Development Effort from BI Team Team (Technical Specification /
Development and Unit Testing)
Functional Unit Test - Effort in Function Unit Testing
Development Effort - - - -
Integration Test - Effort in Integration Testing
User Acceptance Test - UAT is the responsibility of User but effort may be involved in supporting UAT
by the user, like authorization, setting up data, coordination with other Teams
for Inbound / Outbound Interfaces
Performance Test - Effort involved in Performance Test. This is performed by the Infrastrutcure
Team but effort may be involved in supporting the Performance Test, like
Testing setting up the data, triggering the transactions
Regression Test - Effort involved in Regression Test. This is performed by the Regression
Testing Team but effort may be involved in supporting the Regression Test, like
setting up the data, triggering the transactions
Testing Effort - - - -
Promote to Production - Effort involved in progressing the transports through the landscape
Training Development - Effort involved in developing the Training Content

Training Delivery - Effort involved in developing the delivering the Training
Controls - Effort involved in analysing / developing the Authorization. This is the
Deployment responsibility of the Internal Controls Team but any effort needed to support the
IC Team should be captured here
Master Data - This is the responsibility of the Master Data Team, any effort involved in
supporting or coordinating with Master Data Team should be captured here
Technical Infrastructure - Responsibility of the Infrastructure Team

Deployment Effort - - - -
Total - - - -
* Please represent all effort in Hours
Recommended Delivery Schedule (Earliest Available)
Ready for Unit Testing
Ready for UAT
Ready for Production


• Package Dates (TENTATIVE) – NOT YET CONFIRMED
Month Go – Live
Nov ’09 Nov 23, 2009
Dec ’09 Dec 28, 2009
Jan ’10 Jan 25, 2010
Feb ’10 Feb 22, 2010
Mar ’10 Mar 22, 2010

Global Production Support – SM7 Dotted line = Optional

(Digital Workflow – DW)
Kraft /EDS Help Desk
SM7 – Service Manager 7.0

TPIS interface (2-way)
Incident Problem Change Mgmt

Mgmt (IM) Mgmt(PM) (CM)
Ad-hoc Tasks CR Templates Tasks
Request for - Help finding
Incident workaround Configuration Assessment
Resolution and / or Tasks
(RIR) Root Cause Development Build Tasks
Test Tasks
Security
Request for Implementation
Catalyst Support
Change Open Client Tasks

Web Form
(RFC) (OSS or RBE)
Request for Complete

Information
or Service
(RFI / RFS) Complete
End Users
& Upd / Close Change
Help Desk Support Leads Coordinator SAP CC Teams
37

Global Production Support – SM7

 Ticket sources
- All tickets will come from a single source - DW
- All requests (RIR, RFC, RFI, etc) will be received in SM7 as “Incidents”
 Ticket Status
- There are only 3 statuses (Open, Work in Progress, Hold)
- Suspend - requires a special process
- Ticket should be closed only when the solution is implemented and confirmed by the user (3-strike rule
applies)
 Problem
- A “Problem” record must be raised for actual Incidents (RIRs) whenever Root Cause Analysis and/or
assistance from other teams is required
 Re-routes
- A ticket to be re-routed should NEVER be closed.


 Service classification / Reporting
- In SM7 service classification is in the QCD tab
- QCD contains Reporting Categories + Root Cause + Resolution Codes
- Variable 1 field will contain ticket categories (RIR, RFC, RFI, RFS)
 Work distribution - Change Requests
- Work Orders are replaced by Tasks within Phases
- Phases are sequential. The next phase only starts when the previous is closed.
 Change Approvals / Controls
- An actual Approval in the system is required so the Change Coordinator is able to progress to
Implementation phase.
- Approvers are defined by “Application” (CI) and enforced by the system.

 SM7 is now composed by 5 document types:

- Incident
- Problem
- Problem Tasks
- Change
- Change Tasks
 Incident Categories
- RIR not in Problem or Change mgmt
- RIR passed to Change Mgmt
- RIR passed to Problem Mgmt
- RFC (routine / non routine / BPM)
- RFI / RFS


• The actual list of Resolution Codes within SM7 contains a larger number of values.
• For Catalyst processes, these are the codes to be selected according to the scenarios described. The last column suggests the “Closure Code” to be used along with
each Resolution Code.
SM7 RESOLUTION ANALYSIS CODE Scenario Suggested "closure code"
ACCESS CORRECTED All Security tickets fixed right away. No CR needed. Can be considered Service Requests. user informed
CANNOT REPRODUCE Support team and User cannot reproduce the issue but the issue resolved itself user informed
Any tickets requiring a CR (Incident or Problem).

CHANGE REQUEST OPENED - Usually applied in the Incident closure process when a routine RFC is idenfied. user informed
- Applied in the Problem closuse process when the Change for a RIR is needed.
CHANGE REQUEST OPENED - BPM Any tickets requiring a CR (Incident or Problem) ending up in a NON-Routine RFC. user informed
CHANGE REQUEST OPENED - EMERGENCY Any tickets requiring an emergency CR. Applied in the Problem closuse process when an EMERGENCY Change for a RIR is needed. user informed
DATA CORRECTED Any "Data issue" ticket not requiring CR user informed
DATA MAINTAINED Table updates - RED BOOK ENTRIES user informed
DUPLICATE TICKET Duplicate Ticket user informed
INFORMATION PROVIDED Request for Information type tickets. No CR required. user informed
JOB FORCED OK Control M (Tivoli) type tickets re-executed
JOB RERUN Control M (Tivoli) type tickets re-executed
JOB RESUBMITTED Control M (Tivoli) type tickets re-executed
NO USER RESPONSE Tickets closed without resolution due to missing info. 3-strikes rule. user informed
Temporary solution provided. Passed to Problem mgmt for permanent solution analysis.
PROBLEM TICKET OPENED user informed
Used exclusively in Incidents.
RESOLVED BY EDS Used when ticket is routed to EDS and EDS resolve it. user informed
RESOLVED BY USER By the time Support team gets back to the user they resolved their issue user informed
SCHEDULE CHANGED Job Schedule changed user informed
SYSTEM RESTORED Basis type tickets user informed


• Root Causes are defined in SM7 by Assignment Group
• The following list will be standard for all Catalyst teams.
BPM ENHANCEMENT REQUEST NO PROBLEM
BPM PROCESS CHANGE REQUEST NO RESPONSE
BUSINESS PROCESS CHANGE OSS NOTE REQUIRED
CONFIGURATION BUSINESS REQUEST PLANNED OUTAGE
CONFIGURATION FIX REQUIRED PRINTER ISSUE
CONTROL M JOB FAILURE SECURITY ISSUE
DEVELOPMENT FIX REQUIRED SMS PATCH
DUPLICATE TICKET SOFTWARE ISSUE
HARDWARE ISSUE TECHNICAL IMPROVEMENT IDENTIFIED
INTERFACE ISSUE TRAINING / HOW TO
LOCKED ENTRY UNPLANNED OUTAGE
MASTER DATA ERROR USER ERROR
MATERIAL MASTER DATA ERROR VENDOR MASTER DATA ERROR
MISROUTED TICKET


• QCD vs Root Cause vs Resolution Code
• QCD should categorize what the ticket is about

 What happened
 Where (which system or part of the system) it happened
 What type of issue happened
• Root Cause is supposed to summarize in a single expression WHAT CAUSED the Incident.
• Resolution Code should reflect what was done to solve the Incident.
 Note that there is no Resolution Code for Problem because its resolution will always be
either handled as a Change or doing nothing.

 Incident An Incident is any event which is not part of the standard operation of a service and which causes,
or may cause, an interruption to, or a reduction in the quality of service.
 Problem A Problem is the unknown underlying cause of one or more Incidents. It will become a known
error when the root cause is known and a temporary workaround or permanent alternative has been
identified.
 Incident Management is concerned with restoring the service to the business user as quickly as possible.
 Problem Management is concerned with establishing the underlying causes of an Incident, and their
subsequent resolution and prevention.
 Conflict Between Incident Management And Problem Management
- From an Incident Management perspective the best decision is to, for example, reboot a server to
restore the service.
- This is not ideal from a Problem Management perspective as the reboot may destroy any diagnostics
and so prevent progress towards identifying root cause.


Incident Management
Trigger:
 User calls Help Desk or fill out a Web Form request
Process outline:
 CMC agent inputs ticket info in DW
- if via Web Form ticket info goes automatically to DW
 User sends attachments to the Regional Support Mailbox (NA, EU, AP)
- if via Web Form attachments go automatically to correspondent mailbox
 DW data interfaces to SM7 (every minute) via TPIS interface

 SAP CC Support team monitors SM7 "Incident" queue then performs the following sub-processes:
1. Acknowledgement
2. Propose a Solution – Analysis
3. Propose a Solution - Action Taken
4. Provide a Solution
5. Close Ticket
NOTE: Severity 1 or 2 tickets cannot be "suspended"
Not possible to reopen Closed incidents. New one needs to be opened.


 Refer to this list for ticket re-routing. Make sure you talk with you support colleagues before routing a ticket to their queues to
avoid delays the ticket bouncing around and delaying the response to the client.
Group Queue/Group name Group Queue/Group name

BAS (Basis / Infrastructure) SAPCCINFRA RTR (Finance) ORCATFIN
BI (Business Intelligence) ORCATBUS SAP Chg Mgmt - Other ORCATOTH
BI (Business Intelligence) - Jobs CATALYST BI BATCH SAP Chg Mgmt NA-CHGE
BI (Business Intelligence) - ADF SAPBWADF SAP Chg Mgmt (Rev-Trac) ORCATREVTRAC
IC (Internal Controls) NA-IC Batch Jobs failures (Tivoli) CATALYST BATCH
IC (Internal Controls) - Approva NA-IC-APPROVA Job Scheduling CATALYST SCHEDULING
MDM (Master Data) - Technical ORCATMDM SD (Solution Delivery) NA-DSAP
MDM (Master Data) - Business ORCATMBP SEC (Security) - to be deactivated ORCATSEC

MTI (Manufacturing) ORCATMAN SEC (Security) - SHARP SHARPSECURITY
OTC (Sales) - Technical ORCATSAL SEC (Security) - Approva ORCATAPP
OTC (Sales) - Business NA-BPM OTC SEC (Security) - North America NA-SAP-SECURITY
Imaging ORCATIMG SEC (Security) - Asia-Pacific AP-SAP-SECURITY
SAP GUI ORSAPGUI Solution Manager ORSOLMGR
Portal (SAP Enterprise Portal) ORSAPEP STC (Sales Trade) ORCATSTR
Mercury Quality Center ORMQC STP (Procurement) ORCATPRO
REG (Regression team) NA-SAP-REGRESSION XI (Integration) OREAI


Problem Management
Triggers:
 When an Incident "Propose a Solution" process outcome is a "temporary" solution (RIR)
 When a "Permanent" solution requires further investigation before being implemented
 When an incident requires assistance from other team to find a workaround and/or root cause
Process outline:
 If opened as a result of an Incident, the Incident must have all QCD fields filled out.
- Data from the Incident ticket will be copied over to the "Problem" ticket
 Assign "Problem tasks" to other groups (eg.: security or solution delivery) as needed (ad-hoc) so a pre-assessment of the problem can be provided.
 Create Change requests from the Problem Ticket as needed.
Note that a thorough assessment will be required in the Change Request "Assessment" phase. The Pre-Assessment provided in the Problem ticket can be
used as input for the CR assessment.
Sub-processes:
1. Acknowledgement
2. Propose a Solution – Analysis
3. Propose a Solution - Action Taken
4. Close Problem


Change Management
Trigger:
 A change is required as result of the assessment for resolution of an Incident or a Problem
Process outline:
 If Change is to resolve an Incident or Problem, open the Incident/Problem and create the Change request from there so the Change record is
automatically linked.
 Select a change category:
- Emergency: if from an Incident Severity 1 or 2
- RFC: for Minor/Major changes
- Standard: for Standard changes (repeatable, no impact, same description, same tasks, same implementation plan, same testing plan, same back
out plan)
 Change Requests are composed by Phases:
- Request ; - Assessment; - Build; - Test; - Approval; - Implement; - Review
 The phases behavior varies according to the change category (Emerg, RFC, Std) selected. Eg.: "Approval" for an Emergency comes after "Implement";
it's actually merged in a phase called "Approval/Review"
 The Change Coordinator is responsible for the transition from one phase to the next. Each phase needs to be explicitly "Opened", have Tasks properly
assigned, and "Closed" after all tasks have been completed.
 By closing the "Review" phase the Change is closed as well.


 Catalyst should always use Major RFCs or Emergency
 Standard will be only in special scenarios (to be defined)
Category Minor/Major (RFC) Emergency Standard
Request Request Request
Assessment Assessment Assessment
Building Building Building
Phases Testing Testing Testing
Approval
Implementation Implementation Implementation
Review Review/Approve Review


 Request phase is just the initialization of a CR. No actions are triggered from this phase.
 Change Coordinator identifies the "Reason for Change" accordingly:
- ENHANCEMENT (if BPM non-routine RFC)
- NEW DEVELOPMENT (if BPM non-routine RFC)
- INCIDENT RESOLUTION (if RIR)
- SERVICE REQUEST (if NON-routine RFC accepted by Support with no BPM involvement)
- MAINTENANCE (if routine RFC)
 Assessment phase sends out tasks to other teams including client approval documentation for proceeding with the change.
 When tasks are completed Change Coordinator provides
- Work Effort
- Estimate for Build
- Estimate for Test


 Build phase sends out tasks to other teams for executing the actual change and testing it before handing over to the client for sign off.
 At this point Implementation, Test and Back out plans are mandatory.
 SLA clock for “Provide a Solution” stops.
 Test phase sends out tasks to other teams where the Evidence of Testing (EOT) before production must be attached.
 Hand over to the Client for final testing and sign off.
- IMPORTANT: Evidence of Testing (EOT) MUST be attached to the Test Task.
 Change Coordinator closes the "Test" phase when all tasks are completed.
- "Target Implementation Times" are mandatory to close this phase
- IMPORTANT: These "Target Times" will become the Planned Start and Planned End times for the Implementation Phase.
- The CR must be approved and the "Implement" phase must be opened before the "Target Time". If for any reason the "Implement" phase is
opened past the "Planned Start times", it won't be possible to proceed to next phase until the exception is reported to the Kraft Global Change
Mgmt group.


 Approval phase – At this point all pre-production tests should have been done and client have signed off results. Only approved CRs will be
considered for Implementation in Production.
 Change coordinator contacts the "Application Approver"
- In general, the Kraft Support Lead is the Application approver who approves the change from the IS side
- For some applications a "Client Approver" is also required (Business side)
 Application Approver (and Client Approver) provide approvals
 At this point the Implementation Planned Times and Implementation Plan are locked
NOTE: An approver on Approval phase should never be the Change Coordinator due to conflict of interests (SOX)
 Implement phase – at this point all Rev-Trac’s must be in “Pre-Approval for P” status. Change owner (or representative) should prepare for CCB
meeting.
 Change coordinator assigns a Task within "Implement" phase to his own group (or to EDS if not using Rev-Trac)
- Includes the list of Rev-Trac request numbers or Transport numbers
- Includes any special migration instructions
(eg,: time to move, if outside the scheduled moves to production)


 Review phase – the change is already in Production, so the change coordinator confirms all information documented and takes any subsequent
actions needed before closing the CR.
 Once closed, the CR is locked! No further updates are allowed.
 Change Coordinator reviews if change is OK in production
 Change coordinator reviews if all mandatory information is provided in the CR such as:
- Evidence of Testing (specially if it is an emergency request)
- Rev-Trac or Transports references
- Tasks completed (not Rejected or Cancelled)


 Task Definition
- Tasks are specific assignments to the different groups within the SAP Competency Center (or to EDS)
required to complete a Change Request or a Problem ticket.
- A Task in SM7 compares with a Work Order in SD4, but not exactly the same.
 Problem Task
- Are optionally used to ask for other teams help to complete Root Cause Analysis and/or pre-
assessment for a Change Request
- Problem Tasks can be ad-hoc
 Change Task
- Change Tasks can be created ad-hoc; but
- It’s more common to use Change Templates which auto-populates the task instructions and
assignment groups.

 Two web support forms for Service Manager have been added to
http://support.kraft.com
- In the Quick Search field – type “Service Manager”
 1781 –New – Kraft Service Manager Assignment Group Request
- Use to add/delete a queue, etc
 1780 – New – Kraft Service Manager ID Request
- Use to add an operator – USER MUST HAVE A RECORD IN ASSET CENTER FIRST.
 If the user does NOT have an Asset Center record an/or not sure, open a ticket with
the help desk and use key word – “Service Manager”.

Global Production Support – On Call
 During Business Days:

- Provide On Call Support for Sev 1 (Critical) and Sev 2 (High) SRs outside Business
Hours
 During Non Business Days (Weekends and Holidays)
- Provide On Call Support for Sev 1 (Critical) and Sev 2 (High) SRs during Non
Business Days
 The On Call Support comes into play when a “call out” occurs on Sev 1 or Sev
2 SR received outside Business Hours
 “It is expected that the requestor (Business User) will be available to service
the request.
 Extended Support for Cut – Over or Period End Closing to be treated as Non
Routine Request for Change (NRT RFC)

IBM
Zone
Time
Onsite
IBM Off
NA CST
57
06:00 06:00 18:30 00:30
06:30 06:30 19:00 01:00
07:00 07:00 19:30 01:30
07:30 07:30 20:00 02:00
08:00 08:00 20:30 02:30
23-Feb-18
08:30 08:30 21:00 03:00
09:00 09:00 21:30 03:30
09:30 09:30 22:00 04:00
10:00 10:00 22:30 04:30

Zone
Time
10:30 10:30 23:00 05:00
NA CST
NA CDT
11:00 11:00 23:30 05:30
11:30 11:30 00:00 06:00
12:00 12:00 00:30 06:30

Period
12:30 12:30 01:00 07:00

Mar to Nov
Nov to Mar
13:00 13:00 01:30 07:30
13:30 13:30 02:00 08:00
14:00 14:00 02:30 08:30

Time Zone
GMT -06:00
GMT -05:00
14:30 14:30 03:00 09:00
15:00 15:00 03:30 09:30

15:30 15:30 04:00 10:00

Chicago
Chicago
Location
16:00 16:00 04:30 10:30
16:30 16:30 05:00 11:00

CST
CDT
17:00 17:00 05:30 11:30
17:30 17:30 06:00 12:00
Production Support
18:00 18:00 06:30 12:30
IBM Onsite Hours

Kraft Business Hours
Business Hours
18:30 18:30 07:00 13:00

Kraft Off Business Hours
19:00 19:00 07:30 13:30
19:30 19:30 08:00 14:00

IBM Offshore Hours 02:00 PM to 11:00 PM IST
20:00 20:00 08:30 14:30

Friday
Friday
20:30 20:30 09:00 15:00

07:00 AM to 05:30 PM Monday to
07:00 AM to 05:30 PM Monday to
21:00 21:00 09:30 15:30
21:30 21:30 10:00 16:00
22:00 22:00 10:30 16:30
22:30 22:30 11:00 17:00

Kraft HQ
Kraft HQ
23:00 23:00 11:30 17:30
23:30 23:30 12:00 18:00

Business Days Holiday Calendar
00:00 00:00 12:30 18:30
00:30 00:30 13:00 19:00

01:00 01:00 13:30 19:30

01:30 01:30 14:00 20:00
02:00 02:00 14:30 20:30
02:30 02:30 15:00 21:00
03:00 03:00 15:30 21:30
03:30 03:30 16:00 22:00

04:00 04:00 16:30 22:30
04:30 04:30 17:00 23:00

05:00 05:00 17:30 23:30
05:30 05:30 18:00 00:00

Call
Call
IBM
Zone
Time
Onsite
NA On
NA On
IBM Off
NA CST
58
Friday
Friday
Friday
Friday
Holidays
Monday to
Monday to
Monday to
Monday to
Weekend /
Business Days
18:30 18:30 06:00 06:00 18:30 00:30
19:00 19:00 06:30 06:30 19:00 01:00
23-Feb-18
19:30 19:30 07:00 07:00 19:30 01:30
20:00 20:00 07:30 07:30 20:00 02:00
20:30 20:30 08:00 08:00 20:30 02:30
21:00 21:00 08:30 08:30 21:00 03:00
21:30 21:30 09:00 09:00 21:30 03:30
22:00 22:00 09:30 09:30 22:00 04:00
22:30 22:30 10:00 10:00 22:30 04:30
23:00 23:00 10:30 10:30 23:00 05:00
IBM Onsite Hours

Kraft Business Hours
Kraft Off Business Hours
IBM Onsite On Call Hours

Warm Transfer of Tickets
23:30 23:30 11:00 11:00 23:30 05:30
IBM Offshore On Call Hours

00:00 00:00 11:30 11:30 00:00 06:00
00:30 00:30 12:00 12:00 00:30 06:30
IBM Offshore Hours 02:00 PM to 11:00 PM IST

01:00 01:00 12:30 12:30 01:00 07:00
01:30 01:30 13:00 13:00 01:30 07:30
02:00 02:00 13:30 13:30 02:00 08:00
02:30 02:30 14:00 14:00 02:30 08:30

03:00 03:00 14:30 14:30 03:00 09:00

03:30 03:30 15:00 15:00 03:30 09:30
04:00 04:00 15:30 15:30 04:00 10:00
04:30 04:30 16:00 16:00 04:30 10:30
05:00 05:00 16:30 16:30 05:00 11:00
Production Support
05:30 05:30 17:00 17:00 05:30 11:30
06:00 06:00 17:30 17:30 06:00 12:00
06:30 06:30 18:00 18:00 06:30 12:30

07:00 07:00 18:30 18:30 07:00 13:00

Hours
07:30 07:30 19:00 19:00 07:30 13:30
08:00 08:00 19:30 19:30 08:00 14:00
08:30 08:30 20:00 20:00 08:30 14:30

On Call Hours - Business Days
09:00 09:00 20:30 20:30 09:00 15:00

On Call Hours - Non Business Days
IBM Coverage during Kraft Business
09:30 09:30 21:00 21:00 09:30 15:30
10:00 10:00 21:30 21:30 10:00 16:00
10:30 10:30 22:00 22:00 10:30 16:30
11:00 11:00 22:30 22:30 11:00 17:00
11:30 11:30 23:00 23:00 11:30 17:30
12:00 12:00 23:30 23:30 12:00 18:00

IBM Onsite
IBM Onsite
IBM Onsite
IBM Offshore
IBM Offshore
IBM Offshore
12:30 12:30 00:00 00:00 12:30 18:30

13:00 13:00 00:30 00:30 13:00 19:00
13:30 13:30 01:00 01:00 13:30 19:30

14:00 14:00 01:30 01:30 14:00 20:00
14:30 14:30 02:00 02:00 14:30 20:30
15:00 15:00 02:30 02:30 15:00 21:00
15:30 15:30 03:00 03:00 15:30 21:30
16:00 16:00 03:30 03:30 16:00 22:00

16:30 16:30 04:00 04:00 16:30 22:30
17:00 17:00 04:30 04:30 17:00 23:00

10:00 PM to 10:00 AM CST
10:00 AM to 10:00 PM CST
10:00 PM to 02:30 AM CST
05:30 PM to 10:00 PM CST
02:30 AM to 11:30 AM CST
08:00 AM to 05:30 PM CST
17:30 17:30 05:00 05:00 17:30 23:30
18:00 18:00 05:30 05:30 18:00 00:00


 All On Call Support Numbers will have International Calling Facility enabled on
it
 The On Call Schedule for the next month will be published by the last working
day of the current month
 On Call” Numbers need to be published for other Teams, like, Security / Basis,
plus the Helpdesk number.

Month & Year

Support 10:00 AM to 10:00 PM CST 10:00 PM CST to 10:00 AM CST
Level 1 Escalation Level 2 Escalation
Queues
Primary Alternate Primary Alternate
On Call (Onsite) On Call (Offshore backup) On Call (Offshore) On Call (Onsite Track Lead Offshore PM / Kraft ODSM
STP backup)
MTI backup)
IMWM backup)
OTC backup)
RTR
backup)
STC backup)
BI
backup)
ABAP backup)

 Link to the Policy:

- http://w3-07.ibm.com/hr/ap/in/yourmoney/en-us/comp01-sapap01.html
 Standby Support:
- India: INR 100 per 4 hours of coverage
- US: USD 5 per 4 hours of coverage
- Guideline: Restrict the duration to –
 8 hours per day on Weekdays
 16 hours per day on Weekends/ Weekly off or Public Holidays
 Remote Access:
- The Consultants on “On Call” Support will be eligible for reimbursement of mobile
and internet charges for that month.
- The Project will not fund fixed charges, like, installation cost, device cost, deposits.

Global Production Support – Claiming Expenses

Global Production Support – Processes

• RCA Process
• 3 Strike Rule
• Enhancement Process
• Expense Claim

Production Support-Team Communication Nov 9 2009

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Production Support-Team Communication Nov 9 2009

Загружено:

Авторское право:

Доступные форматы

IBM Global Business Services

Catalyt NA Production Support

© Copyright IBM Corporation 2009

Catalyst NA Production Support

Production Support in Global

© Copyright IBM Corporation 2009

Global Production Support

3 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – What’s changing

Uncle Ben – With great power, comes great responsibility – SpiderMan

4 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – What’s changing

Uncle Ben – With great power, comes great responsibility – SpiderMan

We are Re-Organizing ourselves based on the Services, we deliver

5 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Processes

6 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Time Claim

Time spent on LIS Support or any other non Catalyst

Time spent on Training, Cutover / Go-Live Support,

Time spent by Functional and Technical Teams on Non

Time spent on Knowledge Transition / Hypercare

7 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Time Claim

8 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Time Claim

9 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Time Claim

10 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Categorization of Requests

11 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Categorization of Requests

12 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Categorization of Requests

13 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – Severity of Requests

14 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – SLAs

15 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – SLAs

16 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – SLAs

17 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – SLAs

18 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

19 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

20 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

21 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

22 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

23 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

24 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – KPIs

25 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – CSAT

26 23-Feb-18 Production Support © Copyright IBM Corporation 2009

Global Production Support – SLA Targets

95% within 15 Minutes 95% within 1 Hour

27 23-Feb-18 Production Support © Copyright IBM Corporation 2009