Walk into most small job shops and the real production schedule is not in the ERP. It is on a whiteboard by the supervisor’s desk, or in a spreadsheet that one person keeps updated. Jobs move by marker and eraser. Priorities change by phone call. This is not a failure of discipline. It is what high-mix, low-volume work looks like when the tools do not fit the work.
Why the whiteboard survives
A job shop rarely runs the same part twice in a row. Machines switch between customers, materials and tolerances several times a day. Setup time, not run time, often decides whether a job finishes on schedule. In that environment a whiteboard has one real advantage: it shows the whole floor at a glance, and it changes in seconds when a rush order lands.
Industry guides on shop scheduling tools put a rough ceiling on this approach: one puts the workable range for spreadsheets at under about 50 jobs a week, with error rates climbing once a shop passes 50 to 100 jobs a month. Below that line, the manual tools are honestly the more efficient choice.
Where it breaks
- A rush order lands and every downstream job silently slips, but nobody sees the ripple until a customer calls.
- Two people update the same board from memory and disagree about what is actually next.
- The plan looks fine on paper because it never checked whether the machine is free at that hour.
- A quoted job runs long, and the shop only finds out at the invoice, not on the floor.
Why generic ERP scheduling modules do not fix it
Most ERP systems answer a different question than the one a job-shop planner is asking. Their scheduling module comes out of MRP logic: it works backward from a due date and a lead time to say when an operation should start, without checking whether the machine is physically free at that moment. That is infinite capacity thinking, not finite capacity scheduling, and a job shop lives and dies by finite capacity: one machine, one job, one operator, at a time.
The result is a plan that looks complete in the system and falls apart on the floor the moment a delivery is late, a setup runs long, or a customer calls with a new priority. The planner ends up re-sequencing by hand anyway, which is exactly the job the ERP module was supposed to remove.
The planner as a single point of failure
In a shop that runs on a whiteboard or a personal spreadsheet, the schedule usually lives in one person’s head as much as it lives on the board. That person knows which customer is patient and which is not, which machine drifts out of tolerance by Friday, which operator is faster on a particular fixture. None of that is written down anywhere a report can read.
A schedule that exists only in one person’s head is not a schedule. It is a single point of failure with a whiteboard marker.
Why the stakes keep rising
The pressure on small manufacturers to prove their process, not just describe it, keeps growing. ISO surveillance audits ask for evidence that a documented process is actually followed, not only written down. Customers running their own supplier audits ask the same question in different words. For shops exporting steel, aluminium, cement or fertiliser into the EU, the CBAM carbon border rule adds a formal reporting requirement on top of that.
A schedule that lives on a whiteboard and gets erased every week leaves no record to show an auditor. A missed promise date stops being only a customer relationship problem. It can become the finding that puts a certification renewal at risk.
What a right-sized scheduling approach looks like
The fix is not a bigger ERP module. It is a scheduling layer built for finite capacity: one view of every machine, every job and every promise date, that recalculates the plan the moment something changes instead of waiting for the planner to redo it by hand.
- See every machine’s real availability, not a lead-time assumption.
- Re-sequence a job and see every downstream job move with it, in seconds.
- Keep a record of every change, so a missed promise date has a traceable reason.
- Work from data the planner already has, not a parallel system nobody keeps updated.
This is close to the problem we built Schedor to solve. Schedor is Karutek’s own scheduling product, developed and run in-house rather than licensed from a third party. It is early: the current build is a working prototype, not a finished catalogue product, and we are validating it against real shop floors before calling it done. If job-shop scheduling is the daily fight described above, it is worth a look, but it is not the only way to fix the problem. A disciplined spreadsheet with clear ownership rules can solve it for a small enough shop. What matters is matching the tool to the size and the mix of the work, not buying capability nobody on the floor will use.
Whatever a shop chooses, the underlying question does not change: can someone, at any moment, say exactly what is running, what is next, and why, and show the same answer to an auditor as they show a customer. That is the real job of a production schedule. The whiteboard did it for a while. Growth is usually what makes it stop.