Oops! The input is malformed!
Originally published May 1, 2007
When you listen to most people talk about enterprise resource planning (ERP) initiatives, the conversation largely focuses on business process reengineering. The software becomes valuable when it is used to improve the way employees take orders, manufacture, ship and bill for goods. True enough. But the value of ERP is not only derived from integrated business processes across a corporation’s value chain. Without integrating the data that supports those processes, corporations find themselves hopelessly far away from getting out of their ERP system anywhere close to what they put into it. So millions of dollars and several years later, many organizations find themselves in a frustrating situation: their ERP investment is still not helping them better manage their business.
Each previously dis-integrated process that ERP systems tie together has its own set of master data (also known as reference data), which must also be integrated in order to unlock ERP value. These master data entities include customer, supplier, product, material and other files. The success of ERP depends very largely on “data quality.” Data quality issues include incomplete, duplicated, erroneous, inconsistent and incorrectly categorized records, which can lead to improperly processed orders, inefficient inventory management and procurement, increased time to market for new products, less efficient business processes, less reliable business performance management and increased business risk.
Broadly defined, high data quality means that the data within your ERP system will support all of its intended uses. In addition to traditional ideas surrounding quality, real data quality means that master data has been appropriately integrated. Despite this reality, master data integration remains an afterthought in many ERP initiatives. Corporations believe that they are addressing these issues as they plan for the “data loading” step of their ERP implementation, but this approach often underestimates the importance and complexity in attaining quality, integrated data that will fuel the ROI of their efforts. Without universal trust in the accuracy and timeliness of the data in your new system, your project has all but failed.
Through sample conversations between the CEO and CIO of the fictional company, Wexford Widgets (The names Tony Williams, Bill Evans, and the company name Wexford Widgets are fictitious. Any resemblance to real persons, companies or circumstances is purely coincidence and non-intentional on the part of Alliance Consulting), I highlight some of the key discourses and challenges that organizations must face pre-implementation or upgrade.
From: Tony Williams, CEO, Wexford Widgets
To: Bill Evans, CIO, Wexford Widgets
Subject: Consolidated Billing
What are we prepared to do to address our top customers’ requests for consolidated billing? As you know, key customers have been complaining for years now about how we deliver many different bills to them, one for each of the billing accounts they’ve opened with us. Our manual efforts to intercept invoices and compile them into a single invoice don’t seem to be working very well. Clients are complaining not only about the inconvenience of receiving a stack of bills from us, but also that we aren’t capturing accurate volume purchasing discounts for them. This frustrates our customers, and costs us time and money to manually adjust all those invoices. I’m looking forward to your proposed action plan to address this.
From: Bill Evans, CIO
To: Tony Williams, CEO
Subject: Re: Consolidated Billing
I appreciate the problem. Our new ERP system will give us the ability to combine some of those accounts into a single billing account, with multiple ship-to addresses associated with it. That should address much of the problem. Of course, that begs another question: how are we going to figure out which of the current accounts really belong to the same customer? My staff has been doing some analysis, and they found that many of the accounts use different addresses, different company names, etc., but refer to subsidiaries or units of the same global customer. It’s going to be a real challenge figuring out how to identify all of these duplicate accounts and group them into a “master” account. And that’s assuming we can even get the customers to agree to our consolidating all of their accounts that way. I’ll need to do further research and get back to you.
In this example, Wexford has had individual systems handle different business functions, as well as separate systems for the same business functions at different business units within the company. They hope that implementing a single ERP package will unify these processes. But this is complicated by the fact that they don’t yet have a plan for how to integrate and de-duplicate the master files from each of the current systems.
One of the things Wexford hopes to get out of its ERP implementation is a better handle on customer data, including the ability to produce a single invoice for each customer. Larger customers are demanding a single, integrated bill that will simplify their payments and allow them to track what they are spending with Wexford. In many cases, these customers have implemented volume purchasing discount agreements with Wexford. They are afraid that they will not get the prices they are entitled to by these agreements if they are presented with a variety of separate bills.
The only way for an ERP system to enable this business requirement is if the company can find a way to “group” the accounts, identifying all of the accounts that belong to the same company, despite differing company names and addresses. In many cases, accounts were created under the trading names of subsidiaries or different departments within these customers. The industry standard for manual efforts to identify and group accounts is low, yielding less than 50% success in properly grouping accounts for the average, larger corporation. Wexford may have customer master data spread out in many different locations. Each different legacy system probably has its own customer master file. Consolidating these customer master files means being able to identify all of these accounts within these master files and determining which ones can be collapsed into a single account while still respecting the customer’s organizational hierarchy.
For example, a customer with multiple business units and subsidiaries may have created one or more accounts with Wexford for each of that customer’s business units. These business units can be at different addresses and may have little or no similarity in their names. Each of these accounts may have its own bill-to address, ship-to addresses, assigned Wexford sales rep (valuable information for sales commission purposes), credit limit and credit terms, payment terms and pricing plans. When linking these accounts together, that linking must pay close attention to the customer organization’s hierarchy in order to preserve the integrity of these key business elements. If you found that your organization has assigned two subsidiaries of a client a credit limit of $50,000 credit each while the parent entity had a $75,000 credit limit, would you want to allow each subsidiary to retain the full amounts of their limits, or would you want to ensure that the combined exposure to all subsidiaries of the company was not greater than your assigned $75,000 credit limit for that customer? Most likely the latter.
A customer data integration (CDI) solution addresses these problems by reconciling customer accounts and creating a “master customer account” that has the desired attributes. This master account is then cross-referenced to all of the accounts in Wexford’s application systems that refer to the same customer. This means that Wexford will be able to accurately track all of the sales to each customer by simply aggregating the sales for each of the accounts linked to that customer. A robust CDI solution also supports multiple customer hierarchies, allowing Wexford to track sales at various levels of their customers’ corporate hierarchies.
From: Tony Williams, CEO
To: Bill Evans, CIO
Subject: Overpayment of Rebates
Based on your concerns about our ability to pay out accurate rebates to our larger customers, I asked Finance to assign a team to conduct a spot audit of our contracted rebate and discount terms versus our actual payments made. The results were surprising, to say the least. We found that virtually all of the clients we spot-checked were convinced that we were not crediting them with all of their purchases from us when we calculated discounts and rebates. When they complained that they weren’t getting proper discounts, we were unable to provide them with a comprehensive report showing all of their business with us. Therefore, in the name of customer satisfaction, we were forced to honor their assertions about how much they are owed, or to negotiate a rebate with them. In either case, our audits show that we’re overpaying rebates and discounts by a sizeable amount. Needless to say, we have to put a stop to this situation as soon as possible. Your thoughts?
From: Bill Evans, CIO
To: Tony Williams, CEO
Subject: Re: Overpayment of Rebates
I’ve looked into solutions to this issue. The crux of the matter is that we need to be able to link together all of the accounts that are owned by each of our customers. We can’t force them to have only one account each, since they may have set up the accounts to correspond to their locations, cost centers or some other schema. But we need to be able to figure out which accounts really belong to the same company. I believe that we need to investigate customer data integration solutions. This will allow us to rationalize the customer accounts, and load better quality data into our new ERP system. The challenge at this point is that this CDI technology is not in our ERP project budget. I have asked my team to look into this and advise me on what it will cost.
Obviously, serious operational risks are inherent in a company’s inability to link together customer accounts. Wexford is alienating and frustrating their customers, who fear that they are not being given all of the discounts or rebates to which they are entitled. Because Wexford cannot prove otherwise, these customers are demanding payment, and – more often than not – Wexford overpays. Many ERP implementation projects do not address master data management or customer data integration until they encounter problems either during testing or after the system has gone into production, such as Wexford is facing.
Data loading and migration typically accounts for less than 10% of an ERP implementation program budget. The program managers assume that data will simply be loaded from legacy systems into the new ERP system. This approach drastically underestimates the effort required to load the new system with clean, integrated data. The reality is that data cleansing, migration, loading and integration often consume 30% or more of the effort in an ERP project. This is a far cry from the 10% typically budgeted. As a result, many projects find themselves facing last-minute data loading issues or other data-driven crises, and they need to scramble to meet these challenges. If data integration was given the proper consideration during the planning stages, however, this level of effort could be reduced and yield better results.
By giving Wexford an accurate view of the transactions that should be attributed to each customer, regardless of how many separate accounts that customer has created, a CDI solution can help ensure that Wexford is appropriately valuing each customer’s business. Not only can the customer get a single and (accurately) consolidated bill from Wexford, but Wexford can know with a high degree of certainty that they are giving the customer the appropriate discounts and rebates based on their purchase volume.
In my next article, I will continue to explore the role of data quality and customer data integration in ERP initiatives, following the complexities that Wexford faces in going live with their ERP system without a true data quality improvement plan in place. I will then explore best practices for integrating customer data integration into any ERP implementation.
Recent articles by David Gleason