Smart Production Planning

A planning system for making contact lenses on several lines. Monthly planning of one product used to cost a planner a whole week; today it takes minutes. Control over the result stays with him.

Where it started

We started as a team of six, with me as lead. Out of the first conversations at the client and a few mockups came the first MVP: one product, planned automatically by the client’s rules. That settled it: the principle holds.

We developed it as three: one on the backend, one on the frontend, me across both. Everyone built in their own field, but we decided together, on the interface as much as on the planning logic.

The decision it rests on

Every plan follows the same pattern: hard rules that must always hold, and soft rules you keep to where you can. Instead of treating each product on its own, we built the architecture around this pattern. It carries several products, each with its own, partly shared, set of rules. The hard rules set the frame, the soft ones optimize within it, and where a soft rule does not fit, it is passed over rather than blocking the plan.

At its core this is an assignment problem under constraints. We solved it with a staged heuristic that constructs a workable plan in a single pass. That ready-made solvers exist for this class of problem was not known to us at the time. Today I would evaluate one. For one line and one month, the heuristic was enough.

No bigger than it needed to be

The system is a modular monolith. Where the product would go was open, and verifying results at the client weighed more than an architecture for a need that might never arise. We needed clear boundaries between the business building blocks, not distribution across many machines.

That paid off in two places. Each rule was its own unit and testable on its own, which counts in a system whose mistakes end up in real production. And another line could later be added in short order, because the rules were reusable and only the specifics were new.

What made it hard

The rules sat in the planners’ heads. Much of it they knew only implicitly and did not volunteer. Only through tight iteration and a strict Scrum did that logic come out bit by bit.

On top of that, the planner had to keep control. An algorithm’s result on its own is not enough, because he has to see at a glance whether everything is planned to his satisfaction and be able to correct it himself. A large part of the time went, for that reason, into an interface that does exactly that. Hard rules the algorithm cannot violate by construction; before the export, the planner checks. Where the interface got in the way, we saw by watching the planners at work at the client, over their shoulder.

My role

There from the first intake at the client through to production, as lead and as developer. At the client I understood how the planners actually work and carried that into the team, until, with development, design, and the business side, it became a solution everyone stands behind. I handed the project over when it was running in production every day. What came after built on that foundation.