Abstract
Most industrial AI money has been spent looking at machines. Sensors, anomaly detection, remaining useful life, failure prediction. All of it points at the asset. But the largest recoverable losses in maintenance execution do not happen inside the job. They happen around it, in the scope, the permits, the isolation, the materials, the access, the sequencing, the shared iron and the people who did or did not know the job was coming. This paper argues that coordination is a larger and more tractable target than diagnosis, that software is now visibly moving toward that layer, and that the reason it is hard has almost nothing to do with model quality and almost everything to do with who is accountable for what was agreed.
The claim
A bearing diagnosis can save a failure. Better coordination can change every job in the plant.
That is the whole argument, and it is unfashionable, because coordination does not photograph well. There is no dashboard moment in somebody phoning the next area the day before. The industry has spent a decade building instruments that watch equipment, and comparatively nothing building instruments that watch whether the work was ready, because the equipment produces a signal on its own and the readiness does not.
But sit with where the hours actually go. A shutdown is a coordination problem wearing the costume of a maintenance event. The technical jobs are the smallest part of it. Scope, prerequisites, permits, contractors, materials, inspections, access, sequencing and emergent work all interact, and every one of those interactions is a place the day can be lost without a single component failing.
Three crews and one crane
A planned down day. Three contractor crews brought in to swap the camelback chains on the log decks, same deck, three crews, because the window had to be hit.
On paper it looked good to go. All the chains staged, torches out, crews onboard. Everything you could see was ready.
Then it came apart on everything nobody had looked at.
There was one crane, and nobody had thought about that. Three crews, one crane, so somebody is always standing around waiting to fly their chains up. They had been given two torches on the assumption three crews would share them. Competing contractors do not share. I watched them fight over the torches, unplug each other's welders, and deliberately tie up the crane so the other crews could not lift. The lockout crawled because it was three separate companies, three sets of paperwork, the whole isolation run three times over on a deck packed with bodies. Nobody had confirmed the guys were rated to run the iron they were grabbing.
And a crew that was behind and rushed cut the worst corner of the day. Instead of pulling a chain the right way, they hooked the crane straight to it, caught it on the catwalk, and ripped thirty, forty feet of catwalk out. With a camera pointed right at them. Then lied tooth and nail about it.
The chain was fine. The catwalk had to be cut out and replaced. The cost stacked: the shutdown for the safety investigation, the extra down days to finish the chains, the tear-out and reinstall of the catwalk, and the production lost working around the missing catwalk until it was back. The better part of a month before the job was truly done. Out of a day that looked good to go.
Count the failures in that story and notice what kind they are. One crane nobody clocked. Torches assumed shared. A lockout never planned for three companies. Ratings never confirmed. Not one of them is a maintenance failure. Every one of them is a coordination failure, and every one of them was knowable the day before, on paper, by somebody asking a question.
The smaller twin happened on the same site. We had planned to use the one skid steer for a waste conveyor changeout, went to do the job, and it was gone. Production had it for down-day cleanup, because of course they did, and nobody had reserved it.
After the crane day and the skid steer we built an asset reservation system and started running real down-day meetings. Not just planners. Area leads and crews too. Reserving the iron the same way we reserved the window.
What the software is now aiming at
Something changed in the vendor landscape in September 2026 that is worth noticing, because it is the first time the coordination layer has been the product rather than a feature of the product.
On 17 September 2026 Wipro launched STO360, built with Saudi Aramco and SAP, for shutdown, turnaround and outage management in asset-intensive industries.[1] It runs on SAP Business Technology Platform, carries SAP Endorsed App status, and the description of what it does is explicitly about the layer this paper is about: it consolidates inspection planning, maintenance work and execution into a single system, replacing fragmented legacy workflows, and provides "real-time visibility across activities and supports coordination between teams during planned industrial shutdowns."[1] Aramco states it intends to deploy it internally to "optimize their Turnaround and Inspection planning and execution phases by increasing the process efficiency and productivity."[1]
Be careful about what that does and does not prove. The public material is considerably stronger on workflow visibility and coordination than on what any AI component is permitted to decide or execute. Wipro's chief executive refers to "AI-led transformation" in the release, which is positioning, not a specification.[1] There is no independent result, no published outcome, no post-implementation evidence. What we have is a real product launch with a named industrial adopter, which is better than a concept and much weaker than proof.
What makes it worth a paper is the direction, not the claim. A global integrator, a major operator and the vendor whose ERP most plants already run have jointly decided that the thing worth building is shutdown coordination. That is an implicit agreement with the argument here: the money is around the job.
If it works, the questions that will decide whether it worked are not model questions. They are whether it reduces schedule variance, emergent-work delay, contractor waiting, material misses or turnaround duration, and which of those gains come from AI at all rather than from ordinary workflow digitization that anyone could have done in 2010. That distinction is going to matter, because the second thing is genuinely valuable and will be sold as the first.
The cheapest fix in the plant
Before I got into down-day planning, this happened all the time. Crews would get their locks on, walk to the job, and the parts were not there. Or nobody had told the next area their line was getting shut down. Expensive down-day time, crews idle, cannot start.
My first response was a band-aid, and I want to name it as one because it is what most people do. I kept a stash of reserved backup work orders, filler jobs with no specific window, to throw stalled crews at instead of standing idle. It became my permanent overflow stack for end-of-day work. It was useful. It did not fix anything. It converted wasted time into slightly less wasted time.
The real fix was this: start pulling the work orders the day before.
That is it. Pull them the day before, so I could confirm parts and tell the other areas ahead of time. Pre-flight the day instead of discovering the gaps live.
And it naturally grew into every area lead sitting in on the planning. Not taking over. Sitting in, because we all have the same job. It is a wonder how long that takes to sink in.
I want to be honest about how that lands in a paper about AI, because it undercuts the paper a little and it should. The most powerful fix for wasted time I have ever found cost nothing. It was communication. People expect the fix to be software or a clever process. It was plugging the comms holes.
The day-before confirmation is the line between a schedule and a plan.
The meeting that works, and why
There is exactly one meeting I have ever found useful from a maintenance perspective, and it is down-day planning. Everybody involved in the room, including contractor representation, talking the down day over top to bottom.
It is too many people. That is the point, not a flaw. If production needs the skid steer, everybody hears it, so it does not get pinched on the day. Everybody knows what is going on and everybody has a voice in it.
Two mechanics make it work. You go in with a spreadsheet of every job, circulated beforehand, so people list needs and grievances before the down day rather than discovering them during it. And it still needs a chair, because the volume of people is exactly what makes chairing non-optional.
Then there is the half that nobody builds software for. Accountability. You do not have some dink who does not read emails. Everybody in that room is accountable for what was discussed, because they were there and they heard it.
An email can be ignored and plausibly denied. A room cannot.
Sit with that sentence, because it is the hardest problem in this entire paper and it is a social problem, not a technical one. The down-day meeting does not work because information moves. It works because attendance destroys deniability. Everyone in that room has been made a witness to the same commitment at the same moment, and that is what makes the commitment stick.
What an AI coordination system would actually have to do
If the value is around the job, then a system going after it has to produce three things, and only one of them is information.
It has to surface the invisible resource. The crane, the torches, the skid steer, the lockout that has to run three times because there are three companies. These are not equipment records and they are not work orders. They are constraints that exist only in the relationships between jobs, and they are exactly what nobody wrote down. A system that can read the work list and say "three of these jobs need the same crane and they are scheduled in the same six hours" is doing something no CMMS currently does and something a good planner does in his head.
It has to make readiness a separate finding from scheduling. A job can be scheduled and not ready. Those are different states and most systems collapse them, which is how a plant ends up sending a crew to do the wrong job urgently. The day-before pull was valuable precisely because it created a moment where readiness could fail without the schedule failing.
It has to carry accountability, and this is where it will break. A room destroys deniability. A notification does not. If the system's output is another email that the area lead did not read, it has rebuilt the exact failure the meeting was invented to solve, with better formatting. Anyone selling coordination software into a plant should be asked one question: when the thing you surfaced gets ignored, what happens? If the answer is "it is logged," the answer is nothing.
There is a real design possibility here and it is worth stating so the paper is not purely sceptical. An agreement made in a room is durable but unsearchable. It exists in memory, it degrades, and it dies when the people leave. A system that captured what was committed, by whom, in the room, and surfaced it again at the moment it became load-bearing, would be adding something the meeting genuinely lacks. That is not automation of the meeting. That is memory for it, which is a different product and a better one.
What this does not claim
It does not claim the asset layer is worthless. Prediction has real value and the rest of this series spends a good deal of time on where that value is and is not.
It does not claim coordination is easy to automate. The argument is closer to the opposite: it is the harder problem, which is part of why it went unattacked while everyone built anomaly detectors.
And it does not claim STO360 works. Nobody knows yet. One product launch with a named adopter is a signal about where the industry thinks value is, not evidence that the value is there.
Conclusion
Everything visible was ready. The chains were staged, the torches were out, the crews were onboard, and the day still ended with forty feet of catwalk on the ground and a month of consequences, because of a crane nobody counted and a lockout nobody planned three times over.
That day was not lost to a maintenance failure. There was no maintenance failure. It was lost entirely in the space around the jobs, which is the space no instrument watches and no model predicts.
If industrial AI is going to earn its keep in maintenance, the largest prize is not a better estimate of when a bearing dies. It is a plant where the invisible readiness and coordination holes get counted the day before, by something that never gets tired of asking, and where what was agreed in the room survives contact with the morning.
The cheapest version of that already exists. It is pulling the work orders the day before and talking to each other. Any system that costs more than that should be able to explain what it adds.
References
- Wipro, Aramco and SAP, "Wipro launches STO360 with Aramco and SAP for outages," IT Brief UK, 17 September 2026. https://itbrief.co.uk/story/wipro-launches-sto360-with-aramco-sap-for-outages