Query and Workflow Management Project “ConQuest External User Group” 14 th January 2010
description
Transcript of Query and Workflow Management Project “ConQuest External User Group” 14 th January 2010
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?