Query and Workflow Management Query and Workflow Management Project Project

“ConQuest External User Group” “ConQuest External User Group”

1414thth January 2010 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

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

Welcome & Introductions

Q Project BackgroundQ Project Background

Why required and chosen technologyWhy 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 ConQuest 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 ConQuest processes

Terms of Engagement

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 eNews Interim Updates

Meetings Venue / Frequency Updates to other Established Forum?

Terms of Engagement

UKLink Engagement – 4 months Operational Changes 6 months System Changes

Business Forum

Discussion

Business Change

Identified

Business Analysis

Business Forum Agree

Reps Received & Considered

UKLink Forum

Discuss

Amend Proposal

UKLink Forum Agree

Implement

No Surprises

Terms of Engagement – Strawman

ConQuest Approach – System Changes – File Formats

Business Forum

Discussion

Business Change

Identified

Business Analysis

Business Forum Agree

Reps Received & Considered

UKLink Forum

Discuss

Amend Proposal

UKLink Forum Agree

Implement

Technical User Input

Pre Agreed – Operational Contacts have Agreed

Terms of Engagement - Strawman

ConQuest Approach – Operational Changes - Screens

Business Forum

Discussion

Business Change

Identified

Business Analysis

Business Forum Agree

Reps Received & Considered

UKLink Forum

Discuss

Amend Proposal

UKLink Forum Agree

Implement

Technical User Input

Project ApproachProject Approach

How are we going to do this…?How are we going to do this…?

Project Principles

The principles being applied are that…

we will seek to minimise change to external Userschanges identified will be communicated

there will be consequential improvements in the way we do things

efficiencies will be identified and adopted

we will ensure that changes are documented, and communicated as we identify them

Indicative Project Timeline

Activities to date

Project – Delivery Stage Start – Oct’09

2 Phases: - Phase 1 – ConQuest Processes Phase 2 – Other xoserve processes with workflow characteristics that

integrate with other parties

Each phase runs concurrently

Indicative Milestone Dates

Project Start (Oct’09)

Modelling & Design (Oct’09 – Apr’10)

Phase 1 Dev’t (Apr’10- Aug’10)

Shipper Testing (Aug’10)

Oct’09

Ph 1 Implementation (Sep’10)

Phase 2 Dev’t (Sep’10 – Jan’11)

Ph 2 Implementation (Jan’11)

Project Completion (Mar’11)

Mar’11

Pilot (Apr’10)

Impacts & BenefitsImpacts & Benefits

What we told you last timeWhat we told you last time

Impacts - Interface

Web User Interface The IP Address WILL change

Planned to replicate ConQuest 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 5th 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

1Screen 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.

3&4 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. MOD565 / 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.

27Improve screen search facility to allow subsequent searches eg. include 'new search' button.

Will be evaluated during detailed screen design.

User Interfaces

User Interfaces Comments within the User requirements regarding:

Do NOT retain ConQuest ‘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’ WebPortal 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 ConQuest 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 ConQuest

User Interfaces

WebPortal 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

WebPortal 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 mod565 codes

ConQuest 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 ConQuest 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

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

ConQuest 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 ToG 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

User (LSO) Requestor

Approver

Shipper / Network

xoserve

New Account Request

Formal Request

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 IE7+ & 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 FeaturesFunctional Features

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

What we can do….

1Screen 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.

3&4 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. MOD565 / 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.

27Improve screen search facility to allow subsequent searches eg. include 'new search' button.

Will be evaluated during detailed screen design.

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.

10Address 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.

12 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.

16AProvide 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.

17Provide data amendment history, including prior to ownership of site? Unable to provide due to restrictions around data

protection / ownership.

18 Provide 'real time' reporting. There are no plans to provide real time reporting. Performance reports are sent Monthly by the Customer Team.

20A Provide facility for Shipper LSO to generate inactive user reports. There are no plans to provide Shippers with report capability.

26It 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.…

6Ability to approve linked (same MPR) Filter Failure queries collectively rather than individually as now

Will be evaluated during modelling phase.

7Remove requirement to 're-approve' Filter Failure queries that have failed the validation a 2nd time (User currently has to contact xoserve to move the query along).

Will be evaluated during modelling phase.

11Pre-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.

11APre-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.

11B Pre-populate user details of query originator on query entry. To be evaluated during design.

13Include 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).

14Provide '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.

20Central 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 2nd '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 Provide search facility for current / historical queries using MPR. If this relates to search via MPR this is existing ConQuest functionality & will be included in BPMS.

16B Visibility of historical query data - Availability of data until 'line in the sand' Pending archive arrangements.

23Account 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.

ConQuest AccountConQuest Account

HousekeepingHousekeeping

Housekeeping Procedure

ConQuest Housekeeping Exercise is conducted on a bi-monthly basis

A list of ConQuest 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.

ConQuest 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 ConQuest 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 ConQuest 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 PilotQ Project Pilot

45

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…

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 ConQuest system & will also demonstrate integration capabilities with peripheral source data systems.

It all starts when a meter is ‘removed’It all starts when a meter is ‘removed’

Gas Safety Gas Safety (Installation & Use) (Installation & Use) Regulation Regulation Gas Safety Gas Safety (Installation & Use) (Installation & Use) Regulation Regulation

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

GSR Processxo

serv

e G

SS

T

eam

Sh

ipp

erxo

serv

e G

SR

T

eam

xose

rve

Ap

ps S

uppo

rtN

etw

ork

Request GSR extract from

DN LinkFor meters removed 8months ago

*GSR report generated

Send report to Network

GSR report received

GSR visit carried out (within M+12

of meter removal)

Notify xoserve of outcome

Confirmed site?

Close on ConQuest

Y-GSS

Receive notification

N-GSR Validate data

End

NOTE:-*Filters applied to the date range i) Meter Removal Effective Date is within date range ii) Input date is within date range iii) Effective Date < start date & Input date > end date

RGMA meter removal

notitfication

System checks carried out

End user process

Close on ConQuest

The scale and effects

There are around 55k 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…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% 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% 30.6%

In the last 6 months…..

GSS 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%)

GSR 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……………

Meter physically removed

RGMA flow updates UKLink

Network request

GSR report

Network terminate service

Meter removed

RGMA flow sent for removal

Meter Installed

RGMA flow sent for

installation

GSR visit no longer triggered

Or

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

Physical Meter

Exchange

RGMA flow sent for removal, but not for

install (or flow rejected & not re-submitted)

Network request

GSR report

Networklocate meter

on site

Network notify

xoserve

Meter physically removed

RGMA flow sent for removal

Meter installed

New service requested/

laid

Network request

GSR report

Networklocate meter

on site

Network notify

xoserve

RGMA flow not submitted for install (or flow rejected & not re-

submitted)

Or

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

MAM / MRA / End Consumer notify of removed meter

RGMA flow sent for removal

Network request

GSR report

Networklocate meter

on site

Network notify

xoserve

End Consumer changes supplier

Withdrawing Shipper sends RGMA flow for

removal

Network request

GSR report

Networklocate meter

on site

Network notify

xoserve

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-engineereda) Root cause analysis of erroneous visits

b) Automate that which is manual

c) Shorten the chain

d) 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?