Heute schreibe ich über eine Methode, auf welche ich als ERP-Projektmanager in fast jedem Projekt zurückgreife: die Geschäftsprozessanalyse. Und diese Methode realisiere ich durch mehrere Workshops.
Die Workshops für die Prozessanalyse können durchgeführt werden, bevor das ERP-System ausgewählt wurde, was allerdings nicht zwingend erforderlich ist. Wichtig ist aber, dass die Workshops durchgeführt werden, bevor das Einführungsprojekt tatsächlich losgeht.
Was ist die Geschäftsprozessanalyse?
Die Geschäftsprozessanalyse ist eine Methode zur Ermittlung des prozessualen Umfangs des anstehenden ERP-Projekts. Damit stellt sie eine Ergänzung, in wenigen Situationen auch einen Ersatz, zum eher funktionalen Ansatz einer Anforderungsanalyse dar, deren Ergebnis in den meisten Fällen ein funktionsorientiertes Lastenheft ist.
Die Prozessanalyse von Geschäftsprozessen kann auch als Basis für eine Geschäftsprozessoptimierung genutzt werden.
Welches Ziel hat die Geschäftsprozessanalyse?
Das Hauptziel der Analyse ist Transparenz. Wir wollen wissen, welche Prozesse und welche Prozessschritte in einem neuen System abzubilden sind. Des Weiteren wollen wir aber auch, dass ggf. auftretende interne Unklarheiten geklärt sind, bevor der Anbieter mit seinem Team in die Workshops startet. Es ist mehr als ärgerlich, wenn die Konzeptworkshops dadurch geprägt sind, dass das Kundenteam intern diskutiert, wie Prozesse eigentlich intern funktionieren sollten. Die Berater sitzen dort, lauschen der Diskussion, kosten Geld und warten auf Antworten. Ein Großteil der zu diskutierenden Punkte fällt bereits auf, wenn man in der Geschäftsprozessanalyse die entsprechenden Prozessschritte diskutiert.
Welches Ziel hat die Geschäftsprozessanalyse nicht?
Die Analyse, so wie sie hier von mir dargestellt wird, hat nicht den Anspruch, interne Unternehmensprozesse zu optimieren. Sie ist mehr als Aufnahme der Anforderungen und Arbeitsabläufe gedacht und dient dazu, ein vollständiges Bild zu erhalten. Gleichwohl passiert es natürlich innerhalb der Workshops, dass sich Themengebiete zeigen, die noch einmal genauer beleuchtet werden sollten, bevor es dann tatsächlich an die Umsetzung geht.
Wichtig ist auch, dass es sich bei dieser Analyse nicht um eine Geschäftsprozessmodellierung unter der Verwendung von Unterprozessen handelt. Eine Modellierung der Geschäftsprozesse verfolgt meiner Erfahrung nach andere Ziele, ist wesentlich aufwendiger, und sollte auch einen anderen Detailgrad haben als das, was ich in der Folge vorstellen möchte. Die hier dargestellte Vorgehensweise ist darauf ausgelegt, das ERP-Projekt optimal zu unterstützen und dies auf eine möglichst simple, flexible und zugängliche Weise.
Vorgehensweise der Geschäftsprozessanalyse in der Praxis
Ein kleiner Einblick, wie ich die Geschäftsprozessanalyse bei meinen Kunden in der Praxis durchführe.
Workshop 1: Ermittlung der Kernprozesse / der End-to-End Prozesse
In diesem, normalerweise eintägigen, Workshop, erarbeiten wir zusammen eine Liste aller Geschäftsprozesse, deren Ablauf von Prozessschritten wir uns im weiteren Verlauf der Workshops erarbeiten werden. Es geht immer wieder um die Frage „Was muss am Echtstarttag alles definitiv funktionieren?“, oder aber auch „Mit welchen Prozessen wird das Geld verdient“.
Das Ergebnis ist eine Liste von üblicherweise 15–30 Prozessen. Anhand dieser Liste werden die weiteren Workshops geplant. Dabei werden jedem Workshoptag einige Prozesse zugeordnet und anhand der Tagesagenda die beteiligten Personen geplant.
Exemplarisch hier ein paar Beispiele für Prozesse, die dann auf der erarbeiteten Liste stehen.
Beispiele von Händlern:
- Verkauf von Lagerware (Vom Angebot bis zur Rechnung)
- Verkauf von kundenspezifischer Ware
- Disposition von Lagermaterial
Beispiele von Fertigungsunternehmen:
- Disposition der Lagerfertigung
- Service an verkaufter Maschine
- Fertigung von Serienteilen anhand eines Produktionsplans
Man sieht hier schon, dass dies an der Stelle noch sehr allgemein gehalten ist, aber den Rahmen für die weiteren Gespräche liefert. Ziel für die weiteren Gespräche ist es dann, die einzelnen Prozesse in Prozessschritte zu gliedern, um so für jeden Prozess klar herauszuarbeiten, welche Schritte, optimalerweise in welcher Reihenfolge, durchzuführen sind. Auf dieser Ebene (ich komme später zu ein paar Beispielen), ist dieser Prozess absolut systemunabhängig. Nur dadurch sind wir auch in der Lage, ihn so früh im Projekt durchzuführen.
Üblicherweise werden rein abteilungsinterne Prozesse, wie Prozesse innerhalb der Finanzbuchhaltung nicht in diesen Workshops beleuchtet. Diese können, falls für das Projekt notwendig und sinnvoll, zu einem späteren Zeitpunkt hinzugefügt werden.
Anhand der Prozessliste werden die weiteren Workshops geplant. In der Praxis werden also bestimmte Prozesse auf die Agenda eines Tages gesetzt und dann ermittelt, welche Personen entsprechend teilnehmen müssen / sollten. Somit hat man einen Fahrplan für die gesamte Workshopreihe.
Workshop 2 – X: Diskussion der einzelnen Prozesse und Strukturierung der Prozessschritte
Der 2. Workshop startet damit, dass man sich die Agenda der zu besprechenden Prozesse anschaut und sich für einen ersten Prozess entscheidet, der diskutiert wird. Dies ist üblicherweise ein Standardprozess, z. B.“ Verkauf Handelsware vom Lager“ oder etwas in der Art. Für den ersten Prozess legt man nun den Startpunkt fest und startet die Diskussion. Für den genannten Prozess könnte dies z. B. die Kontaktanlage sein. Dann wird Schritt für Schritt weiter diskutiert, idealerweise werden gleich die Verantwortlichkeiten (abteilungsbezogen) geklärt, damit auch dies im weiteren Projektverlauf bekannt ist und nicht an der Stelle noch weiteres Diskussionspotenzial lauert.
Wie immer ist es natürlich so, dass der erste Prozess, der diskutiert wird, noch etwas länger dauert. Zum einen muss man erst den richtigen Detailgrad findet, in dem man die Prozessschritte aufschreiben möchte, des Weiteren hat man noch keine Vorlage, von der man Schritte kopieren kann, denn dies wird üblicherweise in den weiteren Schritten getan. Wenn als zweiter Prozess z. B. „Verkauf von kundenbezogener Kommissionsware“ gewählt wird, kann man einen Teil des ersten Prozesses kopieren.
Prozessstörer
Ich füge gerne Prozessstörer in die Prozesse ein. Dies sind für mich Ereignisse, die in jedem Unternehmen passieren und den eigentlich so wunderschön geplanten Prozess stören. Aus meiner Erfahrung wird diesen Ereignissen in ERP-Projekten zu wenig Aufmerksamkeit geschenkt mit dem Effekt, dass nach dem Echtstart nicht klar ist, was eigentlich im Falle eine Prozessstörung zu tun ist, oder die Systemunterstützung an den Stellen nicht optimal sind.
Hier ein paar Beispiele für solche Störungen:
- Kunde verschiebt den gewünschten Liefertermin
- Kunde storniert Ware
- Komponenten stehen in der Fertigung nicht zur Verfügung, der Liefertermin ist nicht mehr zu halten
- Die Disposition kann die benötigten Termine nicht halten
- Etc.
Diese Prozessstörer sollten sehr früh im Projekt bekannt sein, denn je nach ERP-System kann die Unterstützung der benötigten Prozessschritte sehr unterschiedlich ausfallen.
Nachbereitung der Ergebnisse und Prozessketten
Nachdem alle Prozesse analysiert und die entsprechenden Prozessschritte aufgelistet wurden, ist man „eigentlich“ mit der Workshopreihe fertig. Es gibt aber einige Dinge, die ich grundsätzlich empfehle, um das Ergebnis der Workshop noch wertvoller für die weiteren Projektschritte zu machen:
- Abschlusstermin mit allen Keyuser zur Validierung der einzelnen Prozessschritte und Zuständigkeiten. Dies dient dazu, eine gemeinsame Akzeptanz des Endergebnisses sicherzustellen. In diesem Termin werden die Prozesse noch einmal durchgesprochen, um sicherzustellen, dass alles diskutiert und verabschiedet ist. Auch können die Zuständigkeiten in diesem Termin noch einmal finalisiert werden.
- Vergabe von eindeutigen IDs um gleiche Prozessschritte über unterschiedliche Prozesse hinweg zu identifizieren. Als ganz einfaches Beispiel seien hier die Prozesse „Verkauf Lagerware“ und „Verkauf Kundenkommissionsware“ genannt. Der Prozessschritt „Anlage Kontakt inkl. Ansprechpartner“ dürfte hier sicherlich der gleiche sein. Also bekommt dieser in beiden Listen eine eindeutige ID, sodass sich im Gesamtbild eine Liste aller unterschiedlichen Prozessschritte ergibt. Dies dient dazu, im späteren Projekt diese nur einmal zu besprechen und festzulegen.
- Es gibt auch immer wieder Schritte, die nicht im ERP-System durchgeführt werden sollen, aber zu einem kompletten Prozessablauf dazugehören. Diese werden markiert, damit man sie bei dem benötigten Umfang des ERP-Systems nicht fälschlicherweise berücksichtigt.
Wie sieht das Ergebnis einer Geschäftsprozessanalyse aus?
Letztlich handelt es sich bei dem Ergebnis um eine Exceldatei, die pro Geschäftsprozess ein Tabellenblatt beinhaltet. Diese können auch als Prozessketten bezeichnet werden. Hier einmal ein kurzer Ausschnitt, wie das Ergebnis für einen Prozess in Ihrem Unternehmen aussehen könnte:
Prozess: Verkauf Handelsware
ID | Schritt | Abteilung | Status | Bemerkung | ID |
1 | Anlage Kontakt inkl. Ansprechpartner | Außendienst | Offen | GP-01-0010 | |
2 | Klassifizierung Kontakt | Außendienst | Offen | GP-01-0020 | |
3 | Anlage Angebotskopf für Kontakt | Innendienst | Offen | GP-01-0030 | |
4 | Anlage Angebotspositionen | Innendienst | Offen | Bei der Erfassung prüfen, ob das System die hinterlegten Zusatzpositionen anzeigt Prüfung der ermittelten Preise | GP-01-0040 |
5 | Freigabe des Belegs und Versand des Angebots inkl. zusätzlicher Dokumente | Innendienst | Offen | GP-01-0050 | |
6 | Ablage Kundenauftrag (Mail) am Angebot | Innendienst | Offen | GP-01-0060 | |
7 | Erstellung Debitor aus Kontakt | Innendienst | GP-01-0070 | ||
8 | Umwandlung Angebot in Auftrag | Innendienst | Offen | GP-01-0080 |
Diese Liste wird weitergeführt, bis sie mit der Lieferung und Faktura der Ware endet. Als letzten Punkt führe ich IMMER den Prozessschritt „Prüfung der Ergebnisse durch die Finanzbuchhaltung“ ein. Dieser Prozessschritt soll später im Projekt, der Testphase, sicherstellen, dass die entsprechenden Prozesse auch von den Mitarbeitern der Finanzbuchhaltung abgenommen werden und sich nicht an dieser Schnittstelle Probleme aufbauen.
Was passiert mit den Ergebnissen der Geschäftsprozessanalyse?
Für mich persönlich ist die aus Prozessketten bestehende GP-Liste DAS Werkzeug, um die Einführung der neuen Software optimal zu steuern, und zwar mindestens in den ersten 4–5 Phasen. Aufgrund der Vollständigkeit, welche wir mit der Liste erreichen, ist es schon sehr früh in der ERP-Auswahl möglich, die Anbieterpräsentationen optimal vorzubereiten. Somit kann sichergestellt werden, dass das Unternehmen nicht nur eine bunte Vertriebspräsentation erhält, sondern das Gesamtkonzept auch relevant für das Unternehmen ist und zu deren Prozessketten passt.
Ich möchte hier nicht auf jeden einzelnen Punkt eingehen, für den ich die GP-Liste in einem Projekt verwende. Um Ihnen einen Eindruck zu vermitteln, wie wichtig sie in Projekten ist / sein kann, möchte ich je Phase einmal exemplarisch ein paar Beispiele nennen:
Phase 1 Orientierungsphase:
- In dieser Phase wird die Geschäftsprozessanalyse durchgeführt und dient somit als Grundlage für die Arbeit in den einzelnen Phasen. Die Keyuser lernen sehr viel über das anstehende Projekt und die Art und Weise, wie das ERP-Projekt durchgeführt wird. Das Ergebnis dient als Grundlage für Phase 2.
Phase 2 Anbieter- und Systemauswahl
- Vorbereitung einer Workshopagenda für die Anbieterworkshops
- Grundlage für die Auswahl von Demodaten und Beispielvorgänge
- Liste um Prozessschritte zu markieren, die noch offene Fragen bei den Workshopteilnehmern hinterlassen haben
Phase 3 Projektvorbereitung
- Überführung der GP-Liste in ein Projektbacklog
- Planung der ersten Grobkonzeptworkshops
Phase 4 Projektdurchführung
- Überprüfung der Prozessschritte hinsichtlich des Status im Projekt (Status z. B. Offen, Analysiert, Implementiert, im Test, Abgenommen)
- Grundlage für eine vollständige Übersicht über den Projektstatus (Auswertung des Projektschrittstatus nach Prozess, Abteilung etc.)
- Grundlage für die Integrationstestplanung
- Ermittlung von Flaschenhälsen (welche Abteilung hat aktuell die meisten Prozessschritte zu testen, sind zu viele Prozessschritte beim Anbieter in der Implementierung etc.)
Phase 5 Rollouts
- Diskussion der Prozessliste mit den einzelnen Niederlassungen / Standorte zur Klärung von Gemeinsamkeiten und Unterschieden
- Grundlage für praxisbezogene Schulungen für Mitarbeiter vor Roll-Out
Fazit
Die Geschäftsprozessanalyse, ein unerlässliches Instrument in der Welt des ERP-Projektmanagements, entfaltet ihr volles Potenzial, indem sie Transparenz und Struktur in die komplexen Abläufe eines Unternehmens bringt. Sie dient als Fundament, auf dem effiziente, fehlerresistente und optimierte Arbeitsabläufe aufgebaut werden können. Besonders hervorzuheben ist ihre Rolle bei der Optimierung betriebswirtschaftlicher Prozesse, wobei sie den Mitarbeitern und deren Arbeitsweisen besondere Aufmerksamkeit schenkt.
Die Vorgehensweise, die wir in den Workshops etablieren, ermöglicht eine detaillierte Aufschlüsselung und Analyse jedes einzelnen Prozessschrittes. Diese Detailgenauigkeit führt zu einer verbesserten Effizienz und einer Reduzierung von Fehlern im gesamten System. Die Anwendung dieser Methode zeigt, dass wir nicht nur einzelne Prozesse betrachten, sondern das gesamte betriebliche Ökosystem im Auge haben, um es kontinuierlich zu verbessern.
Schließlich ermöglicht die Geschäftsprozessanalyse eine tiefgreifende Einsicht in die Arbeitsweise der Organisation und fördert eine Kultur der kontinuierlichen Verbesserung. Sie ist ein unverzichtbares Werkzeug für jedes Unternehmen, das seine betriebswirtschaftlichen Prozesse optimieren, seine Mitarbeiter effizient einsetzen und gleichzeitig die alltäglichen Herausforderungen des Geschäftsbetriebs meistern möchte. Und wenn diese reibungslos und effizient funktionieren, kann das ERP-System auch passend aufgesetzt und eingesetzt werden.