cutover strategy - legacy to new billing, invoicing engine
TRANSCRIPT
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