NOBODY NEEDS
MORE TRAINING ON
THE SOFTWARE.

01

THE CONVERSATION
WE KEEP HAVING.

An owner tells us they already tried this. They bought the system. It was not cheap. Everyone sat through training, twice, because the first round did not take. The consultant left. Eighteen months later the company is still paying the licence, people are still logging in, and the number the owner actually trusts comes out of a spreadsheet one person maintains by hand.

Then they say the part we hear almost word for word every time. My people just will not use it.

We have never once found that to be true. People use whatever gets the job out the door. If they are going around the software, the software is asking them to do the work in an order the work does not happen in.

Adoption is not a willingness problem. It is a sequencing problem.

02

THE SECOND SYSTEM
NOBODY MENTIONS.

Every company we have looked inside is running two systems. There is the one that was purchased, and there is the one the work actually moves through. The second one is never on the invoice and nobody calls it a system, but it is doing the heavier job.

It looks different in every building. A whiteboard that is photographed at the end of a shift. A group text where schedule changes really happen. A notebook in a truck. A shared drive folder named after the person who made it. A spreadsheet that has been rebuilt four times and still ends up as the thing the owner opens on Monday morning.

The second system exists because it is faster, because it tolerates the exception, and because it never rejects an entry for being incomplete. Those are not bad qualities. They are the reasons it won.

So when we are told adoption failed, the first thing we go looking for is not the software. It is the second system. It tells us precisely what the software got wrong, in the order it got it wrong.

03

TRAINING TEACHES THE BUTTONS.
IT DOES NOT MOVE THE WORK.

Training is built on an assumption: that the process is correct and people simply do not know where to click. Sometimes that is true. Usually it is not.

What we find instead is that the software expects a job to be fully specified before it starts, and in real life half of it gets specified while it is already on the floor. Or it expects one person to own a step that three people genuinely share. Or it requires a field at the start that is only knowable at the end. Or it makes the exception, which is thirty percent of the work, harder than the normal case.

None of that is fixed by a second training session. You can teach somebody the buttons for a sequence that does not match their day, and they will learn the buttons and then go back to the sequence that works.

If the correct way is slower than the workaround, the workaround is not a discipline problem. It is a design verdict.

04

WHAT WE DO
BEFORE WE TOUCH THE SOFTWARE.

We map the work as it actually happens. Not the version in the handbook, and not the version described in a meeting. The real one, including every point where somebody has to ask somebody else, and every point where a decision gets made that was never written down.

That map almost always shows the same thing: the company does not have a software problem at the step everyone is complaining about. It has an unowned decision three steps earlier, and the complaint is just where the consequence became visible.

Once the sequence is right, the software question gets much smaller and much cheaper. Sometimes the system they already own turns out to be fine and only configured backwards. Sometimes two tools collapse into one. Sometimes we build a thin piece that sits between what they have and how they work. We would rather do that than sell a replacement, because a replacement inherits the same sequencing problem and the company gets to discover that twice.

05

THE COST OF CALLING IT
A PEOPLE PROBLEM.

There is a practical reason to be careful with the phrase. The moment a company decides adoption failed because of attitude, three things follow and all of them are expensive.

It stops looking at the design, because the diagnosis is settled. It spends money on more training, which is the one intervention the evidence in its own building has already rejected. And it quietly stops trusting the people who know most about how the work really runs, which is exactly the group whose cooperation any fix is going to depend on.

We have walked into companies where the most useful person in the building had been written off as resistant to change. They were not resistant to change. They were the only one who could still explain why the official sequence does not survive a short week, and they had stopped volunteering it because the last two times they did, it was heard as a complaint.

The person working around the system is usually the person who understands it best. They have tested it against a real week.

06

ONE QUESTION
WORTH ASKING THIS WEEK.

You do not need us for this part. Pick the number you rely on most, and trace it backwards to where it is first entered by a human being. Count the hands it passes through and count how many of those hands open something that is not the system you paid for.

If the answer is none, the adoption is real and the problem is somewhere else. If the answer is two or three, you have not bought the wrong software. You have bought software that was never shown the work.

Nobody works around a system that is faster than working around it.