Typische Fehler bei der Ist-Analyse – Die Ist-Analyse entscheidet oft darüber, ob ein Projekt klar, zielgerichtet und wirtschaftlich startet – oder ob es Monate später in Change Requests, Frust und Mehrkosten endet. Trotzdem wird die Analyse der aktuellen Situation in vielen Organisationen eher als Pflichtübung behandelt. Das Ergebnis: lückenhafte Prozessbilder, Schönfärberei, verpasste Risiken und am Ende Lösungen, die am Bedarf vorbeigehen.
Dieser Beitrag zeigt, welche typischen Fehler bei der Ist-Analyse immer wieder auftreten, warum sie so kritisch sind – und wie Sie Ihre eigene Analyse deutlich professioneller und belastbarer aufsetzen.

Was ist eine Ist-Analyse?
Eine Ist-Analyse ist die systematische Aufnahme und Bewertung des aktuellen Zustands von Prozessen, Strukturen, Systemen und Kennzahlen in einem Unternehmen.
Sie beantwortet Fragen wie:
- Wie werden Aufgaben heute tatsächlich erledigt?
- Wer ist beteiligt, mit welchen Rollen und Verantwortlichkeiten?
- Welche IT-Systeme, Tools und Schnittstellen sind im Einsatz?
- Wo entstehen Wartezeiten, Medienbrüche, Doppelarbeiten oder Fehler?
Typische Anwendungsfelder sind:
- Einführung oder Ablösung von IT-Systemen (ERP, CRM, DMS, Ticket-Systeme)
- Prozessoptimierung und Lean-/KVP-Initiativen
- Organisationsentwicklung und Reorganisation
- Compliance-, Audit- und Qualitätsmanagement-Projekte
Ziel der Ist-Analyse ist kein „Prozessgemälde für den Schrank“, sondern eine belastbare Grundlage für Entscheidungen, Anforderungen und konkrete Verbesserungen.
Warum typische Fehler bei der Ist-Analyse so teuer werden
Fehler in der Ist-Aufnahme wirken sich selten sofort aus – sie explodieren später im Projekt:
- Anforderungen basieren auf Annahmen statt auf Fakten
- Fachbereiche erkennen sich in Konzepten und Soll-Prozessen nicht wieder
- IT-Lösungen bilden wichtige Sonderfälle und Schnittstellen nicht ab
- Einspar- und Effizienzpotenziale werden überschätzt oder verfehlt
- Abhängigkeiten (z. B. zu anderen Systemen/Abteilungen) tauchen erst spät auf
Jeder nicht erkannte Sonderfall, jede vergessene Schnittstelle und jede geschönte Kennzahl führt zu Nacharbeit, Mehraufwand und oft zu Vertrauensverlust zwischen Business, IT und Management. Eine saubere Ist-Analyse ist deshalb Risikomanagement – nicht Bürokratie.
Typische Fehler bei der Ist-Analyse im Überblick
Die häufigsten Fehler bei der Ist-Analyse lassen sich grob so zusammenfassen:
- Unklare Ziele und kein gemeinsamer Rahmen
- Relevante Stakeholder werden nicht einbezogen
- Ist- und Soll-Zustand werden vermischt
- Es wird nur „auf Papier“, nicht in der Realität analysiert
- Schnittstellen, Abhängigkeiten und Kontext bleiben außen vor
- Es fehlt eine klare Methode und Struktur
- Datenbasis ist unvollständig oder verzerrt
- Ergebnisse werden nicht bewertet und priorisiert
- Dokumentation ist unübersichtlich oder lückenhaft
- Die Ist-Analyse wird als einmalige Aktion verstanden
Im Folgenden gehen wir diese Fehler im Detail durch – mit Praxisbezug und konkreten Gegenmaßnahmen.
Fehler 1: Unklare Ziele und falscher Rahmen
Eine Ist-Analyse ohne klares Ziel liefert meist viele Informationen, aber wenig Nutzen.
Typische Ausprägungen:
- Jede Abteilung versteht etwas anderes unter „Ist-Analyse“
- Der Bearbeitungsrahmen ist zu breit („Wir schauen uns mal alles an“) oder zu eng („Nur diesen einen Prozessschritt“)
- Entscheidende Fragen wie „Worauf wollen wir am Ende entscheiden?“ sind nicht beantwortet
Folgen:
- Endlose Workshops mit vielen Details, aber ohne roten Faden
- Überfrachtete Prozesslandkarten, die niemand mehr liest
- Analyse-Ergebnisse, die für das eigentliche Projektziel kaum Relevanz haben
Was hilft:
- Klare Zielaussage zu Beginn, z. B.:
„Wir wollen verstehen, wie die Lead-to-Order-Prozesse heute ablaufen, um Anforderungen für ein neues CRM-System abzuleiten und Effizienzpotenziale zu identifizieren.“ - Saubere Abgrenzung:
- Welche Prozesse/Organisationseinheiten sind im Scope?
- Welche sind bewusst nicht im Scope – und warum?
- Gemeinsame Leitfragen definieren, z. B.:
- Wo entstehen heute Verzögerungen?
- Wo sind Medienbrüche und manuelle Arbeitsschritte?
- Welche Risiken/Geschäftsrelevanzen hängen daran?
Fehler 2: Stakeholder werden nicht (oder zu spät) eingebunden
Viele Ist-Analysen finden vor allem mit Führungskräften oder Projektkernteams statt. Diejenigen, die die Arbeit täglich machen, kommen oft zu spät oder gar nicht zu Wort.
Typische Symptome:
- Workshops nur mit Management und Projektleitung
- Fachanwender werden als „Störer“ empfunden und nicht aktiv eingebunden
- Externe Partner (z. B. Dienstleister, Outsourcing-Partner) werden vergessen
Folgen:
- Beschönigte Darstellungen („So sollte es laufen“ statt „So läuft es wirklich“)
- Kritische Ausnahmen und Workarounds bleiben unsichtbar
- Akzeptanzprobleme später im Projekt („So arbeiten wir aber nicht“)
Bessere Vorgehensweise:
- Stakeholder-Analyse vor Start:
- Wer arbeitet täglich in den Prozessen?
- Wer liefert zu? Wer empfängt Ergebnisse?
- Wer hat informelle Schlüsselrollen (z. B. „Kümmerer“, inoffizielle Experten)?
- Formate mischen:
- Interviews mit Schlüsselpersonen
- Gruppen-Workshops mit Vertreter:innen unterschiedlicher Rollen
- Ggf. kurze Umfragen für breite Einschätzungen (z. B. Zufriedenheit, Pain Points)
- Früh und offen kommunizieren:
- Warum wird analysiert?
- Was passiert mit den Ergebnissen?
- Welche Mitwirkungsmöglichkeiten gibt es?
Fehler 3: Verwechslung von Ist- und Soll-Zustand
Einer der häufigsten und gefährlichsten Fehler: Schon in der Ist-Analyse wird über Lösungen und Zielbilder diskutiert – der aktuelle Zustand gerät in den Hintergrund.
Typische Muster:
- In Interviews wird schnell über „Wunschprozesse“ gesprochen
- Probleme werden übersprungen („Das lösen wir dann im neuen System“)
- Prozessmodelle enthalten bereits Soll-Ideen („Da bauen wir einen Workflow ein“)
Risiken:
- Der reale Ausgangspunkt bleibt unscharf
- Wichtige Ursachen von Problemen werden nicht verstanden
- Anforderungen beruhen auf Meinungen statt auf faktenbasierten Erkenntnissen
Konsequente Trennung hilft:
- Klare Regel in Workshops/Interviews: „Wir sprechen jetzt ausschließlich darüber, wie es heute abläuft. Ideen und Soll-Vorschläge parken wir auf einem separaten Board.“
- Visuelle Trennung:
- Ist: z. B. blaue Post-its
- Soll-Ideen: z. B. gelbe Post-its
- Späterer Soll-Workshop:
- Erst wenn der Ist-Zustand verstanden und dokumentiert ist, werden Soll-Prozesse entwickelt
Fehler 4: Nur Dokumente – keine Beobachtung in der Realität
Viele Ist-Analysen stützen sich fast ausschließlich auf Dokumente und Beschreibungen:
- Prozesshandbücher, Verfahrensanweisungen, Arbeitsanweisungen
- Organigramme, Stellenbeschreibungen
- Tool- und Systemdokumentation
Die Praxis sieht oft anders aus als die Dokumentation.
Typische Folgen:
- Blindes Vertrauen in veraltete oder idealisierte Prozesse
- Wichtige informelle Abläufe („Das machen wir immer so nebenbei…“) bleiben unsichtbar
- Medienbrüche und Workarounds tauchen in keinem offiziellen Dokument auf
Bessere Datenerhebung:
- Gemba Walk / Arbeitsplatzbeobachtung:
- Ein bis zwei Stunden „zuschauen“, wie Arbeit tatsächlich erledigt wird
- Fragen stellen: „Was machen Sie, wenn…?“ – „Wie gehen Sie mit Sonderfällen um?“
- Begleitete Fallbearbeitung:
- Konkrete Vorgänge von Anfang bis Ende nachverfolgen (z. B. Kundenauftrag, Störungsticket, Reklamation)
- Stichproben im System:
- Zufällig ausgewählte Vorgänge analysieren: Bearbeitungszeiten, Schleifen, Statuswechsel
Die Kombination aus Dokumenten, Interviews und Beobachtung liefert ein wesentlich vollständigeres Bild als eine reine „Schreibtisch-Analyse“.
Fehler 5: Nur auf einzelne Prozesse schauen, nicht auf Zusammenhänge
Ist-Analysen bleiben häufig auf der Ebene einzelner Prozesse stehen. Kritische Abhängigkeiten und Schnittstellen werden kaum betrachtet.
Typische Lücken:
- Übergaben zwischen Abteilungen (z. B. Vertrieb → Auftragsabwicklung → Produktion)
- Systembrüche (z. B. Excel-Listen als Zwischenlösung zwischen zwei Systemen)
- Abhängigkeiten zu externen Dienstleistern oder Lieferanten
- Rückkopplungen, z. B. Reklamationen, die auf fehlerhafte Stammdaten zurückgehen
Das führt zu:
- Optimierung einzelner Prozessschritte, ohne den Gesamtfluss zu verbessern
- Verlagerung von Problemen („Problem gelöst“ in Team A, aber verschärft in Team B)
- Unterschätzten Risiken, wenn an Schnittstellen Änderungen vorgenommen werden
Sinnvolle Erweiterung der Ist-Analyse:
- End-to-End-Betrachtung („von Anfrage bis Zahlungseingang“, „von Ticket bis Lösung“)
- Schnittstellen explizit erfassen:
- Welche Informationen werden übergeben?
- In welchem Format? Über welche Kanäle?
- Wie robust ist die Übergabe-Qualität?
- Systemlandkarte erstellen:
- Welche Systeme sind betroffen?
- Wo werden Daten doppelt gepflegt?
- Wo gibt es Medienbrüche?
Fehler 6: Keine Methode, kein roter Faden
„Wir reden mal über den Prozess“ ist keine Methode. Ohne klare Vorgehensweise hängt Qualität von Laune, Lautstärke und Zeitdruck in den Terminen ab.
Typische Probleme:
- Unterschiedliche Detailtiefe je nach Moderator oder Bereich
- Wichtige Aspekte (z. B. Risiken, Kennzahlen, Ausnahmen) werden vergessen
- Ergebnisse sind schwer vergleichbar und kaum auswertbar
Was eine gute methodische Basis ausmacht:
- Einheitliche Struktur für alle Prozesse, z. B.:
- Trigger/Eingang
- Aktivitäten/Schritte
- Rollen und Verantwortlichkeiten
- Systeme/Tools
- Input/Output-Dokumente
- Ausnahmen/Sonderfälle
- Kennzahlen (Dauer, Volumen, Fehlerquote)
- Risiken/Schwachstellen
- Geeignete Notationen und Darstellungsformen:
- BPMN, EPK oder einfache Swimlane-Diagramme – je nach Reifegrad der Organisation
- Ergänzende Steckbriefe pro Prozess
- Klare Moderation:
- Zeitrahmen pro Prozess
- Vorgehen im Workshop (z. B. erst grob, dann Details, dann Schwachstellen)
Fehler 7: Schlechte oder verzerrte Datenbasis
Subjektive Wahrnehmungen („Das dauert immer ewig“) sind wichtig, aber keine belastbare Grundlage für Entscheidungen.
Typische Schwächen:
- Keine oder veraltete Kennzahlen zu Durchlaufzeiten, Volumen, Fehlerquoten
- Nur Durchschnittswerte, keine Betrachtung von Ausreißern und Bandbreiten
- Daten aus Systemen, die nicht plausibilisiert oder bereinigt werden
- „Gefühlte“ Prioritäten, die von Lautstärke und Hierarchie abhängen
Risiken:
- Falsche Schwerpunkte bei Verbesserungsmaßnahmen
- Unterschätzung kritischer Engpässe oder Risiken
- Überschätzung von Effizienzgewinnen im Business Case
Verbesserungsansätze:
- Früh im Projekt klären:
- Welche relevanten Kennzahlen existieren bereits?
- In welcher Qualität liegen sie vor?
- Wo nötig, temporäre Messungen aufsetzen:
- Stichproben über mehrere Wochen
- Simple Erfassungslisten oder automatisierte Auswertungen in bestehenden Systemen
- Interview-Aussagen mit Daten spiegeln:
- „Sie empfinden den Schritt als Engpass – die Daten zeigen X. Wie erklären Sie die Differenz?“
Fehler 8: Keine Bewertung und Priorisierung der Erkenntnisse
Viele Ist-Analysen enden mit dicken Dokumenten und Prozesslandkarten – aber ohne klare Aussage, was nun wirklich wichtig ist.
Typische Situation:
- Lange Listen mit Problemen und „Pain Points“
- Kein gemeinsames Verständnis, welche Schwachstellen kritisch sind
- Management erhält eine „Bestandsaufnahme“, aber keine Entscheidungsgrundlage
Notwendig ist eine strukturierte Bewertung, z. B. entlang von:
- Geschäftlicher Relevanz:
- Umsatz-/Kostenwirkung
- Einfluss auf Kunden- und Mitarbeiterzufriedenheit
- Compliance- und Revisionsrelevanz
- Eintrittswahrscheinlichkeit / Häufigkeit
- Umsetzbarkeit von Verbesserungen (Komplexität, Abhängigkeiten)
Praktischer Ansatz:
- Bewertung der identifizierten Probleme in einer einfachen Matrix (z. B. Wirkung vs. Umsetzbarkeit)
- Top-10-Liste der wichtigsten Handlungsfelder ableiten
- Für jedes Top-Thema:
- Kurzbeschreibung des Problems
- Grobe Ursachenhypothese
- Erste Ideenrichtungen (ohne schon im Detail Soll-Prozesse zu entwerfen)
Fehler 9: Unstrukturierte oder lückenhafte Dokumentation
Selbst gute Workshops und Interviews bringen wenig, wenn die Ergebnisse später nicht nachvollziehbar sind.
Häufige Mängel:
- Prozessbilder liegen als unversionierte PowerPoint- oder Visio-Dateien in privaten Ordnern
- Interviewnotizen sind verteilt über verschiedene Dateien und Personen
- Es ist nicht erkennbar, wer welche Aussagen getroffen hat
- Änderungen an Prozessmodellen sind nicht dokumentiert
Folgen:
- Nach ein paar Monaten weiß niemand mehr, wie bestimmte Darstellungen zustande kamen
- Nacharbeit bei Audits, Zertifizierungen oder Folgeprojekten
- Misstrauen: „Das steht zwar in der Doku, aber ich weiß nicht, ob das noch stimmt“
Besser:
- Einheitliches Ablagekonzept:
- Zentraler Projektordner oder Kollaborationsplattform
- Klarer Aufbau (z. B. 01_Interviews, 02_Prozessmodelle, 03_Kennzahlen, 04_Ergebnisberichte)
- Versionierung:
- Klare Versionsstände für Prozessmodelle und Steckbriefe
- Änderungsprotokoll („Change Log“) bei wesentlichen Anpassungen
- Transparenz:
- Wer wurde wann interviewt, zu welchen Themen?
- Welche Annahmen wurden getroffen, wo besteht Unsicherheit?
Fehler 10: Die Ist-Analyse als einmalige Momentaufnahme verstehen
Organisationen und Prozesse verändern sich – oft schneller, als Dokumente gepflegt werden.
Typische Falle:
- Aufwendige Ist-Analyse wird erstellt
- Ergebnisse werden für ein Projekt genutzt
- Danach „versanden“ die Unterlagen, niemand fühlt sich für Aktualität verantwortlich
Probleme:
- Folgeprojekte starten wieder bei null
- Learnings gehen verloren
- Prozess- und Systemlandschaft wird nicht ganzheitlich weiterentwickelt
Reifer Umgang:
- Ist-Analyse als Baustein eines kontinuierlichen Verbesserungsprozesses verstehen
- Verantwortlichkeiten für Prozessdokumentation definieren (Prozess-Owner)
- Regelmäßige Reviews (z. B. jährlich oder anlassbezogen bei größeren Änderungen)
- Verknüpfung mit anderen Managementsystemen (Qualität, Information Security, Compliance)
Wie Sie eine saubere Ist-Analyse aufsetzen: pragmatischer Fahrplan
Ein praxistauglicher Ablauf für eine professionelle Ist-Analyse könnte so aussehen:
- Ziele und Scope klären
- Projektziel und Entscheidungsbedarf definieren
- Prozesse, Organisationseinheiten und Systeme im Fokus festlegen
- Stakeholder identifizieren
- Fachbereiche, Rollen, externe Partner
- Sponsoren und Entscheider benennen
- Vorgehensmodell festlegen
- Methoden (Interviews, Workshops, Beobachtungen, Datenanalysen)
- Notation und Dokumentationsform (z. B. BPMN, Swimlanes, Steckbriefe)
- Daten- und Informationsquellen sichten
- Bestehende Prozessdokumentationen, Kennzahlen, Reports
- Systemauswertungen (z. B. Ticket-Daten, Durchlaufzeiten)
- Interviews und Workshops durchführen
- Strukturierter Leitfaden mit Fokus auf: Ablauf, Ausnahmen, Schnittstellen, Probleme
- Konsequente Trennung von Ist und Soll
- Beobachtungen und Stichproben ergänzen
- Arbeitsplatzbegehungen
- Nachvollzug realer Fälle (End-to-End)
- Ergebnisse strukturieren und visualisieren
- Prozessmodelle und Steckbriefe
- Überblicksgrafiken zu Systemen und Schnittstellen
- Zusammenführung qualitativer und quantitativer Erkenntnisse
- Bewertung und Priorisierung
- Schwachstellen systematisch bewerten
- Handlungsfelder und erste Empfehlungen ableiten
- Validierung mit Stakeholdern
- Ergebnisse in Fachbereichen spiegeln („Erkennen Sie sich darin wieder?“)
- Korrekturen und Ergänzungen einarbeiten
- Abschlussdokumentation und Übergabe
- Kompakter Management-Report mit Kernaussagen
- Detailanhang mit Prozess- und Datenbasis
- Klare Anschlussfragen für Soll-Konzeption und Umsetzung
Praxisbeispiele: Wie typische Fehler konkret aussehen
Beispiel 1: CRM-Einführung ohne echte Ist-Analyse
Ein Vertriebsteam klagt über „unübersichtliche Kundeninformationen“ und „zu viel Excel“. Das Management beschließt die Einführung eines neuen CRM-Systems. Die Ist-Analyse beschränkt sich auf zwei Workshops mit der Vertriebsleitung.
Was übersehen wird:
- Service und Innendienst pflegen eigene Kundenlisten
- Die Buchhaltung führt kritische Bonitätsinformationen separat
- Partner- und Reseller-Informationen liegen in einer anderen Datenbank
Folgen:
- Das neue CRM bildet zunächst nur den Sichtbereich des Vertriebs ab
- Dateninkonsistenzen und Doppelpflege bleiben bestehen
- Nachträgliche Integrationsprojekte werden teuer und zäh
Mit einer breiteren, strukturierten Ist-Analyse wären Schnittstellen und Abhängigkeiten früher sichtbar geworden – und in die Systemauswahl und -konzeption eingeflossen.
Beispiel 2: Prozessoptimierung „am Schreibtisch“
Ein Unternehmen möchte die Durchlaufzeiten in der Auftragsabwicklung reduzieren. Die Ist-Analyse basiert fast ausschließlich auf Prozessbeschreibungen aus dem Qualitätsmanagement.
Was fehlt:
- Beobachtung der tatsächlichen Arbeitsschritte
- Erfassung von Ausnahmen (z. B. Sonderkunden, projektbasierte Aufträge)
- Analyse der Medienbrüche zwischen ERP, E-Mail, Excel und Drittsystemen
Folge:
- Optimiert wird ein Soll-Prozess aus dem Handbuch, nicht der gelebte Alltag
- Die später umgesetzten Maßnahmen verpuffen, weil zentrale Pain Points nicht adressiert werden
Erst eine ergänzende Feldbeobachtung zeigt, dass Mitarbeiter täglich mehrere Stunden mit dem Nachfassen unvollständiger Kundeninformationen verbringen – ein Thema, das in den Dokumenten nie auftauchte.
Checkliste: Fragen für eine bessere Ist-Analyse
Zur eigenen Qualitätskontrolle können Sie sich u. a. folgende Fragen stellen:
- Ziele & Scope
- Ist klar definiert, welche Entscheidungen auf Basis der Ist-Analyse getroffen werden sollen?
- Ist der Betrachtungsrahmen sinnvoll abgegrenzt – weder „alles“ noch „fast nichts“?
- Stakeholder
- Sind alle relevanten Rollen und Bereiche eingebunden – inklusive der „leisen“ Experten?
- Haben wir externe Partner und Schnittstellen berücksichtigt?
- Vorgehen & Methode
- Nutzen wir einen einheitlichen Fragenkatalog oder Leitfaden?
- Kombinieren wir verschiedene Erhebungsmethoden (Interview, Workshop, Beobachtung, Daten)?
- Inhalte & Tiefe
- Sind Ausnahmen, Sonderfälle und Workarounds explizit dokumentiert?
- Haben wir Schnittstellen, Medienbrüche und Systemabhängigkeiten erfasst?
- Datenbasis
- Liegen uns relevante Kennzahlen vor (Volumen, Durchlaufzeiten, Fehlerquoten)?
- Wurden Daten auf Plausibilität geprüft und mit Wahrnehmungen abgeglichen?
- Dokumentation & Nachvollziehbarkeit
- Sind Prozessdarstellungen und Erkenntnisse einheitlich strukturiert und versioniert?
- Ist erkennbar, wer welche Aussagen getroffen hat und wo Annahmen bestehen?
- Bewertung & Priorisierung
- Gibt es eine priorisierte Liste von Schwachstellen und Handlungsfeldern?
- Sind die wichtigsten Risiken und Engpässe klar benannt und begründet?
Fazit Typische Fehler bei der Ist-Analyse: Eine gute Ist-Analyse ist Versicherung für Ihr Projekt
Eine fundierte Ist-Analyse kostet Zeit und Ressourcen – aber sie spart ein Vielfaches davon in späteren Projektphasen. Wer den aktuellen Zustand nur grob oder geschönt kennt, plant auf Sand: Anforderungen passen nicht, Lösungen greifen zu kurz, Widerstände wachsen.
Entscheider, Projektleiter und Fachverantwortliche sollten die Ist-Analyse deshalb als strategische Investition verstehen:
- Sie reduziert Projektrisiken und Nacharbeiten
- Sie schafft ein gemeinsames Verständnis über Bereiche und Ebenen hinweg
- Sie macht Potenziale, Engpässe und Risiken transparent und priorisierbar
Wenn Sie Ihre nächste Ist-Analyse professionell aufsetzen oder kritisch überprüfen möchten, kann ein externer Blick helfen – etwa durch erfahrene Berater wie PURE Consultant, die Struktur, Moderation und methodische Tiefe einbringen und gleichzeitig die Realität in Ihrem Unternehmen im Blick behalten.