Should getting a master list of customers still be this hard?
Why is it that with the things that seem impossible we somehow manage to buckle up, tackle and conquer the seemingly insurmountable, but when it comes to the seemingly simple - but annoying - things, we tend to just suck it up, tolerate the time-consuming methods, and find a way to get by.
An example of something seemingly simple but annoying that we’ve learn to tolerate is how hard it is to get something as basic, yet and fundamental as a master list of customers. When you think about all the money that has been spent on enterprise applications and the associated consultancy fees, it’s beyond comprehension that people are still having to wrangle data in Excel to get a clean, consolidated Master Customer List.
Maybe the problem is not big enough.
Digging a little deeper, could it be that getting a clean, consolidated Master Customer List is not a big enough problem for the business, so we have resorted to living with the problem rather than solving it once and for all?
As someone who has worked around enterprise applications and close to the office of Finance for all my career, it’s hard for me to believe that any business can operate properly without a Master Customer List, let alone one for its products, suppliers, and employees.
Another theory for why has not been tackled could be that for many companies it’s considered collateral damage or a necessary evil to just ‘put up with’ -- or put a different way, it’s become a ‘tax’ on the business as companies moved away from running their entire business on a single, integrated ERP system to a best of breed approach with a collection of disconnected standalone cloud-based systems.
It’s not just the challenge of getting a Master Customer List that has been impacted by this change, an entire layer of Master Data has evaporated because of this change in systems strategy.
While ERP systems still play a vital role in running the business, more and more critical business data now lives in standalone Customer Relationship Management (CRM), Service Management (SM), Workforce Management (WFM), and Supply Chain Management (SCM) applications.
No more referential integrity.
With data now being originated in each of these standalone systems in isolation, no one system is responsible for defining the data model or ensuring data governance across all systems and providing the Master Data Management that a single integrated ERP system used to provide.
When all your data lived in one system, this system ensured consistency of data across the CRM, SM, WFM and SCM modules. When these modules became standalone systems from multiple vendors the referential integrity of the data they created was lost forever.
To highlight how such a simple change is systems strategy has created such a big problem for certain parts of the business, let’s just focus in on the world of customers for a moment. When all your business data lived in a single ERP system, the customer record was defined once, centrally, and was used in whatever modules necessary. We now have a situation where a customer record is created in several different systems independent of each other.
To further illustrate this point, let’s follow the journey of winning, billing, and servicing a new customer in a business. The CRM system is the first place a new record is created, normally by the salesperson. It’s usually given a loosely defined customer name because it’s either too early to understand the exact legal name of the contracting entity or how it needs to be slightly from other, related companies of a similar name.
When the contract is won, a sales opportunity is closed in the CRM system and the accounting team sets up a customer record in the Finance module of the ERP system. This customer name will need to match the legal name and the contracting name to ensure there are no delays in getting paid. The customer's name in the Finance system will be different to what was originally set up in the CRM system - creating the first of many mismatches.
The next team up is the Customer Service team who immediately has a choice to make as to what customer name they use in their service management system. Not only do they need to think about the name relative to what’s already in the other systems, they also might need to factor-in other considerations like servicing multiple sites or subsidiaries with the same name within the customer’s organization when setting up the customer record.
A sense of the size of the problem.
Granted, this an extremely basic example but when you think about the number of systems that now hold customer data and you multiply that by the customers you have, you start to get a sense of the size of the problem for the distinct functions within a business. While I am in the mood of holding my hands up, I also accept that companies can put manual best practices in place to tackle the problem I look to highlight in my simple example.
Some of these best practices might work and some might fail, but this example illustrates why master data management was not an issue when all your business data lived in one system. This built-in ability evaporated when the decision was made to move to a collection of standalone systems. Now we have a major issue and something other than people doing the right thing and handling this clean-up manually needs to fill this void.
Depending on people to ‘do the right thing’ and rather than a process to do it – onus is on the person to set the name correctly, high risk of this not working naming convention and process to follow
Another theory as to why this problem still exists is that there is a workaround that means it never makes it onto the list of “showstopper” problems. This workaround involves people working long hours, lots of perspiration, and some Excel wizardry to keep the business wheels turning. All of this happens below the radar of senior management and is considered as normal working practice.
Manual workarounds not an option.
As the number of standalone systems and data volumes grow exponentially, it is only a matter of time before this task becomes far greater than the manageability of the workaround and appears in the “showstopper” category for senior management.
We're reaching the print where the problem is too big to use the manual workaround, data grows and so does the problem. Practicality lessens
While it’s clear that the world of standalone cloud-based systems is undoubtedly here to stay, there is some hope on the horizon for people who miss the simplicity of a single, integrated dataset from a single system on which to run their business.
People throughout the organization need data from multiple systems to do their job. Just because the business systems are no longer integrated does not mean that the business data they generate cannot be integrated and shared across the applications these people rely on daily.
A new generation of data blending and streaming solutions offer an effortless way to stitch all this enterprise application data back together and stream it to any application. These solutions reinstate the master data management layer that evaporated with the move to standalone systems.
Join data not systems.
By reinstating this layer, the challenge in creating master customer, product, supplier, and employee lists quite simply goes away. Not only do these solutions make master lists possible, in many cases the more advanced systems leverage AI and Machine Learning and build and clean the lists for you.
Given the volume of data these solutions must process, the best ones “let the machine take the strain,” leveraging the power of the machine, freeing up the user to glean insights and add value to the data that a machine never will.
Going back to the original theme of simple, yet annoying things that just never get properly sorted, it might just be time to take stock of all the unnatural acts you do around data and see if it is finally time to find a better way to automate and let the machine take the strain.
If you would like to an example of this type of system in action www.eyko.io.
You May Also Like
These Related Stories