Ist-Analyse
Wichtig
Die Ist-Analyse ist keine bloße Bestandsaufnahme, sondern eine kritische Untersuchung des aktuellen Zustands. Ihr Ziel ist es, nicht nur zu dokumentieren, "was ist", sondern zu verstehen, "warum es so ist" und "was besser sein könnte".
1. Ziele der Ist-Analyse
Die Ist-Analyse bildet den Ausgangspunkt jeder IT-Beratung. Ohne fundierte Kenntnis des aktuellen Zustands kann kein sinnvoller Change gestaltet werden.
1.1 Warum Ist-Analyse mehr als nur Inventur
| Traditioneller Ansatz (Fehlerhaft) | Professionelle Ist-Analyse |
|---|---|
| "Wie viele Server haben Sie?" | "Welche Applikationen laufen auf welchen Servern?" |
| "Welche Software nutzen Sie?" | "Welche Prozesse unterstützen die Software?" |
| "Wer arbeitet wo?" | "Welche Rollen und Verantwortlichkeiten bestehen?" |
| "Was machen Sie?" | "Warum machen Sie es so?" |
1.2 Drei Analyse-Dimensionen
Eine professionelle Ist-Analyse untersucht den As-Is-Zustand in drei Dimensionen:
graph TD
A[Ist-Analyse] --> B[Organisatorische Dimension]
A --> C[Technische Dimension]
A --> D[Prozessuale Dimension]
B --> B1[Rollen & Verantwortlichkeiten]
B --> B2[Organisationsstruktur]
B --> B3[Kommunikationswege]
C --> C1[Hard-/Software-Landschaft]
C --> C2[Datenströme]
C --> C3[IT-Architektur]
D --> D1[Geschäftsprozesse]
D --> D2[Arbeitsabläufe]
D --> D3[Schnittstellen]
style A fill:#f96,stroke:#333,stroke-width:3px2. Organisatorische Dimension: Menschen und Struktur
2.1 Rollen und Verantwortlichkeiten klären
Oft herrscht Unklarheit darüber, wer eigentlich für welche Tätigkeit zuständig ist. Dies führt zu Dopplungen, Lücken und Konflikten.
Analyse-Methoden: * Organigramm-Review: Ist das aktuelle Org-Chart noch aktuell? * Rollen-Workshop: Gemeinsame Klärung wer was tut * RACI-Matrix: Verantwortlichkeiten pro Prozessschritt dokumentieren * Interviews: Einzelgespräche mit Führungskräften und Mitarbeitern
Praxis-Tipp: RACI-Check
Wenn in einem Prozess niemand "A" (Accountable) hat → Verantwortungslücke. Wenn mehrere "A" haben → Konfliktpotenzial.
2.2 Kommunikationswege und Informationsschleifen
IT-Lösungen scheitern oft nicht am Code, sondern an der Kommunikation.
Fragen zur Analyse: * Wie fließt Information zwischen Abteilungen? * Wo entstehen Informationsverluste? * Welche Medien werden genutzt (E-Mail, Chat, Telefon, Papier)? * Gibt es "Informationsinseln" (Silos)?
Visualisierungsmethode: Kommunikationsmatrix
| Von | An | Häufigkeit | Medium | Problem |
|---|---|---|---|---|
| Vertrieb | Produktion | Täglich | E-Mail, Telefon | Unstrukturiert, keine Historie |
| Kunde | Support | Bedarfsweise | Telefon | Kein Tracking, Wartezeiten |
| Produktion | Einkauf | Wöchentlich | Meeting | Keine Echtzeit-Info |
3. Technische Dimension: IT-Landschaft und Daten
3.1 Hard-/Software-Landschaft erfassen
Die technische Ist-Analyse dokumentiert die existierende IT-Infrastruktur.
Inventarisierung: * Server: Standort, Leistung, Alter * Netzwerk: Topologie, Bandbreite, Sicherheit * Endgeräte: Laptops, Smartphones, IoT * Software: ERP, CRM, Office, Spezialsoftware * Datenbanken: Art, Größe, Zugriff
Tools zur Erhebung: * Automatisierte Scans: Netzwerk-Discovery (z.B. Nmap, Lansweeper) * IT-Asset-Management: Bestehende Systeme abfragen * Interviews: IT-Administrator befragen
3.2 Datenströme und Schnittstellen
Ein IT-Projekt steht oder fällt mit der Datenintegration.
Analyse-Fragen: * Wo entstehen Daten? * Wohin fließen Daten? * Welche Schnittstellen existieren (API, File-Exchange, manuell)? * Gibt es Datenredundanzen? * Wo finden Datenübergaben statt?
Visualisierung: Data-Flow-Diagramm (DFD)
graph LR
A[CRM-System] -->|API| B[Middlelayer]
C[ERP-System] -->|CSV| B
B -->|REST API| D[Webshop]
D -->|JSON| E[Kundenportal]
E -->|E-Mail| A
style A fill:#2196F3,stroke:#333,color:white
style C fill:#4CAF50,stroke:#333,color:white
style B fill:#FF9800,stroke:#333,color:whiteTypisches Problem: Daten-Silos
Wenn Daten nicht fließen, entstehen isolierte Systeme. Ein Kundenwechsel im CRM ist im ERP nicht sichtbar → Fehlinformationen, Double-Work.
3.3 Qualität der technischen Infrastruktur
Nicht nur die Existenz, sondern auch der Zustand der IT-Infrastruktur ist relevant.
Qualitätskriterien: | Kriterium | Analyse-Methode | |-----------|----------------| | Performance | Response-Time-Messung, Load-Tests | | Verfügbarkeit | Uptime-Statistiken, Downtime-Analyse | | Sicherheit | Security-Audit, Penetration-Test | | Wartbarkeit | Code-Quality-Review, Dokumentationsstatus | | Skalierbarkeit | Lasttests, Stress-Tests |
4. Prozessuale Dimension: Arbeitsabläufe und Workflows
4.1 Arbeitsabläufe detailliert dokumentieren
Während die Prozessanalyse den Fokus auf den Geschäftsprozess hat, analysiert die Ist-Analyse die konkrete Ausführung.
Unterschied: * Prozessanalyse: "Wie sollte der Prozess idealerweise laufen?" (Soll) * Ist-Analyse: "Wie läuft der Prozess tatsächlich?" (Ist)
Realitäts-Check
Prozess-Soll: "Kunde sendet Bestellung → System prüft Lagerbestand → System versendet Ware" Prozess-Ist: "Kunde sendet Bestellung → Mitarbeiter prüft manuell Excel → Mitarbeiter ruft Lager an → Mitarbeiter erstellt Lieferschein → ..."
4.2 Ist-Zustand visualisieren (Reality Mapping)
Nutzen Sie die gleichen Notationen wie in der Prozessanalyse (BPMN, EPK), aber dokumentieren Sie tatsächliche Abweichungen:
- Umwege und Workarounds (Papier-Zettel, E-Mail-Schleifen)
- Doppelarbeiten (Doppelte Eingaben)
- Fehlerquellen (Manuelle Übergaben)
- Wartezeiten (Genehmigungen, Abstimmungen)
Kennzeichnung in Modellen: * ⚠️ Kritischer Punkt: Fehleranfällig * ⏱️ Zeitfresser: Lange Wartezeiten * ♻️ Wiederholung: Dopplung oder Rücklauf * 🔀 Verzweigung: Komplexe Entscheidungspunkte
4.3 Arbeitsweisen und Tools erfassen
Wie arbeiten die Mitarbeiter tatsächlich mit den Tools?
Analyse-Methoden: * Go-and-See: Prozess live beobachten * Screen-Recording: Videoaufzeichnung der Arbeit am Computer * Think-Aloud: Mitarbeiter erklären während der Arbeit, was sie tun * User-Journey-Mapping: Kundensicht auf den Prozess
5. Kombinierte Analyse-Methoden
5.1 GAP-Analysis (Ist vs. Soll)
Die Gap-Analyse vergleicht den Ist-Zustand mit dem Soll-Zustand (Vision, Anforderungen, Benchmarks).
| Dimension | Ist-Zustand | Soll-Zustand | Gap |
|---|---|---|---|
| Prozess-Durchlaufzeit | 7 Tage | 2 Tage | -5 Tage |
| Automatisierungsgrad | 20% | 80% | -60% |
| Datenintegration | File-Exchange | Real-Time API | Manuell → Echtzeit |
| Kundenzufriedenheit | 3.5/5 | 4.5/5 | -1.0 |
5.2 SWOT-Analyse der IT-Landschaft
Nutzen Sie die SWOT-Methode für eine strukturierte Bewertung:
| Intern | Extern | |
|---|---|---|
| Positiv | Stärken | Chancen |
| - Stabiles ERP-System | - Cloud-Migration möglich | |
| - Engagiertes IT-Team | - KI-Integration verfügbar | |
| Negativ | Schwächen | Risiken |
| - Veraltete Server-Hardware | - Sicherheitsbedrohungen | |
| - Kein Dokumentenmanagement | - Compliance-Vorschriften |
5.3 Ishikawa-Diagramm (Ursachenanalyse)
Bei kritischen Problemen nutzen Sie das Ishikawa-Diagramm (Fischgräten-Diagramm), um Ursachen zu identifizieren.
- 4M-Analyse: Men, Machine, Material, Method
- Erweiterung 6M: + Measurement, Mother Nature (Umwelt)
- Erweiterung 8M: + Management, Money
(Detailliert in Kapitel 02-Schwachstellen-Gap)
6. Praxis-Beispiel: Ist-Analyse im Onboarding-Prozess
Szenario: GrowthCorp AG
Die GrowthCorp AG ist schnell gewachsen. Die IT-Support-Abteilung ist überlastet, weil neue Mitarbeiter langwierig eingerichtet werden.
6.1 Vorbereitung
Analyse-Schritte: 1. Scope definieren: Onboarding-Prozess neuer Mitarbeiter (Tag 1 bis Tag 30) 2. Stakeholder identifizieren: HR, IT-Support, Facility, Führungskräfte, neue Mitarbeiter 3. Interviews planen: Jeweils 2 Interviews pro Stakeholder-Gruppe
6.2 Erhebung
Interview-Fragen (Beispiele): * "Was passiert am ersten Tag eines neuen Mitarbeiters?" * "Welche Tools benötigen Sie für Ihre Arbeit?" * "Wo hakt es regelmäßig?" * "Welche Informationen erhalten Sie zu spät?"
Beobachtung (Go-and-See): * Einem neuen Mitarbeiter 2 Tage begleiten * Dokumentieren aller Tätigkeiten und Wartezeiten * Erfassen aller E-Mails, Formulare und Dokumente
6.3 Analyse
Ergebnisse der Ist-Analyse:
| Problem | Auswirkung | Ursache (Ishikawa) |
|---|---|---|
| Laptop-Einrichtung dauert 3 Tage | Neuer Mitarbeiter kann nicht arbeiten | IT-Team überlastet (Personal), manuelle Konfiguration (Method) |
| Kein E-Mail-Zugriff für 24h | Keine Kommunikation mit Kunden | IT-Team überlastet (Personal), manuelle Anlage (Method) |
| Büroausstattung unvollständig | Unzufriedenheit | Keine Checkliste (Method), Lagerbestände unklar (Material) |
| Zugriff auf Anwendungen fehlt | Verzögerung im Projekt | Kein Rollenkonzept (Method), keine Automatisierung (Machine) |
6.4 Handlungsempfehlungen
| Ist-Zustand | Anforderung an IT-Lösung |
|---|---|
| Manuelle Laptop-Einrichtung | Automatisiertes Provisioning (z.B. Microsoft Autopilot) |
| Manuelle E-Mail-Anlage | Self-Service-Portal für IT-Support-Tickets |
| Keine Übersicht | Dashboard für Onboarding-Status |
| Kein Rollenkonzept | Role-Based Access Control (RBAC) |
7. Checkliste für Ihre Ist-Analyse
7.1 Vorbereitung
- Ziel klar definiert: Warum analysieren wir?
- Scope abgesteckt: Was ist IN, was ist OUT?
- Stakeholder identifiziert: Wer muss befragt werden?
- Methoden gewählt: Interviews, Beobachtung, Datenanalyse?
7.2 Durchführung
- Interviews geführt: Mit allen relevanten Rollen
- Prozesse beobachtet: Go-and-See durchgeführt
- Daten erhoben: System-Logs, Reports, Statistiken
- Dokumentation erstellt: Aktuelle Prozesse dokumentiert
7.3 Analyse
- Stärken identifiziert: Was läuft gut?
- Schwächen benannt: Wo gibt es Probleme?
- Ursachen analysiert: Warum gibt es Probleme?
- Gap-Analyse durchgeführt: Ist vs. Soll
7.4 Ergebnisse
- Report erstellt: Ergebnisse dokumentiert
- Visualisierung: Diagramme, Dashboards, Prozessmodelle
- Priorisierung: Was zuerst angehen?
- Handlungsempfehlungen: Konkrete Next Steps definiert
8. Häufige Fehler bei der Ist-Analyse
| Fehler | Warum problematisch | Lösung |
|---|---|---|
| Nur Interviews, keine Daten | Subjektiv, verzerrt | Interviews mit Daten kombinieren |
| Fokus auf Technik, ignoriert Menschen | Lösung wird nicht akzeptiert | Change-Management einplanen |
| Kein Fokus, "alles analysieren" | Zeit- und Ressourcenverschwendung | Scope vorher definieren |
| Nur Probleme, keine Stärken | Demotiviert, ignoriert Good Practice | Balanced Analysis (SWOT) |
| Keine Validierung | Annahmen bleiben ungeprüft | Ergebnisse mit Stakeholdern validieren |
9. Zusammenfassung
Die Ist-Analyse ist das Fundament erfolgreicher IT-Beratung:
- Drei Dimensionen: Organisatorisch, technisch, prozessual
- Nicht nur dokumentieren: Kritisches Verstehen statt bloßer Inventur
- Methodenvielfalt: Interviews, Beobachtung, Datenanalyse, Visualisierung
- Validierung: Ergebnisse mit Stakeholdern abstimmen
- Resultat: Fundierte Handlungsempfehlungen und Anforderungskatalog
Nächster Schritt: Identifizieren Sie Schwachstellen systematisch (Kapitel 02-Schwachstellen-Gap).