Onboarding-Neubaustudie — radikale Vereinfachung (Greenfield)
Zielgruppen: Business/Management (Kernaussage + Hebel) · IT-Dev/Architektur (Ist-Inventar, Ziel-Architektur, Slice-Plan). Status: Richtung beschlossen (MED-D-291, 2026-09-13) — die 4 offenen Kundenfragen sind entschieden (§7); N2 gebaut (MED-D-292), N1 als nächster PR, N3–N5 später. Auslöser: „Onboarding gefühlt zu kompliziert — Neubaustudie, wie deutlich entschlacken?" Stand-Bezug:
0.130.0, 2026-09-13. True North: Ein einfacheres Onboarding beantwortet #1 („Wo steht der Kunde / was fehlt?") direkter und senkt gleichzeitig die Wartungslast.
1. Kernaussage (BLUF)
Das heutige Onboarding ist nicht funktional zu schwach, sondern strukturell zu breit: derselbe Zweck — „der Kunde gibt uns seine Daten + Dokumente + Einwilligung" — wird über fünf parallele Kundenwege und eine schwergewichtige Feld-für-Feld-Prüfmaschinerie gelöst. Ein Greenfield-Onboarding kollabiert das auf einen Link · einen geführten Fluss · eine Prüfung und streicht dabei ganze Konzepte (nicht nur Code). Erwartete Wirkung: weniger Kundenreibung, ~40–50 % weniger Onboarding-Code, weniger Begriffe im Kopf — bei gleichem Compliance-Niveau (DSGVO, eIDAS, Audit-Log bleiben).
Der 3-Schritte-Flow (MED-D-285) ist bereits der richtige Kern. Die Vereinfachung besteht darin, die anderen Wege darin aufgehen zu lassen, nicht neue zu bauen.
2. Ausgangslage (Ist) — woher die Komplexität kommt
2.1 Fünf Kundenwege für einen Zweck
| Weg | Datei (LoC) | Zweck | Eigenes … |
|---|---|---|---|
| Onboarding-Strecke | onboarding-public.component.ts (418) | Grunddaten + Einwilligung | Token · Kontext · Entwurf · Turnstile · 3 Schritte |
| Ausfüll-Formular | formular-public.component.ts (346) | einzelnes Formular zurückmelden | Token · Kontext · Sichtungs-Rücklauf |
| Dentmarking-Fragebogen | fragebogen-public.component.ts (451) | Betriebsdaten-Fragebogen | Token · Kontext · Blöcke |
| Lead-Formular | lead-public.component.ts (184) | Erstkontakt anlegen | eigener Kontext · Produkte |
| Self-Service-Portal (S0–S2, dormant) | portal-auth.ts (106) + Routen | persistenter Kundenzugang | Magic-Link · Session · Konto |
Dazu zwei getrennte Einladungs-Arten intern (mandant-einladungen.component.ts, 172): Stammdaten-
Einladung und Dokument-Upload-Link — zwei Links pro Kunde für denselben Onboarding-Schritt.
→ ≈ 1.400 LoC nur Kundenstrecken, jede mit eigener Kopie von Token/Kontext/Turnstile/Entwurf/Consent.
2.2 Schwergewichtige interne Maschinerie
- Feld-für-Feld-4-Augen (
feld-sichtung.ts, MED-D-89): jede Einreichung wird je Feld approve/deny gesichtet, jede Ablehnung braucht einen Grund, danach Mail-Feedback + Korrektur-Schleife über denselben Link. Mächtig — aber teuer pro Onboarding, und doppelt vorhanden (Formular-Sichtung und Portal-Übernahme-Vorschlag nutzen dieselbe Idee an zwei Stellen). - Stammdaten-Hash-Versionierung (
stammdaten-version.ts, 171): append-only, hash-verkettete Snapshots gegen eine fixeVERSIONIERTE_FELDER-Reihenfolge (pruefeVersionsKette). Für revisionssichere Beratungsdoku sinnvoll — im Erst-Onboarding aber Overhead (die Kette bremst sogar neue Felder, vgl. MED-D-284). - Provisionierung: Ablage-Referenzen werden aus Pflicht-Items erzeugt (
dokumente/provisionieren), Onboarding-Items mit 4-Tasten-Umschalter, „wo fehlt was?" abgeleitet.
2.3 Die eigentliche Wurzel
Nicht ein einzelnes Feature ist zu viel, sondern die fehlende Konsolidierung: submitted-vs-actual + 4-Augen + Token-Link + Consent existieren mehrfach nebeneinander statt einmal als geteilter Kern.
3. Zielbild (Greenfield) — ein Weg, ein Fluss, eine Prüfung
Drei Prinzipien:
- Ein Zugang. Das Portal (persistenter, passwortloser Magic-Link) wird der eine Kundenweg; die heutigen Einmal-Token-Strecken werden Spezialfälle desselben Kontos (Einmal-Login statt eigener App). Ein Link pro Kunde — nicht zwei (Stammdaten + Upload) + drei Strecken.
- Ein Fluss. Grunddaten → Dokumente → Einwilligung als eine Strecke (der MED-D-285-Stepper). Formular und Fragebogen werden Bausteine/Schritte dieses Flusses (dieselbe Feld-Engine), keine eigenständigen Apps.
- Eine Prüfung. Standard = Abschnitts-Freigabe („alles i. O." mit einem Klick), Ablehnung einzelner Felder als Ausnahme (der teure Feld-für-Feld-Pfad bleibt erhalten, ist aber nicht mehr der Default). Mail-Feedback nur, wenn wirklich etwas zurückgewiesen wird.
Datenmodell schlanker: ein versionierter Snapshot je Einreichung (Feld-Historie bleibt als abgeleitete Sicht, G-2) statt der per-Feld-Hash-Kette im Onboarding-Pfad.
4. Entschlackungs-Hebel (priorisiert)
| # | Hebel | Was verschmilzt/wegfällt | Wirkung | Aufwand/Risiko |
|---|---|---|---|---|
| H1 | Strecken konsolidieren | Formular + Fragebogen werden Schritte der Onboarding-Strecke (eine Feld-Engine, ein Kontext/Turnstile/Entwurf) | ★★★ (größter Effekt: ~700 LoC + 2 Begriffe weniger) | mittel — geteilte Bausteine sauber ziehen |
| H2 | Prüfung: Abschnitts-Freigabe | Feld-für-Feld-4-Augen wird Ausnahme; Standard = 1-Klick-Freigabe je Abschnitt | ★★★ (Backoffice-Klicks drastisch runter) | niedrig — feld-sichtung bleibt als Ausnahmepfad |
| H3 | Ein Zugang (Portal) | 5 Wege → 1 Konto; Token-Links = Einmal-Login desselben Kontos; eine Einladung statt zwei | ★★★ (weniger Kundenreibung, weniger Zustellwege) | mittel–hoch — Portal S3+ aktivieren, DSGVO/Go-Live-Gate |
| H4 | Versionierung entschlacken | 1 Snapshot je Einreichung statt per-Feld-Hash-Kette im Onboarding | ★★ (weniger Code, neue Felder ohne Kettenbruch) | mittel — Audit-Anforderung sauber wahren (G-4) |
| H5 | Datensparsamer Erst-Fluss | nur echte Pflicht-Grunddaten zuerst, Rest progressiv später | ★★ (kürzere Strecke, G-6) | niedrig |
| H6 | Eine Einwilligung (DocuSign) | SES-Sonderweg → DocuSign-Einverständnis (war als Slice C ohnehin geplant) | ★ (ein Consent-Mechanismus) | mittel — an OP-SIGN-1 gekoppelt |
5. Was BLEIBT (bewusst nicht wegwerfen)
- Compliance-Substanz: Token/Turnstile, EU-Residenz, append-only Audit-Log (G-4), Datensparsamkeit (G-6), Einwilligung mit Fassungs-Version. Vereinfacht wird die Struktur, nicht der Schutz.
- Der 3-Schritte-Flow (MED-D-285) als Kern — er ist schon richtig.
- Feld-Sichtung als Ausnahmepfad (nicht löschen — nur entthronen).
- submitted ≠ actual (4-Augen-Freigabe) als Prinzip — nur einmal statt mehrfach.
6. Migrationspfad (Slices, kein Big-Bang)
| Slice | Inhalt | Liefert |
|---|---|---|
| N1 | Formular + Fragebogen als Schritte der Onboarding-Strecke (geteilte Feld-Engine) — 1. Schritt ✅ (MED-D-293): geteilte Bausteine (Lade-Fehler-Auswertung + Turnstile-Bindung) in pub-bausteine.ts konsolidiert; offen: Item↔Token-Vorgang-Link (Datenmodell-Referenz) + Feld-Engine-Verschmelzung | ein Kundenweg statt drei |
| N2 ✅ | Prüfung auf Abschnitts-Freigabe umstellen (Feld-Sichtung = Ausnahme) — gebaut (MED-D-292) | drastisch weniger Backoffice-Klicks |
| N3 | Portal als einziger Zugang, Token = Einmal-Login; eine Einladung | ein Link pro Kunde |
| N4 | Versionierung im Onboarding auf 1 Snapshot/Einreichung | schlankeres Datenmodell |
| N5 | Consent → DocuSign (mit OP-SIGN-1) | ein Einwilligungs-Mechanismus |
Empfehlung: mit N1 + N2 starten — größter Vereinfachungseffekt bei geringem Risiko (rein Client-/Prüf-Umbau, keine Auth-/Compliance-Umstellung). N3 (Portal) folgt, wenn der Go-Live-Gate (DSGVO/AVV, MED-KB-13) steht.
7. Kundenfragen — entschieden (MED-D-291, 2026-09-13)
- Zugang: ✅ Portal-Konto + Token als Einmal-Login — das persistente Konto wird der eine Kundenweg, die Token-Strecken werden Einmal-Logins desselben Kontos. Treibt H3 → Slice N3 (nach dem DSGVO/AVV-Go-Live-Gate MED-KB-13, nicht sofort).
- Prüfung: ✅ Abschnitts-Freigabe als Standard — 1-Klick „alles i. O.", Feld-für-Feld-Ablehnung bleibt Ausnahme. Treibt H2 → Slice N2 gebaut (MED-D-292).
- Einwilligung: ✅ SES vorerst beibehalten — DocuSign-Umstellung erst Slice N5 (an OP-SIGN-1 gekoppelt). Treibt H6.
- Pflicht-Grunddaten: ✅ minimal + progressiv (nur echte Pflicht zuerst, G-6). Nutzer-Zusatz: der Betreuer muss angeben können, was jetzt dringend gebraucht wird — und das soll gruppiert aus den gebuchten Beratungsmandaten hervorgehen (neuer offener Punkt MED-OP-ONB-1). Treibt H5 → Teil von Slice N1.
Richtung beschlossen; die Slices werden als
MED-D-ngebaut. Umsetzungsreihenfolge: N2 (fertig) → N1 (nächster PR) → N3/N4/N5 später.