The company manufactured kitchen worktops in stone and silica. Production was split across two departments: cutting, where CNC machines cut the raw slabs, and finishing, where the cut pieces were processed and prepared for delivery. As a junior, my role was to bridge the office and the factory floor — and specifically to answer one recurring question: why are orders not shipping on their scheduled dispatch date?
Every morning I held a meeting with the two production supervisors — one for cutting, one for finishing. Almost every time, the answer was the same: bottleneck at cutting, or bottleneck at finishing. Occasionally it was a delay in raw material delivery, but that was the exception.
The root cause was straightforward. The person responsible for accepting orders — who had full commercial authority — was accepting every order with the customer's requested date, without any analysis of available production capacity. There was no feedback loop between the factory floor and the order acceptance decision.
The fix did not require a complex system. The data needed to calculate cutting time already existed at the point where the technical drawing was being made — the geometry of each piece was being drawn anyway. The only thing missing was using that data to check capacity before committing to a date.
The proposed approach: at the time of technical drawing, calculate the cutting perimeter of each piece, apply the cutting speed for the relevant material, account for slab changes and set-up time, and compare the total against available machine time.
The algorithm was never implemented — I left the company before development could begin. The intended logic was the following.
When designing the components of an order, calculate the perimeter of each piece to be cut. Build a matrix of cutting speeds per material type — stone and silica have different cutting speeds, and within each there are variations by thickness and finish. Estimate the number of slabs required. Define a fixed set-up time per slab change.
Version 1.0 — hard constraint at booking
Sum the total cutting time for all accepted orders on a given day. If adding a new order would exceed available machine time, do not accept it for that date.
Version 2.0 — real-time capacity calculation
Same logic, but running continuously as orders are drawn and updated — giving a live view of remaining capacity rather than a binary accept/reject.
Not applicable — the algorithm was not implemented.
The system was never built. The specific cutting speed parameters, set-up times, and slab dimensions used at that factory are not available — they were not retained when I left. The logic described here is sound but would require calibration with real machine data before use.
There was also an organisational constraint that no algorithm would have solved on its own: the person accepting orders had commercial authority and no technical background. A tool that flags overcapacity is only useful if someone acts on it.
The inputs required to build Version 1.0 are minimal — cutting speeds per material, average set-up time, available machine hours per day. Any factory with a technical drawing step already has most of this data. The main work is the integration: connecting the drawing tool output to the scheduling matrix at the moment of order acceptance.