Vom Satzzettel über das Gemengebuch zum Tagesprotokoll

Der Satzzettel legt fest, was in die Wanne soll: welche Rezeptversion, welcher Zielsatz, welche Redox-Lage. Das Tagesprotokoll hält fest, was daraus geworden ist: welche Sätze gelaufen sind, was die Schicht der nächsten hinterlässt und ob der Tag abgeschlossen ist. Auf Papier sind das zwei getrennte Dokumente. In einer Software sollten sie das nicht bleiben.

Das Problem wirkt zunächst harmlos. Labor oder Arbeitsvorbereitung druckt den Zettel, an der Waage wird er abgearbeitet, und jemand überträgt den Verbrauch in eine zweite Liste. Das Schichtende landet auf einem dritten Blatt, oft mit Zahlen, die unterwegs gerundet oder mündlich korrigiert wurden. Am nächsten Morgen passen drei Blätter nicht zusammen, und jedes für sich ist nicht einmal falsch.

Ein durchgängiges Datenmodell verbindet Rezept, Satz, Verbrauch und Abschluss. Der Zettel ist dann der Auftrag, das Gemengebuch die Ausführung und das Protokoll der Stand am Abend. Überall steht dieselbe Rezeptversion. Ändert sie sich, gilt das für neue Sätze und nicht für die, die schon gewogen sind. So muss die Schichtübergabe nicht wieder über Kopien und Nebenrechnungen laufen.

Die Oberfläche kann dabei schlank bleiben. Am Arbeitsplatz braucht man den nächsten Satz, die Lage von Oxid und Redox und am Abend eine Übergabe ohne Zusatzzettel. Die Verbindung muss aber in den Daten liegen. Neue Masken auf getrennten Datenbeständen sehen ordentlicher aus und lösen das Problem nicht.

Das Modell lässt sich einfach testen: Kann die nächste Schicht den Tag erklären, ohne die vorherige anzurufen? Wird dafür noch ein Heft mit Nebenrechnungen gebraucht, ist die Kette nicht geschlossen.

Für die Architektur heißt das: Zeichnen Sie zuerst den Arbeitstag eines Schmelzers auf, nicht die Sitemap der Anwendung. Welche Zahl wird um sechs gebraucht, welche nach dem Wiegen, welche zum Schichtende? Die Masken ergeben sich daraus. In umgekehrter Reihenfolge entstehen schöne Formulare und dieselbe Übergabe wie auf Papier.