Final Due-Diligence report portugal
-
Upload
hiram-francisco-biembengut-serra -
Category
Documents
-
view
37 -
download
0
Transcript of Final Due-Diligence report portugal
Confidential Page 1 of 32
BP Oil International Limited
Due-Diligence Report For
Application Support & Maintenance Western Europe
Portugal
Tata Consultancy Services 3000 Cathedral Hill Guildford, Surrey
GU2 7YB
July 2003
Confidential Page 2 of 32
Table of Contents
EXECUTIVE SUMMARY ........................................................................................................................................ 5
1 INTRODUCTION .................................................................................................................................................... 7
1.1 BACKGROUND ..................................................................................................................................................... 7
1.2 DUE DILIGENCE PLAN ......................................................................................................................................... 7
1.3 REFERENCES ........................................................................................................................................................ 8
1.4 ABBREVIATIONS .................................................................................................................................................. 8
1.5 STRUCTURE OF THE REPORT ................................................................................................................................ 8
2 SCOPE OF WESTERN EUROPEAN APPLICATION SUPPORT .................................................................... 9
2.1 OVERVIEW ........................................................................................................................................................... 9
2.1.1 Production Support and Maintenance ......................................................................................................... 9
2.1.2 User Support .............................................................................................................................................. 10
2.2 SCOPE OF SUPPORT ............................................................................................................................................ 10
2.3 EXCLUSIONS ...................................................................................................................................................... 11
2.4 ASSUMPTIONS .................................................................................................................................................... 12
2.5 DELIVERABLES .................................................................................................................................................. 12
2.6 RESPONSIBILITY MATRIX .................................................................................................................................. 13
3 ANALYSIS OF WESTERN EUROPEAN APPLICATIONS ............................................................................ 13
3.1 OVERVIEW ......................................................................................................................................................... 13
3.2 APPLICATION ANALYSIS .................................................................................................................................... 14
3.2.1 Criticality ................................................................................................................................................... 14
3.2.2 Size Complexity Factor (SCF) ................................................................................................................... 14
3.2.3 Stability ...................................................................................................................................................... 14
3.2.4 Analysis Table ........................................................................................................................................... 15
3.3 DUE DILIGENCE CUBE ....................................................................................................................................... 17
3.4 DETAILED APPLICATION PROFILE ...................................................................................................................... 18
4 TRANSITION PLAN AND RISK MANAGEMENT .......................................................................................... 19
4.1 TRANSITION APPROACH .................................................................................................................................... 19
4.1.1 Ideal Transition Approach ......................................................................................................................... 19
4.2 TRANSITION APPROACH .................................................................................................................................... 19
4.2.1 Recommended Transition Approach .......................................................................................................... 19
4.3 TRANSITION TIMELINE....................................................................................................................................... 20
4.3.1 Transition Activities ................................................................................................................................... 21
4.4 DETAILED TRANSITION PLAN ............................................................................................................................ 23
4.5 TRANSITION RISKS ............................................................................................................................................ 23
5 SERVICE DELIVERY MODEL .......................................................................................................................... 24
5.1 BASIS FOR MODEL SELECTION........................................................................................................................... 24
5.2 PROPOSED SERVICE MODEL .............................................................................................................................. 24
5.3 SERVICE MODEL ORGANISATION CHART .......................................................................................................... 24
6 MEASURING AND TRACKING ......................................................................................................................... 25
6.1 DEFINITIONS ...................................................................................................................................................... 25
.............................................................................................................................................................................. 28
6.2 COMMUNICATION PROCESSES ........................................................................................................................... 28
7 ADDITIONAL INFORMATION.......................................................................................................................... 30
7.1 COMMUNICATION INFRASTRUCTURE ................................................................................................................. 30
Confidential Page 3 of 32
7.1.1 Network Infrastructure .............................................................................................................................. 30
7.1.2 Data Link ................................................................................................................................................... 30
7.1.3 Software Environment ............................................................................................................................... 30
7.1.4 Security Policies ........................................................................................................................................ 31
7.2 PROBLEM MANAGEMENT TOOL ......................................................................................................................... 31
APPENDIX A: DETAILED APPLICATION PROFILE
LIST OF TABLES
TABLE 1: DUE DILIGENCE TEAM ....................................................................................................................... 7
TABLE 2: DUE DILIGENCE PLAN ........................................................................................................................ 7
TABLE 3: REFERENCES ......................................................................................................................................... 8
TABLE 4: ABBREVIATIONS ................................................................................................................................... 8
TABLE 5: PRODUCTION SUPPORT SCOPE DEFINITIONS ............................................................................ 9
TABLE 6: USER SUPPORT SCOPE DEFINITIONS........................................................................................... 10
TABLE 7: SCOPE MATRIX LEGENDS ............................................................................................................... 10
TABLE 8: SCOPE MATRIX ................................................................................................................................... 11
TABLE 9: LIST OF EXCLUSIONS FOR WESTERN EUROPEAN APPLICATION SUPPORT .................. 11
TABLE 10: LIST OF ASSUMPTIONS FOR WESTERN EUROPEAN APPLICATION SUPPORT ............. 12
TABLE 11: LIST OF DELIVERABLES FOR WESTERN EUROPEAN APPLICATION SUPPORT
PORTUGAL .............................................................................................................................................................. 12
TABLE 12: RESPONSIBILITY MATRIX ............................................................................................................. 13
TABLE 13: APPLICATION OVERVIEW ............................................................................................................. 14
TABLE 14: ANALYSIS OF APPLICATIONS....................................................................................................... 15
TABLE 15: ANALYSIS OF APPLICATIONS SUMMARY ................................................................................ 16
TABLE 16: DD CUBE ANALYSIS TABLE ........................................................................................................... 17
TABLE 17: TRANSITION ACTIVITIES ............................................................................................................... 22
TABLE 18: RISK MANAGEMENT PLAN ............................................................................................................ 24
TABLE 19: SERVICE LEVEL DEFINITIONS ..................................................................................................... 27
Confidential Page 4 of 32
Executive Summary
In the current economic scenario, off-shore outsourcing has become a strategic
management tool to enhance the bottom-line. Strategically and historically, BP has
successfully followed the model of outsourcing its IT functions to derive cost benefits and to
focus its energies on its core business. Now, through application support outsourcing using
offshore facilities offered by vendors, BP is seeking to further maximize its cost advantages
as well as its operating efficiency and performance. With rapid changes in technology, only
an organisation with the best processes, effective cost structures and ability to harness
technology to gain competitive advantage, will remain profitable.
TCS started the Due Diligence exercise on Sept 08, 2003 and and interacted with various
the third party and the super users to collect the data. The Due Diligence exercise was
completed on Sept 16, 2003 with the submission of this report. Scope of Western Europe Includes The scope of this RFP includes base and maintenance applications support for:
Downstream Western Europe applications which are supported for following business units: o Retail o Lubes o Logistics & Marketing o LPG
Process for Due Diligence
TCS will adopt the following approach for the due diligence to collect the information from
BP and prepare the Due Diligence report.
TCS will deploy a team (one or more consultant) in BP premises at each country to
undertake the Due Diligence activities.
TCS will first establish formal contact with BP Application Owner(s) and Subject Matter
Experts (SMEs) of each application system and walk through a questionnaire that contains a
detailed set of questions that helps to collect the required information. The information
collected through such questionnaire would help TCS to:
Get a high level understanding of each system/application
Current system health
Development and maintenance methodologies
Maintenance history
Overall maintenance effort
The following are the major activities to be undertaken:
Questionnaire will be supplied to BP in advance so that Application Owner(s) / SMEs
are aware of information to be collected for due-diligence phase
Discuss / Interview BP Application Owner(s) / SMEs using the questionnaire and
document all the information provided by them
Confidential Page 5 of 32
TCS will obtain all the supporting documents (like User manual, System
documentation, process documentation, Various Standards and Procedures) and go
through them for better understanding of the BP applications environment
Current SLAs will be collected, reviewed, metrics to be collected will be identified,
redefine SLAs if required
The proposed bundle of applications will be re-visited and re-bundled if necessary
The FTEs required per application bundle for support will be re-visited and finalised
A detailed plan will be prepared for the deployment of resources for Transition and
Steady State Phases
The potential risks for the transition will be assessed and their mitigation plan will be
prepared
All the information collected from BP Application Owner(s) / SMEs will be consolidated and
documented.
Using the information collected in due diligence, TCS will perform a gap analysis on the
available supporting information/documents. The individual application systems will be
grouped into different bundles. The transition plan given in the response to RFP will be re-
visited based on the Due Diligence findings.
At the end of the Due Diligence exercise, TCS will submit a study report for BP’ approval.
Main Risks
There are two main risks identified about the system. The first one is there is no functional,
design/technical documentation. The other is, only one person is available for knowledge
transfer. If the person is unwilling, Unavailable or Occupied with other work it may effect
the Knowledge Transition.
We must get the knowledge transfer and at the same time prepare documentation. We
must have good relation with third party to get easy and smooth knowledge transfer. if it is
not possible, we will have to learn the integration of all application from the super users and
from own effort.
Confidential Page 6 of 32
1 Introduction
1.1 Background
# Country TCS
Consultant
Role of TCS
Consultant
BP Staff Role of BP
Staff
TCS SPOC
(Y/N)
BP SPOC
(Y/N)
1. Portugal Pathri
Chakravarthy
Provide
Support
Y
2. Portugal Hiram
Biembengut
Provide
Support
Y
Table 1: Due Diligence Team
1.2 Due Diligence Plan The exercise began with a kick-off meeting on Sept 08, 2003 in presence of BP executives, where the expectations were discussed and the list of deliverables were finalized.
The following table outlines list of activities that were performed by the TCS team in close
coordination with BP during this exercise.
Activity Activity Description From Date To Date
A1 Kick of meeting with high level staff of BP and TCS
personnel 08 sept 08 sept
A2 Finalising the scope of the Applicatons
Overview of Systems 09 sept 15 sept
Identification of Applications, Business Areas and Technical Environment
09 sept 15 sept
Identification of Areas Outside of Scope 09 sept 15 sept
A3 Data Collection of Applications
Collection of Details on Each Application/Interface 09 sept 15 sept
Sizing of Applications, Analysis of Complexity & Stability 09 sept 15 sept
Evaluate Criticality of Applications 09 sept 15 sept
A4 Understanding of Service Level Agreement
Meetings on Service Levels 09 sept 15 sept
Establish SLA 09 sept 15 sept
A4 Project Monitoring and Tracking Methodology
Metrics – Collection 09 sept 15 sept
Table 2: Due Diligence Plan
Confidential Page 7 of 32
1.3 References
# Reference Document Author Version/Date
1. Due Diligence Process Doc TCS
2. RFP Western Europe Doc BP
version 1.1 28 May 2003
3. Appendix A details Application Profile TCS
4. Appendix Metrics Monitoring TCS
5. Western Europe Engagement TCS
6. TCS Response to Western Europe TCS
Table 3: References
1.4 Abbreviations
Abbreviation Description
SME Subject Matter Expert
SPOC Single Point Contact SLA Service Level Agreement
TCS TATA Consultancy Services
BP British Petroleum
Table 4: Abbreviations
1.5 Structure of the Report
The structure of the report is as follows
Section 1: Provides a background and an overall introduction to the Due Diligence exercise
carried out by TCS at BP, Portugal
Section 2: Describes the detailed scope of BP engagement. Section 3: Contains all analysis and profiling of all applications and business areas within the scope of BP Support. Section 4: Details on the proposed transition plan and associated risk management. Section 5: Briefs on the proposed service model going forward from transition phase. Section 6: Contains the proposed measuring and tracking mechanism for the BP engagement. Section 7: Details on the additional information collected for the engagement.
Confidential Page 8 of 32
2 Scope of Western European Application Support
2.1 Overview
Production and Interface support
User Support
The Scope of the support Includes maintenance applications support for
Retail
Lubes
Logistics & marketing
LPG
2.1.1 Production Support and Maintenance
# Activity Description Reference
1. Production Support
Maintain application quality
Recover application services after Incident
Provide technical/Business consultation
2. DB Support
Maintain users
Maintain User access Permissions
3. Documentation
Support
Documentation on resolution of
application problems
4. Implementation
Support
Software Release Management for Applications
Table 5: Production Support Scope Definitions
Confidential Page 9 of 32
2.1.2 User Support
# Activity Description Reference
1. User Support - 1st
Level
Fixing the problems over the phone
To verify if the user is proceeding
correctly
2. User Support - 2nd
Level
Correcting Error situtations
To organize all the information about
the problem and pass it to the supplier
of the application
3. User Training
Table 6: User Support Scope Definitions
2.2 Scope of Support
The following tables list the entire scope of support for Western European engagement as
agreed mutually by BP and TCS.
Legend Legend Description
Y Yes – in scope
N No – out of scope
Table 7: Scope Matrix Legends
#
Application Name (Owner)
Pro
du
cti
on
Su
pp
ort
En
han
cem
en
ts
In
terfa
ce S
up
po
rt
In
terfa
ce E
nh
an
cem
en
ts
User S
up
po
rt
- 1
st
Level
User S
up
po
rt
- 2
nd
Level
Data
base S
up
po
rt
Backu
p a
nd
DR
Op
erati
on
s
Backu
p a
nd
DR
Su
pp
ort
D
R D
ril
ls P
arti
cip
ati
on
Do
cu
men
tati
on
Su
pp
ort
User T
rain
ing
Im
ple
men
tati
on
Su
pp
ort
Pro
du
cti
on
Im
ple
men
tati
on
1 Delivery Document system Y N Y N Y Y N N N N Y N Y N
2 GTPC Y N Y N Y Y N N N N Y N Y N
3 LPG Planning Distribution Y N Y N Y Y N N N N Y N Y N
4 CLC Automation Loading Process Y N Y N Y Y N N N N Y N Y N
5 Petrogal Automation Loading
Process Y N
Y N Y Y N N N N Y N Y N
6 Retail Card and Retail Head office Y Y Y N Y Y N N N N Y N Y N
7 DLS Interface Y N Y N Y Y N N N N Y N Y N
8 Site Communications Y N Y N Y Y N N N N Y N Y N
9 Third Party system support Y N Y N Y Y N N N N Y N Y N
10 Post watch Y N Y N Y Y N N N N Y N Y N
Confidential Page 10 of 32
#
Application Name (Owner)
Pro
du
cti
on
Su
pp
ort
En
han
cem
en
ts
In
terfa
ce S
up
po
rt
In
terfa
ce E
nh
an
cem
en
ts
User S
up
po
rt
- 1
st
Level
User S
up
po
rt
- 2
nd
Level
Data
base S
up
po
rt
Backu
p a
nd
DR
Op
erati
on
s
Backu
p a
nd
DR
Su
pp
ort
DR
Dril
ls P
arti
cip
ati
on
Do
cu
men
tati
on
Su
pp
ort
User T
rain
ing
Im
ple
men
tati
on
Su
pp
ort
Pro
du
cti
on
Im
ple
men
tati
on
11 Terminal installation Y N Y N Y Y N N N N Y N Y N
12 FEP Y N Y N Y Y N N N N Y N Y N
Table 8: Scope Matrix
2.3 Exclusions
The applications and areas which are out of scope
# Areas that are out of scope
1. Sibs Services
2. Retail Account Processing
3. Help Desk Management
4. Call Center Management
5. System Administration
6. User Training
7. Support for third party vendor products, unless otherwise specified in Section 2.2.
8. Updates to User Manual
9. Data Base administration
Table 9: List of Exclusions for Western European Application Support
2.4 Assumptions
List of assumptions for the Western European Application Maintenance and Support
The Due Diligence exercise identified the following assumptions for the Western European
Application Maintenance and Support.
# Assumptions
1.
BP will make every attempt to ensure that it will be available to TCS to transfer knowledge, answer queries, review documents in a timely manner during the Transition Phase.
BP will provide necessary support to TCS while transitioning the applications from existing vendors. BP will liaison and resolve any issues related to non-cooperation from the out going vendor.
2.
Confidential Page 11 of 32
# Assumptions
3.
BP will provide the necessary access to its application environments (Development, Test and QA/Staging) to TCS consultants to have access through a communication link from its s offshore development center in Hungary.
BP will also provide access to related software tools and any other special hardware (such as Check printers, etc.). BP will provide remote access to all applications during off-hours including holidays and weekends to the TCS primary support personnel.
4. BP will be responsible to provide infrastructure, computer (hardware and necessary software – where applicable, 3rd party software), communication facilities and office supplies to TCS onsite team at BP sites at no additional cost during the entire engagement.
5.
Table 10: List of Assumptions for Western European Application Support
2.5 Deliverables
List of deliverable for each application / enhancement in the scope
The following list contains the deliverables for each application / enhancement under the
scope of the Western European Application Maintenance and Support at Portugal
# Deliverables
Due Diligence Report
Data Collection Sheets
Transition Plan & Schedule
Staffing Plan for transition and service phase
Table 11: List of Deliverables for Western European Application Support Portugal
2.6 Responsibility Matrix
The following table represents the responsibility matrix between TCS and BP for the Western
European Application Maintenance and Support.
Work description
Responsibility
TCS BP Production Support and Maintenance
Describe problem Primary
Study and perform impact analysis Primary Assist
Design fix Primary Review
Approve design (for critical fixes) Primary
Perform installation and implementation Assist Primary
Quality Assurance
Define quality standards Primary Assist
Implement quality standards Primary
Monitor quality standards Primary Assist
Implement corrective actions Primary Review
Confidential Page 12 of 32
Work description
Responsibility
TCS BP
Table 12: Responsibility Matrix
3 Analysis of Western European Applications
3.1 Overview
# System Type Platform
1 Delivery Document system Vendor Product Unix, Windows,
Progress
2 GTPC Vendor Product Unix, oracle,
Delphi
3 LPG planning and Distribution Vendor Product Unix, Progress
4 CLC Automation loading process Vendor Product Unix, Windows,
progress
5 Petrogal Automation Loading process Vendor Product Unix, Windows,
progress
6 Retail card and Retail Head office Vendor Product Unix, Windows,
Adabas
7 Third party System Support Vendor Product Windows
8 Post watch Vendor Product Windows,
Informix
9 Terminal Installation Not an application
10 FEP Vendor Product Unix, Crystal
Reports
11 Site Communications Not an Application
12 DLS Interface Vender Type Unix
Table 13: Application Overview
3.2 Application Analysis
3.2.1 Criticality
The Criticality figure has been arrived from the data received from BP Application owners /
SMEs. A criticality rating of 3 means that an application is very critical having large impact
to BP business whereas, a rating of 1 means that an application is less critical having low
impact to BP business.
3.2.2 Size Complexity Factor (SCF)
Confidential Page 13 of 32
The Size figure was calculated depending on the software inventory details, such as number
of components, tables, databases, reports etc. A rating of 3 means that an application is of
large size and 1 is of small size.
The Complexity figure has been derived based on the parameters such as, business
functionality, degree of parameterisation, and interfaces with other systems etc. A rating of
3 means that an application is of highest complexity and 1 is of lowest complexity.
Size Complexity Multiple (SCM) = Size * Complexity
As Size and Complexity can be in the range of 1 to 3 individually, the Size Complexity
multiple will be in the range of 1 to 9.
The Size Complexity Factor (SCF) is calculated as follows:
SCF = 1 if SCM is between 1 and 3
SCF = 2 if SCM is between 4 and 6
SCF = 3 if SCM is between 7 and 9
A Size Complexity Factor rating of 3 is assumed to be for a very large and complex system,
whereas, a rating of 1 is assumed to be for a small and simple system.
3.2.3 Stability
This factor identifies how stable is an application before it breaks down and requires an
immediate fix. This is derived by looking at the effort being spent today on the system to
keep it operational.
The Effort hours per application is computed from the average monthly effort consumed in
Production Support for the XXX months.
Effort Factor (EF) = Effort / SCM
The Stability is calculated as follows:
Stability = 1 if EF is less than or equal to 25
Stability = 2 if EF is between 26 and 50
Stability = 3 if EF is more than 50
A Stability rating of 3 is assumed to be least stable with a lot of effort being spent on
reasonable number of change requests and maintenance support calls, whereas, a rating of
1 is assumed to be most stable with minimum maintenance calls and minimum effort spent
on the same.
3.2.4 Analysis Table
Confidential Page 14 of 32
Business
Area # Application Name
Co
mp
lexit
y (
1-3
)
Siz
e (
1-3
)
Siz
e C
om
ple
xit
y M
ult
iple
Eff
ort
(h
ou
rs /
mo
nth
)
Eff
ort
Facto
r
Sta
bil
ity
Siz
e C
om
ple
xit
y F
acto
r
Crit
icali
ty
Logistics
and
Marketing
01 Delivery Document System 3 2 6 0 0 1 2 3
02 LPG Planning Distribution 3 2 6 0 0 1 2 3
03 GTPC 3 2 6 0 0 1 2 3
04 Post Watch 2 1 2 0 0 1 1 2
05 FEP 2 1 3 11 3.6 1 1 3
06 CLC Automation Loading Process 2 1 2 5 2.5 1 1 3
07 Petrogal Automation loading
Process 2 1 2 5 2.5 1 1 3
08 DLS Interface 2 2 4 10 2.5 1 2 3
08 Terminal Installation
09 Site Communications
Retail
10 Retail Card(Cardex) 3 2 6 - - - 2 3
11 Head office(Merchant) 2 1 2 - - 1 1 2
Table 14: Analysis of Applications
The following table summarizes number of applications by each of the three factors
(Criticality, SCF and Stability):
Parameter Degree Count
Criticality
High 25
Medium 22
Low 19
Size Complexity
Factor
Large 5
Medium 21
Small 40
Stability
Low 7
Medium 11
High 48
TOTAL 66
Table 15: Analysis of Applications Summary
Confidential Page 15 of 32
< Please note that above data is for sample only. The actual value will be derived
based on Western European Applications Analysis>
Confidential Page 16 of 32
3.3 Due Diligence Cube
This section would cover the following:
Due-diligence Cube. Depending on the analysis table, all the applications have been
profiled and represented in the form of a cube, which contains 27 smaller cubes each
representing a degree of Criticality, SCF and Stability.
The below given is the Sample of Due-diligence cube which should be prepared for Western
European Project.
DDCube Stability Stability Stability
Low Medium High Low Medium High Low Medium High
Siz
e C
om
ple
xity F
acto
r
Larg
e
5 2 0 1 0 0 2 0 0 0
Med
ium
21 0 2 10 1 2 1 0 1 4
Sm
all
40 1 2 7 2 2 12 1 2 11
3 4 18 3 4 15 1 3 15
66 High Medium Low
Criticality
Table 16: DD Cube Analysis Table
Size & Complexity factor
Small Medium Large
High Medium Low
Criticality
Medium
Low
High
Stability
Confidential Page 17 of 32
DDCube Stability Stability Stability
Low Medium High Low Medium High Low Medium High S
ize C
om
ple
xity F
acto
r
Larg
e 5 2 0 1 0 0 2 0 0 0
Med
ium
21 0 2
DDS/ LPG/
GTPC/Retail
card/DLS Interface
1 2 1 0 1 4
Sm
all
40 1 2 CLC/
Petrogal 2 2
Postwatch /Head office/ FEP
1 2 11
3 4 18 3 4 15 1 3 15
66 High Medium Low
Criticality
3.4 Detailed Application Profile
Please refer to Appendix A for detailed profiles of each application that are included in the
scope of Western European engagement.
Confidential Page 18 of 32
4 Transition Plan and Risk Management
4.1 Transition Approach As there are a number of complex applications across business areas, the ideal approach is to consider transitioning the applications under the scope of BP engagement in two phases. The first phase would contain the logistic critical applications while the second will contain the business ones.
4.1.1 Ideal Transition Approach The ideal approach is to consider all of logistics applications in Phase I and Business applications in Phase II. The logistics applications are critical and must be transitioned first and together.
Phase I Phase II
All Logistics Applications All Business applications
DDS Postwatch
GTPC Terminal installation
LPG Planning Distribution Site Communication
CLC RETAIL CARD
PETROGAL FEP
DLS Interface
Main Risks and Mitigation plan
There are two main risks identified about the system. The first one is there is no functional,
design/technical documention. The other is, only one person is available for knowledge
transfer. If the person is unwilling, unavailable or occupied by other work the transition
would not take smoothly.
We must get the knowledge transfer and, at the same time, prepare documentation.
We must have good relation with third party to get easy and smoothly knowledge transfer,
if it is not possible, we will have to learn the integration of all application from the super
users and from ourselves effort.
4.2 Transition Approach
4.2.1 Recommended Transition Approach
The above approach is build keeping in view the Inter relationship between various
applications and Vendor Dependencies. The above transition would be the recommended
transition.
Confidential Page 19 of 32
Phase I Phase II
All Logistics Applications All Business applications
DDS Postwatch
GTPC Terminal installation
LPG Planning Distribution Site Communication
CLC RETAIL CARD
PETROGAL FEP
4.3 Transition Timeline
This section would cover the following:
High Level Transition timelines
Owner from TCS
Owner from BP
Involvement of Vendor
Post Transition Support
Confidential Page 20 of 32
4.3.1 Transition Activities
This section would cover the following:
The transition activities should be detailed here with ETVX (Entry->Tasks->Validation-
>Exit) criteria. The table below is for SAMPLE only.
Transition Process Detailed activities
Entry Criteria
Detailed transition plan is approved by BP
Crossover criteria is defined and agreed mutually between
TCS and BP
Tasks
(for each Business
Area)
Setup
o Detailed transition plan is approved for each business
area
o Cross over criteria is defined and approved by BP
o Meetings with SMEs scheduled within the business
area
Knowledge Acquisition
o Training
Gather knowledge about the business
area
Learn about the processes, standards
and toolset
Hands-on and meeting with SMEs
Case studies
o Documentation
Prepare Induction manual
Prepare Maintenance manual
Shadow Support
o Learning support process from incumbent (parallel
support)
o Incumbent provides primary support while TCS
shadows
Primary Support
o TCS provides primary support
o Incumbent provides secondary support
Review
o Crossover criteria is met (as in Exit criteria)
Verification &
Validation Obtain sign-off on the maintenance manual
Exit Criteria Review completed and Crossover criteria is met
Maintenance manual is signed off
Work Items
Induction manual
Maintenance manual
Standards and checklists
Estimation guidelines
Study Areas
System Environment
o Batch job details, other software environment details
o Standard and conventions followed by BP
o Security and access controls; error profiles
Maintenance and enhancement processes
o Problem resolution process – once a ticket is raised
o Set up process for onsite and offsite
Confidential Page 21 of 32
Transition Process Detailed activities
o Version control procedures
Application area
o Identify “Hot spots” having high frequency of error
occurrence
o Any additional details that were not captured during
the Due Diligence
Table 17: Transition Activities
4.4 Detailed Transition Plan
This section would cover the following:
Detailed transition plan (MS-Project) for each application or a group of applications
(bundles) that are included in the scope of Western European Application Maintenance
and Support.
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Delivery
documen
t system
Delivery
documen
t system
Delivery
document
system
LPG
Planning
Distribution
LPG
Planning
distribution
Retail
Card and
Head
Office
Retail
Card
Third Party
System
Support
GTPC GTPC GTPC
CLC
Automation
Loading
Process
FEP FEP DLS
Interface
LPG
Planning
distributio
n
Petrogal
Automation
Loading
Process
Third
Party
Site
system
Support
4.5 Transition Risks
Risks Proactive Risk Management Risk Mitigation Strategy
Non-Availability of
Vendor SMEs
during the
knowledge
acquisition
Proactive gathering of information
Induction of Business Analysts to supplement Vendor’s SMEs
Collect any Existing Documentation
Ineffective
knowledge
transfer
To get Knowledge from
super
Users
Interrogate the supplier with more
questions
Investigate the testing
environment
Confidential Page 22 of 32
Insufficient
support requests
during shadow
support
Identify mock problems with the help of SME
Solving mock problems
Learning through history of problem log
Transition
Schedule Slippage Monitoring of early warning
signals
Resources to put in extra hours to speed up transition
Augmenting with additional resources to cope with additional workload
Table 18: Risk Management Plan
5 Service Delivery Model
5.1 Basis for Model Selection
This section would cover the following:
Basis for Onsite-Offshore Model – Hungary as an offshore location and Countries as
onsite locations
Why Hungary? What benefits it drives to the engagement
5.2 Proposed Service Model
This section would cover the following:
Model diagram explaining how onsite-offshore would work
Country-wise Onsite-offshore mix
Country-wise list of people involved and SPOC
How long people are going to be staying onsite during due-diligence, transition, post
transition and service phases
Clearly define the high level process from a user reports a problem until resolution
Clearly define the high level process from a user requests for an enhancement until its
closure
At a high level, what tools will be implemented to support problem logging / reporting
and handling the change requests
5.3 Service Model Organisation Chart
This section would cover the following:
Organisation Structure
Clearly mention SPOC in each country
Clearly mention Project Manager (SPOC) in Hungary
Confidential Page 23 of 32
6 Measuring and Tracking
This section would cover the following:
Service Level Definitions
What tools will be used to support the measurement process and how and by whom they
will be used?
6.1 Definitions
The definitions given here are for SAMPLE only. This needs to be modified as per Western
European Project requirements.
Term Definition
Actual Uptime “Actual Uptime” of a particular System means the portion of Scheduled
Uptime during which all functionality of a System is actually available for normal business use by the universe of end users.
- in hours/month
Availability “Availability” of a particular System means the Actual Uptime
expressed as a percentage of the Scheduled Uptime for such System
- 100 X Actual Uptime / Scheduled Uptime
- Percentage
XXX Alert A communication from XXX that a problem exists
Uncontrollable
Downtime
The aggregate amount of time, (in minutes), during Scheduled Uptime
in any month during which a System is not available for business use
due to: (i) a defect in the applicable hardware or infrastructure, (ii) a
force major event (as defined in the Agreement), or (iii) performance
of Scheduled Maintenance (but only to the extent the downtime is
reasonably required to perform such maintenance). Supplier shall use
best efforts to maintain the Availability of the Systems during Scheduled Maintenance.
- in minutes / month
Scheduled
Uptime
“Scheduled Uptime” means that period of time (days of the week and
hours per day) during which a System is expected to be available to the end user for normal business use.
- Excludes: scheduled and mutually agreed time required for System
Confidential Page 24 of 32
Term Definition
maintenance
- Excludes: Downtime caused by user requests, ABENDs caused by
XXX operations personnel or contractors other than Suppliers, problems external to the system.
- Days of Week & Hours per day.
Measurement Objective criteria by which Service Level performance is measured.
Peak Time Period of time within a System’s Scheduled Uptime when utilization is
at its maximum
- Day, Time
Non-Peak Time Period of time within a System’s Scheduled Uptime when utilization is
at its minimum
- Day, Time
Outage Any instance during Scheduled Uptime in which all functionality of a
System is not available for normal business use for a period of more
than three (3) minutes. “Outage” does not include Uncontrollable
Downtime. An Outage shall be deemed to commence as of the earlier
of the time that unavailability is reported to the help desk or the time
the unavailability is otherwise discovered by Supplier. Supplier shall
notify the help desk of an Outage immediately after Supplier discovers
or otherwise learns of such Outage.
- Count
Problem An unplanned incident that adversely affects the ability of any
individual within the universe of end users to access, use, retrieve data
from, enter data into, or otherwise use a System in accordance with
normal business use. Problems also include incidents in which the
interaction between Systems and applications outside the XXX
environment fails to occur in accordance with applicable specifications
or XXX business requirements (e.g., non-receipt of payment from lock box).
Response Time The elapsed time required for completion of a transaction within the
applicable System. For the sake of clarity, “Response Time” does not
measure throughput relating to system software, network or infrastructure
- Milisecond
Service Level A measurable level of performance that the Supplier must achieve on a
monthly basis.
Severity Level The weight or significance assigned to a Problem based on its impact to
the operations of the business.
Severity Level
1
A Problem with any System, service or loss of access to a work group
that is critical to XXX’ business or any unplanned outage of a service
for which Service Level Credits are applicable in relation to Availability.
Additionally any Problem that has a high profile media / market impact
upon report of the incident shall be treated as Severity 1. Severity 1
Problems will be handled in accordance with channeled communication
processes set forth in the Agreement.
Severity Level A Problem that does not have a high profile media / market impact
Confidential Page 25 of 32
Term Definition
2 upon report of the incident but impacts a critical service (other than
those described as a Severity 1) that affects a large number of end
users or performance degradation to a work group. Severity 2
Problems will be handled in accordance with channeled communication processes set forth in the Agreement.
Severity Level
3
A Problem that does not have a high profile media / market impact
upon report of the incident but results in loss of access or performance
to an individual. Severity 3 Problems will be handled in accordance
with channeled communication processes set forth in the Agreement
Severity Level
4
A Problem other than a Severity Level 1, 2 or 3 Problem. Severity 4
Problems will be handled through appropriately channeled communication processes set forth in the Agreement.
Time to
Acknowledge
The elapsed time between registration of a Problem (e.g., automatic
notification or help desk call) to Supplier and contact by Supplier to
the originator of such registration to acknowledge that Supplier is
aware of the Problem. (Note : No action may have been initiated at this time)
- In minutes
- = t3 – t2 (Refer Problem/Issue Lifecycle diagram below)
Time to Notify The elapsed time between registration of a Problem (e.g., through
automatic notification or help desk call) to Supplier and contact by
Supplier to BTS to acknowledge that Supplier is aware of the Problem.
Unless mutually agreed otherwise, “Time to Notify” shall also include
the frequency with which Supplier must provide BTS with recurring
updates regarding status of the Problem until resolution occurs.
- In minutes
- = t4 – t2 (Refer Problem/Issue Lifecycle diagram below)
Time to
Respond
The elapsed time between registration of a Problem (e.g., through
automatic notification or help desk call) to Supplier and Supplier’s
communication to the originator of such registration as to Supplier’s
solution plan (including diagnostics, solution findings and forecasted
System downtime).
- In minutes or hours
- = t5 – t2 (Refer Problem/Issue Lifecycle diagram below)
Time to
Resolve
Unless otherwise noted, “Time to Resolve” shall be defined as the
elapsed time between the earlier of Supplier’s initial awareness of a
Problem or registration of a Problem (e.g., through automatic
notification or help desk call) to Supplier and the successful Resolution
(i.e., repair or bypass to the end user’s satisfaction, not escalation) of
the Problem. Resolution occurs when the cause has been identified and
corrected and the System is operational in accordance with all
applicable Service Levels. Resolution can occur through a permanent
and/or temporary fix (e.g., workaround, patch). For the sake of clarity,
Time to Resolve ends when such permanent and/or temporary fix
causes the applicable System to be operational in accordance with all
applicable Service Levels.
- In minutes or hours
Confidential Page 26 of 32
Term Definition
- = t6 – t2 (Refer Problem/Issue Lifecycle diagram below)
Table 19: Service Level Definitions
Confidential Page 27 of 32
6.2 Communication Processes
This section would cover the following:
Communication and Escalation process for the following:
o Severity Level 1 Problems
o Severity Level 2 Problems
o Severity Level 3 Problems
o Severity Level 4 Problems
Escalation Path(s) The following table defines the escalation times for unresolved Incidents for different severities. The first table entitled “normal business hours” shows the escalation stages for an Incident occurring within normal business hours for a country or site where service is being received. The second table shows the escalation stages for an Incident occurring outside normal business hours for a country or site where service is being received. The people occupying the various escalation levels may normally work in different time zones from where service is being delivered and from each other. “Wait till normal business hours” in the second table below means wait till normal business hours for the people occupying the 1
st escalation levels in their normal time zone for working and then “start the clock”
for the escalation. Once escalation has started the Service Provider shall continue to escalate using the normal business hours table from this point onwards regardless of the time zone for normal working of the people occupying the upper escalation levels. The Service Provider must not “stop the clock” and must use the time zone where service is being received as the basis for measuring the time intervals.
Business Hours
1st
Level1 2nd Level
Severity 1 Immediate Immediate
Severity 2 1 hour 2 hours
Out of Business Hours
Severity 1 Immediate Immediate
Severity 2 1 hour 2 hours
It is recommended that all metrics and SLAs’ are measured and monitored on a monthly basis (unless mentioned and agreed otherwise). The following methods are recommended.
Monthly reports from TCS to BP.
Escalation Report/Note. This can be a free-format note from the affected group to the applicable next escalation level owner. This would highlight the need and purpose for the escalation. The diagram below depicts the proposed escalation route map.
1 The designated job positions corresponding with the 1
st 2
nd 3
rd and 4
th escalation levels above
should be agreed in writing between the Local Representatives.
Confidential Page 28 of 32
Escalation Path
Unresolved Problem / Issue
TCS O nsite supp
or
ort team
TCS offshore Manager Hungary
Es
cal
ati
on
Pat
h
Confidential Page 29 of 32
7 Additional Information
7.1 Communication Infrastructure
7.1.1 Network Infrastructure
This section would cover the following:
Communication set-up between Hungary and BP offices
The communication infrastructure diagram given below if for Sample only. Please make
specific diagram for Western European engagement.
7.1.2 Data Link
Between BP and TCS Hungary Development Centre
7.1.3 Software Environment
This section would cover the following:
Local PTT
Central Office
Local PTT’s
Exchange
VSNL ITMC
Local
VSNL ITMC
Mumbai/
Chochi
Europe
Transit Cable
Station
Service
Provider
USA
Local PTT’s in-
Country Network
Service
Provider POP
USA
CSU/DSU Router
Server DATA Server
Ethernet
FIBER FIBER
International
Cable Head
FlagTAT 12/13 Fiber
CSU/DSU Router
CSU/DSU Router
TFS Facility in Los
Angeles, USA
(Onsite)
TCS Facility
In INDIA
(Offshore)
Local Service
Provider -
USA
Dedicated T1
(1.54 Mbps)
Firewall
Firewall
Ethernet
Server
Workstation
CSU/DSURouter
Firewall
Server
Workstation
TCS Facility in
Los Angeles, USA
(Offsite) Frame Relay (128 kbps)
Ethernet
Typical Schematic Diagram
Of Connectivity in between
Onsite-Offshore and Onsite-Offsite
TFS Facility in Los Angeles (Onsite)
TCS Facility in INDIA (Offshore)
TCS Facility in Los Angeles, USA (Offsite)
Frame Relay (128 kbps)
Local PTT
Central Office
Local PTT’s
Exchange
VSNL ITMC
Local
VSNL ITMC
Mumbai/
Chochi
Europe
Transit Cable
Station
Service
Provider
USA
Local PTT’s in-
Country Network
Service
Provider POP
USA
CSU/DSU Router
Server DATA Server
Ethernet
FIBER FIBER
International
Cable Head
FlagTAT 12/13 Fiber
CSU/DSU Router
CSU/DSU Router
TFS Facility in Los
Angeles, USA
(Onsite)
TCS Facility
In INDIA
(Offshore)
Local Service
Provider -
USA
Dedicated T1
(1.54 Mbps)
Firewall
Firewall
Ethernet
Server
Workstation
CSU/DSURouter
Firewall
Server
Workstation
TCS Facility in
Los Angeles, USA
(Offsite) Frame Relay (128 kbps)
Ethernet
Typical Schematic Diagram
Of Connectivity in between
Onsite-Offshore and Onsite-Offsite
TFS Facility in Los Angeles (Onsite)
TCS Facility in INDIA (Offshore)
TCS Facility in Los Angeles, USA (Offsite)
Frame Relay (128 kbps)
Confidential Page 30 of 32
Core Network Operating System
Core Load Software
Access to Problem Reporting tool
Access to BP applications
7.1.4 Security Policies
This section would cover the following:
Security requirements e.g. Firewall keeping in view BP security policies
7.2 Problem Management Tool
Proposed Problem Resolution Flow
The proposed interaction of problem resolution is shown below.
This flow is during office hours.
After office hours the flow is as follows.
End user/Business User
Super User TCS Support Team
Application Developer
End user/Business User
TCS Support Team
Application Developer
Confidential Page 31 of 32
Production Services
-Helpdesk
-TFS AppSupport
-NetOps
-Scheduling Ops
Problem Ticket
BTS
TCS Team
Acknowledge Problem Ticket
Notify Work Progress
Respondwith Plan to resolve
Communicate Problem Resolution
Communicate Problem Resolution
Confidential Page 32 of 32