Ist-Analyse dokumentieren

Die Ist-Analyse ist das erste inhaltliche Kapitel deiner Doku und legt das Fundament für alles, was danach kommt. Sie beantwortet die Frage: Wie sieht es aktuell aus, und welche Probleme oder Anforderungen treiben uns zu diesem Projekt? Ohne saubere Ist-Analyse hängt das Soll-Konzept in der Luft – die Prüfenden bemerken das sofort und werten ab.

Diese Lektion zeigt dir, welche Inhalte in die Ist-Analyse gehören, welche Methoden hilfreich sind (W-Fragen, SWOT, Stakeholder-Analyse), wie ausführlich es sein muss und wie du häufige Fallen vermeidest. Die Ist-Analyse ist typisch 1–1,5 Seiten lang – kurz genug, dass man sie schnell schreiben kann, wichtig genug, dass sie dichten Inhalt braucht.

1) Was in die Ist-Analyse gehört

Die Ist-Analyse beschreibt drei Dinge sauber und sachlich: die technische Ausgangs­lage, die aktuellen Probleme oder Schwächen und die Anforderungen, die sich daraus für das Projekt ergeben. Sie enthält noch keine Lösungen – Lösungen kommen im nächsten Kapitel.

• Aktuelle Situation: was ist installiert, wie viele Nutzer, welche Systeme, welche Verfahren? Konkrete Zahlen, keine vagen Beschreibungen
• Beteiligte Personen / Stakeholder: wer nutzt das System heute, wer ist betroffen vom Projekt
• Schwächen / Probleme: was läuft schlecht, was kostet Zeit, was ist riskant? Mit konkreten Beispielen
• Anforderungen: was muss die neue Lösung können (funktional und nichtfunktional)?
• Rahmenbedingungen: Budget, Zeitrahmen, gesetzliche Vorgaben (z. B. DSGVO), bestehende Systeme, die weiterlaufen müssen

2) Die W-Fragen-Methode

Eine bewährte Technik, um die Ist-Analyse strukturiert anzugehen, sind die klassischen W-Fragen. Wenn du jede dieser Fragen für dein Projekt sauber beantwortest, hast du die wichtigsten Inhalte beisammen:

Diese Fragen kannst du auch wörtlich als Zwischen­überschriften in der Doku nutzen, falls du Struktur brauchst – wirken aber selten gut. Besser: die Antworten in einen flüssigen Text einbauen, gegliedert nach den oben genannten 5 Inhalts­blöcken (Situation, Stakeholder, Probleme, Anforderungen, Rahmen).

3) Stakeholder-Analyse

Stakeholder sind alle Personen oder Gruppen, die vom Projekt betroffen sind oder es beeinflussen können. Eine Stakeholder-Analyse erkennt sie früh und ordnet sie nach Interesse und Einfluss. Daraus ergeben sich Kommunikations­strategien.

4) Ist-Zustand visualisieren

Eine einfache Skizze des Ist-Zustands wertet die Doku enorm auf. Sie macht in einem Bild klar, was sonst zwei Absätze Text wären. Beispiel für ein typisches Netzwerk-Ist-Bild:

Ein gutes Ist-Diagramm zeigt nicht nur die Komponenten, sondern markiert die Problemstellen – mit Symbolen, Farben oder Notizen. So sieht der Prüfer sofort, wo du den Hebel ansetzen wirst. Wichtig: das Bild muss im Text referenziert werden („wie in Abb. 1 ersichtlich…").

5) Probleme strukturiert auflisten

Eine Liste der konkreten Probleme mit Beschreibung und Schweregrad wirkt sehr professionell. Sie ist gleichzeitig die Grundlage für die Soll-Konzept-Diskussion – jedes Problem wird im Soll-Konzept gelöst.

Diese Form hat den großen Vorteil, dass du im Soll-Konzept später jedes Problem konkret mit „adressiert durch…" verknüpfen kannst. So entsteht eine durchgehende Argumentations­kette von Ist über Soll bis Realisierung – genau das, was Prüfende sehen wollen.

6) Anforderungen ableiten

Aus den Problemen leiten sich die Anforderungen ab. Man unterscheidet zwei Arten – die Trennung ist klassischer Industrie­standard und wird in der Doku gerne gesehen:

7) SWOT-Analyse

Bei größeren Projekten oder strategischen Themen ist eine SWOT-Analyse hilfreich – sie betrachtet Stärken, Schwächen, Chancen und Risiken. Für eine kurze IHK-Doku ist sie nicht zwingend, aber bei Themen mit Make-or-Buy-Entscheidung oder Cloud-Migration wirkt sie sehr professionell.

8) Erhebungs­methoden für die Ist-Analyse

Wie kommst du an die Informationen für die Ist-Analyse? Eine Mischung aus verschiedenen Methoden:

• Interviews mit Stakeholdern: 15–30-Min-Gespräche mit Auftraggeber:in, IT-Leitung, Endnutzenden. Vorab Frageliste vorbereiten
• Beobachtung im Tagesgeschäft: einen Tag mitlaufen, schauen, wie Prozesse tatsächlich gelebt werden – oft anders als beschrieben
• System-Inventur: Hardware-Liste, Software-Bestand, Lizenzen, Netzwerkpläne durchgehen
• Dokumenten-Analyse: vorhandene Konzepte, Verfahrens­anweisungen, alte Projekt­dokumente
• Log-Auswertung: bei IT-Systemen oft sehr aufschlussreich – wie oft fallen Systeme aus, was sind die häufigsten Fehler?
• Messung von Kennzahlen: Performance-Daten, Auslastung, Reaktionszeiten

In der Doku reicht es, einen oder zwei Sätze zu deinen Erhebungs­methoden zu schreiben – das zeigt, dass du nicht „aus dem Bauch" entschieden hast. Beispiel: „Die Ist-Analyse stützt sich auf Gespräche mit der IT-Leitung, eine zwei­wöchige Beobachtung der bestehenden Backup-Routine sowie auf System-Logs der letzten 6 Monate."

9) Häufige Fehler in der Ist-Analyse

• Zu wenig konkrete Zahlen: „Die IT ist veraltet" reicht nicht. Konkret: „Server X läuft seit 2015 auf Windows Server 2012 R2 (Support endete 2023)"
• Lösungs­vorschläge in der Ist-Analyse: Soll-Konzept gehört ins nächste Kapitel. In der Ist-Analyse nur Beschreibung, keine Empfehlungen
• Schönfärben oder dramatisieren: sachlich neutraler Ton. Weder „alles ist katastrophal" noch „eigentlich läuft schon alles"
• Keine Stakeholder benannt: man wundert sich, wer das Projekt eigentlich braucht. Heilung: Auftraggeber, Endnutzende, IT-Team kurz benennen
• Anforderungen vermischt: funktionale und nichtfunktionale durcheinander aufgelistet. Klar trennen
• Kein Ist-Diagramm: bei IT-Projekten fast immer hilfreich. Mindestens eine einfache Skizze oder Tabelle
• Triviales beschrieben: „Die Mitarbeitenden nutzen Computer mit Bildschirm und Tastatur." Bringt keine Punkte – nur Relevantes nennen
• Quellen vergessen: wenn du Zahlen aus Logs, Interviews oder Dokumenten nutzt – in den Anhang verweisen oder Quelle nennen

10) Tipps für eine starke Ist-Analyse

1. Mit konkreten Zahlen beginnen: „8 Server, 25 Clients, 300 GB Daten, 4 GB tägliches Wachstum" wirkt sofort kompetent
2. Eine zentrale Skizze einbinden: zeigt in einem Bild die Ausgangs­lage – wertvoller als eine halbe Seite Text
3. Stakeholder kurz benennen: ein einziger Satz reicht oft, zeigt aber, dass du nicht im luftleeren Raum arbeitest
4. Probleme priorisieren: nicht alle Probleme sind gleich wichtig. Schwere­grad nennen (kritisch / erhöht / moderat)
5. Anforderungen funktional/nichtfunktional trennen: zeigt System­engineering-Verständnis
6. Erhebungs­methoden nennen: ein Satz dazu macht die Quelle nachvollziehbar
7. Brücke zum Soll-Konzept schlagen: am Ende der Ist-Analyse mit einem Satz andeuten, was im Soll-Konzept zu lösen ist
8. Sachlich neutralen Ton: weder vorwurfsvoll noch beschönigend – analytisch, professionell

11) Beispiel-Eröffnung einer Ist-Analyse

Damit du eine Vorstellung vom Ton bekommst, hier ein Beispiel für die ersten Sätze einer Ist-Analyse eines Backup-Projekts:

„Die XY GmbH betreibt am Standort Musterstadt einen Bestand aus 8 produktiven Servern (Mischung aus Linux- und Windows-Systemen) sowie 25 Client-Arbeitsplätzen. Geschäfts­kritische Daten – darunter Kunden­daten, Produktions­daten und das Lohn­buchhaltungs­system – werden in einem Volumen von ca. 300 GB im täglichen Betrieb erzeugt und liegen verteilt auf drei Datei­servern. Die aktuelle Sicherung erfolgt manuell wöchentlich auf USB-Festplatten, die anschließend im Server­raum verschlossen werden. Ein zentrales, automatisiertes Backup­system existiert nicht. Drei zentrale Probleme ergeben sich daraus: das Risiko erheblichen Datenverlusts bei Hardware-Ausfall (P1), die fehlende räumliche Trennung der Sicherungen (P2) und der hohe manuelle Aufwand von ca. 1 Stunde pro Woche (P3). Hinzu kommt, dass das Restore-Verfahren bislang nie unter realen Bedingungen getestet wurde."

Was an diesem Beispiel gut funktioniert: konkrete Zahlen (8 Server, 25 Clients, 300 GB), klare Bezeichnung der Probleme mit Kürzeln (P1, P2, P3), sachlich-neutraler Ton ohne Übertreibung, klarer Übergang zum Soll-Konzept im Hintergrund („Hinzu kommt, dass…"). In 4 Sätzen ist eigentlich schon die halbe Ist-Analyse geliefert.

12) Übergang zum Soll-Konzept

Die Ist-Analyse endet nicht abrupt, sondern leitet ins Soll-Konzept über. Ein guter Schluss­satz formuliert die Zielrichtung, ohne schon Lösungen vorzugreifen. Beispiel: „Aus diesen Befunden ergibt sich die Anforderung eines automatisierten, zentral verwalteten Backup-Systems, das die genannten Probleme adressiert und die abgeleiteten funktionalen sowie nicht­funktionalen Anforderungen erfüllt. Die im folgenden Kapitel beschriebenen Lösungs­ansätze werden gegen diese Anforderungen abgewogen."

Zusammenfassung

Die Ist-Analyse ist ein 1–1,5-seitiges Kapitel und das Fundament der Doku. Inhalt: aktuelle Situation (mit konkreten Zahlen), Stakeholder, Probleme/Schwächen (priorisiert), Anforderungen (funktional und nichtfunktional getrennt) und Rahmen­bedingungen. Methoden: W-Fragen (Was, Wer, Wo, Wann, Warum, Wie), Stakeholder-Matrix (Interesse × Einfluss), SWOT bei strategischen Themen, Ist-Visualisierung als Skizze, priorisierte Problemliste. Erhebungs­methoden: Interviews, Beobachtung, Inventur, Doku-Analyse, Log-Auswertung. Häufige Fehler: zu wenig Zahlen, Lösungen schon hier nennen, vage Beschreibungen, keine Stakeholder, vermischte Anforderungen, kein Ist-Diagramm. Tipps: mit Zahlen beginnen, eine Skizze einbinden, Probleme mit Kürzeln versehen, Übergang zum Soll-Konzept andeuten. Sachlicher, analytischer Ton.