Data death spiral

Feedback is the breakfast of champions.”
Ken Blanchard
.

Data synchronisation comes at an OSS from so many different angles. If any of them get out of control it can quickly send your OSS into a death spiral. By that, I mean that an OSS is only as good as the data it stores. If the data gets out of synch with reality, momentum builds and it tends to degrade further and further until the product no longer holds relevance to operators.

Conversely, an OSS provides the opportunity to clean up poor quality data is clever positive feedback loops are built into the process. The best way to explain this is by example.

The most common source of invalid data in an OSS is in the outside plant network (ie cables and patching) because it has no programmatic interface to reconcile against. It relies on cabling records being documented and maintained well. Early in my career I was project managing a team that was doing an optical fibre cutover for a tier-1 Telco. We were given a design that indicated we were to terminate our service on fibres 5 and 6. Using a fibre identifier we determined that 5/6 already had traffic on them. A quick call to the Telco’s design team identified a solution of using fibres 7/8 instead. The fibre identifier showed they were also in use. 9/10 showed the same, as did 11/12. The Telco’s suggestion was to just cut fibres 5/6 because their records showed that they weren’t in use. I asked them to fax me that in writing (yes, it was the days before scanners were commonplace). Naturally they weren’t willing to take that risk and we didn’t hear from them again.

Anyway, upshot was that the Telco’s OSS showed that fibres 5-12 were all unused but testing in the field proved otherwise. The real problem was that the Telco’s field operation processes did not have suitable feedback mechanisms to rectify the records when these defects were identified so they would’ve propagated to through to the next time a crew was asked to patch a new service on fibres 5/6.

There are modern tools that allow field technicians to view records from hand-held devices and provide red-line mark-ups that go back to head-office to rectify immediately. Each field visit means another data sample and another opportunity to provide positive feedback to improve (or confirm) the accuracy of those records, ensuring the inventory data matches the field topologies.

Even without such tools, it’s imperative that the field work force that identifies the problem is then tasked with ensuring the problem is resolved. Otherwise a series of unsuccessful truck-rolls ensues, costing the Telco each time. The down time is actually a cost saving in the long run.

Tomorrow’s blog will provide some additional data synch considerations.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.