Master data management consulting for companies in Germany

When one customer lives in four systems

Master data are the records that other records point to: customers, suppliers, products and sites. Master data management decides what counts as one of them and which system holds the leading version of each field.

In a growing company these records tend to appear system by system. The CRM knows a customer under one number, the ERP under another, the shop under an email address and accounting under a debtor number. Each system keeps its own copy of the address, and each copy changes on its own. A simple question then has several answers, such as how many active customers the company has.

What I set up

A record describes one thing in the world, and its type says what kind of thing it is: a company, a person, a product or a site. The number a system gives the record is a handle for it and says nothing on its own. The model behind this is on Tracking objects over application boundaries.

The commercial register number, the VAT ID and the article number exist outside your systems, and several of your systems hold them. I use such keys to find records that describe the same thing. Registers reuse codes, and two records with one code can still differ in a basic fact, so the key proposes a match and a check decides it.

When two records describe one company, a link says so, and both records keep their numbers and their history. Withdrawing a wrong link is one change. A contradiction, such as a dissolved company and an active one, blocks the link.

The role of a contact person at a customer is a record of its own, and so is a contract between two companies. A contact can leave while both companies continue, and the end of the role is stored as a change with its date.

The other systems write through an API, each with an access token of its own. An import token may create records and may not change existing ones, so a faulty import cannot overwrite what your staff maintain. How other systems couple to the store describes these rules as I apply them in client work.

Who owns which field: an example

A field table names the leading system for each field of a record. The example below is for a customer. Yours will differ, and we write it together in the project.

Field	Leading system	Who changes it	How the other systems check it
Legal name and legal form	ERP	Accounting, from the commercial register	Commercial register number
VAT ID	ERP	Accounting	Format check and the EU’s VIES service
Billing address	ERP	Accounting	Postcode fits the country
Delivery addresses	ERP	Order processing	One delivery address per site
Contact persons and their roles	CRM	Sales	Email domain fits the company
Newsletter consent	Shop or CRM	The customer	Date and source of the consent
Customer number	ERP	Assigned once, not changed	Stored in each system as a reference

For a product, the same table names the ERP for the article number and the price, and the shop or a product information system for texts and pictures.

Who I am

I am Michael Wutzke, based in Frankfurt, with more than twenty years in IT and media. At Policen Direkt I connected a customer portal for insurance policies to an existing CRM system. I have helped build a client’s information platform on which companies and people keep one identity across registers and sources. I hold a training authorization from IHK Frankfurt and teach at Claude Hacker House. I build software with Claude and Codex and am interested in open-source AI models that a company runs on its own servers. Details: Career stages.