Most automation projects start with a sentence like, "Every morning, she just pulls the report."

Then you sit beside her.

She opens three systems, changes yesterday's date in one but accounting date in another, ignores one store because its feed is always late, texts a manager about two missing deals, removes a duplicate and finally sends the number. The report was never the job. The judgment around the report was the job.

Observe before you diagram

Toyota's production-system guidance is unusually direct: before replacing work with a machine, people must be able to perform it smoothly by hand, identify abnormalities and improve the process. Toyota calls the result "automation with a human touch."

That principle transfers cleanly to dealership software. The person doing the work knows which exceptions matter. A process map written in a conference room usually captures the happy path and misses the reasons the task exists.

Build the observation sheet

For one week, record:

Lean standardized-work practice treats the current sequence as a baseline for improvement, not a commandment. That distinction matters. Automating a bad sequence makes it faster and harder to see.

Design the stop conditions first

A safe automation should know when not to continue. Examples:

The first production version can stop and ask a person. Full autonomy is not the goal. Reliable flow is.

Move through four levels

  1. Observe. Document the real work and exceptions.
  2. Assist. Compile the data while a person decides and sends.
  3. Approve. Prepare the complete action and require one review.
  4. Automate. Run the known path, stop on abnormalities and issue a receipt.

Each level should earn the next one with actual usage and a lower correction rate.

The machine is the easy part now

Modern tools can write the connector, schedule the job and draft the interface quickly. They cannot decide which exception should stop the line unless the operator teaches them.

Record the human first. The resulting document is the requirement, the training guide, the test plan and the first version of the product. That is why creativity and operating knowledge are the bottlenecks now - not the ability to produce code.

Measure the work after launch

Automation should create a better process, not merely a faster one. Track cycle time, correction rate, exceptions, missed runs and the number of times a person has to work around the system. Keep the old manual path available long enough to compare and recover.

If users build a shadow spreadsheet, treat it as evidence. They may be resisting change, but they may also be preserving a judgment the automation missed. Observe that work again before removing the workaround.

The takeaway

The process document is the first version of the software. If the store cannot explain the work, the machine will only hide the confusion.

Sources and further reading

External sources support the public facts and frameworks above. Store-level outcomes remain qualitative unless they are already published and verifiable.