Business Technology 02/10

Nutzen und Grenzen von Geschäftsprozessmanagement

Autor:

Geschäftsprozesse sind wichtig, keine Frage. Wenn es um Businessthemen geht, stehen Geschäftsprozesse und deren Management oft im Zentrum des Interesses. Unterstützt wird dies durch verschiedenste Unternehmensarchitektur- und Geschäftsprozessmanagementwerkzeuge, die die Erfassung und Automatisierung dieser Prozesse auf vielfältige Weise unterstützen. Doch wie wichtig sind Geschäftsprozesse wirklich? Wie genau muss man diese Prozesse kennen? Wo hört der Sinn auf, wo beginnt der Unsinn? Und ist es möglich, dass Geschäftsprozesse und deren Automatisierung nicht immer das probate Mittel sind, um das Business optimal zu unterstützen?

Geschäftsprozesse sind allgegenwärtig, wenn über Businessthemen gesprochen wird. Ihre Historie lässt sich bis weit in das letzte Jahrhundert zurückverfolgen [1]. Eine erste Blütezeit erreichten sie in den frühen 90er Jahren des letzten Jahrhunderts im Kontext des Business Process Reengineerings (BPR [2]). Das war die Zeit, in der sich jedes Unternehmen, das etwas auf sich hielt, eine Abteilung „Methoden und Verfahren“ (oder mit einem ähnlich klingenden Namen) leistete, die neben dem damals ebenfalls unvermeidlichen Unternehmensdatenmodell die Geschäftsprozesse mit akribischem Fleiß erfasste und dokumentierte. Mit dem Abklingen des BPR-Hypes wurde es dann eine zeitlang wieder etwas ruhiger um die Geschäftsprozesse, bis das Thema des Geschäftsprozessmanagements (GPM oderauch BPM nach der englischen Bezeichnung Business Process Management) in den letzten Jahren eine immer größere Bedeutung erlangte.

Dokumentation von Geschäftsprozessen

Mittlerweile ist GPM omnipräsent und nicht mehr aus moderner Unternehmenssteuerung und -optimierung wegzudenken. Literatur dazu findet man in Hülle und Fülle (als stellvertretende Beispiele seien hier nur [3] und [4] genannt), und auch der IT ist das Thema allseits präsent, sei es als „Überbau“ zu SOA Initiativen, sei es in Form von Werkzeugen zur Geschäftsprozessmodellierung und -optimierung oder einfach nur in Anforderungen, Geschäftsprozesse möglichst gut IT-technisch zu unterstützen bzw. zu automatisieren. Es scheint naheliegend, das Management und die Optimierung von Geschäftsprozessen in den Fokus der geschäftlichen und der IT-Aktivitäten zu stellen. Haben wir erst einmal die Geschäftsprozesse genau genug verstanden und IT-technisch im Griff, dann sollte das vielbeschworene Business/IT-Alignment doch endlich Realität sein, oder?

Ist die Marschrichtung wirklich so klar oder haben wir da etwas übersehen? Sind Geschäftsprozesse, deren Management und Optimierung wirklich alles, oder gibt es da noch mehr? Und überhaupt, wie genau müssen wir die Geschäftsprozesse denn verstehen, um vernünftig handlungsfähig zu sein und zu bleiben? Diesen Fragen möchte ich mich im weiteren Verlauf dieses Artikels aus drei unterschiedlichen Perspektiven nähern:

  • In der ersten Perspektive geht es um die Frage des Detaillierungsgrads, wie viel Geschäftsprozess man braucht, um handlungsfähig zu sein.
  • Die zweite Perspektive beleuchtet die Frage, ob Geschäftsprozesse überhaupt ausreichend sind, ein Unternehmen fachlich zu beschreiben.
  • Die dritte Perspektive geht noch einen Schritt weiter und betrachtet die Einbettung des GPM in die Unternehmensziele und ob es andere wichtige Instrumente zum Erreichen der Ziele ggf. behindern kann.

Viel hilft nicht viel

Die erste Perspektive betrachtet erst einmal Geschäftsprozesse an sich. Wir wissen, dass Geschäftsprozesse wichtig sind und dass wir sie verstehen müssen, um ein Unternehmen und seine Geschäftsabläufe zu verstehen. Geschäftsprozesse sind das dynamische Gerüst, um das sich die Ablauforganisation eines Unternehmens anordnet. Während man die eher statische Aufbauorganisation meist recht einfach aus einem (hoffentlich aktuellen) Organisationschart ablesen kann, ist das mit Geschäftsprozessen (und der begleitenden Ablauforganisation) in der Regel nicht so einfach: Sie sind aufgrund ihrer dynamischen, nicht direkt sichtbaren Form schwerer zu erfassen und entsprechend oft auch nicht so gut dokumentiert. So scheint es naheliegend, die Geschäftsprozesse möglichst akkurat zu dokumentieren, um die Abläufe und die damit verbundene Wertschöpfung des Unternehmens möglichst gut zu verstehen. Doch ist das wirklich so? Hilft viel und detaillierte Dokumentation wirklich viel?

Modell für die Geschäftsebene einer Unternehmensarchitektur

Die Erfahrung lehrt, dass eine sehr feingranulare Dokumentation der Geschäftsprozesse eher kontraproduktiv wirkt. Es wird sehr viel Zeit und Aufwand in die Erfassung und Dokumentation der Prozesse investiert, aber praktisch niemand zieht einen Nutzen aus den entstehenden „Schrankwänden“ voll Dokumentation. Warum ist das so? Dafür gibt es verschiedene Gründe. An dieser Stelle möchte ich die folgenden drei, aus meiner Erfahrung besonders wichtigen Gründe herausgreifen:

  • Geschäftsprozesse unterliegen – zumindest im Detail – einer hohen Änderungsdynamik. Im Gegensatz zu den relativ stabilen Geschäftsfunktionen ändern sich die darauf aufsetzenden Prozesse sehr dynamisch, haben also bildlich gesprochen eine recht kurze Halbwertszeit. Erfasst und dokumentiert man Geschäftsprozesse zu detailliert, benötigt das relativ viel Zeit, sodass vereinfacht ausgedrückt der erste Geschäftsprozess schon lange nicht mehr in der beschriebenen Form existiert, bevor der letzte Prozess dokumentiert ist.
  • Die reine Informationsmenge wirkt auf die meisten Menschen schlicht abschreckend, oftmals geradezu erschlagend. Wer kennt das nicht, dass man bei einem dicken Dokument schon gar keine Lust mehr hat, überhaupt anzufangen, es zu lesen? Das ist eine Art natürlicher Überlastungsreflex unseres Gehirns, weil es weiß, dass es diese Informationsmenge nicht wirklich überblicken und in ihrer Gesamtheit verarbeiten kann. Aus dem Grund versucht es, schon vorher zu blockieren. Und selbst, wenn wir diesen Schutzreflex überwinden und uns tapfer durch die Unmenge von Informationen durcharbeiten, werden wir in der Regel wenig echten Nutzen daraus ziehen können, denn die Masse an Detailinformationen versperrt uns den Blick auf die elementaren Zusammenhänge. So erkennen wir üblicherweise nicht die wirklich bedeutenden Verbesserungspotenziale. Wir sehen den Wald vor lauter Bäumen nicht mehr.
  • Ein zusätzliches Problem ergibt sich daraus, dass viele Geschäftsprozess-Erfassungsvorhaben mit der Erfassung des Ist-Zustands beginnen. Eine detaillierte Erfassung des Ist-Zustands hat sehr häufig eine ungewollte Beschränkung des Denkhorizonts bei den beteiligten Personen zur Folge. Sie normieren ihr Denkmodell unbewusst mit dem sehr detailliert untersuchten Ist-Zustand. Der Ist-Zustand wird zum Referenzmodell (ein natürliches Verhalten des menschlichen Gehirns). Mit dieser Beschränkung fällt es in der Regel sehr schwer, echte Verbesserungspotenziale zu identifizieren und einen möglichst optimalen Soll-Zustand zu ermitteln. Meistens werden sich die Soll-Geschäftsprozesse dann nicht an den Unternehmenserfordernissen ausrichten, sondern werden mehr oder minder direkt aus den Ist-Prozessen mit all ihren ggf. vorhandenen Unzulänglichkeiten abgeleitet.

Welche Empfehlungen lassen sich aus diesen Beobachtungen ableiten? Als Erstes sollten Geschäftsprozesse nicht zu detailliert erfasst und dokumentiert werden (Tabelle 1).

Aufgrund ihrer hohen Veränderungsdynamik ist das in der Regel verschwendetes Geld. Stattdessen sollten die Prozesse leichtgewichtig beschrieben werden, um das notwendige Verständnis und den erforderlichen Überblick sicherzustellen. Eine weitere Verfeinerung sollte nur situativ erfolgen, z. B. im Rahmen konkreter Projekte und dann auch nur beschränkt auf die Prozessteile, die das Projekt berührt. Zusätzlich sollte die Geschäftsprozesserfassung mit den an den Unternehmenszielen und -bedürfnissen ausgerichteten Sollprozessen beginnen, um den Beteiligten ein möglichst optimales, das Handeln normierendes Referenzmodell zu bieten. Nebenbei sieht man auf diese Weise bei der nachfolgenden Erfassung des Ist-Zustands wesentlich schneller die Unterschiede, die ggf. vorhandenen Unzulänglichkeiten und die daraus resultierenden Verbesserungspotenziale.

Hierzu noch eine kurze Ergänzung: Ein Kernargument der Verfechter des Beginnens mit der Ist-Erfassung ist, dass es keinen Sinn mache, einen Soll-Zustand ohne die Kenntnis des Ist-Zustands zu entwerfen, da dies häufig in nicht umsetzbaren Soll-Modellen resultiere und die geleistete Arbeit damit nicht nutzbar wäre. Nun ist es richtig, dass man nicht direkt umsetzbare Soll-Modelle entwerfen kann. Das ist aber nicht weiter schlimm, denn der entworfene Soll-Zustand muss gar nicht vollständig erreicht werden. Vielmehr sollte der Soll-Zustand eine Art Richtungsvektor für Veränderungen an den Geschäftsprozessen darstellen. Die konkrete Ermittlung von Veränderungsschritten ist die Aufgabe der Transitionsplanung, die sich an das Ermitteln des Ist- und Sollzustands anschließt. Ohne einen guten, möglichst optimal an den Geschäftserfordernissen ausgerichteten Soll-Zustand werden die ermittelten Veränderungsschritte meist nur kleinere, lokale Optimierungen des Ist-Zustands sein und keine konsequente Verbesserung in Richtung der Unternehmenserfordernisse.

Geschäftsprozesse sind nur ein Teil des Ganzen

In der zweiten Perspektive geht es um die Frage, ob Geschäftsprozesse überhaupt ausreichend sind, ein Unternehmen fachlich zu beschreiben. Viele Unternehmen fokussieren sich bei der Optimierung des Business (und der damit verbundenen IT-Unterstützung) sehr stark auf Geschäftsprozesse. Doch ist das überhaupt ausreichend, um ein Unternehmen basierend auf seinen Zielen und Bedürfnissen umfassend zu optimieren? Eine recht gute Antwort darauf liefern gängige Unternehmensarchitekturmodelle wie Archimate [5]. Wenn man sich anschaut, welche Entitäten diese Modelle auf Geschäftsebene berücksichtigen, sieht man direkt, dass Geschäftsprozesse nur eine relevante Dimension sind. Im Detail unterscheiden sich die verschiedenen Modelle, aber typischerweise betrachten sie alle neben den Geschäftsprozessen zusätzlich mindestens noch die Organisation und die Produkte, häufi g auch noch Geschäftsstrategie und -regeln (Contracts und Policies) sowie Informationen im Sinne einer Informationsarchitektur (Abb. 1).

Um ein Unternehmen in seiner Gesamtheit verstehen – und optimieren – zu können, muss man auf der obersten Ebene neben den Geschäftsprozessen mindestens die Organisation und die Produkte verstehen, die das Unternehmen anbietet (wobei hier auch Dienstleistungen als Produkte verstanden werden). Im Rahmen des Geschäftsprozessmanagements erhält man durch die Verbindung der Geschäftsfunktionen mit Rollen häufig noch einen Einblick in die Ablauforganisation, aber sowohl die Aufbauorganisation als insbesondere die Produkte lassen sich im Rahmen von GPM nicht ausreichend durchdringen, um sie zu verstehen. Diese Einschränkung birgt gerade im Hinblick auf die Produkte zwei Risiken:

  • Die Produkte sind der eigentliche Unternehmenszweck. Die Kunden des Unternehmens kaufen die Produkte, keine Organisation und keine Prozesse. Es ist unmöglich, ein Unternehmen zu verstehen, wenn man seine Produkte nicht verstanden hat, denn die Produkte defi nieren letztlich das Unternehmen. Ohne Verständnis der Produkte ist es daher zumindest sehr schwer, ein Unternehmen zielgerichtet und effektiv zu verbessern.
  • Es ist wichtig zu verstehen, welche Teile einer Geschäftsarchitektur die relevanten Treiber für Veränderungen sind, sowohl auf Geschäftsebene als auch auf der unterstützenden IT-Ebene. Es gibt Unternehmen wie z. B. Versicherungen oder viele produzierende Unternehmen, deren Geschäftsprozesse im Kern seit Langem bekannt und relativ stabil sind. Die eigentlichen Treiber für Veränderungen liegen dort in den Produkten, und die Treiber für Optimierungen häufig in der Organisation (d. h. die Prozesse sind suboptimal aufgrund einer den Produkten und Prozessen nicht mehr angemessenen Organisation und nicht umgekehrt). Fokussiert man sich unter solchen Rahmenbedingungen auf die Geschäftsprozesse, wird man die eigentlichen Veränderungs- und Optimierungstreiber nicht erkennen und nicht verstehen können.

Was lässt sich daraus lernen? Geschäftsprozessmanagement und -optimierung sind wichtig, um unnötige Blind- und Fehlleistungen bei der Herstellung der Produkte und den begleitenden Abläufen zu vermeiden, d. h. um bildlich gesprochen möglichst wenig Geld aus dem Fenster zu werfen. Eine ausschließliche Fokussierung auf GPM ist aber in der Regel nicht zweckdienlich. Man muss mindestens noch die Organisation und die Produkte des Unternehmens verstehen, besser auch noch die weiteren zuvor beschriebenen Größen, um ein Unternehmen basierend auf seinen Zielen und Bedürfnissen verbessern zu können. Der Blick über den Tellerrand ist nicht nur wünschenswert, sondern sogar erforderlich, um die richtigen Treiber identifizieren und die richtigen Maßnahmen ableiten zu können. Das gilt nicht nur für die Geschäftsebene, sondern auch für die unterstützende IT-Ebene. Nur mit einem umfassenden Verständnis aller genannten Geschäftsdimensionen wird man als Architekt tragfähige IT-Lösungen entwickeln können.

Innovation und Geschäftsprozesse können sich beissen

In der dritten Perspektive wird die Frage betrachtet, ob GPM nicht sogar das Potenzial bergen kann, wichtige Unternehmensziele nicht zu erreichen. Um diese Fragestellung zu beantworten, muss man erst einmal betrachten, was die Ziele von GPM sind: GPM versucht durch kontinuierliche Verbesserung, die Blind- und Fehlleistung in den Abläufen zu minimieren und die Nutzleistung zu maximieren. Das bedeutet eine Optimierung eines Status quo (bezogen auf den Unternehmenszweck) entweder durch Erhöhung des möglichen Durchsatzes (Steigerung des Umsatzes bei konstantem Ertrag-Kosten-Verhältnis) oder durch Reduktion von Kosten (Verbesserung des Ertrag-Kosten-Verhältnisses). Das sind für jedes Unternehmen wichtige Ziele, da sie i. d. R. eine Steigerung des Gewinns zur Folge haben.

Einen Hebel zur Steigerung des Gewinns deckt das GPM aber überhaupt nicht ab, nämlich die Verbesserung des Ertrag-Kosten-Verhältnisses durch eine Steigerung des Ertrags. Das ist in der Regel nur durch Innovationen möglich: Man verbessert das Produkt in einer Form, dass der Kunde bereit ist, dafür einen relativ zu den Kosten deutlich höheren Preis zu zahlen als für das alte Produkt. Innovation ist eine existenzielle Triebkraft für alle Unternehmen, denn nur Innovationen ermöglichen ein gutes Ertrag-Kosten-Verhältnis. Alte Produkte geraten immer unter Preisdruck, weil die Kunden nicht mehr bereit sind, so viel Geld dafür zu zahlen wie für neue Produkte. Das bedeutet, dass die meisten Unternehmen (bis auf ein paar wenige Kostenführer [6]) darauf angewiesen sind, innovativ zu sein, um langfristig überleben zu können.

Was hat das mit Geschäftsprozessen zu tun? Nun, eine strikte Fokussierung auf GPM kann dazu führen, dass man das Thema Innovation aus den Augen verliert. Anstatt sich darauf zu konzentrieren, dem Kunden genau das Produkt anzubieten, das er haben will, konzentriert man sich darauf, die Herstellung der vorhandenen Produkte zu optimieren. GPM ist eine primär nach innen gerichtete Tätigkeit. Konzentriert man sich zu sehr auf GPM, verliert man die Kunden und ihre Wünsche aus den Augen und optimiert sich schlicht zu Tode. Besonders kritisch wird es, wenn auch die Innovation dem GPM unterworfen werden soll. Man hört immer wieder den Begriff Innovationsprozess, aus meiner Wahrnehmung ein Widerspruch in sich. Innovation ist kreativ und folgt keinem Prozess. Für Innovation muss man erst einmal eine Umgebung schaffen, in der man neue Ideen entwickeln kann. Man muss die Möglichkeit haben, bekannte Pfade (sprich Prozesse) zu verlassen, um Neues zu entdecken.

Versucht man nun – wie gelegentlich zu beobachten – Innovation mit Mitteln des GPMs zu optimieren, so führt das ganz schnell zu immer weniger Innovation, weil das Prozesskorsett keinen Platz für die Kreativität lässt, die man für Innovation benötigt. Natürlich braucht man ein Verfahren, um erfolgversprechendere Ideen von solchen zu trennen, die es nicht sind, und man braucht verschiedene Test- und Validierungsschritte, bevor aus einer Idee ein neues Produkt wird, das man auf den Markt bringt. Doch zum einen haben sich für richtige Innovationen häufig wenig formale Verfahren als ziemlich erfolgreich erwiesen (z. B. subjektive Beurteilung durch ein Expertenteam) und zum anderen muss man erst einmal den
kreativen Raum schaffen, um möglichst ungehindert neue Ideen zu entwickeln. Wenn man diese Bereiche aggressiv mit GPM-Mitteln optimiert, läuft man Gefahr, seine Innovationsfähigkeit empfindlich zu reduzieren.

Auch hier wieder die Empfehlung, GPM mit Augenmaß zu betreiben, sowohl auf Geschäfts- als auch auf ITEbene. Zu viel GPM erstickt die Innovationsfähigkeit, zu wenig GPM lässt die Blind- und Fehlleistungen unnötig anwachsen. Am Rande bemerkt, lässt sich diese Beobachtung in der gleichen Form auf IT-Governance und Unternehmensarchitekturmanagement übertragen. Es gilt, die Mitte zwischen Lähmung und Chaos zu finden.

Zusammenfassung

Natürlich gäbe es noch eine Menge mehr zu diesem Thema zu schreiben, und auch die hier diskutierten Aspekte sind bei Weitem nicht vollständig betrachtet. Dennoch lässt sich mit bekannten Worten von Paracelsus zusammenfassend ein Fazit ziehen: Die Dosis macht’s!

Geschäftsprozesse sind wichtig, wir sollten sie auch kontinuierlich verbessern und – wo sinnvoll – automatisieren. Auf der anderen Seite muss man aber auch beachten, dass Geschäftsprozesse nicht alles sind und eine übermäßige Fokussierung bzw. Detaillierung kontraproduktiv wirken kann. Das Hauptproblem ist, dass sich sehr viele Leute schwer damit tun, eine angemessene Balance zu finden und stattdessen häufig in die einfacher zu verstehenden und zu verkaufenden Extreme abdriften. In Unternehmen wird dieser Effekt durch verstärkende kommunikative Rückkopplungsschleifen in der Organisation häufig noch verstärkt, die sinnvolle Mitte zu finden, ist noch schwieriger. Hier ist es extrem wichtig, immer im Auge zu behalten, was man wofür benötigt und wie viel davon gesund ist. Genau das ist aus meiner Überzeugung eine der Kernaufgaben eines Architekten, egal ob als Unternehmens- oder Softwarearchitekt: Er muss den Überblick bewahren, immer auch den Blick über den Tellerrand wagen und im Rahmen seines Wirkens aktiv unterstützen, eine mehrwertmaximierende Balance zwischen den verschiedenen Kräften zu finden und zu etablieren. Das gilt für alle Themenbereiche, aber insbesondere auch für das wichtige Thema Geschäftsprozesse.

Links & Literatur

[1] Wikipedia: Geschäftsprozesse: http://de.wikipedia.org/wiki/Geschäftsprozess
[2] Wikipedia: Business Process Reengineering: http://en.wikipedia.org/wiki/Business_process_reengineering
[3] Allweyer, Thomas: „Geschäftsprozessmanagement“, W3IVerlag 2005
[4] Schmelzer, H. J.; Sesselmann, W.: „Geschäftsprozessmanagement in der Praxis“, 6. Auflage, Hanser Verlag 2008
[5] Archimate: siehe http://www.archimate.org/
[6] Wettbewerbsmatrix nach Michael E. Porter: http://de.wikipedia.org/wiki/Wettbewerbsmatrix

Vollständiger Artikel