DCC OPERATIONS UPDATE

Transcription

1 DCC OPERATIONS UPDATE 7 June 2016 Dave Broady Operations Director, Smart DCC DCC Public

2 Service Desk Core Team All staff trained by DCC 100% Availability in year up to 31 st May 2016 SD has gained ISO Certification of Launched 26 th January as per SEC H15 75 Connections forms received 1 Manager 84 quotations provided 16 Analysts 4 Installations Pending 1 T&D Manager 37 Connections Completed 2 Team Leaders Registration SMKI Registration organisations and individuals are authorised to get the credentials that will allow them to obtain the SMKI certificates which are needed for both test and live services. Applications received: 7Large Suppliers 8Network Parties 3Other Gateway Connections Prototype CH for Testing Parties can order Prototype Comms Hubs to conduct the End-to-End testing in a CSP or remote test labs. Applications received: 9Large Suppliers 2Small Supplier 1Other Remote Test Labs Remote test labs allow Parties to conduct End-to- End testing from a location of their choice rather than using the CSP test labs. Applications received: 7Large Suppliers s 691 Calls 594 Nominated Contacts established since January Lead operational contacts established for SEC Parties DCC Public 2

3 Augmenting Smart Energy Code obligations with Operational Readiness input Service Management System Platform build progressing well. Service Management Forums Ongoing opportunity for SEC Parties to help shape DCC services and capabilities Operational and Business Acceptance Testing Proving that systems and services are fit for purpose User training Install and Commissioning and Self Service Interface Training SEC Obligations Customer Journeys Transposing SEC obligations into Service Interworking guides Operational Reporting Providing operational information to assist Users in Go Live Foundation Learning DCC recommendations to maximise Right First Time installs Service and Operational Readiness Program Ensuring User facing services are adequately scaled in the DCC. DCC Public 3

4 DCC Back office/scalability Operational Readiness User consumable Service Readiness Operational Readiness underpins Release 1.X services Progress to Date Release 1.0 Release 1.1 Release 1.2 Release 1.3 SMKI Registration Gateway Ordering Gateway Configuration CH Forecasting & Ordering SM WAN Coverage Nominated Contacts Parse & Correlate (Beta) Incident Management SMKI Test Certificates DCCKI Registration SREPT Gateway Performance Reporting OMS Pt1 SMKI Live Certificates Test Remedy & SSI Gateway Cancellation & Renewal Pre UIT Testing Parse & Correlate CH Operational Testing Acceptance CH Remote Monitoring & Management User Entry Process Testing SM Inventory & Device Management Gateway Relocation, Replacement & Amendment CH Installation Training SMWAN Connectivity, Security & Coverage Upgrade DUIS Service Request & Alerts First monthly service reports Full Reporting Capability Full Functionality Prepayment Full Functionality Export Metering Remedy Full Install & Commissioning ability Certified Product Automation Full Anomaly Detection Full Alert Capability Full Service Request & User Case Capability SMKI Recovery Full BI/MI suite Ongoing Operational Readiness activities that enable Service Readiness Customer Journeys and Use Cases BCDR Business Hours Service Desk Manual Processes BCDR Problem Management Ready Demand Management Scenarios Release Operating Model Defined Full Incident Management Capability Ready Verifications of Process Manual Workarounds Ops SH lifecycle Modelling E2E Transition Approach User Reporting Packs Service Benchmarking Interim Data Integrity Checks War Room CH Returns Reconciliation Knowledge Management 24*7 Service Desk Defect Management Service Management Nominees Data Integrity Checks Industry Contact Management Capacity Management Forecasting Performance Management Reporting Catalogue Increasing levels of maturity through R1.x cycle DCC Public 4

5 User Customer Support New supplier confirms New supplier sends Consumer decides to Consumer contacts new validates customer details contract with the notification to respective change energy supplier supplier either direct (by including MPAN consumer in writing the Network Operator (gas or following marketing or phone, online) or via a (electricity) MPRN (gas) switch including tariffs electric) with a specific advice on best deals switching site and usage if available and T&Cs start date A B C D E Registration Data Providers submit daily update to DCC K New Supplier sends SR6.23 to instigate change of security credentials on devices L Z New supplier receives acknowledgement Complete DCC key steps and processes (refer to CoS DCC user to DCC user) AA Losing supplier receives DCC alert N27 and performs final CoS read AG Refer to CoS journey for full details of key DCC steps and processes M DCC receives SR6.23 New supplier receives service response confirming success of Change of Security credentials AB Losing supplier follows industry process to complete the CoS event AH DCC performs access control on original request including look up to registration database N New supplier is able to request opening read from meter device AC Consumer receives final bill from losing supplier AI Electricity Network Operator updates electricity registration database F G Xoserve updates the gas registration database The respective Objection process registration system Losing supplier is notified takes place. If losing informs both suppliers of loss of consumer. Able supplier is able to of change in customer to contest the switch and object then CoS is status follows existing processes cancelled and does H I J not go ahead New supplier cannot find the incident relating to the fault in the CH No objection R T New incident New supplier receives specific DCC error Generate message to indicate New supplier checks SSI New supplier confirms acknowledgement Fail failure of SR6.23 for open incident for CH Open there is an open incident response code as per incident O P DUIS or DCC Alert N26 Q S Successful New supplier closes CH incident on SSI (where applicable if the incident exists) AD New supplier follows industry process to complete the CoS configuration AE Consumer receives welcome pack from new supplier AF New supplier raises new incident on SSI (follow incident management process) Losing supplier is able to check status of the incident on SSI at anytime during the journey X The incident originator will be able to see the status of the incident Objection resolved Y AJ New supplier raises a new incident on SSI and makes a note about existing open incident U V SSI validates User SSI validates User New Supplier undertakes site visit to check CH as instructed by the CSP via the SSI as per CH Maintenance Support W Material Engineer resolves CH issue Draft v0.4 Consumer permits. access, carry out preinstallation checks Unable to connect to SM WAN (Arq) Try Comms Hub variant (e.g. Mesh) or Comms Hub aerial (Tef) Reschedule visit. User reviews how to proceed (check SSI, raise an incident, abort etc.) Key User DCC SSI/Remedy Installer Consumer Telefonica Arqiva Interaction with DCC Letters are to ABC facilitate comments Commission failure in these steps may trigger an incident to be raised Install Comms Install, join devices, Transfer security Hub, confirm commission creds. Install tariffs, operation via LEDs as & test Smart Meters, perform Safety Check per comms hub GPF and IHD. and Update Records support material SEC section F7 SEC section H5 and 6 SEC section H5 Options to resolve either: follow No SM WAN install Process or abort Abort visit. Raise No coverage incident with DCC Service Desk No SMWAN coverage, follow No SM WAN install process, Install CH as per CHSM NOTE: This journey shows the service interaction between DCC, User and Consumer and it is not to be relied on as a complete process, policy or instruction set. It is therefore recommended that the journey is read in conjunction with the relevant SEC obligations and subsidiary documentation. Note that the SEC references relate to version 4.3 may be subject to change as the SEC evolves. Refer to the CH Support Materials for further detail around obligations and requirements. Submit DUIS service request DCC Controlled Gather consumer feedback & take appropriate action as per SMICOP Give consumer IHD demo (if taken), safety & efficiency advice, contact details No SM WAN coverage incident raised with CSP, 90 days to resolve Complete postinstallation activities (Private Key Regeneration, enable Network Operator use, etc) Appropriate fix available Internal triage to assess incident Establish if network related issue (Arq) No Establish if property related issue (Arq) Reassign incident back to User for revisit (Arq) Yes Complete Job Status Report (DUIS Service Request) Mark incident for closure and update Service User (via SSI) No fix available (Tef) Link to master related network incident. Update (Arq) Update the incident with progress. This will give the User an update via SSI or Service Desk (Arq) End DCC gather and publish installation MI No SM WAN coverage incident raised with CSP, 90 days to resolve Assess incident and identify fix option Update incident with details of fix Update incident with no fix available Mark incident for closure and update Service User (via SSI) End End End Customer Journeys No SM WAN Expected Coverage Smart Meter Installation User Entry Checklist Comms Hub Lifecycle No SM WAN install and commissioning Change of Supplier Change of Supplier No comms available/faulty CH Security registration Comms Hub Exceptions (Tef) Other customer journeys being assembled include CH Product recall, Mass firmware roll-out, Anomaly detection DCC Public 5

6 Service Readiness Progress to date Tier 1 Services Product User Entry Services Core Comms & Elective Services Key Infrastructure Services Comms Hub Services Optional Data & Elective Services Service Management Business Services Reporting Services 108 sub-services Foundation SEC Licence Contracts SEC Subsidiary Docs Service Levels Reporting Use Cases Work Instructions User Guide Requirements 83% Design 72% Testing 39% Transition 39% Test Approach Test Scenarios Test Execution Defect Management Requirements Traceability Training User Release Notes System Readiness Process Readiness Data Readiness Requirements Service Introduction & Overview Service Design document Test plans Transition plans Test Results Use Cases Customer Journeys User Order forms Security Services Testing Services Notes: % figures indicates progress made to date Service drop is the logical grouping of the 108 sub services for optimal delivery These figures do not take into account the size and complexity for each service drop Transition Checklist Operational Acceptance Board DCC Public 6

7 Enhanced Service Support (ESS) Service Providers only SSMI Level 1 Support Level 2/3 Support ESS DCC back office full defect management SSI Service Managers DCC Service Desk Resolved by SD/Remedy Triage Point DCC Service Desk Ops/SD SME Support Resolved by Ops/SD SME Triage Point ESS ESS is crucial to establishing a stable platform for sustainable rollout. Key objectives: Support Users in using DCC Services for the first time Resolve early integration issues in the Production environment Use early learnings to refine and improve processes Prove that systems and processes will support rollout at higher volumes Prove forecasting/modelling accuracy Group daily call for those Users who have progressed past Entry Process Testing Comprises of Subject Matter Experts from e2e Smart Meter Infrastructure (including active meter and IHD manufacturers For meters, KPIs will be latency, frequency/size of firmware updates, proportionate/informative alerting ESS runs on a release basis only and will close when key issues/defects for that release have been resolved DCC Public 7

8 Demand Management (DM) Service Requests SERVICE REQUEST PROFILE RISK 80 EFFICIENT CAPACITY UTILISATION Service User A Service User B Service User C Service User A Service User B Service User C Similarity of demand profiles poses a risk to DCC System Ops may take defensive measures Policy on resource allocation subject to consultation Build Demand intelligence into User business processes 1. Scheduled SRs are less onerous than On-Demand 2. Retain process flexibility to shift/fragment SR peaks 3. DCC will measure User SR volumes by type from R1.3 Possible non residential/energy management loadings will complicate this further Please help DCC avoid unnecessary capacity enhancement spend, and risk of DM invocation. DCC Public 8

9 User Self Service Interface (SSI) Example used to diagnose CH related problems prior to logging an Incident. Train the trainer classroom based training will be available (July -> Sept initially) User guide and Webex overview under construction DCC Public 9

10 Performance Measures Summary 8 x DCC Code Performance Measures Target Response Times CPM 1 % On Demand CPM 2 % Future Dated CPM 3 % Alerts Incident Response Targets CPM 4 % Sev 1 /2 CPM 5 % Sev 3/4/5 Self Service Interface CPM 6 % SSI Availability SMKI Target Response Times CPM 7 % Cert Sign Requests CPM 8 % Repository Updates 127 x Service Provider Performance Measures Anomaly Detection Application Management Availability Communications Hub "Incidents" Communications Hub Connectivity Communications Hub delivery Disaster Recovery Incident Notification and Response Industry Registration Data Packet Loss Power Outage Events Service Management Target Response Times Testing Services Reported Key Partially Reported Not Reported DCC Public 10

11 DCC Code Performance DCC Operational Performance DSP Non Reported DSP Reportable measures Value for Money Development and Innovation 8 x DCC Code Performance CSP(C/S) Reportable measures CSP(N) Reportable measures Service Delivery Service User Benefit CSP(C/S) Non Reported CSP(N) Non Reported 8 x DCC Code Performance Measures 127 x Service Provider Measures Service Provider Margin at Risk OFGEM designed and administered Suggested categories and weightings tbc Licensee Margin at Risk DCC Public 11

12 Round Trip (RTT) and Target Response Times (TRT) Target Response Time: TRT = t 1 + t 2 Onward to/ from Device Device Device Device Home CH t 1 t 2 Smart Metering Wide Area Network DCC User Interface User System DSP TRT CSP RTT (pings) 50% of CH s pinged every month Includes mesh hops as relevant CH s don t time stamp actual traffic HAN Interface DCC RTT SMWAN Gateway Includes HAN and Meter response Not in scope for code performance Used by DCC Ops to distinguish between DCC and User(Meter) performance Code performance measure TRT s = DSP actual + CSP test DCC RTT = Actual times for every message (DCC + HAN/Meters) DCC Public 12

13 Operational Acceptance approach Business Acceptance Testing (BAT) is focused on service management process checks whilst OAT is concerned with infrastructure failover (BCDR), Technical Readiness and PEN testing. This must be applied to production environments. Note that some of the activities within OAT and BAT are proposals and are still being considered by DECC. 1) DCC Service Providers will conduct Operational Acceptance on their own systems prior to R1.2 2) BCDR testing is best exercised on the E2E SMIP infrastructure, but needs Users to be connected (ie we need to be Live before final tranche of OA can be fulfilled) E2E BCDR SP1 BCDR Primary Secondary SP2 BCDR Primary Secondary SP3 BCDR Primary Secondary Main objective is to prove that User business processes operate correctly on back-up DSP Systems. This one failure scenario supports many BCDR process checks. This test will need to be repeated every 12 months, but critically not at R1.3 Completed Pre R1.2 Go Live Completed Post Go Live in Production Request is for Users to accept additional maintenance windows between R1.2 and R1.3, whilst we soak test DCC s back-up systems over a 2/3 week period. DCC Public 13

14 BAT scenarios DCC have categorised the tests into those scenarios that must be proven prior to Go Live vs those that should be purposely validated ASAP in a multi-user Verification of Process (VoP) environment. Examples of Pre Live BAT tests are:- CSP WAN failure notification. User ability to run diagnostic and raise Incident ticket via Self Service Interface. Proven DCC Incident triaging to Service Providers. Security Incident procedures tested. Request Management fulfilment. Correct handling and validation of a User s anomaly detection profiles. Change and Problem Management routines validated Examples of Verification of Process are:- User initiated Incident against each Error Handling Strategy scenario. RDP Incidents raised by mail/phone. DCC detected Incident handed back to Industry for resolution eg Meter faults. Repeat Incidents trigger a Problem record. WAN failure handling during Change of Supplier or Tenancy event. Receipt of SP Month end Service reports. SSI publication of Live Service alerts and status. CH Returns and exceptions eg replacement of healthy device with TEF Mesh/T3 variant. DCC Public 14

15 Operational Testing and Validation summary Enhanced Service Support (ESS) ESS is run by DCC Operations and applies to the Production System Handover of Prod environment to Ops Operational Acceptance Testing Service Provider failover and roll-back. DCC R1.2 Business Continuity and Disaster Recovery Testing Test availability of DCC Back up Systems DCC R1.3 This is in addition to Test team support for Users progressing through Entry Process and E2E testing BCDR can only be satisfactorily completed once early adopters are connected to the Production platform Business Acceptance Testing Verification of Live R1.2 Process Verification of Live R1.3 Process Service Management processes Validation of live R1.2 processes CH exceptions SMWAN prediction Data Integrity checks Anomaly detection DCC <-> User BI/MI comparison DCC Public 15

16 Thank you. Questions? Dave Broady Operations Director, Smart DCC DCC Industry Team DCC Public