Data Discrepancies Don’t Matter
Now, referring to the title, you may be thinking: That’s a rather cheeky thing to say given the high direct and indirect costs of errant data incurred by virtually all operators. You might cite the significant Opex penalty related to reworking designs and to service activation fallout. I get that. What about the millions of USD in stranded Capex most operators have in their networks? Check. My personal favorite comes from Larry English, a leading expert on information quality, who has ranked poor quality information as the second biggest threat to mankind after global warming. And here I was worried about a looming global economic collapse!
My point is actually that the discrepancies themselves have no business value. They are simply an indicator of things gone bad. The canary in the coal mine. These “things” are likely some combination of people, processes and system transactions, of course. Yet many operators make finding and reporting discrepancies the primary focus of their data quality efforts. Let’s face it, anyone with modest Excel skills can bash two data sets together with MATCH and VLOOKUP functions and bask in the glow of everything that doesn’t line up. Sound familiar?
For context, I am mostly referring to mismatches between the network and how the network is represented in back-office systems like Inventory—but the observations I will share can be applied to other domains. Data anomalies, for example, are all too common when attempting to align subscriber orders and billing records in the Revenue Assurance domain.
Too often, Data Integrity Management (DIM) programs start with gusto and end with a fizzle, placed on a shelf so that shinier (and easier!) objects can be chased. Why is this? Understanding that I am now on the spot to answer my own rhetorical question, let me give it a go.
- The scourge of false positives: There are few things as frustrating as chasing one’s tail. Yet that is the feeling when you find that a high percentage of your “discrepancies” are not material discrepancies (i.e. an object in the Network but not in Inventory) but simply mismatches in naming conventions. A DIM solution must profile and normalize the data that are compared so as not to spew out a lot of noise.
- The allure of objects in the mirror that are closer than they appear: OK, not sure this aphorism works but I trust you to hang with me. I am referring to misplaced priorities— paying attention to one (closer, easier) set of discrepancies while ignoring another set that might yield a bigger business impact once corrected. Data quality issues must be prioritized, with priorities established based upon clear and measurable KPI targets. If you wish to move the needle on service activation fallout rates, for example, you need to understand the underlying root causes and be deliberate about going after those for correction. Clearly, you should not place as much value on finding ‘stranded” common equipment cards as on recovering high-value optics that can be provisioned for new services.
- The tyranny of haphazard correction: I’m alluding here to the process and discipline of DIM. Filtered and prioritized discrepancies should be wrapped with workflow and case management in a repeatable and efficient manner. The goals are to reduce the cost and time related to correction of data quality issues. If data cleanse activities are unstructured and not monitored by rigorous reporting, the business targets for your DIM program are unlikely to be met.
- The failure to toot one’s own horn: Let’s say that your data integrity efforts have met with some success. Do you have precise measurements of that success? What is the value of recovered assets? How many hours have been saved in reduced truck rolls related to on-demand audits? Have order cycle times improved? By how much? Ideally, can you show how your DIM program has improved metrics that appear on the enterprise scorecard? It is critical that the business stakeholders and the executive team have visibility to the value returned by the DIM program. Not only does this enable continued funding but it could set the stage for “self-funding” using a portion of the cost savings.
- The bane of “one and done”: For a DIM program to succeed in the long run, I suggest drawing from forensic science and tracing bad data to underlying pathologies… i.e. people, process and/or system breakdowns. A formal data governance program that harnesses analytics to spotlight these breakdowns and foster preventive measures is highly recommended. The true power of DIM is in prevention of future data issues so that the current efforts to cleanse data will not simply be erased by the passage of time.
Identifying data discrepancies is a good first step. Correcting and preventing them is even better. Institutionalizing DIM via continuously measuring and reporting your successes… well, you get the idea.
Portfolio Head – Network Analytics
Andy has 20+ years of experience in engineering management, business operations and IT, primarily with Tier 1 operators including Level 3, MCI and GTE. His responsibilities included leading IT development teams that built mission-critical network management, provisioning and inventory systems with thousands of users. Prior to joining Subex, Andy was a Senior Manager overseeing a Data Governance organization at a major Internet Services provider. Andy graduated from the University of Pennsylvania with degrees in Electrical Engineering and Economics (Wharton). He holds an MBA from the University of Colorado.
Request a demo