Ein Lager. Eine Wahrheit.

Es gibt einen einfachen Weg, Lagersoftware überzeugend aussehen zu lassen.
Ein Dashboard öffnen.
Ein paar grüne Zahlen zeigen.
Ein Diagramm hinzufügen.
Etwas Bestand auf eine Lagerkarte legen.
Mit einem Report abschließen.
Alles sieht gut aus.
Und trotzdem kann alles falsch sein.
Denn ein Lager interessiert sich nicht dafür, wie gut das Dashboard aussieht.
Es interessiert sich dafür, ob jeder Teil des Systems sich darüber einig ist, was tatsächlich passiert ist.
Das wurde zum interessanten Teil des neuesten softify.pro Flow-Experiments.
Kein weiterer Bildschirm.
Kein weiterer KPI.
Kein weiterer Report.
Etwas viel Unsichtbareres.
Konsistenz.
Es begann mit einem Lager.
Die aktuelle softify.pro Flow-Demo arbeitet mit mehreren synthetischen Lagerumgebungen.
Unterschiedliche Lager-IDs.
Unterschiedliche Kapazitäten.
Unterschiedliche Zonenstrukturen.
Kein Produktivbestand.
Keine Kundendaten.
Keine echten Betriebsinformationen.
Aber die Prozesslogik verhält sich so, als würde all das eine Rolle spielen.
Denn in der echten Logistik tut es das.
Sobald ein Lager ausgewählt ist, wird dieser Kontext Teil von allem, was folgt.
Flows.
SSCCs.
Bewegungen.
Bediener.
Analytics.
Reports.
Das klingt selbstverständlich.
Es wird deutlich weniger selbstverständlich, sobald derselbe Prozess in mehreren verschiedenen Teilen der Anwendung auftaucht.
Dann öffneten wir eine andere Ansicht.
Operational Analytics.
Plötzlich sah das Lager völlig anders aus.
Keine Lagerplätze.
Keine Bewegungspfeile.
Stattdessen:

• abgeschlossene Flows,
• aktive Aufträge,
• Lagerauslastung,
• Ausnahmen,
• Wareneingang,
• Warenausgang,
• Bearbeitungszeit.

Die visuelle Darstellung hatte sich geändert.
Das Lager nicht.
Diese Unterscheidung wurde wichtig.
Denn unter den KPIs steckten noch immer einzelne Datensätze.
Flow-IDs.
SSCCs.
Zonen.
Status.
Bediener.
Bearbeitungszeiten.
Andere Ansicht.
Dieselbe operative Realität.
So weit, so gut.

Operational Analytics — aggregierter Lagerzustand, mit den zugrundeliegenden Flow-Datensätzen weiterhin sichtbar.

88 % sind nur dann nützlich, wenn das System sie erklären kann.
Angenommen, das Dashboard sagt:
Lagerauslastung: 88 %.
Nützlich.
Aber unvollständig.
Manche Plätze sind belegt.
Manche sind reserviert.
Manche bleiben frei.
Diese Zustände sind nicht austauschbar.
Die Zahl wird erst vertrauenswürdig, wenn das System noch erklären kann, woher sie kommt.
Fünf abgeschlossene Flows?
Zeig sie.
Zwei aktive Aufträge?
Zeig sie.
Eine Ausnahme?
Welche?
88 % Auslastung?
Was ist belegt?
Was ist reserviert?
Was bleibt frei?
Ein Dashboard sollte die Realität zusammenfassen.
Es sollte sie nicht ersetzen.
Dann haben wir die Sprache gewechselt.
Niederländisch.
Das Lager blieb dasselbe.
Die Flow-IDs blieben dieselben.
Die SSCCs blieben dieselben.
Die Bediener blieben an ihre Datensätze gebunden.
Nur die Sprache änderte sich.
Später erschien derselbe operative Zustand auf Kroatisch.
Dann auf Französisch.
Hier wird mehrsprachige Software deutlich interessanter als übersetzte Buttons.
Eine schlechte Übersetzung fällt leicht auf.
Eine Zustandsänderung, ausgelöst durch einen Sprachwechsel, ist viel gefährlicher.
Man stelle sich vor, von Deutsch auf Französisch zu wechseln und dabei still den ausgewählten Flow zu verlieren.
Oder einen Filter gegen das falsche Lager neu aufzubauen.
Oder die korrekte SSCC im falschen Prozesskontext anzuzeigen.
Die Oberfläche könnte trotzdem perfekt aussehen.
Das System wäre es nicht.
Flow folgt deshalb einer einfachen Regel:
Sprache darf die Worte ändern. Sie darf nicht die Wahrheit ändern.
Dann bekam der Flow eine Historie.
Browse & Drill-down gibt sich nicht besonders viel Mühe, beeindruckend zu wirken.
Vielleicht ist es genau deshalb nützlich.
Einen Flow auswählen.
Sein Kontext erscheint.
Lager.
Zone.
Status.
Bediener.
SSCC.
Und dann die Belegkette.
ASN.
Wareneingang.
Lagerbewegung.
Kommissionierauftrag.
Kommissionierung.
Versand.
FLOW.
Sieben Schritte.
Der Prozess ist nicht mehr nur ein aktueller Zustand.
Er hat eine Vergangenheit.
Und das ändert die Frage.
Statt:
Was passiert gerade?
können wir fragen:
Wie sind wir hierher gekommen?
Das ist eine viel bessere Frage, wenn irgendwann etwas schiefgeht.

Ein Flow, eine SSCC, eine Belegkette — vom ASN bis zum Abschluss.

Die SSCC wird zum roten Faden.
Zunächst sieht eine SSCC aus wie das, was sie ist.
Ein Identifikator.
Eine lange Zahl in einer Tabelle.
Aber über Flow hinweg wird sie zu etwas Nützlicherem.
Ein roter Faden durch den Prozess.
Folgt man ihm, beginnen andere Dinge sich zu verbinden.
Ein Lager.
Ein Flow.
Eine Zone.
Ein Status.
Ein Bediener.
Eine Belegkette.
Schließlich ein Report.
Dasselbe physische Logistikobjekt ist nun aus mehreren verschiedenen Teilen der Anwendung sichtbar.
Nützlich.
Auch gefährlich.
Denn jede zusätzliche Ansicht schafft eine weitere Gelegenheit für das System, eine andere Geschichte zu erzählen.
Und genau da wird es interessant.
Angenommen, Analytics sagt, der Flow sei aktiv.
Drill-down sagt, die SSCC gehöre zu diesem Flow.
Die Belegkette sagt, der Vorgang sei weiter fortgeschritten.
Der Report sagt etwas anderes.
Welche Aussage stimmt?
Das ist kein Flow-spezifisches Problem.
Es ist eines der ältesten Probleme in Business-Software.
Verschiedene Teile desselben Systems entwickeln nach und nach ihre eigene Version der Realität.
Ein Bildschirm liest den transaktionalen Zustand.
Ein anderer liest ein Aggregat.
Ein anderer verlässt sich auf zwischengespeicherte Daten.
Ein Report berechnet etwas leicht anders.
Eine Ausnahme wird operativ gelöst, verschwindet aber aus dem Reporting.
Jede Komponente funktioniert.
Das Gesamtsystem lügt.
Meist höflich.
Also öffneten wir das Report Center.
Tägliche Betriebsübersicht.
Bestand und Auslastung.
Flow-Performance.
SSCC-Rückverfolgbarkeit.
Ausnahmen und SLA.
Dieselbe operative Geschichte erschien erneut.
Abgeschlossene Flows.
Aktive Aufträge.
Lagerauslastung.
Ausnahmen.
Wareneingang.
Warenausgang.
Bearbeitungszeit.
Doch diesmal war die Frage nicht, ob der Report korrekt aussah.
Die Frage war:
Kann er sich selbst verteidigen?
Ein guter Report liefert eine Zahl.
Ein besseres System kann erklären, woher die Zahl kommt.

Reporting aus demselben operativen Zustand — keine zweite Version der Realität.

Die Ausnahme war immer noch da.
Eines der leiseren Details erwies sich als eines der wichtigeren.
Die Demodaten enthalten eine Ausnahme.
Sie erscheint in Analytics.
Sie erscheint im Drill-down.
Sie erscheint in der SSCC-Rückverfolgbarkeit.
Sie erscheint im Report Center.
Und sie bleibt in Exceptions & SLA sichtbar.
Genau das sollte passieren.
Sich operativ von einer Ausnahme zu erholen bedeutet nicht, dass die Ausnahme aus der Historie verschwinden sollte.
"Der Prozess ging weiter" und "Es ist nichts passiert" sind nicht dieselbe Aussage.
In der Logistik macht dieser Unterschied einen Unterschied.
An diesem Punkt hatten wir ein Testproblem.
Kein Softwareproblem.
Ein Testproblem.
Wir hatten nun dasselbe Lager dargestellt als:

• Analytics,
• einzelne Flows,
• SSCC-Historien,
• Belegketten,
• Reports,
• und Ausnahme-Ansichten.

Jede davon ließe sich unabhängig testen.
Öffnen.
Klicken.
Filtern.
Prüfen.
Bestehen.
Weiter.

Das wäre einfach.
Es würde aber auch den interessanten Teil verfehlen.
Denn sechs grüne Häkchen beweisen nicht, dass sechs Ansichten miteinander übereinstimmen.
Auftritt COCO.
Wieder.
COCO hatte sich schon zuvor mit Flow befasst.
Authentifizierung.
Benutzer.
Rollen.
Datenbankumgebungen.
Sprachen.
Desktop-Ausführung.
Dann kam die Logistik.
Lager.
Bestand.
Kommissionierung.
Bewegungen.
Ausnahmen.
Belege.
Ubuntu.
Red Hat Enterprise Linux.
Diesmal gaben wir COCO etwas leicht anderes.
Keinen Bildschirm zum Prüfen.
Eine Geschichte zum Verfolgen.
Nimm dieses Lager.
Nimm diesen Flow.
Nimm diese SSCC.
Öffne Analytics.
Öffne Drill-down.
Wechsle die Sprache.
Schau noch einmal.
Öffne den Report.
Finde denselben Flow.
Finde dieselbe SSCC.
Finde die Ausnahme.
Vergleiche.
Dann vergleiche noch einmal.

COCO verfolgt denselben operativen Kontext über softify.pro Flow hinweg — Analytics, Rückverfolgbarkeit, Sprachwechsel und Reporting.

Das verändert das Wesen des Tests.

Die Frage lautet nicht mehr:

• Funktioniert jedes Modul?

Sondern:

• Glauben alle Module dasselbe passiert zu sein?

Eine viel bessere Frage.
Eine viel unbequemere.
Ein Lagersystem sollte ein Gedächtnis haben.
Bediener sehen vielleicht Lagerplätze.
Lagerleiter sehen vielleicht KPIs.
Der Support nutzt vielleicht Drill-down.
Auditoren nutzen vielleicht Reports.
COCO sieht vielleicht alle davon.
Aber unter diesen Perspektiven sollte es eine einzige Historie geben.
Ein Flow sollte nicht mehrere Biografien bekommen, je nachdem, welches Modul gerade geöffnet ist.
Eine SSCC sollte nicht mehrere Vergangenheiten haben.
Eine Ausnahme sollte nicht nur dort existieren, wo es gerade bequem ist.
Ein Lager sollte nicht zu einem anderen Lager werden, nur weil sich die Oberflächensprache geändert hat.
Genau darum geht es beim aktuellen Flow-Experiment.
Nicht um Dashboards.
Nicht um Reports.
Nicht einmal um einzelne Bildschirme.
Um eine operative Wahrheit, ausgedrückt auf unterschiedliche Weise.
Kontrolle.
Das Lager kennen.
Den Zustand kennen.
Wissen, was sich bewegt.
Wissen, welcher Prozess es besitzt.
Klarheit.
KPIs zurück in Datensätze verwandeln.
Datensätze in Historie verwandeln.
Ausnahmen in Beweise verwandeln.
Eine SSCC in etwas Rückverfolgbares verwandeln.
Flow.
Ein Lager wird ausgewählt.
Analytics beginnt, es zu beschreiben.
Ein Flow schreitet voran.
Die SSCC bleibt angeheftet.
Eine Belegkette wächst.
Eine Ausnahme erscheint.
Der Prozess läuft weiter.
Der Report erinnert sich.
Dann ändert sich die Sprache.
Das Lager ist immer noch dasselbe.
Der Flow ist immer noch derselbe.
Die Historie ist immer noch dieselbe.
Das war der erwartete Teil.
Was danach geschah, war interessanter.
COCO hörte auf, die Ansichten unabhängig voneinander zu testen.
Es begann, sie zu vergleichen.
Eine Weile lang passierte nichts Bemerkenswertes.
Dasselbe Lager.
Derselbe Flow.
Dieselbe SSCC.
Dieselbe Geschichte.
Wieder.
Wieder.
Wieder.
Und dann stoppte COCO.
Nicht weil die Anwendung abgestürzt war.
Das war sie nicht.
Nicht weil ein Test im üblichen Sinn fehlgeschlagen war.
Das war er nicht.
Es stoppte, weil zwei völlig vernünftige Antworten eine dritte Frage erzeugten.

Wir wissen, was die Frage ist.
Flow weiß, warum es existiert.
COCO weiß, wo es als Nächstes nachsehen muss.

Der Rest kann warten.

Control. Clarity. Flow.