What happens after the demo

The demo went well. It usually does. That is worth taking seriously rather than explaining away, because the reasons a demo succeeds are real reasons and they tell you what the rollout is missing.

Why does the demo work?

It was not a trick. The data was real, pulled from real systems. The answer was right. The room was correct to be impressed.

Now name what else was in the room. Somebody chose the example, and they chose one they understood. They knew which of four systems held the true version of that record. They knew that this particular customer is invoiced differently for historical reasons nobody has written down. If the answer had been wrong, they would have seen it in half a second and quietly moved on to the next question.

What is the demo borrowing?

Six things, in roughly the order they break at scale.

1. 01Object identity. Which real thing this is, across systems that name it differently. In the demo one person resolved it. In production nobody does, and the same job exists three times under three identifiers.
2. 02Ownership. Who is accountable for this object right now, as opposed to who was listed as the owner when it was created.
3. 03State. Where the object sits in its lifecycle, and what that permits. Closed, on hold, awaiting approval and in progress are not decorations on a record. They are the rules.
4. 04Exceptions. The cases everybody in the room knows about and nobody has written down. Every operational business runs on a body of exceptions that lives entirely in people.
5. 05Scope. How much was in the demo. One department, one month, one project. The behaviour of a system on a slice is not evidence about its behaviour on the whole.
6. 06Judgement. Somebody was checking. In production the checker is the person receiving the answer, and they do not have the context to check it.

Do we need to clean our data first?

The consensus answer is yes, and it has real evidence behind it. Gartner predicted in February 2025 that through 2026 organizations would abandon 60 percent of AI projects unsupported by AI ready data, and reported that 63 percent of organizations either lack appropriate data management practices for AI or are unsure whether they have them. That survey ran with 248 respondents, and both figures are worth knowing.

It is also worth noticing who gives this advice most loudly. Data cleaning is sold by people who sell data cleaning, and the recommendation is commercially convenient for almost everyone making it, ourselves included when we are careless.

A company with forty years of accumulated systems that starts by cleaning them will still be cleaning them in three years, and the definition of clean will have moved twice. The work is real, but as a precondition it is a counsel of despair.

A structured model has the completion criterion that cleaning lacks. When the central operating object is named and the organization has agreed what has to be true about it, what is missing becomes a specific, finite and boring list: this system does not hold an owner, that one has no lifecycle state, these two disagree about identity. That list can be worked through and finished, and most of it turns out not to matter for the decisions anyone actually wants to make.

You do not need clean data. You need an agreed structure sitting above the data you already have, and the structure tells you which parts of the mess are load bearing.

What changes between a pilot and a system of record?

How do you know it is working?

If success is defined as somebody remarking that it helped, you will get remarks. People are generous about new tools, particularly ones their executives are enthusiastic about. That is precisely the failure mode that produced the most quoted and least reliable statistic in this field.

Define success before, in the units the business already runs on, over a window somebody agreed to in advance. Days to close a period. Percentage of variations captured in the month they occurred. Hours between a site event and its appearance in the record.

That gap is the whole reason measurement matters. Regular use in one function is easy to reach and easy to mistake for progress. Scaling is the thing that does not happen by itself, and the two are far enough apart that a company can spend two years in the first and believe it is on its way to the second.

For a counterweight: Google Cloud's third ROI of AI study, published 28 July 2026 with 2,403 respondents, reports that 84 percent of executives see increasing returns from AI while only 26 percent see returns accelerating. It is a cloud vendor surveying its own market and the returns are self reported, so treat the level with caution. The shape is the interesting part: returns are common, compounding is not.

Who owns it once it is live?

The structure has to be maintained by whoever is closest to the work changing. When a new contract type appears, when a department reorganises, when a subsidiary is acquired with its own way of numbering jobs, somebody has to decide what that means for the model. If that person is a vendor, the model goes stale the day the engagement ends.

Which means somebody has to sit inside the organization until that ownership is real, rather than delivering a system and leaving. That is a service commitment before it is a technical one, and it is how we work.

What to build before the rollout, not after

1. 01The central operating object, and one agreed identity for it across every system that holds a version.
2. 02What the object has to connect to for the decisions people actually make, and what turns out not to matter.
3. 03The lifecycle states, and which transitions between them are legal.
4. 04The exceptions, written down, including the ones that only one person knows.
5. 05The definition of success and the window it is measured over, agreed before anything starts.
6. 06The owner, by name and by role, who decides what a change in the business means for the model.

This list does not depend on which vendor you choose, or on whether you build it yourself. It is the same list either way, which is a good sign that it is the real work. The object at the centre changes by sector and what the organization needs to know about it does not, which is the argument the model rests on.