[{"data":1,"prerenderedAt":84},["ShallowReactive",2],{"content:blog:verbindungsabbruch-im-lager":3,"content:blog":30},{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":12,"toc":16,"body":29},"verbindungsabbruch-im-lager","Verbindungsabbruch im Lager: Warteschlange, Wiederholung und Protokoll","Welche Ordnung eine Anwendung am Regal braucht, damit ein Funkloch die Buchung verschiebt und nicht verliert","2026-08-28","Verbindungsabbruch im Lager: scannen ohne Netz","Verbindungsabbruch im Lager: Warteschlange, Wiederholung und Protokoll machen das Scannen ohne Funk vorhersagbar. Erfahrungen aus 22 Datenquellen.","Zwischen Regalreihe und Hallentor bricht das Funknetz, und eine Anwendung, die das nicht vorgesehen hat, verliert entweder die Buchung oder die Zeit des Menschen davor. Wir beschreiben die drei Teile, die den Ausfall berechenbar machen, und den Puls, an dem eine stillgelegte Quelle auffällt.",4,[13,14,15],"Architektur","Automatisierung","Arbeitsweise",[17,20,23,26],{"id":18,"text":19},"netzloch","Was passiert, wenn das Funknetz zwischen den Regalreihen aussetzt",{"id":21,"text":22},"ordnung","Verbindungsabbruch im Lager: die drei Teile der Ordnung",{"id":24,"text":25},"puls","22 Quellen mit Puls: 89 Stunden Funkstille, die auffielen",{"id":27,"text":28},"arbeitsweise","Verbindungsabbruch im Lager: so bauen wir die Anwendung","\u003Cp>Ein Verbindungsabbruch im Lager darf die Arbeit nicht anhalten, und er darf sie auch nicht stillschweigend verfälschen. Der Scanner muss weiter quittieren, die Buchung muss später ankommen, und der Mensch am Gerät muss sehen, was noch offen ist. Drei Teile machen das planbar: Warteschlange, Wiederholung, Protokoll.\u003C\u002Fp>\n\n\u003Ch2 id=\"netzloch\">Was passiert, wenn das Funknetz zwischen den Regalreihen aussetzt\u003C\u002Fh2>\n\n\u003Cp>Eine Halle ist keine Büroetage. Metallregale, Kühlzellen, ein Tor, das aufgeht — die Funkabdeckung schwankt auf zehn Metern, und sie schwankt jeden Tag anders. Eine Anwendung, die stillschweigend annimmt, dass der Server erreichbar ist, verhält sich an dieser Stelle auf eine von zwei Arten, und beide sind schlecht.\u003C\u002Fp>\n\n\u003Cp>Die erste: Sie zeigt einen Fehler und verwirft die Eingabe. Der Mitarbeitende scannt noch einmal, geht drei Schritte zurück Richtung Tor, scannt wieder. Nach dem dritten Mal schreibt er auf einen Zettel, und der Zettel kommt abends ins Büro — womit genau der Handweg zurück ist, den die Anwendung ablösen sollte.\u003C\u002Fp>\n\n\u003Cp>Die zweite ist gefährlicher: Sie zeigt ein grünes Häkchen, obwohl nichts gesendet wurde. Der Wareneingang gilt als gebucht, die Palette steht im System, und niemand erfährt je, dass die Meldung nie angekommen ist. Ein Gerät, das nicht sagen kann „ich habe nichts übertragen“, sieht aus wie ein Gerät, bei dem alles in Ordnung ist.\u003C\u002Fp>\n\n\u003Ch2 id=\"ordnung\">Verbindungsabbruch im Lager: die drei Teile der Ordnung\u003C\u002Fh2>\n\n\u003Cp>Die \u003Cstrong>Warteschlange\u003C\u002Fstrong> ist der erste Teil. Jede Aktion am Gerät — Wareneingang, Umlagerung, Zählung — wird zuerst lokal festgeschrieben und bekommt eine eigene Kennung. Die Anwendung bestätigt dem Menschen den Vorgang, nicht die Übertragung; das sind zwei verschiedene Zusagen, und die Oberfläche muss sie auseinanderhalten. Was noch aussteht, steht sichtbar als Zahl am Rand.\u003C\u002Fp>\n\n\u003Cp>Die \u003Cstrong>Wiederholung\u003C\u002Fstrong> ist der zweite. Sobald das Netz wieder da ist, werden die offenen Vorgänge in der Reihenfolge ihres Entstehens gesendet, mit wachsendem Abstand zwischen den Versuchen. Entscheidend ist die eigene Kennung: Der Server erkennt an ihr, dass er diesen Vorgang schon kennt, und bucht ihn nicht ein zweites Mal. Ohne diese Eigenschaft macht eine Wiederholung aus einem verlorenen Wareneingang einen doppelten.\u003C\u002Fp>\n\n\u003Cp>Das \u003Cstrong>Protokoll\u003C\u002Fstrong> ist der dritte. Jeder Versuch hinterlässt eine Zeile: wann, welcher Vorgang, welche Antwort, welcher Grund beim Scheitern. Wenn die Inventur am Monatsende nicht aufgeht, ist das der Unterschied zwischen einer Suche und einer Frage mit Antwort.\u003C\u002Fp>\n\n\u003Cp>Eine Grenze bleibt auch mit diesen drei Teilen bestehen, und wir sagen sie vorher. Vorgänge, die eine Freigabe aus dem führenden System brauchen — eine Sperrcharge, ein gesperrter Kunde —, lassen sich ohne Netz nicht abschließen. Sie werden erfasst und als \u003Cstrong>ungeklärt\u003C\u002Fstrong> geführt, statt so auszusehen, als wären sie entschieden. Und wenn zwei Geräte offline dieselbe Palette bewegen, löst die Anwendung den Widerspruch nicht selbst auf: Sie benennt ihn und legt ihn einem Menschen vor.\u003C\u002Fp>\n\n\u003Ch2 id=\"puls\">22 Quellen mit Puls: 89 Stunden Funkstille, die auffielen\u003C\u002Fh2>\n\n\u003Cp>Der Ausfall eines Geräts fällt auf, weil jemand davorsteht. Der Ausfall einer Anbindung fällt nicht auf — das ist die größte Sorge, die uns ein Auftraggeber dazu genannt hat, und sie ist berechtigt: „Es hört still auf, Daten zu ziehen, und wir erfahren es eine Woche später vom Kunden.“ Genau dieser Fall blieb in einem unserer Projekte bis dahin unbemerkt.\u003C\u002Fp>\n\n\u003Cp>Deshalb hat dort jeder Datenfluss einen eigenen Puls bekommen, insgesamt \u003Cstrong>22 angebundene Quellen\u003C\u002Fstrong>. Der Puls hängt am tatsächlich erfolgreichen Abruf und nicht an der Aktualität der Daten — sonst meldet eine Quelle, die nur nichts Neues zu berichten hat, einen Ausfall, und eine wirklich tote Quelle bleibt grün. Ein ausgefallener Lauf färbt sich rot und nennt den Grund; drei der 22 Quellen waren sofort als veraltet markiert.\u003C\u002Fp>\n\n\u003Cp>Sichtbar wurden dabei \u003Cstrong>89 Stunden\u003C\u002Fstrong> Funkstille bei den Sendungsdaten und \u003Cstrong>520\u003C\u002Fstrong> Fehler in Folge eines Postfachs, die vorher niemandem aufgefallen waren. Die Übersicht ist auch gegen sich selbst ehrlich: Sie meldet, wenn sie selbst nichts gemessen hat, statt in diesem Fall grün zu bleiben. Dieselbe Regel gilt für das Gerät im Lager — „nicht übertragen“ ist ein eigener Zustand, kein stiller Erfolg.\u003C\u002Fp>\n\n\u003Ch2 id=\"arbeitsweise\">Verbindungsabbruch im Lager: so bauen wir die Anwendung\u003C\u002Fh2>\n\n\u003Cp>Wir schreiben vor dem Bau auf, welche Vorgänge ohne Netz zulässig sind, welche eine Freigabe brauchen und wie ein Widerspruch aufgelöst wird — diese Liste ist Teil der \u003Ca href=\"\u002Flexikon\u002Fleistungsbeschreibung\">Leistungsbeschreibung\u003C\u002Fa> und später der Maßstab der \u003Ca href=\"\u002Flexikon\u002Fabnahme\">Abnahme des Ergebnisses\u003C\u002Fa>. Das Programm am Regal entsteht in der \u003Ca href=\"\u002Fleistungen\u002Fsoftwareentwicklung\">Softwareentwicklung für Fertigung und Lager\u003C\u002Fa>, der Weg der Meldungen in die führenden Systeme gehört zur \u003Ca href=\"\u002Fleistungen\u002Fprozessautomatisierung\">Prozessautomatisierung zwischen Halle, Lager und ERP\u003C\u002Fa>. Geprüft wird beides am ausgeschalteten Netz, nicht am Schreibtisch.\u003C\u002Fp>",[31,56,63],{"slug":32,"title":33,"subtitle":34,"date":35,"metaTitle":36,"metaDescription":37,"excerpt":38,"readingMinutes":11,"tags":39,"toc":41},"prozess-automatisieren","Wann sich ein Prozess automatisieren lässt: vier Anzeichen aus Wareneingang und Abschreibung","Woran man vor dem ersten Angebot erkennt, ob ein Ablauf reif ist — und woran man erkennt, dass er es nicht ist","2026-09-08","Prozess automatisieren: vier Anzeichen aus dem Lager","Prozess automatisieren oder lassen: vier Anzeichen aus Wareneingang und Abschreibung, ein Schattenlauf vor der Umstellung und die Fälle, in denen wir abraten.","Nicht jeder Ablauf gehört automatisiert, und die Entscheidung fällt vor dem ersten Angebot. Wir nennen vier Anzeichen, die wir bei Wareneingang und Abschreibung gesehen haben, zeigen an einem Projekt mit 2 536 Lagerbelegen, was danach sichtbar wurde, und beschreiben den Schattenlauf vor der Umstellung.",[14,15,40],"Integration",[42,45,48,51,54],{"id":43,"text":44},"anzeichen","Vier Anzeichen, dass sich ein Prozess automatisieren lässt",{"id":46,"text":47},"wareneingang","Wareneingang: derselbe Zettel, dreimal erfasst",{"id":49,"text":50},"schwund","2 536 Lagerbelege: Abschreibung mit Grund statt Vermutung",{"id":52,"text":53},"schattenlauf","Erst im Schattenlauf, dann scharf",{"id":27,"text":55},"Prozess automatisieren: so entscheiden wir mit",{"slug":4,"title":5,"subtitle":6,"date":7,"metaTitle":8,"metaDescription":9,"excerpt":10,"readingMinutes":11,"tags":57,"toc":58},[13,14,15],[59,60,61,62],{"id":18,"text":19},{"id":21,"text":22},{"id":24,"text":25},{"id":27,"text":28},{"slug":64,"title":65,"subtitle":66,"date":67,"metaTitle":68,"metaDescription":69,"excerpt":70,"readingMinutes":11,"tags":71,"toc":72},"datenaustausch-mit-dem-erp","Datenaustausch mit dem ERP: warum Schichtzettel und Lieferscheine einen Tag zu spät ankommen","Was zwischen Halle, Lager und Büro tatsächlich verloren geht — und woran man sieht, dass es nicht am ERP liegt","2026-08-19","Datenaustausch mit dem ERP: Zahlen ohne Folgetag","Datenaustausch mit dem ERP statt Abtippen am Abend: wie Bestände, Verbräuche und Lieferscheine aus Halle und Lager noch am selben Tag im System stehen.","In vielen Fertigungs- und Lagerbetrieben ist das ERP nicht das Problem — der Weg dorthin ist es. Wir beschreiben an zwei Projekten, wie aus einer Schichttabelle und aus Fotos von Lieferscheinen Werte werden, die das System selbst liest, und wo diese Automatik ihre Grenze hat.",[14,40,15],[73,76,79,82],{"id":74,"text":75},"verzug","Warum die Zahlen aus der Halle einen Tag brauchen",{"id":77,"text":78},"abgleich","93 Lagerpositionen: Datenaustausch mit dem ERP als Abgleich, nicht als Formular",{"id":80,"text":81},"belege","Fotos von Lieferscheinen: was mit dem Papier passiert",{"id":27,"text":83},"Datenaustausch mit dem ERP: so gehen wir vor",1789383437961]