Praxisfelder · Validierungsszenarien

Konkrete Situationen, in denen Liquid Nexus beweisen muss, dass es nützlich ist.

Wir veröffentlichen hier keine erfundenen Kundenerfolge. Solange Liquid Nexus in aktiver Validierung ist, zeigen wir stattdessen klar abgegrenzte Praxisfälle: reale Geschäftssituationen, die sich mit vorhandener Evidenz überprüfen lassen.

Status: Die folgenden Beispiele sind Validierungsszenarien und keine abgeschlossenen Kundenreferenzen. Ergebnisse, Kennzahlen und Wirkungsversprechen werden erst veröffentlicht, wenn sie mit echten Design Partnern belegt sind.

Scenario A · Process Reality

Wenn der echte Prozess zwischen Systemen liegt.

Ziel ist nicht, einen Soll-Prozess neu zu zeichnen, sondern aus vorhandenen Spuren zu rekonstruieren, wie ein konkreter Vorgang tatsächlich gelaufen ist.

A1 · Kundenauftrag

Anfrage → technische Klärung → Freigabe → Bestellung

Ein Auftrag durchläuft Vertrieb, Engineering, Einkauf und ERP. Die entscheidenden Gründe stehen teilweise in E-Mail, Zeichnungen, Besprechungsnotizen und Freigaben.

ERP-Auftrag und Stammdaten
E-Mail und Besprechungsnotizen
technische Spezifikation / Zeichnung
formaler Freigabeprozess

Person → Information → Context → Decision → Action → Result

Was bewiesen werden muss

Teilnehmende, Business Objects, Ereignisfolge, Entscheidung und Begründung müssen nachvollziehbar zusammengeführt werden — inklusive Abweichung zwischen Soll und Ist.

A2 · Kundenanfrage mit Engineering

Kundenanfrage → Engineering → Lieferant → Entscheidung → Antwort

Ein technischer Kundenwunsch löst Rückfragen, Lieferantenkontakt und interne Entscheidungen aus. Kein einzelnes System enthält den vollständigen Kontext.

CRM / Ticket / E-Mail
technische Dokumente
Lieferantenkommunikation
interne Entscheidung und Kundenantwort

Evidence → Business Reality Model → Context

Was bewiesen werden muss

Liquid Nexus muss zeigen können, welche Information wann verfügbar war, wer daraus welche Entscheidung ableitete und welche Quellen diese Rekonstruktion tragen.

Scenario B · Business Memory

Wenn Unternehmenswissen in Köpfen, Papier und Altbeständen steckt.

Hier ist die Kernfrage nicht Prozesskomplexität, sondern Wissensverlust: Was muss erhalten bleiben, bevor Schlüsselpersonen ausscheiden oder ein Unternehmen übergeben wird?

B1 · Kundenhistorie

15 Jahre Kundenbeziehung rekonstruieren.

Verträge, Angebote, Sondervereinbarungen, technische Änderungen und persönliche Entscheidungen sind über Jahre verteilt.

Papierverträge und Altakten
Angebote, Lieferscheine, Rechnungen
E-Mail und Dateien
ERP-Auszüge und bestätigtes Erfahrungswissen

Physical legacy → Extraction → Evidence → Business Reality Model

Was bewiesen werden muss

Wichtige Beziehungen zwischen Kunde, Vertrag, Projekt, Produkt, Entscheidung, Sonderregel und beteiligten Personen müssen mit Herkunft und Status rekonstruierbar sein.

B2 · Unternehmensnachfolge

Wissen des Inhabers in überprüfbare Unternehmenshistorie überführen.

Vor Übergabe oder Verkauf soll sichtbar werden, welche Regeln, Ausnahmen und Geschäftsbeziehungen bislang nur durch Erfahrung funktionieren.

Schlüssel-Kunden und Lieferanten
historische Entscheidungen
Sonderkonditionen und Ausnahmen
Dokumente plus gezielte Bestätigung durch Wissensträger

Observed · Inferred · Declared · Expected · Contradicted · Unknown

Was bewiesen werden muss

Das Modell darf Erinnerung nicht als Wahrheit behandeln. Aussagen müssen zwischen belegter Evidenz, menschlicher Erklärung, Schlussfolgerung und Unsicherheit unterscheiden.

Neue Regeln

Ein Praxisfall ist erst dann ein Case, wenn er belegbar ist.

Bis dahin behandeln wir ihn als Testfeld. Das schützt vor Marketingbehauptungen und zwingt das Produkt, echte Evidenz zu liefern.

01Keine erfundenen Kundennamen, Ergebnisse oder ROI-Zahlen.

02Jede Rekonstruktion mit Provenance und Evidenzstatus.

03Keine Behauptung, dass das Modell „die Wahrheit“ über das Unternehmen kennt.

04Process Intelligence darf nicht zur Mitarbeiterüberwachung werden.

05Erster Scope klein genug, um in Wochen überprüfbar zu sein.

06Menschen validieren entscheidende Inferences.

07Automatisierung und Agents erst nach belastbarem Kontext.

08Veröffentlichte Wirkung erst nach realer Validierung.

Reality Lab

So wird aus einem Praxisfall ein belastbarer Referenzfall.

Der Weg beginnt nicht mit einer großen Plattform, sondern mit einem begrenzten Geschäftskontext und wenigen Quellen.

Scope

Einen Prozess, Kundenkontext oder historischen Ausschnitt klar begrenzen.

Evidence

3–5 relevante Quellenklassen verbinden, inklusive Papier dort, wo es zählt.

Reconstruct

Beziehungen, Entscheidungen, Ereignisfolge und Unsicherheit modellieren.

Validate

Mit Prozesskennern prüfen, korrigieren und messbare Nützlichkeit feststellen.

Design Partner

Welcher reale Geschäftskontext wäre bei Ihnen ein guter erster Test?

Praxisfall besprechen