Smart Production Planning

Ein Planungssystem für die Fertigung von Kontaktlinsen auf mehreren Linien. Die Monatsplanung eines Produkts hat vorher einen Planer eine ganze Woche gekostet, heute dauert sie Minuten. Die Kontrolle über das Ergebnis bleibt bei ihm.

Ausgangslage

Wir haben zu sechst angefangen, mit mir als Lead. Aus den ersten Gesprächen beim Kunden und ein paar Mockups wurde der erste MVP: ein Produkt, nach den Regeln des Kunden automatisch verplant. Damit stand fest, dass das Prinzip trägt.

Entwickelt haben wir zu dritt: einer im Backend, eine im Frontend, ich über beides. Gebaut hat jeder in seinem Feld, entschieden haben wir zusammen, bei der Oberfläche genauso wie bei der Planungslogik.

Die tragende Entscheidung

Jede Planung folgt demselben Muster: harte Regeln, die immer gelten müssen, und weiche Regeln, die man möglichst einhält. Statt jedes Produkt einzeln zu behandeln, haben wir die Architektur um dieses Muster gebaut. Sie trägt mehrere Produkte mit je eigenem, teils geteiltem Regelwerk. Die harten Regeln setzen den Rahmen, die weichen optimieren darin, und wo eine weiche Regel nicht passt, wird sie übergangen, statt die Planung zu blockieren.

Im Kern ist das ein Zuordnungsproblem unter Randbedingungen. Wir haben es mit einer gestuften Heuristik gelöst, die in einem Durchlauf einen tragfähigen Plan konstruiert. Dass es für diese Problemklasse fertige Solver gibt, war uns damals nicht bekannt. Heute würde ich einen evaluieren. Für eine Anlage und einen Monat hat die Heuristik gereicht.

Nicht größer bauen als nötig

Das System ist ein modularer Monolith. Wohin sich das Produkt entwickeln würde, war offen, und Ergebnisse beim Kunden zu verifizieren wog schwerer als eine Architektur für einen Bedarf, den es vielleicht nie geben würde. Klare Grenzen zwischen den fachlichen Bausteinen brauchten wir, Verteilung über viele Maschinen nicht.

Ausgezahlt hat sich das an zwei Stellen. Jede Regel war eine eigene Einheit und einzeln testbar, was in einem System zählt, dessen Fehler in echter Fertigung landen. Und eine weitere Anlage ließ sich später in kurzer Zeit ergänzen, weil die Regeln wiederverwendbar waren und nur die Besonderheiten dazukamen.

Was daran schwer war

Die Regeln lagen in den Köpfen der Planer. Vieles wussten sie nur implizit und sagten es nicht von selbst. Erst über enge Iteration und ein striktes Scrum kam diese Logik nach und nach heraus.

Dazu musste der Planer die Kontrolle behalten. Das Ergebnis eines Algorithmus allein reicht nicht, denn er muss auf einen Blick sehen, ob alles zu seiner Zufriedenheit verplant ist, und selbst nachbessern können. Ein großer Teil der Zeit ging deshalb in eine Oberfläche, die genau das leistet. Harte Regeln kann der Algorithmus konstruktionsbedingt nicht verletzen, vor dem Export prüft der Planer. Wo die Oberfläche im Weg stand, haben wir gesehen, indem wir den Planern beim Kunden bei der Arbeit über die Schulter geschaut haben.

Meine Rolle

Von der ersten Aufnahme beim Kunden bis in den produktiven Betrieb dabei, als Lead und als Entwickler. Ich habe beim Kunden verstanden, wie die Planer tatsächlich arbeiten, und das ins Team getragen, bis daraus mit Entwicklung, Design und Fachbereich eine Lösung wurde, die alle mittragen. Übergeben habe ich das Projekt, als es täglich produktiv lief. Was danach dazukam, baute auf dieser Grundlage auf.