AI and Automation
Most firms struggle to turn AI and automation investment into measurable value. The technology is rarely the bottleneck. The operating model is.
Common triggers
The diagnostic looks at the operating model around the technology, not the technology itself. We assess governance, demand pipeline, sourcing strategy, accountability structure, and the integration into the rest of the business. Output is a heat map of what needs to change for value to flow.
The AI or automation programme has been running for twelve months and the board is asking what has changed.
A new platform investment is being scoped and the operating model around it is not yet designed.
The CIO or Chief Data Officer is technically delivering but commercial impact is unclear.
A PE thesis includes AI-enabled value creation and the portfolio company is behind the milestones.
The leadership team is divided on which use cases to prioritise.
What this is about
Boards and executives are under pressure to show value from AI and automation. The funding rounds are signed, the platforms are bought, the use cases are picked. Eighteen months later the programme has cost real money and produced limited operational change.
The pattern is consistent across firms. The technology works. The pilots run. What gets stuck is the operating model around the technology: governance, sourcing strategy, the demand pipeline that decides which processes get redesigned in which order, the accountability for outcomes, and the integration with the rest of the business.
Ambrose and Bell helps boards, investors, and leadership teams design the operating model that lets AI and automation deliver. The work is operator-led, not vendor-led. We build the operating model around the technology, and we start there.
Stephen has run enterprise automation programmes inside a multinational service business. The diagnostic is built from that work.
We build the operating model around the technology, and we start there.
AI Operating Model Diagnostic
A structured read of the operating model around your AI and automation programme. Demand pipeline. Governance. Sourcing. Accountability. Total cost of ownership. Output is a heat map of what needs to change for value to flow, with a prioritised redesign plan against it.
Four phases
1. Demand pipeline and use-case portfolio
How candidate processes are selected, prioritised, and pushed into build. This is where most programmes go wrong: the easiest wins picked first, the team exhausted before the valuable work begins. We map the current pipeline, surface the value gaps, and propose a re-prioritised portfolio with named owners and value targets.
2. Governance and accountability
Where AI sits in the organisation. Who decides what gets built. Who owns delivery. Who owns outcomes. We assess the steering forum, the decision rights, the commercial accountability, and the interface with the COO and CFO. Output is a governance redesign that survives leadership change.
3. Sourcing structure and vendor accountability
The supplier set: platform vendor, system integrator, offshore delivery partner, in-house build team. Whether contracts are signed. Whether one party owns delivery from intake to live or accountability is fragmented across the set. We map the structure, name the gaps, and propose the contract model that ends goodwill working.
4. Total cost of ownership and value capture
What the programme actually costs across platform licensing, infrastructure, integrator labour, support, and internal time. What value has been captured net of that cost, not gross of labour displaced. We baseline TCO at programme inception and reconcile against reported savings.
Outputs
Heat map
Operating model surfaces ranked by gap severity and value at risk.
Prioritised redesign list
Top processes re-ordered by net value, with sequencing and dependency.
Governance redesign
Decision rights, steering forum composition, accountability lines into COO and CFO.
TCO baseline
Programme cost picture including platform, infrastructure, integrator, support, and internal time.
Vendor contract recommendation
End-to-end accountability structure across the existing supplier set.
Board-pack synthesis
One read the board, the CFO, and the CIO can act on.
Shape
Scoped per engagement. The diagnostic stands alone. Operating model redesign and embed work that often follows is a separate engagement, agreed at the end of the diagnostic on the board's terms.
Patterns the diagnostic looks for
The operating model bottlenecks haven't changed materially between the RPA wave and the GenAI wave. The technology changes. The bottlenecks don't.
These are the patterns the diagnostic looks for. They are drag from inside the work, not strategic gaps. Each one has a way through, and in none of these cases is that way through the technology itself.
Commercial
Vendor contracts on goodwill
Suppliers are doing real delivery work without signed agreements, often because the original urgency outran the legal cycle. The firm has no contractual recourse when delivery slips, scope drifts, or a key resource is pulled. Unblocking requires a contract sweep at programme level: every vendor on signed paper before the next gateway, no exceptions.
Business case erosion under leadership change
The case was approved under one CIO and one CFO. A leadership transition arrives and the funding history does not survive the first review meeting in the new regime. Unblocking requires rewriting the case in the language the incoming leadership uses: net of total cost, separated Capex and Opex, value capture stated honestly.
Total cost of ownership blindness
Reported savings are measured against labour displaced. Infrastructure, platform licensing, system integrator labour, and lifetime support are not in the calculation. Across a portfolio the unmeasured costs often eat the benefit. Unblocking requires a TCO baseline at programme inception and a quarterly reconciliation against it.
Discovery and design
Process discovery resistance
The business does not surface the processes that should be automated because the people running them fear for their jobs. Discovery slows to a crawl, the team picks the wrong candidates, and value is left on the table. Unblocking requires a named outcome for the people in the redesigned process before discovery starts: redeployment, role change, or honest exit.
Documentation gap before build
The team starts building without a clean picture of the process being automated: which steps, which data, which people, which exceptions. The build hits the gaps mid-flight and rework compounds. Unblocking requires a documentation standard the discovery team can hit before any build kicks off, and a sign-off that gate-keeps the transition.
Designing for the unhappy path
The design covers the happy path. What happens when the automated process breaks, what the fallback is, how the failure is detected, who is alerted, and how the work is recovered, often get planned after go-live rather than before. Unblocking requires failure modes, monitoring, alerting, and manual fallback designed inside the build, not after it.
Where the automation hands off
The automated process does not run in isolation. It hands off to non-automated steps upstream and downstream, and those boundaries are where work loses integrity. Unblocking requires the boundaries mapped, owned, and instrumented before the automated step is declared live.
Delivery and security
Delivery complexity
Multi-system, multi-stage, cross-vendor builds carry coordination costs that the original plan rarely accommodates. Schedule slip compounds because no one party owns the integration. Unblocking requires a single delivery owner with authority across the supplier set, and a cadence that surfaces handoff risk weekly rather than at gateway.
IT security and change control
Change control board approval, IT security review, application owner sign-off, and penetration testing where required all have lead times that programmes routinely under-plan. Network policies designed to protect the firm slow the deploy path further. Unblocking requires the security pathway designed and scheduled at the start of the build, not discovered at the end of it.
Infrastructure split
Build and test happens in a cloud development environment. Deployment and run sit on-prem behind production change control. The two environments are not symmetric and the handover is rarely clean. Unblocking requires the deployment architecture named upfront, with the on-prem production path treated as a first-class part of the platform decision.
Application ownership and service accounts
Bots need service-account access to the applications they automate. Application owners resist on operational, audit, or security grounds and the build stalls inches from go-live. Unblocking requires the service-account model agreed at programme level, with named application owners on the steering forum from week one.
Senior pressure to demo early
Senior sponsors want to see a robot doing work to defend the funding decision. The team is asked to demonstrate live before the platform, governance, or process is ready. The demo runs, the platform breaks two weeks later, the credibility cost compounds. Unblocking requires the sponsor educated on what a credible early demo looks like and what it costs to fake one that is not.
People and run
Service team capability
Once an automation is live, it needs run-and-maintain capability inside the firm or inside a vendor contract that holds up at three in the morning. Vendor support is often fragmented across the same suppliers who built it, and accountability for a broken bot is unclear. Unblocking requires the run model designed before the build is finished: who owns the bot in production, who fixes it, who pays for the fix.
Workforce literacy around automation
The staff working alongside the automated process need to understand what is automated, what is not, and how to work around it when it behaves unexpectedly. Without that literacy, the human-bot boundary breaks under load. Unblocking requires a workforce-side communication and training plan inside the deployment, not a launch announcement.
Who it is for
This is for you if
- Automation or AI investment is not turning into measurable value and the technology is not the bottleneck.
- A programme is dragging from inside the work: discovery resistance, delivery complexity, or a run model that was never designed.
- You want the operating model around the technology fixed, not another technology pitch.
- You need an operator who has run these builds, not an advisor describing them.
This is not the right fit if
- You want an AI strategy with no operating model around it.
- You want us to build or implement the systems ourselves rather than design the model that lets them deliver.
- You want a vendor to talk up the technology.
Proof
Enterprise automation function
Function operational with a permanent team in place. Delivery pattern transferable to adjacent functions.
An embryonic automation function with no in-house capability. Most of the work sat in the operating model around it: governance, sourcing strategy, delivery rhythm, and demand pipeline.
Read the engagement → European industrial machinery clientsRobotics integration consulting
Integration roadmap signed off. Engineering teams on a defined path with a credible delivery plan.
Industrial machinery OEMs working through robotics integration into manufacturing lines, with real-time control, sensing, and integration questions to resolve.
Read the engagement →Related work
This work sits alongside the operating model diagnostic when the diagnostic surfaces AI or automation as a primary lever. It connects to programme assessment when the AI programme is off-plan and the question is whether to fix or restart. It connects to interim and fractional engagements when the firm needs an operator embedded to run the build, not just specify it.
Operating Model Transformation
The anchor service. Where AI and automation surface as a primary lever inside a wider operating model gap.
View service →Transformation Programme Leadership
For AI and automation programmes off-plan: fix or restart, governance, controls, accountability.
View service →Interim Leadership
An operator embedded in the AI work rather than an advisor describing it. Defined cadence, milestone outcomes.
View service →Engagements
Anonymised case studies showing the operating model work in practice across services and industrial sectors.
View case studies →Frequently asked questions
Talk to us about an AI or automation programme
A short conversation tells both of us whether the work fits. No pitch deck, no discovery call script.