Luke sullivan


Published on

FTTH Conference EUROPE 2012 - Workshop
Munich, Germany

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Luke sullivan

  1. 1. Data requirements for efficient Service Management In day-to-day operations, what are the common events that create the biggest inefficiencies ? How can they be streamlined?1
  2. 2. About Dynamic Design The Dynamic Design Group of Companies Dynamic Design AG Dynamic Design GmbH Dynamic Design GmbH Dynamic Design Pty Ltd CH-5612 Villmergen A-4600 Wels D-01069 Dresden AUS-3004 Melbourne Switzerland Austria (HQ) Germany Australia • Founded in 1993 • 100% centred on the ConnectMaster software platform • Continous growth • International presence via local partners, including locations such as France, South Africa, Brasil and India) • 150+ customers world-wide2
  3. 3. About Dynamic Design Activities • Development and Sales of ConnectMaster, a Resource and Inventory Management tool for Network operators • Integration of Physical, Logical and Service records • Includes the FTTx Rapid Network Planner: A Planning Module to accelerate the detailed planning and design phases of FTTH deployments • Automated generation of objects and connectivity • Automated reports and schematics for construction • Implementation and Support Services – Implementation, Integration and User training • Integration of ConnectMaster with existing BSS and OSS systems3
  4. 4. What’s New for Operations? Extra complexity in Network Records: • Installation – How to record non-standard installations? • Ownership – Who owns what where infrastructure is “shared”? • Usage – Who is using the infrastructure? • Operator – What is the demarcation point for my network? • Notifications – Who to notify, and when?4
  5. 5. What’s New for Operations? Extra complexity in identifying responsibility: • Installation – Coordination with 3rd parties • Service turn-up – what to test / who to notify when a service does not turn-up? • Service Fault – Where ? Who is affected? Who should attend?5
  6. 6. Data Records MDU Example Customer 1 Customer 2 Provider 1 Street Customer 3 CAB Provider 2 BEP CAB Provider 36
  7. 7. Data Records Extra complexity in identifying responsibility: EG: Owner = P2 Operator = P1 EG: User = P2 Owner = P1 & P2 Services = Cust 2 Operator = P1 User = P1 & P2 Customer 1 Services = Multiple Customer 2 Provider 1 Street Customer 3 EG: CAB Provider 2 Owner = P1 BEP Operator = P1 CAB User = P1, P2 & P3 Provider 3 Services = Multiple7
  8. 8. Data Records Other Information to be Recorded: • Fibre allocation - identification of fibre owner, operator, user, and services • E.g. Utilisation calculations • References – How to communicate which user / fibre / cable with partners / shared users ? • Are the naming conventions aligned for all parties ? • Which references should be stored to reduce confusion ? • Test Results – Ability to reference construction test results for individual fibres. • Building specifics – Access, Contacts • Non-standard installs – descriptions, special instructions, photos8
  9. 9. Why the records are needed? When we need the information: • When a service doesn’t work on turn-up, and the fibre is in question; AND • When a fault is logged, and the fibre is suspected: • Where is the issue? - Who’s responsibility is it? • Are we sure which fibre? • Are we sure the fibre under our responsibility is intact? • Can we hand the fault back to the service provider? • With READY access to ACCURATE records, Operations teams can handle difficult faults and disputes efficiently. • BUT, if the records are difficult to locate, ambiguous, or simply incorrect, costly delays can ensue...9
  10. 10. Why the records are needed? Typical Causes of Delay : • Uncertainty over fibre status • Risk: If unable to demonstrate that the fibre path is without fault – technician to attend multiple sites to establish end-to- end test, or additional technician. Risk of impact to live services inadvertently. • Result: Additional costs in Field workforce mobilisation – potential delay in service handover or restoration. • Mitigation: Ensure any available test results are provided. Provide tools and procedures for appropriate testing on site.10
  11. 11. Why the records are needed? Typical Causes of Delay : • Incorrect records or missing references • Risk: Lost time to establish the correct equipment and service to verify. Risk of impact to live services inadvertently. • Result: Additional time and cost to establish correct data. Possible KPI breaches. • Mitigation: Ensure all relevant data / diagrams are available to the field for reference.11
  12. 12. Why the records are needed? Typical Causes of Delay : • Unknown Responsibilities • Risk: Can result in a dispute over the status– Can be a lengthy investigation before demarcation boundaries are defined and tests confirm the status to the demarcation. • Result: Can require long delays, potentially involving a number of escalations to agree appropriate steps. Potential multiple visits required, possible KPI breaches. • Mitigation: Clear records providing the responsibilities of each network item.12
  13. 13. Maintaining Records To Maintain Record Sets: • Adopt processes to improve the currency of records. • Adopt auditing processes to support the completeness of records. . • Ensure the Resource and Inventory solution is fit for purpose.13
  14. 14. Maintaining Records Currency of Records - updating records related to Network Modifications: • Currency is supported with processes that close the feedback and update loop for network changes: • during fault restorations • augmentation works • as-built mark-ups • Equips the Operations team to respond accurately even where recent changes have been made to a service14
  15. 15. Maintaining Records Completeness of Records - Auditing: • Completeness – auditing records to analyse missing or invalid stored data: • Routinely – on pre-determined fields • After a set number of augmentation works • Provides the Operations team with additional confidence to react and respond as determined by the network records15
  16. 16. Maintaining Records Resource & Inventory Tool: • When choosing the tools / techniques to store and retrieve network records, some key decision points: • All network / service inventory records stored in single tool / location • Management of fibre and duct connectivity • Caters for current data requirements, and extendible for additional data requirements as needed • Allows easy update of data • Control of user rights • Supports change management processes – identify services affected based on selected network infrastructure • Supports Reporting and Integration with existing BSS and / or OSS16
  17. 17. Maintaining Records Questions??17