Repeatable ERP programmes: the assets many teams rebuild every wave
On a multi-wave ERP programme, the data migration and its checks are often built by hand for each wave, so each new wave pays for them again. Kept as repeatable programme assets, they carry to the next wave and only the differences are built.
5 min read
The first wave of an ERP rollout builds the data migration: the mappings, the validations, the reconciliations and the load sequence for cutover. On many programmes the second wave builds them again, and pays for them a second time.
Some of it is copied from wave one and some is rewritten. All of it is tested again as new code, since a copy cannot be trusted to behave like the original until it has been proved.
The alternative is to keep that work as repeatable programme assets: version-controlled, with the migration code printed from the mappings. Each wave then starts from the assets the last one cut over with, and builds only what is different.
Why each wave starts again
There are good reasons it happens. Each wave has its own scope (a region, say, or a brand) with its own extracts, local rules and reference data. The people change too. SI teams roll off between waves, and the BAU experts who answered the data questions go back to running the business.
The migration code was written by hand for wave one's cutover, so it carries its developers' choices, and the validations and reconciliation queries sit beside it in scripts and spreadsheets. When wave two starts, copying and adapting that work looks cheaper than understanding it.
Why the copies drift
Hand-built work is written for one wave's scope, so the next wave adapts a copy of it, and from then on there are two versions to keep in step. Two developers adapting the same validation can produce two different validations. A fix made in the last week before wave one's cutover may never reach the copy wave two started from. Wave two's reconciliation is rewritten for a new store list, so its results cannot be read against wave one's.
The checks are proved again as new code, on the critical path, by people who did not write the originals, and the estimate for wave two is based on what wave one cost to build. Each cutover's evidence stands alone, so the steering committee cannot tell whether the data is becoming more trustworthy from wave to wave or is simply being re-proved.
A well-run programme can hit this too. Hand-crafted delivery builds each wave's artefacts for that wave's cutover. When the wave ends, what is left is the migrated data and a set of scripts written for a scope that has moved on.
Repeatable programme assets
Repeatable programme assets apply deterministic delivery to what a wave leaves behind. What wave one built is kept as assets of the programme, under version control, and the code that moves the data is printed from the mappings. The next wave changes the assets where its scope differs and prints the code again, and everything else runs as it did at the last cutover.
elfware's toolchains run the same way in every environment, which limits how far a bad change can spread.
Rebuilt each wave
- Wave one builds the migration
- Cutover
- Wave two copies and adapts
- Tested again as new code
- Evidence stands alone
Repeatable programme assets
- Wave one's assets, under version control
- Cutover
- Wave two changes only its differences
- Same gates as wave one
- Waves read side by side
How the assets carry from wave to wave
The mappings are self-documenting, so the analyst on wave two can read what wave one decided without tracking down whoever decided it, and take a change from request to deployment alone.
elfware reuses existing adaptors to accelerate delivery. On Oracle Retail the validations draw on a library of automated scenario and data validations. Each load reconciles source and target for both correctness and completeness, as measures broken down by dimension.
The load sequence is orchestration persisted as code, so wave two starts from the order wave one cut over with. Execution and quality data are trended across environments. Wave two reconciles on the same measures as wave one, so the steering committee can read the two waves side by side and see whether the data is getting more trustworthy.
The next wave is then estimated from assets that already exist and loads that have already run, which makes its estimates for cost and timeframes more reliable.
What wave two changes in a region-by-region Oracle Retail rollout
Say a retailer moves onto Oracle Retail one region at a time. Wave one would build the mappings for items, suppliers, stores and prices, the validations and reconciliations on them, and the load sequence, and cut over the first region.
In the default plan, wave two would copy that work, adapt it for the second region's tax rules and extra price types, and test it again as new code. With repeatable programme assets, it would start from wave one's assets at the version that cut over. The only changes would be the second region's differences: a new price type in the price mapping, the new stores and local suppliers in the extracts. Nothing else would change, and wave two's first load would meet the same validation and reconciliation gates that wave one finished on.
If wave two found a price rule that should have held everywhere, it would be fixed once, in the mapping. Wave one's region could then be re-run through the same gates in a test environment to show it still reconciles.
What a wave hands to the next
At the end of a wave the programme holds its assets at the version that cut over, and a validation and reconciliation result for every load they ran. The next wave starts there.
What did your last wave leave behind?
Ask what your last wave handed over besides the cutover. If the answer is a set of documents, the next wave will rebuild the rest.
If the answer is a set of documents, the next wave will rebuild the rest.
When a wave brings in a brand or a business whose idea of a product differs from yours, the assets repeat only once the mappings agree on what the data means, and the product master is where that agreement breaks first.
If you have waves still to run, talk to us about putting one area of the next wave through a first cut on your own data, reconciled.
Part 1 of this series: The data problem nobody sees until SIT