final due-diligence report portugal

Confidential 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 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 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 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 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 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 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 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 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 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 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 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 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



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 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 of 32

< Please note that above data is for sample only. The actual value will be derived

based on Western European Applications Analysis>

Confidential 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 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 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 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


High Level Transition timelines

Owner from TCS

Owner from BP

Involvement of Vendor

Post Transition Support

Confidential of 32

4.3.1 Transition Activities


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 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


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 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


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


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


Organisation Structure

Clearly mention SPOC in each country

Clearly mention Project Manager (SPOC) in Hungary

Confidential of 32

6 Measuring and Tracking


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 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 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


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


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 of 32

Term Definition


Table 19: Service Level Definitions

Confidential of 32

6.2 Communication Processes


Communication and Escalation process for the following:

o Severity Level 1 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 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 of 32

7 Additional Information

7.1 Communication Infrastructure

7.1.1 Network Infrastructure


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


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 of 32

Core Network Operating System

Core Load Software

Access to Problem Reporting tool

Access to BP applications

7.1.4 Security Policies


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 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 of 32

final due-diligence report portugal

Documents