Your business is constrained by foundational layers built for another era, writes former Sasol group CIO and IT expert Lungile Mginqi.
I keep walking into boardrooms where “digital transformation” and “AI strategy” are treated like a victory lap: cloud logos, ERP timelines, smart plant pictures, digital twins, data platforms, IT/OT convergence, copilots, the full catalogue. But downstairs, work still moves through emails and favours, duplicate capture, teams fight for priority, executive reports are held together via overtime, and “core platforms” remain modern only on paper. The show looks transformed, but the business is still running on the same underlying friction.
The uncomfortable truth: AI isn’t the problem, modernisation is. Most organisations aren’t modernising the business; they’re swapping systems. Buying a new CRM doesn’t modernise anything if the workflow still lives outside the system: manual approvals, shadow spreadsheets, exception queues in WhatsApp. That’s not transformation; it’s friction with a new logo.
Modernisation isn’t one thing: it’s four layers. Most “platform programmes” modernise only one layer, architecture (the runway). But the business runs on all four: service (front door), transaction (workflow), delivery (change engine), and architecture (runway). If the other three stay unmodernised, you’re just running the same friction on newer technology and calling it progress. And that misconception is exactly why so many organisations treat modernisation as a purchase order rather than a fundamental redesign of how the business works.
1. The misconception: Modernisation is a purchase order
Most modernisation conversations follow the same script:
- “Once we move to cloud, we’ll be AI-ready.”
- “Once we upgrade ERP, we can automate end-to-end.”
- “Once the data platform is in place, AI will finally work.”
- “Once we add sensors, OT will predict everything.”
It sounds logical – and it’s wrong. Yes, platform upgrades are often necessary. The mistake is treating them as sufficient. Platform work only pays off when it is tied to named outcomes and a value driver tree with measures, owners and evidence; otherwise, the business inherits the same bottlenecks, just wrapped in more expensive technology.
Value, cost and governance are shaped by how the layers interact. To see why so many efforts stall, look beneath the surface at the four layers where modernisation succeeds or fails.
2. The four layers: Where modernisation succeeds or fails
This does not mean you run four workstreams. It means modernisation fails in one of these four places, so diagnose all four, then concentrate effort where the constraint sits.
Service modernisation: fix the front door
If the front door is chaotic, you manufacture noise and cost before a single transaction starts. Service modernisation means one coherent entry point where people request outcomes (not “access”), with a catalogue in business language designed for self-service and first-contact resolution.
Diagnostic: if people still “phone a friend” to get work moving, your front door is theatre.
Transaction modernisation: fix how work actually happens
If the workflow is manual and inconsistent, you don’t just waste time; you generate bad data, hidden risk and opaque cost. Transaction modernisation means mapping the real steps (including shadow spreadsheets), stripping dead steps and duplicate capture, then automating what repeats while measuring cycle time, rework and exceptions.
Diagnostic: if you cannot show the end-to-end steps and wait states for a critical flow on one page, you don’t control it.
Delivery modernisation: change how you change
This is the political layer: ownership, funding and blame. Delivery modernisation means moving from siloed projects to value-stream owners funded against outcomes, run in 90-day slices with clear decision rights. It must change ways of work, not just relabel the org chart.
Diagnostic: if you cannot name a single accountable owner for a value stream, delivery is still theatre.
Architecture modernisation: rebuild the spine
Architecture is the quiet dictator of what is possible. Architecture modernisation means reducing debt and increasing resilience, breaking monoliths via APIs and events, designing data with context and lineage, and building in security and observability so incidents are contained and explainable. This matters even more where OT/IT coupling and safety change controls make change high-risk.
Diagnostic: if every change triggers a six-month integration saga (or a plant outage risk review), your architecture is governing you.
This isn’t a four-workstream programme. It’s a four-layer diagnosis so you can pick the constraint, lead with it and make the other layers do only the minimum required to prevent rework, inside one 90-day slice.
3. Modernisation in 90-day slices: Run the A–E Cycle across all four layers
You don’t fix this with a big bang. You fix it by choosing one value stream and running a tight A–E Cycle that forces coordinated change across Service, Transaction, Delivery, and Architecture in the same quarter.
Aim: pick one flow and one stubborn number
- Choose one critical flow that matters to the business. Set one stubborn number to move (cycle time, manual touches, downtime, rework, change failure rate) and name the value-stream owner with authority.
Build: baseline reality and the value driver tree
- On a single page, show how demand enters, how work flows, where it waits, who owns decisions, and which systems make change risky, across all four layers. Attach a value driver tree: baseline, target, measures, data sources, and owners. If you cannot measure it, you cannot govern it.
Construct: redesign the flow and the minimum viable spine
- Define the coordinated moves for this one flow: front door (service), workflow and exceptions (transaction), operating model and funding (delivery), and the minimum viable integration, data and security spine (architecture). If it is too big for 90 days, you have not sliced it.
Decide: evidence review, then a decision gate
- Replace status rituals with evidence. In Week 3, inspect what changed and what moved. In Week 4, decide Scale, Fix, or Stop, and record the decision and assumptions so the next cycle starts smarter.
Embed: make it default, then extend
- Make the new way the default for that flow (and retire the old path), then extend it to the next plant, region, store, or segment. This is where modernisation stops being a project and becomes an operating capability.
Once you run one A–E Cycle and modernise a flow, the real test is simple: did you modernise the Service, Transaction, Delivery, and Architecture for that flow, or did you just bolt new technology onto old habits? Before you approve your next AI investment, pressure-test yourself with three questions.
4. The litmus Test: Three questions before your next AI pitch
Before you move forward, pause and test your progress. Are you truly modernising, or just window dressing?
- Which single value stream are we putting through the A–E Cycle across Service, Transaction, Delivery, and Architecture in the next 90 days?
- What stubborn number will prove that value is more unavoidable, cost more legible, and IT/OT more governable as a result?
- Are we using AI to decorate an unmodernised stack, or to compound gains on a flow we have already modernised end-to-end?
If you can’t answer these cleanly, it’s not AI that’s failing you; it’s your modernisation approach. You’re trying to launch jets off a gravel road, then blaming the jet.
