Capability
Artificial Intelligence & Digital Transformation
Most organisations do not have an AI capability problem. They have a selection problem, a data problem, or an adoption problem wearing a technology label. The useful first question is not what to build next, but why the last attempt stopped.
In short
The problem
Two or three initiatives have been funded. Something was demonstrated and it worked in the room. None of it is running in the business, and no one can explain precisely what stopped it — so the next proposal looks identical to the last one.
Why it matters
The cost is not the pilot budget. It is organisational appetite, which is finite: each failed attempt makes the next harder to fund and easier for the sceptics to block. Meanwhile the operational gap against competitors who selected better compounds quietly, and is difficult to close later.
Who typically needs this
- CEOs and boards who need a position on AI rather than a purchase
- COOs and plant heads carrying process cost they cannot see
- CIOs and CTOs asked to industrialise something that only ever demoed
- Compliance and quality functions under rising audit pressure
- Organisations two or more failed pilots into a programme
What we do
- AI opportunity assessment
- Enterprise AI strategy
- Use-case selection & prioritisation
- Process automation assessment
- AI governance & assurance frameworks
- Analytics & decision support
- Technology and vendor evaluation
- Pilot design and production scaling
There is a specific failure pattern we are hired to interrupt.
An organisation funds a promising initiative. It demonstrates well. Then it meets the production environment — the data that arrives dirty, the system it has to integrate with, the operator who was never consulted, the auditor who asks how the number was produced — and it quietly stops. Twelve months later the same proposal returns with a different vendor.
The technology is almost never the reason. The reasons are selection, data readiness, decision ownership and governance, and all four are diagnosable before anyone writes code.
We are a consulting firm, not a software vendor
That distinction matters here more than in any other practice. We do not resell platforms, take commission on technology selection, or hold partnerships that would make a recommendation less than neutral. When we say a tool fits, there is nothing behind the statement.
It also means our most valuable output is frequently a decision not to build. An executive workshop that stops a badly-selected programme before it is funded returns more than most implementations.
Where you do want something built, our venture Prakreon builds and operates production software for regulated environments — which is why the constraints we design against are ones we have actually met.
What you actually receive
Services describe activity. These are the artefacts that exist at the end, and that you own.
-
AI opportunity assessment
Every candidate process scored on value at stake, technical feasibility, data readiness and whether a named person owns the decision it would change. Most assessments end with more processes ruled out than in — that is the assessment working.
-
Enterprise AI strategy
A position a board can adopt: where AI is worth capital over three years, where it is not, what capability has to be built internally versus bought, and what the organisation will deliberately not do.
-
Use-case selection & business case
A shortlist with a defensible ROI model for each — benefit modelled against the decision or process it changes, not against vendor benchmarks. Including the ones we recommend against and why.
-
AI governance framework
Approval thresholds, human-in-the-loop requirements by risk class, model documentation standards, monitoring and rollback triggers, and who is accountable when output is wrong. Written to satisfy an auditor, not a conference talk.
-
Implementation blueprint
Architecture, data flows, integration points with existing systems, security and access model, and the specific operational changes required — the plan an internal team or a vendor can build from.
-
Technology & vendor evaluation
Structured comparison against your requirements with total cost over five years including exit. We do not resell, take commission, or hold partnerships that would make this recommendation less than neutral.
-
Pilot design
A pilot with success and failure criteria agreed in advance, instrumented so the result is unambiguous, and architected so a success can be scaled rather than rebuilt.
-
Scaling roadmap & operating model
What changes to move from one working pilot to production across sites — ownership, support model, retraining cadence, monitoring, and the roles that have to exist afterwards.
How we approach the work
-
We start by ruling things out
A large share of what arrives labelled AI is a process problem, a data problem, or an organisational problem in fashionable clothing. Automating a broken process makes it broken faster. The first pass is elimination, and a good opportunity assessment usually rejects more than it recommends.
-
Use cases are selected on four tests, not on enthusiasm
Value at stake, technical feasibility, data readiness, and whether a named person owns the decision it would change. The fourth is the one most often skipped and the most common cause of failure — a system that improves a decision nobody owns will not be adopted, however good it is.
-
ROI is modelled against the decision, not the technology
The question is never "what is AI worth". It is what a specific decision costs today when it is made late, made wrong, or made by the most expensive person available — and what proportion of that a system can realistically recover. Benefits are attributed to the change in the decision, and we discount claimed savings that depend on headcount reductions nobody intends to make.
-
Governance is designed before deployment
Approval thresholds by risk class, where a human must remain in the loop, what is documented, what is monitored, and what triggers a rollback. Governance written after an incident is damage control. It is also the difference between a system a regulated business can defend and one it quietly stops using.
The Use-Case Selection Matrix
Six tests applied to every candidate use case. Which test fails determines the disposition — a valuable use case with no data foundation is not ready; a use case with no owner is not a use case.
- 01
Business value
Fails → DeclineWhat does this decision or process cost today when it is made late, made wrong, or escalated to the most expensive person available?
What goes wrong without it
Without a number here, the initiative is justified by capability rather than by consequence. These are the projects that survive on enthusiasm until a budget round removes them, having consumed a year.
What resolves it
Value quantified against the specific decision or process, not against vendor benchmarks or industry averages. Where the number is small, that is the finding.
- 02
Decision ownership
Fails → DeclineIs there a named person whose job gets measurably better, and who has authority to act on the output?
What goes wrong without it
The most under-weighted test and the most common cause of a technically successful system nobody uses. A system that improves a decision belonging to no one will be adopted by no one, however accurate it is.
What resolves it
A named owner, not a department. Where no owner exists, the organisational question has to be resolved before the technical one — and sometimes that is the whole project.
- 03
Process maturity
Fails → PrepareIs the underlying process stable, understood, and worth preserving in its current shape?
What goes wrong without it
Automating an unstable process makes it fail faster and at greater scale. It also hard-codes the current design at exactly the moment it should have been questioned.
What resolves it
Fix or simplify the process first. Frequently that intervention alone captures most of the available benefit, at a fraction of the cost and with none of the model risk.
- 04
Data readiness
Fails → PrepareDoes the required data exist, arrive reliably, and is it trusted internally?
What goes wrong without it
Pilots that succeed on hand-cleaned extracts fail in production, where data arrives incomplete, late and inconsistent. This is the single most common reason a working demonstration does not become a working system.
What resolves it
Assess the data as it actually arrives, not as it appears in a sample. Where the gap is material, build the data foundation first and treat it as the project.
- 05
Technical feasibility
Fails → PrepareIs this achievable to the required reliability with proven methods, and can it integrate with what exists?
What goes wrong without it
Feasibility is usually the test organisations over-weight, and it is rarely the binding constraint. Where it does bind, the failure is expensive because it is discovered late.
What resolves it
A pilot with success and failure criteria agreed in advance, designed as the first increment of the production system rather than as a demonstration.
- 06
Governance and consequence
Fails → DeclineIf the output is wrong, what happens — and can that be contained by a human check?
What goes wrong without it
Systems deployed into consequential decisions without agreed accountability are withdrawn at the first questionable output, with no framework to resolve whether it was actually wrong. The programme usually does not recover.
What resolves it
Risk class, human-in-the-loop requirements, monitoring and rollback triggers defined before deployment. Where the consequence cannot be contained and the output cannot be explained, the correct answer is not to proceed.
How we deliver
Our full delivery model →Every engagement runs on the same model, whatever the discipline — one accountable partner, a fixed reporting cadence, a live risk register and a decision log.
AI engagements usually begin at assessment and run through to implementation and governance. Where a strategy or opportunity assessment is all that is needed, the work stops at stage four and that is a complete engagement.
- 01 Discovery
- 02 Assessment
- 03 Strategy
- 04 Planning
- 05 Implementation
- 06 Governance
- 07 Handover and improvement
- One accountable partner, end to end
- Fortnightly written reporting, including the quiet weeks
- We agree in advance what would make us recommend stopping
Who this is for, and what they arrive with
-
Manufacturing
Process and quality data that exists in volume but never reaches a decision, and maintenance regimes running on calendars rather than condition.
-
Regulated & compliance-bound organisations
Documentation-heavy processes where the bottleneck is assembling defensible evidence, and where an unexplainable output is worse than a slow one.
-
Energy & infrastructure
Forecasting, dispatch and asset performance decisions where the model has to respect physical and contractual constraints rather than pattern-match around them.
-
Government & PSUs
Service and administrative processes where automation has to work with existing systems, existing staff and procurement rules that predate the technology.
-
Large enterprises
Several disconnected pilots across business units, no shared governance, and no agreed basis for deciding which to scale.
Standards & practice
- Model documentation and traceability appropriate to audit
- Human-in-the-loop requirements defined by risk class
- Data governance, access control and retention aligned to the client's obligations
- Vendor-neutral evaluation — no resale, no commission, no platform partnerships
- We build and operate production software through our venture Prakreon — so our advice is constrained by what actually survives deployment
- Audit-grade output: systems designed so every result traces to its source in two steps
- Governance frameworks written before deployment, not retrofitted after an incident
- Vendor-neutral. We do not resell platforms and take no commission on technology selection
Questions buyers ask about this work
When should we NOT implement AI?
When the underlying process is broken — automating it makes it broken faster. When the data does not exist, is not trusted internally, or would take longer to fix than the benefit is worth. When no named person owns the decision the system would change. When the consequence of a wrong output cannot be tolerated and cannot be contained by a human check. And when a rules-based system, a fixed report, or removing three steps from the process would achieve most of the benefit for a fraction of the cost. We say this often enough that it is the most common conclusion of an opportunity assessment.
Why do most AI pilots never reach production?
Four reasons, and rarely the model. The pilot was built to demonstrate rather than to run, so it has no integration, monitoring or support model. The data that made the pilot work was hand-cleaned and does not arrive that way in production. Nobody owned the decision the system was improving, so there was no one whose job got better. Or governance was never established, and the first questionable output stopped the programme with no agreed way to resolve it.
How do you evaluate ROI on something this uncertain?
By refusing to model the technology and modelling the decision instead. What does this decision cost today when it is made late, made wrong, or escalated to the most expensive person available? What proportion is realistically recoverable, and over what period? We discount savings that depend on headcount reductions nobody intends to make, and we present the case that the investment does not clear the bar where that is the honest answer.
How do you govern AI in a regulated environment?
Approval thresholds by risk class, explicit human-in-the-loop requirements where consequence is high, documented model provenance and change history, monitoring with defined rollback triggers, and a named accountable owner for each system in production. The test we design against is simple: if a regulator or auditor asks why the system produced a particular output on a particular date, the organisation can answer without reconstructing it.
Will this work with our existing systems, or does everything have to change?
Integration with what exists is a design constraint from the first week, not a later problem. Most of our work sits alongside ERP, MES, SCADA, historians and document systems that are not going anywhere. A recommendation that requires replacing a functioning core system to proceed is usually a recommendation that has not understood the constraint.
How do you measure success?
On the decision, not the model. Agreed before the pilot starts: the specific operational metric expected to move, by how much, by when, and what would count as failure. Model accuracy is an input, not an outcome — a highly accurate system nobody uses has failed, and we would rather report that plainly than describe adoption as a change-management issue.