Data readiness
The redesign is only as good as what the organization can actually know.
A workflow redesigned around AI depends on information being there, being right, and meaning the same thing everywhere. Most of the time nobody checks that until the build has started. We check it as part of reading the work, against the workflows already on the table — and we tell you what a gap is costing you before you spend against it.
Why this stops programmes
Three ways a redesign meets the data problem, all of them late.
None of these are data quality problems in the abstract. They are specific things a specific step needed to know.
It was in someone's head
The step ran fine for years because an experienced person carried the context. Nobody wrote down why a case was rejected, or what made an account risky. The redesigned step cannot ask them. The information was never captured, because until now it never had to be.
Three systems, three answers
Two functions have argued about the same number for years and both are right, because they are counting different things under one word. Automate the step and the disagreement stops being a meeting and starts being an output nobody trusts.
Right answer, no working
The step produces the correct result and nobody can reconstruct how. That is survivable while a person signs it. It is not survivable at a step an auditor, a regulator or a board committee will ask about — and that is usually the step worth automating most.
We do not ask whether your data is good. That is an argument about your organization that you would win. We ask whether this workflow can run on what you can produce, which has an answer.
What you get
Four things, all running off one model of the work.
Underneath them sits the same thing: what each redesigned workflow has to know, written in the workflow's own words. Each of the four stands on its own. Each is worth more with the others.
The readiness verdict
Per workflow: can this run on what you can actually produce, and if not, precisely why not. Rolled up from every dependency at every step, with confidence and source on every score. This is what decides whether a workflow enters the first wave, whatever it is worth.
The definitions register
The words the workflow runs on — active customer, qualified, at risk, complete — each defined once, with the systems holding a version of it and the places those versions disagree. It settles arguments that have run for years between two functions who were both right and counting different things.
The gap ledger
Every gap, the check it failed, the share of workflow value it holds up in a range, what the fix is, who does it, how long. Ranked by the value it holds up — then by how long the fix takes. Pull on any row and you reach the record behind it.
The fix
The gaps closed, to a specification we wrote, tested against acceptance criteria we set. We bring the specialist capability that executes it and we supervise it. If the gap is not closed, that is ours to answer for.
And it stays true. Definitions drift, systems change, the business adds products, and a picture that was right in January stops being right in April. The data picture is recalibrated on the same cadence as the rest of the work.
What gets assessed
One thing a redesigned step has to know.
We read the future-state workflow and write down each thing a step depends on, in the step's own words — the credit step has to know the customer's current exposure across every product, at the moment it decides — not as a table name. Then each one is checked.
Three rules keep the list honest. It is read off the future state, not today's, because a step a person runs today may be carrying information in their head that the redesigned step cannot. It includes what the oversight needs, not only what the work needs — if a human checks the step, the thing they check is a dependency. And it stops at the edge of the workflow. What the next workflow needs is that workflow's problem, recorded and left there.
The six checks
Every dependency, checked six ways.
In the order a person would actually ask them. Any one of the six can stop a workflow on its own.
Checks five and six are the ones most assessments skip, and the two that most often stop a redesigned workflow after it goes live rather than before.
How it is scored
Three verdicts, and the line between two of them is the whole thing.
Ready
If the redesigned workflow went live on Monday, this would not be the reason it failed.
Fixable
Someone can say what the work is, who does it, and roughly how long it takes. Bounded work, scoped inside the transformation, quoted separately with its boundary written down.
Blocking
Either nobody can say what the work is, or it is a platform, integration or governance programme in its own right. That runs on your timetable, and the redesign sequences around it.
The line between fixable and blocking is whether the work can be named and bounded — not whether it is hard, and not whether it is expensive. That is the same line as the boundary between what we take on and what we will not pretend to. A workflow that scores badly is a finding, not a failure: it is often the most valuable thing the two weeks produce, because it stops you spending on a redesign that could not have run.
What the block is costing
A gap list is not a decision. A gap with a number attached to it is.
Each workflow already carries what it is worth — its loaded cost today, and the value of compressing its cycle time — because the same two weeks produce that. So a dependency that blocks a step holds up a knowable share of that value, and it is written down that way: in a range, with the assumptions on the surface, never as a point estimate.
Which changes how the gaps are ranked. Not by how broken they are — by the value they hold up, then by how long the fix takes. A badly broken field on a step worth very little is a low-ranked gap, and saying that out loud is part of what you are paying for.
Then it feeds the sequencing decision, which is where it belongs.
What it takes from you
About four hours, across two people.
It runs inside the two-week diagnosis, against the workflows already in scope. It is not a separate engagement and we do not sell it as one.
What we ask for
- A walkthrough of where the information actually lives.
- Samples of real records, where you are able to share them.
- Ninety minutes from a systems owner, sixty from them and your operational lead together.
What we do not ask for
- Warehouse access. We do not connect to anything.
- A data extract, or a data project before we start.
- Your team's time cleaning something up so the assessment looks better. That defeats the assessment.
Who carries it
We own the data readiness of the workflows in scope. Not a handover.
You have one counterparty for this and it is us — through the assessment, through the fix, through the workflow actually running. Specialist capability comes in to a specification we wrote, works inside our engagement, and is supervised and signed off by us. What follows is who puts their hands on which work, not who carries the consequence.
We are accountable for
- The dependency list for each redesigned workflow, in plain words.
- The six checks scored, with confidence and source on every verdict.
- Gaps ranked by the value they hold up and how long the fix takes.
- What has to be true before the workflow can run, and what that changes about sequencing.
- The gaps actually closed, tested against acceptance criteria we set.
Executed by specialists we bring
- Pipeline build, integration, migration, data engineering.
- Data governance design, model risk management, security.
Our resource, on our specification, supervised by us. You do not manage them, contract with them, or chase them.
Outside the scope
- Building or re-platforming your data estate.
- Systems integration beyond the workflow in scope.
- Vendor and tool selection.
A boundary on what work is in the engagement — not a gap in who carries it inside.
The questions we get
Said the way people actually say them.
Q01"We need to fix our data before we can do any of this."
Q02"Our data is a mess. You will just tell us that and leave."
Q03"Can you just do the data piece?"
Q04"Four hours sounds too short to understand our data."
Q05"Our systems owners will tell you it is all fine."
Q06"What does the remediation cost?"
Where this sits
The work, the data and the people move together, or the redesign does not run.
The work has to be redesigned around what AI can actually do. The information those workflows depend on has to exist and be trustworthy. And people have to understand what is changing and why. Any one of the three left out is where AI programmes stall — and the reason data sits inside the engagement rather than beside it is that the same evidence answers all three.
Not sure your data can carry a redesign?
Not a sales meeting. A conversation about whether this addresses a problem you recognize in your organization, and what you would need to see to hold the answer under scrutiny from your CFO and your board.
Rajeev, who runs the engagement. Not a qualifier.
Bring one workflow you already know is painful. We trace it one or two layers out loud with you, tell you what we would need to see to answer it properly, and say what we could not answer.