Which application owns the definition of a customer account?
At one time or another for most businesses, this question or argument becomes prominent. The need to decide which application is to be the “system of record” for the notion on an “Account” usually appears during the time when the business is rationalizing its enterprise operating software applications for sales, orders, billing, and supply chain management, or when integration is needed. And when the question or problem becomes apparent, we see stakeholders and IT professionals immediately take sides. The conflict begins.
I wish I had a dollar for every ERP consultant that says: “ERP is—or should be the system of record for the customer.”
I completely disagree. I’m going to take a very hard stand and then back it up. When it comes to the notion of a “customer” (whether a business reselling partner or a business or residential consumer), CRM must be the “system of record” to define and track the definition of the customer as an entity and its relationship to your business. ERP has nothing to do with it. (* for ecommerce-oriented businesses, CRM should be the backbone and maintain customer definitions that transcend the ecommerce shopping account).
There I said it. It had to be said :-). And whether your business takes this approach or confers upon ERP the right to own the definition of a customer will eventually influence and help determine if your business will be customer-centric or operational-centric. If you choose the latter, it’s only a matter of time before a competitor or startup begins to erode your market share.
Before stating my argument, let’s not muddy the waters. If you acquired an ERP system based on its ability to function as a business intelligence tool, not only did you likely make a mistake, but you also will use that requirement to steer the argument toward using ERP for containing the definition of a customer…so you can do proper reporting. But let’s assume your thinking about enterprise application rationalization is mature, and you realize the need for a separate BI tool, so CRM is all about marketing and selling processes, and ERP is all about finance, accounting and supply chain management processes.
In short: CRM must sell. ERP must invoice and collect (and deliver). And my argument is that each respective mission uses a different definition of the database record that defines an element of the customer. This is the critical difference, and again it will determine if you are customer-centric and therefore economically dynamic, or if you are legalistic, operations-centric and static.
The argument boils down to the notion of an account, which is the database entity that contains the basis for a customer, and importantly its predecessor the “prospect” (not yet a customer but you want it to be).
So, we need to define terms that help us understand how each respective system wants to understand the notion of an account. It boils down to the mission of each respective solution and its perspective.
CRM: An account to CRM is an economic actor defined in a way that allows optimal sales representation. An account is always one of these things: CRM a customer is a business, org, person or household. It represents something real in the world, something tangible with rights, plans and actions. It is one of these things:
B-B: A legal entity that produces organizational entities that are DBA’s, operating as a business or NFP or governmental unit. This can be a consuming org or a reselling partner org.
B-C: Or it can be a consumer defined as an individual or household.
Financial ERP: an account to ERP is a means to invoice and collect; no more. An ERP account represents a legal right to collect funds. It is just an account, an abstraction. It can be a bank account or credit card account or a billing address. Of course, ERP wants to know that behind this collection account is an entity that limits risk, but that’s about its only concern for the notion of a customer.
ERP wants cash. And if it must track a contact person who represents either the consumer-payer, or an accounts-payable agent, that’s could easily be the extent of the relationship. Cash flow. It helps to look at an exaggerated example to illustrate the differences between the CRM and ERP perspective. Imagine we live in a socialist dystopian order; all payments were made by a single government payer. ERP would be happy to have that one account in its system. However, CRM would still need to track every individual citizen, their propensities, and decision-making processes.
But notice the difference this perspective makes. ERP only needs a payment account and a legal entity that owns the account, and a helpful person who can give status and make payments. CRM needs to know about the real organizational units and composition of the actors which can be defined differently.
(Note, like the need for financial account data, ERP may also need to know ship-to data or some sense of a customer’s operational footprint. All the same rules apply as above. This is the supply chain/fulfillment perspective, and not the actual customer.)
These different perspectives give CRM the right to be very fluid in its definition of a customer. Think about it. Let’s first take the example of a large, multinational business customer. It is an entity that is comprised of many legal entities. These legal entities exist “on paper”, but not in the real world.
In 2012 I led Caterpillar’s global CRM solution deployment and as an example it had 17 legal entities in Australia alone (not including their independent dealers). But in no case did any legal entity have a marketplace definition such that any business selling to Cat would ever make progress by selling into those entities. Instead, the DBA business groupings reflected both Cat’s organizational decision-making units (across legal entities) and the supplier’s organizational groupings based geographically and on the basis of value proposition. Therefore, CRM accounts are invented with real business interaction as the basis, with flexibility for account management.
But any Cat vendor ERP would need to know which legal entity and their credit rating. This might be the parent company...and that would render the idea of a customer almost pointless. Cat as a complete org is a $50 billion complex organization.
If you were selling to Cat, might it be good to have a structure like this in CRM (just as an example)?
Cat Global
Mining
Construction
Diesel Engines
Parts
Transportation
-Marine
-Locomotive
-Truck
Now, what if the Mining group told you that when you sell them X or Y, you should bill to account 123 in Brazil? But when you sell Z or Q, you must use account 789 in New York. As a salesperson responsible for making quota and generating revenue, do you care? No. But as an accounts-receivable analyst, do you care about the VP of Procurement in the Mining group in Milwaukee? Nope.
ERP: ERP wants to keep the legal entity/ billing account records that tend to be very static, slow changing. But CRM could reorganize its definition of accounts as needed to exploit the ever-changing marketplace. It must not be constrained.
Folks, we have completely different account definitions because we have different missions and perspectives.
Now what about B-C commerce? It’s the same thing. Payment channels for consumers are likewise proliferating. I can pay you by debit card, any number of credit cards, bank accounts, PayPal. Heck even my Bitcoin. I might pay for my adult children, or they may pay for me. We might have one account at the household or many. But that is not the same thing as the person with real characteristics and proclivities and decision-making capabilities. CRM needs to know the real household, the real residential owners/renters and if there are others, exactly who they are. ERP still just wants to know how to get paid.
ERP solutions are aware of their simple mission to get that cash, and they are designed with very simple and limited customer tracking mechanisms. CRM is a very dimensional and omnichannel tracking database with many attributes. ERP solutions with financial tracing have been around forever, and if they were adequate to explain the notion of a customer, there would be no such thing as a CRM. Since CRM’s became prominent in the 1990’s, and ever-increasingly mature, ERP’s have even less to offer.
So, how does this make a difference to the way systems must operate, especially in an integrated environment? It causes the reporting systems to utilize orthogonal dimensions. The relationship between CRM and ERP accounts is N-N, which means you can report on revenue for an ERP account (bill-to) and a CRM account (sell-to) but they will not be 1-1. The account names will confuse the reporting audience since ERP may use a similar name to CRM. OF the two, only the CRM account has real BI value.
If you force CRM to accept and use only the ERP account definition, you destroy its ability to define the marketplace in the optimal manner for selling, and you cripple the sales resources. In fact, the sales user community will simply go offline with their CRM. You will become less competitive and unable to make good revenue-generating decisions. You will see customers as payers. Your model will be to raise prices vs. to promote 1-1 value.
How does a CRM prospect become a CRM customer and link to an ERP account? Well, every good CRM should have high-value targets pre-loaded. Prospects are accounts that have initiated a commercial conversation tracked in the CRM as a “prospect” account (a wannabe customer). When they request a quote or place an order, the ERP solution can track the collection account (or seek to determine if that account already exists). And CRM can track the one or many ERP accounts the customer uses for billing. Then let each order/transaction inform ERP which ERP-account is being used for collections and refunds, but let CRM understand how it is satisfying the marketplace by tracking the real customer. ERP should stay in its lane and let your business be customer centric. If you get this right, you are on track toward customer-centricity. If not, well, good luck.
For advice about your customer definitions and how to properly structure CRM within the integrated application architecture, feel free to contact us at Ascendant Group Inc.