CRM to ERP Basic principles considered
1. Duplicate data in a CRM system is a bad thing
It’s the aim (or should be) of a CRM system to have a single record for anyone Organisation/Company/ Account, Person/Contact, etc. This means that reporting, marketing, customer service, account management and more are all built from and updated to this single unique record; therefore offering the utopia of a single 360-degree view of a customer.
2. Merging/deleting records in an Accounting/ERP system is generally a bad thing
Whereas in CRM most systems usually offer some level of de-duping/merge/purge capability to assist with achieving point 1, most Accounting/ERP solutions do not and for good reason. Merging/deleting records in an Accounting/ERP system is very likely to affect reporting in a negative way. It may change the way a historic set of accounts is presented with specific details of invoices, purchased orders, and so forth being affected. Generally, this would not go down well with an accountancy practice and could have legal implications.
For these reasons, most accounting solutions will only support making an account “Inactive”.
3. Having “duplicate” records in an Accounting/ERP system can be a requirement
Although handled differently by different systems, a company may be a Supplier and a Customer. This may require an entry in both Purchase and Sales Ledgers.
Testing the Design
Let us, therefore, consider a few scenarios to test the design against.
Scenario One: Company A is both a supplier and a customer
In CRM terms, there is only one Managing Director, CEO, Sales Manager, Purchasing department etc. Therefore it makes perfect sense to have only one record for these within CRM.
In most accounting system, however, these contacts will be managed as two separate records- Customer & Supplier.
Scenario Two: Company A has several divisions
A company may have many divisions e.g. Auto Division, Marine Division, Aero Division. From an accounting perspective, these divisions may need to be managed as separate entities as they may have different credit terms and separate purchasing procedures for example.
Again the issue is, the management line of Company A is the same across all divisions with only people at the operational level being unique to that division.
Scenario Three: Mergers and Acquisitions
If a company is merged with another or acquired it may be appropriate in CRM to consolidate what may be several existing records into one because the executive level management is now the same.
In the accounting system, however, the business may wish to retain a view of the previous purchase history for all the newly merged or acquired companies.
The above scenarios are three possible cases where there is specific need to have multiple “duplicate” records in the accounting system and a single record in CRM. These scenarios could be further complicated by adding any combination of the above.
Data entry errors
We all know that manual data entry is a prime source of error. People will search for records with slightly different spellings of names, meaning that when they look it’s not there so they may end up re-entering the record. Data imports and other integrations also lend a hand in adding to the data nightmare.
When finally it comes to cleaning up that data, what can be done? As discussed above, CRM and Accounting/ERP generally have a different view on what is best practice.
If the integration is 1-1 and someone runs the inherent or external CRM match & de-dupe process without thinking…..BANG!!! you have just blown the integration. In a 1-1 structure, there is no place to record a second or third accounting link in the CRM system. The accounting system may retain the CRM link but the CRM record has been deleted as part of the merge/purge process.
Therefore the integrity of the system is shattered!!!
This is probably the most serious of the situations that can arise.
So the answer is…
I have to use generalisations again but it would be true to say that most modern CRM systems will allow additions to the underlying database. This enables the addition of a table which can support multiple entries linked to the Organisation/Account/ Company table. Designing this additional table to hold not only the Accounting/ERP reference number/ID but also the name as held within the Accounting system, Status (Active/Inactive), Type (Supplier/Customer) perhaps even main address, Credit status, Credit Limit, and so forth will provide continued integrity and protection against the sort of issues described above. Not only will this design enable 1-many links to be set up pro-actively but as and when a data clean up task is carried out, the merge/purge process is now able to roll up and preserve all the links of the duplicates to the primary or master CRM record.
A further consideration is where you may be running multiple sets of accounts in the Accounting/ERP, say one set of accounts for each country you operate in. This would be inherently managed within a 1-Many structure.
And the downside ….
With the 1-many design the integrity is maintained but what of the downsides? Well, this approach does inherently add more complexity. The integration sync process needs to be aware of which link to use, which may require a slightly more sophisticated design and user interface. Presenting a single field at the Company record level of credit status, credit limit and so forth also is not going to work. Therefore there will be other design and implementation considerations.
But the benefits are…
As described through this post, data integrity is far superior in a 1-many design but this is only the ‘mechanical’ benefit. Beyond this we should consider the users:
- Users will now only have to go to one place to see the total 360 view of the customer
- Account management is easier and more accurate
- Marketing will also not have to work out which of the duplicate contacts they should be marketing to
- Customer Services has consolidated view of purchases
- Cross selling becomes more effective
- Improved usability and therefore user adoption
- The total value to you as a Supplier and/or Customer becomes absolutely clear.
And in the end, should for any reason, your business prefer to operate in a 1-1 mode, this is obviously still possible within the 1-many design.