A consultant once brought a transport for approval. Add a field to a table.
I asked what the field was for. He said that was it — just add the field. It was on the list he’d been given. So I asked what data would go into it, and what would consume the data once it was there. He didn’t know. Neither, it turned out, did the person who’d asked for it.
The change was correct. It would have transported cleanly and broken nothing.
It didn’t go, and not because he’d done anything wrong.
I’ve thought about that exchange a lot this year, because the thing that stopped it working is about to stop working generally.
What approval actually is
Here is what I do as a final approver, roughly in this order.
I want a clear description of the change and the process area it sits in. Then the scope — which company codes, which sales organizations, which divisions. I’m establishing boundaries, because most of what goes wrong later turns out to have been sitting just outside the boundary somebody drew.
Then the change itself and what it does. I have enough exposure to follow it and to ask questions. Where I’m not sure, I ask for an explanation.
Then testing, which is where the real risk lives. Not whether they tested — everyone tests. What was the scope and breadth. What was actually executed. Did anyone test for failure, or only the happy path. What are the variables. What is downstream.
Then the administrative tail, which is unglamorous and is where cutovers die. Transport status. Fields complete. Back-out plan. Impacts of moving — do we need to restart integrations, update a certificate, open the system to finish the job. Anything external.
And then organizational change. Which documents need updating, which training material, how this gets communicated, to whom.
Read that list again and notice what isn’t in it.
I never claim to read the code.
Every step is a question addressed to somebody who can be asked a follow-up. The gate isn’t an inspection of the artifact. It’s an interrogation of the account — and what it establishes is not whether the change is technically correct, but whether anybody thought about it.
That distinction sat harmlessly in the background for as long as the only way to sound like you’d thought about something was to have thought about it.
The side door
Most of the conversation about AI in enterprise systems is about agents acting autonomously. Posting documents. Executing transactions. Deciding.
That isn’t where we are, and framing the risk that way misses what’s already happening.
The thing that’s already happening is smaller and much harder to see. The person still does the work. They use AI to explain it.
Sometimes that’s a genuine gain. Someone understands more than they otherwise would have, because they asked good questions of a good tool and followed the answers. I’ve seen people come out of that exchange sharper than they went in.
Sometimes it’s a thin understanding papered over with fluent, well-structured, entirely plausible answers.
From the approver’s chair, those two are identical.
Because the gate was never measuring understanding directly. It measured whether somebody could explain — and until very recently, you couldn’t explain a change you didn’t understand. Explanation was a reliable proxy, so nobody had to think about the difference.
That correlation is what broke. Not the process. Not the workflow. The thing underneath both of them that everybody was relying on without naming it.
The questions that still work are the ones about the decision rather than the change. What did you consider and reject? Who did you have to talk to? Why this option and not the other one? The change sits in the system and anything can describe it.
The reasoning only exists if it happened.
Point it at the artifact
There’s an obvious response to all this, and it’s the wrong one: put AI on the approval itself. Score the change, recommend approve or reject, move the queue faster.
Wrong layer. And it’s the layer most of the tooling conversation is aimed at.
Go back to my list and sort it differently. Not into hard and easy — into what’s about the artifact and what’s about the decision.
Establishing the org footprint is about the artefact. Reading a test plan to work out whether failure paths were covered is about the artifact. Tracing outward from changed objects to find what consumes them is about the artifact. Transport status, field completeness, back-out plan, integration restarts, certificates — all artifact, and most of it deterministic.
Nearly the entire list is artifact.
It requires no seniority. It takes time. It’s the reason approvals sit in queues, and it’s the first thing that quietly stops happening when a date is close.
Research is everything about the artifact. Judgment is everything about the decision.
That line is the whole design. Everything on the artifact side can be assembled, cross-checked, and put in front of an approver as a brief — under two conditions, without which it makes things worse rather than better.
Every conclusion carries its evidence, traceable to the object, the configuration entry, the test result. My own gate depends on being able to say I’m not sure, explain that. A brief that can’t be interrogated has replaced a consultant I could question with a summary I can’t, which is a downgrade wearing efficiency’s clothes.
Concerns are ranked, not listed. A brief flagging forty items teaches the reader to skim it, which is a slower and more expensive version of rubber-stamping.
One item on that list deserves correcting, because most people place it wrongly and I did too. The downstream trace — what else touches this, what breaks quietly — feels like the part that needs an experienced human. It isn’t. A person can only check what they thought to check, and under delivery pressure they think to check less. That’s precisely the step a machine does better, and precisely the step most often skipped.
What doesn’t automate
Every organization has three or four people who make the difference at this gate.
Individual contributor, then manager, then back to hands-on. SME in one area, generalist across five. SAP, and everything hanging off it — the integrations, the reporting layer, the third-party systems nobody has a current diagram for.
What you’re paying them for isn’t SAP knowledge. You can hire that.
It’s three things at once. They know how a business like this one operates. They know how systems behave, and how they tend to behave together. And they know what’s actually sitting in your environment right now.
The first two travel. The third doesn’t.
You see it in a lot of places — in estimates, in what they push back on, in who they tell you to go and talk to. It’s sharpest in the questions they ask before a change goes.
Not does the field work. Anyone can check that. Something closer to: this new field is going on the sales order — which reports pick it up, which integrations have to change, and what happens when it hits the data lake?
Now notice what’s already in the system by the time that question gets asked.
The spec. The config. The test evidence. All documented, all still there in five years.
The question is the only thing the review adds. And it’s the only thing nobody keeps.
Which is backwards, when you look at it. The answer applied to one change. The questions apply to every field anyone adds from here on.
Where the learning goes
So there are two things happening at the same gate, and they pull in opposite directions.
On one side, the account arriving at your desk is getting more fluent and less reliable as a signal, because the tool that produces good explanations produces good-sounding explanations too, and you can’t tell them apart by reading.
On the other, the work that takes the time — the artifact side, the research, the cross-checking — is exactly the work that can now be assembled before anybody senior looks at it.
Those aren’t in tension. They’re the same shift arriving from two directions, and the response to both is the same.
Move the machine to the artifact. Keep the human on the decision. And then capture the questions, because the questions are the part that doesn’t survive anything — not documentation, not handover, not the end of a contract.
The research part of a review is the same in every company. Scope, boundaries, downstream, test coverage. None of it changes when the name on the building changes.
The questions are the part that doesn’t travel. Yours come from what this organisation has already lived through, and from people who won’t be here forever.
Capture enough of them and the review starts asking about the reporting layer before anybody senior walks in.
That part nobody can sell you. It only exists where it was earned.
The SAP AI Signal · signal.cogniteer.io