Query and Workflow Management Project Con Quest External

Query and Workflow Management Project “Con. Quest External User Group” 14 th January 2010

AGENDA -1§ Welcome § Project Background – brief recap § Principles § Chosen technology § Terms of Engagement § Project Approach § Timeline § Impacts and benefits § Pilot Process

AGENDA -2§ Project – Functional Update / Requirement Feedback § User Interfaces § Screens § Files § Data § Access Controls / Security § Process Updates § § Process Review – end to end (starting with the pilot process) Process Based Requirement Feedback User Account housekeeping Migration / Cutover strategy § AOB

Welcome & Introductions § Dave Addison Project Manager § Michelle Fergusson Project Officer § Dave Ackers Customer Data Services Manager § Emma Lyndon Customer Data Services Officer § Steve Deery Customer Data Services Admin

Q Project Background Why required and chosen technology

Principles of the Project § We have immediate drivers § Provide a stable system for Query Management § Ensure Continuity of Service § We are seeking to minimise changes to external users § But… there will be some change § There may be some changes from you that we can incorporate § Primary objective § Providing a functional Query Management Service to Users

Why did we choose BPMS? BPMS has been chosen as the strategic solution to replace Con. Quest for query and workflow management as it: - § Is a recognised contemporary solution for workflow related processes § Provides process analysis and simulation tools § Provides better integration between business, systems and processes § Links with other systems to support automation § Better interface with business through process modelling § Scalable solution § Offers capability that will support additional non Con. Quest processes

Terms of Engagement § External User Group Forum § Communication on Progress § Business Forum to highlight and discuss Impacts § Approval of Change § UKLink Committee (Technical) § Communication § xoserve. com / email / operational meetings / Shipper e. News § Interim Updates § Meetings § Venue / Frequency § Updates to other Established Forum?

Terms of Engagement § UKLink Engagement – § 4 months Operational Changes § 6 months System Changes Business Change Identified Business Forum Discussion Business Analysis Business Forum Agree UKLink Forum Discuss Reps Received & Considered Amend Proposal UKLink Forum Agree Implement

Terms of Engagement – Strawman § Con. Quest Approach – System Changes – File Formats Business Change Identified Business Forum Discussion Business Analysis Business Forum Agree Amend Proposal UKLink Forum Agree Technical User Input No Surprises UKLink Forum Discuss Reps Received & Considered Implement

Terms of Engagement - Strawman § Con. Quest Approach – Operational Changes - Screens Business Change Identified Business Forum Discussion Business Analysis Business Forum Agree Technical User Input Pre Agreed – Operational Contacts have Agreed UKLink Reps Amend Forum Received & Proposal Discuss Considered UKLink Forum Agree Implement

Project Approach How are we going to do this…?

Project Principles § The principles being applied are that… ü we will seek to minimise change to external Users ü changes identified will be communicated ü we will ensure that changes are documented, and communicated as we identify them ü there will be consequential improvements in the way we do things ü efficiencies will be identified and adopted

Indicative Project Timeline § Activities to date § Project – Delivery Stage Start – Oct’ 09 § 2 Phases: § Phase 1 – Con. Quest Processes § Phase 2 – Other xoserve processes with workflow characteristics that integrate with other parties § Each phase runs concurrently

Indicative Milestone Dates Oct’ 09 Mar’ 11 Project Start (Oct’ 09) Modelling & Design (Oct’ 09 – Apr’ 10) Pilot (Apr’ 10) Phase 1 Dev’t (Apr’ 10 - Aug’ 10) Shipper Testing (Aug’ 10) Ph 1 Implementation (Sep’ 10) Phase 2 Dev’t (Sep’ 10 – Jan’ 11) Ph 2 Implementation (Jan’ 11) Project Completion (Mar’ 11)

Impacts & Benefits What we told you last time

Impacts - Interface § Web User Interface § The IP Address WILL change § Planned to replicate Con. Quest screens § If there are consequential changes, we’ll discuss them with you § File Interface § Planned to retain formats § Data modelling might identify changes, we’ll discuss them with you

Impacts – Access Controls § Security Requirements § Browser based solution. As now, access limited to own data. § Password management (in line with IAD) § Amendment of password every 30 days § Password format convention § Ability to reset password § Time out § Management of User accounts § Inactive accounts locked after [3] months

What’s happened with your requirements ? § 27 requirements captured on 5 th October or from subsequent Shipper feedback § Grouped into 3 types: § General § Process specific § Security § Initial assessment by Developers to identify what BPMS can or can’t deliver § Unable to confirm some requirements until completion of Discover & Model phase

Shipper Requirements 1 Screen navigation using key depressions / enter key. However final commitment of the action must be by clicking a button. Will be delivered through BPMS. 2 Remove redundant screen templates eg. Meter Asset Will be delivered through BPMS. Provision of query specific mandatory data / data populated in defined fields. Can be delivered through BPMS but may have an impact on Shipper systems if fields become Mandatory. 8 Provide Network Operator Identifier on Theft Of Gas queries. NWO Id can be provided. Development of MODs 245 and 274 also need to be considered. 9 Where the meter asset is Imperial, provide adjustment volumes in metric. BPMS could convert from Imp to Metric (however this is only applicable for the 'final' resolution correspondence). 15 Streamline the number of query codes available. Where appropriate to do so, eg. same SLA applies. MOD 565 / Non 565 codes will not be merged. 24 & 25 Single sign on. Allow users to access authorised xoserve systems via a single 'log on' However this may not include the Gemini system. 27 Improve screen search facility to allow subsequent searches eg. include 'new search' button. Will be evaluated during detailed screen design. 3&4

User Interfaces § Comments within the User requirements regarding: § Do NOT retain Con. Quest ‘Look and Feel’ § Single Sign On for xoserve Web Apps § Greater usability – navigational screen changes § Removal of unnecessary screens (and codes) § On line help / hints and tips § Search facility

User Interfaces § UI Solution Proposed § Q Solution will use ‘off the shelf’ Web. Portal functionality § UI will not replicate CQ ‘Look and Feel’ § Changes to screens will need to be communicated within User organisations § Single Sign on to xoserve Web Applications § IAD and Con. Quest are xoserve current web apps § Develop consistent ‘Look and Feel’ between two applications § Q likely to deliver xoserve Enterprise Web Screens § xoserve Welcome § Security / password § Q will look very different from Con. Quest

User Interfaces § Web. Portal Functionality § Provides capability as per standard web apps § Improved Usability § Key stroke within screen movement (commit by online button) § Improved Navigation § Enables standard portlets to be included within the User Screen § Web. Portal provides User Screen Configuration § This may not be enabled § Development of entirely new web interface § Will not replicate unnecessary screens § Will retire unnecessary Query codes § But Not impact mod 565 codes

Con. Quest Look and Feel

Q For Illustration Only

User Interfaces § Search Facility § Capability to search against MPR § Will only enable search against queries when in User’s ownership § Will only be able to search against live data § Archived data will not be accessible § Data will be archived at [5] years § Data from Con. Quest at Q implementation will be archived if closed § On Line Help § UI will validate mandatory fields, not allow query commit if incorrectly formatted § Formats will be shown – e. g. DDMMYY § Hyperlink to User Guide § NOT A MICROSOFT PAPERCLIP!

Data § Comments within the User requirements regarding: § Amendments to Data Requirements § Identify key data items for Query Resolution § Provide structured formats – not free text fields § Changes to mandate data items § Pre-population of data from Source Systems § Rejection back to the raising User

Data § Solution Proposed § Process and Data Modelling being conducted for each Con. Quest Process § ‘To Be’ Data Models to be created § Changes to Inputs and Outputs § e. g. Output - Network Id requested to be provided in xoserve to Shipper To. G Notifications § e. g. Input – Customer provided Supplier Name in Network to xoserve GSR Notifications § Will be assessed by process § Changes communicated for approval as identified

Data § Solution Proposed § Prepopulation of Data from xoserve Source Systems § Prepopulation of Data from UKLink / MI Database § Undergoing assessment for performance impacts § Rejection back to User – Screen § Mandatory Data / Format Validation will be conducted prior to successful commit § Live validation against UKLink § Undergoing assessment for performance impacts § Rejection back to User – File § Responses will be back by file

Security § Comments within the User requirements regarding: § Security § Users able to Manage Accounts § User password reset § User account creation / deletion § User Report on Account Usage § Group Accounts

Security & Reporting § Solutions Proposed: § Security – 3 Tier Request Layer § Proposed Approach User New Account Request Shipper / Network User (LSO) Requestor Formal Request Approver xoserve Approval by xoserve – expected to be automated, based on valid requestor, but might be amended – e. g. if account numbers breached by a User organisation

Security & Reporting § Solutions Proposed: § Users able to Manage Accounts § User password reset § Individual Users reset § User (LSO) Requestors reset Individual Users passwords § User account creation / deletion § User (LSO) Requestors only § User Report on Account Usage § User ‘Pull’ Report - Not planned § Group Accounts § Need clarification

Q For Illustration Only

Security & Reporting § Technical Questions – Please Provide § Current Internet Browser § Internet Browser Version § Security Product works with IE 7+ & Equivalent § Organisation View on Cookies § Security Product requires “Cookies Enabled” § Assessment of premises that users will need to access the ‘Q’ system from. § Please assess with your organisation

Functional Features Your requirements and ‘out of the box’ functions

What we can do…. 1 Screen navigation using key depressions / enter key. However final commitment of the action must be by clicking a button. Will be delivered through BPMS. 2 Remove redundant screen templates eg. Meter Asset Will be delivered through BPMS. Provision of query specific mandatory data / data populated in defined fields. Can be delivered through BPMS but may have an impact on Shipper systems if fields become Mandatory. 8 Provide Network Operator Identifier on Theft Of Gas queries. NWO Id can be provided. Development of MODs 245 and 274 also need to be considered. 9 Where the meter asset is Imperial, provide adjustment volumes in metric. BPMS could convert from Imp to Metric (however this is only applicable for the 'final' resolution correspondence). 15 Streamline the number of query codes available. Where appropriate to do so, eg. same SLA applies. MOD 565 / Non 565 codes will not be merged. 24 & 25 Single sign on. Allow users to access authorised xoserve systems via a single 'log on' However this may not include the Gemini system. 27 Improve screen search facility to allow subsequent searches eg. include 'new search' button. Will be evaluated during detailed screen design. 3&4

What we can’t do…. 5 If an on-line help facility is available eg. 'hints & tips', ensure the ability to switch off. BPMS can deliver on-line validation eg. format of date field, & hyperlink to training / user guide, but will not provide a 'help' facility for each data item. 10 Address queries for aggregated meter points - Remove requirement for User to raise as individual queries and contact xoserve to advise that the queries are linked. N/A - Requirement withdrawn by requester. Provide rejection of invalid queries back to originator. If query logged via screen the user will know straight away if query accepted or not. Batch transactions will continue to be provided to a central point within each Shipper Organisation. Provide a synopsis of resolution data for closed queries including history & dates (particularly for Filter Failure queries). A synopsis screen will not be provided however the facility to search / interrogate historical queries will be provided up to the date queries are archived. 12 16 A Provide data amendment history, including prior to ownership of site? 17 18 20 A 26 Unable to provide due to restrictions around data protection / ownership. Provide 'real time' reporting. There are no plans to provide real time reporting. Performance reports are sent Monthly by the Customer Team. Provide facility for Shipper LSO to generate inactive user reports. There are no plans to provide Shippers with report capability. It would be useful if there was an option to swap the address over when carrying out address amendment, e. g. Flat A to Flat B and vice versa, because it is quite common to have this kind of mix up and it would negate the need to raise two requests. User will still need to log as individual address queries.

What we might be able to do. … 6 Ability to approve linked (same MPR) Filter Failure queries collectively rather than individually as now Will be evaluated during modelling phase. 7 Remove requirement to 're-approve' Filter Failure queries that have failed the validation a 2 nd time (User currently has to contact xoserve to move the query along). Will be evaluated during modelling phase. 11 Pre-populate originator details and data fields with existing UKLink data (driven from MPR) and on query entry. Data will be specific to each query type & will be evaluated during modelling. 11 A Pre-populate data fields with existing UKLink data (driven from MPR) and on query entry. Data will be specific to each query type & will be evaluated during modelling. 11 B Pre-populate user details of query originator on query entry. To be evaluated during design. 13 Include the CRN (Contact Reference Number), MPR or a 'link' on Data Clarification (DC) requests to allow the User to directly respond to the DC rather than having to access from a different screen. Provide CC & DC notification / alert back to originator. Will be considered during screen design. May be able to provide to user email account (if provided on query submission). 14 Provide 'quick-links' / shortcuts to allow the User to navigate directly to particular screens. Improved screen navigation is likely to be a feature of 'web centre' capability. 19 Provide on-line incremental 'count' & view facility for priority queries (Top 50 list). Will be evaluated during detailed design. 20 Central user managed accounts eg. ability to reallocate accounts, unlock / reset passwords. Will be evaluated during detailed design. 21 Provide Invoice Number in query resolution text. May be possible to provide in 2 nd 'QMR' closure ? Will be evaluated during modelling. 22 Provide reason (sub category) for invalid Theft Of Gas queries in resolution response. Will be evaluated during modelling.

Confirm our understanding of your requirements…. 16 16 B 23 Provide search facility for current / historical queries using MPR. If this relates to search via MPR this is existing Con. Quest functionality & will be included in BPMS. Visibility of historical query data - Availability of data until 'line in the sand' Pending archive arrangements. Account Admin - Provision of Shipper Group accounts (single account meaning that a User can access data relating to defined all Shipper accounts within a group). Shippers need to be aware that this will provide visibility of entire organisations portfolio to all users within their group.

Con. Quest Account Housekeeping

Housekeeping Procedure § Con. Quest Housekeeping Exercise is conducted on a bi-monthly basis § A list of Con. Quest users who have not raised a query within the last six months is produced. § The list is issued to our shipper contacts, asking for it to be reviewed and then each shipper to advise of accounts that are either still required or that can be deleted. Thank you to those who have helped us with this. § This process is essential to help manage system integrity and also to ensure we have an accurate user base. § Con. Quest Housekeeping will need to continue until the Q&WFM Project implements. Your continued help and support with this initiative is appreciated.

Current User Group § Total number of active users in Con. Quest database – 4928 § This has reduced from 5370 since October § Total number of accounts not accessed system for >6 months – 4008 § This has reduced from 4434 since October § Conquest Users that only use the system to search and view queries are deemed inactive. § System activity is denoted by either logging a query or responding to an outstanding request for information/action.

Migration / Cut Over Strategy § § Parallel running – short period Visibility of old queries raised on Con. Quest for a period New queries to be raised via new Q system from day 1 Live (in flight) queries to be moved across for long standing queries e. g Filter Failures § At point of migration the query creation date will start from that day § The Open Query will have a new Contact I. D. but it will be linked to the original Contact I. D. § Closed queries will be archived

Q Project Pilot

Objectives of Pilot § Provide implementation opportunity without external Stakeholder impacts § Ensure Implementation Activities are clearly understood, and that key learning is documented for future implementations § Early demonstration of automation and capability, potential refinement of Models prior to formal (External) implementation § Reduce number of Users within Initial Training Programme – Test Packages, and ensure that these ‘Train the Trainer’ packages can be refined prior to full scale roll out § Introduce Expert Users / System Advocates to embed Training for latter Phase Users § Governance – Embed Process Modelling governance with limited processes § Visibility of Technology, preparedness for Support and check Service Management approach § … and lots more… 45

Getting BPMS bedded in § The chosen Process for the Pilot is : § Gas Safety Regulations (GSR / GSS) § GSR / GSS is the acronym given to the Network Queries which are generated when the Networks can’t seal the outlet because they have found an installed meter. § GSR & GSS contains a set of processes that touches upon all workflow capabilities of the Con. Quest system & will also demonstrate integration capabilities with peripheral source data systems.

Gas Safety (Installation & Use) Regulation It all starts when a meter is ‘removed’

What is a GSR (GSS) Obligations documented in Gas Safety (Installations & Use) Regulations 1998 ( www. opsi. gov. uk) Where a primary meter is removed and not re-installed or replaced by another meter (before the expiry of 12 months), then the person who last supplied the gas shall …… § Close any service valve § Seal the outlet

Who is involved and why § The Gas Supplier has a duty under Gas Safety (Installations & Use) Regulations 1998 to take appropriate action. § A Gas Transporter does not have a direct duty under GS(I&U)R but it does have an obligation under Regulation 14 of the Pipelines Safety Regulations 1996 to decommission a pipeline which has ceased to be used. § xoserve currently facilitates this to aid both in meeting their obligations § The process chain should be short but…. .

Start, Middle and End

The scale and effects § There around 55 k GSRs per year § Some of these will require 2 or more visits § The cost of undertaking these visits will not be insignificant § The monetary cost of erroneous visits is being determined § Costs aside, the consequences of unnecessary visits are… § § § An engineer wasted visit(s) An unhappy and surprised consumer Terminated at the mains (if repeated attempts to contact ignored) Warrants being obtained incorrectly Network Queries raised requiring investigation

Over the last 6 months… Jun-09 Jul-09 Aug-09 Sep-09 Oct-09 Nov-09 Dec-09 Total Avg. Per Month GSR Network Visits Carried Out 3, 995 3, 730 3, 987 3, 525 4, 360 4, 569 3, 466 27, 632 4, 605 Number Of Disconnections 951 3, 570 2, 765 3, 240 4, 079 1, 586 2, 963 19, 154 3, 192 % Of Disconnections (against visits) 23. 8% 95. 7% 69. 4% 91. 9% 93. 6% 34. 7% 85. 5% 69. 4% No. Of GSRs Received By xoserve 3, 044 160 1, 222 285 281 2, 983 503 8, 478 1, 413 % of GSRs Received by xoserve (against visits) 76. 2% 4. 3% 30. 6% 8. 1% 6. 4% 65. 3% 14. 5% 30. 6%

In the last 6 months…. . GSS GSR A code that distinguishes a meter point with a Shipper but without a meter attached No. of instances of a meter in situ 1380 No. of MSNs sent via RGMA 320 No. not actioned 1060 (77%) A code that distinguishes a meter point without a registered Shipper and without a meter attached. These are sent to the previous Shipper who removed the meter No. of instances of a meter found in situ 4054 No. that have since been Nominated, Confirmed & meter attached 812 No. that remain in unconfirmed (“orphan pot”) 3242 (80%)

What should happen…………… Or

When GSRs are contrary to expectation ………… Or

When GSRs are contrary to expectation ………………… Or

What the Networks say… § “Shippers are removing the meter from UK Link incorrectly. More often than not the meter is still on site or they have put through a meter removal (where it is a meter exchange) and have not put through an install or it has rejected. ” § “We have plenty of examples where the DN has visited the site to confirm that the meter allegedly removed is actually still on site. This is quite frustrating and costly to the DN. ” § “UK Link not updated in a timely manner by the Shipper i. e. Customers not happy that we contact them when they have had a meter fitted but it does not show in UK Link”

It all starts when a meter is ‘removed’ § The ‘fall out’ from the GSR routine only exists because…. a) Something happened that shouldn’t have happened b) Something should have happened that didn’t § Is there another way? a) Can these instances be eliminated? b) Does xoserve need to be involved? § The options are to be considered and re-engineered a) b) c) d) Root cause analysis of erroneous visits Automate that which is manual Shorten the chain Prevention better than cure

High level view of changes § Networks will only need to provide 5 mandatory data items § § § 1. Meter Point Reference Number (MPRN) 2. Meter Serial Number (MSN) 3. Building Number 4. Building Name 5. Post Code § Additional data will be sourced from UK-Link (where it is present) § Networks will have visibility of status of each query returned § Validation will be placed at right point and will be instant § Output from validation will be auto-routed § Register of each referred case (and status) will be visible to Shippers

Slide 60! § AOB? § Next Meeting § § § March 2010 Membership? Other Forums to take these messages to? § § Agenda Items for next meeting? Interim Updates § Frequency / Event Based?