1 / 34

User Pays User Group Monday 2 nd June 2008

User Pays User Group Monday 2 nd June 2008. Today’s Agenda. Introduction (HB) Review of minutes & actions (TD) Contractual Change IAD performance standards proposals (AM) Proposal for contract change (RM, CB, all) Next steps (GF) Terms of Reference

Télécharger la présentation

User Pays User Group Monday 2 nd June 2008

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. User Pays User Group Monday 2nd June 2008

  2. Today’s Agenda • Introduction (HB) • Review of minutes & actions (TD) • Contractual Change • IAD performance standards proposals (AM) • Proposal for contract change (RM, CB, all) • Next steps (GF) • Terms of Reference • Feedback on draft ToR (GF, all) • Next steps (GF, all) • Updates from xoserve • Operational update (DA) • IAD update (DA) • Proposed Process for Managing User Pays Systems and Service Enhancements (GF, all) • High level timeline (HB) • AOB (all) • Close (HB)

  3. Contractual Change

  4. IAD performance standard proposals • Background • Core Hours • Availability • Data re-fresh

  5. xoserve proposal • Background: feedback from users that xoserve need to provide increased commitment for Core Hours and data re-fresh frequency • Currently: • Operational hours defined as 06:00 – 22:00 Monday to Saturday excluding bank and public holidays • Core Hours (against which performance will be measured for liabilities) are 09:00 – 17:00 each Business Day • Performance standard of 95% availability during Core Hours • Operationally data re-fresh is daily • Core measure (against which performance is measured) data re-fresh must not be later than 4 Business Days

  6. xoserve proposal - IAD Core Hours • Aim: to provide increased service provision with little or no impact to price • Core Hours proposed as: • 08:00 to 20:00 Monday to Friday (Business Days) • 08:00 to 12:00 Saturday (excluding Christmas or New Year where these fall on a Saturday) • IAD operational hours are still 06:00 to 22:00 Monday to Saturday (excluding bank and public holidays)

  7. Existing Arrangements - IAD availability • The performance standard for availability is currently 95% of Core Hours • Below this performance, for Unplanned Downtime reductions in charges are currently made as follows: Unplanned downtime Reduction applied to monthly charge 5% or less 0% 5.01 – 10% (8hrs*) 20% 10.01 – 15% (16hrs*) 35% 15.01 – 20% (24hrs*) 50% 20.01 – 30% (32hrs*) 60% 30.01 – 50% (48hrs*) 70% More than 50% (80*) 90% *hrs based upon a 160 hour month (4 weeks, 20 business days)

  8. xoserve proposal - IAD availability • The performance standard for availability will be increased to 97% against the proposed Core Hours • Below this performance, for Unplanned Downtime, reductions in charges will be made as follows: Unplanned downtime Reduction applied to monthly charge 3% or less 0% 3.01 - 5% (7.68hrs*) 5% 5.01 – 10% (12.80hrs*) 15% 10.01 – 15% (25.60hrs*) 25% 15.01 – 20% (38.40hrs*) 40% 20.01 – 30% (51.20hrs*) 50% 30.01 – 50% (76.80hrs*) 60% More than 50% (128hrs*) 80% *based upon a 256hr month (4 weeks, 4 Saturdays)

  9. xoserve proposal – IAD availability In the event the IAD availability performance measure is satisfied in a calendar month, but:

  10. xoserve proposal - IAD re-fresh • Performance measure to ensure the data on the IAD system is updated within 2 Business Days following date of receipt and acceptance by xoserve of such criteria • Improvement against present standard (4 days) • Where not met, charges reduced by 50% of the relevant Daily Failure Charge Rate – same as present arrangements • Operationally, data re-fresh is daily

  11. xoserve proposal - summary • Extending Core Hours, Availability and Data re-fresh meets customers requirements as stated at the April meeting • Extending Core Hours, Availability and Data re-fresh standards increases xoserve’s costs and risk exposure • xoserve consider that the extension to Core Hours, Availability and Data re-fresh can be accommodated by reducing the liability risk exposure rather than by increasing the charges

  12. xoserve proposal - summary • Views? • Possible next steps: • Transporter to incorporate within SPAA change • Performance standards incorporated within Schedule 4

  13. Contractual change • Proposal submitted by Rosie McGlynn and Colette Baldwin

  14. Terms of Reference

  15. xoserve update

  16. Operational Update

  17. Current demand for Non-Code services Value of non-Code sales for April £236,000 against forecast of £274,000

  18. April’s Non-Code Service KPIs Non-Code services Invoice issued on 20th May Payment due date is 17th June

  19. Interruptions to Non-Code Services during May • Tuesday 6th May • Telephone Service unavailable for eight hours due to suspected server problem • Sunday 11th May • IAD unavailable on 11th May due to server failure as a result of air conditioning problems in data centre. IAD data re-fresh was three days late for Monday 12th May, fully recovered on Tuesday 13th May • Wednesday 14th May • xoserve call centre employees could not access Sites and Meters so were unable to deal with calls and thus provide the Telephone Service and E Mail reporting services. Six hour outage to Telephone Service Note: calls made during Telephone Service outage periods do not count towards usage

  20. IAD Update

  21. IAD users

  22. IAD Enhancements

  23. IAD Enhancements • Enhancements to improve the IAD service were identified in mid 2006 • Requirements captured and design solutions developed pre User Pays • Implementation had to be scheduled around a number of other key systems changes, hence now planned for 2008 deployment • As a result, changes proposed for implementation during transition of User Pays arrangements • Combination of feedback from users and the results of testing have identified the need for further review prior to implementation • What were the objectives? • How were these to be satisfied? • Issues and implications?

  24. IAD Enhancements • Objective • Improved service for IAD password re-sets • How delivered • user driven password re-set functionality • Two options: • Users set security information (series of questions) • Auto email response “ping-back” service • Issues: • Questions – nature, number and security of data • Auto email – slower delivery of service • Frequency of system initiated password re-set

  25. IAD Enhancements • Objective • IAD system performance stability • How delivered • ability to monitor activity at transactional level • Implications • none on users • Code to be deployed, but later than scheduled

  26. IAD Enhancements • Objective • Improved IAD security • How delivered • Single user log-on functionality • Issues and implications: • Consider implications of local (to user) network failure • Web browser discrepancies • Change still under review

  27. IAD Enhancements • Summary: • Outage on 21/22 June cancelled • Transaction monitoring to be implemented • Password re-set functionality – need to agree preferred solution and implement • Timescales for implementation to be advised. • Note: • DN interruption functionality was implemented during the outage on 17th/18th May • Single/ Concurrent User was deferred • Outage planned for 1st June to rectify minor issues with data search and display functionality

  28. Proposed Process for Managing User Pays Systems and Service Enhancements

  29. Proposed User Pays User Group role in change to service provision Note: Contract change process not yet included here as under separate development

  30. Proposed system/service enhancement to UPUG Project set up to deliver. Will keep UPUG informed Inform other industry forums if required Commitment to proceed UPUG discussion Feasibility study Proposed Process for non-code services Process excludes Mods and Regulatory driven change However, xoserve will make UPUG aware of any impacts to services due to Mods or Regulatory change

  31. User Pays User Group role in change • UP system change • Full discussion with UPUG from initial idea to any implementation. Change can be proposed by any party • ACS modification • Sharing of information at earliest opportunity • Legislative and regulatory change • Sharing of information at earliest opportunity. Nature of change depends upon scope for consultation / notification • UNC modifications • Kept under review for any implications on User Pays services (code or non-code)

  32. Time Line

  33. High Level Time Line Activity May June July Aug Sept Governance: Develop revised Ts and Cs Establish TOR for UPUG Review forecast under/over recovery/ACS implications Operational: Invoices issued 20th Invoice payment 17th IAD transactional monitoring Lessons Learned User Pays User Group mtgs 2nd tbc tbc tbc 7

  34. AOB

More Related