Über die tatsächliche Gewinnmarge eines Fertigungsauftrags entscheidet sich meist während der Schicht, doch kaum ein Werk kann sie sehen, solange die Schicht läuft.
Der Shopfloor weiß, ob die Linie läuft, ob ein:e Bediener:in am Platz ist und ob die Stückzähler weiterzählen. Das Controlling weiß, was eine Überstunde kostet und zu welchem Preis ein Auftrag angeboten wurde. Beide Seiten haben Daten. Sie liegen nur in verschiedenen Systemen mit unterschiedlichen Aktualisierungsraten und werden meist erst beim Monatsabschluss zusammengeführt, zwei Wochen zu spät, um an einem schlechten Tag noch etwas zu ändern.
In diesem Beitrag versuchen wir zu skizzieren, was nötig wäre, um diese Lücke zu schließen.
Die Auftragsmarge (für alle, deren Woche damit nichts zu tun hat) ist der Deckungsbeitrag eines einzelnen Fertigungsauftrags: der Preis, den der Kunde gezahlt hat, abzüglich Arbeit, Maschinenzeit, Material und Gemeinkosten, die der Auftrag tatsächlich verbraucht hat. Üblicherweise wird sie im Finanzbereich monatlich aus verbuchten Journalbuchungen ermittelt. Die interessante Frage ist, ob sie sich stündlich ermitteln lässt.
Die Branche hat recht: Echtzeitdaten zählen
In der Branche wird derzeit argumentiert, dass operative Echtzeitdaten selbst einen Margenhebel darstellen. Eine Analyse von Grant Thornton zu versteckten Margenverlusten in der Fertigung 2026 ist ein Beispiel (Grant Thornton, 2026); der "Margin Blind Spot"-Artikel von ManufacturingTomorrow ein weiteres (ManufacturingTomorrow, Feb. 2026). Beide Argumente sind grundsätzlich richtig. Produktionsumstellungen, Lieferantenwechsel und beschleunigte Lieferungen können die Profitabilität binnen Stunden verändern, und ein Finanzreporting, das erst zwei Wochen später Bilanz zieht, kommt zu spät.
Bei der Prämisse sind wir uns also einig. Wo diese Beiträge meist zu kurz greifen, ist bei der Umsetzung. "Schafft Echtzeitdaten" wird so verkauft, als wären sie das fehlende Element. Die meisten Werke haben aber Echtzeitdaten. Die SPS senden im Zwei-Sekunden-Takt Zyklusdaten. Das MES sendet Events, wenn ein Auftrag startet oder fertig wird. Das ERP hält den Kostenstamm und den Vertragspreis. Das Zeiterfassungssystem zeichnet auf, wer ein- und ausgestempelt hat. Die Daten fließen, und sie sind aktuell.
Was fehlt, ist eine semantische Schicht, die all das auf eine einzelne Zahl reduziert, die ein:e Schichtleiter:in ablesen kann.
Der semantische Join ist die fehlende Schicht
Vereinfacht gesagt lässt sich die Auftragsmarge live so berechnen:
- Die Zyklus-Events erfassen, die die Linie sendet.
- Den aktuell laufenden Auftrag bestimmen und prüfen, wie lange jedes Teil im Vergleich zur Standardzykluszeit für das Material dieses Auftrags tatsächlich braucht.
- Die Zeitabweichung mit dem Stundensatz der aktuell eingestempelten Person zuzüglich des Maschinensatzes multiplizieren, um die Kosten zu erhalten.
- Die Nettomarge auf Basis der berechneten Zeitabweichung und des Stückpreises ermitteln.
Diesen Vorgang dann kontinuierlich wiederholen.
Wer die obige Berechnung genau liest, sieht den Haken. Sie enthält fünf Datenquellen, drei Aktualisierungsfrequenzen und vier Fremdschlüssel, die in keinem System tatsächliche Fremdschlüssel sind. Die SPS weiß nicht, welcher Auftrag läuft. Das MES kennt den Auftrag, aber nicht den Stundensatz. Der Kostenstamm kennt den Stundensatz, aber nicht, wer Schicht hat. Kein einzelnes System kann die Antwort liefern. Die Antwort entsteht erst im Join.
An dieser Stelle bleiben die meisten "Real-time-Analytics-für-Fertigung"-Projekte entweder stecken oder geben sich stillschweigend mit einer weniger interessanten Kennzahl wie OEE zufrieden. OEE ist eine sinnvolle Größe, und sie ist einfacher, weil sie nur ein System braucht. Die Auftragsmarge ist das, was das Controlling tatsächlich sehen will, und sie ist genau aus dem Grund schwer, der sie interessant macht.
Wie das in einer echten Schicht aussieht
Die Grafik oben in diesem Beitrag stammt aus einer Schicht eines Verpackungswerks mit vier Linien, simuliert auf Basis der Annahmen, mit denen wir diese Berechnung intern prüfen. Die Blisterlinie bei Müller-Pharma liegt 14 % über der Standardzykluszeit. Bis 11:30 Uhr steht die Projektion fest: dieser Auftrag steuert auf eine aktuelle Margenabweichung von etwa -363 € zu. Um 14:25 Uhr ist der Auftrag 55 Minuten zu spät fertig, und die Projektion wird vom tatsächlichen Kostenlauf bei -363,31 € bestätigt, etwa zu gleichen Teilen verteilt auf Materialausschuss, Überstundenzuschläge und vermeidbaren Effizienzverlust.
Das Interessante an dieser Geschichte ist nicht die Bestätigung um 14:25 Uhr. Das Controlling hätte das ohnehin irgendwann gefunden. Das Interessante ist die Projektion um 11:30 Uhr. Wer als Schichtleiter:in um 11:30 Uhr diese Zahl sieht, hat noch die Option, eine zweite Person zur Unterstützung an die Linie zu holen, den Auftrag umzurüsten oder die Abweichung zu akzeptieren und das nächste Angebot entsprechend zu kalkulieren. Um 14:25 Uhr bleibt nur noch, die Abweichung zu verbuchen.
Ein:e Schichtleiter:in möchte vermutlich nicht mehrere SQL-Abfragen schreiben müssen, um die Frage zu klären: "Warum droht dieser Auftrag, Geld zu verlieren?" Stattdessen sollte sich die Frage in normaler Sprache stellen lassen, und es sollte schnell ein Untersuchungsbericht erscheinen, der die Abweichung in ihre operativen Ursachen zerlegt: wie viel davon Ausschuss war, wie viel auf Überstundenzuschläge entfiel, wie viel auf vermeidbaren Effizienzverlust gegenüber dem Standard. Der schwierige Teil ist auch hier nicht das Chat-Interface. Es ist die semantische Schicht darunter, die den Weg von der Frage zum Beleg über den Join kennt.
Was wir denken
Die meisten Werksleiter:innen im DACH-Mittelstand, mit denen wir gesprochen haben, wollen kein neues Dashboard. Sie haben Dashboards. Was sie wollen, ist die Antwort auf eine Frage, die heute eine Person im Controlling, einen Termin und zwei Wochen braucht. Diese Lücke zu schließen ist im Kern eine Aufgabe der Datenmodellierung, und sie ist lösbar. Der Grund, warum es noch nicht passiert ist, liegt darin, dass bisher niemand geduldig genug war, die semantische Schicht zu bauen, die diese Frage überhaupt erst möglich macht. Die Branche fängt an, das zu verstehen, und aus unserer Sicht ist das Nützlichste, was Beetl tun kann, mittelständische Unternehmen dabei zu unterstützen, ihre eigene semantische Schicht zu bauen und das volle Potenzial ihrer Daten zu nutzen.
Für das breitere Bild, warum Fertigungsunternehmen im DACH-Mittelstand die vorhandenen Daten bisher kaum nutzen, siehe unseren Begleitbeitrag Die DACH-Fertigung verliert bei der Digitalisierung den Anschluss.