Zum Hauptinhalt springen

Flow-Analyse — Auftrags-Flow (Reservierung → … → Abholung)

Typ: Analyse & Empfehlung (Entscheidungsgrundlage). Status: größtenteils umgesetzt (Historie) — die Empfehlung wurde als OP-R3-1 beschlossen und über Flow-Refactor-Plan.md (PR 1–7 ✅) umgesetzt; dieses Doc bleibt als Begründungs-Hintergrund erhalten. Anlass: Nutzer-Eindruck (06-24), der Flow Reservierung – Anlieferung – Annahme – Aufbereitung – Produktion – QS – Abholung sei „nicht sinnvoll/intuitiv aufgesetzt". Geprüft aus Daten-, Prozess- und UX-Sicht. Bezug: OP-R3-1 (Standard-Prozess & Klärfälle) · Lastenheft §5.1 · Sanity-Checkliste Frage 2 („Wo stehen die Fahrzeuge — auch in der Bearbeitung?").

Ergebnis vorweg​

Der Eindruck stimmt, und die Ursache ist strukturell: Es existieren drei nicht deckungsgleiche „Flows" im System, und der vom Nutzer genannte 7-Schritt-Flow ist eine Vermischung zweier orthogonaler Achsen — Lifecycle/Reservierung (Zustand des Vorgangs) und fachliche Arbeitsphase (wo im Werkstatt-Prozess). Genau diese Vermischung erzeugt das „unintuitiv"-Gefühl.

Die drei konkurrierenden „Flows"​

SichtSchritteQuelle
A. Technischer Lifecycle (8 Status)geplant → angeliefert → in_arbeit ⇄ pausiert → fertiggestellt → abgeschlossen → kontrolliert → archiviertserver/src/operativ/auftrag.ts:18-48
B. Fachlicher Standard-Prozess (5 Phasen)Annahme → Aufbereitung → Produktion → QS → Abholungdocs/fachlich/Lastenheft.md:541-564
C. UI-Flow-Band (5 Stationen)Annahme · Aufbereitung · Produktion · QS · Abholung (heuristisch aus Status abgeleitet)client/src/app/leitstand/flow-band.component.ts:28-110
(Nutzer-Mental-Modell) (7 Schritte)Reservierung – Anlieferung – Annahme – Aufbereitung – Produktion – QS – Abholung—

Keiner deckt die anderen ab. Lastenheft §5.1 erklärt A und B sogar explizit zu „zwei getrennten Schichten" (docs/fachlich/Lastenheft.md:564) — aber ohne saubere Abbildung zwischen ihnen. Das ist der Kern des Problems.

1. Daten-Sicht​

  • „Reservierung" ist kein Schritt, sondern ein abgeleiteter Modus weich | hart | keine (auftrag.ts:56-61, reservierungsmodus()). Es ist eine orthogonale Achse (Ressourcen-Härte), kein Punkt in der Kette. Sie als ersten „Flow-Schritt" zu führen vermischt zwei Dimensionen.
  • „Anlieferung" und „Annahme" kollabieren auf EINEN Status angeliefert (auftrag.ts:20). Real sind das zwei Dinge: Anlieferung = Fahrzeug ist physisch da; Annahme = formale Übernahme inkl. Zustandsdoku. Das Modell kann „Auto steht da, aber noch nicht angenommen" nicht ausdrücken. (Historisch hieß angeliefert einmal reserviert; Migration v3 hat nur umbenannt, nicht aufgeteilt — leitstand.ts SCHEMA_VERSION.)
  • Annahme / Aufbereitung / QS haben keine First-Class-Repräsentation. Sie werden erraten:
    • Annahme ≈ Status angeliefert (implizit).
    • Aufbereitung vs. Produktion = fragile Heuristik („ist irgendein Teilschritt erledigt?") — flow-band.component.ts:35. Startet jemand Schritt 3 vor Schritt 1, springt die Anzeige fälschlich auf „Produktion". Der Code-Kommentar markiert das selbst als Provisorium bis OP-R3-1 (flow-band.component.ts:23-26).
    • QS ≈ Status fertiggestellt, gleichzeitig als Teilschritt ts-qm modelliert → doppelte Modellierung derselben Sache.
  • Zwei verschiedene Kontrollen werden verwechselt: QS/Endkontrolle (VOR Abholung) vs. kontrolliert/Nachkontrolle (NACH Abholung, auftrag.ts:25). Das Flow-Band mappt „QS-Station" = fertiggestellt und „Abholung-Station" = kontrolliert (flow-band.component.ts:38-42) — vermengt also End- und Nachkontrolle.
  • Das Prinzip „Derived State nie speichern" ist eingehalten — aber die Ableitung ist verlustbehaftet und fragil, weil die fachliche Phase nicht eindeutig aus dem Status folgt.

2. Prozess-Sicht​

  • A (Lifecycle) und B (5 Phasen) sind „bewusst getrennt" (Lastenheft.md:564), aber es gibt keine saubere 1:1-Abbildung: der eine Status in_arbeit deckt Aufbereitung + Produktion + QS ab.
  • Annahme/Aufbereitung/QS sind als „explizite Phasen mit Doku-Aktivität" spezifiziert (Lastenheft.md:564), aber als optionale Teilschritte implementiert → keine erzwungenen Doku-/Kommentar-Gates (Bezug OP-R4-3). Bekannter offener Punkt OP-R3-1.
  • Klärfälle-Prozess (Skill „Klärung", Unterbrechung an jeder Stelle → Eskalation → zurück / Sprung zu QS / anderer Schritt / Abbruch) ist dokumentiert, aber NICHT implementiert — es gibt nur ein generisches pausieren (auftrag.ts:42-43). Kein „Abbruch"-Übergang im Lifecycle.
  • QS → Abholung ist inkonsistent verdrahtet: Die Quality-Page-Aktion „Freigeben (zur Abholung)" ruft direkt abholen (client/.../pages/quality.component.ts), wodurch der Status kontrolliert faktisch verwaist / übersprungen wird.
  • Transitionen sind durchweg manuell (UI → auftrag.aktion), keine automatischen Status-Wechsel durch den Scheduler (server/party/leitstand.ts). Das ist konsistent, macht aber die fehlenden Phasen-Gates umso spürbarer.

3. UX-Sicht​

  • Zwei visuelle Sprachen nebeneinander: 8-Status-Farb-Badges (auftrag-detail-panel.component.ts:272, orders.component.ts:218, Gantt-Legende) vs. 5-Stationen-Flow-Band. Der Operator sieht je nach Seite eine andere Darstellung desselben Vorgangs.
  • Die Aufbereitung/Produktion-Heuristik kann die tatsächliche Arbeitsphase falsch anzeigen (s. §1).
  • Eintritt in die Arbeit ist versteckt: „▶ Aufbereiten starten" gibt es nur auf der Belegung/Wareneingang-Seite (occupancy.component.ts:36), nicht im Haupt-Flow-Band.
  • Die Annahme-Station mischt „erwartet" (geplant) und „da" (angeliefert) in einer Station (flow-band.component.ts:79-91) — die vom Nutzer erwarteten separaten Schritte Reservierung und Anlieferung sind nicht als eigene Stationen sichtbar.
  • Terminklasse-Badges (garantiert/ziel/best_effort) stehen neben Status-Badges (auftrag-detail-panel.component.ts:278) und werden leicht als „Phase" fehlgedeutet.
  • Der intuitive 7-Schritt-Flow des Nutzers ist nirgends als solcher abgebildet.

Kernursache (eine Zeile)​

Das System mischt zwei orthogonale Achsen — Lifecycle/Reservierung (Zustand des Vorgangs) und fachliche Arbeitsphase (wo im Werkstatt-Prozess) — in eine einzige gefühlte Kette, kollabiert dabei real getrennte Schritte (Anlieferung ≠ Annahme) auf einen Status und modelliert QS/Kontrolle doppeldeutig (End- vs. Nachkontrolle).

Die zwei Achsen sauber gedacht​

Empfohlene Richtung — Zielbild „Phasen first-class" (OP-R3-1)​

Größerer, migrationspflichtiger Umbau; hier als empfohlenes Zielbild, nicht als beschlossene Umsetzung. Schärft OP-R3-1 um konkrete Punkte:

  1. Zwei Achsen explizit trennen & benennen statt sie in eine Kette zu zwingen: Lifecycle/Reservierung (Zustand + Ressourcen-Härte) und fachliche Phase (wo im Werkstatt-Prozess) als First-Class-Konzept. Abgeleitet bleibt nur, was eindeutig ableitbar ist; die aktuelle Aufbereitung/Produktion-Heuristik entfällt.
  2. Anlieferung ≠ Annahme entkoppeln: Sammelstatus angeliefert auflösen bzw. um einen Annahme-/Doku-Schritt ergänzen, damit „da, aber noch nicht angenommen" abbildbar wird.
  3. QS-Doppelmodellierung auflösen: Endkontrolle (vor Abholung) und Nachkontrolle (kontrolliert, nach Abholung) klar trennen; falsches UI-Mapping kontrolliert↔Abholung im Flow-Band korrigieren.
  4. Klärfälle-Prozess als jederzeit auslösbare Unterbrechung mit eigenem Skill „Klärung" (Eskalation + Doku) + „Abbruch"-Übergang im Lifecycle (S-6).
  5. Eine konsistente visuelle Flow-Sprache über Flow-Band, Orders-Timeline, Detail-Panel und Gantt — Lifecycle/Reservierung und fachliche Phase getrennt, aber gemeinsam lesbar.
  6. Pflicht-Doku-Gates je Phasenwechsel (Bezug OP-R4-3) als Teil des Zielbilds.

Migration/Risiko: First-Class-Phasen erfordern schemaVersion-Bump + idempotenten Remap in server/party/leitstand.ts (Konvention wie bei den bestehenden Status-Migrationen, z. B. v3 reserviert→angeliefert). Bestehende Aufträge müssen verlustfrei auf das neue Achsen-Modell abgebildet werden.

Umsetzung​

Konkreter, inkrementeller Refactor-Plan (PR-weise) zum Zielbild „Phasen first-class": docs/Flow-Refactor-Plan.md.

Referenzen (Code)​

  • server/src/operativ/auftrag.ts:18-61 — AuftragStatus, TRANSITIONS, reservierungsmodus()
  • docs/fachlich/Lastenheft.md:505-588 — §5.1 Lifecycle-Tabelle, Standard-Prozess, Klärfälle (Mermaid)
  • client/src/app/leitstand/flow-band.component.ts:23-110 — 5-Stationen-Mapping + Heuristik
  • client/src/app/leitstand/auftrag-detail-panel.component.ts:247-292 — Status-/Aktion-/Phasen-Labels
  • client/src/app/leitstand/pages/occupancy.component.ts:16-42 — Wareneingang/„Aufbereiten starten"
  • client/src/app/leitstand/pages/quality.component.ts — QS-Freigabe (abholen-Sprung)

↩ Zurück zur Doku-Landkarte · Lesepfade · Register (alle OPs)