COCO schlägt wieder zu

Wir sollten COCO wahrscheinlich keine Ideen mehr geben.
Das vorherige Experiment sollte eigentlich genug sein.
Eine echte Anwendung.
Echte Navigation.
Benutzer.
Rollen.
Datenbanken.
Sprachen.
Nachweise.

Eine respektable Fallstudie.
Ein sauberer Abschluss.
Dann zeigte uns jemand: Logistics in Motion.
Das war wahrscheinlich der Fehler.

Es begann mit drei Lagern
Nichts besonders Aufregendes.
Drei DEMO-Lager.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Synthetische Daten.
Keine Kundeninformationen.
Kein Produktivbestand.

Genau die Art von Umgebung, in der nichts Wichtiges passieren soll.
Dann wurde das erste Lager ausgewählt.
Und die Anwendung erhielt Kontext.
Von diesem Moment an hatte jeder Bildschirm eine weitere Frage angehängt.

Gehört das noch zum selben Lager?
Ändert die Sprache nur die Oberfläche?
Bleibt der Prozess auf demselben Schritt?
Stimmt der Bestand noch überein?
Zeigt die Belegreferenz noch auf das richtige Ereignis?
Sieht der Bediener genau das, was für die nächste Aktion benötigt wird?

Plötzlich war nicht mehr der Bildschirm der interessante Teil.
Es war die Kontinuität zwischen den Bildschirmen.

COCO neigt dazu.

Logistik ist keine Sammlung von Bildschirmen
Von außen kann Lagersoftware trügerisch einfach wirken.
Ware kommt an.
Sie wird eingelagert.
Jemand bestellt sie.
Sie wird kommissioniert.
Sie wird versandt.
Fertig.
Nur dass sich zwischen angekommen und versandt eine ganze betriebliche Welt verbirgt.
Erwartet.
Erhalten.
Geprüft.
Verfügbar.
Reserviert.
Bewegt.
Kommissioniert.
Gesperrt.
Korrigiert.
Versandt.
Geprüft (Audit).

Die physische Bewegung zählt.
Aber der Statusübergang ist es, der diese Bewegung für Software verständlich macht.
Und wenn diese beiden Realitäten nicht mehr übereinstimmen, hat irgendjemand irgendwann einen schlechten Tag.



Ein Lager ist leichter zu verstehen, wenn Bewegung sichtbar ist, nicht nur aufgezeichnet.
Deshalb hat unsere Logistikarbeit nie wirklich mit Menüs, Dashboards oder Technologie begonnen.
Sie beginnt mit dem materiellen Flow.

Wo tritt Information ein?
Wo ändert sie sich?
Wo kann sie verloren gehen?

Wo ist jemand gezwungen, eine andere Person zu fragen, was passiert ist?
Wo wird ein manueller Schritt stillschweigend zum schwächsten Teil eines ansonsten automatisierten Prozesses?
Manchmal ist die Antwort eine neue Oberfläche.
Manchmal eine Integration.
Manchmal ein Scanner.
Manchmal einfach ein besseres Statusmodell.

Mehr Software ist nicht automatisch bessere Software.
Das Ziel ist nicht Automatisierung um ihrer selbst willen.
Das Ziel ist ein Prozess, der verständlich bleibt.

Control. Clarity. Flow.

Der Prozess beginnt vor der ersten Buchung.
Vor dem Wareneingang.
Vor der Kommissionierung.
Vor der Bestandsbewegung.
Vor der ersten Transaktion.
Flow stellt eine sehr grundlegende Frage:
In welchem Lager arbeiten wir?
Das klingt fast trivial.
Ist es nicht.
Der Lagerkontext gehört zu allem, was folgt.
Bestand.
Dokumente.
Lagerplätze.
Kommissionierung.
Umlagerungen.
Prüfhistorie.
Ausnahmen.

Der Prozess kann völlig gesund aussehen, während er im falschen Kontext läuft.
Das ist genau die Art von Problem, die ein Screenshot selten aufdeckt.
Und genau die Art von Grenze, die COCO gerne hinterfragt.

Sprache ist einfach, bis sie es nicht mehr ist
Deutsch.
Englisch.
Kroatisch.
Norwegisch.
Und andere.

Ein Benutzerprofil definiert die verfügbaren Sprachen.
Der Bediener wechselt die Sprache, während die Anwendung läuft.
Die Oberfläche ändert sich sofort.
Der Geschäftsprozess darf es nicht.
Diese Unterscheidung ist wichtig.
Das Lager bewegt sich nicht, weil sich das Wort für Lager geändert hat.
Der Kommissionierauftrag startet nicht neu, weil der Benutzer eine andere Sprache gewählt hat.
Eine Reservierung verschwindet nicht.
Eine Ausnahme gehört nicht plötzlich zu einer anderen Transaktion.
Der Prozess bleibt, wo er ist.
Nur seine Darstellung ändert sich.
Das klingt offensichtlich.

Bis man erkennt, wie viele Anwendungen einen Sprachwechsel fast wie eine neue Sitzung behandeln.

Eine mehrsprachige Geschäftsanwendung sollte das nicht.
Der Darstellungszustand darf sich ändern.
Der Geschäftszustand muss stabil bleiben.
Das macht den Sprachwechsel zu einem überraschend nützlichen Regressionstest.
Eine kleine Funktion.
Eine sehr gute Bruchstelle.
COCO mag Bruchstellen.

Schritt für Schritt beginnt die Anwendung, Historie anzusammeln
Ware kommt an.
Der Prozess schreitet voran.
Der Wareneingang wird gebucht.
Der Bestand ändert sich.
Der Lagerstatus spiegelt die neue Realität wider.
Die Kommissionierung beginnt.
Bestand wird reserviert.
Der Bediener erhält eine Aufgabe.

Eine mobile Ansicht reduziert den gesamten Prozess auf das, was in genau diesem Moment zählt:
Position.
Lagerplatz.
Menge.
SSCC.
Bediener.
Nicht mehr.
Nicht weniger.
Das ist wichtig.
Die mobile Oberfläche ist kein zweiter Geschäftsprozess.
Sie ist eine weitere Ansicht desselben.
Die Lageranwendung darf alles wissen.
Der Kommissionierer muss es nicht.
Clarity bedeutet nicht immer, mehr Informationen zu zeigen.
Manchmal bedeutet Clarity die Disziplin, fast alles zu verbergen.

Dann scannt jemand den falschen Lagerplatz
Hier wird ein Logistik-Workflow interessanter als eine Funktionsliste.
Der erwartete Lagerplatz ist eine Sache.
Der gescannte Lagerplatz eine andere.
Flow stoppt.
Kein Absturz.
Stopp.
Es gibt einen Unterschied.
Der Prozessstatus bleibt sichtbar.
Der betroffene Bestand bleibt verständlich.
Die Ausnahme wird explizit.

Kontexthilfe erklärt, was für die aktuelle Situation relevant ist.
Der Benutzer löst die Abweichung.
Der Prozess läuft weiter.
Dieser Moment sagt mehr über betriebliche Software aus als mehrere Seiten mit Happy-Path-Screenshots.
Echte Logistik ist nicht schwierig, wenn alles korrekt ist.
Echte Logistik wird schwierig, wenn etwas fast korrekt ist.
Ein nützliches System versteckt das nicht hinter einem grünen Dashboard.
Es gibt der Ausnahme einen Status.

Einen Grund.
Eine Historie.
Und einen Weg nach vorn.

Dokumente erinnern sich an das, was Menschen vergessen

Während der Workflow voranschreitet, sammeln sich Referenzen an.
ASN.
Wareneingang.
Lagerbewegung.
Kommissionierung.
Versand.
Flow.
Der interessante Teil ist nicht, dass Dokumente existieren.
Der interessante Teil ist, dass sie dieselbe Geschichte erzählen wie der Prozess.
Warum ist dieser Bestand hier?
Welcher Wareneingang hat ihn eingeführt?
Welche Operation hat ihn reserviert?
Welche Kommissionierung hat ihn verbraucht?
Welche Sendung hat ihn hinausbewegt?
Wurde eine Ausnahme vor dem nächsten Schritt gelöst?
Was war das aktive Lager?
Was geschah vor dem aktuellen Status?
Wenn Status und Dokumentation vom selben Prozess erzeugt werden, wird Rückverfolgbarkeit leichter vertrauenswürdig.
Wenn nicht, beginnen Menschen irgendwann, die Historie zu rekonstruieren.
Meist in Excel.
Meist unter Druck.
Meist nachdem bereits etwas schiefgegangen ist.
COCO zieht Nachweise vor diesem Moment vor.
Offenbar reist COCO auch
Es gab noch eine kleine Änderung zwischen den Durchläufen.
Ubuntu hatte seinen Durchlauf.
Red Hat Enterprise Linux 10 übernahm den nächsten.
COCO machte weiter.
Keine Zeremonie.
Kein spezieller „Red-Hat-Modus".
Kein umgeschriebener Workflow.
Kein bequem vereinfachter Test.
Derselbe Flow.
Anderer Boden darunter.
Ein früherer COCO-Durchlauf hatte die Anwendung bereits unter Ubuntu Linux durchgespielt.
Der aktuelle wechselte zu Red Hat Enterprise Linux 10.
Andere Desktop-Umgebung.
Andere Systembibliotheken.
Andere Paketierung.
Andere Betriebsumgebung.
Dasselbe Lager.
Dieselben Geschäftszustände.
Dieselben Bestandsübergänge.
Dieselben Sprachwechsel.
Dieselbe Ausnahmelogik.
Dieselben Nachweise.
Das ist eine ziemlich schöne Art, plattformübergreifende Software zu testen.

Nicht ankündigen, dass es plattformübergreifend ist. Verschieben. Dann sehen, was kaputtgeht.

Sprachstatus.
Lagerkontext.
Dialogverhalten.
Timing.
Themes.
Prozessübergänge.
Ausnahmebehandlung.
Nachweise.
Betriebssysteme haben überraschend kreative Wege, Annahmen offenzulegen.

Ubuntu hat einige offengelegt.
Red Hat legt andere offen.
Das ist nützlich.

Denn plattformübergreifende Entwicklung ist nicht die Fähigkeit, die ausführbare Datei zweimal zu starten.

Es ist die Fähigkeit, die Umgebung zu ändern, ohne die Bedeutung des Prozesses zu ändern.
Ein Lagerbediener sollte es egal sein, ob die Anwendung unter Ubuntu oder Red Hat läuft.
Ein Kommissionierauftrag sollte es ebenfalls egal sein.
Ebenso wenig eine Prüfspur.
Wenn Plattformunterschiede beginnen, das Geschäftsverhalten zu ändern, ist die Software nicht wirklich plattformübergreifend.
Sie ist lediglich portabel.
COCO scheint an der ersten Definition erheblich mehr interessiert zu sein.
Wir auch.

COCO entscheidet nicht, was korrekte Logistik bedeutet
Dieser Teil ist wichtig.
COCO wird nicht zum Lagerexperten, nur weil es einem Lager-Workflow folgen kann.
Menschen definieren weiterhin Korrektheit.
Menschen entscheiden, wann Bestand verfügbar wird.
Menschen definieren, was eine gesperrte Lieferung bedeutet.
Menschen entscheiden, wer eine Menge korrigieren darf.
Menschen definieren, welche Bewegung eine Prüfspur erfordert.
Menschen entscheiden, wie eine gültige Ausnahmelösung aussieht.
Menschen entscheiden, wann eine Sendung wirklich vollständig ist.
Die Aufgabe von COCO ist anders.

Wiederholen.
Beobachten.
Vergleichen.
Erinnern.
Nachweise hinterlassen.

Dann macht es das nach jeder Softwareänderung wieder.
Und wieder.
Und wieder.
Ohne gelangweilt zu werden.
Ohne zu entscheiden, dass das Ergebnis der letzten Woche wahrscheinlich noch gültig ist.
Ohne die lästige Ausnahme zu überspringen, weil in zwölf Minuten Mittagspause ist.
Die glamouröse Zukunft des KI-Testens enthält eine überraschende Menge an Wiederholung.
Wir betrachten das als Feature.

Nachweise verändern das Gespräch
Traditionelles Testen endet oft mit einem völlig vernünftigen Satz:
„Es hat funktioniert, als ich es getestet habe."

COCO interessiert sich für den nächsten Satz.

Was genau hat funktioniert?
Welches Lager?
Welcher Benutzer?
Welche Sprache?
Welcher Prozessstatus?
Welche Reihenfolge?
Welches Dokument?
Welcher Bestandswert?
Was geschah unmittelbar vor dem Testschritt?
Was änderte sich unmittelbar danach?
Kann ein anderer Ingenieur das Ergebnis verstehen, ohne die Person zu fragen, die den Test durchgeführt hat?
Genau hier wird Regressionstesten zu mehr als wiederholtem Klicken.
Ein Bildschirm kann korrekt sein, während der Prozess falsch ist.
Ein Kommissionierfenster kann perfekt aussehen, während der Bestand bereits abgedriftet ist.
Ein Dokument kann existieren, während der Status, der es hätte erzeugen sollen, nie eingetreten ist.
Eine Anwendung kann 100 % anzeigen, während eine Prüfspur stillschweigend widerspricht.
COCO folgt dem Flow, weil im Flow diese Widersprüche sichtbar werden.

Irgendwo zwischen Control und Flow
Hier gibt es eine interessante Symmetrie.
Gute Logistiksoftware versucht, Unsicherheit innerhalb eines Betriebs zu reduzieren.
Gutes Testen versucht, Unsicherheit über die Software zu reduzieren, die ihn ausführt.
Das eine fragt:
Wo ist der Artikel?
Das andere fragt:
Woher wissen wir, dass die Software es noch weiß?
Das eine fragt:
Wurde diese Bewegung abgeschlossen?
Das andere fragt:
Welcher Nachweis belegt, dass sich der Status korrekt geändert hat?
Das eine fragt:
Kann die nächste Schicht weitermachen?
Das andere fragt:
Kann der nächste Ingenieur verstehen, was passiert ist?
Unterschiedliche Fragen.
Derselbe Instinkt.
Den Status sichtbar machen.
Die Begründung bewahren.
Die Menge an Wissen reduzieren, die nur im Kopf einer Person existiert.
Vielleicht ist das die Verbindung, die wir ursprünglich nicht geplant hatten.

Ingenieurskunst ohne das Banner
Niemand klickt auf eine Schaltfläche „Engineering Excellence".
Es gibt keine.
Und es sollte wahrscheinlich auch keine geben.
Ingenieurskunst zeigt sich indirekt.
Der Lagerkontext überlebt einen Sprachwechsel.
Derselbe Prozess überlebt eine andere Linux-Plattform.
Eine Bestandsbewegung bleibt rückverfolgbar.
Ein mobiler Kommissionierer sieht genau das, was gebraucht wird, und nichts anderes.
Eine Ausnahme unterbricht den Prozess, ohne seinen Status zu zerstören.
Das Hilfefenster erklärt den aktuellen Kontext, statt generische Dokumentation anzuzeigen.
Die Belegkette stimmt mit der betrieblichen Abfolge überein.
Der nächste Ingenieur kann verstehen, was passiert ist, ohne die Person zu fragen, die zufällig dabei war.
Es gibt reichlich Theater in moderner Software.
KI kann beeindruckende Demonstrationen erzeugen.
Dashboards können animieren.
Zahlen können sich bewegen.
Videos können sehr überzeugend aussehen.
Nichts davon beweist, dass zwei Bestandsoperationen nicht stillschweigend ein falsches Ergebnis erzeugen können.
Nichts davon beweist, dass eine Ausnahme Wochen später noch rekonstruiert werden kann.
Nichts davon beweist, dass Lagerarbeiter, Disponent, und Entwickler auf dieselbe betriebliche Wahrheit blicken.

Ingenieurskunst beginnt an einem weniger fotogenen Ort.

Mit Konsistenz.
Mit Nachweisen.
Mit Grenzen.

Mit der Bereitschaft, die langweiligen Teile langweilig zu lassen.
Unsichtbare Zuverlässigkeit erzeugt selten den dramatischsten Screenshot.
Bis man bewusst anfängt, danach zu suchen.

Control. Clarity. Flow.
Control bedeutet zu wissen, welches Lager, welcher Prozess, und welcher Status aktiv sind.
Clarity bedeutet zu verstehen, was sich geändert hat, wann es sich geändert hat, und warum.
Flow bedeutet, den Betrieb fortzusetzen zu lassen, ohne die Geschichte dahinter zu verlieren.
Das funktioniert für Logistik.
Es funktioniert für Softwaretests.
Es funktioniert überraschend gut für die Ingenieurskunst selbst.
Das erste Flow-Experiment gab COCO Administration.
Benutzer.
Rollen.
Datenbanken.
Sprachen.
Dann gab ihm jemand ein Lager.
Dann mehrere Sprachen.
Dann mobile Kommissionierung.
Dann Bestand.
Dann Umlagerungen.
Dann Ausnahmen.
Dann Dokumente.
Dann ein weiteres Betriebssystem.
An diesem Punkt sollten wir wahrscheinlich aufhören, Dinge hinzuzufügen.
Wir werden es wahrscheinlich nicht.

Control. Clarity. Flow.

Ubuntu war dran.

Red Hat ist jetzt dran.

Der Flow bewegt sich weiter.

COCO schaut weiter zu.
Und irgendwo mitten im letzten Durchlauf wurde offensichtlich, dass hinter diesem eine weitere Frage wartet.

Wir wissen, was sie ist.
COCO weiß, was sie ist.
Du weißt es nicht.
Noch nicht.

Wir könnten es dir sagen.

Aber dann würdest du vielleicht aufhören zu prüfen, ob ein neuer Insiders-Artikel erschienen ist.
Und das würde das Experiment ruinieren.