How an entrenched systems dispute was solved – not by force, but by understanding the real work
A few years ago, I was asked to step into a problem that had been simmering inside a major defence shipbuilding organisation. The company had recently acquired a Combat Systems department, and on paper the integration should have been straightforward. In reality, it had created a structural fault line.
The two divisions were running on fundamentally different ERP systems.
- The Ship Builder relied on Aveva ERM, a system built for the vast choreography of ship construction — thousands of work orders, long lead items, fluid sequencing and continual re-planning.
- Combat Systems, by contrast, lived in SAP — ideal for short, high-tech, iterative engineering projects where teams move on and off rapidly, and design evolves week by week.
The consequence?
Every month, the finance teams had to manually reconcile two incompatible worlds. It burned time, created errors, and caused constant tension between the divisions. The CEO, understandably exasperated, issued a directive: Combat Systems must abandon SAP and adopt Aveva ERM.
On the surface, it sounded decisive. In practice, it would have been disastrous.
Understanding the Real Difference
Once engaged, I spent time with both sides. It was immediately clear that the issue wasn’t political reluctance — it was functional reality.
- Shipbuilding demands large-scale orchestration.
- Combat Systems demands high-frequency agility.
Forcing Combat Systems into Aveva ERM would have crippled their ability to deliver rapid design changes, small projects, and high-tech increments. Conversely, moving Ships onto SAP would have broken the cadence of ship construction.
The company wasn’t dealing with resistance to change; it was dealing with two fundamentally different production logics.
A Simple, Overlooked Fact Changed Everything
Rather than arguing theoretical benefits, I asked both ERP vendors — Aveva and SAP — to sit down together. When we laid the systems side by side, one fact immediately stood out:
Aveva ERM is not primarily a finance system. Its finance module is optional.
This was the breakthrough.
If Aveva ERM wasn’t tied to the finance architecture, then the problem wasn’t “Which ERP should win?”. The problem was:
Which system should own finance, and which should own work control?
Once reframed, the solution revealed itself.
The Integrated Solution
We designed a hybrid architecture that preserved the strengths of both environments:
- Shipbuilding kept Aveva ERM for all ship-level work orders and planning.
- Combat Systems kept SAP for their engineering-centric project management.
- SAP became the single finance system across both divisions.
- Integration replaced reconciliation — the two systems exchanged the right data automatically.
No division had to surrender its operational backbone. Finance could finally see a single, consistent picture. The monthly reconciliation exercise — which consumed enormous time and caused repeated friction — was eliminated entirely.
Planning the Transition: Moving Ships onto SAP Finance
Once the preferred architecture was agreed — SAP for finance, Aveva ERM for ship-level work control – the next challenge was designing a safe and realistic implementation plan. Moving Ships onto SAP Finance was not a technical “lift and shift”. It required careful orchestration across processes, people, data, and timing.
The key constraint was the year-end financial cutover. SAP migrations of this nature can only be executed cleanly at a financial boundary, so all planning worked backwards from that immovable milestone. The first step was a detailed mapping of the Ships chart of accounts, cost centres, project structures, asset registers, and open commitments into SAP’s financial architecture. This was not a one-to-one translation. Shipbuilding carries unique patterns — multi-year work packages, batch material flows, standing construction teams, and earned-value mechanisms — which SAP needed to accommodate without breaking operational cadence.
We then constructed a phased testing plan to ensure financial accuracy under live conditions. Three consecutive month-end rehearsals were scheduled, each one using progressively cleaner data and tighter reconciliation tolerances. In parallel, workstreams were launched to align time-recording, expenses, and procurement processes so they would feed SAP in a consistent format. This included harmonising MyOptions shift patterns, creating new approval workflows, and establishing interim interfaces to ensure continuity while the systems ran in parallel during migration.
Finally, we prepared the organisation for the change. Ships had long operated its financial rhythms through CODA and bespoke warehouse tools, so the shift to SAP required targeted training, updated procedures, and a revised governance model for forecasting, change control, and project reporting. The rollout plan deliberately sequenced functions to minimise disruption: finance first, then project controls, then material planning. By the time the cutover arrived, SAP had been rehearsed repeatedly, the datasets had been cleansed and reconciled, and every process owner understood their role on day one.
The result was a controlled, predictable transition. Ships gained a modernised finance backbone capable of supporting consolidation, real-time reporting, and tighter alignment with Combat Systems — without destabilising the shipbuilding tempo that keeps major programmes on track.
Outcome
The impact was immediate and lasting:
- No more manual alignment between two incompatible finance structures
- Improved accuracy and visibility of project cost performance
- Fewer delays in invoicing and month-end reporting
- Better working relationships between Shipbuilding and Combat Systems
- Redeployment of finance staff from low-value reconciliation to high-value analysis
- A scalable model that respected both domains’ realities rather than forcing uniformity
This wasn’t a technology win — it was an organisational one.
By respecting the nature of the work, rather than forcing a top-down directive, we enabled an integration that actually worked.