You have the requirements. Here is what to do with them first, and it is not buying software.
This week's edition is a departure. There is no feature to announce, and rather than stretch a quiet stretch into a release note, we want to answer a question we have been asked in nearly every conversation since the summer.
You have run the assessments. You have a ranked set of gaps, a priced business case, and two documents that came out of it: a requirements specification for the technology, and a readiness brief for everything that is not technology. So what happens on Monday?
The honest answer is that most improvement programs get this order backwards, and it costs them a year.
Start the work that does not need a purchase order
Open the readiness brief first, and start on it this week.
It is the less exciting of the two documents and it is where most of the value is. On our ExampleCo demonstration, of the value those use cases could deliver, roughly $7.10M a year is software-addressable and about $9.48M needs standard work, skills, clear ownership, and changes to how decisions get made. More than half the benefit is sitting in work that no vendor can sell you and no procurement cycle can delay.
That split is not unique to the example. Every serious analysis we have run lands somewhere near it, because the reason a measure is not moving is usually that nobody owns it, the standard was written years ago and never reopened, or the escalation path exists on paper and not in practice. Software can make those problems visible. It cannot make them go away.
So the recommendation is simple. The moment you have the readiness brief, start on it. Assign the owners. Reopen the standard. Fix the escalation. None of it requires a signature from finance, and all of it is a prerequisite for the technology working when it does arrive. A plant that installs a system into an operation with no ownership and no standard work has bought an expensive way to keep doing what it was already doing.
There is a second benefit, and it is political. By the time the technology decision reaches a steering committee, you will be able to show work already delivered against the same business case. That is a different conversation from asking for money on a promise.
Then run the technology decision from the requirements, not from a demo
Once the internal work is under way, turn to the requirements specification.
The specification matters because of where it came from. It is not a wish list assembled the week before a vendor meeting. It is generated from the same records as the value case, so every requirement in it traces back to a measure, a finance line, and an assessed gap. When a supplier asks why you need something, the answer is not a preference. It is a number.
That changes the shape of the decision, and it opens three routes rather than the usual two.
Buy. Select an existing product that meets the specification. The requirements give you an evaluation scorecard that is about your operation rather than the vendor's feature list.
Make. Build it on a platform your organisation already owns. Many manufacturers are further along here than they realise, with an industrial application platform already licensed and under-used.
Generate. This is the newer one, and it is becoming real. Given a sufficiently structured specification, application platforms are increasingly capable of assembling a working application from the requirements themselves rather than from a developer reading them. We are watching this closely, because a requirements document that is precise enough to be audited by finance turns out to be precise enough to be built from.
Most programs will use more than one of these across a portfolio. The point is to make the choice deliberately, per use case, against a specification, instead of inheriting it from whoever demonstrated most recently.
One thing worth saying about all three
We do not sell software, we do not resell it, and we are not paid when you choose one product over another. The platform's job is to tell you what the work is worth and what it has to do. Which supplier meets that specification is a decision that belongs to you.
That constraint is not modesty. It is the only reason a requirements document from us is worth anything in a negotiation.
Where to start
If you have already run an analysis, open the readiness brief and pick the three items that need no budget. Start those this week.
If you have not, the assessment is the front door, and one department is enough to see what comes out the other end.
ExampleCo is a fictional manufacturer we built to demonstrate the method. Its financial model and every calculation shown are real; the company, its people and their answers are not.