Module
S/4HANA Readiness & Migration
Which records in your separate ERP systems are the same part, decided by a person on evidence.
What it produces
- Candidate pairs across instances, each ranked with the evidence that produced the score
- A confirmation queue ordered by spend and transactional usage, with dormant records removed from it
- The group nomenclature standard, and every record's compliance with it
- Coverage by group spend, weekly, with the unharmonised remainder itemised by system and reason
- A cross-reference in the system integrator's load format, with the decision history behind every row
A worked example
Two descriptions that score 0.60 on text, and are different parts
HEX BOLT M8 40 against HEX BOLT M8 50, in two instances of the same ERP
normalised tokens {HEX, BOLT, M8, 40} and {HEX, BOLT, M8, 50} — shared 3, union 5
Jaccard = 3 ÷ 5 = 0.60, which on any sane threshold would have merged them
numerals {40} ≠ {50} → suppressed, and no score anywhere overrides that
Illustrative numbers. On your tenant the same page shows yours.
Why it is hard
The part that is not a report.
A group that has grown by acquisition holds one part under a different code in every system it bought, and nobody can say how many. That is not a reporting problem to be solved with a better dashboard: until somebody has said that three codes are one part, a group-level number for that part cannot exist, and every number built on top of it is an average of things that are not alike. The expensive mistake here is the opposite one. Two descriptions can be almost identical and be different parts — HEX BOLT M8 40 and HEX BOLT M8 50 share three tokens in five — and a merge made on that resemblance becomes a wrong purchase order, found on a shop floor rather than in a report. So nothing merges on a score here. The engine proposes, ranks, and shows a buyer the two records side by side with the evidence it used; a person answers same, different or unique, and the record keeps their name, the date, and what they were shown. The arithmetic behind every score is deterministic and reproducible from your own extracted data, because a score you cannot recompute is a score you cannot defend to an auditor.
Opened by the finance director and the procurement lead — what each of them sees first.
Said before you ask
What we don’t do.
SIAARU decides from your records and nothing else. It carries no copy of the world’s data, states no number your systems have not, and acts in nobody’s name. Where your data does not support an answer, it says so by name rather than producing a confident one — which is the whole reason a decision taken on it holds up later.
Held back deliberately: the engine is at build phase 1 of the seven in docs/MASTERDATA.md. The shapes, the normalisation with its numeric guard, and the write-back gate are built and tested; the four scoring passes, the event log behind L1–L5, the confirmation workflow, the nomenclature standard and the load-format export are not. It is COMING_SOON rather than BETA because it has not passed a release gate, which is what BETA would claim.
Where this sits
One of 36 modules, on one engine.
S/4HANA Readiness & Migration reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 35 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.