One IBM Maximo platform across business units for a UK and Ireland building materials group
A building materials group running enterprise asset management differently in each business unit, with one division still on SAP. There were three credible ways forward. The one that was cheapest to plan would have produced a platform that looked consolidated and behaved exactly as before.
The decision on the table
Consolidate the platforms, report over the top of them, or agree how the group works and then move. Only one of those answers the question the group was actually asking.
- Sector
- Building materials & aggregates
- Region
- UK & Ireland
- Duration
- 13 months
- Scope
- Implementation, migration, cloud, support
- Versions
- IBM Maximo on DB2, cloud-hosted
One group, several vocabularies
What the group had, and what the date forced
The estate
One division still on SAP EAM, an ageing Maximo environment on on-premises infrastructure in another territory, and business units that each ran maintenance in a way that made local sense and did not travel.
Group questions about asset performance or maintenance load could be answered only by joining sources and attaching a caveat. The hard part was agreeing what an asset is, how a job gets classified, and when a job is done.
The clock
The UK date was set by the exit from the incumbent platform. It arrived whether or not every business unit felt ready, so the plan was built backwards from it.
The second territory’s upgrade and move to cloud had its own much shorter window, and the two overlapped. Two live workstreams, one immovable date, one pool of people with deep knowledge of source and target.
Three routes, one of them wrong
How a group with several operating models gets to one platform
All three were credible enough to survive a steering meeting. Open each for what it buys, what it costs, and the judgement.
Move every unit onto one platform exactly as it works today
Rejected. The fastest plan to write and the easiest business case to get signed, because nobody is asked to change how they work. It produces one platform holding several incompatible operating models: asset naming, work classification and the definition of a finished job stay local, so group reporting still needs translation.
- Buys
- Speed to a signed business case
- Costs
- Disagreement becomes invisible inside one system
- Verdict
- Worse than leaving the platforms alone
Leave the platforms and build a group reporting layer over them
Rejected, and it was the tempting one. Group-level numbers without touching any site, no migration risk, a smaller first invoice. Every group answer still carries a footnote, incumbent platform costs stay, the ageing on-premises estate in the second territory still needs solving, and the group maintains one more tool to compensate for the tooling it already has.
- Buys
- Consolidated view without migration
- Costs
- Footnotes forever; decisions skew to clear reporters
- Verdict
- Right only when units must work differently
Agree one operating model first, then migrate unit by unit
Chosen. Slowest to start, and the only one that answers the question. One definition of an asset, a work type and a completed job across the group. Each unit goes live on its own date behind its own readiness gate, so a problem at one site stays at one site.
- Buys
- Comparability as a property of the data
- Costs
- Months of operating-model work before anything moves
- Verdict
- Chosen because the group was buying comparability
The sentence that decided the route
The group was buying comparability rather than a platform.
If the group had only needed a cost line reduced, route two would have been defensible. Because comparability was the purchase, route three was the only answer, and everything below is the consequence of it.
What route three required
Thirteen months, operating model before migration
Each stage carries the decision taken inside it. On a consolidation the decisions are the deliverable. Unit report variants, mobile execution and non-finance integrations stayed out of scope by written agreement.
- 01
Agree the model, write the exceptions
One asset naming convention, one work type list, one preventive maintenance approach. Local variation allowed only as a documented exception with a reason.
Owner Group asset management with unit leads Typically Before any data moved
- 02
Settle the reconciliation rule
UK division came off SAP: assets, work orders, PMs and inventory mapped onto the agreed model. What must match exactly, what may differ, and who signs, fixed before the first trial load.
Owner Named signatory per data domain Typically Pre-load
- 03
Build on the supported database
Single cloud-hosted IBM Maximo for all units. Database converted from SQL Server to IBM DB2 during the build. Incident, change and release management running before first go-live.
Owner MaxIron delivery with group IT Typically Build phase
- 04
Second territory as parallel tracks
Existing Maximo moved from on-premises to cloud in under three months as three parallel tracks (infrastructure, application, data) overlapping the main migration.
Owner Shared senior team Typically < 3 months, overlapping
- 05
Cut over per business unit
Each unit on its own date behind its own readiness gate. The second unit went live having learned from the first.
Owner Unit readiness gate owner Typically Sequenced go-lives
- 06
Enable by role, then hand over
Role-based enablement for planners, supervisors, stores and technicians. Stabilisation with the delivery team, then BAU support with service governance. Mobile and non-finance integrations deferred.
Owner Delivery team into group support Typically Post go-live
The platform the group runs
SAP EAM into one cloud-hosted Maximo
UK division data migrated from SAP; second territory moved from on-premises Maximo to the same cloud platform; group ERP carries purchase order and invoice flow.
What each box is
- Legacy SAP EAM
- UK division assets, work orders, preventive maintenance and inventory extracted once.
- Unified IBM Maximo
- Cloud-hosted, IBM DB2 converted from SQL Server, one operating model across UK and Ireland units.
- Group ERP and cloud
- Finance and purchase orders bi-directional; managed cloud replaces on-premises Maximo infrastructure.
What we would do differently
Three sequencing changes on the next group consolidation
Both dates were met. These three are sequencing rather than execution.
Data readiness before mobilisation
Only the unit that owns an asset register can decide what is still true about it. We would now run a readiness workstream with a named owner per unit before the programme mobilises.
Super-users in the mapping decisions
Bring planners, supervisors and stores controllers into mapping and operating-model decisions months earlier, so the people explaining the change at each site helped shape it.
Stagger overlapping workstreams
Both streams landed, and still concentrated two live workstreams on the same small group who understood source and target. We would separate them by a few weeks or duplicate those roles deliberately.
Where it stands now
Figures a buyer needs from this engagement
Platform
- Release
- IBM Maximo on DB2, cloud-hosted
- Database
- Converted from SQL Server during the build
- Duration
- 13 months overall; UK SAP migration eight months mobilisation to go-live
- Scope
- Implementation, migration, cloud, support
Connections and outcomes
- Finance
- Group ERP: purchase orders, invoices, cost centres
- Legacy SAP
- One-off UK division EAM extract, map and load
- Comparability
- Group planned-maintenance questions answered as a query, not a reconciliation
- Support
- BAU with service governance, problem management and release planning
Anonymised. Client-identifying systems, sites and naming removed.
If you are weighing the same three routes
Services and products in this engagement
What buyers ask about consolidating across business units
- Why is the group not named?
- Published anonymised at the client's request. A migration off an incumbent enterprise platform is commercially sensitive on both sides. We can arrange a reference call under an NDA at the right stage.
- Would you ever recommend the reporting layer instead?
- Yes, when the group genuinely only needs a consolidated view and the units have good reason to work differently, for example a regulated unit alongside an unregulated one. It is the wrong answer when units differ by habit rather than by obligation.
- Is eight months realistic for a SAP to Maximo migration?
- It was here for the UK division, and it depended on an operating model the group was willing to standardise, reconciliation rules agreed before the first load, and sequenced go-lives per unit. What usually sets duration is data readiness. See Maximo data migration.
- What happened to the maintenance history?
- It was migrated onto the standardised model, which is why mapping and reconciliation rules were agreed before the first trial load. History that lands on a model nobody agreed is history nobody trusts.
- How do you get distributed sites to adopt one operating model?
- By making local variation a documented exception rather than a silent one, and by enabling people by role rather than by application. See business process optimisation.
- Was the database conversion necessary?
- Converting from SQL Server to IBM DB2 aligned the platform with the IBM support matrix and removed the SQL Server licence line. Doing it during the build meant one set of testing rather than two. Maximo database conversion covers when we would separate them.
Consolidating across business units starts with the disagreement between them.
A short assessment that produces a target operating model outline, a data readiness view per unit, and a migration sequence with the exceptions named. Where units need to work differently, the design follows that rather than a single template.
Bring this and the assessment can be specific
- The asset registers as each business unit actually holds them today, including the spreadsheets.
- Your exit date from any incumbent platform, because that usually sets the sequence.
- The reports each unit relies on, and which of them the group actually reads.
- A named person per unit who can decide what is still true about their asset data.
- Your view of where local practice is genuine and where it is just habit.