Prozessmodell — wie Medidentas die Geschäftsprozesse abbildet & unterstützt (MED-D-79, Achsen seit MED-D-151)

Kernaussage (pyramidal). Medidentas bildet den Mandanten-Prozess schon reif ab — als flexibles Case-Management (Zustandsmaschine, kein starrer linearer Ablauf) mit zwei bewusst getrennten Achsen (grober lifecycleStatus je Person, feiner status je Beratungsauftrag), einem geführten Lifecycle-Guard + Playbooks auf beiden Ebenen und rein abgeleiteten Sichten (Aktenreife, Nächste Schritte). Bis 0.82.0 gab es eine dritte, redundante Achse (prozessphase) — MED-D-151 hat sie retiriert: ihre feine Granularität deckte Beratungsauftrag.status bereits ab, nur pro Person statt pro Auftrag, und konnte deshalb nie abbilden, dass eine Person mehrere Beratungsprodukte gleichzeitig in unterschiedlichen Stadien hat (MED-D-95). Der beste Weg, die Prozesse "am besten abzubilden", bleibt Schärfen statt Neubau: die zwei verbleibenden Achsen orthogonal halten, Dokumente & Unterschriften als quer-liegende Achse (nicht als einzelnen Schritt) führen und die verbleibende Lücke (Gesprächsnotizen/R11) schließen. Dieses Dokument ist die eine Quelle dafür, wie der Prozess modelliert ist; der priorisierte Fahrplan steht in §8.

Zielgruppen: Business/Management (§1, §3, §7, §8) · IT-Dev/Architektur (§2, §4, §5, §6) · alle (Kernaussage). Verortung: bündelt System-Charakter.md §1, Lastenheft.md §5 und Akte-Struktur.md (D-41) an einer Stelle. Trifft die verbindliche Vokabular-Entscheidung (§2), ansonsten beschreibend.

---

1. Archetyp — was für ein Prozess ist das?

Medidentas ist vertikales, compliance-getriebenes Case-Management mit Orchestrierungs-Kern (System-Charakter §1). Für den Prozess heißt das dreierlei:

• Zustandsmaschine, kein Fließband. Jeder Mandant ist ein "Fall", der durch einen Lebenszyklus läuft — aber verzweigbar: an jeder Stelle kann unterbrochen, zurückgesprungen oder eskaliert werden (§3, Lastenheft §5.3).
• Steuerungsziel = Vollständigkeit & Termintreue, nicht Durchsatz (Lastenheft §6): "nichts fällt durch" — keine vergessene Wiedervorlage, keine fehlende Unterschrift, keine unvollständige Beratungsdoku.
• System of Engagement, nicht of Data (System-Charakter §3): Medidentas hält Prozesszustand, Referenzen und Audit-Trail — die Dateien liegen in der Ablage (R3/R2/NextCloud), der Kundenstamm im CRM.

2. Die Achsen — eine autoritative Landkarte (behebt die Vokabular-Uneindeutigkeit)

Ein Mandant trägt mehrere orthogonale Klassifikationen. Sie werden oft verwechselt; diese Tabelle ist ab sofort die verbindliche Referenz.

Achse	Werte	Zweck	Wie geändert	Feld / Quelle
Lifecycle-Status	lead · onboarding · aktiv · ruhend · archiviert	grobe, CRM-/geschäftsnahe Beziehungsstufe einer Person — funktioniert auch ohne jeden Beratungsauftrag	manuell (Board/Aktendeckel), seit MED-D-151 geführt (Guard bei Eintritt in aktiv, s. u.)	Mandant.lifecycleStatus (R1-F05)
Auftrag-Status	anbahnung · beratung · unterschrift · laufend · abgeschlossen	feine, produktbezogene "wo steht dieses Beratungsprodukt?" — 0..n je Person, je Auftrag unabhängig	geführt (Produkt-Katalog erlaubt nur bestimmte Werte je Produkt)	Beratungsauftrag.status (MED-D-95)
Onboarding-Teilschritt	stammdaten · dokumente · beratung · abschluss	Fortschritt innerhalb der Lifecycle-Stufe onboarding	intern, aus Items abgeleitet	Onboarding.phase (R2-F04)
(orthogonal, nicht Prozess) Betreuungsmodell	intensiv · standard · basis	internes Leistungsversprechen (neutral, nicht Ampel)	manuell	Mandant.betreuungsmodell (R1-F11/D-35)
(orthogonal, geplant) ABC-Priorität	tbd	Wichtigkeit ≠ Lifecycle/Auftrag-Status	—	OP-ABC-1

Verbindliche Regel (MED-D-79). DIE fachliche Phase = Mandant.prozessphase. Abgelöst (MED-D-151). Es gibt keine mandantenweite "fachliche Phase" mehr — die feine Granularität lebt je Beratungsauftrag in Beratungsauftrag.status. Onboarding.phase (R2-F04) bleibt weiterhin ein Teilschritt innerhalb der Lifecycle-Stufe onboarding, keine eigenständige Achse.

Enum-Regel (server/src/domain/enums.ts). Status-Werte sind logik-tragend (treiben Ableitung/Guards) → fix; geschärft werden nur Labels & Doku, nicht die Enum-Werte selbst.

Warum zwei Achsen (nicht mehr drei)? lifecycleStatus beantwortet "wie weit ist die Beziehung insgesamt?" — eine Frage, die auch für einen Mandanten mit null Beratungsaufträgen sinnvoll ist (der Normalfall am Trichter-Eingang). Beratungsauftrag.status beantwortet "wie weit ist dieses konkrete Produkt?" — und das mehrfach unabhängig, sobald ein Mandant mehr als einen Auftrag hat (z. B. eine Versicherungsoptimierung in beratung, während eine Kapitalanlage bereits laufend betreut wird). Eine einzelne, mandantenweite Prozessphase (bis 0.82.0) konnte diese zweite Frage nie korrekt beantworten — sie zwang jede Person auf eine Phase, egal wie viele Aufträge sie hatte (Lastenheft §5.2, MED-D-95).

3. Der Standard-Prozess (Mandanten-Lebenszyklus)

Lead → Onboarding → Aktiv → Ruhend/Archiviert ist die grobe, personenbezogene Achse — sie gilt unabhängig davon, ob und wie viele Beratungsaufträge existieren. Nur der eine Übergang → aktiv ist geguarded (er fasst die zwei früheren Phasen-Engine-Guards onboarding→beratung/unterschrift→betreuung zusammen, MED-D-151): er verlangt vollständiges Onboarding und keine offenen Unterschriften (personenweite Fakten, nicht auftragsgefiltert). Ruhend/Archiviert sind administrative Zustände ohne Ordinal — von überall frei erreichbar, nie automatisch verlassen.

Innerhalb jedes einzelnen Beratungsauftrags läuft eine eigene, feinere Zustandsmaschine — unabhängig für jeden Auftrag derselben Person:

Dokumente & Unterschriften (inkl. Ablage) sind eine quer-liegende Achse (§6, MED-D-80), sowohl über die Lifecycle-Stufen als auch über die Beratungsaufträge hinweg — keine eigene Phase auf keiner der beiden Achsen.

• Einstieg (MED-D-70). Der eigentliche Prozess beginnt mit dem Onboarding. Dentmarking ist eine Beratungsleistung (niedrigschwelliger Lead-Einstieg): ein Lead ohne Onboarding wird direkt als lead-Mandant angelegt (verantwortlich = null, gemeinsamer Lead-Pool), das Onboarding folgt danach.
• Verzweigung (Lastenheft §5.3). An jeder Stelle unterbrechbar (fehlende Unterlage, Rückfrage, Eskalation) → dokumentieren, Wiedervorlage setzen, zurück/Sprung/Abbruch; jede Unterbrechung ist auditierbar (G-4).

4. Wie wir ABBILDEN (Repräsentation)

Die Prozess-Sicht ist rein abgeleitet (G-2, nichts doppelt gespeichert):

• Prozessgegliederte Mandant-Ansicht (Akte-Struktur.md, D-41): Aktendeckel mit den 3 True-North-Kennzahlen + Lifecycle-Zeitstrahl; Register = Lifecycle-Stufen (Erstkontakt → Onboarding → Aktiv) plus ein separates Register Wiedervorlagen (Stufe aktiv) sowie quer liegende Beratungsaufträge (feine Ebene je Produkt), Dokumente & Unterschriften, Zeiten & Abrechnung und Verlauf (Register mit stufe: null).
• Aktenreife (server/src/domain/aktenreife.ts): strukturierte Mängelpunkte je Lifecycle-Stufe mit Schwere; nur blockierend verhindert die Reife — offene Wiedervorlagen sind hinweis (D-41).
• Nächste Schritte (server/src/domain/naechste-schritte.ts, D-46): dieselben Mängel als klickbare Handlungen (blockierend zuerst) — True North #2 als Handlung, nicht nur Diagnose.
• Cockpit "Fokus/Leitstand" (D-35, MED-D-151): mandantenübergreifende Sicht "wo steht wer · was ist fällig" — Leitstand-Lanes = Lifecycle-Stufen (Lead·Onboarding·Aktiv·Ruhend, Archiviert ausgeblendet), je Karte zusätzlich eine kompakte Auftrag-Status-Chip-Zusammenfassung (z. B. "2 Aufträge · 1 Beratung · 1 Unterschrift") — löst das in §2 beschriebene Mehrfach-Auftrag-Problem direkt in der Darstellung.

5. Wie wir UNTERSTÜTZEN (Orchestrierung — der eigengebaute Kern, G-1)

• Lifecycle-Guard (server/src/domain/lifecycle.ts, MED-D-151, löst die frühere Phasen-Engine domain/phasen.ts ab): genau ein Guard — Eintritt in aktiv aus lead/onboarding verlangt vollständiges Onboarding und keine offenen Unterschriften (personenweite, nicht auftragsgefilterte Fakten, abgeleitet, G-2); jeder andere Übergang (inkl. lead→onboarding, alles zu/von ruhend/ archiviert) bleibt frei. Rückwärts als Korrektur immer möglich (Undo-Toast, MED-D-24).
• Mandanten-Playbook (admin-editierbar, D-17, auf 2 Einträge reduziert seit MED-D-151): beim Eintritt in onboarding (nachfassen) bzw. aktiv (jahrescheck) entstehen idempotent die passenden Folge- Wiedervorlagen (R5).
• Auftrag-Status-Playbook (Code-Katalog, domain/auftrag-playbook.ts §AUFTRAG_STATUS_PLAYBOOK, MED-D-151): beim Statuswechsel eines Beratungsauftrags nach beratung (termin) bzw. unterschrift (ruecklauf) entstehen ebenso idempotent Folge-Wiedervorlagen, an den Auftrag gebunden — löst die zwei entsprechenden Einträge ab, die vor MED-D-151 im Mandanten-Playbook lagen.
• Die Wiedervorlage-Tabelle ist die einzige durable Arbeits-Queue — jede Quelle (manuell · onboarding_item · dokument_frist · playbook · befund · formular) trägt einen stabilen quelleRef (idempotent).
• Formular-Vorgänge (server/src/domain/formular-vorgaenge.ts, MED-D-67): einheitliches Vorgangs-Modell über die öffentlichen Token-Strecken — Parallel-Limit, Öffnungs-Tracking, Ausfüllgrad, SLA weich/hart, Sichtungs-Wiedervorlage bei Einreichung.
• Feld-Sichtung & Korrektur-Schleife (domain/feld-sichtung.ts, MED-D-89): der verbindliche Regelkreis aller Kundenformulare — der Kunde reicht ein, ein Mitarbeiter sichtet jedes Feld (approve/deny, eine Ablehnung braucht einen Grund), der Kunde erhält Feedback per Mail und die abgelehnten Felder werden über denselben Link zur Korrektur wieder geöffnet (akzeptierte bleiben gesperrt), bis alles akzeptiert ist — jede Entscheidung append-only auditiert (PII-arm, G-4).

6. Dokumente & Unterschriften — eine quer-liegende Achse (nicht ein Schritt)

Anforderung des Eigentümers: Dokumente/Unterschriften können an jeder Stelle des Prozesses nötig werden; jedes einmal erstellte Dokument muss lückenlos getrackt werden; und es soll möglich sein, frei geschriebene Dokumente ins Hauslayout zu setzen und zur Unterschrift zu geben.

Konsequenz fürs Modell: Dokumente & Unterschriften sind keine einzelne Phase, sondern eine achsen-übergreifende Achse — analog Zeiten & Abrechnung und Verlauf, quer sowohl zu den Lifecycle-Stufen als auch zu den Beratungsaufträgen. Sie werden als ein Dokument-Ledger geführt, das alle Einträge bündelt:

• Dokument (R3) — angeforderte/abgelegte Dateien (Referenz + Status + Ablage-Pfad),
• Dokumentgenerierung (R12) — aus dem Stammsatz erzeugte Hausdokumente,
• Signatur-Vorgang (R4) — E-Signatur mit eIDAS-Niveau.

Lebenszyklus je Dokument (append-only, auditiert G-4; "nie löschen"-Invariante der Ablage, MED-D-56):

• Nachverfolgung ist heute schon technisch da (R3-Status + nextcloudPfad, abgeleiteter signiert aus dem Signatur-Vorgang, alles auditiert) — die Lücke ist die Darstellung: heute im Register "Dokumente & Unterschriften" gebündelt (ein Ort, MED-D-80), aber Beratungsdoku/Formular-Rückläufe leben im Register „Beratungsaufträge" daneben. Ledger-Feinschliff (dedup'ter Einzel-Ledger) bleibt Fahrplan-Rest.
• Aktenreife bleibt stufen-genau: Onboarding-Pflichtbelege gaten weiter die Lifecycle-Stufe onboarding (die Reife-Zuordnung in aktenreife.ts ist unabhängig von der Anzeige-Achse). Nur die Darstellung wird quer, die Gates bleiben, wo sie fachlich hingehören.
• Freitext → Layout → Unterschrift (P4): frei geschriebener Text → in das bestehende Block-/PDF-Layout (server/src/pdf/pdf-dokument.ts#erzeugePdf, gleiche Marke wie die Vorlagen) → als R3-Dokument abgelegt (damit automatisch im Ledger + auditiert) → über den vorhandenen Signatur-Weg zur Unterschrift.

7. Abgleich — Prozessbild des Eigentümers ↔ gebautes Modell

Der Eigentümer beschreibt den Prozess als: Onboarding → Beratung (Gesprächsnotizen) → Unterschriften/Dokumente → Wiedervorlagen → Zeiten & Abrechnung → Verlauf. Gegenüberstellung:

Schritt (Prozessbild)	Register / Achse (gebaut)	Modul	Divergenz / Maßnahme
(Erstkontakt)	Register Erstkontakt (Lifecycle-Stufe lead)	R1/DM	Lead-Stufe; für Nicht-Leads defensiv (Default-Register = aktuelle Stufe).
Onboarding	Register Onboarding	R2/R3	deckungsgleich.
Beratung (Gesprächsnotizen)	Register Beratungsaufträge = Beratungsprotokolle (R6) je Auftrag	R6 / R11	seit MED-D-151 in „Beratungsaufträge" gebündelt (vormals eigenes Register „Beratung"). Lücke: Gesprächsnotiz → Protokoll → Aufgaben (R11) fehlt → P5.
Unterschriften/Dokumente	quer-liegende Dokument-Achse (statt Split Onboarding/Unterschrift)	R3/R12/R4	P2 gebaut (Ledger + "an jeder Stelle") + P4 gebaut (Freitext); Rest: dedup'ter Einzel-Ledger (§6).
Wiedervorlagen	eigenständiges Register Wiedervorlagen (Lifecycle-Stufe aktiv, vormals „Betreuung")	R5	P3 gebaut (MED-D-80): offene/überfällige WV am Register sichtbar gezählt (neutraler Hinweis-Badge). Umbenannt (MED-D-151, sprechenderer Name, G-3).
Zeiten & Abrechnung	quer-liegendes Register Zeiten & Abrechnung	R13	deckungsgleich.
Verlauf	quer-liegendes Register Verlauf (Audit)	R8	deckungsgleich.

8. Fahrplan (priorisiert)

Prio	Schritt	Umfang	Anker
P1	✅ erledigt (MED-D-79) — Vokabular vereinheitlichen: Achsen-Regel (§2) + Nachziehen in Lastenheft R2/§5.2 & MVP-Scope §4.2 ("Onboarding-Teilschritt")	docs-only	G-3, OP-DOCS-1, MED-D-79
P2	✅ gebaut (0.56.0, MED-D-80) — Dokumente & Unterschriften als quer-liegende Achse: Register "Dokumente & Unterschriften" (R3+R12+R4), "an jeder Stelle" erzeugbar; Gates bleiben	Client-Slice	G-3/G-4, MED-D-56, MED-OP-DOC-2
P3	✅ gebaut (0.56.0, MED-D-80) — Wiedervorlagen sichtbar: Register-Badge zählt offene WV (jeStufe.hinweis seit MED-D-151, neutraler Stil); reif-Semantik unverändert (D-41)	kleiner Code-Slice	True North #2, MED-OP-REG-1
P4	✅ gebaut (0.57.0, MED-D-81) — Freitext → Layout → Unterschrift: Entität Individualdokument (Entwurf → freigeben → Hauslayout-PDF/R3 → Unterschrift), eIDAS-Niveau explizit wählbar	mittlerer Slice	R12/R4, OP-DOCGEN-2 (Freitext-Teil), OP-SIGN-1
P5	🟡 Kern gebaut (0.58.0, MED-D-82) — Gesprächsnotizen/Meeting-Doku (R11): Entität Meeting (manuelles Protokoll) → Aufgaben ableiten (Fake-Auswerter, Mensch-im-Prozess) → Wiedervorlagen (R5, quelle='aufgabe', delegiert an R7); Aufgaben = Wiedervorlagen (G-2). Offen: echte Transkription (Standard-Tool + EU-Residenz/AVV)	großer Slice (Kunden-Prio 1)	W1/R11, OP-MEET-1, MVP-Scope Slice 9
P6	✅ gebaut (0.83.0, MED-D-151) — PROZESS_PHASE retiriert: dritte, redundante Achse entfernt, Mapping auf lifecycleStatus/Beratungsauftrag.status (§2/§3); erster Lifecycle-Guard; Auftrag-Status-Playbook; Cockpit-Chips lösen das Mehrfach-Auftrag-Problem	Domain+API+DB+Client-Slice	G-8, MED-D-95, MED-D-151

Stand: P1–P4, P6 ✅ gebaut; P5 Kern ✅ gebaut (0.58.0, MED-D-82). Offen: die echte Transkriptions-Anbindung (OP-MEET-1: Tool-Wahl + EU-Residenz/AVV, RISK-15) — heute nur quelle=manuell; plus template-basierte Individualvertrags-Ausformulierung + echte E-Signatur (MED-KB-5).

9. Compliance-Flags (proaktiv, DE/AT/CH)

• P4 (Freitext → Unterschrift) berührt eIDAS/ZertES: das Signatur-Niveau (SES/AES/QES) muss je Rechtswirkung begründet gewählt werden (OP-SIGN-1); formgebundene Verträge verlangen echte AES/QES (MED-KB-5), nicht die SES-Vorschau. Inhalts-Hash + Audit (G-4) sind Pflicht.
• Retention/Aufbewahrung (GoBD/§147 AO): der append-only Audit-Trail + die "nie löschen"-Ablage (MED-D-56) tragen das bereits.

10. Referenzen

System-Charakter.md · Akte-Struktur.md · Lastenheft.md §5 · Beratungsauftraege.md (Auftrag-Status-Achse, MED-D-95) · Unterschriften.md (eIDAS) · Dokumentenverwaltung-NextCloud.md · Meeting-Doku-und-Aufgaben.md (R11) · Decision-Log.md (MED-D-79, MED-D-151).