Part 2 Business Transformation and Delivery. Price Control 2017/18 Submission

Transcription

1 and Delivery Price Control 2017/18 Submission Date: July 2018 Classification: DCC Public

2 Table of Contents 1 Introduction to Part 2: Business Transformation and Delivery... 4 Orientation and Purpose Delivery of Remaining Capability for DCC SMETS2 Live... 5 Release 1.3 Update... 5 Release 1.4 and the Delivery Train Functionality delivered in R Development of the Delivery Train and applying to R Implementation of R1.4 and ensuring value for money SMKI Repository Testing (SRT) Release SMKI Recovery Release 2.0 and Dual Band Communications Hub Introduction Major Drivers of Cost in 2017/ Key Lessons Learned Key Activities Development of the R2.0 Baseline Plan & Implementation Timeline Commencement of Testing for both SBCH and DBCH Development and Agreement of the Incentives Regime Transition to Operations Resourcing R2.0 in 2017/ Transitioning the Business for Live Service Operations Update to the Operations Target Operating Model Project to Business (P2B) Designing an effective P2B programme Overall progress at end of RY2017/ Progression into Business as Usual Readiness to Scale Readiness to scale performance audit The introduction of production proving capability into DCC Customer Focus Overview Driver for Change Customer journey mapping Measuring Customer Satisfaction/ Customer Effort Intended benefits of Customer Touchpoint work: Due process: Trade-offs and options considered Initial options for customer journey mapping Extension to the customer journey mapping exercise... 47

3 4.4.9 Customer Satisfaction and Customer Effort Customer Journey Mapping Tool Key events during implementation Link to expenditures / RIGs/ Baseline Margin application Customer Journeys Customer Satisfaction and Customer Effort Release Management Strategy Introduction Scope of the change Drivers for the change Identification and evaluation of options Consideration of options Decision Managing the complex implementation Architectural Strategy for Environments... 56

4 1 Introduction to Part 2: Business Transformation and Delivery Orientation and Purpose This document is the second in a suite of five documents which comprise the RY2017/18 Price Control submission. The purpose of Part 2 is to provide a detailed explanation of our progress in delivering the remaining functionality associated with SMETS2, as well as the changes we are making to ensure we are ready to scale our business to ensure successful delivery of additional programmes. Additionally, this part also provides a description of the bulk of the drivers we will reference to in the Baseline Margin Application. 1. Ensuring Value for Money 5. Internal Costs 2. Transformation and Delivery 4. Services in Development 3. External Costs Figure 1-1: Transformation In Part 2 we report on the following: Delivery of the remaining capability for scalable live services remaining functionality associated with Release 1.3 Delivery of Release 1.4 and the introduction of the Delivery Train designed to maximise the efficient use of testing environments required to deliver multiple DCC programmes; The SMKI Recovery Testing (SRT) release Progress on roll-out of Release 2.0 which includes delivery of Dual Band Communications Hubs and the changes required to support updates to the GBCS mandated by BEIS Transitioning the business for live service Operations Our strategy for future releases Architecture Strategy for testing environments In addition, there has been considerable progress in supporting the delivery of BEIS s Enrolment & Adoption programme (SMETS1), as well as acting as a strategic delivery partner for OFGEM s Switching Programme. These activities are covered separately in Part 4 of this submission. DCC Public Page 4 of 56

5 2 Delivery of Remaining Capability for DCC SMETS2 Live Release 1.3 Update The bulk of Release 1.3 (R1.3) was explained in Part 2 of last year s submission. For the purposes of this year s submission we include an update on the final months leading up to the delivery of the Release. June 2017 During the month of June, DCC completed Systems Integration Testing (SIT), as below: Central and South (C/S) Region: 01 June 2018 against a planned timeline of 02 June North Region: 05 June 2017 against a planned timeline of 02 June due to a late problem with the Arqiva Comms Hub. Test Assurance Boards for both regions were completed subsequently on 05 and 07 of June (Region C/S and Region North, respectively) and were successful. DCC completed entry to the end-to-end (E2E) User Integration testing (UIT) phase on the 13 June as planned. The UIT testing phase is where SEC parties perform their own testing against the new DCC and this testing is conducted with meters as opposed to emulators. During this month DCC s Programme Delivery team received verbal and written confirmation from the Test Assurance Group (TAG) that they recognised a successful SIT exit as well as the entry to E2E UIT testing. SEC Panel met on 30 June 2017 and confirmed DCC s achievement of SIT completion, as per the above dates, and the entry into E2E UIT testing. SEC Panel used the TAG recommendation as an input to their decision. July 2017 The focus in July was to ensure communication and engagement with stakeholders to get approval for Release 1.3 to go live in the production systems. The first requirement was an internal validation and assurance that DCC had achieved the objectives outlined in the Release 1.3 Readiness document. Submission of this document was required to enable DCC Board approval for the release to go into production and a stepping stone before BEIS could grant the same approval. The readiness reviewed whether DCC delivery of R1.3 was managed through governance and gating processes in line with industry good-practice. Programme Gates and Assurance Points were in place to approve entry into and, where relevant, exit out of, the various programme delivery phases, as well as the key programme milestones. These include testing phases and services such as: System Integration Testing; and End to End Testing as well as milestone points, including: Solution Design Complete / Entry into Pre-Integration Testing (PIT); and confirmation that DCC is ready for Live. In completing these governance and gating processes, DCC firstly ensured that all relevant solution designs were assured for quality and SEC compliance through the Design Assurance Board (DAB), after which these approved designs then passed through Programme Gates to reach a status of Solution Design Complete. This set out the baseline design for DCC s Service Providers and ensured that the solution designed had been implemented. Further checks were done during the readiness review, such as, Operational Governance that DCC Public Page 5 of 56

6 assured DCC Release 1.3 products have passed through design and test assurance and processes that DCC will follow as part of its operation of the DCC solution. Key dates included: 11 July 2017: the DCC Board reviewed and approved the programme Release 1.3 to move forward into the governance and obtain BEIS approval of deploying Release 1.3 into Live production platforms. 13 July 2017: DCC provided the R1.3 submission letter to BEIS to seek approval of deploying Release 1.3 into the production platforms. In addition, DCC undertook to write to BEIS to update on how E2E testing and resolution of testing defects had progressed from a SEC party perspective in the UIT environment. DCC provided a short letter with concise supporting material to provide clarity that testing was progressing well and there were no significant issues preventing the release from going live into production systems. 18 July 2017: the BEIS SMIP Senior Responsible Officer (SRO) provided the decision & SEC Direction for DCC Release 1.3 to go live for all regions. BEIS also issued a direction to activate the SEC provisions governing the DCC live services. This brought into legal effect the relevant SEC Sections and designated or re-designated a number of SEC Subsidiary Documents and Schedules. 21 July 2017: the release 1.3 team started the R1.3 release deployment process into the live systems which concluded on 22 July Milestones laid out in RY2016/17 Part 2 Appendix B were met with minimal additional resource required beyond what was requested in last year s submission. Release 1.4 and the Delivery Train In last year s submission, we introduced some of the functionality to be delivered as part of R1.4. In this section we build on this and describe the two main aspects of Release 1.4 (R1.4). The functionality of (and exclusions from) R1.4: We describe the scope of the release and the benefits that flow to customers from the change requests of which it was comprised. We describe how SMKI was left out of the original R1.4 and delivered elsewhere; Introduction of the Delivery Train and its application to R1.4: The Delivery Train is a process by which code is managed through testing using an innovative technique called feature toggling. It was developed so that DCC could deliver SMETS1 and Release 2.0 simultaneously. However, its first use in DCC was in de-risking the delivery of R1.4 by breaking down the whole release into manageable stages which were delivered discretely Functionality delivered in R1.4 R1.4 served the dual purposes of integrating changes in the Smart Energy Code (SEC) into the DCC solution, as well as supporting the overall enhancement of DCC services since Go-Live. R1.4 had the following scope and specific benefits: EUI64 Identifiers: Multiple EUI identifiers per SEC party were not supported as part of Releases 1.2 & 1.3 and were introduced in this release. Self Service Interface (SSI) Changes as Defined in SEC H8.16c: Legal text had been added to the SEC which required the SSI to provide access for all Users to the Service Audit Trail entries for Read Profile Data and Retrieve Daily Consumption Log Service Requests. Anomaly Detection SMETS Object Limits: The DCC solution s data value (attribute limit) Anomaly detection process was enhanced to support an additional set of four data values to be checked as part of Service Request processing. DCC Public Page 6 of 56

7 Exclusions Software Platform Technology Upgrades: Certain of the underlying DSP software platforms were updated in order to improve the maintenance and supportability of the Systems and reduce/mitigate the risk of operating unsupported and older versions of software platforms over time. There were certain security changes that were originally scheduled to be included in R1.4 however these were left out as DCC systems could not fully support these at the agreed time of implementation. These related specifically to recovery testing and restriction of communications placed upon the DCC as part of the 3rd consultation of the SMKI Recovery Procedure document. These were due for inclusion into the SEC as a SEC Subsidiary document. Following a consultation in September 2017 on revisions to the SMKI & Repository Testing Approach document, a decision was made to integrate these into the wider SMKI Recovery Programme for delivery later. As part of implementation, CR260 was raised to ensure that the DCC solution was compliant with the contents of the already designated recovery procedure contained within the SEC. In summary there were three changes in this CR; Annual setup of an environment to test recovery interfaces and functionality; Extend the recovery application to re-instate communications to affected devices; Generate notification files for Users with only devices for which they are responsible. Please note that CR260 is a material change request and is therefore fully described in Part Development of the Delivery Train and applying to R1.4 Feature toggling to solve the problem with test environment architecture The original DSP delivery model followed a serial path to test and validate a programme release in the SIT-B environment. This meant that only one DCC programme could be present in the testing environment at any one time, blocking any other programme from entering their SIT Phase. In 2018, DCC had committed to deliver both the R2.0 and SMETS1 programme in parallel. This effectively double-booked the use of the SIT-B test environment. DCC was faced with the position that Release 2.0 would enter SIT-B in advance of SMETS1 Enrolment and Adoption (E&A). The SIT-B environment would therefore not be released for E&A until the end of Q E&A could not therefore begin SIT until the end of Q which would then push its production delivery into In summary, the existing physical integrated test environment architecture, strategy and schedule could not support the published Smart DCC portfolio milestones for the SMETS2 R1.4, SMETS2 R2.0 and SMETS1 Programmes. Driver for Change To address the situation described and deliver the series of releases, there was a need to move to a more enduring and flexible delivery approach. However, it was still important to optimise other important factors such as delivery speed, cost & quality. DCC began a series of workshops with service providers to develop a methodology and a business case. The following requirements and / or success factors were established. No additional risks- There should be no additional risks introduced to into delivery of the Programmes; DCC Public Page 7 of 56

8 Sufficient resources - Sufficient and appropriately skilled resources are to be available for all programmes. Achievable dates - The dates that are committed to are achievable. Accurate plans - Published plans for Release 2.0 and E&A accurately reflect the DCC requirement. Options for Change DCC prepared a draft business case with three options No change - DCC would continue to operate in a serial / waterfall delivery process. Release 2.0 would enter SIT first, ahead of E&A. The E&A programme would be blocked from entering SIT Phase until late 2018; its Production delivery date would likely be pushed out to Delivery Train - Utilise feature toggling to separate the source code into discrete blocks which each provide a tightly scoped amount of functionality (such as the delivery of anomaly detection). The Release 2.0 and E&A delivery programmes can then be developed within the same source code an in parallel. Those features which are sufficiently developed to test can then be independently passed to the appropriate test environment after they are switched on. A problem encountered with one feature would not therefore impact other features. Without feature toggling release 2.0 and E&A would each have to be developed and tested in their entirety and delivered as separate releases. So, if a significant problem was found within a small part of the code of either release the entire release and all its constituent functionality would be jeopardised. More Environments - Introduce an additional stream of environments for PIT, SIT and UIT per programme. Each option was assessed using a Strengths, Weaknesses, Opportunities and Threats (SWOT) matrix. This is summarised in Table 2-1 below: Table 2-1: Options for change to the delivery programme OPTION STRENGTHS WEAKNESSES OPPORTUNITIES THREATS NO CHANGE Solves the problem without business change and using tried and tested methods Inflexible, complex and limited to big bang releases shut for business DCC transformation embeds more successfully as there are no multiple programmes in flight Insufficient environments to support parallel delivery and my require re-scope / cancellation of R1.4 DELIVERY TRAIN Flexible solution which optimises existing resources and which removes need for new environments Steep learning curve and difficulty in prioritisation and configuration management Increased probability of 2018 delivery for both R2.0 and SMETS1. Requires stronger governance against too much development change Pollution of code sets between multiple programmes testing DSP functionality in the same environment DCC Public Page 8 of 56

9 OPTION STRENGTHS WEAKNESSES OPPORTUNITIES THREATS MORE ENVIRONMENTS More enduring environments. Minimal business change and proven development and test approach within DCC Expensive and complicated to procure if following traditional contracting approach. Expensive to run and retains the same complexity of code branching (as option one), reduced business hours and still dependent on rigid deployment order More environments provide the opportunity to parallel more testing without risk of data set or test result pollution. Could Accelerate testing Unlikely (highly) to achieve 2018 delivery plan R1.4 in danger of cancellation as a mitigation to R2.0/E&A being Choosing the Delivery Train Following the analysis, the chosen option was agreed to be the Delivery Train. DSP currently create separate code branches for a given Release / Programme; for example, R1.3 and R1.4. These code branches are developed and delivered in isolation. Figure 2-1: Visual representations of testing with code branching 1 The proposed Delivery Train Approach allows for the parallel delivery of what are currently constructed as separate Releases. The Delivery Train Approach therefore offers the potential to deliver new functionality to our customers in a more flexible and predictable manner, by supporting the deployment into live of discrete pieces of additional functionality and by mitigating the constraints of the current suite of test environments. 1 DCC Public Page 9 of 56

10 Design and development within CR255 The first application of this novel and innovative technique was in R1.4. This is described below. The delays to R1.3 and the associated environment constraints added significant risk to the baselined R1.4 plan. This put at risk the delivery of the entire scope of R1.4 by 2 November At the time, DCC was operating under Transitional Variances (time limited derogations from the SEC). Were R1.4 to slip beyond 2 November 2017 then DCC would have potentially been non-compliant with the SEC. In June 2017, the DCC Executive Board (DEB and later became ExCo) considered several options to resolve the issue. To de-risk R1.4, DEB considered that the release should be split into individual deliverable parts. It was envisaged that some of the parts would be released to production systems between active Releases 1.3 and 2.0 The remainder would be released during the 2.0 SIT and UIT phases. On 26 June 2017, CR255 was formally raised by DCC. It requested that the DSP design a solution to deliver R1.4 in discrete elements. Following workshops and discussions during June 2017, the DSP provided a full Impact Assessment, dated 26 July which formally proposed the Delivery Train approach. This was based on Feature Toggles that would allow elements of the new or revised functionality that was introduced in R1.4 to be enabled. R1.4 was originally going to be released by implementing CR237. The benefit of CR237 was that it integrated the component CRs which would have individually delivered the functionality described earlier in However, when it became clear that a more flexible approach to R1.4 was required, CR237 was terminated. The development work which went into CR237 was not lost and it was transferred into CR255. The benefits of CR255 are enduring and do not stop at R1.4 DCC has developed a flexible approach which delivers the best value from its physical test environments. Energy networks (gas and electricity network infrastructure) use an analogous approach. For example, electricity networks will use flexible demand management to postpone investment in physical assets Implementation of R1.4 and ensuring value for money Release 1.4 was formally implemented on 2nd November 2017 following achievement of all eight programme milestones. The delivery plan is shown below. DCC Public Page 10 of 56

11 Figure 2-2: The R1.4 Delivery Plan The delivery of R1.4 and SMKI Recovery changes was met through a mix of both internal and external resource over a 12-month period. We provide information on how these programmes were undertaken with value-formoney being a core component of its delivery: Internal Resource: towards the end of delivery of R1.3, it was agreed that rather than hire new teams and resource to support delivery of R1.4, existing R1.3 teams and resource from other areas would be used as a preferred delivery option. This had the dual benefits of reducing recruitment costs and ensuring that existing learning and expertise from previous deliveries could be utilised. It also meant that efficiencies in delivery of R1.4 stemming from experience with other releases could be factored in which altogether drives value-for-money. External Resource: R1.4 was delivered contractually by our DSP via a number of Change Requests (CRs). To ensure value-for-money we held a number of meetings to discuss costs contained within the Impact Assessments for the DSP to undertake the CRs. This included scrutinising team sizes and proposed levels of resources for each delivery component. Our DSP was required to justify how they came to their resourcing decisions, with a particular emphasis on teams only billing DCC for the time spent on R1.4, rather than on a whole-days basis. Further and more detailed information can be found in Part 3. SMKI Repository Testing (SRT) Release SMKI Recovery The DCC has been delivering incremental changes to the SMKI Repository and Recovery Testing Approach since Prior to submission of this document we have completed parts 1, 2 of SMKI Recovery Testing. DCC Public Page 11 of 56

12 On Friday 9 June 2017, the SEC Panel approved version 5.0 of DCC's SRT Approach document following consultation with SEC Parties and the SMKI Policy Management Authority (PMA). The updated document provides details of parts 3a and 3b of the SRT Approach: Part 3a tests the SMKI recovery environment in SIT involving the recovery Key and IKI File Signing Certificates that are also used for SMKI recovery file signing; Part 3b tests the SMKI recovery environment with User SMKI recovery systems and processes in the End to End Testing that occurred after R1.3. On Wednesday 12 July 2017, the SEC Panel approved DCC's completion of Part 3a SRT following consultation with Parties and the SMKI PMA. The Panel directed DCC to publish this Test Completion Report in accordance with SEC T5.21(c). In September 2017 we consulted on changes to the SMKI and the Repository Testing Approach Document. The updated document provides details of parts 3b and 4 of the SRT Approach: Part 3b tests the SMKI recovery environment with User SMKI recovery systems and processes in the End to End Testing that occurred after R1.3; Part 4 tests the SMKI recovery environment on ability to re-instate communications to Devices should the SMKI PMA decide that use of the Recovery environment is not necessary or appropriate. DCC Public Page 12 of 56

13 3 Release 2.0 and Dual Band Communications Hub Release 2.0 will be a major upgrade to the DCC Smart Metering Solution. It will deliver: A Dual Band Communications Hub (DBCH) capable of operating at the current 2.4GHz frequency, as well as operating at a sub-ghz frequency in areas where the Home Area Network (HAN) propagation is particularly challenging. This will help to ensure that around 95% of homes can access the benefits of Smart Metering. Updates to the TSG will be delivered in R2.0 including a move to GBCS v2.0, incorporation of the latest SEC changes, and updated DCC specifications relating to Device User Interface Specification (DUIS) v2.0 and Message Mapping Catalogue (MMC) v2.0. These updates cover both Single Band and Dual Band Communication Hubs and will be underpinned by a robust programme of testing that builds on lessons learned from previous releases. The programme commenced in March 2015 following a direction from BEIS to carry out an Impact Assessment to estimate the associated costs of delivering DBCH. Amalgamation of DBCH into the R2.0 programme occurred in December 2016 following agreement on the technical baseline of delivering both R2.0 and DBCH. The programme is due for implementation in RY2018/19 subject to satisfactory testing outcomes and assurance that the solution meets the overall objectives of the Release as agreed by BEIS and other DCC stakeholders. Background to Release 2.0 and DBCH was provided in Part 4 of our Price Control submission document for 2016/17 2. For the purposes of this submission it would be useful to refer to this submission to understand the activities that took place prior to RY2017/18. Introduction Following extensive scoping and design work of the DBCH solution in RY2016/17, the focus has shifted towards delivery of the core development activities that will form the basis for implementation of R2.0 and DBCH in RY2018/19. The focus of RY2017/18 has therefore been on ensuring the solution is fit for purpose prior to implementation and the activities associated with this purpose are explained in greater detail in subsequent sections of this chapter. A major achievement was agreeing the overall timeline for implementation of R2.0 between our Fundamental Service Providers (FSPs), BEIS and other stakeholders. This included agreement on the programme milestones, as well as the delivery activities and timelines that underpin the implementation of the Release. Agreement on the approach to testing the functionality of DBCH and all other components of the R2.0 programme was also achieved in RY2017/18 and is currently underway across both our CSPs. While DCC are on track to deliver R2.0 in RY2018/19, there have been a number of challenges that DCC has had to mitigate in this regulatory year. Most of these challenges stem from external dependencies that have had moderate to severe impacts on our overall ability to deliver a robust solution. For example, testing of both SBCH and DBCH has been dependent on the availability and suitability of metering equipment, which is largely driven by the supply chains of our two CSPs. Likewise, R2.0 has had to effectively compete with other DCC programmes for access to testing environments and resources. In addition, the added complexity of delivering the R2.0 programme has put pressure on both internal and external resources. The ability to source specialists and other technical experts with the right mix of experience has been a significant challenge for the programme and this is likely to remain an issue until the final stages of implementation in RY2018/19. Irrespective of difficulties within RY our focus has always been on ensuring that there are clear processes and procedures which drive Value-For-Money throughout the entire programme. Clear governance and due-diligence around the assessment of cost proposals from our CSPs, salary and day-rate benchmarking 2 Insert Link to PC2016/17 Part 4: Services in Development DCC Public Page 13 of 56

14 of both our permanent staff and contractors, and thorough assessment of our external procurements have contributed to our drive to keep costs as economic and efficient as possible. Figure 2 below summarises where DCC are currently in the programme, as well as a description of the main themes that have either taken place or are due to take place over the lifetime of the programme: Figure 3-1 Release 2.0 Summary of Main Activities At the time of writing of this submission in July 2018, DCC has so far met all of the R2.0 programme milestones. This is a major achievement of the programme and bodes well for the planned full roll-out of DBCH by December Major Drivers of Cost in 2017/18 DCC has been negotiating, with its External Service Providers, the cost and timescales of delivering R2.0 and the consequential costs associated with changes to a number of underlying technical documents. The main cost drivers for the overall programme are: Development work for new DBCH for the North, South and Central Regions which includes: Development of hardware; Development of firmware; and Build and test activity (which includes the provision of environments, along with certification); The consequential costs to the External Service Providers and DCC systems and processes, associated with the changes to the underlying technical specifications TSG2; A dual supply approach for the South and Central Regions, which includes mesh technology (used in premises that have no cellular/wireless coverage). DCC Public Page 14 of 56

15 To support development and implementation of R2.0, several change requests have been raised which, for RY2017/18, are the major drivers of cost. These are CR184, CR194 and CR253. These CRs have formed the basis for delivery of the core functionality required to deliver R2.0 and DBCH by our Service providers as listed above. They also provide the first major updates since go-live from R1.2 to DCC systems following changes in technical and regulatory requirements as required by the SEC and BEIS. There have also been two Project Requests (PR023 from last year, PR062 and PR080) that were raised which supported both the development as well as driving VFM in delivery of these CRs. Negotiation on the final price from both our CSPs for delivering CR184 has taken place over an 18-month period straddling both RY2016/17 and RY2017/18. Final agreement on the cost of delivering CR184 was agreed by Arqiva & DCC in February For Telefonica, this agreement occurred in March In Part 3 of the submission we provide greater detail on costs associated with these Change Requests / Project Requests and a rationale for the activities that underpin them. A summary of these are provided below. CR184 SBCH & DBCH variants DBCH is wholly dependent on development of a range of communication hub HAN variants capable of receiving communications at both 2.4GHz and sub-ghz ranges. Upgrades to SBCH required to deliver the functionality of R2.0 will also be undertaken as part of development of different SBCH HAN variants. CR184 provides the over-arching scope and framework of how these will be delivered, as well as the legal and commercial mechanisms by which our CSPs will undertake the required work. The table below provides information on the range of HAN variants that will be delivered under the scope of CR184: Table 3-1: HAN Variants delivered under R2.0 The focus of RY2017/18 has been on the development work associated with introducing these new communication hub variants. This has included working with the CSPs to ensure their supply chains manufacture and procure the required hubs, as well as the program of testing that assures that the hubs are fit for purpose for mass rollout. This development work undertaken in RY2017/18 has built on the design and scoping of requirements for the CR that was undertaken in RY2016/17. This previous work included developing the impact assessments for the total cost of the CR by both our CSPs, as well as holding a number of clarification workshops to agree scope and ensure that our CSPs were clear on the requirements of the CR. DCC Public Page 15 of 56

16 CR194 Updated SEC requirements CR194 was raised in August 2016 following the Technical and Business Design Group (TBDG) agreeing the first iteration of the Technical Specification Group (TSG) 2.0 the suite of changes that would make up Release 2.0. The technical baseline for delivery of R2.0 was subsequently agreed by DCC, BEIS and other stakeholders on 31 January CR194 ensures that the changes to DCC systems needed to support R2.0 take into account the requirements within the agreed technical baseline. This specifically includes the following: Updated BEIS Technical Specification: An upgrade to GBCSv2.0, CHTSv2.0 & SMETSv3.0 Updated Regulatory Requirements: A move to SECv5.14 and DUISv2.0 Updated DCC Requirements: DUGIDsv2.0 and MMCv2.0 The requirements listed above are significant and extremely complex in nature. The upgrade to GBCSv2.0 alone will require integration of 10 Change Request Proposals (CRPs) and 82 Issue Resolution Proposals (IRPs). A full list of these requirements and their descriptions are included in Part 3 of this submission under the relevant CR heading. PR045 Commencement of CR184 & 194 Extensive and ongoing cost negotiations involving CR184 & CR194 were seen as putting at risk the delivery timeline of R2.0. This Project Request was raised to provide our External Service Providers with the necessary commercial and financial cover with which to commence delivery of CR184 and CR194 in advance of a signature of a formal Change Authorisation Note (CAN). This served two purposes: Ensures that external service providers can work to DCC timelines for delivery of R2.0 in RY2018/19; Allows for a greater period of time for DCC to negotiate the price of CR184 & CR194 in a bid to drive greater VFM As with all Project Requests, the budget for this specific Project Request was capped at a fraction of the estimated total cost amount of both CRs. The total cost of PR045 was subsequently rolled-up with the total agreed costs of delivery of CR184 & CR194 towards the end of RY2017/18. [REDACTED] Key Lessons Learned Development of R2.0 has built on the extensive experience gained from R1.2 and R1.3. In particular, there were four key lessons which have been applied to R2.0: 1. LESSON 1: Increases in Value for Money can be gained from Change Requests. Experience from R1.2 and R1.3 around sizes of teams and resources required to undertake various tasks can be applied directly to R2.0. Previously there was more need to trust our External Service Providers on their ability to source and develop cost-efficient solutions for previous Releases. Over time, DCC has become more experienced and thus better able to spot areas in which there are discrepancies between team sizes and scope of task. One example includes the need to ensure that a whole team is not retained until the end of portions of the release (such as a phase of testing) if there is minimal work left to undertake. In addition, negotiations on day rates as well as the flexibility to ramp up and down resources has allowed better VFM in delivery of the overall solution, thus creating efficiencies in delivery. 2. LESSON 2: A move to automation to keep costs down. Experience gained by both DCC and External Service Providers in scoping test requirements and outputs has allowed better judgement relating to portions of testing that can be automated and those that need to be DCC Public Page 16 of 56

17 undertaken manually. A sizable amount of Regression Testing has now been moved to automation, which has had the impact of significant decreases in cost. 3. LESSON 3: More efficient use of external resource between R2.0 and non-r2.0 programmes. Rather than concentrating all effort on R2.0, our policy has been to ensure that resource is used more effectively if that programme resource is not required for 100% of the time. For example, we would expect our External Service Providers to ensure all their permanent and contractor staff are allocated across multiple programmes. This ensures that they do not bill DCC for a whole day when the resource has in fact only worked for part of a day. 4. LESSON 4: The requirement to have a Device Integration Test phase. Experience from R1.2 and R1.3 found that the proposed Release needed more testing with a greater variety and number of meters to ensure the solution was robust and fit for purpose. This reduces the risk of service affecting issues being experienced in the live environment. Key Activities As outlined earlier in this section, R2.0 in RY2017/18 has focused on the delivery activities of the programme that together will support successful implementation of the solution in RY2018/19. There have been four main areas of work undertaken in this Regulatory Year. These are: Development of the R2.0 Baseline Plan and Implementation Timeline Commencement of Testing for both SBCH & DBCH Development and Agreement of the Incentives Regime Planning for Transition to Operations and Business as Usual We explain each of these areas of work in more detail in the following sections Development of the R2.0 Baseline Plan & Implementation Timeline On 24 January 2017, DCC received a Direction from the Secretary of State, in accordance with Condition 13 of the Smart Meter Communications Licence (the Licence), to produce a plan for the delivery and implementation of R2.0. The plan, once approved, consists of the binding milestones with which DCC must comply in accordance with its Licence obligations. The timeline and milestones for the R2.0 plan were required to include: hardware and software design and build phases; changes to the Smart Energy Code which are consequential on the provision of dual-band Communications Hubs, including changes to the CH Support Materials; changes to the Smart Energy Code which are consequential on the changes to the Technical Specifications and the GB Companion Specification, including changes to the DCC User Interface Specification and the Message Mapping Catalogue; the development of any additional version of the Parse and Correlate Software that is required as a result of R2.0; identification and consideration of any potential changes that are needed in the Charging Methodology; and milestones and timelines for the testing and trialling of R2.0 in advance of providing live services. DCC launched a four-week consultation in July 2017 which was aimed at giving the SEC panel and SEC party members the opportunity to input into the plan and provide views on key areas that would impact on the ability of DCC to deliver R2.0 in a robust and timely manner. The plan was subsequently signed-off by the Secretary of State (SoS) in October 2017 following agreement with our FSPs and wider stakeholders. DCC Public Page 17 of 56

18 Figure 3 and Table 2 illustrates the baselined R2.0 Delivery Timeline through to implementation in RY2018/19, as well as the agreed milestones which underpin delivery of the plan: DCC Public Page 18 of 56

19 Figure 3-2: Release 2.0 Delivery Timeline (agreed in October 2017) DCC Public Page 19 of 56

20 Table 3-2: Agreed R2.0 Milestones Milestone Date Definition DUIS/MMC Consultation Started DUIS/MMC Baselined ZigBee 1.0 specification available Communications Hubs Support Materials Consultation Starts Communications Hubs Support Materials Baselined Updated GFI without dual-band functionality available 16/10/2017 This milestone represents when the updated GFI without dual-band functionality will be available. Solution Design Complete 20/10/2017 This milestone represents when solution design is complete. CTSD/ETAD Consultation Start SIT TSG 2.0/SBCH Commence 06/11/ /11/2017 This milestone represents the start of the consultation on the Common Test Scenarios Document and the Enduring Test Approach Document through the TBDG process. This milestone represents the achievement of the Entry Criteria for first CSP as outlined in the approved Testing Approach Document for Release 2.0 as determined by DCC. The R2.0 SIT phase will test the integration of all the DCC Systems required to support R2.0 DIT SBCH commence 11/12/2017 Updated GFI DBCH available 03/01/2018 PIT for TSG 2.0/SBCH Complete 17/01/2017 OMS for Forecasting Available to End Users 30/01/2018 CTSD/ETAD Baselined 23/02/2018 ITCH DBCH available for ordering 08/03/2018 PIT for DBCH Complete 30/03/2018 Charging Statement for Regulatory Year ending 31 March 2019 is published 05/05/ /06/ /07/ /08/ /09/2017 Parse and Correlate Software Available 20/11/2017 Formal Notice to amend the Charging Statement is submitted to Ofgem (which we expect will include DBCH charges) 29/12/2017 SIT DBCH Commence 12/03/2018 ZigBee Certification Complete 28/03/ /04/2018 SIT TSG 2.0/ SBCH Complete 13/04/2018 DIT DBCH commence 16/04/2018 UIT TSG 2.0/SBCH Commence 21/05/2018 ITCH DBCH Available 31/05/2018 OMS for Orders Available to end Users 30/06/2018 SIT DBCH Complete 13/07/2018 This milestone represents the start of the DUIS/MMC consultation This milestone represents when the DUIS and MMC was baselined by TBDG This milestone represents when ZigBee 1.0 specification will be approved by the ZigBee Alliance and made available to parties. This milestone represents the start of the consultation on the Communications Hubs Support Materials through the TBDG process. This milestone represents when the Communications Hubs Support Material will be baselined by TBDG. This milestone represents when the updated Parse and Correlate software will be available for Users (including all SBCH and DBCH functionality). This milestone represents the point at which the device integration testing with the first CSP which will incorporate regression testing and testing of new devices. This milestone represents the date by which the formal Notice to amend the Charging Statement, which we expect will include the DBCH charges, will be submitted to Ofgem. This Notice will propose that the changes come into effect from 1 April Note: the changes will be incorporated into the standard process to refresh the Charging Statement each year. This milestone represents when the upgraded GFI with DBCH hardware and firmware will be available. This milestone marks the point at which the final Test Phase Complete Certificate issued by DCC in respect of Pre-Integration Test Phase for R2.0 This milestone represents when the Order Management System (OMS) will be available for all regions to enable unconstrained forecasts of Production Communications Hubs This milestone represents the latest point when the Common Test Scenarios Document and the Enduring Test Approach Document will be baselined by TBDG. This milestone represents when the DBCH Instrumented Test Communications Hubs (ITCH) for the North region and the wired DBCH ITCH for the Central and South region will be available to order. This milestone represents the achievement of the Entry Criteria outlined in the approved Testing Approach Document for Release 2.0 as determined by DCC. The R2.0 SIT phase will test the integration of all the DCC Systems required to support R2.0 This milestone represents the date when all Communication Hubs products will have achieved ZigBee Certification. This milestone marks the point at which the final Test Phase Complete Certificate issued by DCC in respect of Pre-Integration Test Phase for R2.0 This milestone represents the date by which the Charging Statement for Regulatory Year ending 31 March 2019 must be published, which we expect will include DBCH charges This milestone represents the point at which the DCC has completed the system integration test phase (Solution Test and Service Provider User Acceptance Test (UAT)) for all regions for R2.0 SBCH functionality by meeting the exit criteria set out in the Testing Approach Document for Release 2.0. This milestone represents the point at which the Device Integration Testing with the first CSP for DBCH will commence This milestone represents the point at which UIT entry criteria have been met for SBCH R2.0 functionality for all regions as defined in the TAD. This milestone represents the end of SIT and DIT phases for SBCH. This milestone represents when the DBCH Instrumented Test Communications Hubs (ITCH) for the North region and the wired DBCH ITCH for the Central and South region will be available for use in UIT (subject to orders being placed 12 weeks prior to this). This milestone represents when the Order Management Systems (OMS) will be available for all regions to enable unconstrained orders of Production Communications Hubs This milestone represents the point at which the DCC has completed the system integration test phase (Solution Test and Service Provider User Acceptance Test (UAT)) for all regions for R2.0 by meeting the exit criteria set out in the Testing Approach Document for Release 2.0. DIT complete 13/07/2018 This milestone represents the point at which the device integration testing will complete. UIT DBCH Commence 19/07/2018 This milestone represents the point at which UIT entry criteria have been met for DBCH R2.0 functionality for all regions as defined in the TAD. DBCH CPA Complete 31/07/2018 This milestone is complete once both CSPs (Arqiva and Telefonica) have Certified Product Assurance (CPA) certification for DBCH to be used in operation at the time of DCC Live (GBCS v2). This milestone is the point at which: BEIS has activated the appropriate provisions within the SEC enabling live DCC services for Release 2.0 (e.g. enrolment and communication) to commence. R2.0 Code into Live 30/09/2018 DCC systems have been successfully uplifted to R2.0 in all Regions. DCC have made available the R2.0 Communications Hub firmware for SBCH and DBCH in all Regions. DCC Operations have accepted R2.0 services into live. First batch of production DBCH available 15/10/2018 This milestone represents when the first initial batch of compliant production DBCHs in all Regions will be available. Full volume production DBCH capability 13/12/2018 This milestone represents the point at which DBCH can be delivered at full volume by the DCC in all Regions in accordance with the SEC (F5-F9). DCC Public Page 20 of 56

21 3.4.2 Commencement of Testing for both SBCH and DBCH The delivery of DBCH and upgrades of SBCH are assured by a robust and lengthy programme of testing that straddles both RY2017/18 and RY2018/19. This will ensure that the Release is fit for purpose and builds on the lessons learned with regards to testing of the R1.2 and R1.3 solutions in previous years. As a summary, testing will be performed following established industry practice the changes will be developed and tested by service providers, then subjected to integration testing by DCC and then made available to users for integration testing with their systems. Testing will also be conducted in a way that ensures the changes fully meet the new requirements and obligations, at the same time as ensuring that the changes do not undermine the ability of parties to continue to meet their existing obligations. In the following sections we provide information on the programme of testing focusing on the activities of RY2017/18. We provide a high-level timeline for testing of the overall solution, as well as an explanation of the various test phases and progress against these phases. Development of the Proposed Testing Approach for R2.0 On 23 February 2017, the Secretary of State directed DCC to produce a Testing Approach document for Release 2.0, in accordance with Section X11 of the Smart Energy Code. The following testing objectives were contained in the X11 Direction received from the Secretary of State: demonstrate that new version 1.1 of Communication Hubs designed to comply with CHTS v1.1 do comply with CHTS v1.1; demonstrate that Communications Hubs that comply with CHTS v1.0 can be upgraded to comply with CHTS v1.1 via a firmware upgrade sent over the Smart Metering Wide Area Network; demonstrate that DCC and the component parts of the DCC system together with version 1.1 Communication Hubs operate and interoperate with each other, and with User Systems and RDP Systems to ensure compliance under the SEC; demonstrate the extent to which the DCC Total System and both new 1.1 CHs and those upgraded from CHTS v1.0 are capable of interoperating with the Device or Devices that from part of an Enrolled Smart Metering System and IHDs; enable users to test the interoperability of their User Systems with the DCC System together with 1.1CHs, and that Testing Participants can test the interoperability of Devices that comply with the requirements of SMETS v3.0 with the DCC System. In response to this, DCC developed a plan and proposed approach for testing of the overall R2.0 solution. This consultation was outlined in the SEC Variation Testing Approach Document (SVTAD) and was consulted on for four weeks in late The proposed approach was subsequently signed-off by the Secretary of State (SoS) in January 2018 following agreement with our FSPs and wider stakeholders. Timeline and High-Level Plan The figure below shows the high-level timeline for R2.0 testing up until Go-live in RY2018/19. DCC Public Page 21 of 56

22 Figure 3-3: R2.0 Testing Timeline In practical terms figure above illustrates three distinct blocks of the overall testing timeline. These are as follows: BLOCK 1: Early Integration (DSP Only). Regression testing of the R1.3/1.4 functionality by DSP only for backwards compatibility, plus testing of new DSP GBCS2.0 functionality with a CSP Simulator BLOCK 2 GBCS2.0 testing with a Single-Band Communications Hub for all SP s. Testing of new GBCS2.0 functionality between DSP and CSPs BLOCK 3 Dual-Band Communications Hub Testing for all SPs. Testing to complete the scope of Release 2.0 All Communications Hub variants will be subject to testing in R2.0. Testing Sub-Phases The blocks outlined above are further broken down into phases that are defined and agreed with stakeholders as part of the programme. The overarching principle is to progress testing from each phase iteratively, and to facilitate progress and provide access to Parties for testing earlier than waiting for a test phase to complete, these are steps to develop and assure code or products prior to making them available in production. There are four test phases: PRE-INTEGRATION TESTING (PIT) this covers the testing by DCC Service Providers undertaken individually to verify that the solution meets the requirements. SYSTEM INTEGRATION TESTING (SIT) - confirms that the different DCC Service Provider and DCC internal systems work together effectively to meet the requirements of the SEC and operate as a working system for Users. DESIGN INTEGRATION TESTING (DIT) - Device Integration Testing (DIT) will utilise selected smart metering devices to verify the changes to the Total DCC System, where suitable devices are available to support testing. USER INTEGRATION TESTING (UIT) - allows users to test their systems with the DCC Total System before changes are made available in the production environment. DCC Public Page 22 of 56

23 At the time of submission of this document, all PIT phases have successfully completed and exited the test environments from both our CSPs. SIT for DBCH has also been concluded by both our CSPs, and testing has now moved into the UIT stage to ensure the solution is fit for purpose for users before roll-out later in In parallel to this the DIT phase is being undertaken independently following the lessons from Releases 1.2 & 1.3. A UIT-B environment for SBCH was made available for test participants from 21st May 2018 (in line with the agreed R2.0 BEIS incentive regime) and will run until the 7th of September At the time of publication of this submission, the UIT-B environment will also support DBCH from the 19th of July and will also run up until the 7th of September Development and Agreement of the Incentives Regime In December 2017 BEIS consulted with SEC party members on a proposed Incentives Regime for R2.0. There were four delivery milestones that would need to be met to ensure that DCC retains the margin for delivery of R2.0. These milestones commenced from May 2018 and are due to be concluded in December These are: MILESTONES 1A 3 and 1B: constitutes all the activities undertaken by the DCC to provide a User Integration Testing (UIT) facility for the DCC Systems functionality relating to upgraded SBCH, including by making available upgraded test SBCH for use. These milestones need to be met by 21 May MILESTONES 2A and 2B: constitutes all the activities undertaken by the DCC to provide a User Integration Testing (UIT) facility for the DCC Systems functionality relating to upgraded SBCH and upgraded DBCH, including by making available both upgraded test SBCH and DBCH for use. These milestones need to be met by 19 July 2018, MILESTONES 3A and 3B: constitutes the activities relating to delivery of DBCH during the period which falls after the SEC modifications requiring the DCC to provide Enrolment and Communications Services in accordance with R2.0. This specifically includes becoming effective in relation to Smart Metering Systems located in each region, being supported by appropriate DCC Systems functionality, and to make a limited quantity of DBCH available to SEC Parties. These milestones need to be met by 15 October MILESTONES 4A and 4B: constitutes the activity of delivering DBCH that are required to be delivered to support the roll-out of Smart Metering Systems in each Region, during the period which falls after the SEC modifications requiring the DCC to provide Enrolment and Communications Services in accordance with R2.0. This specifically includes becoming effective in relation to Smart Metering Systems located in each Region, being supported by appropriate DCC Systems functionality, and in response to Valid Communications Hubs Orders that, at the time at which they are submitted, are not subject to quantitative limits set by virtue of variations made under Section X3 of the SEC. This milestone needs to be met by 13 December BEIS issued the final decision on the R2.0 Incentives Regime in April Our performance against each milestone will be determined by SEC party members, with additional assurance provided by an Independent Auditor as directed by BEIS. BEIS will provide the ultimate decision on whether DCC has successfully met the performance milestones as defined above. As each of these milestones fall within RY2018/19, it is expected that these will be reported on in the Price Control submission for RY2018/19. 3 Note: In each of the above, milestone A relates to the CSP North Region and milestone B to the Central and South Regions. DCC Public Page 23 of 56

24 3.4.4 Transition to Operations Towards the end of RY2017/18, DCC started to develop a plan to ensure a smooth transition of R2.0 functionality and enduring activities to Operations. Key to this included assessing the impacts, scoping the requirements and building on the lessons learned from previous releases. DCC anticipates that there will be an optimization of the current systems and processes to support R2.0 functionality. This will include integrating any technical changes required to support R2.0 on an enduring basis, as well as any interim or permanent changes in resource required to operate the changes. It is anticipated that these activities will be reported on in Price Control submission for RY2018/19. Resourcing R2.0 in 2017/18 Our approach to resourcing R2.0 has built on the lessons learned from previous Releases. These aim to balance the need to control costs and drive VFM with the need to ensure programme milestones are met with the expected levels of quality that our stakeholders demand. This helps to build external confidence in DCC s overall delivery capabilities and helps to demonstrate how the outputs have justified the resources expended to meet delivery. To ensure VFM and control of R2.0 program costs we have a clear recruitment policy that takes into account both permanent and contractor resource. For permanent staff a clear preference has been to ensure qualified and experience staff working on previous Releases are deployed into R2.0 to ensure the program benefits from relevant learnings. For contractor resource, these are only recruited if a suitable permanent resource is not available or cannot be made available in time to meet programme deadlines and milestones. Unless there is an ongoing business need, then there is the expectation that R2.0 contractor resources will be terminated on completion of their activities within the program. The planned implementation of R2.0 and DBCH has grown in scope and complexity since the programme inception in RY2015/16. As reported in our Price Control submission for 2016/17, we expected the R2.0 team to grow in RY2017/18 to meet the added demands of the programme. This has occurred in this Regulatory Year and it is expected that these numbers will be retained until implementation in RY2018/19. For RY2017/18 there have been a number of factors driving increase in team size. These are: Testing: testing for R2.0 forms a substantial delivery component of the program as this Release is larger and more complex when compared to R1.3 & R1.4. Therefore, each of the four testing phases of PIT, SIT, DIT and UIT has required a dedicated resource to coordinate each aspect of the programme. This has included ensuring that our CSPs are on track to deliver their testing obligations as per their impact assessment, as well as to ensure that all the requisite components are in place to ensure a smooth transition of testing from entry to exit of each testing phase. Where possible we will automate testing, an example being Meter Regression Testing (MRT). Changes to TSG: in addition to the testing of functionality associated with DBCH and SBCH variants, the need to integrate a substantial number of technical (GBCS) and regulatory (SEC) changes, as well as integrate internal changes, has required additional resources. This has included increases in Regulatory and Technical resources as well as supporting resources from across the program and wider DCC to ensure these changes are robustly planned for and integrated. Planning for Transition to live operation: this includes increase in Business Analyst time to build requirements to ensure a smooth transition when the functionality of the Release is implemented in RY2018/19. Solution Design: this includes ongoing development of communications hubs design as well as procurement and assurance of emulators. The figures below illustrate how our resources have grown at six-month stages in RY2017/18: DCC Public Page 24 of 56

25 Figure 3-4: R2.0 team as of 1st October 2017 DCC Public Page 25 of 56

26 Figure 3-5: R2.0 as of 1st April 2018 DCC Public Page 26 of 56

27 4 Transitioning the Business for Live Service Operations Update to the Operations Target Operating Model The change in Operations structure reflects the movement from developing capability being built to support a programme, to a full operating capability which is designed to meet the full rollout demands of the combined SMETS1 and SMETS2 meter environment. Figure 4-1: Updated Structure of DCC Operations The Operations structure is live from RY and is expected to endure for the life of the service. Management and leadership structures may flex up or down based on demand, but the overall structure is focused on efficient and effective service delivery. Senior managers with experience have been recruited to drive quality service across the DCC ecosystem so that all Customers can get the full value from the investment. DCC Operations has developed significantly from the original LABP assumptions for 5 key reasons, which have changed or were not known at the time of the original bid. The plan for development of the area has also grown due to changes in characteristics, scope, complexity, customers and service providers. Operations structure includes a growth of skills and resources which are now more specialist and can provide more dedicated support to underpin the size of the customer base and network usage. Increase in Customers DCC have continued to support new SEC parties to on-board to the DCC systems and services, although this continues to be in excess of the expectations set at LABP stage. Significant new small suppliers have signed up to the Smart Energy Code, 151 compared to an original list of 17 parties. Overall 310 parties are now signed up, compared to just 73 on the original SECAS list at LABP stage. Table 4-1: Increase in SEC parties from 2013 SEC Party Type 31 July 2018 SECAS Original List from 2013 Electricity Networks Gas Networks DCC Public Page 27 of 56

28 SEC Party Type 31 July 2018 SECAS Original List from 2013 Large Suppliers Other SEC Parties 89 3 Small Suppliers Other 3 Total The customer groupings, particularly the smaller suppliers, do have different needs and requirements. In some instances the newer market players are not traditional licence holders, and as the energy market decentralises we are seeing new entrants who have much higher requirements for support. Overall demand for the services is expected to grow as DCC Operations supports customers on-boarding to the service, support for installations and rollout and the management of the deployed network. Going forward, we expect the number of Users and customers to increase with the incorporation of SMETS1 into the live service in 2019/20. While not yet costed for this year, we also expect to see an increase in customers with the addition of the Switching Programme. Operating Model The operating model for Operations has developed to provide improved support to develop self-service channels (Level 0), and also to effectively manage the Service Providers by developing enhanced service desk and Technical Operations Centre (Level 2). Whilst self-service was envisaged in the LABP and is referenced in the SEC, it has become clear that effective management of this capability, and the adoption of self service capabilities needs to be a core competency for DCC operations. Additional resources in areas such as Knowledge Management, Process Design and Change. DCC Public Page 28 of 56

29 Figure 4-2: Existing Operations ecosystem The Operating Model will develop further in RY and beyond, with the deployment of SMETS1 and the enrolment and adoption of the c.12m meters and the associated new service providers. DCC is planning to grow based on demands from customers and service providers. Figure 4-3: Expanded operations ecosystem with the introduction of SMETS1 This represents a sheer increase in the volume of service required. Moving beyond ITIL As part of the move to a Technical & Service Operations model, OPs has recognised that the needs of customers have grown as they start to use DCC's service and understand how it impacts their organisations. This maturing of our customers has driven an internal recognition that the ITIL processes set up around processes such as problem management, knowledge management, and incident management, have gaps. These processes were set up in preparation of Go-Live and represented the best understanding at the time of how the service would run. As we are now actually in live operations, we are testing these processes in a live environment and realising that many need to be adapted or improved to fit the realities of the live environment. Support teams are being added to Operations which are additional to ITIL, but which address real customer risks or demands. Reporting increases in demand for data and comparisons from customers and key stakeholders (BEIS and Ofgem), with increasing frequency and complexity. Forecasting higher demand due to growth in customer numbers, and the experience of low quality submissions necessitating additional effort to drive improvements. Monitoring proactive system and service monitoring via the Technical Operations capability to directly address risks as outlined by SEC Ops Group. DCC Public Page 29 of 56

30 Supply Chain increase in orders from wider customer base, lower consignment values, higher returns and rejections. Service Delivery growth of Service Providers to support SMETS1 and SMETS2 above the original LABP based on more complex design Production Proving new capability to address risk through the management of system heartbeat style checks and improved diagnostics to support incident resolution and service restoration to reduce demand on industry participants. Customer Experience focus on customers by an increasingly diverse structure with support for MSPs, MOPs and MAPs as well as Suppliers. CRM need to coordinate communications and service orientated information. Business Intelligence data and insight to support decision making for customers and DCC. Training support for customer education to drive quality and accuracy of service. Figure 4-4: Additional services on top of previous ITIL model This expansion represents additional services beyond ITIL. Scope of Support DCC has been asked by SEC panel to expand the scope of support for incident management process to address issues with HAN devices after initial experiences with customers (particularly Network Operators). DCC were following the SEC guidelines but at June SEC Panel it was outlined that this should change. The summary position indicated: The Panel were informed of an issue that was recently raised at the May Operations Group meeting concerning DCC treatment of Incidents from Network Parties. The Panel were requested to determine if the scope of DCC Incident Management should extend to meter related issues. The Panel noted DCC Public Page 30 of 56

31 DCC and SECAS interpretation that a meter is outside the scope of Incidents and Services as defined in the SEC per the SEC definitions of Incident and Services. However, the majority of the Panel were of the view that, Clause H9.2 (d) requires DCC to assign Incidents to the Responsible Supplier. In addition, the Panel were of the opinion that that it would be more efficient and effective for DCC, with its central role in smart metering to allocate Incidents to responsible parties. The Panel AGREED with the Networks view that Clause H9.2(d) requires DCC to assign incidents to the Responsible supplier. DCC see this as a significant change in scope as the management of devices was not envisaged at LABP, nor prior to the June 2018 SEC panel. This type of request is being made as it is clear that DCC is often best placed to support the full range of customers, even if this is not definitively specified in the Smart Energy Code. This expansion represents increased depth of responsibility for existing ITIL services. Service standard expectations As part of the move to a Technical & Service Operations model, OPs has recognised that the needs of customers have grown as they start to use DCC's service and understand how it impacts their organisations. This maturing of our customers has driven an internal recognition that customers are expecting services beyond ITIL service management framework. This expansion represents increased level of customer service for existing and expanded ITIL services. Major Incidents For example, we have had four major incidents since go-live. These experiences have demonstrated that we didn't have a robust enough communications process in place to provide guidance on when and who to send status updates to as the incident was resolved. These updates and gaps must be ironed out for two reasons. The first is that it will enable DCC to operate at scale. Gaps in processes are generally covered by manual work arounds or steps. At scale, these become an overwhelming drain on resource time. This leads to the second reason, which is that DCC is seeking to find efficiencies over the next several years until a stable operating environment is achieved. A seasoned look at how DCC carries out processes and a mechanism to measure how DCC performs is required to identify and realise resource efficiencies. The correct processes must be set, embedded, and then measured to achieve efficiency over time through continuous improvement. Performance Reporting The service standards are also now underpinned by the Operational Performance Regime. This regime is live from 1 st April 2018, after running for 2017/18 on a trial basis. It became clear that dedicated focus was needed to ensure that the service expectations which underpin the OPR would require a role to act as a single point of operational focus for the whole of DCC. The service requires managing all forecast inputs, actual results, risks and mitigations to ensure that DCC can meet the intent of the OPR incentive by reacting rapidly and effectively to any movement in the projected performance levels. The OPR regime was anticipated as part of the LABP, but the level of focus is a new requirement from and expectation from Customers. Business Support Systems (BSS): DCC has a plethora of interlinked systems surrounding the core messaging service. These systems support DCC business and operational processes across the Comm Hubs life cycle (from forecasting to retirement, including charging statements), reporting and performance metrics through BIMI, addressing problems / queries through the SSI and Remedy, managing the integrity and consistency of data across the DCC ecosystem. These systems were all built as per requirements set out in the SEC and through delivery of R1.2, R1.3 and R1.4. Customers are providing us feedback based on their experience interacting with DCC via the existing systems. We have been receiving feedback from our Users that, although these systems have been built as specified, they aren t meeting their needs. For example: DCC Public Page 31 of 56

32 Duplication of effort from customer part due to the two OMS interfaces Limited flexibility in the order management to adapt to customer business requirements Errors in manual process (e.g. ASN files loaded on SharePoint) Failures in CH pre-notification impacting the installation and commission in the field The original requirements for these systems did not dictate that a comprehensive end to end solution be provided. After the service went live, we started to recognise the potential impact of the business systems supporting the core service were built in isolation from each other. For example: OMS did not originally included functionality to support cancellations and other CH in-life management. This is why customers feel that OMS does not support their needs Work arounds have been implemented to cover the E2E gaps. This is why customers feel that manual processes are prone for errors. In addition, some of the requirements were not specific enough or evolved through out the time and resulted in DCC workarounds. Workarounds which will not be possible at scale. For example: OMS was not originally required to provide interface for customers In addition, technologies have moved on since we set out the original requirements of the systems and selected solutions. We have the option of leveraging technology which provides an alternative to effectively hard-coding the way customers interact with data. This was not envisioned as part of the original design. Therefore, we can address the customer feedback, inflexibility of existing platforms, and scalability without rebuilding existing systems. Lastly, we believe that the FSPs may have delivered their requirements as specified, but not considered their functionality in the end to end system, which means the functionality may not be working properly. A comprehensive end to end review will hold Service Providers accountable to delivering not just their requirements, but functionality that actually works in a holistic way. This is a question of agility and augmentation rather than rework. In the end, however, it is reflecting that customers have changing standards of service. Project to Business (P2B) The DCC system and service has been designed and implemented through several major releases, and has been operational since November A number of energy suppliers have completed live installations, although total meter volumes remained low. Volume ramp-up is expected during the autumn of 2018 as energy suppliers accelerate roll-out to meet the 2020 mandate. The rate of smart meter installations will increase from 0 to up to 200,000 new installations every week Confidence for volume ramp-up is dependent on: Resolution of priority defects from customer testing and issues identified during early live installs Confidence in Service Provider performance levels and resilience Resolution of customer system and meter issues and defects, and customer readiness for scale In 2017, DCC initiated a new programme of work called Project to Business (P2B). Project to Business was comprised of a range of activities to make enhancements to DCC s ways of working. This would ensure our confidence that the live service can be operated at scale; that new services could be delivered to time, cost and quality and more robust processes were in place. P2B was specifically not concerned with re-designing the business from scratch but instead ensuring that the basic capabilities required to support roll-out were comprehensive and effective. DCC Public Page 32 of 56

33 4.2.1 Designing an effective P2B programme In late 2017, [REDACTED] won a competitive procurement to review aspects of the Delivery Hub. Following a review of the scope of this work, early in the three-month assignment, [REDACTED] was asked to support the emerging Project to Business Programme. At the time, there were some 130 initiatives being taken forward in the business. Some of these were small projects and others were continuous improvement activities. Most were concerned with either assuring operations, given the future scale, or adding to the business capabilities in this respect. It was important that DEB had oversight of all such activity and that it could be ensured that anything taken forward was appropriately scoped and aligned with DCC s wider strategy. Working together, [REDACTED] and DCC staff created a P2B business case that identified the benefit categories for which the initiatives would contribute. This is shown in the figure below. Figure 4-5 Project to Business benefit areas On the left-hand side of the diagram are the P2B benefit categories. These include risk management and cost management against which all P2B activities align. [REDACTED] assessed all initiatives for benefits and strategic alignment, re-scoping, consolidating and terminating initiatives as necessary. Following a two-month period, the final list of six P2B programmes was settled on, as described below, together with a summary of each programme s scope and the challenge which it addresses. The readiness to scale programme included a performance assurance audit by [REDACTED]. DCC Public Page 33 of 56

34 Figure 4-6 High level scope of Project to Business Overall progress at end of RY2017/18 As the table below shows, we have made considerable progress in delivering our P2B objectives, and the P2B Transformation Programme has served its primary purpose to establish change momentum and catalyse delivery of our transformation objectives. Table 4-2 Overall progress against P2B objectives P2B Objectives Confident we can operate at scale Confident we can deliver new products to plan Robust business processes and controls in place Changing culture our Progress at the end of RY2017/18 Established capabilities for scale through R2S, which we will now iterate and enhance Built capability and momentum for internal change and improvement Established DCC on the front-foot with our Service Providers Established confidence with BEIS and our customers Increased total DCC resource from <200 FTE to >400 FTE Completed RY18/19 business planning, establishing functional budgets and resource plans, aligned to our operational and programme delivery plans Implemented new change delivery and risk management capabilities Established SEC-approved DCC Release Management policy Restructured and simplified governance and accountabilities Aligned accountabilities under rule of one Simplified internal governance, removing multiple internal forums and committees Implemented improved financial, commercial and compliance processes Established HR department and HR Business Partners for each function DCC Public Page 34 of 56

35 Established ways-of-working to break down organisation and location silos, and improve collaboration and team-working within and across sites Established recognition and reward for role-modelling of DCC values Progression into Business as Usual By March 2018, DCC had matured sufficiently to move away from transformation and align ownership and accountability to the operating model. In particular, DCC wanted to avoid embedding a permanent transformation or Ready to Scale agenda. This might create the perception of an ongoing ready to scale issue which was demonstrably not the case. Consequently, DCC closed the P2B Transformation Programme at the end of RY2017/18, devolving any ongoing activities to the responsible functions. In parallel, DCC has chosen to develop and mobilise a continuous improvement capability, enabling a structured approach to drive future performance and efficiency gains. Readiness to Scale Readiness to scale performance audit An important part of the P2B programme was the readiness to scale performance audit. This was undertaken by [REDACTED] around August 2017 following a competitive procurement exercise. It assessed the readiness of the DCC ecosystem, consisting of DCC and its supply chain, to operate at scale. The project conducted interviews with 71 people across the DCC ecosystem, reviewed supporting documentation and held an end to end scenario workshop to test a number of technical and operational processes. The process is summarised in Figure 4-8 below. Figure 4-7: Process for implementing the [REDACTED] The scope of the audit was set to be measurements of risk to DCC and the maturity of the underlying capabilities over the following areas of DCC operations Architecture and security Testing Operational processes Operations infrastructure and reporting DCC ecosystem wide Following the initial [REDACTED], the R2S programme director completed an assurance exercise to determine that all improvement actions identified by [REDACTED] were allocated to the business. In February 2018, [REDACTED] returned to undertake a follow-up study to capture the progress that DCC had made in maturing its capabilities. [REDACTED] found good progress has been made, as the graphic below demonstrates. In summary, at the beginning of 2018, no capability was measured to be requiring improvement. Similarly, an assessment of 26 risk categories across the above scope revealed that risks had moved from the analysis and planning stage and were mitigated, were in the process of being so or had been formally accepted by DCC. The latter category represented only 2 out of the 26 risks. DCC Public Page 35 of 56

36 Figure 4-8 Progress against Baringa performance audit - maturity The introduction of production proving capability into DCC Introduction and description of the change DCC wishes to undertake a number of proving activities in the live production environment ( production ) to provide customers with increased confidence in its systems in readiness for roll-out at scale. The principal objectives of these activities are to enable the following: Seamless release process - releasing new software into production seamlessly, where Service Requests have been tested against all Device types to provide Users with confidence in the system; End-to-end proving - prove the DCC Total Systems end-to-end, where Service Requests are exercised daily to ensure the systems are working correctly; Early identification of issues - proactively identify issues in the production environment before they impact Users; Fast triage - speedily triage and resolve User issues to minimise disruptions and loss of service to Users; and Prove fixes - prove fixes following implementation. DCC has experienced faults in the live environment that are specific to the production environment; they cannot be tested/ identified in the test (PIT, SIT and UIT) environments. This has led to release failures. However, DCC s diagnostic capability is limited and slowed down by the fact that DCC is unable to replicate faults (without requesting assistance from a DCC User) that have occurred in the production environment. This has weakened User confidence in the DCC s ability to deliver high quality systems and services. The delays caused by these issues imply greater direct costs and inconvenience for Users, with possible resultant delays and loss of impetus for their rollout plans; and greater costs in the form of DCC charges (since increased DCC resources will be required to handle the cascading problems). Clearly there are also negative reputational and financial consequences for DCC. DCC considers that these issues can be avoided and the risks to the strategic aims of the programme mitigated if DCC has production proving capability which allows DCC to interact with real Devices in the production environment. DCC conducted a detailed analysis of the options available to achieve its production proving objectives. DCC put forward an option which would allow DCC to have the ability to install, commission and interact with real Devices in the live environment. This would be limited to Devices deployed for proving purposes only there DCC Public Page 36 of 56

37 will be controls in place which stop DCC from communicating with non-production proving Devices in the live environment, and the proving would be undertaken in a controlled non-consumer environment. DCC asked BEIS for its agreement to consult on DCC s proposals and for it to use its Section 88 Powers to amend the SEC to enable DCC to implement Production Proving Party capability. Following consultation with the industry, and some minor amendments, BEIS put the necessary changes to industry codes before parliament. Driver and trigger of the change DCC continues to undertake rigorous testing of DCC Systems in the PIT, SIT and UIT environments. However, under the existing regulatory and security arrangements, DCC is permitted only limited capability to test with real Devices in the live environment. For R1.2, DCC worked with BEIS to introduce changes to SEC to enable proving of production Communication Hubs. Whilst this has enabled DCC to undertake some proving activity, the scope does not include meters. Since going live with R1.2 (November 2016), DCC identified a number of faults in the live environment which were not apparent during testing. Two such examples of faults are: Example 1: Commissioning issues in first User installs in North region DCC has been experiencing ongoing issues with the first User installs taking place in the North Region. These issues have manifested as erratic device installation and commissioning. One User had to postpone installing and commissioning Devices in the North Region until the issues were resolved. Had the DCC been able to carry out full installation and commissioning against different meter sets in different Regions, then it is feasible that DCC would have been aware of the problems before the customer and it is certain that better triage, without the need of customer assistance, could have been carried out. Example 2: High levels of device alerts For the Devices that have been successfully commissioned in production to date, DCC and Users have experienced high levels of device alerting. These issues were not experienced or identified in testing, because the Devices are different (they are production Devices, not test Devices) and are being installed on a different platform (the production platform, not a test platform). If DCC had the ability to fully prove its production systems, these issues could have been identified and resolved (speedily) before they impacted Users. Some further examples of the faults that have been encountered in the live environment are provided in section 2.2 of the annex. The cause of the problem Due to the differences between the test environments and the live environment, these issues could not have been identified in the test environments. Two examples of faults are The test environments are purposely designed to be more dynamic and fluid as a result of fixes being tested in support of Incident and defect resolution. Also, they are generally a release ahead of production due to defect fixes being applied to support end to end test defect resolution. For example, DCC s UIT A environment is functionally equivalent to live, but also functionally ahead as it is a test environment where new functionality/ fixes are tested, meaning the code base will often be different. Other differences are as follows:. Different security - the test environments use a different SMKI repository and SMKI certificates. This means that faults and upgrades relating to this functionality can only be identified in the live environment; Smaller scale - the extant test environments are not built to production scale and are only functionally equivalent to production. This means that the end to end production environment performance and performance related issues can only be predicted via these environments rather than definitively identified; DCC Public Page 37 of 56

38 Configured differently - the test environments are not always at the same configuration baseline as production. This is because workarounds are often applied in this environment to enable successful testing (e.g. manual configuration changes may be applied in the test environments that would be implemented as automated configuration once implemented in production); and Not a cloud solution - pre-production (option 1b) will be a hybrid cloud solution. It will therefore not be an exact replica of production until production is also a hybrid cloud solution. DCC considers that these issues can be avoided and the risks to the strategic aims of the programme mitigated if DCC has production proving capability which allows DCC to interact with real Devices in the production environment (or a pre-production environment). Customer and other stakeholder views DCC sought customer views on its preferred option of production proving this is discussed in the following section. Two fora were used to explore the scope of DCC s preferred solution; the Customer Operations and Business Improvement (COBI) Forum and the Design Release Forum. In both fora, customer expressed support for DCC preferred option and expressed the following additional views; COBI forum - 14 December 2017 Key outputs were as follows: Agreement on industry benefits - General agreement that production proving would certainly benefit the industry. Proving of the Change of Supplier (CoS) Service Request was highlighted as being critical. Energy suppliers, in particular, wanted the Change of Supplier Service Request to be proven in production. Proving of HAN performance customers are keen that HAN performance is proven as part of production proving. DCC Production Proving Party of the options presented, this was a preference. DCC Design Release Forum, 21st November 2017 General support - for DCC undertaking production proving. Independence in triage of faults - Noted that DCC having the ability to triage faults without reliance on a 3rd party (known as Option 3) would help to speed up fault resolution. Support for DCC option 3 - Support for Option 3 subject to security concerns and risks being mitigated. Process: Trade-offs and options considered Given the production proving has security considerations, DCC proposed to BEIS that it decide whether to proceed with the options that were generated by DCC. In this section we cover: Decision accountability and process - the questions posed to BEIS for its consideration. Options that were considered the options under consideration and the one chosen to present to BEIS (option 3) Proposed solutions A discussion of Option 3 in more detail; and Options that were dismissed A discussion of the trade-off that informed our decision. Decision accountability and process Given that the proposed solution will impact the existing security arrangements, which Government and DCC has always regarded as a particular concern, we believe the decision on whether DCC should implement DCC Public Page 38 of 56

39 Production Proving Party capability is more suited to BEIS given its role in the programme. DCC therefore proposed that BEIS made the following decisions: Is BEIS content with the recommendation that DCC should implement Production Proving Party capability; and That BEIS consider using its Section 88 Powers to amend the SEC to enable DCC to implement Production Proving Party capability. DCC s proposal was also shared with the SEC Panel s Security Sub-Committee (SSC) and implementation of the solution will be subject to SSC s agreement. Options that were considered DCC has identified a number of options to enable it to undertake production proving. We have conducted a thorough review of each option to help us identify the best solution. This has entailed evaluating each option in terms of its strengths and weaknesses and the extent to which the option meets DCC s production proving objectives. The principal objectives of these activities are to enable the following: Seamless release process - releasing new software into production seamlessly, where Service Requests (SR) have been tested against all Device types to provide Users with confidence in the system; End-to-end proving - prove the DCC Total Systems end-to-end, where SR are exercised daily to ensure the systems are working correctly; Early identification of issues - proactively identify issues in the production environment before they impact Users; Fast triage - speedily triage and resolve User issues to minimise disruptions and loss of service to Users; and Prove fixes - prove fixes following implementation. We have also assessed each option against criteria which are cost, security impact, risk and implementation regulatory impact, stakeholder impact and risk. In Table 4-3 below, we have summarised a description of the options: Table 4-3: Options to undertake Production Proving Title Option Key Benefits Key Constraints Preproduction environment (*different usage to live environment) 1a Pre-production with infrastructure a close replica and same code base to production Provides high confidence for new releases and can triage functional faults and some non-functional. The biggest constraint in using a pre-production is the fact that live Service Request monitoring of the production system cannot be carried out, and therefore DCC will still be behind Users in becoming aware of environmental issues. Costs significantly higher than other options ( 50m+) and time to implement 12 months +. DCC Public Page 39 of 56

40 Title Option Key Benefits Key Constraints 1b - with the same code base as production, but different infrastructure (UIT-A or a cloud based solution) Provides high confidence for new releases. UIT-A is capable of acting as a pre-production environment, but cannot be considered a true reflection for performance and resilience issues. If UIT-A is not used then a cloud based pre-production could be used, which would have the benefits of not being restricted by Service Levels that are currently in place for UIT-A. As a hybrid cloud environment would not enable proving of environment configuration / implementation issues for certain sub-sets of the solution (core IT stack). Would not be an exact replica of production (different infrastructure). It would not be possible to run full diagnostics against this option as it would be a different environment. Code based issues could be diagnosed, but not environmental issues. Costs significantly higher than other options ( 40m- 45m) and time to implement 12 months +. Utilise energy supplier 2a utilise existing energy suppliers 2b supplier in a box (via MSP) Allows for end to end systems proving, post release proving and can triage faults. Allows for end to end systems proving, post release proving and can triage faults. DCC is required to manage multiple suppliers. Incident resolution slowed down due to reliance on 3 rd party. Increases DCC s risk of non-compliance with its Licence - working with energy supplier may increase the risk of unforeseen market distortions and discrimination. Incident resolution slowed down due to reliance on 3 rd party. Potentially raises wider regulatory concerns as DCC will need to restrict the supplier s ability to supply energy and compete in the supply market. Potentially long lead time in comparison to other options(setting up a supply company will be time consuming). DCC Production Proving Party 3 DCC production proving party Allows for end to end systems proving, post release proving and can triage faults at speed as the PPP will be an internal DCC function (within DCC Technical Operations) and there is no reliance on a 3 rd party. Regulatory and security amendments required. Greater DCC investment (in comparison to other options). DCC Public Page 40 of 56

41 Title Option Key Benefits Key Constraints Early roll out of releases to some Users Do nothing 4 early rollout of releases to some DCC Users Provides high confidence for new releases. 5 do nothing No investment, security impact or regulatory changes required. Proving capability is limited to releases, this option does not enable daily proving of DCC systems and does not enable DCC to triage faults occurring in live. Continuation of issues in live results in loss of service resulting in direct costs to Users, potentially also increased DCC charges due to release failures and high volume of Incidents resulting in the need to deploy additional resources to handle the cascading problems. Impacts roll-out progress, impacts DCC meeting operational performance targets. Proposed Solution (Option 3) DCC considers that Option 3 is the most effective of all the options considered for three principle reasons: It meets the objectives in respect of meeting the principal production proving objectives i.e. it provides a secure and reliable service for end to end systems proving, post release proving and for triaging faults at speed. It can be managed securely - Option 3 impacts the existing security arrangements and this has been the subject of extensive discussion between DCC and BEIS colleagues to address concerns that these changes could adversely affect the security of the system. After careful assessment of the risks, mitigations have been identified. It is welcomed by our customers - Consultation with DCC customers also suggests that this approach would be welcome (subject to a costs breakdown being shared) and more generally that the DCC undertaking production proving will be beneficial to customers and the programme, as a whole. Options that were dismissed Options 1a and 1b - have been dismissed on the basis that the implementation lead times and costs are significantly higher (in comparison to the other options). DCC s proving ability is limited (in comparison to option 3) and the high investment is therefore not considered economic and efficient; Option 2a - is dismissed on the basis that DCC has concerns that contracting with energy suppliers (and certain energy suppliers having early access to new DCC releases) will increase the risk of unforeseen market distortions and discrimination and therefore increase DCC s risk of non-compliance with its Licence; and Option 2b - is dismissed on the basis that setting up an energy supply company would entail considerable work (and potentially long lead times). Furthermore, DCC does not have absolute certainty at this stage that the solution does not give rise to wider regulatory concerns given that under this arrangement DCC would need to restrict the supply company s ability to supply energy and compete in the supply market. DCC Public Page 41 of 56

42 Option 4 - is dismissed on the basis that it provides very limited proving capability; it only enables post release proving, DCC will not be able to prove systems on a daily basis or undertake diagnostics, the option therefore does not meet DCC s production proving objectives; and Option 5 - is dismissed on the basis that the existing position is unsatisfactory and gives rise to delays and additional costs. What was implemented Scope DCC would have the ability to install, commission and interact with real Devices in the live environment. This would be limited to Devices deployed for proving purposes only there will be controls in place which stop DCC from communicating with non-production proving Devices in live, and the proving would be undertaken in a controlled test environment. Changes are required to the Smart Energy Code (SEC) to enable this. Consultation undertaken with DCC customers suggests that this approach would be welcome (subject to a cost breakdown being shared) and more generally that the DCC undertaking production proving will be beneficial to customers and the wider programme. Benefits Constraints Allows for end to end proving of the solution to real Devices in the production environment. Allows for post release production proving. Diagnostics can be run against this option. DCC has greater control for diagnostic capability (as no reliance on non-dcc party). No requirement for purchasing separate diagnostic tools Triage would be possible for functional Incidents, and within the control of DCC (no reliance on non-dcc party) Environmental issues would be visible Regulatory changes required. Security architecture amendment required. DCC will need relationships with device manufacturers. The solution requires greater DCC involvement (hands on). Greater integration with adapter and head end costs. Own RDP feed along with management (lead time and costs to deliver). Anticipated Costs Estimate Impacts Set-up costs [REDACTED] Operating costs [REDACTED] annually (under further review as they are considered high) Security (impact is low) impact is considered low as mitigations have been identified. The existing security controls prohibit DCC from acting in a User role. This restriction is intended to avoid security breaches resulting from the compromise of one organisation, and reflects that the DCC has functions that are not operated by a User. However, mitigations have been identified and as a result the security impact is considered to be low (see Annex section 5 on DCC Production Proving Party solution for details). The final solution will be presented to the SSC and implementation of the solution will be subject to SSC s agreement. DCC Public Page 42 of 56

43 Regulatory impact is high. Changes are required to the SEC (and possibly the Licence) to implement the solution. Stakeholder (medium) impact to SP to deliver the solution. Key events during implementation On 14 February 2018 BEIS issued a consultation seeking stakeholder views on changes to the SEC to permit the DCC to develop and use a Production Proving capability. During the consultation period the proposals were widely circulated across enduring governance groups, several existing working groups within the Smart Metering Implementation Programme and a public presentation and discussion of the proposals was also held. The consultation closed on 14 March BEIS received 12 responses from energy suppliers, the SEC Panel, a managed service provider and from the DCC. A selection of three points made by respondents to the consultation and BEIS s response to these are stated below Customer support acknowledged - The majority of respondents agreed that SEC changes should be made to permit the DCC to carry out Production Proving, although various points of detail were made. However, one respondent did not agree with the proposal and another was of the view that a different option should be implemented. Benefits of wider device scope acknowledged - It is noteworthy that BEIS described the potential benefits from DCC being able to communicate with a range of devices including meters (rather than just communications hubs). These devices have substantially more functionality than communications hubs and would enable the proving of a wider range of Service Requests than is available in relation to just communications hubs. Wider benefits support production proving despite impossibility of proving Change of Supplier functionality - One respondent noted that the proposed approach did not include the ability to prove change of supplier functionality and stated that this could prove to be a fundamental gap. BEIS agreed that ideally this functionality would also be included within scope, but the security constraints imposed on the solution (and discussed with the SEC Panel s Security Sub-Committee) were such that this was not possible. BEIS specifically made the point that an inability to test this specific functionality means that there is no value in implementing the proposals more generally. BEIS laid the necessary changes to SEC before Parliament pursuant to section 89 of the Energy Act 2008 Customer Focus Overview During the initial build phase of the DCC system, the focus was upon meeting the minimum specifications provided by the Smart Energy Code (SEC) and the DCC Licence. There is no requirement in either document for DCC to maintain a customer centric approach or for DCC to monitor Customer Satisfaction and Customer Effort. As DCC customers have moved into use of the DCC Production system, the DCC approach has moved from focussing on the build of our systems into the creation of a sustainable business. DCC recognises that to survive as a sustainable business, a greater focus on the needs of our customers is required. To this end, in the past year, DCC has created a Customer Experience Team and a number of independent projects to support this. 4 In addition, the Customer Experience Team is independently carrying out work in the following areas: 4 Readiness to Scale (operations programme) DCC Public Page 43 of 56

44 Customer journeys - The creation of Customer Journeys to support key activities carried out by DCC Customers; Measurement - Customer Satisfaction reporting and assessment of Customer Effort. The following sections of this paper will explore work carried out in these areas in more depth Driver for Change DCC s Operational processes were designed by business and systems architects and based upon the requirements of the SEC and the DCC Licence. They have not been developed in consultation with customers, though the SEC Modification process provides a regulatory vehicle for our customers to request change. Documentation of the DCC systems is largely within system and service design documents that are heavily technical. For a small number of complicated processes, where mandated by the SEC, DCC have created User Guides to support customers. With the DCC Board s focus on operating the business in the long term, DCC s underlying technology should be considered a platform to support customer requirements. This is a different ethos to simply running business processes to discharge narrow obligations. In order to deliver this change, DCC s proposed operational solution was to map out customers experience and measure satisfaction levels. In this section, two change drivers are discussed. The first relates to the drivers behind DCC s strategy to put customers at the heart of its business processes. The second concerns DCC s need to understand customers experience in more depth Customer journey mapping DCC employed the same tool that many of our customers use to map out the customer experience: a customer journey map (CJM). This is a visual representation of the experience distinct types of customers have when using a DCC service. A CJM tells a story from a customers' perspective identifying actions taken, channels used, key moments, motivations, pain points and touchpoints. DCC s CJM approach also highlights how customer interactions are met within DCC. For example, what DCC teams are involved in the underlying processes and the identity of the enabling services and their supporting systems. Finalised CJMs will be used to communicate with and educate customers. Customers need access to concise, simple and complete information on how DCC s services impact their own business processes and customer journeys. This allows customers to assess their own journeys against future changes, for example; Release 2.0, Switching and SMETS1. Whilst DCC considers that providing this information to customers is an example of being open and transparent, there are many hard operational requirements for working closely with customers. A complete understanding of the service experience by customers is necessary for both parties to avoid conflicts and gaps. DCC also needed to understand the experience its customers have when interacting with it and, how service delivery matches up to the organisation s customer promise. DCC had already constructed a number of CJMs, on an ad-hoc basis. Moreover, the CJMs were not fully embedded into the organisation. However, despite the immaturity of the CJMs, it was a useful platform on which to build and develop the tool further. Customer Journeys offer the following benefits to DCC: Outside-in perspective - They help to develop Smart DCC services from an outside in perspective, developing processes and services around the desired customer experience and outcome; Moments that matter to customers - They help DCC internal teams to understand the moments that matter for customers at different points in the journey and what may be potential pain points and challenges; DCC Public Page 44 of 56

45 Problem solving from a customer perspective - Encourages a customer centric approach to problem solving; A basis for improvement - They help to establish a framework for customer effort and improvement, at each point of customer interaction. Customer Journeys provide the following benefits to DCC customers: Better understanding - They help Smart DCC service users better understand how they will or do interact with Smart DCC; Provide documentation - They provide links to more detailed documentation; Identify participants - They identify which industry participants are involved at each stage of a process; Visible touchpoints - They identify impacts and touchpoints with the energy end consumer; Improved quality - They enhance the quality of the Smart DCC services delivered; Improved satisfaction - They potentially increase service user satisfaction. DCC considered a number of options to develop Customer Journeys most suited to our customers requirements Measuring Customer Satisfaction/ Customer Effort Without objective measures of customer satisfaction, continuous improvement of the customer experience is not possible. There are both quantitative and qualitative measures of customer satisfaction. However, with DCC s strategy to move customer support to the Self-Service Interface, it becomes increasingly important to capture customers experience at this operational interface with the DCC. DCC needs to provide a good customer experience under high volume operations and our systems cannot be a barrier to this. This means using tools and techniques that will withstand the potential scale of transactions. DCC s proposed solution was to map out customers experience and to measure customer satisfaction levels with a focus on customer touchpoints within the Self-Service Interface. A touchpoint in a customer journey is defined as a point in the customer journey where the customer interacts directly with DCC. In respect of the customer metric, this is split between measures of customer satisfaction and customer effort. These are defined as: Customer Effort This measures the customer s perception of the degree of effort that the customer has invested in a given interaction with DCC. Customer Satisfaction This measures the overall satisfaction that the customer has with the DCC service. In respect of the type of data used, this is split into quantitative, qualitative and derived data. With increasing automation and for reasons of efficiency an increasing number of DCC s customer journeys have touchpoints within the Self-Service Interface ( SSI ). The SSI allows authorised users, using supported web browsers, to perform a range of self-service interface functions that we refer to as interface transactions. These include, but are not limited to, raising and monitoring the status of incidents, viewing smart metering inventory, accessing external systems, viewing smart metering network information, running reports and viewing help information. Access to the data and functions of certain interface transaction is restricted to specific types of user, defined by their role(s). Access to the SSI is controlled by use of securely issued certificates that are protected the DCC Key Infrastructure (DCCKI) Intended benefits of Customer Touchpoint work: DCC Public Page 45 of 56

46 Figure 4-9 Benefits which flow from the outcomes of customer touchpoint analysis Measuring Customer Effort at touchpoints via the SSI and measuring Customer Satisfaction provides a rich source of actionable insights to identify areas for improvement in design and service. For example, measurement and analysis helps to identify efficiencies, set accountabilities, drive first time fix rates, reduce issue-resolution times and the cost experienced at scale. DCC will be monitoring both Customer Satisfaction and Customer Effort. It is intended to measure Customer Satisfaction and where possible Customer Effort in the following areas: Across business processes; At a customer touchpoint level Due process: Trade-offs and options considered Initial options for customer journey mapping DCC developed over time, but on an ad-hoc basis, a number of SMETS 2 "Customer Journeys". These were based upon bilateral conversations with our customers regarding issues experienced with their respective SMETS1 deployments. These journeys were used extensively to plan the unhappy paths and in the development of the Remedy incident management tool. The journeys existed in various formats and were not co-ordinated with each other. They covered a disparate number of processes (Onboarding, Change of Supplier, T3 Aerials). Twelve of these Customer Journeys were identified. Since those original journeys were constructed, customer forums have taken place and in some cases amendments to the journey and process have been agreed with our customers. We have also taken further learning from the SMETS1 experience. Despite this further learning, it was immediately clear that a number of the challenges that would be experienced during the deployment and life of Smart Meters were not covered. There was therefore a requirement to undertake a gap analysis to ensure requirements were prioritised. Moreover, the existing journeys would need to be updated, extended and to demonstrate the 'handshake' with customers processes. DCC Public Page 46 of 56

47 These interfaces to the customer were not available previously. This is because the customers had their focus on SMETS1 and had not produced or designed their journeys for SMETS2. Hence the following activities were identified: Design the template - Design a best practice customer-facing design for mapping and presentation of processes that customers can use as a supporting guide to their interactions with DCC (Customer Journeys) which broadens and deepens the existing approach and will allow DCC to drive continuous improvement activities; Update existing journeys - Update existing DCC Customer Journeys into that template Undertake gap analysis - Examine the gaps in the current suite of Customer Journeys and agree with customers which new Customer Journeys are priorities for development Three options were considered Option 1 Do nothing - This would introduce risks against the cost of delivering initiatives and an increased risk of service failure by one or more of our customers. Option 2 (Use internal resource) - We did not at that time have available internal resource to carry out this work. Option 3 (Approved): procure external resource to develop a standardized template and toolset and to map a number of Customer Journeys. This allowed DCC to address a risk to our reputation and to the Smart Metering roll out by providing concise information to our customers to meet their business needs and spreads knowledge of the DCC solution. Baringa Partners (LLP) (Baringa) were engaged at the end of 2017 to deliver an eight-week project to establish a Customer Journey capability by developing a tailored template, mapping seven initial priority journeys and then developing an awareness and embedding plan with supporting materials. The value of these maps has been recognised across the business and by BEIS and our customers Extension to the customer journey mapping exercise The Value for Money Board was asked to approve an extension to Baringa s engagement to map the remaining 4 high priority, plus 9 medium priority CJMs. This would be based on the developed DCC template and approach and provided our customers with a wide suite of Journeys that covered key interactions with DCC and their own key operational processes that impact with DCC. This project took place over another eight week period. This also trialled embedding of the process with R2.0 and SMETS 1 programmes. The work also provided support to DCC s training plan and its content as well as making a further contribution to the practical embedding of the CJMs into DCC s gating process. There were five options that were considered. Option A - Do nothing - Catalogue of customer journeys not expanded as per identified risk above. Option B - Use internal resources - Earmarked resource on maternity leave. Alternate resources redirected to other priority work. Option C - Proceed with mapping of 4 highest priority and 9 medium priority customer journey maps over 9 weeks. Option D - Proceed with the mapping all the remaining 21 journey maps. Option E (Approved) - As option C with the 4 high and 9 medium journeys mapped plus additional work on the training and gating embedding processes DCC Public Page 47 of 56

48 4.4.9 Customer Satisfaction and Customer Effort To fully mobilise this project, DCC needed a dedicated resource to embed the project and baseline current levels of Customer Satisfaction. Currently, key Subject Matter Experts are involved in other projects. DCC has therefore decided to engage an external consultant to provide resource. Outline Business Case Obtain quantitative data - Customer Satisfaction and Customer Effort will give DCC quantitative data so that DCC can feed into continuous improvements and identify areas of opportunity Identify improvements - DCC will quickly identify improvements before it scales and to and maintains service desk headcount at 120 Utilise benefits - Key corporate objective for 2018/19 is to implement this toolset and utilise outputs. Will enable DCC to become more customer centric Impact of Not Progressing - DCC will not achieve corporate objectives of improvements in the customer experience nor will it feed into the overall strategy to ensure DCC operates at scale Work was placed with Bright Consulting. Consistent with the DCC procurement strategy, this work was not placed via competitive tender as the total costs for the work are below 10, Customer Journey Mapping Tool Figure 4-10 An example of a customer journey Time duration of each stage - Stages are high level descriptions of every step of the customer journey, from left to right across the first lane of the template. Clear time indicators serve as SLAs and will be useful to 1) track service performance, 2) communicate clear SEC obligations to our DCC Public Page 48 of 56

49 customers and 3) manage customer expectations throughout the journey. Each stage is then detailed/explained in further detail in the lanes below it Storyboard - The storyboard lane helps to contextualise what the customer is going through at every step. The imagery brings each concept to life. Consumer touchpoints These highlight when the end consumer (the customer s customer) is impacted/involved in each stage of the customer journey and signifies a more urgent interaction. Customer Personas This indicates which different types of customers could be in action at each stage of the journey. Customer types may have diverse expectations, emotions and pain points at different times throughout the customer journey Goals - Having the customer s goal top of mind allows DCC to align the experience and associated processes to what the customer wants to accomplish Thinking/feeling This describes the customer s emotions, perception, frustrations, pain points and expectations of DCC at each stage of the journey. Customer and employee feedback and forums inform a journey s thinking/ feeling information over time. Understanding the emotions, perception and frustrations of a customer at every stage of the journey can help tailor the experience to them. It can also help Smart DCC anticipate pain points, rather than react to them. Customer inputs This represents the information DCC must provide the customer at every stage of the journey, in order for the customer to successfully complete the journey. It supports DCC proactively providing the customer with the right information and helps reassure the customer that Smart DCC has thought about their requirements. Channels - This lane indicates the channel(s) which may be used by the customer as they interact with DCC. These could be: WAN & DUIS, SSI, , Phone, OMS, SharePoint, Text, Forums, etc. Customer interactions with DCC and front stage DCC interactions These two lanes indicate the live interactions taking place between the customer and Smart DCC. These lanes can help understand how efficient a process is and how Smart DCC should respond to the customer at every stage The line of interaction and its corresponding arrows - The line of interaction is important as it outlines what the customer is directly seeing, in real time, allowing Smart DCC to better understand how a customer experiences its services. These arrows indicate who is driving the interaction between the customer and DCC. The line of visibility- Lanes below the line of visibility indicates where customers are no longer interacting with DCC in real time DCC enablers - This lane indicates the infrastructure, documents and systems that exist/run in the background ( back of stage ) and allow for every stage of the journey to take place. The enablers should be directly or indirectly working towards fulfilling the customer s goal. Main variations - This lane lists the main variations that could occur at each stage of the customer journey as well as items to remember/notice at every stage. The lane highlights areas of importance for the customer or for DCC and helps to identify specific differences that could occur at each stage, depending on who the customer is. Customer Journeys Mapped The following table identifies the Customer Journeys mapped by [REDACTED] during their two projects. DCC have further supplemented this suite using the tools created by [REDACTED]. DCC Public Page 49 of 56

50 Figure 4-11 Core customer journeys in live operations as defined by customers Customer Journeys within the DCC Change Process If there are any changes to the DCC Change Process, we will do so in a way that does not negatively impact on the experience of customers in interacting with the DCC. We will also ensure that we put forward changes that instead, positively impact on Customer Experience with DCC. Customer Satisfaction/ Effort Work is currently ongoing for the initial baseline Customer Effort survey. This Survey will assess our customers effort and issues with the Incident Management and on-boarding process (SEC Section H and Appendix AG) and will extend to journeys within the SSI. Improvements identified from this survey will be fed into the SSI/ Remedy Improvements Project and continuous service improvement initiatives Key events during implementation The work was outcome focused and DCC s objective was to obtain a set of journeys with accompanying capabilities such as a communications plan, training and embedding in the gating process. We engaged with customers through the customer operations forum (COFORUM) to update them and gain approval for the scope of work. We agreed with the forum what the journeys were, asked the forum to prioritise them as either high, medium or low, then asked the forum to validate them. By using the forum in this way DCC could be assured that the mapping of the journey reflected the customers own experience. DCC has made significant efforts to ensure that the capability to undertake future customer journey mapping will be embedded in the organisation. DCC s significant investment in internal training ensures that internal staff are held to account for the quality of the customer experience. This strategy is much more aligned with a customer centric culture. 5 Readiness to Scale (operations sub programme) DCC Public Page 50 of 56