Have you ever had an OSS or BSS project that’s impacted by poor data quality?
The problem of data integrity gets raised on almost every project we get involved with here at PAOSS, especially when passive assets such as cables, splice joints, etc are involved.
Our systems face a perennial challenge of poor data quality. As we aim to add increasing levels of automation into our network and systems, we become even more dependent on reliable data to avoid incorrect inferences and automated actions.
In an ideal world, OSS/BSS tools would operate on clean, accurate, and up-to-date datasets. Yet, real-world data is often inconsistent, outdated, or simply incorrect. This can happen due to:
OSS are great at collecting, organising and disseminating information about a telco’s networks, services, workforce and much more. However, poor data can cause it all to derail, when provisioning new services, designing network augmentation through to troubleshooting faults. It increases costs, delays processes and frustrates designers, technicians and customers.
The problem with OSS is that they’re an offline interpretation or digital twin of what’s happening in the real network environment. What the technicians or customers see in the field isn’t always aligned with what the OSS is telling the designer and other back-office workers. We talk about this in the big loop, little loop, redline markup article where back-office data fixes (inferences – or little feedback loops) aren’t as reliable as in-the-field observations and data updates (real-world or big feedback loops).
Unfortunately, big-loop data fixes often require expensive field audits and remediation. As a result, big-loop fixes typically only occur when data quality has deteriorated to the point that it’s causing significant operational inefficiency (eg repeat truck rolls). As an aside, our downloadable Data Quality Contagion Cost Calculator can help you to determine the full extent of your data integrity issues – helping you to monetise the real impact and justify the effort required to fix your data.
However, before it gets to that data quality death spiral, I’m constantly on the lookout for tools and processes that continually improve data quality rather than being a custodian over continually declining data standards.
We’ve talked previously about DOC (Data Operations Centres), a method that helps to systematically fix data “faults” in much the same way as a NOC fixes network faults. Another concept is to provide field-workers and customers with the mechanisms that allow them to quickly and easily report any data issues they see. These can include similar mechanisms for reporting network faults to a NOC (eg reporting via phone calls, emails / drop-boxes, web portals, ticketing systems or similar).
However, I wonder whether there’s something even more efficient for enabling real-time feedback. That is, for OSS to have in-built data confidence functionality where Technicians can flag anomalies, ensuring issues are logged as soon as they arise, without major delay to the technician’s main workflow / objective on site. This could be a data confidence / quality toggle that’s analogous to the dishwasher indicator in the video below (and probably also needs a dialogue box or media recording capability for the technician to share what the problem is and/or what they’ve done to work around the problem – possibly leaving further data discrepancies behind in the process).
Once the “dirty” data toggle goes up, it triggers people in the DOC to systematically analyse and fix the data point. It can also be used to identify heat-maps showing areas of low data confidence. This functionality doesn’t have to be solely available for field-facing people though. It can also be used via “little loop” or back-office resources such as data scientists that are noticing data faults when working on analysis assigments.
What do you think? What are the best systematic data improvement mechanisms you’ve seen? We’d love to hear about them in the comments below so that we can help improve data quality across the industry.
In our “chasm” series of articles, we’ve talked about the gap that exists between OSS buyers (eg carriers or network operators) and OSS sellers (eg
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
