Ask any team that has been through an SAP S/4HANA go-live what kept them up at night, and master data will be near the top of the list. Not because the objects are exotic, but because they depend on each other. A routing is useless without valid work centres; a production version is useless without the bill of material (BOM) and routing it points to; and planning results are only as good as every object in the chain.
Why the dependency chain matters
Migration is usually organised by object, with each object owned by a different team. Problems appear at the boundaries: a BOM loaded before its components exist, a routing referencing a work centre that was renamed, a production version created before its routing was approved. Each object passes its own validation, yet the end-to-end process still fails. Mapping the dependencies explicitly, and loading and validating in that order, avoids most of these surprises.
A typical dependency sequence for manufacturing
- Organisational structure. Company codes, plants, storage locations and MRP areas must be configured and stable before anything else is loaded.
- Business partners. In S/4HANA, customers and suppliers are maintained as business partners. Supplier records must exist before purchasing info records, scheduling agreements and source lists can be created.
- Material master. Basic data first, then plant-level views: MRP type, lot-sizing procedure, procurement type, planning strategy, scheduling margin key and, where relevant, the advanced planning flag for PP/DS.
- Bills of material. Every component must already exist as a material in the right plant, with the correct base unit of measure.
- Work centres and resources. Capacities, formulas, shift definitions and cost centre links. Inaccurate capacity here quietly undermines every finite schedule later.
- Routings. Operations, standard values and work-centre assignments, plus component allocations to operations where needed.
- Production versions. In S/4HANA, production versions are central to selecting the BOM and routing for production, so they must point to valid, released objects with sensible validity dates and lot-size ranges.
- Planning data for PP/DS. Where embedded PP/DS is used, production data structures (PDS) are generated from the production version, BOM and routing, so they can only be created once all three are correct.
- Sources of supply. Purchasing info records, contracts, scheduling agreements and source lists for purchased materials.
- Transactional data. Stock balances, open purchase orders, open production orders and sales orders, loaded close to cutover.
What to check for each object
| Object | Key checks before sign-off | Typical owner |
|---|---|---|
| Material master | MRP type, lot size, procurement type and planning strategy set per plant; units of measure consistent | Master data / planning lead |
| Bills of material | Every component exists in the plant; quantities and units plausible; validity dates correct | Engineering / manufacturing engineering |
| Work centres / resources | Capacity, shifts and formulas reflect reality; cost centre assigned | Production / industrial engineering |
| Routings | Every operation points to an active work centre; standard values plausible | Manufacturing engineering |
| Production versions | Reference a released BOM and routing; lot-size ranges and validity dates sensible | Planning lead |
| Sources of supply | Every purchased material has a valid info record, contract or scheduling agreement | Procurement |
| Stock and open orders | Quantities and values reconcile with legacy and finance | Inventory / finance / planning |
Proving the data is ready
Record counts and load logs prove that data arrived; they do not prove it works. Strong programmes add three layers of validation:
- Object-level rules. Mandatory fields populated, values within allowed ranges, units of measure consistent, no orphan references.
- Cross-object checks. Every BOM component exists in the plant; every routing operation points to an active work centre; every production version references a released BOM and routing.
- Process-level tests. Run MRP, and PP/DS where used, against migrated data and review the results with planners. If planned orders, dates and capacity loads do not make sense to the people who use them, the data is not ready.
Measure readiness, don’t guess it
A simple readiness scorecard by object and plant, tracking completeness, accuracy against agreed rules, and sign-off by the business owner, turns “we think it’s fine” into an evidence-based go or no-go decision. Tracking the same measures across each mock load also shows whether quality is improving fast enough to hit the cutover date.
Ownership after go-live
Master data does not stop at cutover. New materials, engineering changes and capacity updates keep coming. Defining who creates, approves and maintains each object, and in what sequence, protects the quality that the migration worked hard to achieve.
Common pitfalls
- Loading by team, not by dependency. Objects arrive in the order teams finish, not the order the system needs them.
- Counting records instead of testing processes. A perfect load log can still produce planning results nobody trusts.
- Fixing data in S/4HANA but not at the source. The same errors return in the next mock load.
- No business sign-off. IT declares data “ready” without the people who will use it agreeing.
- Freezing too late. Engineering changes during the final mock loads invalidate earlier validation.
Quick checklist
- Publish the dependency sequence and share it with every object owner.
- Agree object-level and cross-object validation rules, with pass thresholds.
- Run MRP (and PP/DS where used) on every mock load and review results with planners.
- Track readiness by object and plant after each mock, and watch the trend.
- Get named business sign-off for every object before go/no-go.
- Define post-go-live ownership for creating, changing and approving each object.
Key terms in plain English
- Business partner – the single S/4HANA object used to maintain customers and suppliers.
- Production version – the link that tells the system which BOM and routing to use to make a material, and when.
- PDS (production data structure) – planning master data used by PP/DS, generated from the production version, BOM and routing.
- MRP area – an organisational unit for planning a material separately, for example by plant or storage location.
- Cross-object check – a validation that tests the links between objects, not just each object on its own.
Free master data readiness scorecard
To make readiness measurable, we have built a free Excel scorecard around the approach in this article. It maps the dependency chain, tracks validation rules, rolls results up to a Ready / At risk / Not ready status and shows the trend across mock loads.
| Template / tab | Use it to | Key fields |
|---|---|---|
| Dependency map | Load objects in the right order and catch anything loaded too early | Sequence, dependencies, owner, load status; automatic sequence check |
| Validation rules | Track object-level and cross-object rules with pass thresholds | Rule, records checked, failures, pass rate, Pass / Fail |
| Readiness scorecard | Give each object an evidence-based readiness status | Completeness, accuracy, cross-object %, sign-off; Ready / At risk / Not ready; overall % |
| Mock load trend | See whether quality is improving fast enough for cutover | Score per mock, change since mock 1, on track? |
Preview: readiness scorecard
| Object | Completeness | Accuracy | Cross-object | Sign-off | Status |
|---|---|---|---|---|---|
| Example: material master | 99.5% | 97.0% | 99.0% | No | At risk |
| Routings | 99.2% | 98.5% | 98.1% | Yes | Ready |
| Production versions | 96.0% | 88.0% | 91.0% | No | Not ready |
Objects, rules and targets (98% ready, 90% at-risk floor) are a generic starting point. Agree your own with data owners.
The bottom line
S/4HANA rewards clean, connected master data with faster planning and better visibility. Treating master data as a dependency chain, rather than a list of separate objects, is one of the most effective ways to reduce go-live risk.
Planning an S/4HANA move or reviewing your production planning set-up? Talk to Taksh Solutions about a fit-gap review shaped around how your plants actually run.