End Customer Migration Command & Control: Requirements Capture Workshop (2)

1. End Customer Migration Command & Control:Requirements Capture Workshop (2) The purpose of this presentation is to: articulate to Communication Providers the high level design proposed by BT to provide a Command & Control structure during End Customer migration In order to: facilitate the capture of any low level design requirements Enquiries regarding this presentation should be directed to Dave Jackson on 0121 230 2383 or email david.j.jackson@bt.com

2. What we will cover today • BT Design For Migration Control Structure • Timing and Sequencing • Change Control processes • Interfaces • Alignment with Initial requirements (from Workshop 1) • Duration of structure • Open Forum (requirements capture 2) • Review of requirements • Next Steps and Forward plan review

3. Why not BAU?Why Command & Control ? • Migration of End Customers to 21CN is a very complex task • Therefore careful planning is paramount • There are multiple stakeholders • We need to keep everyone appropriately informed • Each Migration is time constrained • Take decisions & enact them quickly • We need to be able to receive and respond to all incidents in a controlled manner • Service Assurance for End Customers is paramount • We need to ensure our engineering resources are free to focus on assuring the network • There needs to be very clear processes so that all parties know their responsibilities and how to react to events as they unfold

4. Migration Command & Control: Key Purpose • For End Customer Migration, it will • provide a clearly understood structure for the dissemination of defined information including the • lifespan of the structure • timings for information flow • provide a set of defined interfaces for managing information flow • identify processes which require development or evolution • It will not: • define detailed processes • replace BAU, it will supplement • manage or communicate with end customers directly • manage CP interconnect route migration

5. Command & Control Structure End Customers End Customer Contact Centre (Comms WG) Communication Providers BT Service Centre Network Management Centre Migration Control Centre • Core Business Functions: • Schedule & Schedule Change Control • DLE preparation management • Migration Control Management • Fallback Management • Fault Reporting support • Measurement & Management information • Supplier Performance Monitoring INFORMATION FLOW • Alarm Monitoring • 2nd / 3rd line fault support

6. Migration Command & Control Centre:Core Business Function Definitions • Schedule Change Control: • development/dissemination of fit for purpose migration schedules including operation /management and adjudication of change requests • DLE Planning Management: • preparation activities are completed to schedule • Migration Control Management: • detailed migration activity on a per DLE basis until BAU processes resume • Fallback Management: • operating the process which will assess performance against pre defined fallback criteria and implementing agreed fallback methodologies • Fault Management: • operating the fault management support processes during the period of migration until BAU processes resume • Measurement and Management: • collate information and design reports prior to distribution • Supplier Management: • responsible for monitoring performance trends of key suppliers

7. Migration Command & Control:Principles • utilises BAU where at all possible • does NOT break working processes • augments the fault / fix process • supports best in class cost, efficiency optimised, ensures SLA management remains controlled • retains existing Communication Provider relationships • ensures information flows from a single central expert control

8. Migration Command & Control:What are the key areas of consultation? • Schedule Change Control: • What should the schedule contain and when/how is it shared? • What are the processes which underpin it eg Change Control? • Fallback Management: • What are the fallback criteria? • Fault Management: • How do we diagnose faults during the migration period? • What special reporting procedures should we have in place? • What are the service levels in operation during migration? • Measurement and Management: • What pro-active updates do we provide and when (before, after & during migration)?

9. Migration Command & Control:Consultation Framework Fallback Criteria Operation & fit for purpose will be reviewed during Pathfinder Go/No Go Decisions Fault Diagnosis Fault & Service Mgt criteria Delivery (inc War game development War gaming & Implementation Requirement Capture Jan 06 May 06 Jul 06 Nov 06 W/shop (1) 17/01 Output End 04 W/shop (2) 14/03

10. Migration Schedules:Key principles: • Migration Schedules will start being issued at “6months to go” • Progressively more detailed (Monthly>weekly>daily) • Monthly Schedules will identify the “Grooming window” for a DLE • This can show DLE, Conc and number range. • Build on information contained within NIPP/LLU portal • Issued & controlled by Migration Control Centre • Will enable Communication Providers to conduct detailed planning for End Customer Migration • Support End Customer Communications: • as envisaged by Communications Working Group • By Communications Providers directly as required

11. NIGHT OF END CUSTOMER MIGRATION Schedule Change Control - 4 Wks -2 M -3 M -21 to -18 Months -6 M -4 M + 1 W Plan of Record Fixed SCHEDULING & CHANGE CONTROL Change Request process available Schedule Fixed Monthly Migration Schedule Issued Weekly Migration Schedule Issued Nightly Migration Schedule Issued Monthly Migration Schedule Fixed Weekly Migration Schedule Fixed Nightly Migration Schedule Fixed

12. Schedule Change Control:Principles • Plan of Record (Quarterly Programme) • Issued Quarterly under Change Control • No Change Requests to “advance” DLE migrations from one quarter to another 21 months out (HLSAN issued) • Migration Schedules (Monthly Programme) • Issued monthly on a rolling basis & includes “low network activity period” • No Change requests accepted after “4 months to go” • Migration Schedules (Weekly Programme) • Issued monthly on a rolling basis • No Change Requests accepted after “2 months to go” • Work Schedules (Daily or rather “Nightly” programme) • Issued 6 weeks out on a weekly basis • No Change Requests after “5 weeks to go”

13. Change Request Process:Principles • The Change Request Process for the Plan of Record will remain unchanged • Change Requests can be raised against any of the “Schedules” within the defined window • to an defined BT email account • using the same forms as used for the Plan of Record • BT circulate to registered Communication Providers who may comment within 5 days (anonymous basis) • Requests adjudicated • BT notifies all of outcome • Schedule updated at the “Fixing Point”

14. Alignment of Initial Requirements • Update on existing requirements: • Nearly all requirements are catered for • What BT cannot deliver: • MCC 007 only generic periods will be communicated.