Your ERP And Customer Master Data

Are you really addressing the problem?

14Feb

If your ERP implementation includes the revenue cycle, you will need to convert customer master data to the new financial system of record.  This may seem like an obvious if not simple task.  Certainly, customers represent mission-critical data, but how hard can it be to convert this data?  

Other than the customers' unique identifiers themselves, there aren't many codes to worry about.   NAICS and the older SIC are standards which should not vary by platform. One doesn't need to translate a chart of accounts nor reconcile AP or AR balances. There's no depreciation to tie out. No prior period GL balances.  Aside from perhaps a hash total as a completeness check, there may not be any numbers at all. It seems straightforward, and often it gets treated that way. But if you've governed an ERP project, you know converting customers is hardly ever this simple.

Why isn't it as easy as it seems?   Here's one tidy question which speaks to how messy customer conversion can be. 

How do you know when to create a new customer record versus when to add an address to an existing customer record?

A hypothetical case study will clarify. Consider that you have five ACME Corp records with different addresses. During a conversion design workshop, someone asks whether these five ACMEs should become:

- Five ACME customer records

OR

- One ACME customer with five addresses

This sounds like a tidy question, but try to get a straight answer.  Too often, the response from your implementation consultants echoes the official system documentation. The documentation merely states that the system is flexible. You can add one ACME with five addresses or five linked ACMEs. And this is all true. Modern ERP systems are flexible, so you could do either one of these options in Oracle Cloud, Oracle EBS, Oracle PeopleSoft, SAP, or others. Such a tautology answers nothing and just takes you back to the question.     

Here is some advice on breaking the cycle and getting to an actual answer. Think downstream. For the revenue cycle, this means framing the questions in terms of Accounts Receivable analysis.

Do your AR specialists collect individually on each of the five ACMEs? If so – strongly consider making these separate customer records. Yes - you can, in theory, run reports which age items based on customer address. But step into the shoes of your AR specialists. They talk to customers and rely on one or two key screens to have the customer account at their fingertips. But these screens don’t reference a customer address. They reference a customer. Shouldn't you set up your customer data accordingly?

There will be other considerations in determining how granular to make your customers, but if you start by asking what level of granularity supports your AR, you’re moving in the right direction. 

Rather than drowning in a sea of flexible alternatives, you’re reaching a conclusion based on a business need.  

A fine reason to implement ERP in the first place.

Accounting

Read next:

Your Chart Of Accounts - Revisited

i