Data quality is the bane of many a telco. If the data quality is rubbish then the OSS tools effectively become rubbish too.
Feedback loops are one of the most underutilised tools in a data fix arsenal. However, few people realise that there are two levels of feedback loops. There’s what I refer to as big circle and little circle feedback loops.
The little circle is using feedback in data alone, using data to compare and reconcile other data. That can produce good results, but it’s only part of the story. Many data challenges extend further than that if you’re seeking a resolution. Most operators focus on this small loop, but this approach maxes out at well below 100% data accuracy.
The big circle is designing feedback loops that incorporate data quality into end-to-end processes, which includes the field-work part of the process. Whilst this approach may also never deliver data perfection, it’s much more likely to than the small loop approach.
Redline markups have been the traditional mechanism to get feedback from the field back into improving OSS data. For example, if designers issue a design pack out to field techs that prove to be incorrect, then techs return the design with redline markups to show what they’ve implemented in the field instead.
With mobile technology and the right software tools, field workers could directly update data. Unfortunately this model doesn’t seem to fit into practices that have been around for decades.
There remain great opportunities to improve the efficiency of big circle feedback loops. They probably need a new way of thinking, but still need to fit into the existing context of field worker activities.
The challenge with the big circle approach is that it tends to be more costly. It’s much cheaper to write data-fix algorithms than send workers into the field to resolve data issues.
There are a few techniques that could leverage existing field-worker movements rather than being sent to specifically resolve data issues:
- Have “while you’re there” functionality, that allows a field worker to perform data-fix (or other) related jobs while they’re at a location with known problems
- In some cases, field worker schedules don’t allow enough time to fix a problem that they find (or flagged “while you’re there). So instead, they can be incentivised to capture information about the problem (eg data fix) for future rectification
- Have hot-spot analysis tools. These hot spot analysis tools target the areas in the network where field-worker intervention is most likely to improve data quality (ie the areas where data is most problematic).