Luke sullivan
17
Data requirements for efficient Service Management 1 In day-to-day operations, what are the common events that create the biggest inefficiencies ? How can they be streamlined?
-
Upload
ceobroadband -
Category
Technology
-
view
590 -
download
0
Transcript of Luke sullivan
Data requirements for efficient
Service Management
1
Service Management
In day-to-day operations, what are the common events that create the biggest
inefficiencies ?
How can they be streamlined?
About Dynamic Design
• Founded in 1993
• 100% centred on the ConnectMaster
The Dynamic Design Group of Companies
Dynamic Design AG
CH-5612 Villmergen
Switzerland
Dynamic Design GmbH
A-4600 Wels
Austria (HQ)
Dynamic Design GmbH
D-01069 Dresden
Germany
Dynamic Design Pty Ltd
AUS-3004 Melbourne
Australia
2
• 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-wide
About Dynamic Design
• 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
Activities
3
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 systems
What’s New for Operations?
• Installation – How to record non-standard installations?
• Ownership – Who owns what where infrastructure is “shared”?
Extra complexity in Network Records:
4
infrastructure is “shared”?
• Usage – Who is using the infrastructure?
• Operator – What is the demarcation point for my network?
• Notifications – Who to notify, and when?
What’s New for Operations?
• 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?
Extra complexity in identifying responsibility:
5
• Service Fault – Where ? Who is affected? Who should attend?
Data Records
MDU Example
Customer 1
6
BEP
CAB
Customer 2
Customer 3Street
CAB
Provider 3
Provider 1
Provider 2
Data Records
Extra complexity in identifying responsibility:
Customer 1
EG:
Owner = P1 & P2
Operator = P1
User = P1 & P2
Services = Multiple
EG:
Owner = P2
Operator = P1
User = P2
Services = Cust 2
7
BEP
CAB
Customer 2
Customer 3Street
CAB
Provider 3
Provider 1
Provider 2EG:
Owner = P1
Operator = P1
User = P1, P2 & P3
Services = Multiple
Data Records
• 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 ?
Other Information to be Recorded:
8
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, photos
Why the records are needed?
• 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?
When we need the information:
9
• 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...
Why the records are needed?
• 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
Typical Causes of Delay :
10
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.
Why the records are needed?
• 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.
Typical Causes of Delay :
11
• 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.
Why the records are needed?
• 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.
Typical Causes of Delay :
12
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.
Maintaining Records
• Adopt processes to improve the currency of records.
• Adopt auditing processes to support the completeness of records.
To Maintain Record Sets:
13
.
• Ensure the Resource and Inventory solution is fit for purpose.
Maintaining Records
• Currency is supported with processes that close the feedback and update loop for network changes:
• during fault restorations
• augmentation works
Currency of Records - updating records related to Network Modifications:
14
• augmentation works
• as-built mark-ups
• Equips the Operations team to respond accurately even where recent changes have been made to a service
Maintaining Records
• Completeness – auditing records to analyse missing or invalid stored data:
• Routinely – on pre-determined fields
• After a set number of augmentation works
Completeness of Records - Auditing:
15
• After a set number of augmentation works
• Provides the Operations team with additional confidence to react and respond as determined by the network records
Maintaining Records
• 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
Resource & Inventory Tool:
16
• 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 OSS
Maintaining Records
Questions??
17
