Manufacturing

Seeing a capacity clash while it is still a scheduling problem

An example use case: turning accepted work into hours against work centres, so two jobs colliding shows up when the quote is accepted rather than in the week it matters.

Example use case Specialist engineering workshop

Example use case. A worked example showing how a system of this shape would be built. Not a delivered project.

The situation this addresses

A small workshop building bespoke assemblies. Quotes live in one system, jobs on a magnetic whiteboard, and delivery promises in the sales manager’s head. Each of those is fine on its own. The gap is that nothing compares committed work against available capacity, so when two large jobs overlap nobody finds out until the week it matters.

A business in this position does not need an ERP, and buying one usually makes things worse. What is missing is narrower than that: seeing what is committed, what capacity exists, and where the two collide.

How I would build it

The first slice would be read-only, and small enough to be useful in a fortnight: pull accepted quotes from the system that already holds them, express each as hours against a work centre, and draw it on a calendar. Nothing is replaced, nothing is migrated, and if it turns out to be wrong very little has been spent finding that out.

Read-only first is the important part. It earns trust in the numbers before anyone is asked to change how they work.

Once it is being used and believed, the obvious next pieces are:

  • Editable job stages, so the whiteboard can come down.
  • Capacity by work centre, including planned absence, rather than a single headline figure that hides the actual bottleneck.
  • A forward view that flags a clash when a quote is accepted, not when the material arrives.
  • Exports for whichever reports someone is currently rebuilding by hand each month.

What I would deliberately leave alone

The scheduling decision itself. A system like this should show the collision and let a person decide what moves. Automating that decision is the fastest way to lose trust in the tool, and trust is the whole point — a forecast nobody believes is worse than a whiteboard everybody does.

Status: example use case

This is a worked example, not a delivered project, and there is no client behind it. It is here because the pattern comes up constantly in small manufacturing and because it shows how I would sequence the work: the smallest read-only slice first, and the clever parts only once the boring parts are trusted.

No figures are quoted for it, because there is nothing to measure.

More work

Got a process that is costing you hours?

Tell me what is slowing the business down. I will tell you honestly whether software is the answer, and roughly what it would take.