Workshop parts: a stockroom is a ledger you can walk into

Walk into most fleet workshops and you can point at the parts cage before anyone tells you where it is: the shelving is denser, the labels are older, and somewhere near the door there is a clipboard, a whiteboard, or a half-filled spreadsheet that is supposed to be the record of what is on the shelves. It rarely agrees with the shelves. Not because anyone is careless — because the moment a part is actually consumed is the worst possible moment to ask a technician to also update a ledger.

The count is wrong because of when it gets written down

A brake pad set comes off the shelf at the exact point in a job where the technician’s hands are dirtiest and the truck is due back on the road soonest. Writing it down then competes with finishing the job, and it loses. So the write-down gets deferred — to the end of the shift, to the end of the week, to “whenever someone does a stocktake” — and in the gap between the part leaving the shelf and the record catching up, the stockroom is running on a number nobody currently believes.

That gap is the whole problem, and it is not a discipline problem. Recording consumption at annoyance-time — mid-job, hands full, truck waiting — asks people to absorb friction at the worst possible moment, every time, for the life of the workshop. Recording it at use-time only works if the record updates as a by-product of something the technician was already doing, not as an extra step bolted onto it. A work order that already lists which parts a job needs, and lets the technician tick off what was actually taken against it, moves the record-keeping to a moment that already existed rather than inventing a new one.

Tying parts to the job that used them

The reason a parts ledger drifts even when someone is diligent about recording issues is that “recorded” and “accurate” are different claims. A part taken off the shelf and logged against the wrong work order, or logged as a quantity of one when two were used, produces a ledger that looks maintained and is still wrong — and a ledger that looks maintained is the one nobody double-checks.

Binding consumption to the specific work order it belongs to closes part of that gap for a reason that has nothing to do with honesty: a work order already carries the vehicle, the fault, and usually the parts a similar job has needed before, so the technician is confirming a short list rather than recalling one from memory at the shelf. It also means the cost of a repair is known at the moment the repair is finished, not reconstructed weeks later from a stack of paper slips — which matters more than it sounds, because a fleet that cannot say what a given repair actually cost cannot tell a recurring fault from a one-off, or a technician’s estimate from what the job really took.

Reorder points that know how long a part takes to arrive

A stock ledger that is accurate but naive about lead time still leaves a truck on a ramp. A reorder point set as a flat number — “order more when we have three left” — is really a bet about how many of that part get used before a replacement arrives, and the bet is only as good as the assumption about how long arrival takes. A fast-moving filter with a same-day local supplier and a slow-moving part sourced from a manufacturer’s regional warehouse cannot share the same rule without one of them being wrong most of the time: the filter sits overstocked, tying up shelf space and cash, while the slow part runs out mid-repair on the one week demand ticks up.

The fix is not a cleverer formula so much as an honest one: a reorder point that reflects how long this part actually takes to land, multiplied by how fast it is actually consumed, rather than one number applied to a shelf of parts with wildly different supply chains behind them. Getting that right is less about the arithmetic and more about having the consumption history to base it on — which only exists if the ledger above was accurate enough to trust in the first place. The two problems compound: a sloppy ledger produces a bad reorder point, and a bad reorder point either wastes money on a shelf or grounds a vehicle, and either way the workshop loses faith in the numbers and goes back to the whiteboard.

The cage stays honest only if the ledger is the easy way

None of this holds if the correct way to record a part is also the slow way. A technician choosing between “log it properly” and “grab it and tell someone later” will, reasonably, pick whichever is faster when the truck is booked to leave in ten minutes — and a system that makes accuracy the harder path is training people to build the workaround it exists to prevent. The stockroom that stays honest over months, not just on the day after a stocktake, is the one where scanning a part against the work order already open on a phone or a tablet is quicker than walking to the clipboard, and where a technician never has to reconstruct at the end of the week what they used and on what.

That is also why a stocktake correction has to be allowed to just be a correction. A shelf count that disagrees with the ledger is real information — damage, a supplier short-ship, a part quietly borrowed for another vehicle — and the fix is to reconcile the ledger to what is actually on the shelf, not to treat the physical count as the thing that must be wrong. A system that resists an honest correction teaches people to stop counting.

Where navichain stands

navichain keeps warehouse goods and workshop parts on one set of shelf figures rather than two disconnected spreadsheets pretending to agree, and takes parts off the shelf against the work order that used them as the job is closed, not as a separate stock-taking exercise afterwards. Work orders run from open to closed with their parts, and purchase orders, workshops and parts inventory sit in the same place rather than three tools that each believe a different number is correct. The platform page covers what that looks like alongside the rest of fleet and workshop management — maintenance scheduled on distance or on the calendar, per maintenance type, so the reorder conversation and the service-due conversation are informed by the same data instead of two separate guesses.