Common mistakes, and how to avoid them

Implementations rarely fail because the software could not do something. They fail in a small number of recognisable ways, and every one of them is recoverable if you catch it early. Here they are, with the symptom first, because that is what you will notice.

Symptom: stock figures are close but never right, and nobody can say where the drift comes from.

Cause: goods in gets recorded because it arrives with paperwork. Material taken for a rush job does not, because someone was in a hurry. Every skipped movement is invisible on the day and permanent afterwards.

What to do: treat this as the one non-negotiable rule, and make recording physically easy where the work happens — a scanner or a tablet at the rack, not a PC in the office. Most skipped movements are a walk, not defiance.

Symptom: people complain the system is slow to use, and start batching entries up for later.

Cause: bin-level locations, serial numbers on consumables, an operation for every step. Each was individually reasonable; together they made routine work into data entry.

What to do: start coarser than feels right and tighten where a real problem justifies it. Detail you cannot sustain is worse than none, because it looks authoritative while being wrong.

Symptom: planning keeps suggesting purchases that feel wrong, and jobs finish with leftover material or unexplained shortages.

Cause: the BOM was loaded from an old drawing. The shop has built it differently for years and nobody wrote that down.

What to do: have the person who actually builds it check the recipe, not the person who has the drawing. Fix them as jobs reveal them; expect the first two months to be a correction period.

Symptom: the two disagree, and different people quote different numbers in the same meeting.

Cause: a reasonable wish to hedge until the new system is trusted. But two live records means twice the entry and no way to settle a disagreement.

What to do: pick a date, make the system authoritative from then, and keep the spreadsheet read-only as history. Hedging is what keeps the old system winning.

Symptom: when a particular person is away, nothing gets recorded properly.

Cause: one enthusiast set it up and became the only person who understands it. Everyone else asks them rather than learning.

What to do: give people the narrow permissions they need and let them own their own part. A shop-floor operator recording their own output is more reliable than one person entering everybody's, and it removes the single point of failure.

Symptom: the system is used diligently and yet nothing about the business has changed.

Cause: the daily habits stuck; the monthly review never started. Job costs and scrap trends are recorded and never read, so the insight they contain is never acted on.

What to do: put the monthly review in the calendar with a name against it. It is the step that turns record-keeping into a return.

Symptom: weeks in, nothing is live, and enthusiasm is draining.

Cause: an attempt to load the whole catalogue, every BOM, all history and every integration before going live. There is no point at which it feels finished, so it never starts.

What to do: go live on your top-moving items and their BOMs, and add the tail afterwards while running. A partly-populated system in daily use beats a complete one nobody has started.

All of them are recoverable, and the recovery is the same shape: stop, re-count, agree the one rule that was being skipped, and restart from a known-good position. A fresh stock count and a clear owner fixes most of it in a day.

What does not work is carrying on and hoping the numbers come back. They do not — drift only compounds.