Inhaltsverzeichnis
Wenn ein IT-Projekt seinen terminlichen oder finanziellen Rahmen überschreitet, liegt das meistens an lückenhafter Vorbereitung. Das Unternehmen hat seine Prozesslandschaft nicht ausreichend analysiert und stellt erst im Projektverlauf fest, dass angrenzende Abläufe ebenfalls einbezogen werden müssen. Das erhöht den Scope, sodass die ursprünglichen Vorgaben nicht mehr einzuhalten sind. Das Projekt läuft aus dem Rahmen.
So etwas passiert häufig, wenn das Management beschließt, die Anforderungsanalyse Top-down durchzuführen. Um die operativen Mitarbeiter nicht aus dem Tagesgeschäft zu reißen, definieren Abteilungs- oder Geschäftsleitung (je nach Organisation) die Schwachstellen im Prozess-Framework selbst. Solch eine Analyse aus Helikoptersicht fördert allerdings nur abstrakte Probleme zu Tage – oft in Form schlechter Kennzahlen. Die eigentlichen Schwachstellen, die das Tagesgeschäft behindern, bleiben im Verborgenen.
Wendet sich das Unternehmen nun an einen IT-Dienstleister, kann dieser keine passende Lösung konzipieren, denn er kennt die wahren Anforderungen nicht. Deswegen kommt es im Projektverlauf immer wieder zu konzeptionellen Anpassungen und Erweiterungen des Scopes. Diesen Ärger vermeiden Sie, indem Sie vor Projektbeginn eine strukturierte Prozessanalyse durchführen.
Eine Prozessanalyse aus Helikoptersicht reicht nicht
Eine große Schwäche der High-Level-Anforderungsanalyse ist, dass sie die Betroffenen nicht zu Wort kommen lässt. Sie betrachtet lediglich die Kennzahlen der betroffenen Abteilung sowie grundlegende Prozessschwächen, die aus der Ferne erkennbar sind. Das hat zwei Konsequenzen:
- Die verantwortlichen Personen können den Prozess nicht präzise genug beschreiben, denn viele Details existieren nur in den Köpfen der operativen Mitarbeiter. Es handelt sich um Erfahrungswerte, die nie offiziell dokumentiert wurden, weil sie als banal gelten. Beispielsweise wird kaum ein Unternehmen schriftlich festhalten, welche Buttons ein Lagermitarbeiter genau drücken muss, um eine Materialieferung im Warenwirtschafts-System zu registrieren. Auf die Effizienz eines Prozesses können solche Details jedoch großen Einfluss haben.
- Der definierte Prozess entspricht nicht immer dem gelebten. Manchmal nehmen Mitarbeiter Änderungen an Abläufen vor, um ihren Arbeitsalltag effizienter zu gestalten oder Probleme abzufangen. Beispielsweise umgehen die Mitarbeiter einiger Unternehmen den Dienstweg, wenn sie neues Arbeitsmaterial benötigen. Bei den Kollegen im Lager nachzufragen geht viel schneller, als ein Formular einzureichen und die Antwort abzuwarten. Auf diese Weise entstehen Abläufe, die offiziell gar nicht existieren.
Beide Punkte stellen das Unternehmen und den beauftragten IT-Dienstleister vor Probleme, denn sie verfälschen den Input für potentielle Optimierungsmaßnahmen. Ein zu geringer Detailgrad führt dazu, dass wichtige Anforderungen übersehen und nicht umgesetzt werden. Undokumentierte Prozessänderungen haben den gleichen Effekt.
Eine reine Top-down-Analyse durch den Geschäfts- oder Abteilungsleiter birgt daher Risiken. Im schlimmsten Fall steht das Projekt von Anfang an auf wackeligen Füßen. Ein besserer Ansatz ist, die Prozesslandschaft vor Projektbeginn aus verschiedenen Blickwinkeln zu betrachten und ein Big Picture zu erstellen.
Gehen Sie ins Detail
Im ersten Schritt sollten Sie den betroffenen Prozess komplett durchgehen. Wichtig ist, dass Sie sich von der Helikoptersicht lösen und sich stattdessen auf die operative Sicht konzentrieren. Betrachten Sie den Prozess so, wie er tatsächlich in der Praxis abläuft. Überspringen Sie keinesfalls einzelne Schritte, egal wie banal diese auch sein mögen. Jeder Teil eines geschäftlichen Ablaufs kann Schwächen oder Optimierungspotential aufweisen.
Falls Sie Schwierigkeiten haben, den Prozess in Gänze zu erfassen, helfen strukturierte Analysemethoden. Zum Beispiel:
- Customer Journey Mapping
- Wardley Mapping
- Grafische Spezifikationssprachen wie BPMN 2.0
Alternativ können Sie die Perspektive wechseln und den Prozess aus der Sicht eines Objekts betrachten, das ihn durchläuft. Das kann ein physisches Objekt sein (z. B. eine Warenlieferung), ein virtuelles (z. B. ein Datenbankeintrag im CRM) oder eine Person (z. B. ein Kunde), je nach betrachtetem Ablauf. Wichtig ist auch hier, dass Sie keine Schritte überspringen.
Haben Sie das Grundverständnis für den Hauptprozess geschaffen, sollten Sie sich den Unterprozessen widmen, um eventuelle Redundanzen und Einsparpotenziale zu erkennen. In der Regel zeigen sich sehr schnell Abhängigkeiten zu anderen Systemen bzw. Daten und somit zu anderen Abläufen. Auch Vorgänger- und Folgeprozesse sollten Sie in die Analyse einbeziehen. Auf diese Weise identifizieren Sie Schnittstellen, die eventuell abgelöst oder neu geschaffen werden müssen. Das alles sind Faktoren, die großen Einfluss auf den Projektumfang haben.
Sprechen Sie mit den operativen Mitarbeitern
Mit drei oder vier Kollegen in einem Meetingraum zu sitzen und über Geschäftsabläufe zu sprechen ist zwar ressourcenschonend, aber ineffektiv. Um einen Prozess vollständig zu durchdringen, müssen Sie ihn in der Praxis erleben. Das geht nur, wenn Sie in die Abteilungen gehen und den Mitarbeitern über die Schulter schauen.
Nehmen Sie sich die Zeit und begleiten Sie den betroffenen Prozess von Anfang bis Ende. Es reicht nicht aus, nur darüber zu sprechen – nicht einmal im Tiefeninterview mit den operativen Mitarbeitern. Sie müssen den tatsächlichen Prozess beobachten, so wie er gelebt wird.
Ein großer Teil menschlicher Denkvorgänge läuft unbewusst ab. Wenn Sie beschreiben müssten, wie Sie Ihr Auto rückwärts ausparken, würden Sie vermutlich nicht erwähnen, dass Sie vor dem Einlegen des Rückwärtsgangs erst den Ganghebel drücken oder ziehen (je nach Fahrzeugmodell). Diesen Routinehandgriff nehmen Sie nicht mehr bewusst wahr.
Im Tagesgeschäft sind solche Automatismen hilfreich. Für die Prozessanalyse stellen sie jedoch ein Hindernis dar, denn die operativen Mitarbeiter betrachten sie als selbstverständlich. Selbst in einem Tiefeninterview kommen manche Prozessdetails nie zur Sprache. Der Befragte hält sie für trivial und der Moderator kann nichts abfragen, was er nicht kennt. Das Resultat sind Prozessschwachstellen, die nie dokumentiert und daher auch nie behoben werden.
Solche blinden Flecke können Sie nur beheben, indem Sie den Prozess live beobachten und bei Verständnisproblemen nachfragen. Wichtig ist, dass Sie dabei objektiv bleiben. Reagieren Sie auf Workarounds oder Abweichungen nicht mit Kritik. Betrachten Sie solche Dinge lieber als Hinweise auf Schwachstellen bzw. Ansatzpunkte für Prozessoptimierung.
Eine Prozessanalyse reduziert die Kosten des Projekts
Manche Unternehmen scheuen den Aufwand, den eine Prozessanalyse verursacht. Nur auf direkte Kosten zu achten, ist allerdings der falsche Ansatz. Denn auf lange Sicht reduziert eine Prozessanalyse den Gesamtaufwand sogar.
Zum einen ermöglicht sie, die Ziele des Optimierungsprojekts genauer zu bestimmen. Streuverluste werden minimiert und Sie können Ihre Ressourcen präzise auf das eigentliche Problem ausrichten. Zum anderen hilft gründliche Vorbereitung dabei, den IT-Dienstleister besser zu schulen. Dieser kann genauer bestimmen, welche Technologien und Fachexperten er in das Projekt einbringen muss und welche Kosten dadurch entstehen. Das verbessert den Forecast auf beiden Seiten.
Wichtig ist allerdings, dass Sie es nicht übertreiben. Das Ziel einer vorbereitenden Prozessanalyse ist, den Ablauf in seiner Gänze zu verstehen. Es geht nicht darum, jedes Detail ausführlich zu untersuchen und zu dokumentieren. Sie wollen ein Big Picture, das zwar alle Details umfasst, aber nicht zu sehr in die Tiefe geht.
Diesen Spagat hinzubekommen kann knifflig sein. Ein guter Ansatz ist, die passende Methodik zu wählen. Knappe Zeitlimits verhindern zum Beispiel, dass die Analyse ausufert. Hilfreich ist auch, auf Brainstormings statt auf mehrtägige Workshops zu setzen. Die Faustregel lautet: Sie wollen wissen, was in dem Prozess passiert, nicht wie. In diesem Schritt geht es darum, die Voraussetzungen für ein erfolgreiches Projekt zu schaffen. In die Tiefe können Sie später noch gehen, sobald Sie die Rahmenbedingungen festgelegt haben.