Fault Prioritisation

1. Fault Prioritisation Telecom Wholesale Industry Consultation Seminar Telecom, Auckland30th October 2007

2. Agenda • Welcome and Introduction • The Overview: • Proposed Fault Framework – Gary Jamieson • The Detailed Bit: • Walkthrough how it works in practice – Derek Twort • Questions & Answers

3. The Overview: Proposed Fault Framework Gary Jamieson Operational Capability Telecom Wholesale

4. Why we are here • In the UCLL/Colo Standard Terms conference it was agreed that the most important aspects of faults were • Equivalence • Transparency and • Information to enable updates to end customers • Telecom proposed that this outcome could be reached with some minor modifications to the way faults are done today • The following information will describe how Telecom will achieve this

5. Allowing the Faults proposal to work • The proposal is based on Telecom’s current practices and existing systems. • Telecom performs the fault tasks across all Access Seekers and Telecom business units in the same manner. • Telecom to manage the process, setting the priority and restore times as Telecom will have the widest view of the fault situation. • The proposal will use a defined list of priorities as the basis to determine the priority assigned to each fault. • The priority will determine the overall focus given to resolving the fault. Restoration time will be determined by the circumstances of each individual fault.

6. A run through of the Fault process A UCLL MPF example • Access Seeker performs initial diagnosis to filter out problems such as: • Access Seeker or End User Equipment • User error • Existing network events • The Access Seeker refers fault to Telecom, service level clock starts for returning priority and fault restoration time • Telecom assigns the fault to service company and next available technician based on initial assessment from the information provided by the Access Seeker • Technician commences fault identification activities. These activities include: • travel to exchange to commence field diagnosis, checking MDF jumper and placing a short circuit on the HDP to enable testing. • travel to cabinet, check jumper and continuity tests to exchange • travel to end user location, checks terminal connection, isolates customer wiring and tests continuity to exchange. • Restore timeand priority identified and information returned to the Access Seeker, service level clock starts for restore time. • After service has been restored, service level clock stops • Repair action carried out on any defect found. • If cable fault found temporary service provided where possible by transposal to spare pair. Fault referred to cable faults for permanent underground fix. • Technician advises Service Given, but fault not closed • NB. Telecom does not have centralised diagnosis or line test capability on an unbundled circuit so every fault activity requires a truck roll and manual test procedures in the field.

7. The detailed bit:Walkthrough how it works in practice Derek Twort Field Services Telecom Wholesale

8. What this section will cover • What the priorities are • How the priorities are determined • How the restoration times are determined • Can they change? • Detailed processes • How we know it is working

9. What the priorities are

10. How the priorities are determined • The initial priority assessment is based on: • Information provided by the Access Seeker about the fault. • Reviewing any known existing events • Initial fault information returned from the group performing the initial fault diagnosis • It is carried out by the Fault restoration group that is the interface with all Access Seekers

11. How the restoration times are determined • The initial restoration time is based primarily on the fault information returned from the group performing the initial fault diagnosis • Other factors known about the fault situation: • Information provided by the Access Seeker about the fault. • Any known existing events may also influence the advised restoration time • The overall assessment required to determine the restoration time is carried out by the Fault restoration group that is the interface with all Access Seekers

12. Can they change? • Yes the initially advised priority and restoration time can change • Changes are based on additional information relating to the fault being discovered during the restoration work.

13. End User Customer reported problems P1 Alarm generated problems Decision P2 P3 WMS OUT Assure Prioritisation Process • Some WMS faults will be P3 • Maintenance • Lighting etc Most alarm generated faults will be P1 Some faults will begin as P2 but escalate to P1 as information emerges Majority of faults will be P2

14. End User Customer reported problems Vantive OUT OFM End User Customer Reported Faults • Majority initially prioritised as P2 • Work category “Work Division” is automatically determined based on the field skill required. • Commitment automatically determined by selecting earliest appointment from a schedule matching the Work Division attributes. Later appointments can be selected to meet end user preference. • Wholesale & Retail customer commitments drawn from the same schedule.

15. End User Customer reported problems End User Customer reported problems End User Customer reported problems Decision Vantive Vantive Vantive OUT OUT OUT OFM OFM OFM Escalated End User Customer Reported Faults • Priority assessment decision point reached: • Multiple end user problems identified • Report from Field • Alarm & Customer reported problems • Community isolated • Risk to Health & Safety • Risk to sites or equipment • “Fault Related Event” (FRE) ticket created • Detailed investigation initiated to scope event size • Escalation to P1 • Additional resources engaged

16. WMS Vantive OFM Alarm generated problems Alarm Generated Events • Most problems automatically generated into WMS • Priority determined by automated algorithm – “Alarm PrePlan” • Most service affecting faults will be P1 • Access Seeker reported faults relating to Co-Location will be created in OFM and may be classified as P1, 2 or 3

17. Typical Prioritisation Scenarios

18. Detailed Assure Process

19. Detailed Assure Process – NOC & CoLo Faults

20. How we know it is working • Service Level default reporting • Independant Oversight Group (IOG) reporting