Prozessanalysen helfen, nützen aber nichts

Ich paraphrasiere den Titel von Dan Ariely’s großartigem Buch „Denken hilft zwar, nützt aber nichts„. Was Denken anbelangt, verweise ich auf sein Buch; zum effektiven Nutzen von Geschäftsprozessanalysen will ich aber meine Erfahrungen und die daraus gezogenen Schlussfolgerungen in diesem Beitrag darstellen.

Wir haben ein Henne-Ei-Problem

„Wir müssen zuerst unsere Soll-Prozesse definieren, denn wir dürfen nicht suboptimale Geschäftsprozesse automatisieren!“, diesen Satz höre ich immer wieder. Völlig richtig ist, dass IT-Projekte Geschäftsprozesse ermöglichen sollen, die optimal auf die Unternehmensziele abgestimmt sind.

Ohne zu wissen, wofür man IT überhaupt einsetzen will, darf man kein IT-Projekt starten. Also startet man eine Geschäftsprozessanalyse ohne Beteiligung der IT, weil man sich ja nicht die Prozesse von der IT vorgeben lassen will. Ich habe schon oft erlebt, dass ein erheblicher Aufwand in solche Analysen investiert wurde, vor allem, wenn man zuerst die Ist-Prozesse im Detail dokumentiert und dann Soll-Prozesse möglichst im gleichen Detaillierungsgrad erarbeitet. Die Enttäuschung war allerdings regelmäßig groß, wenn sich bei der Konkretisierung der Anforderungen an die IT-Anwendungen herausstellt, dass ein Großteil der geforderten Inhalte nicht ohne neuerliche Recherchen und Analysen beantwortet werden kann.

Was sagen die Standards?

PMI definiert im „Business Analysis for Practitioners: A Practice Guide“ folgendes Phasenmodell:

1. Initiierung: In dieser Phase werden die Ziele und der Umfang der Prozessanalyse festgelegt. Es wird bestimmt, welche Prozesse analysiert werden sollen und welche Stakeholder beteiligt sind.
2. Anforderungsanalyse: Hier werden die Anforderungen der Stakeholder erfasst und dokumentiert. Techniken wie Interviews, Workshops und Umfragen werden verwendet, um die Bedürfnisse und Erwartungen der Stakeholder zu verstehen.
3. Prozessmodellierung: Die identifizierten Prozesse werden grafisch dargestellt, um ein besseres Verständnis der Abläufe und ihrer Interaktionen zu ermöglichen. Modellierungstechniken wie BPMN (Business Process Model and Notation) kommen zum Einsatz.
4. Prozessanalyse: Die Prozesse werden hinsichtlich ihrer Effizienz und Effektivität untersucht. Dies beinhaltet die Identifikation von Engpässen, Redundanzen und Verbesserungspotenzialen.
5. Prozessdesign: Basierend auf den Analyseergebnissen werden neue oder verbesserte Prozessdesigns entwickelt, die die identifizierten Schwachstellen adressieren.
6. Implementierung: Die neuen oder verbesserten Prozesse werden in die Organisation eingeführt. Dies kann Schulungen, Anpassungen von IT-Systemen und andere Maßnahmen umfassen.
7. Überwachung und Kontrolle: Die implementierten Prozesse werden kontinuierlich überwacht und bewertet, um sicherzustellen, dass sie die gewünschten Ergebnisse liefern und um weitere Verbesserungsmöglichkeiten zu identifizieren.

Der Business Process Management Common Body of Knowledge (BPM CBOK) beschreibt einen ähnlichen Lebenszyklus für Geschäftsprozessmanagement mit diesen Phasen:

1. Prozessplanung und Strategie
2. Prozessanalyse
3. Prozessdesign und -modellierung
4. Prozessimplementierung
5. Prozessüberwachung und -kontrolle
6. Prozessverfeinerung und -optimierung.

Der Unterschied besteht vor allem darin, dass PMI naturgemäß den Projektcharakter einer Prozessanalyse stärker akzentiert, während die Association of Business Process Management Professionals International (ABPMP) das Geschäftsprozessmanagement als permanente Aktivität adressiert.

Wann darf, soll oder muss die IT mitreden?

In den Anfängen meiner Projektpraxis dominierte die Aussage, dass man man die Prozesse nicht an die IT-Lösungen anpassen wolle, sondern es nur umgekehrt sein darf. Mittlerweile hat sich das Blatt gewendet. Das Angebot an Standardsoftware ist mittlerweile so groß, dass die Entwicklung von Individualsoftware nach Vorgaben des Business in den meisten Branchen nicht mehr argumentierbar ist. Sowohl die Kosten und die Durchlaufzeit ihrer Entwicklung als auch ihr Beitrag zur Erreichung der Geschäftsziele sind nicht mehr konkurrenzfähig. Zudem ist das Erfolgs- und Kostenrisiko deutlich höher als beim Einsatz von Standardsoftware.

Gerade lese ich in einer Ausschreibung den Satz: „Seitens des Auftraggebers besteht ausdrücklich die Bereitschaft, Prozesse anzupassen, wenn dadurch eine gleichwertige oder bessere Prozessqualität erreicht werden kann und der Anpassungsaufwand der Standardsoftware geringer wird. Diese beiden Aspekte sind im Verlauf der Projektarbeit im Sinne einer Kosten-Nutzen-Analyse abzuwägen.“

Man darf allerdings auch hier nicht von einem Extrem ins Andere verfallen. Es gibt auch unter dieser Prämisse genug zu tun, bevor man sich mit konkreten Softwarelösungen auseinandersetzt.

Vorarbeiten auf Seiten des Business

Das Sammeln von Informationen über den Ist-Zustand kann während der Projektrealisierung viel Zeit ersparen. Das sind die wichtigsten Inhalte, zu denen man am besten ohnehin laufend, spätestens aber beim Start eines IT-Vorhabens Informationen systematisch sammeln sollte:

• Märkte und Kundensegmente
• Produkte und Dienstleistungen
• Geschäftsprozesse (zumindest Prozesslandkarte)
• Daten
• Geschäftsregeln
• Beteiligte Organisationseinheiten und Stakeholder
• Standorte
• IT-Systeme (Ist-Situation aus Anwendersicht)
• Gesetzliche Vorgaben und Compliance-Regelwerke.

Zu jedem dieser Punkte ist eine SWOT-Analyse sinnvoll, um den Änderungsbedarf zu identifizieren und hinsichtlich der Wichtigkeit und Dringlichkeit zu bewerten.

Aber, das ist jetzt die große Einschränkung aus meiner Sicht: Umfang und Detaillierung der Erarbeitung von Soll-Prozessen (Punkt 5 des PMI-Modells bzw. Punkt 3 des BPM CBOK) sollten in dieser Phase nicht zu weit getrieben werden. Es ist durchaus sinnvoll, Soll-Prozesse zu entwerfen, die eine verbesserte Umsetzung der Geschäftsstrategie ermöglichen. Allerdings bringt es wenig, hier zu sehr ins Detail zu gehen, bevor man einen Blick auf die IT-Lösungsoptionen geworfen hat.

Der Blick über den Tellerrand auf vorbildliche Geschäftsprozesse anderer Organisationen und Unternehmen bringt mehr als ein hoher Aufwand für die Detaillierung von Soll-Prozessen auf Grundlage der aktuellen Ist-Situation und der Innen-Sicht.

Wenn man einzelne Geschäftsprozesse schon vorweg im Detail neu konzipiert, dann ist das jedenfalls ein sinnvolles Training für die Herausforderungen der Projektarbeit. Es muss nur allen bewusst sein, dass diese Ergebnisse als Hypothesen zu betrachten sind und im weiteren Verlauf eventuell völlig neu gestaltet werden müssen.

Selbst die unverdächtig erscheinende Empfehlung, sich im Vorfeld eines IT-Projektes über die Ziele und Rahmenbedingungen im Klaren zu sein, ist zu relativieren. Revolutionäre Änderungen des Geschäftsmodells sind in vielen Bereichen erst oder nur mit einer völlig neuartigen IT-Unterstützung machbar. Man bleibt hinter den Möglichkeiten zurück, wenn man ohne Betrachtung der IT-Potenziale Ziele festlegt und Rahmenbedingungen als gegeben nimmt, obwohl sich beides in einem neuen Kontext völlig anders darstellt. Disruptive Änderungen der Geschäftsprozesse ergeben sich fast immer aus neuen Optionen, die aufgrund technischer Innovationen zur Verfügung stehen. Das Internet und E-Commerce sind nicht aufgrund einer Geschäftsprozessanalyse entstanden, gleiches gilt derzeit für die Entwicklungen im Bereich der Künstlichen Intelligenz. KI ist derzeit ein Paradebeispiel für technologiegetriebene Prozessoptimierungen, wobei der Einfluss über die Prozessoptimierung ja weit hinausgeht und vielfach neue Geschäftsmodelle ermöglicht oder gar verlangt.

Vorarbeiten auf Seiten der IT

Die Darstellung aller Aufgaben, die eine kompetente IT-Abteilung (wie immer diese organisatorisch definiert und verankert ist) hier darzustellen, übersteigt den Scope dieses Beitrages. Es übersteigt auch meine inhaltliche Kompetenz. Ich stütze mich in diesem Bereich vorzugsweise auf meinen Freund und Kollegen Wolfgang Keller, der soeben die 4. Auflage seines Buches „IT-Unternehmensarchitektur – Von der Geschäftsstrategie zur optimalen IT-Unterstützung“ veröffentlicht hat.

In den Prozessen „Projektbegleitung“ sowie „Projektprozess“ ist das Zusammenwirken von Business und IT zu verorten. Dass diese Prozesse effektiv und effizient sind, hängt wesentlich davon ab, dass die anderen Prozesse von der IT permanent und professionell exekutiert werden.

Typische Fehlentwicklungen

Unter dem Leitbild der agilen Projektabwicklung wird oft mit IT-Umsetzungen begonnen, ohne dass die notwendigen Grundlagen geschaffen worden sind. Nun habe ich gerade dafür plädiert, gewisse Vorbereitungsaktivität zu reduzieren. Ja, es gibt Aktiväten im Bereich der Prozessanalyse und Prozessoptimierung, die ich aus den dargestellten Gründen zurückschrauben würde. Und es gibt eine ganze Reihe von Aktivitäten, die oft zu kurz kommen (siehe oben).

Dass auch agile Projekte Vorbereitung brauchen habe ich an anderer Stelleschon ausführlich argumentiert und muss es daher nicht weiter ausführen.

Ich beobachte allerdings auch unter agilen Prämissen den Versuch, die Anwender mit immer detaillierteren Anforderungsbeschreibungen quasi festzunageln. Ich hatte schon damit zu kämpfen, dass eine Controllerin die User-Stories „einfrieren“ wollte, weil sonst das Monitoring des Projektfortschrittes nicht möglich sei.

Ebenso habe ich erlebt, dass User-Stories priorisiert werden sollten, obwohl kein Lösungskonzept vorlag, anhand dessen man die Anforderungen hinsichtlich Wichtigkeit, Dringlichkeit, Machbarkeit und Aufwand hätte beurteilen können. Wie komplex das Thema Priorisierung ist, habe ich auch schon an anderer Stellebeschrieben.

Leitlinien für eine gute Praxis

Prozessoptimierung muss sich von Anfang an mit den Möglichkeiten der Informationstechnologie auseinandersetzen, um Leistungspotenziale zu erkennen, die bisher nicht gegeben waren. Es darf weder ein aufbau- noch ein ablauforganisatorisches Konzept finalisiert werden, ohne die technischen Möglichkeiten auf Potenziale für bessere organisatorische Lösungen abzuklopfen.

Aber wie kann das in der Praxis bewältigt werden? Man braucht eine Struktur, in der man diese Flexibilität abhandeln kann. Geeignet dafür ist ein Spiralmodell, das in seinen Grundzügen auf Barry W. Boehm zurückgeht. Dieses Spiralmodell ist ursprünglich im Kontext des Risikomanagements entstanden, mit diesem Vorgehen sollte das Risiko des Scheiterns eines IT-Projektes reduziert werden.

Grundidee des Spiralmodells ist, die unterschiedlichen Themenbereiche immer wieder mit jedes Mal steigendem Detaillierungsgrad zu durchlaufen. Was sind solche Themenbereiche? Es sind die Ziele und Rahmenbedingungen, die Geschäftsprozesse, die eingesetzte Software (Standardsoftware und/oder Individualentwicklung), die zugrunde liegende technische Infrastruktur und natürlich auch die Kosten und der Ressourceneinsatz, der für das Erreichen der gesetzten Ziele notwendig ist.

Nötig ist ein ständiger Dialog zwischen Anwendern und IT. Die Idee, dass Anwender eine Liste von Anforderungen erarbeiten und an die IT übergeben, wird zu keinen besseren Ergebnissen führen, nur weil jetzt Epics, Features und User Stories statt Funktionen in dieser Spezifikation enthalten sind. Man braucht eine Vision für das Geschäftsmodell und die Geschäftsprozesse, in der die Möglichkeiten der IT-Unterstützung bereits berücksichtigt werden. Sicherlich zu Beginn in abstrahierter, möglichst lösungsneutraler Form. Aber durchaus mit Beispielen für mögliche Lösungen aus der Erfahrung der Anwender, auch aufgrund von Erfahrungen in anderen Branchen und im privaten Umfeld. Das kann noch ohne IT-Beteiligung stattfinden, aber je kürzer diese Phase ist, umso besser.

Sobald wie möglich, wird gemeinsam von „Business“ und „IT“ an Lösungen gearbeitet, mit denen die gesetzten Ziele umgesetzt, am besten sogar übertroffen werden können. Aber schon in dieser Phase muss ein Entwurf der Architektur erarbeitet werden und dieser eröffnet eventuell neue Möglichkeiten. Es wird aber auch dazu führen, dass einige Ideen nicht mit vernünftigem Aufwand realisierbar sind und daher verworfen werden müssen. Dann muss der Dialog, die gemeinsame kreative Arbeit, auf dieser veränderten Basis fortgesetzt werden.

Diese Zusammenarbeit endet auch nicht mit dem Start des Projektes. Der/die Product Owner*in kann nicht die einzige Verbindung zwischen der IT und den Anwendern sein, bei jedem größeren Projekt wird dafür ein Team erforderlich sein. Er/sie ist dafür verantwortlich, dass der Dialog, die gemeinsame kreative Arbeit in jeder Phase stattfindet. Die IT ist berechtigt und gefordert, Geschäftsprozesse infrage zu stellen und Vorschläge zu deren Optimierung zu machen, Anwender sind berechtigt und gefordert, die Lösungsvorschläge der IT infrage zu stellen und Vorschläge zu deren Optimierung zu machen.

SAFe betont, dass User Stories keine Anforderungen sind, sondern zitiert Bill Wake, einen der Begründer von Extreme Programming (XP): „Stories act as a ‚pidgin language‘, where both sides (users and developers) can agree enough to work together effectivly“ (S. 209). Solche Mischsprachen sind uns aus vielen Lebensbereichen vertraut, „Denglisch“ ist auch in diesem Text oft vertreten. Von Ron Jeffries, einem anderen Begründer von XP, übernimmt SAFe auch die Charakterisierung von User Stories als „promise for a conversation“ (S. 213). Mit diesem Ansatz, User Stories als ein verbindliches Gesprächsangebot zu sehen, wird die optimale Herangehensweise sehr gut auf den Punkt gebracht.