Programmers and software developers understand the concept of “technical debt” – it is tied to the implied cost of future refactoring work to improve an existing piece of software. This technical debt could relate to the inherent design of the software, some aspects of its logic or methods, its integration and even the database that it relies upon.
Technical debt was originally coined by software developer, Ward Cunningham. Ward first used the metaphor to explain to non-technical stakeholders at WyCash (a portfolio management system), why developer resources are needed to be budgeted for refactoring work.
The exact reasons for why you may land with technical debt depends on many factors but it is often tied to simply the passage of time and expedient decisions that were taken, that on reflection now need to be undone.
Data, customer data, in particular, experiences the same challenges and changes with ‘technical debt’. Businesses that want to keep ahead of their competitors, need to continuously adapt and reevaluate the data that they hold, the way they hold it and the way they use and distribute it, sometimes the technical debt around their customer master data holds them back from being able to keep ahead of the pack.
Unfortunately, a great many systems that are already in use, constrain the flexibility that the business has around changing or adding the data on hand and as a result short-cuts and potentially bad decisions are taken about how to work around the deficiencies of the systems in use.
What constitutes customer master data debt exactly?
It is really only when you dive into the details of the data that you have, how you use I, where it is used and the effectiveness of it in getting certain jobs done, that you really draw some solid conclusions about whether or not you have a customer master data debt problem.
Customer data degrades over time, typically due to customers’ circumstances changing. they may change their name, they may move, they may get a new phone number, change their email address or start using new social media services. Unless you have a continuously managed relationship with that customer then the chances are that your systems are not current with the latest information that relates to your customers. Is this data debt? Probably….
If your systems are deficient in a particular set of customer attributes, like the ability to store their social media accounts, then what do you do? It has often been observed that with older types of systems that predate social media platforms, often the decision is taken to repurpose certain data fields to accommodate the storage of additional customer attributes that in all likelihood have no real relationship with the fields as defined in the system. When an upgrade comes along, those records risk being wiped out or ruined in some way. In some instances, a decision is taken to simply not store that data in a repository that is accessible to everyone. This type of decision becomes a data debt decision.
String data without a clear understanding of why you are storing it or without an understanding of the final purpose for that data is another example of a data debt decision. This is the kind of decision that ultimately also introduces compliance risk, and also unnecessarily clutters up your systems.
Then there are the critical bugaboos of data quality that seem to be pretty pervasive, namely the forced nullification or fake data posting for records that you have poor or missing data. Putting in Telephone Numbers like “(000) 000 0000” for example or capturing phrases like “UKNOWN” where data is missing but where the system requires some sort of entry.
You can probably think of a good many more. Pretectum’s approach to all of this is distinctive and flexible. When you define your customer master you decide which attributes you need to have and whether they are mandatory or optional. You also get to decide whether the data needs to be bound to certain kinds of data capture rules or data maintenance rigor. Data captured, is continuously assessed relative to the definitions that you have maintained.
Most decisions that you take today, can be ‘undone’ or modified and adapted as your business needs evolve thereby avoiding the situation where you make a decision and then struggle to recover from the negative consequences of that decision. All of this serves to reduce the risk of you introducing customer master data debt. In fact, if anything this enhances the likelihood of you being able to consider your customer master in the Pretectum platform as an asset.
Contact us today to learn more.