Ist-Analyse und Soll-Konzept
Die zwei Kapitel Ist-Analyse und Soll-Konzept sind das methodische Herz deiner Projektdokumentation. Hier zeigst du, dass du nicht einfach drauflosgebaut hast, sondern dass deine Lösung aus einer systematischen Bedarfs-Analyse hervorgeht. Prüfer:innen lesen besonders aufmerksam: Wie hast du den Bedarf erhoben? Welche Anforderungen ergaben sich daraus? Welche Lösungs-Varianten hast du überhaupt geprüft? Mit welchen Kriterien hast du entschieden? Wo ist die Wirtschaftlichkeit nachgewiesen? Wer hier sauber arbeitet, holt sich verlässlich 15-20 Punkte – wer es überspringt, bekommt nur eine durchschnittliche Note, auch bei brillanter Umsetzung. Diese Lektion zeigt dir die Methoden zur Ist-Erhebung (Interviews, Beobachtung, Dokumenten-Recherche), die MoSCoW-Priorisierung der Anforderungen, den Variantenvergleich mit Nutzwertanalyse, die Wirtschaftlichkeits-Rechnung (Make-or-Buy, ROI, Amortisation) sowie typische Antipatterns wie „Soll-Konzept ohne Ist-Bezug".
1) Von Ist zu Soll – der rote Faden
Beide Kapitel hängen logisch zusammen: das Ist liefert die Beobachtungen und Probleme, daraus werden Anforderungen, daraus Lösungs-Varianten, daraus die begründete Auswahl:
2) Methoden der Ist-Analyse
Du brauchst Fakten, keine Vermutungen. Vier bewährte Erhebungs-Methoden:
🗣Interview
Strukturierte Gespräche mit Stakeholdern (Anwendern, Ausbilder, IT-Leitung). Vorbereiten mit Fragenkatalog, protokollieren. Im Anhang als Interview-Notiz ablegen. Siehe K66 Aktives Zuhören.
👀Beobachtung
Anwender beim Arbeiten beobachten, Prozesse mitlaufen. Auch hier Notizen / Foto-Beweise als Anlage. Deckt oft Dinge auf, die in Interviews nicht erwähnt werden.
📂Doku-Recherche
Bestehende Doku auswerten: Netzwerkpläne, Verträge, Wartungs-Logs, Verfahrens-Anweisungen. Liefert die formale Basis. Sehe K65 IT-Dokumentation.
📊Messung & Daten-Analyse
Tickets der letzten 12 Mon. auswerten, Performance-Metriken, Auslastung, Mengen-Gerüste. Liefert harte Zahlen.
📋Workshop / Fokusgruppe
Mehrere Stakeholder gleichzeitig befragen. Effizient, deckt Konflikte auf. Aufwendig zu moderieren.
📝Fragebogen / Umfrage
Bei vielen Anwendern (> 20) sinnvoll. Strukturierte Auswertung möglich. Geringe Rücklaufquote bedenken.
Eine gute Ist-Analyse kombiniert mehrere Methoden – z. B. 3 Interviews mit Schlüssel-Anwendern + Doku-Recherche + Ticket-Auswertung. Dies wird im Bericht erwähnt: „Die Ist-Analyse stützt sich auf drei Interviews, eine Auswertung der Ticket-Historie 2024 und die Sichtung der vorhandenen Wartungs-Doku."
3) Anforderungen strukturieren (MoSCoW)
Aus der Ist-Analyse leitest du Anforderungen ab. Sie werden in funktionale (was die Lösung können soll) und nicht-funktionale (wie sie sich verhalten soll) unterteilt – und priorisiert. MoSCoW ist die Standard-Methode:
| Priorität | Bedeutung | Beispiel (Backup-Projekt) |
|---|---|---|
| MUST | Muss zwingend erfüllt sein. Ohne diese Anforderungen ist die Lösung nicht abnahmefähig. | Tägliches Backup aller Produktiv-Server; Restore-Test erfolgreich; DSGVO-Konformität |
| SHOULD | Soll erfüllt sein, falls möglich. Wichtige Anforderungen, die zur Not aufschiebbar sind. | Verschlüsselte Backups; Wiederherstellung in < 4h (RTO); Monitoring der Backup-Jobs |
| COULD | Wäre schön, gehört aber nicht zum Kern. Nice-to-have. | Self-Service-Restore für Anwender; Detail-Reports per E-Mail |
| WON'T | In diesem Projekt nicht – evtl. später. Wichtig zur Erwartungs-Klärung. | Backup von Endgeräten (separates Projekt geplant) |
Nicht-funktionale Anforderungen umfassen: Performance, Verfügbarkeit (z. B. RTO/RPO), Sicherheit, Skalierbarkeit, Wartbarkeit, Konformität (DSGVO, BSI-Grundschutz), Usability.
4) Lösungs-Varianten gegenüberstellen
Mindestens 2-3 Varianten vergleichen. Achtung: keine Schein-Alternativen („mit oder ohne Tippfehler"), sondern echte unterschiedliche Architektur-/Anbieter-Ansätze:
| Variante | Beschreibung | Vorteil | Nachteil |
|---|---|---|---|
| A · Veeam B&R On-Prem | Veeam-Server lokal, Backup auf NAS + Tape | Datenhoheit, hohe Performance, etablierte Lösung | Hohe Investitionskosten, eigene Wartung |
| B · BaaS (Backup-as-a-Service) | Cloud-Backup-Dienst, monatliche Gebühr | Keine Hardware, OpEx statt CapEx, Off-Site automatisch | Bandbreite, Kosten skalieren mit Datenmenge, US-Anbieter-Risiken |
| C · Hybrid | Primär-Backup On-Prem + verschlüsselte Cloud-Kopie | Schnelle Restores lokal + Off-Site-Schutz, DSGVO-konform | Komplexere Architektur, höhere Lizenz-Kosten |
5) Nutzwertanalyse
Die Nutzwertanalyse formalisiert die Bewertung mit gewichteten Kriterien. Sehr beliebt bei Prüfern, weil methodisch sauber:
| Kriterium | Gewicht | A · On-Prem | B · BaaS | C · Hybrid |
|---|---|---|---|---|
| Datenhoheit / DSGVO | 25 % | 10 → 2,50 | 4 → 1,00 | 9 → 2,25 |
| Investitionskosten (CapEx) | 15 % | 3 → 0,45 | 9 → 1,35 | 5 → 0,75 |
| Laufende Kosten (OpEx) | 15 % | 7 → 1,05 | 5 → 0,75 | 6 → 0,90 |
| Restore-Geschwindigkeit | 20 % | 9 → 1,80 | 5 → 1,00 | 8 → 1,60 |
| Off-Site-Schutz / Ransomware | 15 % | 4 → 0,60 | 9 → 1,35 | 10 → 1,50 |
| Wartungsaufwand | 10 % | 4 → 0,40 | 9 → 0,90 | 5 → 0,50 |
| Summe (max. 10) | 100 % | 6,80 | 6,35 | 7,50 |
6) Wirtschaftlichkeit – Pflicht in jeder Doku
Die Wirtschaftlichkeits-Rechnung zeigt, dass deine Lösung nicht nur technisch, sondern auch wirtschaftlich sinnvoll ist. Mehrere Bausteine:
Beispiel-Rechnung kompakt:
- Variante C: CapEx 8 000 € (Hardware) + 3 500 € (Lizenz Jahr 1) = 11 500 € einmalig
- OpEx jährlich: 2 800 € (Lizenz-Folgejahr) + 600 € (Cloud-Speicher) + 800 € (Wartung) = 4 200 €
- TCO 5 Jahre: 11 500 + 5 × 4 200 = 32 500 €
- Nutzen pro Jahr: 1 vermiedener Total-Ausfall (geschätzt 18 000 € Schaden × 30 % Wahrscheinlichkeit) = 5 400 €
- Amortisation: 11 500 ÷ (5 400 − 4 200) = ca. 9,6 Jahre – das ist lang, der Hauptnutzen liegt aber im Risiko-Schutz, nicht in barer Ersparnis. Das muss klar dargestellt werden.
7) Tipps für saubere Argumentation
- Zahlen, nicht Adjektive. „schneller" → wie viel schneller? In ms, h, %?
- Quellen nennen. Hersteller-Listen-Preise, IHK-Stundensätze, BSI-Empfehlungen. Mit Quellen-Verweis.
- Annahmen offen legen. „Es wird angenommen, dass…" – Prüfer akzeptieren Annahmen, wenn sie transparent sind.
- Bandbreiten zeigen. Best Case / Worst Case bei Schätzungen.
- Nicht zu detailliert. 3 Nachkomma-Stellen wirken pseudo-genau. Sinnvoll runden.
- Visualisieren. Balkendiagramm der TCO-Vergleiche, Tabelle der Nutzwertanalyse.
- Roter Faden. Jede Anforderung muss aus dem Ist hervorgehen, jede Variante muss die Anforderungen abdecken. Lücken sind problematisch.
8) Antipatterns
- Ist-Analyse als Firmenkundgebung. 1 Seite Firmen-Geschichte, kein konkreter Bedarf. Lösung: fokussiert auf den Projekt-relevanten Ausschnitt.
- Anforderungen kommen aus dem Hut. Keine Verbindung zur Ist-Analyse. Lösung: jede Anforderung explizit aus einer Ist-Beobachtung herleiten.
- Nur eine Variante. „Es gibt nur Veeam." Auch wenn am Ende eine Lösung passt – mindestens 2-3 betrachten.
- Schein-Alternativen. „Mit Doku oder ohne Doku" sind keine Varianten. Lösung: echte Unterschiede prüfen.
- Nutzwertanalyse manipuliert. Gewichte werden so gesetzt, dass die schon vorab geplante Variante gewinnt. Lösung: Gewichte vorher festlegen und begründen.
- Wirtschaftlichkeit „nicht relevant". Klassische Falle. Auch FISI muss wirtschaftlich denken.
- Nur CapEx, kein OpEx. Lösung sieht günstig aus, weil Folgekosten verschwiegen werden.
- Quellenlose Behauptungen. „Unser Server fällt 10 % aus" – woher? Lösung: Ticket-Statistik oder Monitoring-Auswertung als Beleg.
- Make-or-Buy ignoriert. Eigenbau wird nicht hinterfragt. Lösung: explizit prüfen, ob „kaufen" günstiger / besser ist.
- Soll-Konzept ohne Verbindung. Plötzlich kommt eine Lösung, die im Soll nicht abgeleitet wurde. Lösung: Soll baut nahtlos auf Ist auf.
Zusammenfassung
Ist-Analyse und Soll-Konzept sind das methodische Herz der Doku. Die Ist-Analyse erhebt mit mehreren Methoden (Interview, Beobachtung, Doku-Recherche, Messung) den aktuellen Zustand und identifiziert Schwachstellen. Daraus werden Anforderungen abgeleitet und per MoSCoW priorisiert. Mindestens 2-3 Lösungs-Varianten werden gegenübergestellt und mit einer Nutzwertanalyse (gewichtete Kriterien) bewertet. Die Wirtschaftlichkeits-Rechnung ist Pflicht – mit CapEx, OpEx, TCO, ROI, Amortisation, Make-or-Buy. Größter Fehler: Soll-Konzept ohne Bezug zur Ist-Analyse oder ohne saubere Variantenprüfung. Wer die Kette Ist → Anforderungen → Varianten → Nutzwertanalyse → Wirtschaftlichkeit → Soll sauber durchzieht, holt verlässlich Punkte.
Verwandte Lektionen: Aufbau Doku · Umsetzung · Zeitplanung · und mehrWeitere relevante LektionenTestberichtFazit & AnhängeBeispiel-DokuKlassisches PMAktives Zuhören (K66)Anbieter-Vergleich (K66)Wirtschaftlichkeit (K02)