1 / 57

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

‘Q’ Project “ConQuest External User Group” Meeting No. 3 12 th April 2010. AGENDA -1- . Welcome Project Q - Update Reminder of the Principles Timeline - revised Technical File Formats Application Requirements Security & Access Controls. AGENDA -2-. Operational

hosanna
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

  15. ‘Technical’ Update- User Interfaces - Screen

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

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

  18. User Interface - ScreensSample Artwork

  19. Q system HTML Prototype

  20. Login Screen

  21. xoserve home/landing page

  22. QSystem home/landing page

  23. Application level business processes

  24. Upload GSR EFT

  25. File Details Screen

  26. Show History screen

  27. EFT Reference Number Details Page

  28. File Download Screen

  29. Access Controls

  30. 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)

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

  32. Security Layer - Roles

  33. 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?

  34. Cut Over from Old to New&Data Migration

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

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

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

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

  39. Are these Invoice Codes Required?

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

  41. These all do the same thing

  42. Meter Number Creation Process(MNC)

  43. 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…..

  44. Data will be retrieved by BPMS Mandatory data

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

  46. Questions & Answers

More Related