One view of the customer, without an 18-month data project
5 min readUpdated
A single view of the customer requires agreeing which field identifies the same company in each system, then keeping that agreement current. The traditional route is to copy every system into a warehouse and model it there, which takes many months. The alternative is to query the systems where they are and join them on an approved key. Faster to start, provided the tool refuses to guess when the key is missing.
Why this is hard, in one example
In your CRM the company is "Falcon Systems Ltd". In finance it is customer number 259. In the support desk it is "falcon-systems". None of those three systems knows about the other two, and no amount of clever software makes that knowledge appear from nothing.
Somebody has to state, once, that those three records are the same company. That statement is the entire project. Everything else is plumbing.
The two routes, honestly compared
The second route is not a replacement for a warehouse and anyone telling you otherwise is overselling. It is a way to stop the warehouse programme from being the thing that blocks every question for a year.
| Copy everything into a warehouse | Query the systems where they are | |
|---|---|---|
| Time to first answer | Months | Days to weeks |
| Up-front cost | High: people and platform | Low |
| Who is needed | Data engineering team | Someone who knows the business keys |
| Handles very large history well | Yes, this is its strength | Better for current-state questions |
| Still needs the key agreed | Yes | Yes |
What to insist on
- It asks for the key rather than inventing oneMatching on company name looks like it works. It quietly merges two subsidiaries with similar names and splits one customer who was entered twice with a typo.
- It refuses when the key is missingThe correct behaviour for an unlinked question is to say so. A number produced without an agreed link is not an estimate. It has no defined meaning.
- It does not silently pick one systemAsk for a comparison across two systems and watch carefully. Answering confidently from one of them, using the other's vocabulary, is a failure that is very hard to spot in a demo.
- Currencies and periods stay separateTwo systems can both be right and still disagree because one reports in local currency on a different financial calendar. Anything that sums them into one unlabelled total is hiding the problem.