The Orion Five Readiness Model

Integration projects rarely fail because of their main technical task. The controller can be read, the model is accurate and the dashboard is correct, but the project still fails. The cause is often elsewhere. Nobody could agree which of three identifiers referred to the same pump. The engineering laptop that programs the line was also used for email. Or, eighteen months after go-live, the person who understood the system left and there was no budget to replace them.

Each of these problems belongs to a different dimension of readiness, and the dimensions are independent of each other. A site can be excellent on four dimensions and critically weak on the fifth. For this reason, the model does not average the scores.

We give every dimension equal weight

Weighting would assume that we can compare the cost of, for example, a flat network with the cost of having no process owner. We cannot, and nobody else can either. Each dimension has three questions and scores from 0 to 9. The maximum total is 45.

The weakest dimension sets the result band

Instead of weighting, the model prevents a high total from hiding a critical weakness. If one dimension scores at or below a third of its scale, the result is capped at pilot-ready, however high the total. If two dimensions do, the result is capped at not-ready. The total only decides your position within the band.

Projects with four strong dimensions and one critical weakness are often funded, delivered competently and then abandoned. A model that averaged the scores would give such a project a respectable 80% and call it ready.

Whether there is reliable data to integrate, and whether each physical item can be matched to a record in a system.

How it fails

The integration works, but nobody trusts the data. Two systems report different production counts, because they count different things and nobody has reconciled them. Or one physical asset has three identifiers, linked only by a spreadsheet that one person maintains. Staff then stop using the system. This looks like resistance to change, but it is a sensible response to unreliable data.

What it costs to fix

Fix identifiers first, then history. Agreeing on one identifier scheme and reconciling the existing ones is routine operations work. It usually takes a few weeks and needs no vendor. You cannot buy history. If no data has been kept, start collecting now. Any system that learns from patterns must then wait a year.

What a full score looks like

One identifier scheme, applied consistently, with each identifier linked to exactly one record. At least a year of timestamped history that can be retrieved. When the system and the physical count disagree, people check the physical count.

Whether the process you want to automate is stable enough to be worth automating.

How it fails

Automation locks in an unresolved disagreement. The process varies by shift or by person, and everyone believes their version is the standard. Automating one version makes the disagreement permanent and expensive to change. Or nobody measured the exception rate, which turns out to be a quarter of cases. Most of the promised saving is then still done by hand after go-live.

What it costs to fix

Agree the process before you automate it, and count the exceptions before you price the build. Both are operations tasks, not engineering, and both are cheap. Both cost far less than a change request against a signed scope. Two weeks spent counting exceptions gives the highest return of any task before an automation project.

What a full score looks like

The process is documented and followed as documented. Exceptions are under 5%, and each type is known. Two people doing the work produce the same result.

Score your site before you ask vendors to quote

You can improve three of the five dimensions yourself, without a vendor: identity and history, process stability, and ownership. This work costs less as internal operations work than as change requests against a signed scope. It also improves the quotes you receive, because a vendor quoting for a stable process adds a smaller contingency.

Run the pilot on your weakest dimension

Most teams choose a pilot in the area most likely to succeed. That only produces a demonstration. Run the pilot where the model shows you are weakest, because that is the only area where the outcome is unknown. A pilot that fails there gives you information that a successful demonstration cannot.

Score your site again after go-live

Readiness declines over time. New equipment arrives with closed controllers, new connections appear across the network, and the owner of the last system takes on two more. Scoring the site once a year takes an hour and finds these problems while they are still cheap to fix.

The Integration Readiness Assessment applies this model as a scored questionnaire. It has fifteen questions, takes about six minutes and uses the weakest-dimension rule described on this page.