Cut Over Strategy

Author: Ajay Kumar Uppal

Issue Date: 6th April 2006

Project: Beacon

File Ref: Beacon Cutover Strategy V2.1

Issue: 2.1

Approval:

QA Approval:

Authorisation:

page 2 of 21

Abbreviations And Acronyms

Ascential 3rd party products to assist with data migration & cleansing

BCRT Business Capability Resource testing

CGABS Legacy system for large business gas customers (not shared)

CIA Customer, Infrastructure & Application Management) – collective reference for former

Service Delivery

COT Change of Tenancy

CRM SAP product for Customer Relationship Management

EAI - XI SAP product for Enterprise Application Integration (AKA XI)

EDM SAP product for managing meter reading – Energy Data Management

ETL Extract Test & Load (data migration strategy)

FICA SAP product for Finance and Contract Accounting

GT Gas Transporter

HDS Historical Data Store

IAT Integration Acceptance Testing

ICON Industry Interaction Control – system through which L&R is processed

ICS Industry Change of Supplier

IGT Independent Gas Transporter

IS-U SAP product for Industry Standard - Utilities

L&R Loss & re-registration process (see also ICS)

MAM Master Asset Manager

MPR Meter Point Reference

NMS National Metering Service

OAT Operational Acceptance Testing

PPP Policies, processes and procedures

Quality Centre Mercury tool to assist testing (formerly Test Director)

SD Service Desk – part of Oxford Systems – legacy billing system, not shared

TGB Tariff Gas Billing – shared legacy system for ~300,000 non-contract business gas customers

UAT User Acceptance testing

page 3 of 21

1. Table Of Contents

1. Introduction ......................................................................................................................................................... 4

1.1 Summary, Scope And Objectives .............................................................................................................................. 4

1.2 Cutover definition ........................................................................................................................................................ 4

2. Purpose ............................................................................................................................................................... 5

2.1 Approach ...................................................................................................................................................................... 5

2.1.1 Strategy & planning .................................................................................................................................................. 5

2.1.2 Cutover Team ........................................................................................................................................................... 5

2.1.3 Cutover Rehearsals .................................................................................................................................................. 6

3. Cutover Strategy ................................................................................................................................................. 7

3.1 Key principles of cutover........................................................................................................................................... 7

3.2 Key features of the Beacon Programme: .................................................................................................................. 8

3.3 Domain Responsibilities for Cutover & Implementation ......................................................................................... 8

3.3.1 Deployment Domain ................................................................................................................................................. 8

3.3.2 IS Readiness Domain – cutover workstream ............................................................................................................ 9

3.3.3 Data Migration Domain. .......................................................................................................................................... 12

3.3.4 Billing Confidence and Finance .............................................................................................................................. 12

3.4 Dependencies ............................................................................................................................................................ 12

3.5 Check points, quality gates and go/no-go criteria ................................................................................................. 13

3.5.1 Quality Gate 4 ......................................................................................................................................................... 13

3.5.2 Quality Gate 5 ......................................................................................................................................................... 14

3.5.3 Success Criteria & closure of Cutover activity ........................................................................................................ 14

3.6 SAP Technical Audits ............................................................................................................................................... 14

4. High-level timeline ............................................................................................................................................ 14

4.1 Sequences, Dependencies and Milestones ............................................................................................................ 15

5. Cutover process ............................................................................................................................................... 16

5.1 Cutover workshops ................................................................................................................................................... 16

5.2 Cutover Plan Management ....................................................................................................................................... 16

5.3 Interim Procedures .................................................................................................................................................... 16

5.4 Business Manual procedures ................................................................................................................................... 16

5.5 Read only systems availability during downtime................................................................................................... 16

5.6 System availability after the successful go-live ..................................................................................................... 17

5.7 Business Contingency Plans ................................................................................................................................... 17

5.8 Business Continuity .................................................................................................................................................. 17

5.9 Cut-Over log ............................................................................................................................................................... 17

5.10 Cutover contact & escalation procedures ............................................................................................................. 17

5.11 Status meetings ......................................................................................................................................................... 18

5.12 Cut-Over validation process ..................................................................................................................................... 18

5.13 Post Go-live tracking................................................................................................................................................. 18

5.14 Legacy Retirement .................................................................................................................................................... 18

5.15 Go-Live Support ........................................................................................................................................................ 18

page 4 of 21

6. Assumptions ..................................................................................................................................................... 19

7. Next steps ......................................................................................................................................................... 20

1. Introduction

1.1 Summary, Scope And Objectives

.

This document sets out the key features of the Beacon Cutover strategy. Its primary objective is to ensure that the numerous

parties, organisations and individuals associated with the Beacon Programme share a common understanding of what

cutover entails and the roles and responsibilities of each party in ensuring that cutover is a smooth, error-free, repeatable and

sustainable process.

.

This document is applicable to all parties involved in the process including the Beacon Project Team comprising both Wipro

and BGB representatives, 3rd party application suppliers, IS CIA, as well as each area of the business involved with or

impacted by the change. This document will lead to a detailed cutover plan which will demonstrate how and when the detailed

tasks will be undertaken - and who will be responsible for carrying them out - to implement both the technical (i.e. system)

aspects as well as the business (i.e. deployment) aspects of the implementation. The cutover plan will identify the detail

tasks that are to be undertaken by each of the parties concerned, and will be integrated into the SAP Beacon Programme

Plan.

This strategy is only concerned with those activities currently nominated for inclusion in Release 1 (gas) of the Beacon

Programme.

1.2 Cutover definition

Cutover is the last stage of Phase 4 of the ASAP project implementation methodology -“Final Preparation”. This is typically

illustrated in the ASAP roadmap reproduced below.

Cutover planning starts at the same time as Final Preparation which itself normally coincides with Integration Acceptance

Testing (IAT) and Data Migration Testing. By the time that both of these activities have been completed, the detailed cutover

plan should be in place, and will coordinate the remaining key activities leading up to successful deployment including UAT,

end user training, cut over rehearsals, OAT (including acceptance by CIA) and, finally cutover itself.

page 5 of 21

2. Purpose

The cutover strategy and subsequently the cut-over plan describes how BGB will continue to carry out business as usual

whilst making the transition from existing systems to the implementation of the Beacon system. It also describes the process

to ensure that the technical preparations necessary to implement the Beacon solution can be carried out in the required

timescale and with the available resource.

It is essential that whilst implementation takes place disruption to the business is understood, mitigated against, and any risks

that are identified are shared with the relevant business areas and actions taken to minimise impacts. It is essential that both

the IS Transition and the Deployment Team understand their activities within the cutover plan and how these will contribute to

successful transition.

The cutover strategy also deals with the work necessary to ensure that the Beacon system and all of its components is of

sufficient quality to ensure that following cutover the system can be taken over by IS CIA for daily and all other periodic

operations

2.1 Approach

2.1.1 Strategy & planning

This document is a high level strategy aimed at agreeing the principles under which cutover will take place. Following this a

detailed Cutover Plan will identify all procedures, sites, legacy systems and processes which will be impacted in one way or

another by the implementation of Beacon: this will include the need for interim processes both over the cutover period itself

and for any extended period during which both legacy and Beacon systems will be in place. Many current work activities will

move to the SAP system although some processes may depend on the ability to reference legacy systems or on the

existence of an Historical Data Store and it will be necessary to ensure that all work activities are analysed and any MIS and

regulatory reportable items are managed to ensure that business as usual is maintained as far as possible.

There will also be system implications regarding interfaces and retirement of current systems. The plans of the Sunset and

Dependency teams need to be aligned to set out how, including interim modifications such as file splitters and interfaces will

be transitioned during the period in which both legacy and SAP systems will interact with external systems such as Payment

Director, QAS, BACS, etc.

2.1.2 Cutover Team

The Beacon Cutover team has been established as a workstream within the IS Transition Domain.

Since the Beacon project encompasses a particularly wide scope of in terms of impact in both business and technical issues,

the Cutover Team has been established with principal areas of speciality as follows:-

Beacon IS Cutover Manager: Management of transition of solution into CIA and coordination of all 3rd party cutover

activities including integration

Beacon Implementation Manager: single point of contact with Beacon Deployment team to ensure that all business

cutover activities are included in cutover planning

Both of the above roles will be supported by their counterparts from the Wipro organisation.

The above Cutover team will be supported by Cutover Partners who will, between them, represent all detailed areas of the

business and IS, who need to be involved with, or are impacted by, the transition process. An important step following

publication of this cutover strategy will be the identification of all cutover partners (COPs) and to agree their specific roles and

responsibilities. It is envisaged that COPs will be required to be responsible for each of the following areas:-

Each affected site (e.g. Leicester, Staines, Oxford, Cardiff)

page 6 of 21

Overall data migration readiness, with COPs responsible for each key data segment

Business readiness for each key process area and business directorate

IS Readiness (with responsibilities for technical acceptance, CIA, Infrastructure, Security, Monitoring, Support and

Operational Planning)

Third party systems suppliers and interfaces (“dependencies”)

Interim processes

Finance

Training & documentation

Organisational Change

Communications

Legacy Systems including updates, rerouting or closure.

Business Continuity

Wipro knowledge transfer (business process and IS technical/build expertise)

.

2.1.3 Cutover Rehearsals

An important principle is that extensive rehearsals of the activities to be included in the final cutover will take place in the

period leading up to cutover. These will comprise walkthroughs (paper-based simulation of individual cutover activities) right

through to full dress rehearsals, where all activities will take place in strict chronological and time-constrained circumstances

which will apply to the actual cutover itself. 3 full rehearsals will be required to provide sufficient confidence to proceed with

the actual cutover itself and it has yet to be determined whether separate rehearsals will be held for data migration activities

or whether these will be scheduled to take place alongside cutover rehearsals. Cutover rehearsals will also be include

deployment of code and file splitters in 3rd party and legacy systems where it is not possible to deploy these before the actual

cutover event itself.

The cutover team will determine the exact activities to be included in each cutover practice during detail cutover release

planning. However, the following tasks are expected to be included in all rehearsals:-

Building and pipe cleaning the production environment

Loading SAP software , manual configuration and static data load

Integration with pre-production (i.e. test) environments of 3rd party and legacy systems

Analysis and coordination of detailed event timings

To be determined: Practice of business readiness activities as determined by the deployment team

To be determined: Test loading of migrated data under the ETL methodology

The last two items will be covered in more detail in the Business Cutover Strategy and Data Migration Cutover Strategy

respectively.

A key principle of cutover practice is “Nothing which is unrehearsed or untested will be allowed to be part of live cutover”.

“The more I practice, the luckier I get” Gary Player, champion golf professional

.

page 7 of 21

3. Cutover Strategy

The fundamental focus of this cutover strategy in association with the cut-over plan is to successfully deploy the SAP Beacon

Programme with minimal disruption to the business, including revenue flows, while ensuring that the system meets the quality

and support standards required by IS CIA. Given the extended duration of transition (brought about by there being more than

one data migration event), it is equally important that there are clear responsibilities for the support of new, legacy and interim

systems during the entire transition period.

3.1 Key principles of cutover

There will be one cutover master plan managed by the Beacon cutover team, supported by detailed cutover

activities for each area of individual Cutover partner (COP) responsibility. Cutover Partners will be grouped into

deployment, data migration and IS transition areas of responsibility. The Master Cutover Plan will feed into the

overall Beacon Programme Plan.

We will cutover as much as possible before go live. For example, changes to legacy systems which will be required

to recognise and split transactions between Beacon and legacy systems may be able to be implemented ahead of

go live itself. Such changes will have no impact on live operations until after such new codes begin to be generated

or utilised by Beacon and therefore can be implemented (and tested) ahead of go live itself.

We will establish a series of checkpoints leading to a final “Go/No-go” decision immediately prior to go live. The

criteria for these checkpoints will be agreed in detail between the Beacon cutover team, individual COPs and the

Beacon Programme Board and will comprise a series of acceptance criteria. Where related to Business readiness,

these checkpoints will be managed under the BRAT process.

There will be a contingency plan detailing alternative actions to be taken in the event that either any of the above

acceptance criteria have not been met or if external factors impact the expected operating baseline for the

programme. Note that although it is important for such detailed contingency plans to exist, it is not usually part of

cutover practice to exercise these extreme contingencies themselves.

Each contingency will be assessed by its probability, impact, description of detailed trigger point and mitigating

action.

Existing business continuity plans will be reviewed in the light of revised Beacon processes. A gap analysis will be

produced by a dedicated business continuity team (working under the Beacon Implementation manager) and revised

business continuity processes devised in conjunction with business representatives where necessary. The revised

business continuity processes will be agreed by October 2006 and ready for deployment immediately upon go live in

January 2007.

There will be a backout and recovery plan in the event that deployment is temporarily unsustainable immediately

following go live, or should an unmanageable backlog develop in immediate post-go live processing. The data

migration strategy will deal with any additional problems which may arise out of a failure of the proposed data

migration method or timings.

There will be 3 cutover rehearsals in which, as a minimum, all technical IS steps to enable all components of the

Beacon solution to be put into live production will be practised.

There will be a hard code and business change freeze effective from the start of UAT (November 2006). No changes

will be made to the Beacon solution after this point unless deemed by the programme board to be “showstoppers”

(to be further defined as part of the go/no-go criteria).

Application code will be frozen as at 27th October following OAT and IAT3 cycle 1. This code set will be used to

populate both the production live environment (to be used for BCRT and Performance testing) and the appropriate

QA environment to be used for UAT from 30th October

BCRT (Business Capability testing) activities scheduled for November 2006 will take place under a pseudo

production live environment, to provide confidence both to the IS CIA support operation and to the business users

that the system is capable of being run under live conditions.

page 8 of 21

3.2 Key features of the Beacon Programme:

The unique aspects of the Beacon Programme which need to be specifically addressed as part of cutover are as follows:-

Requirement for Interim Processes

As a consequence of the phased data migration approach, a number of interim processes will need to be put into place to

manage the customer base during the transition period. Contact handling procedures will need to be agreed depending

whether the customer was originally managed under the TGB, CGABS or SD systems and whether they are dual fuel

customers in the period until which the electricity customer database is also migrated to Beacon (release 2) Design and

definition of these processes is well under way, but each will need to be tested, and users trained, in the run up to cutover.

Decisions also need to be made regarding the use of the HDS or whether users will need to access legacy systems during

and after the transition period.

Requirement for interfaces to many external and legacy systems

Beacon Release 1 will primarily replace 3 legacy systems (CGABS, Service Desk (“SD”, part of the Oxford systems) and

TGB) . Once again, due to the extended period of migration, interfaces and other transactional data will need to be split

between legacy and Beacon systems depending on whether a particular customer or group of customers has, at that time,

begun the migration process. Depending on the final data migration strategy agreed, this may further complicate the cutover

and transition process

Implementation into a changing environment

With the Jupiter programme proceeding in parallel with Beacon, while there may be some benefits in terms of lessons learned

and re-use of tools and migration objects, the existence of another large programme rollout inevitably places constraints

(resource, time windows, flexibility of changes to legacy systems) on the Beacon cutover.

Single Customer View

Data is being migrated from 3 different legacy systems and therefore there will be differences in the quality and scope of data

available for each system. To rectify this, a sub project called Single Customer View is designed to ensure that the data when

migrated to SAP is consistent and sufficiently detailed, such that it will be eventually transparent regarding from which system

the data originated

Historical Data Store

SAP Best Practice is to migrate as little data as possible when switching to the IS-U billing engine and supporting products.

This strategy has been followed for Beacon but with the result that it has been necessary to build a repository into which non-

SAP data pertaining to the period prior to the Supply start date can nevertheless be interrogated after legacy systems have

been shut down. This data is necessary to support, for example, customer restatements where corrected meter readings are

received for earlier periods. The deployment team will need to ensure that Customer service agents receive clear training

regarding the handling of customer queries and requests for information during the transition period.

3.3 Domain Responsibilities for Cutover & Implementation

Governance for the Beacon programme is organised into a number of Domains. Three of these will have the majority of

involvement and interaction with the cutover process, being Deployment, IS Readiness, and Data Migration. In addition,

Finance and Test & Fix domains will have important direct involvement in certain activities leading to a successful cutover.

The primary responsibilities of each domain are described below:-

3.3.1 Deployment Domain

. The Deployment team is responsible for the following key business activities:-

End User training & documentation

Organisational Change Management

Management of Interim Processes

page 9 of 21

Individual site readiness

Communications

UAT

Overall business readiness

Business Cutover Strategy and Planning

A Business Cutover Strategy dealing with the above activities will be produced by the deployment team. This will be

complemented by a detailed business deployment plan and business readiness cutover plan. The Beacon Implementation

Manager within the Cutover Team will liase with the Business Readiness Managers in the Deployment team to ensure that

these plans are coordinated within the master cutover plan.

.

Communications Plan

To ensure that all parties are kept fully informed, a communication plan will be developed within the deployment team to

cover communications with each of the following parties and organisations:-

Customers

Suppliers

Beacon Project Team

Sponsors & stakeholders

Users

Industry participants

Other industry bodies e.g. Energywatch, Ofgen

Business generally

A single point of contact (“communication lead”) will be appointed within the deployment team to manage all communications.

The Cutover team, via the Beacon Implementation manager, will keep the communication lead informed about cutover

activities affecting any of the above parties to ensure that the appropriate information is conveyed to the affected party.

Equally, the communications lead should ensure that regular feedback regarding the perception and acceptance of the

Beacon Programme is communicated back to the Programme team.

3.3.2 IS Readiness Domain – cutover workstream

The cutover workstream within the IS Readiness domain comprises 2 specific roles: IS Cutover Manager and Beacon Implementation manager, both of which are shadowed by their equivalent counterparts in Wipro.

.IS Cutover Manager

The IS Cutover manager is responsible for ensuring that the Beacon application solution is transferred smoothly from its project-based development into the Centrica IS CIA support department structure. This is to be achieved without any impact to BGB BAU business and IS operations, whilst maintaining the Beacon solution delivery which will be signed off at the Programme Go No Go meeting

The main accountabilities of the Beacon IS Cutover manager are as follows:-

To plan and manage, with the assistance of Wipro technical experts and the IS transition manager, the IS CIA aspects of the cutover of the Beacon solution into production live.

page 10 of 21

To ensure the delivery of a supported Beacon server infrastructure that can support the Beacon SAP application service according to the agreed Beacon IS Service Contract (SLA). Where 3rd party systems or interfaces are involved, the Dependencies workstream within the IS Readiness domain will arrange for the required facilities, resources and systems to be made available for rehearsals and cutover itself.

To recommend to the IS Readiness Domain lead that the infrastructure and CIA support elements of the Beacon solution are ready for production service.

To recommend to the IS Readiness Domain lead that the IS cutover plan with all risks mitigated is valid for use.

The specific responsibilities of the IS Cutover Manager are as follows:- Stage manages all IS activities from end of OAT and UAT stages until 1 week into Post Implementation

support Owns the IS go live plan including individual release plans and software cutover plan Ensures that the IS CIA SAP Enterprise Management Services and SAP Applications Management

teams conduct a SAP technical audit review of the final Beacon environment configuration and infrastructure.

Confirms with the appropriate IS CIA technical support teams that the software code base for SAP and non SAP elements has met their required standards and is supportable

Ensures that the delivery & support for all environments including production, pre-production, training and data migration environments pre cutover and immediately post go live (software cutover + 1 week) is provided by the relevant IS CIA technical teams.

Owns the IS CIA cutover of the new Beacon system into production including any subsidiary cutover phases and interfaces.

Owns the IS CIA planning, resourcing and management of software cutover and rehearsal activities. Ensures specified IS CIA implementation and cutover quality standards are achieved. Ensure IS CIA criteria for QG4 are met Ensures all cutover activities conform to IS best practice Create & maintain technical back-out and contingency plans Manage IS CIA cutover dependency register Ensure all IS CIA QG5 requirements are met Ensure availability of 3

rd party suppliers’ systems for rehearsal and cutover activities

Establish IS checkpoints & go/no go criteria Identifies & secures IS CIA resources required for pre cutover, cutover and post cutover (cutover + 1

week) activities. Proactively resolve all IS CIA issues and risks associated with IS cutover Manages IS CIA risk & issue register and escalates those risks via the IS Readiness Domain Manager Manage IS CIA release manager activities Ensures that a detailed IS CIA cutover log is maintained by all concerned Arrange for "copy live" system if required to support business as "read only" if any significant downtime is

required . This will be done only if design activities are required, therefore an implementation responsibility is required

Ensure that OAT planning takes account of the subsequent implementation requirements of the agreed Beacon cut over plan

Monitor that Centrica IS security standards are being adhered to at the appropriate level for Infrastructure, Environment (via the IS Readiness process) and Application Build and Data Migration (via the Design and Build and Data Migration domains)

Beacon Implementation Manager The Beacon Implementation manager is responsible for the following:-

Responsible for IS Readiness domain interface with other domains for all cutover issues.

Coordination of the overall SAP cutover strategy for the Beacon Project, ensuring business case deliverables are achieved to plan, and interim processes are in place

Maintain overall cutover plan, with inputs from IS, deployment & data migration teams, covering all transition activities up to and including go live and for a period afterwards until “steady state” operation is achieved.

Establish escalation routes and procedures for all cutover activities

Manage overall cutover dependency register

page 11 of 21

Ensure all non-IS criteria for QG5 are met

Manage interaction impacting cutover with other Centrica change planning activities and Beacon design authority

Establish regular checkpoints leading to cutover covering all workstreams

Proactively resolve general issues and risks associated with cutover and transition and highlight conflicts between workstreams

Working closely with the Deployment team in general, and the Business Readiness managers in particular, to ensure the following:- Manage process for agreement of how user support and management of exceptions are handled between IS

support and business operations Agree legacy system retirement plan with IS and business via BR managers Ensure non-IS criteria for quality gate 4 are met Coordinate back-out and contingency activities between IS and business via BR managers Establish, with BR managers, cutover partners for each area of implementation (geographical site, data owners,

process owners etc) and publish agreed resource plan Agree systems outage with business for rehearsal and cutover activities via BR managers Ensure business continuity objectives are achieved as “BAU” processes are transformed to the Beacon

processes Coordinate input to overall communications plan regarding cutover activities

Wipro support for Cutover The counterparts to the IS Cutover manager and Beacon Implementation manager provided by Wipro will, as a minimum, actively engage in Beacon Release 1 cutover and implementation activities as follows:

Detailed cutover, rehearsal, release and post implementation planning. As part of Quality Gate 4 signoff, demonstrating that the solution meets business requirements and technical

specification and is supportable exclusively by Centrica Rehearsal and cutover execution including all associated meetings Provision and support of data migration activities including data migration rehearsals as defined in BW118 Provide required skills transfer to Centrica skilled staff as defined in the signed off BW280 Skills Transfer

document Provide required skills transfer and support to Centrica skilled staff as defined (and to be refined) “Wipro

Approach to support for deployment V2.0” in particular in the areas of training, process transition and business readiness

Ensure that the relevant work products for Phase 5 – implementation owned by Wipro are delivered in a timely manner.

Subscribe and support the achievement of Phase 5 implementation acceptance criteria.

Subscribe and support agreed post implementation tasks and support process

Contingency & Backout Planning

The cutover plan will identify the need for contingency procedures for unplanned events or if any acceptance or go no-go

criteria cannot be fully met.

A template will be produced by the Cutover team, and this will be used by the Cutover Partners(COPs) to document the

issues, costs, advantages and disadvantages when a failure is identified. This template will be produced by the end of June

2006. Once the template has been populated by the relevant COP it will be assessed and any decisions will be made by the

Beacon Programme Board.

One of the first contingencies to be established is an alternative acceptable date for go live if, for any reason, the currently

assumed date is missed for any reason.

Resourcing Plan

All key personnel – including Beacon team members, COPs, general business resource, IS specialist technical expertise and

third party software suppliers, need to be identified in the early stages of developing the cutover plan to ensure that they are

available during the critical periods of activity leading up to go live, but also including important earlier activities such as

page 12 of 21

rehearsal walkthroughs and execution. Back up, or multi-skilled team members need to be identified or trained to ensure that

critical activities can still be carried out even in the event that the main team member is unavailable for any reason.

Business Continuity

It has also been agreed that responsibility for business continuity planning for changes brought about by Beacon is the

responsibility of the Beacon Implementation Manager within the cutover team

3.3.3 Data Migration Domain.

Successful data migration is frequently the key factor in a successful transition, and in the Beacon Programme , given the

complexities and extended timescale of the migration programme, this is particularly relevant. It is therefore important that a

detailed data migration strategy and cutover plan is developed to focus on the detailed activities and timings associated with

the whole data migration strategy. Although guidelines and assistance will be readily available from the Cutover team, the

development of the detailed data migration cutover plan is the responsibility of the data migration team. A draft data migration

cutover strategy containing the following proposals is required by the Cutover team by mid April 2006 in order to ensure that

the overall cutover activities are properly planned and coordinated:-

High level analysis of customer demographics leading to an initial proposal for migration profile

COPs, agreed with the deployment team, for each area of data responsibility

Proposals for business sign off of data objects or groups of data, following each rehearsal and the go live cutover

event itself

Requirements for any static data to be loaded ahead of cutover

Any requirements for manual data load, either during rehearsals or at go live

Requirements for rehearsals during the cutover practice period

3.3.4 Billing Confidence and Finance

There will be an additional testing phase specifically to provide confidence that Beacon is capable of providing an accurate,

consistent and repeatable cycle of billing activities. This testing activity will be managed by the Test & Fix domain with

appropriate input and resource from the business.

Similarly, all required finance functionality, as well as data feeds to and from the legacy R3 finance modules will be verified by

the Finance team assigned to the programme

3.4 Dependencies

The cutover strategy and more importantly the cut-over planning has a clear dependency on the delivery of the SAP system,

hardware and satisfactory completion of all testing including UAT. The following specific dependencies exist:-

Data migration build and testing must be sufficiently advanced by end October 2006 to enable representative data

from both TGB and CGABS to be utilised in performance testing and UAT

CIA Acceptance Testing (OAT) completed and signed off by 16th October 2006

IAT3 cycle 1 completed, with defect levels within tolerances as defined in the Acceptance Criteria, by 27 th October

2006

Availability of production environment for rehearsals and actual software cutover. Specifically:-

o Rehearsal 1: 21st August 2006 (environment required 2 weeks before for preparation)

o Rehearsal 2: 27th October (preparation begins 16/10/06)

o Rehearsal 3: 27th November (client data clear down takes place over weekend of 24/11)

o Go live event: 11th December 2006

page 13 of 21

Hard code freeze in place from 30th October 2006

Availability of suitable pre-production or application maintenance environments on all impacted legacy , 3rd party

systems and interfaces

Training to the proposed schedule should be completed ready to enable customers to be migrated on to Beacon

from 1/1/07.

Gas Industry Accreditation Testing completed and signed off

User Acceptance Testing started on 30th October 2006 and completed , and signed off, by 22nd December

Desktop XP rollout completed without interference to any cutover preparation activities

Alternative found to use of existing Acorn XI server for Beacon production system

3.5 Check points, quality gates and go/no-go criteria

In addition to the regular project status reports, we have opportunities to gauge project readiness at notable milestone events.

These check points will be identified within the cutover plan. At each ‘check point’ we will evaluate the readiness and should

a check point not be running to schedule this will be identified as part of the weekly project status report delivered by the

Cutover Team. Progress will be monitored by the PMO and any areas of concern that cannot be rectified by the Cutover

Team will be escalated to the Beacon Programme Board.

The ‘check point’ meetings will have clear measurable guidelines to allow informed agreement by the Beacon Programme Board to proceed with the implementation of the system. The checkpoint meetings will be based around agreed Go/no-go criteria (“GNG”) and it has been agreed that the deployment team will own the overall GNG criteria, with input regarding the specific IS criteria to be provided by the cutover team. The overall GNG will be refined and correlated with BRAT and Quality Gate 4 criteria by the Deployment team. It has been agreed that the IS Readiness manager will take responsibility for ensuring that Quality Gate 4 criteria are achieved. The programme will adhere to the quality gate principles and the following specific quality gate criteria will form part of the GNG criteria and checkpoints at the appropriate time:-

3.5.1 Quality Gate 4

Are all aspects of testing criteria met and approved for implementation, with test results confirming that the system will behave predictably under normal conditions?

Are IS and the Business confident that the support arrangements will meet requirements?

Are any amendments to operational procedures (Business and IS) documented?

Is training adequately delivered to enable the change to be accepted and supported once it has gone live?

Is knowledge transfer adequately delivered to enable the change to be accepted and supported once it has gone live?

Are all “go/no go” criteria signed off with the recommendation being to proceed to implementation?

Are implementation windows confirmed?

Is there a robust plan for implementation with committed resources?

Is there evidence of positive change leadership giving confidence that change will be embedded?

Are there any risks that will jeopardise the implementation and operation of the solution?

Does the proposed solution comply with Centrica’s minimum standards for Information Security & Business Continuity? For any material risk / area of non-compliance has an action plan been identified & agreed by the Project / Programme Board?

Are key risks, assumptions, issues, dependencies and inter-relationships (RAID) still clearly understood & managed, with mitigating actions and agreed owners – including Legal, Privacy, Regulatory, Continuity, Security and those relating to other policies"

Has the baseline/scope been reviewed to take account of any external / environmental changes so as not to proceed with invalid assumptions?

Are actual costs still within the plus/minus 10% tolerance of those within the Business Case, with any variation investigated and explained?

Do benefits still align to original objectives/vision and are they still valid, owned and on track to be delivered as anticipated?

page 14 of 21

Is the Business Case still viable?

Is project performance to date on track to meet the performance criteria, with any variance explained, understood, mitigated and signed off?

3.5.2 Quality Gate 5

.

Is the system live, in use, and meeting the Service Level Agreement (SLA)?

Is support of the system operating according to the Support Model and Operational Procedures (IS & Business)?

Have de-commissioning plans got clear ownership and have they been mobilised?

Has the operational owner accepted responsibility for day-to-day operation, maintenance and support of the change?

Are project acceptance criteria complete and signed off?

Is the Benefits Realisation Plan finalised and passed to the Benefits Owner/Project Sponsor to deliver the benefits expressed in business case?

Is an action plan in place for any/all material Business Continuity and Information Security risks / areas of non-compliance?

Are project risks and issues and containment activities successfully managed, accepted and closed?

Is a Project Closure Report completed and signed off, including identification of lessons learned?

Is the overall project performance assessed, with any variance explained, understood, mitigated and signed off?

Is the Post Investment Review owner agreed (if applicable)?

3.5.3 Success Criteria & closure of Cutover activity

The work of the cutover team will be deemed complete when the quality gate 5 criteria above have been achieved, or have

moved to an acceptable level of progress, with the exception of any issues remaining open for the purposes of an extended

data migration schedule.

3.6 SAP Technical Audits

It is normal practice to ask SAP to undertake 3 separate technical validation sessions during the final preparation phase as

part of the quality assurance procedure. The first of these is a Technical Integration Check (TIC) which normally takes place

towards the end of Integration testing. The second (pre go live check) is normally scheduled between rehearsal 3 and the go

live event itself and is targeted for early November 2006. Finally there is a post go live tuning and optimisation session.

Checks 2 and 3 will be included within the cutover plan and all 3 sessions need to be managed and organised by the Design

& Build team.

4. High-level timeline

The following chart provides an indication of the activities involved in cutover. The precise timing, content and frequency of

each activity is still under discussion and will be finalised during detailed cutover planning.

page 15 of 21

20

-Ma

r

27

-Ma

r

03

-Ap

r

10

-Ap

r

17

-Ap

r

24

-Ap

r

01

-Ma

y

08

-Ma

y

15

-Ma

y

22

-Ma

y

29

-Ma

y

05

-Jun

12

-Jun

19

-Jun

26

-Jun

03

-Jul

10

-Jul

17

-Jul

24

-Jul

31

-Jul

07

-Au

g

14

-Au

g

21

-Au

g

28

-Au

g

04

-Se

p

11

-Se

p

18

-Se

p

25

-Se

p

02

-Oct

09

-Oct

16

-Oct

23

-Oct

30

-Oct

06

-No

v

13

-No

v

20

-No

v

27

-No

v

04

-De

c

11

-De

c

18

-De

c

25

-De

c

01

-Jan

08

-Jan

15

-Jan

Cutover

Cutover strategy draft

Cutover strategy agreed 7*4

IS Cutover Plan prep Prepare

IS Cutover Plan agreed 20*4

IS GoNoGo Criteria agreed 28*4

Master Cutover Plan publish Prep 14*6 - agreed Revise Revise

Contingency Plan Prep 28*6 - agreed

Backout/Recovery Plan Prep 26*7 - agree

Go Live Release plan Prep Draft Revise Revise FINAL - 5*12

REH 1 Execute 21-23*8

REH 1 PIR

REH 2 Execute 27-29*10

REH 2 PIR

Software cutover- Prod 30-31*10

Hard Code Freeze 27*10 X

Check site infrastructures

REH 3 Execute 27-29*11

REH 3 PIR 30*11

Go Live walkthroughs 28*11 4*12

Go No Go Meetings 6-7*12 28*12

Beacon Ready for

Production Live Cutover 11-12*12

Cutover Contingency X 18-19*12

Beacon Ready for Prod

Live to Business 1*01Beacon Business

Production Live 15*01???

Prod Platform under BAU support Prod under BAU Support

OAT/High Vol 1 & High Vol 2 Executed on Prod OAT2 & Hi Vol 1 Hi Vol 2

BCRT on Prod Executed on Prod BCRT

IAT 3 Cycle 1 on test env IAT3 C1 C2

UAT on test env UAT

Other Test Cycles on test env Billing Confidence & Data Migration

Key deliverables

100% ETL

data

150% ETL

data

4.1 Sequences, Dependencies and Milestones

For the purposes of this document the proposed ‘high level’ steps illustrate some detail of the cutover plans. The summary

steps are as follows:

April 7th 2006 – Cutover strategy agreed and signed off

April 28th 2006 –Provide IS go no-go criteria to deployment team as overall GNG criteria owners

April-June 14th 2006 – development of detailed master cutover plan and COP plans

May 2006 – development of business cutover plan

June 2006 - development of contingency plans

July 2006 – development of Backout plan

July-August 2006 – 1st Dress rehearsal – adjust all plans from lessons learned

October 2006 – 2nd Dress rehearsal – adjust all plans from lessons learned

November 2006 – final dress rehearsal – final cutover plans settled

7th December – Final go /no-go decision

13th December – Beacon ready for live

page 16 of 21

5. Cutover process

5.1 Cutover workshops

Following agreement of the Cutover Partners (process, site, data etc) workshops will be held with groups of COPs and their

teams to ensure that all work activities in which they are likely to be engaged as part of cutover are known and documented.

A plan detailing when these workshops will be created by the cutover team, with the workshops being run from April 2006. .

In particular, the BGB Technical Cutover manager will conduct a series of meetings and workshops with the IS CIA team to

agree the IS readiness plan, SLA and handover conditions.

Workshops will also be held with representatives of the deployment team and, at their request, appropriate business

representatives. One key output from the business workshops will be the identification of main activities leading up to cutover,

including activities which need to be practiced at the same time as the technical cutover rehearsals and those activities which

instead will take place on a continual basis (e.g. structured practice exercises in a “model office” or “play pit” environment.

(TBA). It will then be the responsibility of the COPs and the Beacon cutover team to work through how these business and

technical processes will be successfully managed. Any workarounds that are needed will be communicated and any resource

implications identified to the business.

5.2 Cutover Plan Management

The Cutover Plan is a living document and (after having been agreed by the Programme Board and baselined by the PMO)

will be updated on a continual basis as we progress through the various stages of the project. The Beacon Cutover Team will

communicate any risks to the milestones as identified above to the SAP Beacon Programme Board. Any impacted

stakeholders and COPs will also be kept informed on a regular basis via the routine programme of meetings already in place.

Prior to the cutover event itself, an Operational Cutover Plan (BW258) will be produced as an amalgamation of the detailed IS

and Business release plans.

5.3 Interim Procedures

All interim business procedures, whether required solely to cover any period of interruption to BAU legacy system during the

cutover period, or for longer term until all data has been successfully migrated from legacy, will be analysed as per the

cutover process above. The COP responsible for interim processes will ensure that the relevant resources identify and plan

all tasks relating to interim systems, interfaces and other IT processes as they are required and that all activities relating to

cutover are practised before the cutover event itself.

5.4 Business Manual procedures

There may need to be a period of business downtime whilst data is migrated into the Production system or while changes are

made to legacy systems. This time is currently unclear, however once the timings are known more precisely this will be

further refined. Once detailed timings are known through migration and testing it will be possible to say how long each activity

will take and then procedures can be put in place to minimise disruption including revenue flows. To ensure that the business

is able to continue as effectively as possible, a plan will be created as identified above (detailed cutover plan). Once the

system is a read only facility, either current documented manual systems or locally agreed manual business process will be

implemented. Where a manual system does not currently exist a process will be designed to record the necessary

information to be replicated into SAP once cutover is complete. The workshops detailed in 5.1 will give timelines on this

activity.

5.5 Read only systems availability during downtime

If necessary, the cutover team will endeavour to provide a read only (copy live) system to allow the business to make

enquiries during the period of the transition is available for all systems which would otherwise be unavailable for any

page 17 of 21

significant period during any stage of the transition. All systems access should be specified during the workshops described

in 5,1 above. These systems will not allow transactions to be committed into them and will only be used as reference

sources, to backup any manual processes in place.

5.6 System availability after the successful go-live

A detailed plan will be agreed with the Deployment team showing how the user community will be introduced into the new

system once it is released back to the business after a successful cut over and go-live. This would potentially involve a

staggered approach to visualize the impact as each group of users as they are released onto the system. This plan will be

drawn up by the Beacon Cutover Team and agreed by the business prior to the actual event.

5.7 Business Contingency Plans

The Beacon Cutover Team will prepare a contingency plan which will be presented and discussed at a workshop with key

stakeholders to identify areas of risk or issues. The workshop will be facilitated by the Business Readiness team and the

document reissued taking into account any feedback received from the workshop. This process will take place during June

2006. The contingency plan will be made up of various scenarios and mitigating action assigned to each scenario raised and

ownership of these agreed within the project and business representatives.

5.8 Business Continuity

The Cutover team will be responsible for ensuring that the business requirements regarding Business Continuity planning are

addressed covering each distinct phase of the Beacon programme i.e. Period 1: up to Go Live, Period 2: after go live but

before full handover to BAU and Period 3: Handover to BAU. This will be achieved by comparing current business processes

with the changed processes under Beacon and identifying how the supporting continuity plans need to change accordingly.

This work will begin during April 2006 and will require involvement from members of the deployment team and the business

both to identify the changed processes and to agree the required continuity processes. This work will be completed by end

September 2006.

5.9 Cut-Over log

Chronological documentation of the cutover process is important for retracing steps and events should problems develop

during execution of the cut over plan. At a minimum, the log should record the person identifying the action, a description of

the action, and the time and also any dependencies linked with the task. The formal cutover log will be created in time for the

first Rehearsal and administered by the Cutover team. Creation of the log will be the responsibility of the cutover team and

communication on its use and location will be provided to each COP and interested party. The COPs will be responsible for

cascading the above to their teams.

5.10 Cutover contact & escalation procedures

Every team member involved in the cutover process will be identified in the master cutover plan and will contain contact

details including names, role, telephone numbers, emergency contact details, backup/stand-in information and reporting lines.

Within the cutover plan it may be that individuals that are not directly involved in the project will need to be contactable over

the cutover period.

It will be the responsibility of the Beacon Cutover Team jointly to ensure that the following groups of people fully understand

and are committed to delivering the activities with which they have been tasked.

Functional team members

Business representatives to support over the cutover period

Hardware or system people - BGB & 3rd party systems

Project/Programme Management

page 18 of 21

5.11 Status meetings

Status meetings between the Cutover Team and appropriate COPs will take place in the lead up to each cutover rehearsal,

and will escalate to a frequency of up to three times a day (by Tconf where appropriate) during rehearsals or the cutover

event itself to assess progress of the cutover plan.

Issues and dependencies will be noted and the plan continually monitored to ensure that timescales are not in jeopardy by

any tasks that are delayed. Should a task be in jeopardy re-planning will take place to understand the issues around

dependant tasks. As cutover progresses the status meetings will be increased or decreased if a consensus of attendees feel

this is appropriate.

The cutover team will monitor the detailed cutover plan, and will liase directly with COPs to communicate the progress of the

cutover plan and any issues arising out of this. COPs will be expected to report and update their individual cutover activities

on a weekly basis

5.12 Cut-Over validation process

Specific documentation will be created to formally accept key elements of the Beacon solution. It will be the responsibility of

each COP to sign that critical processes function correctly and that data objects or processes assigned to them are correct

and that the quality of the data assigned to the object is sufficient for their new processes to work. Part of the cutover process

will also be to run live work through the Production System before this is released back to the business. This work will be the

responsibility of the COPs within the functional teams to identify the tasks that will be performed. The scope of these

activities will be agreed between the test team and the deployment team and will be known as BCRT – Business Capability

Resource Testing. A period of 4 weeks formal test activity will be scheduled for November 2006 but it is envisaged that a

series of mini-BCRT activities will take place as part of each cutover rehearsal

The Cutover team will also work closely with the IS CIA team to ensure that the solution meets production standards well in

advance of cutover itself. Where possible system changes will be put into production ahead of cutover so that changes on

cutover day itself are minimised. Sign off forms will also be required from the IS CIA teams but it is accepted that not all

aspects of the system will become part of BAU CIA until an agreed stabilisation point (to be determined) after the initial go

live.

Once successful testing of the above has occurred and signatures obtained from the COPs (and their business sponsors

where appropriate), the Beacon Programme Director will sign to confirm that cutover is complete, which will in turn release

the Beacon Solution for the business to use.

5.13 Post Go-live tracking

The cutover team will maintain a cut over log, as outlined above, detailing all activities up to and including cutover. This will be

handed over to the CIA BAU team once cutover is complete, and it is proposed that the BAU team continue to maintain this

log for the period of post implementation support.

Implementation cutover reports will be completed by the Wipro team assisting with the technical cutover process and these

will in turn be incorporated into the overall implementation reports (BW294) by the cutover team.

5.14 Legacy Retirement

This will be the responsibility of the “sunset” workstream within the IS Readiness domain.

5.15 Go-Live Support

The Cutover team will specify the necessary dedicated resources required for “Go-Live” as well as post production support.

The Beacon Deployment manager will ensure that appropriate business resource is available to support cutover and the

Beacon technical cutover manager will liase with IS CIA to ensure that the appropriate technical support and acceptance

resource is available. These requirements will be documented in the resource strategy and detailed cutover plan.

page 19 of 21

6. Assumptions

This cutover strategy has been devised after appropriate consultation and is subject to the following principal assumptions:-

1. The planned go live date for the Beacon Programme is 1st January 2007. “Go live” in this context means that the IS

production system is ready to begin processing the business processes as defined in the BPML (BW213), under full

production conditions, and the business is ready to deploy the SAP system under BAU conditions.

2. Resources to satisfy the cut-over strategy and plan will be available when required, including those required during

rehearsal, cutover and post go live “hypercare” periods

3. The Business, IS and the Programme will have jointly made a Go decision for the go live cutover to take place based on a

favourable assessment of the agreed Go/No-go Criteria and checkpoint decisions

4. The standard desktop programme will be complete and have no impact on cutover or necessary events leading up to cutover

(e.g. rehearsals)

5. Pre and post go live Solution Change will be rigorously managed though a planned program of maintenance and “small

change” releases as part of a structured plan to achieve stabilisation and acceptance of the Beacon system into BAU

business and IS CIA operations

6. The Programme Board will work closely with the Business Sponsors and stakeholders to ensure that Business Change is

frozen (or at least severely constrained to the absolutely essential) throughout the period beginning with Final Preparation

through to Stabilisation (i.e. acceptance into BAU)

7. A suitable infrastructure landscape is available to begin Cutover Rehearsals from August 2006 and that sufficient time is

made available between other activities such as OAT and Performance testing for pipe cleaning and similar landscape

preparation tasks

8. All parties will sign off (or turnaround as appropriate) all cutover deliverables normally within 5 working days of delivery, or

sooner if required to meet the cutover timetable.

9. Data migration strategy, resourcing and cutover plan will be published separately.

10. There will be 3 software cutover rehearsals and no pilot before IS system is ready for Go Live

11. Data migration team will be involved in all cutover rehearsal planning but may plan separate cutover rehearsals for data

migration

12. Rehearsal 3 (Dress rehearsal) will take place not more than 2-3 working weeks before Ready for Go Live

13. Software cutover event will be relatively simple as up to 95% of 3rd party system changes can be completed beforehand and

the SAP production environment and final code set can be pre-loaded before the software cutover event.

14. A solution will be found to the problem of the existing Beacon SAP XI server being used to support Acorn production.

15. Final code set following IAT 3 cycle 1, high volume test 1 and OAT phase 2 as at 27th October can be cut and released to

Production ready for start of business Monday 30th October

16. The data migration team will be able to expedite automated data load from CGABS to enable performance testing to start on

30th October. Failing this another approach will be found (manual data entry or tool such as E-cat) will be used to ensure

performance includes representative CGABS data

17. BCRT and performance testing cycle 2 can co-exist on the production environment and can be completed in 4 weeks

18. Pipe cleaning and client data clear down can be accomplished over the weekend of 25th November ready for cutover

rehearsal 3 to commence on Monday 27th November

19. IS “Ready for go live” means that the Beacon Solution is prepared and ready to receive migrated data and to go into live

operational service. Specifically:-

- Software Cutover complete - All testing (other than final stages of UAT) complete - Final Dress Rehearsal satisfactorily completed - Solution is supportable and is supported - Capable of receiving live data migration - IS Go/no-go criteria met and signed off

page 20 of 21

7. Next steps

30th March 2006 This draft to be distributed as indicated at the start of the document along with comments sheets

5th April 2006 Comments sheets to be returned to the author and agreed/challenged by Cutover Team

7th April 2006 Final Cutover Strategy issued

13th April 2006 Cutover team receive Dependencies Cutover Plan, detailing 3rd party and interface cutover

activities

13th April 2006 Cutover team receive Data Migration Cutover Plan

13th April 2006 Cutover team receive Business Cutover Strategy

25th April 2006 Wipro provide cutover team with detailed steps for build of IS-U, CRM, BW, Java & XI servers

16th May 2006 Cutover team receive Business Cutover Plan

31st May 2006 Cutover roles, responsibilities & COPs agreed

14th June 2006 IS readiness, Dependencies, Data Migration and Deployment Cutover Strategies to be included

into Master cutover strategy

page 21 of 21