02 · Requirements · Object ownership
Three customer numbers that do not match are not one customer
The data steward owns codes, names, deactivation, and quality rules. Until someone owns them, the new system is only a fourth numbering scheme.
Who is the owner: customer master data stays in the system with the most complete transactions. The other two keep a mapping only, and create no more.
What counts as the same company: the same tax ID is the same customer. When the tax ID is missing, name plus phone must not auto-merge. It needs a human confirm.
What deactivation does: after deactivation, no new document can be opened. Historical documents keep the old number. Direct delete is forbidden, or reconciliation breaks.
The data steward owns whether the object is unique, not whether the report looks good
When two tables do not match, it is often not a wrong formula. It is that customer numbers, item numbers, warehouse numbers are not the same set of objects at all. The mark of a data steward is setting, early in the project, the owner of master data, the merge rule, the deactivation rule, and the quality rule, and refusing “go live first, wash the codes later”. Wash later means historical documents have already gone out on the wrong number. They cannot be washed back. Who may change a name, how a deactivated row shows in a list, whether an interface may invent a code, how long a field such as a phone number is kept — those also need an owner. Without those sentences, governance is only washing master data. How a metric is calculated, and which column time is taken from, are not this role.
He needs the customer to name an owner. The owner is not an IT group chat. It is the person who can decide whether two companies with similar names actually merge. With no owner, the data steward will not auto-merge. One wrong auto-merge stacks two customers' AR together, which is harder to split than three numbering schemes.
How three numbering schemes appear, and why each side must not keep creating its own
At a trading company, customers sat in Kingdee, an old ordering system, and a salesperson's Excel at the same time. Kingdee had tax IDs. The ordering system had store short names. Excel had numbers the salesperson made up. The same supermarket differed by two characters across the three. If the new system again let a salesperson create when search missed, go-live plus one month would become four schemes. The data steward wrote the rule: the new system does not produce a customer master number; opening a document must pick a customer already in Kingdee; a miss submits a master-data request, handled by the owner within one working day; until it is handled the document cannot become confirmed.
A mapping table only solves history. Each row either matches on tax ID, or is human-confirmed, or is marked “do not migrate”. A do-not-migrate customer cannot appear in opening AR. Name similarity is only a candidate list for the owner. It is not a condition for the system to auto-merge. When a salesperson complains they cannot search, the data steward looks at the request backlog, not at opening the create button.
Handoff with neighbouring roles
The solution consultant decides master data stays in Kingdee. The data steward decides, once it stays there, how new documents stop growing side branches, and who may change names, grading, and retention. The data-migration engineer moves opening balances by the mapping table, and cannot invent a merge. The backend engineer implements “no master number, no confirm”. If implementation added a temporary customer to make a demo easier, the data steward will list those documents as data that must not enter acceptance.
After go-live he still keeps a sample check: every customer created this week must be findable in Kingdee, and new documents on deactivated customers must be zero. A failed sample is not an operations-campaign problem. It is master-data rules being bypassed. The bypass entrance has to be closed. It cannot rely on a notice asking people not to create that way.
The data steward does not own metric algorithms. He only makes sure both sides use the same set of customer numbers, item numbers, warehouse numbers, and that sensitive fields display under the same grading. When the numbers themselves do not match, arguing algorithms later has no meaning, because the two tables are not talking about the same objects at all.