The first move should
remove work, not add it

Almost every company I walk into has a screen nobody opens. It was introduced properly — everyone gathered, the vendor explained it, people nodded. Six months later it is dead. The software was usually fine. The selection was usually fine. What went wrong was the order in which it arrived.

How double entry gets built

When a new system goes in, the old method cannot be switched off on day one. If something slips through during the change, the work stops — so both run side by side for a while. That is a sensible decision.

The problem is that nobody decides when "a while" ends. No date is set for retiring the paper. No person is named who gets to declare it retired. So the floor writes it on the board, and then types the same thing into the screen. The work went up, not down.

What the floor then says is that the system is "hard to use". This is usually not about the interface. It is a polite way of saying there are more steps than before — and that is an accurate report.

Given enough months, the board survives and the screen is abandoned. The board is needed to do the job; the screen was only needed to report on it. The necessary one wins.

The floor does not judge a system by how complete it is.
It judges it by how many steps it has today.

So the question changes

The instinct is to sequence by size of saving. That is the second criterion, not the first. The first is: whose task disappears on day one?

You find those by looking for the same information written twice; for someone who copies it into another form every morning; for the phrase "who knows where that is"; for a calculator being used at month end. There is always something removable there.

And then the crucial part: the removed task must stay removed. Before starting, decide the date the old method stops and who is entitled to stop it. Projects without that decision almost always settle into permanent double entry.

Head office gets its numbers second

Management wants data, and management is right to want it. But if that is the first move, the floor carries the cost and sees none of the benefit.

Reverse it. Remove work first, and let the data pass through the system the floor is already using for its own reasons. Information entered for the operator's own benefit becomes the report as a by-product, and nobody fills in an extra field.

This does require deciding at design time which fields will later be needed for reporting. A tool built purely for the floor, in a shape that cannot be aggregated, simply grows a second input later.

What "start small" actually means

• One process, end to end. Not half a process — the seam between an automated half and a manual half is where new steps get created
• One site or one team first. The purpose of the pilot is to find what people dislike, and there will be something
• The stop date for the old method, set before you begin. Without it, running in parallel becomes permanent
• Keep "build nothing" on the table. Often a change in sequence solves it, and the development cost is zero

Tool selection comes last

Which product to buy is the final decision, not the first. Once the process is broken down properly, the required functions fit in a few lines, and off-the-shelf software often covers them.

The reverse order — pick the tool, then bend the work to fit — does work sometimes, in young companies whose processes are not yet fixed. It rarely works where the judgement lives in one experienced person's head, because the tool has nowhere to put that judgement.