ERP data preparation: bu ne anlama geliyor
ERP systems are built to record transactions: an order was entered, goods left, an invoice was raised. What decision-making needs is different, and the difference is usually discovered halfway through the project.
Four typical gaps
- Master data inconsistency. The same product sits under one code in the ERP, another in the WMS and a third in the POS extract. The same supplier is registered three times under three trading names. Until those matches are built, no question spanning systems can be answered.
- Missing timestamps. ERPs generally hold the current state, not the historical one. “What was this product’s stock last Tuesday” cannot be answered unless it is reconstructed backwards from stock movements.
- Negative events not recorded. Sales that happened are recorded; sales that did not happen are not. Out-of-stock days, unmet demand, cancelled orders — these matter as much as sales data for decisions, and are usually not captured at all.
- Free-text fields. Cancellation reason, delay explanation, customer note. Unstandardised text is data that cannot be analysed.
The order of preparation
Relationships first, cleaning second. Establish cross-system matching before starting to clean. Incorrectly matched clean data is more dangerous than correctly matched dirty data — because it looks trustworthy.
Then clean the critical fields, not all of them. Focus on fields that affect the decision. Projects that try to clean everything finish after everyone has stopped waiting for the result.
Then start capturing the missing events. Out-of-stock flagging can start today; it cannot be built retrospectively, which is what makes starting early valuable.
Where master data management starts
Master data cleaning looks like an endless task. The practical starting point is: which entities live in more than one system?
Typically four: product, supplier, customer, location. Once cross-system matching exists for those four, most decision questions become answerable.
While building the matching, write down which system is authoritative for which field. If it is unclear which wins when two systems disagree, the cleaning repeats every month.
Snapshot or event history
An ERP mostly holds current state. Decision analysis needs past state, and that is obtained two ways:
Reconstruction from events — past stock positions computed from stock movements. Accurate, but expensive to compute.
Periodic snapshots — a nightly copy of critical tables. Simple, and misses intraday change.
For most operational decisions a daily snapshot suffices. Because it is simple to set up, starting early is valuable: it cannot be built for the past.
Finding what is missing for a decision
A practical method: write down the ten operational questions you want answered (“why did this product run out”, “why was this order late”). Try to answer each with the data you have.
The unanswerable ones set the priorities of the data roadmap. That gives a faster and more defensible ordering than “let us clean all the data”.
A field name is not the field’s meaning
An ERP may hold three fields called “delivery date”: promised, planned and actual. Which one is populated varies by module and by year.
Ambiguities like this are not resolved from documentation; they are resolved by looking at the data. What share of rows a field is populated in, and what range it takes, says more than its name does.
Cancelled, not deleted
Cancelled orders remain in most ERPs, flagged with a status code. Including them inflates demand; excluding them entirely discards something that genuinely was demanded.
The right treatment depends on the reason: an order cancelled for lack of stock is unmet demand and should count; one the customer withdrew should not. The distinction is available in the cancellation code and is almost never made.