‘Q’ Project “ConQuest External User Group” Meeting No. 3 12 th April 2010

1. ‘Q’ Project “ConQuest External User Group” Meeting No. 312th April 2010

2. AGENDA -1- • Welcome • Project Q - Update • Reminder of the Principles • Timeline - revised • Technical • File Formats • Application Requirements • Security & Access Controls

3. AGENDA -2- • Operational • Transition from Old to New • Data Migration • Specific Process Changes (proposed) • Discussion Subjects • User Acceptance Testing • Training • Questions & Answers • Communication Approach • AOB

4. Welcome & Introductions • Dave Addison Project Manager • Dave Ackers Customer Data Services Manager • Emma Lyndon Customer Data Services Officer

5. Project Q Update

6. Principles of the Project • We have immediate drivers • Provide a stable system for Query Management • Ensure Continuity of Service • There will be some change… • changes to external Users identified will be communicated • there will be consequential improvements in the way we do things • efficiencies will be identified and adopted • Primary objective • Providing a functional Query Management Service to Users

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

8. ‘Technical’ Update- User Interfaces - File

10. Electronic File Transfer (EFT) file - 1 - Currently… • The EFT File (xoserve issue) is an Excel spreadsheet • Prior to dispatch to appointed box account you are required to convert into a .QMP file (.csv format) – macro provided • We are aware that ‘clones’ of EFT files are used which are already converted to .csv format • The current version of the EFT holds 95 fields of which many fields are never used • Presently the EFT can contain a variety of Contact Codes within the same spreadsheet • The EFT is sent via email – bulk upload or as a contingency • Or can be sent as a QMP File via IX

11. Electronic File Transfer (EFT) file - 2 - Previously, we have asked… • Which format is preferred for file transfer? XML or csv? • Interface files will be csv • Q System will convert csv files to XML

12. Electronic File Transfer (EFT) file - 3 - Proposed… • Redundant fields (columns) are removed • Updated EFT xls macro sheet to generate csv • XLS sheet may require that differing formats may need to be issued within separate files • Following review of all In-Scope Processes we will know the extent of surplus fields • ‘To Be’ Process Workshops continuing into May • We will present our findings and consult at the earliest opportunity • The ability to import the EFT (.csv file) will be incorporated as part of the Q system • The user will have a choice of either bulk (circa 100-200 records) uploading via the Web or to send via the IX • Despatch of the EFT via Email will cease. • Question… • Do you presently generate a .QMP file without using the xoserve version of the EFT?

13. Electronic File Transfer (EFT) file - 4 - • Via the Web: • If uploaded via the Web (need to convert to csv) this will be limited to [~200] records • If Web uploaded then file and content is validated and result visible on screen • There will be a delay before an Error File is displayed on the Web Interface • Question… • Should a QMR / QMJ file be generated via I’X? • A consensus view required

14. Electronic File Transfer (EFT) file - 5 - • Via the IX : • Format you will need to convert to .csv • .QMP file transmitted • Return QMJ,QMR Response Files • Via Screen: • Entry via screen - Validated at point of committing and Error messages displayed instantly

17. Loading of Contacts – i/o – In Summary

18. ‘Technical’ Update- User Interfaces - Screen

19. User Interfaces - Screen Previously, we have asked… • What Browser can we benchmark to? • Responses all indicated IE6 and above • Note: Tools used assume IE7 or above – tests have indicated no major functionality issues • Users receive warning • No major functionality compromises identified currently • We will benchmark at IE6, and equivalent • i.e. Fire Fox v3.x; Safari v4.x • Security Packages used assume IE7 or above, test have indicated issues at IE6

20. Previously, we have asked… • Can we use Cookies? • Responses accepted use of Cookies – Thank You • Use of Remote Location for Homeworkers / Other Sites • Responses – mixed views • Allow not to restrict to certified sites

21. User Interface - ScreensSample Artwork

22. Q system HTML Prototype

23. Login Screen

24. xoserve home/landing page

25. QSystem home/landing page

26. Application level business processes

27. Upload GSR EFT

28. File Details Screen

29. Show History screen

30. EFT Reference Number Details Page

31. File Download Screen

32. Access Controls

33. Access Controls • Need to prepare the construction of the security regime – part of Oracle Identity Manager (OIM) • The Security Layer requires • Name of User • User I.D. • Email Address • Operational Role • Work Type Group(s) • Organisation – Group or Sub Division • We only know existing ConQuest Account holder names and User I.D. No. • We will issue these lists to you (or named point of contact)

34. Homework • The following needs to happen…. • Validate list to ensure named User is indeed the account holder • Populate the issued spreadsheet with missing details i.e. email address, work type group, role(s), membership of group or sub division • Add full set of details for those not listed if they require a Q system account • Annotate list if named person no longer requires an account • You have until August 2010 (Date TBC – circa UAT-4 weeks) • We will need to maintain list up to point of Go Live • Where do passwords go to prior to launch?? • LSOs • Users direct (we will have their passwords) – NB: This might be sometime prior to implementation

35. Security Layer - Roles

36. Q Accounts • It would be useful to know how many Q system accounts you require? • Propose to apply a cap by Organisation • Options for limit setting – Views? • Fixed • Pro-rated – What variable? • What happens when you reach the limit?

37. Cut Over from Old to New&Data Migration

38. Cut Over – ConQuest to ‘Q System’ • The current Contact Reference Number (CRN) is a 7 digit sequential serial number – currently starting 266nnnn • In the new Q system the CRN serial number will commence from 20,000,000 • A ‘live’ Contact which migrates from ConQuest to the Q system will inherit a new CRN but be cross referenced to it’s original CRN. • ConQuest Users will be pointed to new Q system from the Monday we go live…Users will have to do some registration • ConQuest will still be there for a short while for viewing only

39. Data Migration • Closed queries (circa 2m) will be migrated from ConQuest to the new system and placed into an Archive area • Context of these queries – query outline, query resolution, query status, will be retained • Closed query data will move across at point when new Q system is enabled • Queries resolved during the period of parallel running [30 days] will migrate at the end of each day into the Archive area • After the [30th day] of parallel running the auto migration will cease and remaining unactioned Contacts will be manually moved to Q system • The transposition of open queries from current format into new format is under consideration

40. Pre-Archived Records • The viewing of a Contact record is via a screen that requires you to input either :- • The CRN • The MPRN • The Post Code Note : within 18 months since contact closure date • If CRN known and used as search key then it will retrieve record. • If Post Code or MPRN used as the search key this will retrieve record(s) that could be of the old CRN series and/or new CRN series • Contact records move into Archive on the 18th/19th month post completion (closure) of the Contact.

41. Archived Records • Closed Contacts will be archived at the end of each month • If a Query resolution does not have a financial adjustment impact then the record will be deleted after [5 years] • If a Query resolution results in a financial adjustment this will be retained for [6 years] • Any Contact records older than 18 months can be retrieved from Archives by raising a Data Retrieval Request (SLA – within 2 days) • Will only see records relevant to your portfolio at the time the Query was received / resolved

42. Are these Invoice Codes Required?

43. Ten Generic Invoice Codes….. Can they become One ? Do you want …. • ADJ – a current Invoicing code Or • INV – to denote an Invoicing Query UQS ADJ RBD CSE RAC MRQ ECB NTE RAT ITR

44. These all do the same thing

46. Meter Number Creation Process(MNC)

47. MNC • We have captured the ‘AS IS’ Process as a process flow diagram • We have conducted a ‘TO BE’ Process Review to plot the stages of the process from the point of entry to point of resolution • This flow is based on the ideal and is subject to proposed changes in the current routine being agreed and adopted. • The logic and validation along the process chain has dependencies on changes at the start of the process. • In this respect it may require you to stop doing something that you are doing now, modify the way that you do things or start doing something. • The following illustrates the point…..

48. Data will be retrieved by BPMS Mandatory data

49. Summary Of Points • We propose …… • deleting 14 redundant Invoicing Contact Codes • converting 10 similar Invoicing codes into 1 • moving 4 Invoicing Contact Codes into the Generic Operational Code set • blending 4 generic Operational Codes – FLE, CNQ, NOM & PAM to become FLE • introducing changes to the MNC process – reduce the number of mandatory data items and introduce 2 other mandatory information requirements

50. Questions & Answers