craftvia/docs/wizard-uebergabe/01_Planung/Onboarding-Wizard-Machbarkeitsanalyse.md

Onboarding-Wizard — Machbarkeitsanalyse (Product Owner)

Bewertung des Berater-Fahrplans (Onboarding_Wizard_Fahrplan_Detail.md) gegen den dokumentierten Funktionsstand (HANDOVER-PM.md, Stand 2026-07-20). Ziel: Umsetzbarkeit, Wiederverwendung vorhandener Funktionen, neue Funktionen, Komplexitäten — als Grundlage für die anschließende Aufgaben-/Epic-Definition.

Status-Legende: ✅ Vorhanden (direkt nutzbar) · 🟡 Teilweise (erweitern) · 🟥 Neu (bauen) Aufwand: S ≤ 1 Tag · M 2–4 Tage · L > 1 Woche (Entwicklung; Fachcontent separat)

---

1. Gesamturteil

Der Wizard ist umsetzbar — und sitzt auf einem für dieses Vorhaben ungewöhnlich starken Fundament. Rund zwei Drittel der fachlichen Bausteine existieren bereits produktiv (Assets/BIA, Risikoanalyse, Richtlinien-/Template-Engine mit Control-Mapping, importierter VDA-ISA-Katalog mit 316 Anforderungen/45 Controls, AL2/AL3-Schalter, Vier-Augen-Freigabe, Lieferanten-Reifegrad-/Gate-Logik, Coverage-Matrix, Audit-Log, Mandantenfähigkeit).

Der Wizard ist damit weniger „neues Modul" als vielmehr eine geführte Orchestrierung vorhandener Module plus einige neue Quer­schnitts-Engines. Der eigentliche Aufwand liegt — wie der Fahrplan selbst richtig betont — nicht in der Software, sondern im Fachcontent (regelfähige Vorlagen, VDA-Risiko-Katalog, Umsetzungshinweise, Reifegrad-Logik). Das ist der kritische Pfad und zugleich die Stelle, an der die GEFIM-Projekt-DNA (~100 Projekte) zum Tragen kommt.

Drei Dinge müssen früh und sauber gebaut werden, sonst werden sie später teuer nachgezogen: (1) ein generisches Aufgaben-Modul, (2) der generische Validierungs-Workflow, (3) der Regel-/Mapping-Layer. Sie sind die Klammer um alle Schritte.

---

2. Querschnittsmechaniken (Kap. 2 des Fahrplans)

Mechanik	Status	Vorhanden (wiederverwendbar)	Neu zu bauen	Aufwand	Risiko
2.1 Validierungs-Workflow	🟡	Vier-Augen-Freigabe Richtlinien (Entwurf→In Freigabe→Freigegeben), Lieferanten-ISB-Reifegrad-Freigabe, RBAC, Audit-Log	Generisches Status-/Review-Modell über alle Objekttypen (Modul/Richtlinie/Risiko/Control-Bewertung), Rolle „externer Berater" als Validierer, Kommentare, „unbestätigt zählt nicht" in der Auswertung	M	Querschnitt — früh bauen, nicht anflanschen
2.2 Umsetzungshinweise	🟡→🟥	implementation-Feld je Anforderung im Katalog, Anwender-Handbuch (kuratiert, Deep-Links)	Strukturiertes Hinweis-Modell (org/tech/Nachweise/Vorlagen-Verweis/Ressourcenindikation), Scope-/Antwort-Filter, Inline-Panel	Backend S · FE S · Content L	Content-Flaschenhals (SME)
2.3 Maßnahmen → Aufgaben-Modul	🟡	Maßnahmen-Kanban (risikobezogen), berechnetes Restrisiko	Generisches Aufgaben-Objekt (Typ/Verantwortlich/Fälligkeit/Priorität/Ressourcen/Herkunft/Verknüpfung Control·Risiko·Dok·Asset), Auto-Vorschlag aus Triggern + Bestätigung	M–L	Keystone — alle Schritte hängen daran
2.4 Audit-Trail & Versionierung	🟡	Audit-Log vorhanden	Echte Versionierung (Richtlinien-Diff ist offen), Versionierung von Katalog/Templates/Risiko-Katalog + Instanz-Referenz + Update-Propagation	M–L	Verzahnt mit offener „Versionierung+Diff" & destruktivem Re-Import

---

3. Fachliche Bausteine / Datenobjekte (Kap. 3)

Baustein	Status	Vorhanden	Neu / Lücke	Aufwand
Control-Katalog VDA ISA	✅	Import 316 Anforderungen / 45 Controls, je Anforderung adressierbar, Typen MUSS/SOLL/HOHER/SEHR HOHER	Ggf. explizite AL2/AL3-Kennzeichnung je Anforderung sichtbar machen (Flags vorhanden)	S
Template-Bibliothek	✅	28 Dokumente, Platzhalter/Variablen, optionale Klauseln via {{#if}}, Control-Verknüpfung, Freigabe	Regel-Tagging über Feature-Flags hinaus (Scope/Antwort-getrieben)	S–M
Upload eigener Dokumente	🟡	(geplant) Word-Upload als Block-Modell + Anhang, versioniert	Control-Zuordnung des Uploads in die Nachweislage; Upload selbst ist noch offen	M
Fakten-/Fragemodell	🟡	Variablen-Pflegestelle, Stammdaten (Settings) → ISMS-Variablen	Dynamischer, bedingter Fragebogen als wiederverwendbare Faktenobjekte	M
Risiko-Katalog	🟡	Bedrohungs-/Schwachstellen-Kataloge, Risikoregister, Control-Verknüpfung	Kuratierter Standard-/VDA-Risiko-Katalog (vordefiniert, erweiterbar)	Backend M · Content L
Regel-/Mapping-Layer	🟡	Handlebars-Flags, Variablen-Mapping, Lieferanten-Anforderungs-Engine (Schutzbedarf→Stufen)	Generalisierung: Antwort → betroffene Controls/Assets/Risiken (nicht nur Dokument-Klauseln)	L
Reifegrad-/Gap-Engine	🟡	Coverage-Matrix (Control↔Dokument), Lieferanten-Reifegrad-Freigabe, Gate→Risiko	Control-Scoring aus Belegen + Markierung offener Teilanforderungen	Backend M–L · SME M

---

4. Die neun Schritte (Kap. 4)

Schritt	Status	Trägt auf vorhandenem auf	Neu zu bauen	Aufwand
1 Scoping	🟡	AL2/AL3-Schalter (global + Override), TISAX-Level in Settings	Scope-Objekt (Prüfziele/Standorte/Geltungsbereich/Ausschlüsse) + Filterung der Control-/Template-/Risiko-Sets	FE S · Backend M
2 Kontextaufnahme	🟡	Stammdaten→Variablen	Geführter, bedingter Fragebogen + wiederverwendbare Faktenobjekte + Propagation	M
3 Rollen & Verantwortlichkeiten	🟡	RBAC/Rollen je Mandant, RACI-Matrix (Lieferanten)	ISMS-Rollenmodell (GF/ISB/DSB/IT), Funktionstrennungs-Prüfung, Rollen-Platzhalter in Dokumenten (ISB-Bestellung)	Backend M · FE S
4 Richtlinien & VA	✅🟡	Template-Tailoring (a) voll: variablenbasiert, Klausel-Ein/Ausblendung, Freigabe	(b) Upload+Control-Mapping (Upload offen); (c) „später erstellen" → Aufgabe (hängt an 2.3)	(a) ✅ · (b) M · (c) S
5 Asset-Inventar	✅	Assets & BIA: C/I/A, Schutzbedarf, Eigentümer, Vererbung, Abhängigkeiten, Risiko-Verknüpfung	„unvollständig/kein Eigentümer" → Aufgabe (Trigger)	S
6 Risikomanagement	✅🟡	5×5-Heatmap, Register, Behandlung, Maßnahmen, Control-Verknüpfung	VDA-Risiko-Katalog-Auswahl; Maßnahme→Aufgabe (2.3); Methodik konfigurierbar (siehe Offen #2)	M
7 Control-Zuordnung & Reifegrad	🟡→🟥	Coverage-Matrix, Beleg-Verknüpfung, Lieferanten-Reifegrad-Muster	Control-Assessment-Oberfläche (SoA ist bisher Platzhalter) + Reifegrad-Selbsteinschätzung + Gap-Markierung je Teilanforderung	Backend L · FE L · SME L
8 Gap- & Maßnahmenableitung	🟥	Ergebnisse aus 6/7	Aggregation/Dedup/Priorisierung → konsolidierte Gap-Liste (hängt an 2.3)	M
9 Assessment-Readiness	🟥	validierte Objekte, Coverage-Daten	Reifegrad-Dashboard + vorausgefüllte VDA-ISA-Katalogsicht + Export (koppelt an offenen DOCX/PDF-Export)	Backend M · FE L
Wizard-Shell (implizit)	🟥	—	Geführter Multi-Step-Flow: Zustand, Fortschritt, Gates, Wiederaufnahme, „bestätigt/unbestätigt"-Propagation	M–L

---

5. Was wirklich neu gebaut werden muss (verdichtete Liste)

1. Wizard-Shell / State-Machine (Flow, Fortschritt, Gates, Resume). 🟥 M–L
2. Generisches Aufgaben-Modul (2.3) — Keystone. 🟡→ M–L
3. Generischer Validierungs-Workflow (2.1) inkl. externer-Berater-Rolle. 🟡→ M
4. Regel-/Mapping-Layer generalisiert (Antwort→Controls/Assets/Risiken). 🟡→ L
5. Scope-Objekt + Filter-Engine (Schritt 1). 🟥 M
6. Dynamischer Fragebogen (Schritt 2). 🟥 M
7. ISMS-Rollenmodell + Funktionstrennung (Schritt 3). 🟥 M
8. Control-Assessment / Reifegrad-Gap-Engine (Schritt 7, SoA-Surface). 🟥 L
9. Gap-Konsolidierung (Schritt 8). 🟥 M
10. Assessment-Readiness-Dashboard + Export (Schritt 9, koppelt an DOCX/PDF-Export). 🟥 L
11. Umsetzungshinweis-Content-Modell + Inline-Panel (2.2). 🟡→ Backend/FE S, Content L
12. Versionierung/Diff + Update-Propagation (2.4; löst zugleich offenen destruktiven Re-Import). 🟡→ M–L

Direkt wiederverwendbar (kaum/kein Neubau): Assets/BIA · Risikoanalyse (Kern) · Richtlinien-Template-Engine · Control-Katalog VDA-ISA · AL2/AL3-Schalter · Vier-Augen-Freigabe (als Muster) · Coverage-Matrix · Lieferanten-Anforderungs-/Reifegrad-Engine (als Muster) · Audit-Log · Multi-Tenant/RBAC · Stammdaten→Variablen.

---

6. Größte Komplexitäten & Risiken (priorisiert)

1. Fachcontent ist der kritische Pfad (bestätigt der Fahrplan selbst): regelfähige Vorlagen, VDA-Risiko-Katalog, Umsetzungshinweise je Teilanforderung, Reifegrad-Logik. Muss parallel und früh von der Beratung erstellt werden — sonst blockiert er M3/M4/M5/M7.
2. Regel-/Mapping-Engine (Generalisierung). Heute: Klausel-Flags + Variablen + Lieferanten-Engine. Neu: eine Antwort steuert Dokument-Klauseln und Control-Relevanz und Risiko-/Asset-Bezug. Architektur-Kernrisiko — Regel-Syntax und Test­barkeit früh festzurren.
3. Control-Assessment/Reifegrad (Schritt 7). Das „SoA & Controls"-Modul ist bisher nur Platzhalter; hier entsteht die eigentliche Assessment-Oberfläche. Größter einzelner FE/Backend-Block.
4. Versionierung & Update-Propagation. Solange Re-Import destruktiv ist und Richtlinien keine echte Versionierung haben, sind laufende Kundeninstanzen bei Katalog-/Template-Updates gefährdet. Muss vor „Katalog lebt beim Kunden" gelöst sein.
5. Keystones Aufgaben-Modul & Validierungs-Workflow früh, sonst teurer Umbau (Schritte 3–9 hängen daran).
6. Export/North-Star (vorausgefüllter VDA-ISA-Katalog) koppelt an den offenen DOCX/PDF-Export.

---

7. Antworten auf die offenen Entscheidungspunkte des Fahrplans (Kap. 7), PO-Sicht

1. Upload-Gap-Check: Start mit manueller Control-Zuordnung (deckt sich mit dem bereits geplanten Word-Upload); automatischer Inhalt↔Anforderung-Abgleich später als KI-Ausbaustufe (koppelt an geplanten „KI-Wizard").
2. Risiko-Methodik: mandantenspezifisch konfigurierbar, aber zuvor die zwei bestehenden Matrizen (5×5 Risikoanalyse / 4×4 FB-80-04 im Richtlinienmodul) auf eine zentrale Skala vereinheitlichen (steht bereits als offener Punkt).
3. Versionierung/Propagation: nicht-destruktives Update mit Diff und expliziter Übernahme je Instanz (löst zugleich den destruktiven Re-Import). Voraussetzung für „Katalog beim Kunden".
4. Validierungs-Granularität: pro Objekt (einzelne Richtlinie/Risiko/Control-Bewertung) plus Modul-Gate — die Freigabe-Logik ist heute schon objektbezogen (Richtlinien) und wird generalisiert.
5. Aufgaben-Modul: existiert nur teilweise (Maßnahmen-Kanban, risikobezogen) → muss generalisiert werden; die Task-Erzeugung ist mitzuplanen (Keystone).
6. Reifegrad-Vorschlag: regelbasiert vorgeschlagen, mit Pflicht zur Bestätigung durch den Bearbeiter (entspricht dem vorhandenen Lieferanten-Reifegrad-Freigabe-Muster).

---

8. Empfohlene Reihenfolge (für die Aufgaben-Definition)

Angelehnt an M1–M7 des Fahrplans, sortiert nach Abhängigkeit und Wiederverwendung:

1. Querschnitt-Keystones zuerst: Aufgaben-Modul (2.3), Validierungs-Workflow (2.1), Versionierung/Diff (2.4), Wizard-Shell. (sonst später teurer Umbau)
2. Regel-/Scope-Fundament: Scope-Objekt + Filter (Schritt 1), Regel-/Mapping-Layer, Fragebogen (Schritt 2).
3. Wiederverwendung einklinken: Richtlinien (Schritt 4, größtenteils vorhanden), Assets (Schritt 5, vorhanden), Risiko (Schritt 6, Kern vorhanden + VDA-Katalog).
4. Neuer Kern: Control-Assessment/Reifegrad (Schritt 7), Gap-Konsolidierung (Schritt 8).
5. Output: Assessment-Readiness-Dashboard + Export (Schritt 9).
6. Durchgängig parallel: Fachcontent (SME/Beratung) + Umsetzungshinweise (2.2).

---

9. Nächster Schritt

Auf dieser Basis die Entwickler-Aufgaben als Epics/Stories definieren — vorgeschlagene Epic-Schnitte: E1 Aufgaben-Modul · E2 Validierungs-Workflow · E3 Wizard-Shell & Navigation · E4 Scope & Regel-/Mapping-Layer · E5 Fragebogen/Fakten · E6 ISMS-Rollen & Funktionstrennung · E7 Richtlinien-Anbindung (Upload/Control-Mapping) · E8 Risiko-Katalog & -Anbindung · E9 Control-Assessment/Reifegrad-Gap · E10 Gap-Konsolidierung · E11 Assessment-Readiness/Export · E12 Versionierung/Propagation · E13 Umsetzungshinweise (Content+Panel) · C1 Fachcontent (querlaufend).

Offen für die Feinspezifikation: Regel-Syntax, Aufgaben-Objekt-Schema, Reifegrad-Scoring-Formel, Export-Format des VDA-ISA-Katalogs. Diese vier zuerst festzurren — sie determinieren den Rest.