End-to-End-Geschäftsprozessmanagement: Organisationselement - Integrationsinstrument - Managementansatz

fl SpringerWienNewYork Stefan Bergsmann End-to-EndGeschäftsprozessmanagement Organisationselement – Integrationsinst...

Author: Stefan Bergsmann

331 downloads 2062 Views 4MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

fl SpringerWienNewYork

Stefan Bergsmann

End-to-EndGeschäftsprozessmanagement Organisationselement – Integrationsinstrument – Managementansatz

SpringerWienNewYork

Dr. Stefan Bergsmann Wien, Österreich

Gedruckt mit Unterstützung des Bundesministeriums für Wissenschaft und Forschung, Wien.

Das Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdruckes, der Entnahme von Abbildungen, der Funksendung, der Wiedergabe auf photomechanischem oder ähnlichem Wege und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Produkthaftung: Sämtliche Angaben in diesem Fachbuch/wissenschaftlichen Werk erfolgen trotz sorgfältiger Bearbeitung und Kontrolle ohne Gewähr. Eine Haftung des Autors oder des Verlages aus dem Inhalt dieses Werkes ist ausgeschlossen. © 2012 Springer-Verlag/Wien

SpringerWienNewYork ist ein Unternehmen von Springer Science + Business Media springer.at Satz/Layout: Jung Crossmedia Publishing GmbH, 35633 Lahnau, Deutschland Druck: Strauss GmbH, 69509 Mörlenbach, Deutschland Gedruckt auf säurefreiem, chlorfrei gebleichtem Papier SPIN 80063450 Mit 79 Abbildungen Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-7091-0839-0 SpringerWienNewYork

Inhalt 1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2 End-to-End-Verständnis von Geschäftsprozessen . . . . . . . . . . . . . . . . . . . . 11 2.1 Etabliertes Prozessverständnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Echte End-to-End-Definition von Geschäftsprozessen . . . . . . . . . . . . . . 16 2.2.1 Definition End-to-End-Geschäftsprozess . . . . . . . . . . . . . . . . . . 16 2.2.2 Geschäftsprozesssicht und Kundenorientierung . . . . . . . . . . . . . 30 2.2.3 Prozesssicht und Mitarbeiterorientierung . . . . . . . . . . . . . . . . . . 33 2.2.4 Abgrenzung von Unternehmensfunktionen . . . . . . . . . . . . . . . . 35 2.2.5 Abgrenzung von Organisationseinheiten . . . . . . . . . . . . . . . . . . 46 2.2.6 Benennung von Prozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.3 Identifizieren von End-to-End-Geschäftsprozessen . . . . . . . . . . . . . . . . 49 2.3.1 Leistungserstellungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.3.2 Bereitstellungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.3.3 Steuerungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.3.4 Prozesskategorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.3.5 Erhebung und Detaillierung von Teilprozessen . . . . . . . . . . . . . . 81 2.3.6 Abgrenzen von Teilprozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.3.7 Prozessvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 2.3.8 Prozessarchitektur und Detaillierungstiefe . . . . . . . . . . . . . . . . . 92 2.3.9 Modellierungsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 2.3.10 Prozessbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3 Prozessmanagement als Organisationselement . . . . . . . . . . . . . . . . . . . . . . 3.1 Möglichkeiten der Organisation von Unternehmen . . . . . . . . . . . . . . . . 3.1.1 Allgemeine Ziele einer Organisationsstruktur . . . . . . . . . . . . . . . 3.1.2 Grundlegende Elemente einer Organisationsstruktur . . . . . . . . . 3.1.3 Faktischer Primat der Aufbauorganisation . . . . . . . . . . . . . . . . . 3.1.4 Möglichkeiten zur Gestaltung der Aufbauorganisation . . . . . . . . 3.1.5 Prozessorganisation – Ideal oder Mythos . . . . . . . . . . . . . . . . . . 3.2 Prozessverantwortung – Prozessmanagement als Element der Sekundärorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Prozessmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Zentrales Prozessmanagementteam . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Strukturelle Verankerung der Rollen in der Organisation . . . . . . 3.2.5 Koordinationsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 107 108 115 117 120 125 140 144 148 150 153 157 V

Inhalt

4 Prozessmanagement als Integrationsinstrument . . . . . . . . . . . . . . . . . . . . . 4.1 Integration über die Teilprozesse zur Leistungserstellung . . . . . . . . . . . 4.2 Integration über Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Integration über IT-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Integration über Produkte und Leistungen . . . . . . . . . . . . . . . . . . . . . . 4.5 Integration über gemeinsam genutzte Ressourcen . . . . . . . . . . . . . . . . . 4.6 Integration über Standorte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Integration über die Wertschöpfung zu Lieferanten und Kunden . . . . . 4.8 Integrative Process Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Integration nach größeren Reorganisationen . . . . . . . . . . . . . . . . . . . . . 4.10 Integration bei Firmenakquisitionen . . . . . . . . . . . . . . . . . . . . . . . . . . .

167 167 169 172 174 178 179 183 185 192 194

5 Prozessmanagement als Managementansatz . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Managementverständnis von Prozessmanagement . . . . . . . . . . . . . . . . 5.2 Managen des Prozessmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Ziele des Prozessmanagements festlegen . . . . . . . . . . . . . . . . . . . 5.2.2 Prozessmanagementstrategie festlegen . . . . . . . . . . . . . . . . . . . . 5.2.3 Planung für das Prozessmanagement erstellen . . . . . . . . . . . . . . 5.2.4 Zielvereinbarungen festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.5 Performance des Prozessmanagements monitoren und analysieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.6 Normen des Prozessmanagements festlegen . . . . . . . . . . . . . . . . 5.3 Managen der Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Ziele für Prozesse festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Prozessperformance messen und analysieren . . . . . . . . . . . . . . . 5.3.3 Prozess optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 Verbesserung der Prozessperformance überprüfen . . . . . . . . . . . 5.3.5 Learnings ziehen und transferieren . . . . . . . . . . . . . . . . . . . . . . .

197 197 203 203 204 214 216 217 221 224 225 230 233 249 252

6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

VI

1 Einleitung Prozessmanagement ist heute kein Fremdwort mehr. Ganz im Gegenteil: Es ist weitgehend über den Stand einer Modewelle hinaus akzeptiert; viele Unternehmen geben an, Prozessmanagement wichtig zu finden und in der einen oder anderen Form bei sich umgesetzt zu haben; Positionen als Prozessmanager oder zumindest mit verschiedenen Aspekten des Prozessmanagements finden sich vermehrt in den Stellenanzeigen; der Markt für Softwaretools zur Modellierung, Analyse und noch mehr zur Unterstützung von Geschäftsprozessen hat einen hohen Reifegrad erreicht. Es gibt kaum mehr Unternehmen und Organisationen, die nicht in irgendeiner Form Prozessmodelle haben oder diese zumindest für die Erfüllung bestimmter Normen oder im Zuge der Arbeit in bestimmten Projekten einsetzen. Kein Wunder, verspricht Prozessmanagement doch Verbesserungen in allen Bereichen des Unternehmens: von der Verkürzung der Bearbeitungs- und Durchlaufzeiten, über Kostenreduktionen und bessere Qualität bis hin zu weniger Verschwendung, zufriedeneren Mitarbeitern, Kunden und Geschäftspartnern. Ausgehend von dieser Verbreitung könnte man zu dem Schluss gelangen, dass sich Prozessmanagement heute als wichtiger Managementansatz etabliert hat und zum normalen Managementinstrumentarium gehört.1 Dies wäre jedoch weit gefehlt. Denn blickt man genauer hin, so zeigt sich vielfach ein ganz anderes Bild: Geschäftsprozesse und Prozessmanagement sind zwar auch unter Topmanagern in Vorstands- und Geschäftsführeretagen nominell positiv besetzte Begriffe. Kaum jemand bestreitet, dass gute und ständig verbesserte Prozesse wichtig sind. Dennoch ist Prozessmanagement und die damit verbundene Prozesssicht auf das Unternehmen kein Managementthema von höchster Priorität. Topmanager befassen sich in erster Linie mit der Strategie ihrer Unternehmen, mit der Steuerung, den aufbauorganisatorischen Strukturen und – in Krisenzeiten – mit dem rigiden Management der Kosten. Prozesse sind dabei nicht primärer Anknüpfungspunkt für klassisches Management, sondern werden eher als Aufgabe für die unteren operativen Ebenen gesehen. Das hat sich insbesondere in der aktuellen Wirtschaftskrise gezeigt, in der Topmanager fast ausnahmslos auf bewährte Restrukturierungs- und Cost Cutting-Ansätze gesetzt haben, während Prozessmanagement und die darin enthaltenen Prozessoptimierungsansätze zur Krisenbewältigung nur sehr vereinzelt eingesetzt wurden.2 Ja, teilweise fielen die Prozessteams und Prozessmanagementaktivitäten 1 Vgl. dazu z. B. die European Association of Business Process Management, aus deren Sicht sich Prozessmanagement „immer stärker zur dominanten Managementphilosophie entwickelt hat.“ EABPM (2009), S. 19. 2 Vgl. dazu Schmelzer, Sesselmann (2010): Sie halten fest, dass es für deutsche Unternehmen Tradition habe, Ergebnisprobleme über Kostensenkungsprogramme und weniger über Qualitätssteigerungsoder Zeitreduzierungsprogramme zu lösen (S. 3).

S. Bergsmann, End-to-End-Geschäftsprozessmanagement © Springer-Verlag/Wien 2012

1

Einleitung

selbst den Einsparungen zum Opfer. Während Topmanager versuchten die Krise über die Restrukturierung der Aufbauorganisation und ein drastisches, top-down getriebenes Streichen von Kostenpositionen zu bewältigen, war es die meist unausgesprochene Erwartung an das mittlere Management sicherzustellen, dass trotz einschneidender Änderungen die Prozesse weiterhin noch einigermaßen problemfrei funktionierten. Prozessmanagement ist heute kein Topmanagementthema und kein primäres Instrument des Topmanagements – es ist als Thema in Topmanagementkreisen schlichtweg „unsexy“. Im Bereich der operativen Detailsteuerung wird es durchaus als wichtig gesehen, jedoch als eher weiches Randthema in den Operations nicht mit allzu hohen Erwartungen verknüpft. Wenn es wirklich ernst wird, greifen Manager auf andere, bewährte Instrumente zurück. Ebenso zeigt sich auf der operativen Ebene des Prozessmanagements bei einer detaillierten Betrachtung ein sehr gemischtes Bild: Existierende Prozessmodelle sind vielfach veraltet und nicht mehr aktuell; Modellierungstools werden oft nur zum Zeichnen von Abläufen verwendet, während ihre vielfältigen Analyse- und Optimierungsfunktionalitäten zum Großteil brachliegen; Prozessmanagement, das im Zuge von speziellen Projekten eingeführt wurde, wird oft nur halbherzig in den operativen Betrieb übernommen und nur teilweise oder gar nicht gelebt; nominierte Prozessmanager bestehen oft nur am Papier, werden bei Abgängen nicht nachbesetzt oder sind isolierte Einzelkämpfer zwischen den nach wie vor dominierenden funktionalen Silos und Abteilungsreichen; selbst Prozessmanagementsysteme, die auf Normen basieren, werden vielfach nur als Pflichterfüllung gegenüber dem Markt oder wichtigen Lieferanten und Kunden aktualisiert; Prozessoptimierungsinitiativen versanden in der Umsetzung und bringen keine transparent nachvollziehbaren Optimierungseffekte. Prozessmanagement ist auf operativer Ebene durchaus ein beliebtes Thema, wirklich aktive und akzeptierte Prozessmanagementteams sind jedoch nach wie vor selten. Viele Prozessmanager nutzen vielmehr ihr breites Wissen über die Prozesse ihres Unternehmens als willkommenes Sprungbrett, um möglichst rasch einen anderen, „richtigen“ Job in der Unternehmenshierarchie zu bekommen. Als Drittes zeigt sich dieses gemischte Bild auch in der wissenschaftlichen Verarbeitung. Während das Thema in den letzten Jahren sehr rasch Eingang in die Curricula verschiedener Fachhochschul- und Masterlehrgänge gefunden hat, sucht man es in klassischen betriebswirtschaftlichen Lehrplänen nach wie vor oft vergeblich. Kommt es vor, dann meist nur sehr am Rande und ohne klare Verbindung in die Organisationslehre, zu der es eigentlich gehört.3 In der Literatur zum Thema nehmen die Versuche, Prozessmanagementansätze mit den Konzepten der Organisationslehre zu verbinden, dankenswerterweise in den letzten Jahren zu.4 In der Vergangenheit war dies jedoch 3 Vgl. Gaitanides (2007), für den der Einbau des Prozessmanagements in das Theoriegebäude der Organisationsforschung fast gänzlich fehlt (S. 3). Detto Schmelzer, Sesselmann (2010), S. 44. 4 Siehe z. B. Fischermanns (2006), Mayer, Fischer in Horváth & Partners (2005), S. 207, 223; Schober (2002), Mangler (2006) oder auch Kugeler, Vieting (2008).

2

Einleitung

nicht so der Fall. Zahlreiche publizierte Methoden- und Vorgehensanleitungen zum Prozessmanagement weisen keinerlei Bezug zur Organisationslehre auf, beschränken sich dabei auf einen kurzen Verweis auf die Wurzeln des Prozessdenkens bei Fritz Nordsieck und Karl Wilhelm Hennig5 oder auf kurze Referenzen zu den Ausprägungen des Organisationsbegriffs und klassischer Organisationsformen. Durch diese lange Zeit sehr isolierte Parallelentwicklung des Prozessansatzes präsentiert sich das Themenfeld nach wie vor für viele als isolierter Wissensbereich, der quasi einen Gegenvorschlag zur klassischen Unternehmensorganisation darstellt, eine Parallelwelt für alle, welche die hierarchische Organisationsstruktur nicht gut finden und nach Alternativvorschlägen suchen. Aber auch die Organisationslehre befasst sich ihrerseits viel stärker mit klassischen Organisationsformen und mit modernen Organisationstrends als mit Prozessmanagement. Erst seit Kurzem werden auch hier vermehrt Prozessmanagementansätze rezipiert und in die Darstellungen und Überlegungen der Organisationslehre einbezogen.6 Bisher passierte dies vielfach gar nicht oder nur am Rande, ohne die Arbeiten in diesem Themenfeld entsprechend zu reflektieren und ohne eine umfassende konzeptionelle Integration zu anderen diskutierten Organisationskonzepten.7 Es ist wirklich erstaunlich, wie ein Wissensgebiet einen der wesentlichsten neuen Trends in seinem Bereich über Jahre so verschlafen und ignorieren konnte. Das Prozessmanagement befindet sich als Managementansatz daher in einer Krise: Während es einerseits operativ mehr und mehr Verbreitung findet und mit hohen – vielfach auch zu hohen – Erwartungen verknüpft wird, ist es bisher nicht gelungen, das Thema als Element der Organisationsentwicklung und als echten Managementansatz auf der Ebene der Unternehmensleitungen nachhaltig zu verankern. Solange dies aber nicht gelingt, wird der mögliche Nutzen, den Prozessmanagement bringen kann, nicht oder zumindest nicht voll erreicht werden;8 solange ist Prozessmanagement nicht wirklich dauerhaft etabliert, undes besteht dieGefahr, dass es mit dem Aufkommen neuer Ansätze und Strömungen auchwieder an Bedeutung verliert und mangels sichtbarer und messbarer Beiträge zur Unternehmensperformance beiseite geschoben wird. Angesichts der zahlreichen positiven Effekte, die ein gut aufgesetztes Prozessmanagement bewirken 5 Zum Beispiel Bogaschewsky, Rollberg (1998), S. 20. 6 Siehe z. B. Nicolai (2009) und Klimmer (2007). 7 Vgl. dazu z. B. Burton et al. (2010), Schmidt (2006), Schreyögg (2006), S. 203–206. Ebenso Mayrhofer, Meyer, Titscher (2010), deren Sammelband über die Praxis der Organisationsanalyse Prozessansätze nur ganz am Rande unter dem Titel „Qualität und Produktion“ streift. Detto Kieser, Walgenbach (2010), die dem Prozessansatz gerade einmal einen kurzen Verweis auf die Prozessorganisation im Zusammenhang mit einer stärkeren Aufgabenintegration und der Delegation von Kompetenzen widmen (S. 76–77) sowie einen noch kürzeren Verweis auf ereignisgesteuerte Prozessketten als Mittel zur Einführung von ERP-Systemen in der Fertigung (S. 327), während das Thema Prozessmanagement im Abschnitt über mögliche Koordinationsinstrumente keinerlei Erwähnung findet (S. 93–127). 8 Vgl. Rummler, Ramias, Rummler (2010): Auch für sie hat die Prozessbewegung ihr echtes Potenzial noch nicht erreicht (S. 17).

3

Einleitung

kann, wäre dies sehr schade, da es – richtig verstanden – einen sehr wertvollen Beitrag zur Gestaltung und Steuerung von Unternehmen leisten kann. Eine wirkliche dauerhafte Verankerung kann jedoch nur erfolgen, wenn es gelingt, Prozessmanagement besser als Organisationselement und als Managementansatz zu entwickeln. Dafür sind mehrere Änderungen im Verständnis und in der grundsätzlichen Konzeption von Prozessmanagement notwendig: Zum Ersten muss es gelingen, den Mehrwert von Prozessmanagement gegenüber den traditionellen Sichtweisen auf die Unternehmensstruktur – nämlich jene der Aufbauorganisation und der Unternehmensfunktionen – klar herauszuarbeiten. Dafür muss die vielfach vorherrschende Vermischung von funktionalen, aufbauorganisatorischen und prozessualen Elementen unter dem Titel der „Prozesse“ überwunden und anstelle dieses bisherigen partiellen und funktionsorientierten Prozessverständnisses ein echtes End-to-End-Verständnis von Geschäftsprozessen etabliert werden.9 Hierfür bedarf es insbesondere einer klaren Definition des Prozesskonzepts aus einer End-to-EndSicht und eines eindeutigen Verständnisses, was mit end-to-end gemeint ist. Während viele der bekannteren Prozessdefinitionen hierfür ungeeignet und zu vage sind, gibt es durchaus auch Konzepte, die dieses stringente End-to-End-Verständnis zumindest teilweise beinhalten.10 In der Anwendung des Prozesskonzepts in der Unternehmenspraxis finden wir jedoch vielfach eine Vermischung mit funktionalen Elementen oder funktional abgegrenzten Teilprozessen. So beinhalten bestehende Prozessmodelle häufig „Prozesse“ wie „Vertrieb“, „Marketing“, „Produktion“ oder „Buchhaltung“. In vielen Fällen handelt es sich dabei trotz verwendeter Prozesssymbolik nur um die altbekannten funktionalen Einheiten. Dort wo sie tatsächlich prozessorientiert verstanden werden, dienen sie dennoch meist nur als isolierte Gliederungselemente, innerhalb derer dann erst entsprechende Prozesse mit einer Ablauflogik definiert sind. Damit werden Prozesse nur innerhalb der bekannten Funktionen und Bereiche definiert – die Gräben zwischen den so definierten Teilprozessen bleiben jedoch bestehen; der übergreifende Zusammenhang zur gemeinsamen Leistungserstellung für den Kunden fehlt.11 9 Vgl. dazu auch Rummler, Ramais, Rummler (2010), S. 215. 10 Vgl. dazu z. B. EABPM (2009): Für sie beschäftigt sich Business Process Management mit End-toEnd-Prozessen, die funktionsübergreifend sind und unmittelbar für den Kunden Wert schöpfen. (EABPM 2009, S. 39 und S. 47, ebenso S. 206). Ähnlich Bogaschewsky, Rollberg (1998, S. 205) die von der Betrachtung des „überbetrieblichen Wertschöpfungsprozesses“ sprechen. 11 Siehe dazu auch Gaitanides (2007), S. 55: Er sieht einzelne „Prozesse“ wie Kontaktbearbeitung, Anfragebearbeitung, Angebotsbearbeitung etc. ebenso nicht als Geschäftsprozesse, da sie keinen originären Kundennutzen stiften, sondern nur als „Bausteine für ein noch zu konstruierendes Prozessmodell“ und stellt bei so einem Fokus auf derartige Teilprozesse die Frage nach der Originalität der Prozessorganisation gegenüber der funktionalen Organisation. Vgl. auch Rummler, Remias, Rummler (2010): Sie haben die Prozessidee als Ansatz zum Managen der „weißen Flecken in den Organigrammen“ wesentlich mitentwickelt und stellen 2010 fest, dass durch die falsche Anwendung des Prozesskonzeptes noch viel gefährlichere weiße Flecken entstanden sind: jene zwischen den einzelnen Teilprozessen zur gesamten Wertschöpfung (S. 54). Vgl. auch Hammer (1997): Für ihn bestehen unsere Leistungsprobleme nicht in den einzelnen Aufgaben und Aktivitäten, sondern beziehen sich

4

Einleitung

Auf Basis dieses echten End-to-End-Prozessverständnisses müssen die Unterschiede und Zusammenhänge zwischen der aufbauorganisatorischen Sicht auf Unternehmen, der funktionalen Gliederung und der Prozesssicht klar herausgearbeitet werden. Nur wenn es gelingt, diese andere, ergänzende Sicht auf Unternehmen und ihren zusätzlichen Beitrag zum Verständnis, zur Optimierung und zur Steuerung von Unternehmen aufzuzeigen, kann die Prozesssichtweise des Prozessmanagements einen wertvollen Beitrag leisten und hat damit Aussicht auf dauerhafte Verankerung in den Unternehmen. Wie wir sehen werden, liegt dieser Beitrag vor allem in der Integration und in der frühzeitigeren, detaillierteren und geschäftsnäheren Steuerung. Der Schlüssel dazu ist ein echtes End-to-EndVerständnis von Geschäftsprozessen. Zum Zweiten ist es notwendig, Prozessmanagement wieder mit der klassischen Organisationslehre, aus der es sich ja eigentlich entwickelt hat, zu verknüpfen.12 Allzu viele Manager und Mitarbeiter glauben immer noch, dass Prozessmanagement ein Gegenpol zum traditionellen Organisationsdesign ist und zwingend zu einem Kippen der bestehenden Aufbauorganisation um 90 Grad führt. Dies darf nicht verwundern, findet sich das Anpreisen der Prozessorganisation als der quasi idealen Stufe der prozessorientierten Organisationsentwicklung nicht nur im Bestseller von Michael Hammer und James Champy, sondern auch nach wie vor in zahlreichen maßgeblichen Standardwerken zum Prozessmanagement.13 Vielfach wird dabei inzwischen in verschiedene Ausprägungen einer solchen Prozessorganisation differenziert, jedoch weiterhin meist mit der expliziten oder impliziten Aussage, je mehr Prozessorganisation desto besser – man könne es halt nur leider nicht überall sofort umsetzen. Das in Anlehnung an Alfred Chandlers Statement „structure follows strategy“ entwickelte Diktum „structure follows process“ suggeriert dabei eine eindimensionale Bestimmung der Aufbauorganisation aus den Geschäftsprozessen und führt das Idealbild der Prozessorganisation damit fort. Dies ist umso verwunderlicher, als die konkrete Ausgestaltung dieser idealen Prozessorganisation kaum irgendwo im Detail beschrieben wird und es in der Praxis so gut wie keine Beispiele für eine reine Prozessorganisation gibt. Die wenigen bekannten Beispiele, die Prozessorganisationen beschreiben, umfassen nicht komplette Endto-End-Prozesse in einer Verantwortung, sondern nur funktional abgegrenzte Teilprozesse, wie eben den Vertriebsprozess oder den Produktionsprozess. Auch wenn dies sicher gegenüber den davor bestehenden, noch viel mehr differenzierten Organisationsstrukturen eine stärkere Prozessintegration bringt, so handelt es sich dabei doch nicht um echte Prozessorganisationen. Ganz im Gegenteil: Tauscht man die neuen Prozessnamen gegen die alten Bereichs- oder Funktionsbezeichnungen, so bleibt meist nicht mehr viel an Änderung übrig. auf die Prozesse als der „Art und Weise, wie die Einzelschritte zu einem kohärenten Ganzen zusammengefügt werden“ (S. 21). 12 Vgl. Fischermanns (2006), S. 28. Ebenso Österle (1995/2010), S. 24. 13 Siehe z. B. Schmelzer, Sesselmann (2010), S. 77. Gareis, Stummer (2008).

5

Einleitung

Dass dieses falsche Idealbild der Prozessorganisation nach wie vor explizit oder implizit als Ziel propagiert wird, führt jedoch dazu, dass Initiativen zur Einführung von Prozessmanagement nach wie vor Ängste und Widerstände hervor rufen. Mitarbeiter und vor allem Führungskräfte des mittleren Managements stellen beim Begriff Prozessmanagement alle Haare auf und fürchten eine radikale Änderung der aktuellen Organisationsstrukturen. Kein Wunder, impliziert doch das eingeprägte Bild vom 90-GradShift der Organisation, dass derzeitige Führungs- und Machtverhältnisse beseitigt und durch völlig neue ersetzt werden. Dabei sind diese Ängste bei Zugrundelegen eines echten End-to-End-Prozessverständnisses völlig unbegründet. Definiert man Prozesse wirklich vom Kundenwunsch bis zur kompletten Leistungserbringung, so wäre eine komplette aufbauorganisatorische Integration dieser Wertkette betriebswirtschaftlich in den meisten Fällen völlig unsinnig. Und genau das ist auch der wahre Grund, warum es in der Praxis keine reinen Prozessorganisationen gibt. Ganz im Gegenteil zu den vielfach vorherrschenden Ängsten heißt Prozessmanagement auf Basis eines echten End-to-End-Verständnisses nicht, dass die Aufbauorganisation sich komplett an den Prozessen ausrichten muss, sondern dass das übergreifende Zusammenspiel der verschiedenen Einheiten verbessert und gezielt gesteuert werden soll. Das Design von Organisationsstrukturen wird durch verschiedenste Überlegungen beeinflusst. Prozessuale Überlegungen sind dabei nur ein Aspekt unter mehreren. Verstanden als Organisationselement, kann Prozessmanagement jedoch viel zur Verringerung der Probleme beitragen, unter denen gerade die angesprochene Gruppe – Mitarbeiter und mittleres Management – häufig leidet: mangelnde Effektivität in der bereichsübergreifenden Zusammenarbeit, unklare Zuständigkeiten, vage Schnittstellen zwischen den Bereichen und Ineffizienzen in der Abwicklung von Kundenfällen. Durch die mangelnde Rezeption und Einordnung des Prozessmanagementansatzes in das generelle Organisationsdesign von Unternehmen und die isolierte Veröffentlichung von Prozessmanagementanleitungen und -methodenbüchern tragen Vertreter des Prozessmanagements zu diesem Missverständnis auch selbst maßgeblich bei und helfen, den Mythos der Prozessorganisation als einer für manche besseren Idealwelt, für viele jedoch abzulehnenden Angstvision einer weitreichenden, nicht einschätzbaren organisatorischen Änderung weiter am Leben zu erhalten. Der zweite wichtige Punkt betrifft daher die Einordnung des Prozessmanagements in das Gesamtbild der Organisationsgestaltung und – damit konsequenterweise verbunden – das Verwerfen der reinen Prozessorganisation als anzustrebendem Zielbild. Drittens ist es dafür erforderlich, die möglichen positiven Effekte auf eine saubere theoretische Basis zu stellen und stringent herauszuarbeiten. Denn ein Ansatz, der von sich behauptet, alles im Unternehmen besser zu machen bis hin zu glücklichen Mitarbeitern und zufriedenen Kunden, läuft zum einen Gefahr, zu hohe Erwartungen zu schüren, denen man am Ende nicht gerecht werden kann; zum anderen riskiert er, angesichts überzogener Versprechungen nicht ernst genommen und in den Bereich esoterischer Träumereien geschoben zu werden. Auch dies wurde und wird leider von vie6

Einleitung

len Publikationen zum Thema immer noch vernachlässigt. Statt klare Abgrenzungen, saubere Konzepte und theoretische Fundierungen vorzulegen, bietet der Großteil der Prozessmanagementliteratur nach wie vor missionarische Ansätze mit einem breiten Heilsversprechen, die dann ohne klare Konzeption direkt in die Beschreibung der Methoden, Vorgehensweisen und Werkzeuge springen, mit denen dies erreicht werden soll.14 Dabei hat Prozessmanagement durchaus sehr konkrete und handfeste Verbesserungen für die Integration und Steuerung von Unternehmen zu bieten, sodass auch bei einer klaren Abgrenzung noch genug Positives übrig bleibt. Hierfür ist es insbesondere notwendig, Prozessmanagement als echten Managementansatz zu formulieren und zu verankern und nicht nur als Sammelsurium von Werkzeugen und Methoden. Gerade im Zuge neuerer Strömungen zum Verbessern von Prozessen wie etwa Six Sigma, Lean Management oder Lean SixSigma wird oft der Schwerpunkt sehr stark auf die Werkzeuge und deren professionelle Bedienung und Anwendung gelegt. Der Abtausch von methodischen Schlagwörtern und der Verweis auf bestimmte Standards innerhalb der entsprechenden Expertenrunden treten dabei vielfach vor das eigentliche Ziel der Optimierung im Sinne eines sichtbaren Beitrags zur Performancesteigerung.15 Dies zeigt sich insbesondere an der unterstellten Annahme, dass alle Prozesse im Unternehmen ständig und immer weiter verbessert werden müssten. Ganz im Gegenteil zu diesem Ansatz ist Management gerade ein zielorientiertes, sehr selektives und fokussiertes Agieren, bei dem nicht alles ständig gemacht wird, sondern die essenziellen Dinge zur richtigen Zeit. Dies heißt nicht, dass die Sinnhaftigkeit gut entwickelter und geschulter Werkzeuge und Methoden in Zweifel gezogen wird. Dort wo die Optimierung von Prozessen notwendig ist, sind diese Werkzeuge wertvoll und hilfreich, vielfach sogar notwendig. Ohne ein entsprechendes Managementverständnis besteht jedoch die Gefahr des Abgleitens in eine Heimwerkermentalität, bei der die Freude an neuen Werkzeugen und der gegenseitige Austausch über deren Nutzen und Bedienung über den Zweck des jeweils angestrebten Vorhabens gestellt werden. Gerade die neueren Ansätze, die sich auf die Verbesserung der Prozesse fokussieren, unterstützen diesen methodisch, technischen Zugang durch die erwähnte starke Fokussierung auf die Werkzeuge. Als Beitrag zur Diskussion um die „richtigen“ und „besseren“ Methoden und Werkzeuge soll dabei hier eine Anleihe bei Paul Feyerabend genommen werden, um den teilweise überzogenen Fokus auf die Werkzeugkästen wieder etwas zu relativieren und ins rechte Licht zu rücken. Anleitungen im Sinne methodischer Praxisleitfäden gibt es genug. Die Dimension des Managements kommt dabei jedoch zu kurz. 14 Vgl. dazu Schober (2002), der auch festhält, dass in Bezug auf die Erwartungen und Versprechungen des Prozessmanagements Ernüchterung eingetreten ist und dass es an einer theoretischen Fundierung des Prozessmanagements fehlt. 15 Vgl. Rummler, Ramias, Rummler (2010): Aus ihrer Sicht ist die BPM/Prozessmanagement-Bewegung vom Weg abgekommen, v. a. weil der Fokus nicht mehr auf der mit den Prozessen erstellten Leistung liegt, sondern sich alles nur mehr um die Mittel dreht, ohne Verbindung zum Ziel. (S. xvii).

7

Einleitung

Abb. 1: Entwicklung des Prozessmanagements

Diese drei Änderungen – ein echtes End-to-End-Verständnis von Geschäftsprozessen, das Verwerfen der reinen Prozessorganisation als Ideal auf Basis einer Einordnung von Prozessmanagement als Organisationselement in die Organisationslehre und ein echtes Managementverständnis des Prozessmanagements – weichen fundamental vom derzeitigen akzeptierten Body of Knowledge des Prozessmanagements ab. Das bisherige, stark funktional und von Dokumentation geprägte Prozessmanagement war notwendig, um den ersten Schritt in Richtung einer Prozesssicht in den Unternehmen zu schaffen; es war wichtig, um eine breite Akzeptanz für das Konzept von Geschäftsprozessen und seine Bedeutung zu erzielen; und es hat darüber hinaus auch in vielen Unternehmen und Organisationen zu deutlichen Verbesserungen in der Effektivität und Effizienz der Abläufe geführt. Jetzt stößt das Verbesserungspotenzial dieses Ansatzes jedoch an seine Grenzen: Prozesse sind als positives Konzept anerkannt, sie bieten aber in der derzeitigen Konzeption nicht mehr viel an neuem Verständnis und Erklärungswert; ebenso ist die Optimierung innerhalb der definierten, stark funktional geprägten Teilprozesse weitgehend erfolgt – weitere Potenziale können nur mit einer Ausweitung des Prozessverständnisses auf eine echte End-to-End-Betrachtung erreicht werden.16 Und dies ist wiederum nur mög16 Vgl. Davenport (1993, S. 28): Er hat bereits 1993 darauf hingewiesen, dass Prozesse möglichst breit definiert werden müssen, wenn signifikante Verbesserungen erzielt werden sollen, da eine Hauptquelle für Verbesserungen die Übergaben zwischen einzelnen Funktionen im Prozess sind. Vgl. ebenso Rummler, Brache (1997): „In our experience, the greatest opportunities for performance improvement often lie in the functional interfaces – those points at which the baton [. . .] is being passed on from one department to another.“ (S. 9)

8

Einleitung

lich, wenn Prozessmanagement nicht als drohendes Damoklesschwert der Prozessorganisation, sondern als ergänzendes und sinnvolles Instrument der Unternehmensorganisation gesehen wird. Das vorliegende Buch will genau dies mit einem ersten Schritt in diese Richtung versuchen und hierzu einen Betrag leisten, indem es die Rolle und Wirkungsweise von Prozessmanagement als Organisationselement, Integrationsinstrument und Managementansatz herausarbeitet. Es wäre vermessen zu glauben, dass dies alleine mit einem Buch gelingt, selbst wenn dieses auf vielen Jahren Erfahrung im Prozessmanagement und einer noch so umfassenden Recherche des aktuellen state-of-theart beruht. Insofern versteht sich das vorliegende Buch als Impuls, um der Entwicklung des Prozessmanagements und der Literatur darüber eine etwas andere, mehr managementorientierte Richtung zu geben. Wenn dies gelingt und sich auch andere Autoren aus dem Prozessmanagement aber auch aus der Organisationslehre damit auseinandersetzen und mit ergänzten, erweiterten oder auch konkurrierenden Vorschlägen dazu aufwarten, so scheint es mir gerechtfertigt, der reichen Fülle an Prozessmanagementbüchern auch noch dieses hinzuzufügen.

9

2 End-to-End-Verständnis von Geschäftsprozessen 2.1 Etabliertes Prozessverständnis Obwohl Geschäftsprozesse und Geschäftsprozessmanagement nun schon seit Jahren ein etabliertes Thema sind, gibt es dennoch keine allgemein anerkannte Definition von Geschäftsprozessen, ja nicht einmal von den wesentlichen Kernelementen einer solchen Definition. Dies zeigt sich einerseits in der umfangreichen Literatur zum Thema, andererseits auch im Prozessverständnis wie es in den Unternehmen heute etabliert ist.17 Blicken wir etwas auf die Literatur, so zeigt sich, dass einer guten und genauen Definition von Geschäftsprozessen wenig Augenmerk geschenkt worden ist und selbst namhafte Autoren mit sehr ungenauen und vagen Definitionen arbeiten: ·

·

·

·

Michael Hammer und James Champy bezeichnen etwa als „Unternehmensprozesse . . . jene Tätigkeiten, die zusammengenommen einen Wert für den Kunden schaffen“.18 Für Thomas Davenport ist ein Prozess eine zeitlich und räumlich spezifisch strukturierte Menge von Aktivitäten mit einem Anfang und einem Ende sowie klar definierten Inputs und Outputs: eine Struktur zum Handeln.19 Margit Osterloh und Jetta Frost sehen Geschäftsprozesse klar gekennzeichnet durch „die Bündelung von Aktivitäten und die strukturierte Reihenfolge von funktionsübergreifenden Aktivitäten mit einem Anfang und einem Ende sowie klar definierten Inputs und Outputs“.20 Die Object Management Group definiert in ihrem Business Motivation Model: „business processes realize courses of action. Courses of action are undertaken to ensure that the enterprise makes progress towards one or more of its goals“.21

17 Vgl. dazu Jon Siegel: Er stellt ebenso fest, dass es keine allgemein anerkannte Definition von Geschäftsprozessen gibt, vertritt dazu jedoch die abweichende Ansicht, dass es aufgrund der zahlreichen verschiedenen Zugänge zu Prozessmanagement auch keine solche allgemein anerkannte Definition geben kann: „the varying points of view virtually require differing definitions“. Siegel (2008), S. 1. 18 Hammer, Champy (1994), S. 14. Michael Hammer und James Champy führen als Beispiel für so einen Prozess die Entwicklung eines neuen Produkts an (ebenda) – es ist jedoch zweifelhaft, welchen Wert die Produktentwicklung für sich alleine genommen für den Kunden schafft. 19 Davenport (1993), S. 5. 20 Osterloh, Frost (2003), S. 31. 21 Zit. nach Siegel (2008), S. 2.


11

End-to-End-Verständnis von Geschäftsprozessen

Entsprechend diesen Definitionen wäre etwa die Produktion in einem Unternehmen ein Prozess, selbst wenn sie als Funktion organisiert ist und Produktionsaktivitäten an verschiedenen Stellen der Leistungserbringung umfasst, beginnend mit einer vorausgehenden Produktionsplanung über die Vorfertigung von Teilen und Baugruppen bis zur Fertigstellung der verschiedenen Produkte. Denn die Produktion schafft definitiv durch die Erstellung eines Produkts einen Wert für den Kunden. Laut Michael Hammer und James Champy wäre sie daher ein Prozess. Durch die Produktionsstätte und die Schichtzeiten ist die Produktion auch räumlich und zeitlich strukturiert; sie beginnt mit einem Produktionsplan und endet mit der Fertigstellung des Produkts; über die Materialien und die Produktionsaufträge sowie die fertigen Produkte sind die Inputs und Outputs klar definiert. Also wäre die Produktion auch nach der Definition von Thomas Davenport ganz klar ein Prozess. Ebenso kann man die Produktion als Bündelung aller Produktionsaktivitäten sehen, quer über alle Stufen der Leistungserstellung sowie über alle Produkte und Fertigungsarten; diese haben in sich auch eine bestimmte strukturierte Reihenfolge im Sinne einer Planung, der Vorfertigung, bestimmter Produktionsschritte und einer Endfertigung; wenn man annimmt, dass manche dieser Schritte von der Arbeitsvorbereitung, andere von der Schweißerei, der Dreherei und der Beschichtung erledigt werden, sind sie auch funktionsübergreifend im Sinne von Teilfunktionen innerhalb der Produktion; Produktionsauftrag und fertige Produktion markieren Anfang und Ende; Inputs und Outputs wurden bereits erwähnt – also ist die Produktion auch nach der Definition von Jetta Frost und Margit Osterloh ein Prozess. Und abschließend kann man auch sagen, dass die einzelnen Teilschritte der Produktion eine course of action vorgeben, der dem Unternehmen hilft einen Schritt in Richtung seiner Ziele, z. B. der Marktführerschaft in der Produktion spezieller Maschinen, weiter zu kommen. Also wäre die Produktion als Unternehmensfunktion auch nach der Definition der OMG ein Prozess. Ähnlich ist das Ergebnis, wenn wir die Praxis des Prozessmanagements in den Unternehmen ansehen. Hier ist der Begriff Prozess durchaus weit verbreitet und sehr positiv besetzt. Für Topmanager ist es klar, dass man sich „um die Prozesse kümmern muss“, dass sie die „Nervenbahnen des Unternehmens sind“ und dass Informationssysteme die Prozesse unterstützen müssen. Was sind aber nun die Prozesse, die hier gemeint sind? – Fragt man die Betreffenden oder sieht man sich die Prozessmodelle in Unternehmen an, so könnte man meinen, es handle sich bei Prozessen um eine moderne Bezeichnung für die allseits bekannten Unternehmensfunktionen: Es finden sich hier die Prozesse Buchhaltung, Materialwirtschaft, Controlling, Vertrieb oder Engineering. Ist ein Prozess also eine neue und positiv besetzte Bezeichnung für Altbekanntes? Und ist Prozessmanagement damit nur ein neues Label für die seit Jahren etablierte Unternehmensorganisation? Nein, natürlich nicht. Vielmehr wurden in den letzten Jahren auf der Basis des eher ungenauen Prozessverständnisses in der Literatur Geschäftsprozesse in der Praxis fast ausschließlich innerhalb von Bereichen definiert. So spricht man von den Ge12

Etabliertes Prozessverständnis

schäftsprozessen der Finanzabteilung, von den Vertriebsprozessen, den Logistikprozessen und den Supply-Chain-Prozessen, um nur ein paar Beispiele zu nennen. In der Umsetzung der Prozessdefinition in den Unternehmen hat dies den Charme, dass Prozesse klar bestimmten Einheiten zuordenbar sind. Damit ist es leicht, Akzeptanz für ein derartiges Prozessverständnis zu bekommen, da es keine Änderung in den Zuständigkeiten und Berichtslinien mit sich bringt. Gleichzeitig hat dieses organisationsbezogene Prozessverständnis am Beginn auch durchaus seine Berechtigung gehabt, ging es anfangs doch vielfach im ersten Schritt darum, innerhalb von Bereichen und Abteilungen Abläufe besser zu strukturieren und zu optimieren. Sieht man einmal vom Risiko der Verschiebung von Problemen in andere Bereiche hinein ab, so konnte dies mit diesem Prozessverständnis durchaus erreicht werden. Hatte sich die bis dahin vorherrschende Sicht auf die Ablauforganisation vielfach auf die Optimierung von einzelnen Arbeitsschritten innerhalb von bestimmten Stellen konzentriert, so stellte diese Art von Prozesssicht einen Schritt nach vorne dar und war hilfreich für die stellenübergreifende Effizienz- und Effektivitätssteigerung innerhalb der einzelnen Bereiche. Die Unternehmen haben in dieser Hinsicht in den letzten Jahren aber sehr viel gelernt und getan, sodass die Optimierung der Abläufe innerhalb von Bereichen heute in vielen Organisationen und Unternehmen als sehr weit fortgeschritten betrachtet werden kann. Optimierungspotenziale, die heute noch adressiert werden können, liegen nicht mehr innerhalb der Bereiche, sondern vielmehr in der bereichsübergreifenden, teilweise sogar der unternehmensübergreifenden Zusammenarbeit und im Zusammenspiel der einzelnen Teilbereiche für die Wertschöpfung. Genau dafür reicht das etablierte Prozessverständnis aber nicht mehr aus. In der Praxis sind manche Vertreter des Prozessansatzes und manche Beratungshäuser daher dazu übergegangen, nicht mehr Prozesse, sondern Prozessschnittstellen in den Mittelpunkt der Analyse und Optimierung zu stellen oder aber die entsprechenden bereichsübergreifenden Inputs und Outputs der so definierten Prozesse. Abgesehen von einer kurzfristigen Projektsicht greift dieser Ansatz aber zu kurz. Denn einerseits wird durch einen solchen reinen Fokus auf die Prozessschnittstellen die Ablaufstruktur der einzelnen Teilprozesse nicht aufeinander abgestimmt und aus der Gesamtsicht des Prozesses und der gegenseitigen Leistungsbeziehungen verbessert; andererseits verkennt ein derartiger Ansatz auch das generell zugrunde liegende Problem: jenes eines falschen Prozessverständnisses. Denn Prozesse sollen eben genau nicht anhand der Abteilungen und Bereiche definiert werden, da sie sonst über bereichsinterne Tätigkeitslisten und Teilprozessbeschreibungen nicht hinauskommen. Eine wirkliche bereichsübergreifende Integration ist damit nicht möglich. Der Wert eines solchen bereichsbezogenen Prozessverständnisses und Prozessmanagementansatzes erschöpft sich damit sehr rasch mit der erfolgten bereichsinternen Optimierung. Dies ist einer der wesentlichen Gründe, warum zahlreiche Unternehmen und Organisationen das Thema Prozessmanagement heute als weitgehend erledigt betrachten in dem Sinne, dass Prozessmanagement ein13


geführt ist und im definierten Rahmen besteht, und sie die Prioritäten längst wieder auf andere Managementthemen gerichtet haben. Der mit dem abteilungs- oder funktionsorientierten Prozessverständnis erzielbare Nutzen ist weitgehend erzielt, darüber hinausgehende Vorteile von diesem Prozesszugang nicht zu erwarten. Die konzeptionelle Uneinigkeit und Ungenauigkeit in Bezug auf eine klare und hilfreiche Definition des Konzepts des Geschäftsprozesses in der bekannten Literatur ist sicher ein Faktor, der an diesem falschen Prozessverständnis Mitschuld trägt. Teilweise gibt es jedoch auch sehr klar und gut erarbeitete Definitionen, die durchaus ein umfassendes End-to-End-Prozessverständnis oder zumindest wesentliche Teile davon beinhalten: ·

So definieren etwa Arnold Picot und Egon Franck Prozesse als Tätigkeitsfolgen, die Kundennutzen schaffen.22 Peter Horváth und Reinhold Mayer definieren einen Prozess als „eine auf die Erbringung eines Leistungsoutputs gerichtete Kette von Aktivitäten“, wobei sie als kennzeichnende Elemente einen internen oder externen Kunden, einen definierten Leistungsoutput, bestimmte Kosten-, Qualitäts- und Zeitanforderungen, die Inanspruchnahme von Ressourcen sowie Verfahren und Regeln anführen, die die Transformation zielgerichtet sicherstellen sollen.23 August-Wilhelm Scheer sieht einen Geschäftsprozess allgemein, als „eine zusammenhängende Abfolge von Unternehmungsverrichtungen zum Zweck einer Leistungserstellung. Ausgang und Ergebnis des Geschäftsprozesses ist eine Leistung, die von einem internen oder externen ‚Kunden‘ angefordert und abgenommen wird.“24 Die European Association of Business Process Management (EABPM) definiert einen Prozess als „eine Reihe von festgelegten Tätigkeiten (Aktivitäten, Aufgaben) [. . .], die von Menschen oder Maschinen ausgeführt werden, um ein oder mehrere Ziele zu erreichen“25 betont jedoch in der Folge auch das End-to-End-Verständnis von Prozessen: „Von einem End-to-End-Prozess wird immer dann gesprochen, wenn der Auslöser eines Prozesses (z. B. Bestellung eines externen Kunden) das gewünschte Ergebnis auch erhält, ganz unabhängig davon, wie viele interne Stellen von diesem Prozess berührt sind. Anfang und Ende liegen also nicht an den Grenzen einer Abteilung oder Organisationseinheit, sondern bei dem Verursacher des Prozesses“.26 Für Wolf-Dieter Mangler ist ein Geschäftsprozess „der durch eine bestimmte Produkt- oder Leistungsart des Unternehmens festgelegte Weg vom Wunsch des Kun-

·

·

·

·

22 23 24 25 26

14

Picot, Frank (1995), S. 14, zit. nach Gaitanides (2007), S. 54. Hervorhebung durch den Autor. Horváth, Mayer (1993), zit. in Horváth & Partners (2005), S. 3. Hervorhebung durch den Autor. Scheer (1998), S. 3. Hervorhebung in kursiv durch den Autor. EABPM (2009), S. 37. Hervorhebung in kursiv durch den Autor. EABPM (2009), S. 38. Hervorhebung in kursiv durch den Autor.

Etabliertes Prozessverständnis

·

den (z. B. Anfrage, Auftrag) bis zur Erfüllung des Kundenwunsches durch das eigene Unternehmen, z. B. in Form einer Produktauslieferung oder der Bereitstellung einer Dienstleistung. [. . .] Ein Geschäftsprozess ist die logische Aneinanderreihung der dafür erforderlichen Aktivitäten und Tätigkeiten“.27 Für Geary Rummler und Alan Brache ist ein Geschäftsprozess „a series of steps designed to produce a product or service“.28

Sicherlich gibt es auch in diesem Definitionen die eine oder andere Unschärfe oder unklare Interpretationsspielräume. Die Kernelemente eines Prozessverständnisses, das sich durch die Abfolgebeziehung zwischen den Tätigkeiten klar von der funktionalen Bündelung von Aufgaben abhebt und einen Geschäftsprozess aus einer End-toEnd-Perspektive sieht, vom Wunsch des Kunden bis zur erbrachten Leistung, und nicht nur definiert durch beliebige Inputs und Outputs, sind in diesen Konzepten jedoch deutlich vorhanden. Die Gründe für das etablierte bereichsorientierte Prozessverständnis dürften daher nicht nur in der mangelnden Konkretisierung der Konzepte in der Literatur liegen, sondern zu einem guten Teil auch in einer zu geringen theoretischen Fundierung der praktischen Umsetzung in den Unternehmen sowie einer zu großen Kompromissbereitschaft bei der Identifikation der Prozesse in der Diskussion mit Vertretern der Unternehmensfunktionen und Abteilungen in den jeweiligen Projekten. Im nächsten Abschnitt soll daher versucht werden, aufbauend auf diesen Definitionen einen von Unternehmensfunktionen klar abgegrenzten Prozessbegriff mit einem echten End-to-End-Verständnis zu entwickeln, der als Basis für die weiteren Überlegungen dienen kann. Dabei sollen jene Elemente herausgearbeitet werden, die für die Prozessdefinition konstitutiv und essenziell sind und bei denen daher in der Umsetzung auch keine Kompromisse gemacht werden dürfen. Für manche mag dies als theoretische Übung scheinen, der keine praktische Relevanz zukommt. Aber genau das Gegenteil ist der Fall. Nur wenn die Aktivitäten im Prozessmanagement auf einem klaren und sinnvollen Prozessbegriff aufbauen, dem ein echtes End-to-EndVerständnis zugrunde liegt, kann es gelingen, einen weiteren Entwicklungsweg aufzuzeigen und neue Potenziale zu erschließen. Denn Aussagen über mögliche Wirkungen 27 Mangler (2006), S. 24. Hervorhebung in kursiv durch den Autor. Mangler ist jedoch in seiner Definition nicht ganz eindeutig, da er an anderer Stelle konstatiert, dass sich für ihn Beginn und Ende eines Prozesses erst aus der subjektiven Sicht und Festlegung durch den Gestalter ergeben (S. 21) und auch in Bezug auf die hier zitierte End-to-End-Definition von Geschäftsprozessen empfiehlt, Gruppen von Geschäftsprozessen zu bilden, da die Anwendung der Definition zu sehr langen, unübersichtlichen und schwer handhabbaren Ablauffolgen führen würde (S. 24). Vgl. dazu auch Manglers End-to-End-Sicht auf S. 32, die etwas im Widerspruch zu stehen scheint mit seiner Definition vom „Totalprozess“ auf S. 23. 28 Rummler, Brache (1997), S. 45. Siehe auch Rummler, Ramais, Rummler (2010), wo die Autoren Prozesse als „the fundamental building block for defining and organizing the work required to create value“ sehen (S. 230).

15


von Prozessmanagement, über seinen Beitrag zur Unternehmensperformance und zu anderen Verbesserungsaspekten haben ihren Ursprung im zugrunde liegenden Konzept und dessen Elementen und Eigenschaften. Insofern ist eine klare konzeptionelle Grundlage auch etwas, was dazu beitragen kann, den möglichen Beitrag von Prozessmanagement klarer zu umreißen und die Erwartungen auf echte Optimierungsmöglichkeiten aus den Prozessen einzuschränken. Sie kann somit mithelfen, realistische Erwartungen an dieses Managementkonzept besser von unrealistischen Versprechungen zu trennen.

2.2 Echte End-to-End-Definition von Geschäftsprozessen 2.2.1 Definition End-to-End-Geschäftsprozess

Der erste Schritt für ein sinnvolles und wertstiftendes Prozessmanagement ist es, genau zu definieren, was ein End-to-End-Geschäftsprozess ist. Dies mag banal erscheinen, aber wie im letzten Abschnitt diskutiert wurde, ist dies weder in der Literatur noch in der Praxis klar, obwohl Prozessmanagement nun schon seit vielen Jahren etabliert ist. Obwohl es bereits eine umfangreiche Literatur zum Thema Prozessmanagement gibt, existiert keine exakte und allgemein anerkannte Definition, was genau ein Geschäftsprozess ist. Dies ist nun insofern nichts Ungewöhnliches, als dies in vielen sozialwissenschaftlichen Themenfeldern so ist. Unabhängig von der konkreten Formulierung sollten aber zumindest die konstitutiven und essenziellen Elemente einer solchen Definition weitgehend anerkannt sein und außer Streit stehen. Denn eine möglichst klare Definition der Kernelemente eines Konzepts, das den Ausgangs-, Kern- und Angelpunkt aller Überlegungen und darauf aufbauenden Hypothesen und Theorien bildet, ist nicht nur sinnvoll und generell hilfreich, sondern für die Herausbildung überprüfbarer Nutzenaussagen auch unumgänglich. Wollen wir in weiterer Folge Hypothesen ableiten, welchen Nutzen und Beitrag Prozessmanagement bringen kann, so können diese nur aus Eigenschaften des Konzepts und darauf aufbauenden Überlegungen folgen. Ein Konzept muss daher nicht nur die realen Fälle, die es beschreiben soll, adäquat abdecken, sondern vor allem auch theoretisch sinnvoll sein, das heißt klar umrissene Elemente herausarbeiten, aus denen in weiterer Folge interessante Aussagen über Zusammenhänge, Vorteile und Wertbeitrag erarbeitet werden können.29 Für ein klareres Bild über den Nutzen von Prozessmanagement ist daher ein klar definiertes Konzept eines Geschäftsprozesses absolut unumgänglich. 29 Siehe dazu das Verständnis von Theorien und Konzepten bei Kenneth Waltz (1979). Vgl. dazu z. B. auch Ould (2005), der ebenso die Wichtigkeit exakt definierter Konzepte betont: „poor definitions mean poor theories, and poor theories make poor practice“ (S. 3). Obwohl er für die Definition seiner Modellierungsmethode Riva in der Folge sehr genau alle Elemente definiert, bleibt seine Prozessdefinition allerdings sehr vage („A process is a coherent set of activities carried out by a collaborating group to achieve a goal“, S. 6).

16

Echte End-to-End-Definition von Geschäftsprozessen

Fehlt es oder bleibt die Definition unscharf, so leiden notgedrungen auch spätere Aussagen zum Nutzen von Prozessmanagement unter derselben Ungenauigkeit und sind damit nicht überprüfbar und argumentativ wenig wertvoll. Dieses Dilemma zeigt sich sehr deutlich in den breiten und umfangreichen Versprechungen, die vielfach mit Prozessmanagement gemacht werden. Die vorgebrachten Vorteile reichen dabei von optimierten Abläufen, über signifikanten Einsparungen, Qualitätsverbesserungen und geringere Risiken bis hin zu besser motivierten Mitarbeitern, zufriedeneren Kunden, einer um Klassen verbesserten Unternehmensperformance und vielem mehr. In der Praxis zeigt sich, dass diese umfassenden Erwartungen dann eben nicht oder nur zum Teil eingelöst werden können. Essenziell ist dabei insbesondere auch eine klare Abgrenzung der Definition von Geschäftsprozessen von Unternehmensfunktionen, um in der Folge auch die Effekte beider Konzepte entsprechend auseinanderhalten zu können. Versuchen wir daher herauszuarbeiten, was die Kernelemente eines Geschäftsprozesses in einem echten End-to-End-Verständnis sind. Zum Ersten besteht ein Prozess einmal aus Tätigkeiten oder Aktivitäten, die man als Prozessschritte bezeichnen kann. Ein Angebot zu kalkulieren, einen Kunden zu beraten, ein Produkt zu liefern oder einen Auftrag abzuschließen sind zum Beispiel solche Tätigkeiten oder Aktivitäten. Sie beinhalten bestimmte Handlungen an Objekten, werden durch bestimmte Stellen im Unternehmen durchgeführt und benötigen dafür verschiedene Ressourcen und Inputs. Sind diese aufgezählten Tätigkeiten damit schon ein Prozess? – Definitiv noch nicht. Hierzu braucht es als zweites konstitutives Element eine definierte Abfolge zwischen den Aktivitäten.30 Reden wir zum Beispiel davon, dass zuerst eine Anfrage angenommen, dann der Kunde beraten wird, darauf aufbauend ein Angebot kalkuliert und gelegt wird, das dann mit dem Kunden verhandelt wird und schließlich in einen Kundenauftrag mündet, so kommen wir der Sache schon näher. Die genannten Aktivitäten stehen damit nicht isoliert nebeneinander, sondern sind in zeitlich-logischen Abfolgebeziehungen gereiht und bauen aufeinander auf. Die Form der Abfolgebeziehungen kann dabei jene der rein konsekutiven Folge haben (im Sinne einer Vorgänger-/Nachfolger-Beziehung) oder aber auch einer Parallelität unterschiedlicher Aus30 Vgl. Fischermanns (2006), S. 16: „Aufgaben mit logischen Folgebeziehungen stellen den eigentlichen Kern der Prozessorganisation dar“. Ebenso EABPM (2009), S. 85: „Ein Prozess kann als eine Folge von Aktivitäten bezeichnet werden, die nacheinander oder parallellaufend erledigt werden und zur Erfüllung von Zielen dienen“. Jakob Freund, Bernd Rücker und Thomas Henninger (2010) definieren in ihrem Praxishandbuch BPMN einen Prozess als eine zeitlich-logische Abfolge von Aktivitäten (S. 20). Auch für Nicolai (2009, S. 188) ist die Abfolge ein Kernelement der Prozessdefinition. Klimmer (2007, S. 96) sieht ebenfalls die Ablauffolge als wesentliches Merkmal von Prozessen. Ebenso Staud (2001), S. 9, für den der Begriff des Geschäftsprozesses von der Vorstellung einer sequenziellen Struktur der Abläufe in Unternehmen ausgeht. Hess, Österle (1995, S. 154) sprechen diesbezüglich im Rahmen der Promet-Methode von einer Aufgabenkette, die die zum Erstellen einer Leistung erforderliche Folge von Aufgaben beschreibt.

17


prägung aufweisen im Sinne einer gleichzeitigen, voneinander unabhängige Bearbeitung.31 Hierbei können in weiterer Folge verschiedene Formen der Zusammenführung differenziert werden, je nachdem, ob parallele Prozessschritte aufeinander warten müssen oder nicht,32 aber soweit wollen wir hier gar nicht ins Detail gehen. Wesentlich ist, dass es eine definierte zeitlich-logische Abfolge im Sinne von festgelegten Ablaufbeziehungen zwischen den einzelnen Prozessschritten gibt. Die Teilergebnisse der vorausgehenden Schritte dienen dabei wieder als Ausgangsbasis für weitere, nachfolgende Schritte. Die einzelnen Schritte bauen aufeinander auf, um am Ende etwas zu erreichen. Dieses Etwas ist das dritte konstitutive Element eines Geschäftsprozesses: das Ergebnis, das am Ende der Abfolge von Tätigkeiten entsteht. Dies kann zum Beispiel ein bewilligter Kredit sein, eine neue Frisur, eine gelieferte Ladung Stahlblech oder auch eine erfolgreiche Operation in einem Krankenhaus. Prozesse schaffen also Ergebnisse, die als solche klar feststell- und abgrenzbar sind. Wäre es aber auch ein Geschäftsprozess, wenn ein kleines Kind in seinem Zimmer alle Spielzeuge aus den Laden nimmt und sie mit größter Kreativität in der Mitte des Zimmers zu etwas aufstapelt, was außer ihm selbst niemand wollte und in seiner Kunstfertigkeit vielleicht auch niemand erkennt? Es handelt sich bei dem Stapel unzweifelhaft und unübersehbar um einen Output, entsprechend der eingangs zitierten Definitionen. – Aber handelt es sich deshalb bei dem beschriebenen Geschehen um einen Geschäftsprozess? Nein. So lustig diese Abfolge von Tätigkeiten, die dazu führt, auch ist und so wichtig sie für die Entwicklung des Kindes auch sein mag, für einen Geschäftsprozess fehlt hier das vierte konstitutive Element: Geschäftsprozesse schaffen nicht nur irgendein Ergebnis oder irgendeinen Output aus sich heraus. Sie haben vielmehr einen Außenbezug in dem Sinn, dass an ihrem Beginn ein Bedarf steht, den sie aufgreifen und der durch das Ergebnis am Ende der Abfolge der Tätigkeiten bedient und gedeckt wird.33 Sprich: Es gibt einen Kunden, der den Prozess mit seinem Bedarf erst auslöst und der am Ende des Prozesses Adressat des Ergebnisses ist, das der Prozess erzielt: der erbrachten Leistung.34 End-to-End-Geschäftsprozesse schaf31 Demgegenüber sind ODER-Beziehungen (exklusives ODER bzw. auch UND/ODER) nicht Teil der logischen Folgebeziehung, sondern Mittel zur Darstellung von Varianten, sprich alternativen Abwicklungsformen für ein und dasselbe Ergebnis abhängig von bestimmten Parametern. 32 Vgl. Bogaschewsky, Rollberg (1998), die hierfür den Begriff der Vorrangbeziehungen verwenden. 33 Beim Bedarf handelt es sich um ein originäres Bedürfnis, und nicht unbedingt um das Verlangen nach einem bestimmten Produkt. Siehe dazu Fischermanns (2006, S. 16): Er illustriert dies am Bedarf von Kunden, Daten zu sichern. Dieser Bedarf kann durch verschiedene Produkte und Leistungen gedeckt werden, etwa einen USB-Stick, CD-ROMs, eine externe Festplatte oder eine Sicherungsdienstleistung. 34 Vgl. dazu auch Rudolf Wilhelm (2007), S. 23–24: „Die Folge der Prozesse beginnt beim Kunden und endet bei ihm“; Siehe auch Nicolai (2009, S. 182), für die bei der Strukturierung der Abläufe in der Organisationsarbeit der Blick auf den Vollzug der Leistungserstellung gerichtet wird. Vgl. auch Weske (2007, S. 4), der feststellt, dass Geschäftsprozessmanagement auf der Beobachtung

18


fen damit nicht irgendwelche beliebigen Ergebnisse oder Outputs, sondern Leistungen, die einen Bedarf eines Kunden adressieren. Ihre „Enden“ sind nicht beliebig definierbar, sie sind vielmehr ganz klar festgelegt durch den Bedarf des Kunden und die Deckung dieses Bedarfs durch die vollständig erbrachte Leistung.35 Greifen wir den Gedanken des Stapels von verschiedenen Dingen ohne ersichtlichen Zweck in der Mitte eines Zimmers nochmals auf, denken wir uns jetzt aber anstelle des Kindes einen Künstler. Seine Installation ist vermutlich ähnlich wie die gedachte Kompilation des Kindes für viele nicht unmittelbar verständlich. Sofern er damit allerdings einen Bedarf nach bestimmten modern-abstrakten Kunstgütern bedient und einen Kunden findet, der ihm diese Installation abnimmt und dafür sogar noch einen bestimmten Preis bezahlt, wird die Tätigkeitsfolge seiner Erstellung zum Geschäftsprozess.36 Kurz: Erst der Kunde macht ein Prozessergebnis zum Produkt oder zur Leistung, erst er macht damit die Tätigkeitsfolge zu einem Geschäftsprozess.37 Eine Leistung definiert sich dabei darüber, dass sie für den Empfänger einen Wert hat.38 Typischerweise wird dies dadurch zum Ausdruck gebracht, dass der Kun-

35

36

37

38

fußt, dass jedes Produkt das Ergebnis einer Anzahl durchgeführter Aktivitäten ist. Ebenso Staud (2001, S. 10), der festhält, dass man bei der Betrachtung von Geschäftsprozessen von den Adressaten der im Geschäftsprozess erbrachten Leistungen ausgeht. Für Hess, Osterloh (1995), produziert und konsumiert ein Prozess Leistungen (S. 154). Vgl. auch Hiller, Minar-Hödl, Zahradnik (2010), für die das Ziel eines Prozesses immer in Zusammenhang mit der Befriedigung eines Bedürfnisses eines Prozesskunden steht (S. 22). Vgl. auch Fredmund Malik im Vorwort zu Stöger (2009, S.V): „Konsequentes Prozessmanagement sorgt dafür, dass die Leistung im Zentrum steht“. Ledolter (2010, S. 327): „Produkte und Leistungen sind Resultate von Prozessen.“ Auch für Schmelzer, Sesselmann (2010) erzeugen Geschäftsprozesse von Kunden erwartete Leistungen (S. 63). Vgl. dazu auch Schmelzer, Sesselmann (2010): Auch sie definieren an einer Stelle Geschäftsprozesse nicht als reine Input-Output-Transformation, sondern ebenso wie hier über die Anforderung des Kunden und die Leistungserbringung an den Kunden (S. 64), in weiten Teilen des Buches gehen sie jedoch wieder auf die übliche Teilprozesssicht zurück (siehe z. B. S. 68, S. 79 oder S. 130). Auch ihr Geschäftsprozessmodell für Industrieunternehmen (GMI) basiert nur auf einer Teilprozesssicht und nicht auf echten End-to-End-Prozessen (S. 210–211). Für Speck, Schnetgöke (2008) ist für jeden Prozess ein Kunde festzulegen, gegebenenfalls ein interner (S. 205). Vgl. Fischermanns (2006, S. 15). Für ihn muss ein Prozess definitionsgemäß wertschöpfend sein in dem Sinn, dass er einen Nutzen für den Kunden bringt. Der Prozess führt damit zum Entstehen einer Leistung, für die der Kunde bereit ist, Geld zu zahlen. Vgl. dazu auch EABPM (2009): „Geschäftsprozesse legen fest, wie Unternehmen ihre Leistungen für die Kunden erbringen“ (S. 29). Ebenso Gaitanides (2007): Für ihn schließt die Prozessdefinition annahmegemäß Prozessergebnisse aus, für die kein expliziter Kunde existiert (S. 240). Rummler, Remias, Rummler (2010) gehen über diese Konzeption noch hinaus und sehen neben der Leistung für den Kunden auch noch eine zweite für die Investoren oder Eigentümer (financial stakeholders) – aufbauend auf dieser dualen Sicht der Leistungserbringung kommt der richtigen Balance zwischen beiden Kunden eine entscheidende Bedeutung für den langfristigen Erfolg zu (S. 24). Vgl. Rummler, Remias, Rummler (2010): Sie sehen Unternehmen als „value creating machines“, zu deren Steuerung zum einen das End-to-End-Value-Creation-System und zum anderen die Ressourcen gemanagt werden müssen (S. 27–28). Was Rummler, Remias, Rummler als Value-CreationSystem bezeichnen entspricht im Wesentlichen dem hier vorgestellten Ansatz der End-to-EndGeschäftsprozesse und der integrativen Process Map.

19


de bereit ist, für die empfangene Leistung einen entsprechenden Preis zu bezahlen. Das heißt nicht, dass dies in der Realität immer tatsächlich der Fall sein muss. Im Prinzip sollte jedoch beim Empfänger der Leistung, dem Kunden, die Bereitschaft gegeben sein, dafür auch zu bezahlen. Ist diese Bereitschaft nicht gegeben, so hat sie für ihn auch keinen Wert – folglich handelt es sich auch nicht um eine Leistung im betriebswirtschaftlichen Sinn. Der auslösende Bedarf, der den Ausgangspunkt des Prozesses markiert, darf dabei nicht mit den Inputs verwechselt werden, die für einen Geschäftsprozess notwendig sind.39 Der Bedarf ist der Grund, warum der Prozess überhaupt ausgeführt wird und als solcher besteht. Inputs sind hingegen alle Informationen und Materialien, die im Zuge des Prozesses von anderen Prozessen benötigt werden, um den betreffenden Geschäftsprozess durchführen und die gewünschte Leistung am Ende herstellen zu können. Diese Inputs müssen dabei nicht zwingend nur am Prozessbeginn bereitstehen. Vielmehr können Inputs an ganz unterschiedlichen Prozessschritten im Zuge des Prozessverlaufes notwendig sein und verarbeitet werden. So ist natürlich die Beschreibung des Kundenbedarfs ein wesentlicher Input. Ebenso sind aber auch Verfügbarkeiten von Lieferanten oder Plandaten von für die Zustellung genutzten Logistikfirmen Inputs, die für den Prozess wichtig sind. Oder etwa Wetterdaten für die Durchführung von geführten Bergtouren oder Benzinpreise entlang einer Transportroute für die Kalkulation eines auftragsindividuellen Preises für einen Warentransport quer durch Europa. In gleicher Weise ist der auslösende Bedarf vom Ereignis zu unterscheiden, das den Geschäftsprozess auslöst. Vielfach wird dieses auslösende Ereignis als Teil der Prozessdefinition gesehen; und natürlich hat auch jeder Prozess in irgendeiner Form ein solches Startereignis. Das Wesentliche im Sinne der Kernelemente eines Prozesses ist jedoch nicht dieses Startereignis, sondern vielmehr der Bedarf, der zu ihm führt. Der Bedarf ist wie oben beschrieben der Grund, warum der Prozess überhaupt ausgeführt wird und als solcher besteht. Er ist somit eine vorausgehende Bedingung. Der Prozessauslöser ist hingegen ein bestimmtes Ereignis, das diesen Bedarf dem jeweiligen Erbringer der Leistung bekannt macht. Bei diesem Ereignis kann es sich etwa um den Eingang einer Anfrage, einer Bestellung oder einer Beschwerde über Fax, Brief, E-Mail, Telefon oder Internet handeln; ebenso um das Betreten eines Geschäfts, die Einlieferung in ein Spital oder das Schalten eines Inserats. Durch die Bekanntmachung des Bedarfs in diesem Ereignis stößt dieses den entsprechenden Geschäftsprozess an bzw. löst diesen aus. Für die methodisch sauberer Modellierung von Prozessen ist daher das Startereignis als Auslöser wichtig; für das Grundverständnis von End-toEnd-Prozessen ist jedoch der vorausgehende Bedarf das Entscheidende.

39 So z. B. bei Wilhelm Rudolf (2007, S. 27) und Fischermanns (2006, S. 13 f.), die beide Input und Auslöser gleichsetzen.

20


Konzeptionell ist daher zwischen dem vorausgehenden Bedarf selbst, dem Ereignis, das den Bedarf bekannt macht und damit den Prozess auslöst, sowie den verschiedenen notwendigen Inputs zu unterscheiden.40 Nur der Bedarf ist ein konstitutives Element für einen Geschäftsprozess. Auslösendes Ereignis und Inputs sind hingegen Detailelemente, denen in weiterer Folge beim operativen Arbeiten mit Prozessen und bei ihrer Verbesserung Bedeutung zukommt – das wesentliche ist jedoch der Bedarf. Konzentriert man sich bei der Definition und Identifikation von Geschäftsprozessen zu stark auf Startereignisse und Inputs, so besteht die Gefahr, sehr rasch in den operativen Prozessdetails abzutauchen, ohne dass das grundsätzliche Prozessverständnis richtig angewendet wird. Damit geht der für das Prozessdenken so wichtige Kundenbezug bereits am Beginn ein Stück weit verloren, ohne die dahinter liegenden Auftraggeber-/Auftragnehmerverhältnisse vollständig erfasst zu haben, während operative und methodische Details in den Vordergrund rücken. In analoger Weise ist das Prozessergebnis, die durch den Geschäftsprozess erbrachte Leistung, nicht mit den Outputs eines Prozesses gleichzusetzen. Die Leistung im Sinne des Prozessergebnisses ist das, was der Kunde als Bedarfsträger wollte und am Ende zur Deckung seines Bedarfs erhält. Output eines Prozesses sind hingegen alle Artefakte, die von einem Geschäftsprozess im Rahmen der Durchführung entstehen und erstellt werden. So sind Outputs etwa auch verschiedene Informationen und Elemente, die zur Durchführung und zum Abschluss des Geschäftsfalls erforderlich sind. Hierzu zählt natürlich auch das Prozessergebnis im Sinne der erbrachten Leistung. Hierzu zählen aber etwa auch der im Archiv abgelegte Kundenauftrag, das Feedback aus der Kundenrückmeldung für die Entwicklungsabteilung, das dem Kunden separat zugestellte Produktsicherheitsblatt bei der Lieferung gefährlicher Güter, der Plan für die kundenindividuelle Fräsmaschine, die Bedienungsanleitung für den Flatscreen-TV oder die Lieferpapiere.41 Ebenso zählt zu den Outputs die Dokumentation des Geschäftsfalls für die gesetzlich vorgeschriebenen Fristen, auf Basis derer Prüfer zu einem späteren Zeitpunkt die Geschäftstätigkeit des Unternehmens auf die Einhaltung bestimmter Normen überprüfen. Und dazu zählen schließlich auch Abfälle und Beeinträchtigungen der Umwelt, die ein Geschäftsprozess hinterlässt. Archive, ob elektronisch oder noch in Papierform, und Müllhalden sind gefüllt mit Outputs – die erbrachte Leistung oder das gelieferte Produkt sind jedoch beim Kunden. Wie schon im Zusammenhang mit den Inputs erwähnt, gilt daher auch hier, dass nur die erbrachte Leistung ein konstitutives Element von Geschäftsprozessen ist. Andere Outputs sind wiederum operative Elemente, die erst für die detaillierte Analyse und Verbesserung der Prozesse in den Fokus rücken. Ein zu großer Fokus auf sie bereits in der Definition und Identifikation von Geschäftsprozessen riskiert wiederum, zu schnell in 40 Vgl. dazu z. B. Wagner, Patzak (2007, S. 79), die auch zwischen Input und Auslöser unterscheiden. 41 Wagner, Patzak (2007) unterscheiden dafür zwischen Output und Outcome eines Prozesses (S. 79). Zahlreiche aktuell etablierte Methoden wie z. B. der SIPOC-Ansatz scheinen diese Trennung nicht vorzunehmen.

21


Abb. 2: Definition Geschäftsprozess (1)

operative und methodische Prozessdetails einzutauchen und dabei den Blick für ein richtiges End-to-End-Prozessverständnis und die damit verbundenen Leistungsbeziehungen zu verlieren. Leider hat es sich im traditionellen Prozessverständnis etabliert, Prozesse wissend über Input- und Outputbeziehungen zu definieren. Im Sinn eines echten End-to-End-Verständnisses von Geschäftsprozessen wollen wir diese technischen Termini durch den vorausgehenden Bedarf und die erbrachte Leistung als Prozessergebnis ersetzen. Fassen wir das bisher Gesagte zusammen: Ein Geschäftsprozess ist die Abfolge von Tätigkeiten zur Erstellung eines Ergebnisses, das einen Bedarf adressiert, sodass die Empfänger, von denen dieser Bedarf ausgeht, zumindest theoretisch bereit sind, dafür einen Preis zu zahlen. Ein Geschäftsprozess ist damit die Abfolge von Tätigkeiten zur Erstellung eines Produkts oder einer Leistung für einen Kunden. Ist damit ein Prozess ausreichend definiert? – Denken wir uns ein Beispiel: Ein Kunde kommt in ein Möbelhaus, ein Vertriebsmitarbeiter spricht ihn an, greift seine Anfrage nach einem passenden Sofa auf, zeigt ihm verschiedene Modelle, macht ihm ein gutes Angebot und kann ihn zu einem Kaufabschluss überreden. Am Ende liegt ein unterschriebener Kaufvertrag auf dem Beratungstisch des Verkäufers, und auch der Kunde ist zufrieden (siehe Abb. 2). Handelt es sich dabei um einen Geschäftsprozess? – Nun, wir haben Tätigkeiten, eine klar sichtbare wenn auch sehr einfache Abfolge und auch ein klar sichtbares Ergebnis: den Kaufvertrag. Aber ist der Kunde bereit, für den Kaufvertrag zu bezahlen? – Wohl kaum, er bezahlt vielmehr für das Sofa, der Kaufvertrag selbst ist ein notwendiger Zwischenschritt, für ihn allein genommen würde aber kein Kunde auch nur einen Cent bezahlen. Deckt der Kaufvertrag als Prozessergebnis den Bedarf des Kunden? Auch nicht. Der Bedarf wäre natürlich erst durch das Sofa selbst gedeckt. Im Sinne der traditionellen Input-Output-Transformation läge hier bereits ein Prozess vor – im Sinne eines klaren End-to-End-Prozessverständnisses mit den Eckpunkten Bedarf und erbrachte Leistung jedoch nicht. Geschäftsprozesse können also nicht beliebig geschnitten werden. Sie müssen am einen Ende beim Bedarf des Kunden starten und am anderen auch bis zur Deckung dieses Bedarfs gehen. Tun sie dies nicht, sondern bilden nur einen Teil davon ab, handelt es sich nicht um komplette End-to-End-Geschäftsprozesse, sondern nur um Teilprozesse.

22



Um dies zu betonen und komplette Geschäftsprozesse von reinen Teilprozessen abzuheben, wird hierfür von einem End-to-End-Geschäftsprozess oder einer Endto-End-Perspektive gesprochen. Diese Bezeichnung alleine ist jedoch noch nicht ausreichend. Denn die Bezeichnung durch zwei Enden wäre ja nur ein rein formales Kriterium. Jeder Prozess, egal wie er geschnitten ist, hat rein formal gesehen immer irgendwo einen Beginn und irgendwo ein Ende, ist somit per Definition schon endto-end.42 Insofern ist der Begriff end-to-end auch gefährlich, weil er automatisch eine vollständige und integrierte Sichtweise suggeriert, die aber in seiner praktischen Anwendung oft nicht gegeben ist. Entscheidend ist ja nicht so sehr das Ende an sich, sondern was am Anfang und am Ende steht: Für einen End-to-End-Geschäftsprozess muss am Anfang ein entsprechender Kundenbedarf und am Ende eine Leistung stehen, die diesen Bedarf deckt.43 Die reine Bezeichnung als End-to-End-Prozess reicht hierfür nicht aus. Entscheidend ist also die Art, wie Anfang und Ende tatsächlich definiert werden. Erst mit diesem Verständnis der „Enden“ durch Bedarf und Leistung zur Deckung dieses Bedarfs bringt dieser Begriff einen echten Mehrwert; erst damit wird ein Geschäftsprozess zu einem echten End-to-End-Prozess. Erweitern wir also das Beispiel etwas und fragen wir den Verkäufer, was nachher passiert: Nach Abschluss des Kaufvertrags dauert es ein paar Wochen, bis das Sofa geliefert wird. Sobald es da ist, verständigt er den Kunden per SMS, dieser kommt, zahlt den Restbetrag und holt das Sofa in der Warenausgabe ab. Wir erweitern also den Prozess entsprechend (siehe Abb. 3). Der Kunde hat nun sein Sofa, sein Bedarf ist gedeckt. Ist damit der Geschäftsprozess nun komplett? – Nein, immer noch nicht, denn der Ablauf wurde nur aus Sicht des Verkäufers beschrieben. Da er nur jene Prozessschritte aufzählte, bei denen er in42 Vgl. dazu die beiden eingangs angeführten Definitionen von Thomas Davenport und von Jetta Frost, Margit Osterloh, die das Vorhandensein eines Anfangs und eines Endes in ihren Definitionen enthalten ohne jedoch genau festzulegen, worin dieser Anfang und das Ende genau bestehen. 43 Vgl. EABPM (2009), S. 38.

23



volviert ist, erhalten wir so nur einen Teil des Gesamtprozesses aus seiner Abteilungssicht. Mit diesem Teil alleine könnte aber die entsprechende Leistung an den Kunden – das Sofa – nicht erbracht werden. Vielmehr passieren zwischen dem Abschluss des Kaufvertrags und der Abholung noch eine Reihe von weiteren Schritten: z. B. die Bestellung beim Lieferanten, die Entgegennahme des Sofas und dessen Einlagerung im Auslieferungslager (siehe Abb. 4). Diese waren dem Verkäufer jedoch nicht unmittelbar bewusst, als wir ihn nach dem Prozess gefragt haben, da er diese Prozessschritte nicht ausführt, sondern sie durch andere Abteilungen und Teams erledigt werden. Ein Prozess umfasst also nicht nur irgendwelche Tätigkeiten zur Erstellung eines Produkts oder einer Leistung, sondern alle, die notwendig sind, um die Leistung zu erbringen, mit der der Ausgangsbedarf gedeckt wird.44 Der Geschäftsprozess folgt damit nicht der Sicht einer bestimmten Abteilung oder eines Bereichs im Unternehmen, sondern er folgt der Sicht des Geschäftsfalles. Der Geschäftsfall des Kunden ist dabei die einzelne Instanz, die den Prozess durchläuft. Je nach Organisation kann es sich dabei um einen Auftrag, einen Antrag oder Akt oder auch um den Kunden selbst handeln, der in einer bestimmten Weise serviciert wird, z. B. als Kunde in einem Friseurladen oder als Patient in einem Krankenhaus. Wichtig sind damit alle Prozessschritte für die Erbringung der betreffenden Leistung. Würde das Sofa vom betreffenden Un44 Vgl. auch Smith, Fingar (2007), S. 47: Sie führen in ihrer Prozessdefinition explizit an, dass ein Geschäftsprozess alle notwendigen Aktivitäten umfasst („A business process is the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers.“) (Hervorhebung durch den Autor). Dies ist etwa ein wesentlicher Unterschied zur Prozessdefinition auf Basis des Konzepts der Kernprozesse, wie sie von Osterloh, Frost (2000) propagiert wird. Für sie sollen Supportprozesse als eigenständige Module von den Kernprozessen abgespalten werden, um damit die Komplexität der Kernprozesse überschaubarer zu machen und die Supportprozesse so benchmarkfähig zu machen (S. 35). Dies steht jedoch in Widerspruch zu ihrer Forderung, dass Kernprozesse eine Durchgängigkeit von den Schnittstellen mit den Lieferanten (sic!) bis zu den Schnittstellen mit den Kunden aufweisen sollen (Ebenda S. 37). Vgl. auch Österle (2010/1995): Er empfiehlt, dass sich Unternehmen von Anfang an auf jene Prozesse konzentrieren, die wettbewerbsentscheidend sind (S. 24).

24


ternehmen selbst erzeugt, so würden wir hier in der Kette einen entsprechenden Teilprozess der Fertigung vorfinden. Da wir annehmen, dass es sich nur um ein Handelshaus handelt, das die Produkte selbst bei den Produzenten auftragsbezogen zukauft, ist diese Teilleistung ausgelagert – es verbleibt jedoch der entsprechende Bestellprozess und die Übernahme und Prüfung des Sofas vom Produzenten. Wie wir später noch zeigen werden, kann aber auch der zu einem Lieferanten ausgelagerte Teilprozess der Produktion in die Darstellung aufgenommen werden, wenn es sich dabei um eine kritische Schnittstelle handelt und dies daher sinnvoll erscheint. Die End-to-End-Prozesssicht unterscheidet sich damit radikal von der vielfach etablierten Teilprozesssicht. Wie weiter oben gezeigt wurde, beinhalten viele der bekannten Prozessdefinitionen bereits eine End-to-End-Sicht oder zumindest Teile davon bzw. Ansätze dafür. Diese waren jedoch nicht klar und nicht zwingend genug. In der Praxis wurden Geschäftsprozesse daher fast ausschließlich so definiert, dass sie nur die Schritte innerhalb bestimmter Bereiche oder Funktionen abdecken. So finden wir in den Unternehmen heute Vertriebsprozesse, Einkaufsprozesse, Buchhaltungsprozesse und so weiter.45 Was fehlt, ist jedoch eine Verknüpfung all dieser Prozesse zum Gesamtbild der Leistungserstellung für den Kunden. Bestehende Prozessmodelle verkörpern zum Großteil nur eine Teilprozesssicht. Das damit etablierte Prozessdenken entspricht daher meist nur einer Ablaufsicht innerhalb der bekannten abgegrenzten Bereiche und Funktionen. Erst mit der Ausdehnung der Prozesssicht auf eine echte End-to-End-Perspektive rückt der Kunde mit seinem Bedarf und der finalen Leistung als Ergebnis des Prozesses in den Mittelpunkt der Prozesse. Erst mit diesem End-to-End-Verständnis von Geschäftsprozessen entsteht ein Bild der gesamten Leistungserstellung für die Kunden und des dafür notwendigen Leistungsaustausches der einzelnen Teilprozesse.46 Anders als im etablierten Teilprozessverständnis stellt sich bei einer so definierten End-to-End-Prozesssicht die von manchen Vertretern diskutierte Frage der Prozesswürdigkeit47 nicht. Sie beantwortet sich vielmehr aus der Frage nach den wesentlichen 45 Vgl. dazu auch Spanyi (2007), S. 30–31. Ebenso Rummler, Remias, Rummler (2010): Auch sie halten fest, dass heute viele Manager und Mitarbeiter mit dem Prozessbegriff vertraut sind und über „ihre Prozesse“ reden, ohne jedoch deren Verbindung in den größeren Zusammenhang zu sehen. „[. . .] they are fundamentally grounded in their own discipline or functional ara (Engieering, Sales, Manufacturing, Customer Service, Product Development, Finance, HR, and so on) and tend not to look beyond their department boundaries“ (S. 23). 46 Vgl. dazu Spanyi (2007, S. 13), der in diesem Zusammenhang von einem Schaubild (schematic) spricht, das den Fluss der großen, cross-funktionalen Aktivitäten definiert, die für den Kunden Wert generieren. Ebenso Rummler, Remias, Rummler (2010), S. 75. 47 Vgl. z. B. Hiller, Minar-Hödl, Zahradnik (2010), S. 22–23. Sie unterscheiden zwischen Prozessen, die im Rahmen des Prozessmanagements gestaltet und gesteuert werden, und Abläufen, für die dies mangels Prozesswürdigkeit nicht der Fall ist. Als Kriterien für die Prozesswürdigkeit führen sie dabei die organisatorische Komplexität im Sinne der Anzahl von Schnittstellen, eine hohe strategische Bedeutung im Sinne der Sichtbarkeit für den Kunden sowie ein hohes Risikopotenzial und daraus folgende Anforderungen über die Nachvollziehbarkeit an. Ähnlich Wagner, Patzak (2007), die

25


Leistungen des Unternehmens und den für die Erstellung dieser Leistungen notwendigen Teilschritten. Sind diese Leistungen festgelegt, so liegen damit auch die zu definierenden End-to-End-Prozesse vor. Bei der Detaillierung der End-to-End-Prozesse wiederum müssen alle notwendigen Teilprozesse, die für die Leistungserstellung erforderlich sind, transparent gemacht werden. Ein Weglassen von Prozessen widerspricht dem End-to-End-Gedanken – die Kette der Schritte zur Leistungserstellung wäre dann nicht komplett. Ist ein Teilprozess noch so klein, ohne wesentliche Schnittstellen und mit nur geringen Ressourcen – wenn er für die Erstellung der Leistung notwendig ist, kann er nicht weggelassen werden. Denken wir als Beispiel etwa an die Typisierung von Autos oder an die Abnahme von Bauwerken: Beide Teilprozesse sind im Vergleich zu den anderen Teilprozessen der Leistungserstellung Herstellung eines Autos bzw. eines Bauwerks sehr gering, verfügen kaum über große Schnittstellen und sind ohne strategische Relevanz. Für die Leistungserstellung für den Kunden sind sie jedoch essenziell, da ohne diese Teilprozesse die Leistung – hier Auto, da Bauwerk – nicht genutzt werden kann. Die Frage der Prozesswürdigkeit stellt sich damit nur im Hinblick auf die Festlegung der wesentlichen Leistungen, die ein Unternehmen erbringt. Nebensächliche, für die Geschäftstätigkeit des Unternehmens nicht wichtige Leistungen und Produkte können hier im Sinne der Komplexitätsreduktion gegebenenfalls weggelassen werden.48 Man denke etwa an ein Unternehmen, bei dem in der Produktion seiner richtigen Produkte als Abfallprodukt Wärme entsteht, die den benachbarten Firmen als Fernwärme zum Heizen verkauft wird. Oder an einen Dienstleistungsbetrieb, der seine für das Kerngeschäft benötigten Veranstaltungsräume nebenbei auch gelegentlich an andere Firmen oder Vereine vermietet, wenn er sie nicht selbst braucht. Beide Beispiele beschreiben keine Leistungen, die dem Ziel der Unternehmen entsprechen, sondern Nebenleistungen, bei denen etwas, was quasi nebenbei entsteht, in opportunistischer Weise auch verwertet und genutzt wird, ohne dies jedoch zum Geschäftsfeld zu machen. Derartige Leistungen können im Sinne der Konzentration auf das Wesentliche gegebenenfalls auch weggelassen werden, da sie für das Verständnis des Geschäftsmodells eines Unternehmens nicht wesentlich sind. Auf der Ebene der Teilprozesse für die definierten Leistungen stellt sich die Frage der Prozesswürdigkeit jedoch in einem End-to-End-Verständnis nicht. Ist eine Leistung als End-to-End-Prozess abzubilden, so müssen alle notwendigen Teilprozesse erfasst und transparent gemacht werden. Denn für den Prozesskunden macht dies keinen Unterschied. Seine Leistung entsteht nur durch das Zusammenspiel aller Teilproebenfalls die Prozesswürdigkeit als Kriterium für die Aufnahme eines Prozesses in das Prozessmanagementsystem definieren, hier mit den Kriterien der Ressourcenbindung, Anzahl der Schnittstellen, strategischen Relevanz, fach- und organisationsübergreifendem Zusammenarbeiten und Risikopotenzial (S. 81–83). 48 Hiller, Minar-Hödl, Zahradnik (2010) sprechen in diesem Zusammenhang von der Anwendung des Paretoprinzips (80/20-Regel) bei der Erstellung von Prozesslandkarten (S. 87).

26


zesse. Dies bedeutet jedoch nicht, dass alle Teilprozesse in weiterer Folge in gleicher Weise weiter detailliert, analysiert, optimiert oder gesteuert werden müssen. Ganz im Gegenteil: Wie wir später herausarbeiten werden, ist es für ein echtes Verständnis von Prozessmanagement als Managementansatz sogar essenziell, dass nicht alle Prozesse in gleicher Weise und Detaillierung bearbeitet werden. Für welche Prozesse dies erforderlich ist und für welche nicht, ist jedoch eine Entscheidung, die später im Rahmen des Managens der Prozesse zu treffen ist und die sich im Lauf der Zeit auch ändern kann. Genau daher ist es essenziell, am Beginn ein vollständiges Bild aller für die Leistungserstellung notwendigen Teilprozesse zu haben. Nur so ist eine spätere Auswahl, welche Prozesse oder Teile davon gemanagt werden sollen und welche nicht, möglich. Ebenso widerspricht es auch dem End-to-End-Prozessverständnis, wenn die Prozesse aus der Strategie des Unternehmens derart abgeleitet werden, dass nur die strategisch wichtigen Geschäftsprozesse oder jene, in denen das Unternehmen Kernkompetenzen hat, als Prozesse definiert werden.49 Auch bei dieser, aus dem strategischen Management kommenden Vorgehensweise würde nicht die gesamte Leistungserstellung vom einen Ende bis zum anderen Ende transparent. Für eine strategische Neuausrichtung eines Unternehmens mag dieses Vorgehen als Element der Strategieumsetzung daher sehr sinnvoll sein. Für den Zweck des Prozessmanagements ist sie es jedoch nicht – hierfür benötigen wir die komplette Kette aller Teilprozesse zur Leistungserstellung vom Kunden zum Kunden. Die Unterscheidung in jene Geschäftsprozesse, die strategisch wichtig sind, in jene, in denen das betreffende Unternehmen spezielle Kernkompetenzen hat, und in alle übrigen Prozesse, für die dies nicht zutrifft, ist natürlich eine wichtige Analysekategorie in vielerlei Hinsicht. Sie dient jedoch dem gezielten Managen der Prozesse und nicht schon als Kriterium für Ihre Definition, sonst entsteht von Beginn an kein komplettes Prozessbild.50 Wir werden später bei der Analyse von Geschäftsprozessen darauf zurückkommen. Für eine echte End-to-End-Prozesssicht müssen alle für die Erstellung einer Leistung notwendigen Teilprozesse erfasst werden. Wenn man darüber nachdenkt, welche Tätigkeiten für eine Leistungserstellung nun notwendig sind, besteht die Gefahr, dass man dabei auf administrative Teilprozesse vergisst, die zwar vielleicht dem Kunden keinen unmittelbar sichtbaren Nutzen bringen, die aber für die komplette Abwicklung des Geschäftsfalls dennoch notwendig sind. Denken wir etwa an die Verbuchung 49 Siehe dazu z. B. Österle (2010/1995), dessen Konzept der Process Architecture nur wenige wettbewerbsentscheidende Prozesse enthält (S. 61–62); Im Rahmen des Architecture Planning werde dabei Prozesskandidaten ausgewählt, aus denen dann auf Basis der strategischen Relevanz, der Bedeutung für Kernkompetenzen, des erwarteten Potenzials, der Standardisierbarkeit, der Kundenbedarfe, der Verfügbarkeit von Prozessindikatoren, der Verfügbarkeit von Prozessmanagern und der Steuerbarkeit des Prozesskandidaten die wesentlichen Prozesse für die Prozessarchitektur ausgewählt werden (S. 128–139). Zum Konzept der Kernkompetenzen siehe z. B. Becker, Meise (2008), S. 116–119. 50 Vgl. Davenport (1993, S. 27): “An informed selection can be made only when all of the organization’s processes are known.”

27



der Eingangsrechnung vom Lieferanten des Sofas, die im Falle einer auftragsbezogenen Bestellung direkt mit dem entsprechenden Geschäftsfall verbunden ist. Oder denken wir an die Verbuchung des Verkaufs in der Debitorenbuchhaltung, die ebenfalls direkt dem entsprechenden Geschäftsfall zuzuordnen ist, ebenso die kostenrechnerische und steuerliche Verbuchung dieses Geschäftsfalls oder die spätere Ablage der Originaldokumente des Geschäftsfalls in einem Archiv (siehe Abb. 5). Bei Geschäftsmodellen, wo der Kunde anders als in unserem Beispiel nicht gleich bei der Übernahme des Produkts bezahlt, können hierunter auch noch Prozessschritte zur Fakturierung der erbrachten Leistung, zur Nachverfolgung des Zahlungseingangs bis hin zu einer eventuellen Mahnung gehören, oder im Falle einer Vorauszahlung die Verbuchung dieser Anzahlung.51 Abgeschlossen ist der Geschäftsfall erst, wenn alle mit ihm direkt in Verbindung stehenden Aktivitäten durchgeführt sind und er in der elektronischen oder physischen Ablage abgelegt ist. Dazu zählen auch alle geschäftsfallbezogenen Aktivitäten der Abwicklung in der Buchhaltung, der Kostenrechnung, alle direkt mit dem Geschäftsfall verbundenen Beschaffungsvorgänge (geschäftsfallbezogene Beschaffung) samt der damit verbundenen buchhalterischen und kostenrechnerischen Verbuchung dieser Vorgänge, sprich alles, was direkt dem Geschäftsfall zuordenbar ist. Erst damit ist der End-to-End-Geschäftsprozess komplett.52 51 Vgl. dazu auch Hammer (1997, S. 25): Für ihn beschränkt sich der Auftragsabwicklungsprozess nicht nur auf die reine Bereitstellung der gelagerten Waren und ihre Auslieferung, sondern umfasst auch die Fakturierung, das Forderungsmanagement und das Inkasso. 52 Vgl. dazu auch Howard Smith und Peter Fingar, die in ihrer Definition von Geschäftsprozess auch die Vollständigkeit der Aktivitäten für die Leistungserstellung betonen: Für sie ist ein Geschäftsprozess „the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to the customer“ [Hervorhebung Stefan Bergsmann], zit. nach Siegel (2008), S. 2. Den weiteren Charakteristika von Prozessen, welche die Autoren definieren – groß und komplex, dynamisch, stark verteilt, und über Grenzen verlaufend, lang-laufend, automatisiert etc. – wird hier jedoch nicht zugestimmt. Es handelt sich dabei um mögliche Kategorisierungen von Prozessen anhand verschiedener Eigenschaften, nicht jedoch um konstitutive Elemente des Prozesskonzepts.

28


Als letztem Element wird dies noch ergänzt um die Zuordnung der Ressourcen, die für die Ausführung der einzelnen Teilprozesse und Prozessschritte notwendig sind. Dazu zählen naturgemäß die Personalressourcen, also die Abteilungen, Stellen und Rollen aus der Aufbauorganisation, welche die einzelnen Teilprozesse und Prozessschritte ausführen. Ebenso zählen dazu auch alle anderen Ressourcen, wie etwa Maschinen, spezielle Werkzeuge, IT-Systeme etc., die für die Ausführung der Schritte in der Leistungserstellung notwendig sind. Ohne sie wären die Prozesse nicht ausführbar. Daher sind auch sie ein wesentliches Element der Prozesse und stellen die Schnittstelle der Ablauforganisation zur Aufbauorganisation dar. Das heißt nicht, dass diese auch auf den oberen Aggregationsebenen immer explizit dargestellt werden müssen. Vielfach ist es aus Komplexitätsgründen sinnvoll, die zugeordneten Ressourcen erst auf den detaillierteren Ebenen des Prozessmodells auszuweisen. Fassen wir also alle Aspekte nochmals zusammen, so können wir einen End-toEnd-Geschäftsprozess definieren als die Abfolge aller notwendigen und direkt mit dem Geschäftsfall verbundenen Tätigkeiten zur Erstellung einer Leistung für einen Kunden, mit der bei diesem ein vorausgehender Bedarf gedeckt wird und die daher für diesen von Wert ist, samt der Zuordnung der dafür notwendigen Ressourcen.53 Konstitutive Elemente dieser End-to-End-Definition von Geschäftsprozessen sind damit: ·

Der vorausgehende Bedarf des Kunden am Anfang, der den Prozess über ein Ereignis auslöst 53 Eine ähnliche, aber im Detail doch weniger genaue Prozessdefinition findet sich z. B. bei Fischermanns (2006), S. 12–13. Auch er sieht einen Prozess bestehend aus Aufgaben, streicht die Wichtigkeit der Folgebeziehungen hervor und sieht Prozesse durch ein Startereignis und ein Ergebnis, das einen Wert für den Kunden schafft, begrenzt. Fischermanns Definition sieht Folgebeziehungen jedoch zwischen Aufgaben, Aufgabenträgern, Sachmitteln und Informationen und integriert auch die Konkretisierung der zeitlichen, räumlichen und mengenmäßigen Dimensionen als Teil der Prozessdefinition. Im Gegensatz dazu sieht die hier entwickelte Definition die Folgebeziehungen nur zwischen den Tätigkeiten (Prozessschritten). Aufgabenträger und Sachmittel werden nur über die Zuordnung dieser Ressourcen in die Definition eingebunden. Informationen werden als ergänzende Inputs zu einem Prozess gesehen, nicht jedoch als dessen konstitutive Elemente. Dasselbe gilt für die räumlichen und mengenmäßigen Dimensionen – auch sie werden hier als Prozesseigenschaften, nicht jedoch als Elemente der Definition gesehen. Darüber hinaus wird der Ausgangspunkt des Prozesses (Fischermanns Ereignis oder Input) klar als Bedarf gedacht, der mit dem Prozessergebnis im Sinne der durch die Tätigkeitsfolge erbrachten Leistung gedeckt wird. Inputs sind davon – wie beschrieben – getrennt zu sehen. Insofern unterscheiden sich die hier entwickelten konstitutiven Elemente eines Prozesses bei genauerer Betrachtung doch merklich von jenen Fischermanns. Vgl. dazu auch Knuppertz (2009), der sein Prozessmanagement-Buch auch mit den Fragen nach den Kundenanforderungen, den erbrachten Produkten und Leistungen sowie der Art, wie diese erstellt werden, beginnt (S. 31) und damit ein ganz ähnliches Prozessverständnis zugrunde legt, ohne es jedoch in einer vergleichbaren Definition auszuformulieren.

29


·

Die Leistung als Ergebnis des Prozesses für den Kunden, das den Bedarf deckt und damit für diesen einen Wert hat Die Tätigkeiten oder Prozessschritte zur Erstellung der Leistung Die Vollständigkeit aller direkt mit der Abwicklung des Geschäftsfalls verbundenen Tätigkeiten Die Abfolgebeziehungen zwischen diesen Schritten Die Zuordnung der für die Teilprozesse und Prozessschritte notwendigen Ressourcen

· · · ·

Es sind diese Elemente, die einen echten End-to-End-Geschäftsprozess ausmachen54 und auf denen alle weiteren Überlegungen über ein Management echter End-to-EndProzesse aufbauen. 2.2.2 Geschäftsprozesssicht und Kundenorientierung

Durch diese End-to-End-Definition von Geschäftsprozessen über die beiden Eckpunkte Bedarf und Bedarfsdeckung durch die erbrachte Leistung ist die Prozessperspektive noch viel stärker am Kunden ausgerichtet als im traditionellen Prozessverständnis und natürlich auch viel mehr als andere Sichtweisen auf das Unternehmen, wie etwa die funktionale oder aufbauorganisatorische Sicht. Sie beinhaltet damit eine viel stärkere Kundenorientierung: ·

Mit dem auslösenden Bedarf hat der End-to-End-Geschäftsprozess seinen Ausgangspunkt direkt beim Kunden Der Geschäftsfall repräsentiert das Anliegen des Kunden, das vom Unternehmen bearbeitet wird Das Prozessergebnis am Ende des Prozesses ist die Leistung, die den Bedarf des Kunden deckt und daher für ihn einen Wert hat

· ·

54 Hiller, Minar-Hödl, Zahradnik (2010), S. 22–23 führen als konstitutives Element von Prozessen ergänzend auch das Faktum an, dass Prozesse Regeltätigkeiten beschreiben, die nicht nur einmalig passieren, sondern wiederholt durchgeführt werden. Dies sei auch das wesentliche Kriterium zur Unterscheidung von Prozessen und Projekten. Während letztere einen einmaligen Charakter haben, beschreiben erstere ihrer Meinung nach etwas Wiederkehrendes. Dieser Ansicht wird hier nicht gefolgt, da auch Projekte bei genauerer Betrachtung nicht völlig einmalig sind. Wären sie es, so wäre eine Festlegung von Projektstandards nicht sinnvoll. Erst weil bestimmte Projekttypen wiederholt ablaufen, machen Überlegungen über die standardisierte Strukturierung von Projekten im Projektmanagement Sinn, sodass man sogar von einem Projektmanagementprozess spricht. Ein Beispiel dafür sind etwa Projektfertiger wie Anlagenbauer oder Baufirmen, die ihre Geschäft in Projekten abwickeln, die bestimmten Prozessen folgen. Die Grenzen zwischen Prozessen und Projekten sind daher weniger klar, als dies durch das Kriterium der Wiederholung scheinen mag.

30


Abb. 6: Geschäftsprozesssicht und Kundenorientierung (1)

Die Abfolge der Tätigkeiten zur Erstellung des Produkts oder der Leistung sind die Abwicklungsschritte für das Kundenanliegen – sind sie gut organisiert und optimiert, so nimmt der Kunde das über die Qualität der Leistung (z. B. weniger Mängel), die Servicequalität (z. B. verlässliche Lieferung), den Preis (über geringere Prozesskosten) sowie die Prozesstransparenz (z. B. Auskunftsfähigkeit bei Nachfragen zum Kundenanliegen) wahr. Das Ergebnis des End-to-End-Prozesses ist die Leistung, die der Kunde zur Deckung seines Bedarfs benötigt. End-to-End-Geschäftsprozesse verkörpern damit eine sehr ausgeprägte Kundenorientierung. Es ist auch diese Kundenorientierung, die von Vertretern des Prozessmanagements oft als Kernelement des Prozessansatzes definiert und richtigerweise als einer der wesentlichsten Nutzenaspekte daraus angeführt wird. Wie Michael Hammer es ausdrückt: „Wer Prozesse in den Vordergrund rückt, betrachtet sein Unternehmen aus der Sicht der Kunden.“55 Dennoch ist Prozessmanagement nicht gleich zu setzen mit Kundenorientierung.56 Letztere ist viel mehr und geht über die Prozesse hinaus. Anders gesagt, Prozesse sind nur ein Teil von Kundenorientierung, andere Teile, die mit den Prozessen nicht unmittelbar etwas zu tun haben, wären etwa eine entsprechende Freundlichkeit und ein Respekt dem Kunden gegenüber im Service, ein maßvolles Pricing oder auch die Bereitschaft, die Prozesse nicht nur zwischen 9 und 15 Uhr durchzuführen, sondern zum Beispiel rund um die Uhr – denken wir nur etwa an die Prozesse einer traditionellen Bank als Illustration. Alle drei genannten Beispiele würden die Kundenorientierung stark beeinflussen, ohne jedoch den dahinter liegenden Geschäftsprozess in irgendeiner Weise zu ändern. Die Prozessperspektive beinhaltet somit zwar eine starke Kundenorientierung, ist aber auch nicht ausschließlich auf den Kunden ausgerichtet. Vielmehr umfasst sie ne55 Hammer (1997), S. 28. 56 Z. B. EABPM (2009), S. 40; ebenso Knuppertz (2009), für den Prozessorientierung der Kundenorientierung entspricht (S. 138); detto Ahlrichs, Knuppertz (2006), S. 4.

31


ben den aus Kundensicht notwendigen Abwicklungsschritten zum Beispiel auch intern oder extern bedingte Steuerungs- und Kontrollschritte, also auch Elemente, die der Kunde aus seiner Sicht nicht unbedingt wollen und goutieren würde: Denken wir etwa zum Beispiel an zusätzliche Schritte zur Gewährleistung der Prozesssicherheit für die ausführenden Mitarbeiter, die dem Kunden keinen Mehrwert bringen, für den Schutz der Mitarbeiter vor Verletzungen aber ganz wesentlich sind; oder an die Standardisierung und Harmonisierung von Prozessen, die dem Kunden per se einmal nichts bringt und ihn eventuell sogar in Bezug auf die Flexibilität für individuelle Kundenwünsche einschränkt, aber für das Unternehmen für die Steuerung des Geschäfts ganz wesentlich ist. Weitere Beispiele für solche Prozessschritte, die der Kunde von sich aus wohl nicht verlangen würde, sind die strikte Kontrolle offener Kundenforderungen, Schritte zum Einmahnen offener Rechnungen, zur Überprüfung von Personaldokumenten des Kunden vor dem Bezug bestimmter Leistungen, die Überprüfung der Kreditwürdigkeit in den Kreditprozessen einer Bank und Ähnliches. Insofern darf die Prozesssicht nicht mit Kundenorientierung gleichgesetzt werden.57 Sie enthält viele Aspekte, die mit der Kundenorientierung deckungsgleich sind, ist aber dennoch ein Ansatz, der primär den Unternehmenszielen verpflichtet ist und enthält damit auch Elemente, die nicht im unmittelbaren Kundeninteresse liegen oder diesem sogar entgegengesetzt sein können. Gute Geschäftsprozesse sind daher ein notwendiges Element für eine hohe Kundenzufriedenheit, aber nicht ihr Garant. Ganz im Gegenteil kann ein Unternehmen bei sehr guten Prozessen, völlig überhöhten Preisen und einem unfreundlichen und arroganten Personal dennoch unter einer niedrigen Kundenzufriedenheit leiden. Umgekehrt heißt das auch, dass eine hohe Kundenzufriedenheit keine logische Folge und kein alleiniger Nutzen aus guten Geschäftsprozessen sein muss. Gute Prozesse sind nur eine notwendige, jedoch keine hinreichende Bedingung für eine hohe Kundenzufriedenheit. Prozessmanagement kann damit sicher einen sehr wertvollen Beitrag zur Kundenorientierung und Kundenzufriedenheit leisten. Versprechungen des Prozessmanagements hinsichtlich der Kundenzufriedenheit können daher aber dennoch nur sehr vorsichtig und differenziert gemacht werden. Aus den genannten Gründen ist auch die Messung der Kundenzufriedenheit als Messkriterium für die Güte der Prozesse differenziert zu sehen: Sie misst die Zufriedenheit des Kunden mit dem Gesamtauftreten des Unternehmens und seiner Leistungen und nicht nur seine Zufriedenheit mit den Geschäftsprozessen des Unternehmens. Um für das Prozessmanagement als Leistungsmessung sinnvoll verwertbar zu sein, muss die Abfrage der Kundenzufriedenheit konkrete Fragen im Hinblick auf die Prozesse oder von den Prozessen direkt abhängige und beeinflussbare Faktoren beinhalten, also etwa die Zufriedenheit mit der Liefertermintreue, mit der Reaktionszeit 57 Die fälschliche Gleichsetzung von Prozessmanagement mit dem Ziel den Kundennutzen zu optimieren findet sich in der Prozessmanagementliteratur an vielen Stellen, z. B. EABPM (2009), S. 40.

32


Abb. 7: Geschäftsprozesssicht und Kundenorientierung (2)

oder mit der Auskunftsfähigkeit bei Anfragen zu laufenden Geschäftsfällen. Ein allgemeiner, aggregierter Kundenzufriedenheitsindex ist für die Prozesse hingegen nur sehr bedingt aussagekräftig.58 2.2.3 Prozesssicht und Mitarbeiterorientierung

Ganz ähnlich wie mit dem Verhältnis zwischen Prozesssicht und Kundenorientierung verhält es sich auch mit jenem zwischen Prozesssicht und Mitarbeiterorientierung. Denn durch das Ziel, die Geschäftsprozesse zu verbessern, klare Zuständigkeiten festzulegen und die Schnittstellen zwischen verschiedenen Prozessen und Bereichen zu verbessern, kann das Prozessmanagement auch einen wertvollen Beitrag dazu leisten, dass es zwischen den Mitarbeitern weniger Konflikte, Unsicherheit, Hektik und Ärger gibt.59 Darüber hinaus verbinden zahlreiche Protagonisten des Prozessmanagements dieses auch mit weiter gehenden Konzepten der Mitarbeiterorientierung, wie etwa Job Enlargement, Job Enrichment oder anderen Konzepten, welche die Erweiterung 58 Vgl. dazu z. B. Osterloh, Frost (2000), die im Projektbeispiel der Bank Leu die Kundenzufriedenheit als eine von drei zentralen Messgrößen beschreiben (S. 71). Ebenso Schmelzer, Sesselmann (2010), die die Kundenzufriedenheit als einen der wichtigsten Leistungsparameter der Prozesseffektivität sehen (S. 65). Demgegenüber spricht z. B. auch Klimmer (2007, S. 103) differenzierter davon, dass die Prozesse die Kundenzufriedenheit „beeinflussen“ können, ohne jedoch auf andere Einflussfaktoren einzugehen. Wichtig ist hier festzuhalten, dass die Kundenzufriedenheit in Qualitätsmanagementansätzen natürlich eine sehr wichtige Messgröße ist, dass Qualitäts- und Prozessziele und damit auch Qualitäts- und Prozesskennzahlen aber nicht deckungsgleich sind. Als Qualitätskennzahl ist die generelle Kundenzufriedenheit durchaus sinnvoll, als Prozesskennzahl hingegen nicht oder nur sehr bedingt. 59 Vgl. z. B. Klimmer (2007, S. 104).

33


der Verantwortung und des Entscheidungs- und Gestaltungsspielraumes der Mitarbeiter zum Ziel haben und somit deren Arbeit interessanter machen. Auch hierzu kann das Prozessmanagement durch eine stärkere Integration der Ausführungsverantwortung als Gegenpol zu einer zu starken Spezialisierung und durch die komplette Verantwortung für ganze Teilprozesse in manchen Bereichen sicher einen wertvollen Beitrag leisten. Neben diesen Punkten der Mitarbeiterorientierung, die durch die Prozesssicht verbessert und unterstützt werden können, gibt es jedoch auch hier eine Reihe von Elementen der Mitarbeiterorientierung, die mit Prozessmanagement nichts zu tun haben. So z. B. eine leistungsgerechte Entlohnung, faire Karrieresysteme, flexible Arbeitszeiten oder besondere Leistungen für die Mitarbeiter, wie etwa eine Fortzahlung der Gehälter im Krankheitsfall oder spezielle fringe benefits, wie etwa ein kostenfreier Betriebskindergarten. Alle diese Elemente wirken auf die Mitarbeiterzufriedenheit genauso ein, wie die prozessbedingten Einflussfaktoren. Ebenso gibt es auch hier Elemente des Prozessmanagements, welche die Mitarbeiter von sich aus nicht verlangen würden und eventuell sogar eher als Behinderung oder unnötige Administration sehen. Denken wir nur an die Zeitschreibung als saubere Basis für die Verrechnung aufwandsbezogener Leistungen, die kostenarten- und kostenstellengenaue Abrechnung von Reisekosten, das Vier-Augen-Prinzip bei der Freigabe von Bestellungen und Rechnungen oder Revisionsprüfungen zur Überprüfung, ob bestimmte Regelungen auch tatsächlich eingehalten wurden und Handlungen im operativen Geschäft rechtmäßig vollzogen wurden. So wie bei der Kundenorientierung ist es daher auch hier so, dass Mitarbeiterorientierung ein eigenes, klar abgegrenztes Konzept ist, das mit der Prozesssicht nur einige Überschneidungen aufweist. Versprechungen des Prozessmanagements zur He-

Abb. 8: Geschäftsprozesssicht und Mitarbeiterorientierung

34


bung der Mitarbeiterzufriedenheit sind daher zwar nicht unbegründet, müssen aber genau wie im Hinblick auf die Kundenzufriedenheit differenziert und sehr vorsichtig gemacht werden. Die Mitarbeiterzufriedenheit wird durch die jährliche Gehaltserhöhung, eine generösere Firmenwagenregelung oder ganz generell die Kultur des Unternehmens und die Art des Umgangs miteinander mindestens genauso beeinflusst wie durch reibungslosere Abläufe, klarere Zuständigkeiten und umfassendere Gestaltungsspielräume. Für die Leistungsmessung für das Prozessmanagement ist daher eine allgemeine Abfrage der Mitarbeiterzufriedenheit nur sehr bedingt aussagekräftig, sofern sie nicht konkrete, prozessbezogene Fragen enthält und dazu detaillierte Ergebnisse bietet. Zudem ist wichtig festzuhalten, dass viele der Konzepte zur Anreicherung von Arbeitsstellen und zur besseren Nutzung des Potenzials der Mitarbeiter auch durch Erweiterungen in anderen Dimensionen als jener der Prozesse möglich sind. Job Enrichment und Job Enlargement sind genauso in einer rein funktional orientierten Organisationsstruktur durch umfassendere Zuständigkeiten und erweiterte Entscheidungsspielräume denkbar und möglich. Sie sind konzeptionell nicht ausschließlich auf die Prozessorientierung beschränkt. Dass diese Konzepte vor allem von Protagonisten des Prozessmanagements vertreten und gefördert werden, muss daher nicht nur in der Prozesssicht begründet sein, sondern könnte auch genauso an den vorausgehenden Werthaltungen und der grundsätzlichen Philosophie dieser Vertreter liegen. Anders gesagt: Es könnte sein, dass hier in manchen Fällen Ursache und Folge vertauscht sind und die Konzepte zur größeren Mitarbeiterorientierung nicht zwingende Folge der Prozesssicht sind, sondern vielmehr aus einer bestimmten Werthaltung und Philosophie folgen, die jene Vertreter auch erst zum Prozessdenken geführt hat. Im Effekt in der Praxis ist dies vermutlich unerheblich. Für fundierte Aussagen über den Nutzen der Prozesssichtweise auf das Unternehmen macht es jedoch einen wesentlichen Unterschied. 2.2.4 Abgrenzung von Unternehmensfunktionen

Mindestens genauso häufig wie die Vermischung von Prozessorientierung mit den Konzepten der Mitarbeiter- und der Kundenorientierung ist jene zwischen Prozessen und Funktionen. In vielen Prozessmodellen in Unternehmen begegnet man „Prozessen“ wie etwa Buchhaltung, Controlling oder Materialwirtschaft.60 Darunter gibt es häufig „Prozesse“ wie Debitorenbuchhaltung, Kreditorenbuchhaltung und Anla60 Siehe dazu auch Rudolf Wilhelm (2007), S. 37 f. Ebenso Schmelzer, Sesselmann (2010), S. 35.Vgl. dazu z. B. auch Stark, Kind (2010): Für sie lassen sich typische Geschäftsprozesse „entsprechend den Hauptfunktionen eines Unternehmens ordnen und betreffen beispielsweise das Marketing, die Forschung und Entwicklung, die Fertigung und Montage sowie den Vertrieb, aber auch unterstützende Bereiche, wie zum Beispiel das Personalwesen oder den Einkauf, und schließlich die allgemeinen Managementfunktionen, wie beispielsweise die strategische Planung oder das Finanzwesen“ (S. 379–380). Ähnlich führen Becker, Meise (2008) ein konkretes Beispiel an, in dem Vertrieb, As-

35


Abb. 9: Anwendung der Prozesskriterien auf die Buchhaltung

genbuchhaltung; oder aber Kostenrechnung, Reporting, Projektcontrolling und Beteiligungscontrolling, um nur ein paar Beispiele zu nennen. Es sind dies lange bekannte und gewohnte Begriffe im Unternehmen, die keiner großen Erklärung bedürfen. Jeder kennt Sie, entweder aus der Schulausbildung, aus dem Betriebswirtschaftsstudium oder einfach nur, weil man Kollegen kennt, die in den betreffenden Abteilungen arbeiten. Was liegt also näher, als diese bekannten Elemente in das Prozessmodell aufzunehmen. Aber: Handelt es sich dabei wirklich um Geschäftsprozesse im Sinne des definierten End-to-End-Verständnisses? – Versuchen wir unsere oben entwickelte Definition gleich einmal am Beispiel Buchhaltung aus. Die Buchhaltung besteht meist aus einer Untergliederung in Hauptbuchhaltung, Debitorenbuchhaltung, Kreditorenbuchhaltung und Anlagenbuchhaltung. Um Tätigkeiten bzw. Tätigkeitsbereiche handelt es sich dabei zweifellos. Aber wie ist es mit der Abfolge: Können wir die genannten Aufgaben in eine Sequenz bringen, welche die zeitlich-logische Abarbeitung eines Geschäftsfalls wiedergibt? – Nein, zwischen Debitoren-, Kreditoren-, Anlagenbuchhaltung und Hauptbuch besteht keine durchgängige Sequenz der Schritte, die auf eine Kundenleistung abzielt. Auch gehören sie nicht direkt zur Abarbeitung eines gemeinsamen Geschäftsfalls. Wenn wir uns einen Kundenfall denken, in dem ein Kunde etwas kauft, das wiederum bei einem Lieferanten bestellt werden muss, so hätten wir zumindest Elemente der Debitoren- und der Kreditorenbuchhaltung, die dabei vorkommen. Allerdings auch nicht für sich alleine in einer direkten Abfolge, sondern in Verbindung mit Verkaufsaktivitäten und Einkaufsaktivitäten und vermutlich auch noch anderen Teilprozessen zwischen ihnen. Schließlich folgen die kreditorische Buchung aus der Bestellung beim Lieferanten und die debitorische Buchung aus dem Verkauf und der Fakturierung an den Kunden. Ebenso folgen die Aktivitäten in der setmanagement, Nutzenoptimierung, Immobilienentwicklung, Vermarktung, Planen und Bauen sowie Finanzmanagement als Kernprozesse der DeTe Immobilien identifiziert wurden (S. 132).

36


Anlagenbuchhaltung aus der Fertigstellung oder dem Kauf von Anlagen oder auch aus Projekten, in denen aktivierungspflichtige Ergebnisse erstellt werden. Zum Dritten adressiert die Buchhaltung – abgesehen vom Fall einer Steuerberatung oder einem Outsourcinganbieter für Buchhaltungsdienste – keinen Bedarf eines externen Kunden. Und sie erbringt mit den korrekten Verbuchungen der einzelnen Geschäftsfälle auch keine Leistung, für welche die Kunden bezahlen würden. Die Buchhaltung (accounting) ist also definitiv kein Geschäftsprozess. Versuchen wir es eine Stufe darunter, mit der Debitorenbuchhaltung (accounts receivables). Hier finden wir Aufgaben wie: einen neuen Debitor anlegen, die Bonität des Kunden überprüfen, Ausgangsrechnungen debitorisch verbuchen, Zahlungseingänge mit Debitorenposten abgleichen, offene Debitorenposten mahnen, Saldenbestätigungen ausstellen, nicht einbringbare Forderungen ausbuchen etc. Um Tätigkeiten handelt es sich dabei wiederum ohne Zweifel. Und auch mit der Abfolgebeziehung sieht es diesmal nicht so schlecht aus: Die genannten Tätigkeiten können untereinander in eine sinnvolle Sequenz gebracht werden, die sich am Geschäftsfall orientiert. Bildet diese Abfolge jedoch alle notwendigen und direkt mit dem Geschäftsfall verbundenen Tätigkeiten zur Erstellung der Leistung an den Kunden ab? – Nein, das tut sie nicht. Bei genauer Betrachtung fehlt der Großteil der für die Leistungserbringung notwendigen Schritte und die genannten Tätigkeiten decken nur die buchhalterische Verbuchung des Geschäftsfalles am Ende ab. Zusätzlich finden wir, wenn wir dem Geschäftsfall folgen, zwischen den Prozessschritten der Debitorenbuchhaltung andere Schritte, die aus reiner Buchhaltungssicht ausgeblendet sind. So erfolgt das Prüfen der Bonität typischerweise am Beginn des Verkaufsprozesses vor der Auftragsannahme, die übrigen angeführten Prozessschritte folgen jedoch erst nach erfolgter Lieferung und Fakturierung. Last but not least adressiert die Debitorenbuchaltung für sich genommen – abgesehen wiederum von der speziellen Situation von Oursourcinganbietern und Steuerberatungen – keinen Kundenbedarf und liefert keine Leistung, für die der Kunde für sich alleine genommen bezahlen würde. Die Debitorenbuchhaltung fasst also verschiedene Prozessschritte, die an unterschiedlichen Stellen eines Geschäftsprozesses vorkommen und benötigt werden, zusammen.61 Der Grund, warum diese Prozessschritte zusammengefasst werden, liegt in der inhaltlichen Ähnlichkeit ihrer Verrichtung und den dafür notwendigen Kenntnissen und Fähigkeiten. Für die Erledigung dieser Prozessschritte sind detaillierte Buchhaltungskenntnisse und Fähigkeiten zur Bedienung des unterstützenden Buchhaltungs61 Vgl. Hammer, Champy (1994), die anhand der Kreditorenbuchhaltung festhalten, dass es sich dabei nicht um einen Prozess handelt (S. 63). Für sie ist der Prozess in diesem Fall der Beschaffungsprozess, von dem die kreditorischen Verbuchungsaktivitäten ein Teil sind (S. 64). Da jedoch der Beschaffungsprozess für sich keinen Wert für den Kunden schafft, entspricht auch er nicht der von den Autoren selbst vorgebrachten Prozessdefinition, sondern beschreibt selbst wiederum in vielen Fällen nur einen Teil in der gesamten End-to-End-Kette der Leistungserbringung.

37


Abb. 10: Anwendung der Prozesskriterien auf die Debitorenbuchhaltung

systems erforderlich, die eine spezielle Ausbildung und Schulung erfordern. Würde man die Verbuchungsschritte direkt bei den zuständigen Sachbearbeitern lassen, die einen Auftrag abwickeln, so müssten diese alle über gewisse Buchhaltungskenntnisse verfügen und die Buchhaltungsapplikation bedienen können. Dadurch, dass man jene Schritte, bei denen solches Spezialwissen notwendig ist, aus den Prozessen an den verschiedenen Stellen herauszieht und sie bündelt, kann man eine viel kleinere Gruppe von Spezialisten gezielt zu ihrer Erledigung einsetzen. Erst durch dieses gezielte Einsetzen wird vielfach ein wirtschaftlicher Einsatz solcher Spezialisten überhaupt erst möglich. Gleichzeitig wird durch die Bündelung – da die Spezialisten dieselben Spezialschritte ständig in hoher Anzahl immer wieder ausführen – die Effizienz in der Durchführung erfahrungsgemäß signifikant gesteigert und zudem auch die Qualität der Erledigung deutlich erhöht. Genau aus diesen einfachen Gründen werden seit mehr als zweihundert Jahren spezielle Prozessschritte aus den End-to-End-Prozessen für die Leistungserstellung herausgezogen und übergreifend in Unternehmensfunktionen gebündelt.62 Die Buchhaltung und auch die Debitorenbuchhaltung sind solche Unternehmensfunktionen. Die dahinter liegende Grundidee ist jene, die von Adam Smith 1776 erstmals strukturiert dargestellt und später von Charles Babbage, James Taylor und Henry Ford weiter entwickelt wurde.63 Dabei werden Aufgaben im Unternehmen mehrfach in kleine, überschaubare Schritte untergliedert und diese für verschiedene Produkte und Leistungen gebündelt, um einerseits Effizienzvorteile aufgrund der dadurch entste62 In der Organisationsentwicklung wird hierfür der Begriff der „Ausgliederung“ von Aufgaben verwendet. Siehe z. B. Frese (1995). 63 Vgl. Smith (1999), S. 9 ff.; Babbage (1832), S. 98–107. Für eine Darstellung der historischen Entwicklung dieser Ideen siehe z. B. Schober (2002), S. 47 ff. Weilkiens, Weiss, Grass (2010) sehen völlig konträr zur hier vorgestellten klaren Trennung von Unternehmensfunktionen und Prozessen den Ursprung des Prozessmanagements bei Adam Smith (S. 57 f.).

38


Abb. 11: Geschäftsprozesssicht und funktionale Gliederung64

henden größeren Häufigkeit derselben Verrichtung durch eine Stelle zu erzielen (Größendegression, economies of scale) und andererseits auch die Arbeitskräfte entsprechend den für die jeweiligen Schritte notwendigen Fähigkeiten möglichst wirtschaftlich einzusetzen: zum Beispiel ungelernte, billigere Kräfte für bestimmte einfache Abwicklungsschritte und sehr gut ausgebildete, teurere Arbeitskräfte gezielt für jene Abwicklungsschritte in der Leistungserbringung, wo dieses spezielle Know-how erforderlich ist. Es wäre völlig unwirtschaftlich, sehr gut ausgebildete Spezialisten für einfache Tätigkeiten einzusetzen, die auch von günstigeren Hilfskräften durchgeführt werden können. Während Geschäftsprozesse Tätigkeiten in ihrer Abfolge zur Erstellung einer Leistung betrachten, werden dieselben Tätigkeiten in der Funktionssicht nach ähnlichen Verrichtungen aggregiert. Dabei werden Prozessschritte zusammengefasst, die zum Teil innerhalb desselben End-to-End-Prozesses an verschiedenen Stellen vorkommen, z. B. Bonität prüfen und Zahlungseingänge abgleichen; ebenso ähnliche Verrichtungen über verschiedene Geschäftsprozesse hinweg, z. B. Ausgangsrechnung buchen für Produktverkäufe, für Serviceleistungen und für Ersatzteillieferungen; und teilweise kommt es auch vor, dass manche der Tätigkeiten innerhalb eines Geschäftsprozesses unmittelbar aufeinanderfolgen, z. B. Zahlungseingänge prüfen und offene Rechnungen mahnen. Gerade letztere sind insofern gefährlich, als zwischen ihnen partiell eine direkte Abfolgebeziehung besteht und daher der Eindruck entstehen könnte, es handelt sich doch irgendwie um einen Prozess. Das Kriterium der Zusammenfassung ist

64 Vgl. dazu auch die Darstellung bei Weske (2007), S. 80.

39


jedoch nicht die Abfolge des Geschäftsfalles, sondern die Ähnlichkeit der Verrichtung. Die so entstehenden Unternehmensfunktionen sind ein Strukturierungselement der Aufgabengliederung und dienen der Spezialisierung, um einerseits eine höhere Produktivität zu erreichen und andererseits Positionen zu schaffen, für die es durch die genaue Eingrenzung der Aufgaben leichter wird, entsprechende Mitarbeiter zu finden sowie generell Mitarbeiter auf Basis ihrer Qualifikation gezielt und wirtschaftlich einzusetzen. Das Konzept von Shared Service Centern entspricht genau diesem Gedanken: die Bündelung von verrichtungstechnisch ähnlichen Prozessschritten aus verschiedenen Geschäftsprozessen, die meist spezielles Know-how (z. B. Buchhaltungskenntnisse) erfordern in geschäftsprozess-, geschäftseinheits- und auch unternehmensübergreifenden Serviceeinheiten. Shared Services sind somit eine Weiterentwicklung der bekannten funktionalen Aufgabendifferenzierung über die Grenzen von Unternehmenseinheiten hinaus.65 Natürlich wäre es auch möglich, nur abgrenzbare Teilprozesse zusammenzufassen und durch Shared Services erbringen zu lassen. In der Praxis erfolgt die Ausgliederung jedoch meist nicht nur auf der Basis von Teilprozessen in der Abfolge der End-to-End-Prozesse, sondern in Form von funktional zusammengefassten Aufgabenbündeln. Gerade diese Herauslösung der Durchführungsverantwortung für diese Prozessschritte aus den Geschäftseinheiten und ihre Übertragung auf ein eigenes, teilweise u. a. zur Nutzung von Lohnkostenvorteilen auch noch disloziertes Center stellt eine große Herausforderung für die Prozesssicht dar, da trotz neuer Zuständigkeiten die Ablauffähigkeit des gesamten End-to-End-Geschäftsprozesses gewährleistet bleiben muss. Gerade weil Shared Service Center häufig übergreifend für mehrere Unternehmen innerhalb einer Gruppe tätig sind und oft auch selbst in eigenen Legaleinheiten organisiert werden, besteht hier jedoch ein größerer Antrieb, diese Schnittstellen zu formalisieren. Als Mittel hierzu dienen vor allem detaillierte Service-Level-Agreements, in denen die servicierten Prozessabläufe, die jeweils zugesicherten Inputs, die zu erbringenden Leistungen und Leistungsniveaus sowie Kosten und Folgen von Verstößen gegen die getroffenen Regelungen vereinbart werden. Aufgrund dieser Vereinbarungen erzielen Shared Service Center-Lösungen nach einer gewissen Einschwungphase neben Kosteneinsparungen auch meist bessere Ergebnisse für die gesamte Prozessqualität, da derartige Aufgaben meist auch vorher schon innerhalb der Geschäftseinheiten funktional gebündelt und somit in der Ausführungsverantwortung vom Rest des Geschäftsprozesses getrennt waren, jedoch ohne eine derartige formale Vereinbarung an den Prozessschnittstellen. Ein zweiter Grund für die funktionale Bündelung von Aktivitäten besteht in der gleichen, gemeinsamen und koordinierten Steuerung von bestimmten Sachverhalten. So werden etwa häufig Aufgaben in den Bereichen rechtliche Angelegenheiten, HSEQ 65 Zu Shared Services siehe z. B. Klimmer (2007), S. 27. Horváth & Partners (2005), S. 277–292.

40


oder Projektmanagement in den Unternehmen und Institutionen gebündelt. Auch hier fallen die darunter subsummierten Teilaufgaben in verschiedenen Geschäftsprozessen an. Rechtliche Prüfungen etwa im Rahmen der Prüfung von Kundenverträgen in den Verkaufsprozessen, der Beratung für Lieferantenverträge in den Einkaufsprozessen oder etwa der rechtlichen Vertretung von Claims in beiden. Bei HSEQ etwa durch die entsprechende Erstellung von Produktsicherheitsdatenblättern für bestimmte Produkte, deren Versand an die Kunden sowie die regelmäßige Prüfung der Aktualität dieser Dokumente. Im Falle des Projektmanagements durch Projektmanagementaufgaben im Prozess der Bereitstellung neuer Gebäude (Bauprojekte), der Einführung von neuen IT-Anwendungssystemen (IT-Projekte) oder der Integration eines zugekauften Unternehmens zur Umsetzung der Wachstumsstrategie im Rahmen des Strategieumsetzungsprozesses (strategische Projekte). Auch hier werden also wieder Prozessschritte aus verschiedenen Prozessen und von verschiedenen Stellen in den Prozessen auf Basis ihrer inhaltlichen Ähnlichkeit zusammengefasst. Neben dem dadurch entstehenden Servicecharakter umfassen diese genannten Funktionen aber auch steuernde und koordinierende Aufgaben, die nicht unmittelbar in den einzelnen Prozessen als Prozessschritte vorkommen, sondern den Rahmen vorgeben, wie die Prozessschritte in den Prozessen zu erfolgen haben. Hierunter fällt etwa die Erstellung, Vereinbarung und Kommunikation von Richtlinien zu Projektmanagementstandards, zur Arbeitssicherheit oder die Vorgabe allgemeiner Geschäftsbedingungen. Derartige Funktionen werden im organisatorischen Bebauungsplan von Unternehmen als Zentralfunktionen (corporate functions) bezeichnet. Sie zeichnen sich durch einen ambivalenten Charakter aus, weil sie einerseits steuernde Zielsetzungen haben und andererseits auch servicierende Aufgaben erfüllen. Die in diesen Zentral- und Servicefunktionen gebündelten Tätigkeiten und Aufgaben sind auch strukturiert und für die Wertschaffung für den Kunden notwendig. Sie orientieren sich jedoch nicht entlang des Geschäftsfalls und stehen in keiner Ablauffolge untereinander. Ebenso decken sie im Normalfall keinen externen Kundenbedarf mit einer verkaufbaren Leistung. Damit handelt es sich dabei nicht um Prozesse, sondern um Unternehmensfunktionen. Ähnlich wie mit den genannten Beispielen für Unternehmensfunktionen verhält es sich auch mit den neueren Konzepten Customer Relation Management, Supply Chain Management und Product Lifecycle Management. Auch sie umfassen nicht alle notwendigen Schritte für die Erstellung einer bestimmten Leistung für einen Kunden und sind somit keine vollständigen End-to-End-Geschäftsprozesse.66 Customer Relation Management (CRM) fasst verschiedene Aufgaben zusammen, die teilweise den Verkaufsprozessen vorgelagert sind (z. B. die Durchführung gezielter Kampagnen), teilweise diesen nachgelagert sind (v. a. analytisches CRM im Sinne der Analyse von Kundenverhalten) sowie teilweise den Verkaufsprozess begleiten 66 Siehe z. B. Walter (2009), der CRM, SCM und PLM als zentrale Prozesse sieht.

41


(klassische CRM-Funktionen wie Wiedervorlage von Angeboten im Vertrieb oder kompletter Überblick über alle Kundenaufträge und deren Status bei Annahme eines neuen Kundenauftrags eines bestimmten Kunden). Alle diese Aktivitäten zielen auf ein koordiniertes und zielgerichtetes Managen der Kundenbeziehung. Isoliert betrachtet stehen sie sogar in einer bestimmten Abfolge zueinander, jedoch decken sie nicht alle notwendigen Prozessschritte zur vollständigen Abarbeitung von Geschäftsfällen ab. Vielmehr umfasst CRM eben nur bestimmte Schritte, die an unterschiedlichen Stellen der Leistungserstellungsprozesse angesiedelt sind, und dies im Sinne des Konzepts one-face-to-the-customer für verschiedene Produkte und Leistungen. Ebenso erbringt Customer Relationship Management für sich genommen keine eigenständige Leistung für den Kunden, die dessen Bedarf deckt und für die dieser bezahlt. Oder kennen Sie eine Firma, die schon einmal ihren Kunden eine Rechnung für das durchgeführte Customer Relationship Management gestellt hat? – Nein, CRM ist eine funktionale Sicht auf die eigenen Prozesse, um die Kundenbeziehungen konsequent und effektiv zu managen; es erzeugt jedoch im Normalfall keine eigenständige Kundenleistung, die für den Kunden von Wert ist und seinen Bedarf adressiert. Im Sinne des entwickelten Prozessverständnisses handelt es sich daher bei Customer Relationship Management nicht um einen End-to-End-Geschäftsprozess, sondern um eine Unternehmensfunktion. Dasselbe gilt für Supply Chain Management (SCM), das typischerweise vorgelagerte Planungsfunktionen bzgl. Nachfrage und Kapazitäten, begleitende Steuerungsaufgaben (z. B. Mengen- und Lagersteuerung) und nachgelagerte Analyseaufgaben umfasst. Supply Chain Management zielt so auf eine integrierte und prozessorientierte Planung und Steuerung der Warenflüsse von den Lieferanten bis zu den Kunden. Es beschreibt damit vor allem die Logistikkette in der Leistungserstellung, vielfach mit einem speziellen Fokus auf eine bessere Planbarkeit der Produktion, einer optimierten Synchronisierung der Versorgung mit dem Bedarf und einer Reduktion der Bestände entlang der Wertschöpfungskette. So sollen durch verbesserten Informationsaustausch Turbulenzen und Schnittstellenprobleme reduziert werden.67 Spezielle IT-Systeme unterstützen diese Ziele und sorgen für eine verbesserte Informationstransparenz. Wie CRM erzeugt auch SCM – von Spezialfällen wie Logistikdienstleistern einmal abgesehen – keine eigenständige Leistung, für die der Kunde zu zahlen bereit ist, sondern zielt auf die Ergänzung bestehender Leistungen um spezielle Aspekte wie eine höhere Versorgungssicherheit, eine bessere Liefertermintreue oder geringere Kapitalbindung. Ebenso umfasst Supply Chain Management nicht alle Schritte der Wertschöpfungskette für die Erstellung einer Leistung, sondern legt den Fokus auf bestimmte Schritte, die an unterschiedlichen Stellen in den Leistungserstellungsprozes67 Vgl. Kuhn, Hellingrath (2009), S. 384 f. Vgl. Auch Jörns (2003, S. 45), der SCM als Methode bezeichnet, „unter der alle Maßnahmen zur Beherrschung eines komplexen Logistiknetzwerks zusammengefasst sind“.

42


sen angesiedelt sind. Andere, für diese Sichtweise nicht relevante Prozessschritte, wie etwa das Bewerben der Produkte, ihre Fakturierung oder die buchhalterische Verbuchung werden nicht betrachtet und einbezogen. Im Gegensatz zur definierten End-toEnd-Sicht von Geschäftsprozessen bietet Supply Chain Management damit genau wie CRM eine partielle Prozesssicht, die einen speziellen thematischen Fokus hat und damit nur bestimmte Prozessschritte, die für diesen Fokus wichtig sind, prozessübergreifend beleuchtet. Etwas anders verhält es sich mit dem Konzept des Product Lifecycle Managements (PLM). Hier werden Prozessschritte beginnend beim Design, über die Herstellung und Nutzung des Produkts bis hin zum Ausscheiden und Recycling am Ende der Nutzung integriert betrachtet, um den Produktnutzen über den gesamten Lebenslauf zu maximieren.68 In der Entstehungsphase wird dabei in einem Design for Life Cycle bereits darauf abgestellt, dass die Planung und Konstruktion für die spätere Nutzung und auch die sachgerechte Ausscheidung oder Wiederverwendung optimiert wird. Hierfür werden insbesondere auch Daten aus der Produktnutzung herangezogen, um die Produktgestaltung zu optimieren. In der Nutzungsphase – dem Life-TimeManagement – liegt der Fokus des PLM auf der Entwicklung von Strategien und Methoden zur Steigerung der Rentabilität des Produkts während der Nutzung sowie auf einer verbesserten und erweiterten Nutzung durch Zusatzleistungen. Diese sehr weitreichende und übergreifende Sichtweise enthält viele Ähnlichkeiten mit einer End-toEnd-Prozessperspektive. Dennoch gilt auch hier grundsätzlich das für CRM und SCM gesagte: Auch PLM umfasst nicht alle, sondern eben nur jene aus dem Blickwinkel der Lebenszyklusoptimierung relevanten Prozessschritte. Und ebenso wie CRM und SCM erzeugt auch PLM im Normalfall keine eigenständige Leistung für den Kunden. Auch PLM bietet somit meist eine partielle Prozesssicht aus einem speziellen thematischen Blickwinkel heraus. Soweit dieses Optimierungsziel jedoch im Sinne eines pauschalen Leistungsangebots über den gesamten Lebenszyklus hinweg selbst die erbrachte Leistung an den Kunden darstellt, wie dies etwa bei „full-service-Konzepten“, Performanceverträgen oder Life-Cycle-Cost-Verträgen der Fall ist,69 ist die PLM-Sicht deckungsgleich mit der leistungsorientierten End-to-End-Prozesssicht. In diesem Fall entsprechen die Prozesskosten des End-to-End-Prozesses den Kosten des Life Cycle Costings. Während dies in externen Verträgen noch nicht sehr etabliert ist, gilt diese PLM-Sichtweise – wenn auch unausgesprochen – meist für interne Bereitstellungsprozesse für Anlagen, Informationssysteme oder auch Personal. Customer Relationship Management, Supply Chain Management und Product Lifecycle Management sind damit im Regelfall keine End-to-End-Geschäftsprozesse, sondern stellen eine partielle Prozesssicht aus einem bestimmten thematischen Blickwinkel dar, ähnlich wie dies auch bei anderen Unternehmensfunktionen wie etwa 68 Vgl. Niemann (2009), S. 225. 69 Vgl. Niemann (2009), S. 227 und S. 229, sowie Niemann (2009a), S. 302.

43


Produktmanagement, Preismanagement, Supplier Relationship Management oder Brandmanagement der Fall ist.70 Sie entsprechen damit Unternehmensfunktionen, die Aktivitäten aus verschiedenen Geschäftsprozessen und an verschiedenen Stellen in den einzelnen Geschäftsprozessen zusammenfassen, um so einem bestimmten Thema einen höheren Fokus und Stellenwert zu geben und damit für das Unternehmen einen positiven Effekt zu erzielen. Ähnliche wie traditionelle Unternehmensfunktionen beinhalten auch sie steuernde wie auch servicierende Aufgaben. Sie sind inhaltlich sehr wertvolle und notwendige Ergänzungen für Unternehmen, die helfen, Nachteile von bestimmten aufbauorganisatorischen Strukturen abzuschwächen. – Da sie in sich auch in einer entsprechenden Ablauffolge darstellbar sind, werden auch sie häufig als Geschäftsprozesse bezeichnet, entsprechen jedoch nicht dem hier entwickelten Verständnis von End-to-End-Prozessen, die alle für die Erstellung einer Leistung notwendigen Schritte umfassen, sondern einer abteilungsbezogenen Teilprozesssicht. Ihre Vermischung mit Geschäftsprozessen dürfte mit der positiven und integrativen Konnotation von Prozessen zu tun haben und dem Faktum, dass Geschäftsprozesse im Management als wichtig akzeptiert sind, während Funktionen eher als altmodisch und wenig integrativ gesehen werden. Inhaltlich handelt es sich bei den drei Konzepten aber – mit den angemerkten Einschränkungen bestimmter Sonderfälle – klar um Unternehmensfunktionen und nicht um Geschäftsprozesse. Das macht sie jedoch in keinster Weise weniger wertvoll. Ganz im Gegenteil: alle drei sind sehr wichtige und innovative Konzepte für Unternehmen. Genauso hat auch die funktionale Sichtweise und Gliederung generell ihre Berechtigung und ist ein wichtiges Element der Unternehmensgestaltung und der Unternehmensorganisation. Unternehmensfunktionen sind weder etwas Böses, noch etwas Altmodisches, das es aus Prinzip zu überwinden gilt und keinesfalls ein Relikt aus einer längst vergangenen Zeit.71 Ganz im Gegenteil sind Unternehmensfunktionen eine in vieler Hinsicht sehr interessante Organisationsform, die es ermöglicht, komplexe Spezialaufgaben effizienter zu verrichten, die Produktivität in den einzelnen Aufgaben zu erhöhen und Mitarbeiter gezielt auf Basis spezieller Fähigkeiten und Ausbildungen einzusetzen.72 Wenn wir jedoch die Geschäftsprozesse einer Organisation untersuchen wollen, hilft diese Betrachtungsweise nicht weiter. Ganz im Gegenteil: 70 Vgl. Schmelzer, Sesselmann (2010), die CRM, SCM und PLM als „Prozessgruppen“ sehen (S. 79). Bereits die Bezeichnung mit dem Zusatz „*-Management“ ist oft ein Indiz dafür, dass es sich bei den zusammengefassten Aufgaben um eine Funktion handelt und nicht um einen Prozess. Es ist auch nicht verwunderlich, dass diese Konzepte v. a. von Softwareanbietern eingesetzt werden, da Softwaresysteme zum Großteil funktional strukturiert sind. 71 Vgl. dazu den Standpunkt von Michael Hammer und James Champy (1994), für die es in der heutigen Zeit nicht mehr sinnvoll und wünschenswert ist, Tätigkeiten in den Unternehmen nach den Grundsätzen von Adam Smith zu organisieren (S. 46). 72 Vgl. Rummler, Remias, Rummler (2010): Für sie sind “Functions/departments/centers of excellence [. . .] an efficient way to acquire, develop, support, and manage these necessary groups of expertise or ‘talent’.” (S. 76).

44


Sie würde dazu führen, dass die Organisation erst wieder nur aus dem gewohnten und etablierten Blickwinkel betrachtet wird und nicht aus der kundenorientierten Sicht der Geschäftsfälle. Ein solches Vorgehen könnte daher gegenüber den bereits bekannten Sichtweisen auf Unternehmen und Organisationen nur wenig an Erkenntnisgewinn bringen und hätte somit nur einen beschränkten Nutzen für die jeweilige Organisation. Nur wenn sich das Prozessmanagement im Sinn eines echten End-to-End-Prozessverständnisses auf die kundenorientierte Sicht der Geschäftsfälle konzentriert und diese konsequent umsetzt, kann es einen neuen Blickwinkel auf die Organisation bieten, der einen echten Mehrwert bringt. Aktuelle Prozessmodelle in den Organisationen spiegeln diese Prozesssicht oft nicht oder nur zum Teil wieder und basieren vielfach auf der etablierten und bekannten funktionalen Gliederung der Unternehmen bzw. auf funktional gegliederten Teilprozessen, ohne die End-toEnd-Sicht der Geschäftsprozesse im Sinne der Leistungs- und Ablaufbeziehungen zwischen diesen Teilprozessen transparent zu machen.73 Das mag zwar zu einer leichteren Akzeptanz in der Organisation führen – schließlich enthalten solche Prozessmodelle weitgehend Bekanntes und passen vielfach perfekt zur etablierten Aufbauorganisation. Ebenso mag es einen Beitrag zur Optimierung von Teilprozessen in den einzelnen Funktionsbereichen leisten. Über dieses hinaus können solche „Prozesse“ aber keine neue Sichtweise auf die Leistungserstellung im Unternehmen und keinen Mehrwert im Sinne der Integration über die einzelnen Bereiche hinweg bieten. Dass derart aufgesetzte Prozessmodelle oft mangels sichtbaren Mehrwerts wieder im Schrank landen und ein so verstandenes Prozessmanagement mangels neuer Sichtweisen und Inputs nur geringe Wertschätzung genießt, darf nicht verwundern. Dies liegt zu einem wesentlichen Teil an diesem reduzierten Prozessverständnis auf die reine Ebene der Teilprozesse. Für einen weiter gehenden Nutzen des Prozessmanagements für die Unternehmen ist eine echte End-to-End-Sicht auf die Geschäftsprozesse erforderlich.

73 Einen nicht unwesentlichen Anteil an dieser Verwechslung zwischen Unternehmensfunktonen und Geschäftsprozessen dürfe auch A.-W. Scheer mit der von ihm entwickelten ARIS-Methode sowie den diese Methode umsetzenden, weit verbreiteten Prozessmodellierungstools der ARIS-Produktfamilie haben. Denn in dieser Methodik besteht die Funktions- und die Prozesssicht aus denselben Objekttypen – Funktionen – obwohl die Bausteine beider Sichten jeweils nur auf der untersten Ebene gleich sind und für die darüber liegenden Ebenen anders aggregiert werden (einmal nach Prozessgesichtspunkten und das andere Mal nach funktionalen Gesichtspunkten). Vgl. dazu auch Scheer, Thomas (2009, S. 552), wo die Autoren festhalten, dass in der Methode der EPK der Funktionsbegriff mit dem der Aufgabe gleichgesetzt wird; ebenso Scheer (1998), S. 36. Eine klare Trennung der Objekttypen würde hier eine Verwechslung verhindern helfen.

45


2.2.5 Abgrenzung von Organisationseinheiten

Ebenso wie Geschäftsprozesse von Unternehmensfunktionen klar zu trennen sind, muss man sie auch von Organisationseinheiten unterscheiden. Anders als bei Funktionen liegt dies jedoch auf der Hand: Organisationseinheiten beschreiben die Aufbaustruktur des Unternehmens, Geschäftsprozesse die Ablaufstruktur. Da vielfach in den Organisationen eine Deckungsgleichheit zwischen Unternehmensfunktionen und Abteilungen gegeben ist, kann es jedoch zwischen diesen durchaus zu Verwechslungen kommen. Denn die Funktion Buchhaltung wird vielfach durch eine gleichnamige Abteilung wahrgenommen; ebenso ist es häufig bei der Materialwirtschaft und auch – zumindest oberflächlich betrachtet – bei der Funktion Controlling. Letztere ist aber gut geeignet, um zu zeigen, dass diese Deckungsgleichheit nicht sein muss. Denn die Controllingaufgaben im Unternehmen müssen nicht zwingend nur von Mitarbeitern der Abteilung Controlling wahrgenommen werden. Vielfach gibt es Bereichscontroller, die direkt in den Geschäftsbereichen angesiedelt sind und auch Controllingaufgaben wahrnehmen. Abteilung und Funktion sind hier also nicht deckungsgleich. Ein Teil der Aufgaben der Funktion wird durch Angehörige von anderen Organisationseinheiten wahrgenommen. Analog ist das auch für Buchhaltung und Materialwirtschaft möglich: Auch hier gibt es Fälle, wo die Funktion Buchhaltung auf dezentrale Buchhaltungsabteilungen in den lokalen Niederlassungen verteilt ist, oder wo die Funktion Materialwirtschaft an mehrere Lagerorten wahrgenommen wird, die unterschiedlichen Bereichen angehören. Aufbauorganisation, funktionale Gliederung und Geschäftsprozesse sind daher drei verschiedene Sichten auf eine Organisation, die klar voneinander zu trennen sind. Jede hat für sich ihre Berechtigung und ihren Nutzen: ·

Die Aufbauorganisation gliedert die Gesamtaufgabe in handhabbare Teilaufgaben, reduziert so die Komplexität und untergliedert die Gesamtzahl der Mitarbeiter in überschaubare, steuerbare Einheiten Die funktionale Gliederung fasst verrichtungsähnliche Prozessschritte in den Prozessen und über sie hinweg zusammen, um Effizienzvorteile zu erzielen und einen optimierten Personaleinsatz zu ermöglichen Und die Prozesssicht sichert die Integration der einzelnen Teilaufgaben im Hinblick auf die zu erbringende Leistung für den Kunden

·

·

Ihr Mehrwert besteht genau darin, dass sie unterschiedliche Blickwinkel auf Unternehmen und Organisationen bieten. Wird dieser unterschiedliche Blickwinkel durch ein falsches oder zu kurz greifendes Prozessverständnis nicht gewahrt, geht auch der Nutzen dieser dritten Perspektive auf das Unternehmen verloren.74 74 In der Unternehmensmodellierung gibt es neben diesen drei Sichten auch noch weitere: z. B. die Daten- oder die Leistungssicht. Die obige Darstellung bedeutet keineswegs, dass es nur die drei dar-

46


Abb. 12: Drei Sichten auf Organisationen aus dem Blickwinkel der Organisationsgestaltung

2.2.6 Benennung von Prozessen

Um die häufige Verwechslung von Geschäftsprozessen mit Unternehmensfunktionen und Organisationseinheiten zu vermeiden, sollte daher die Bezeichnung von Geschäftsprozessen sorgfältig und in klarer Abgrenzung von diesen beiden gewählt werden. Prinzipiell gilt es, solche Prozessbezeichnungen zu vermeiden, die auch bei Unternehmensfunktionen oder als Abteilungsnamen vorkommen und daher missverstanden werden könnten.75 Um hier sicher zu gehen, empfiehlt sich eine konsequente Bezeichnung von Prozessen über eine Kombination aus Substantiv und Verb,76 wobei das Verb die jeweilige Verrichtung bezeichnet und das Substantiv das Objekt, an dem die Verrichtung vorgenommen wird. Auf oberster Ebene können die Geschäftsprozesse so mit den durch sie erbrachten Leistungen bezeichnet werden, z. B. gestellten Sichten gibt. Sie soll vielmehr nur illustrieren, dass die Aufbauorganisationssicht, die Funktionssicht und die Prozesssicht klar unterschieden werden müssen. 75 Vgl. auch EABPM (2009), S 235. Ebenso Spanyi (2007), S. 59. 76 Siehe z. B. auch Wagner, Patzak (2007), S. 71. Ebenso Freund, Rücker, Henninger (2010), S. 26; Scheer, Thomas (2009), S. 552. Stöger (2009), S. 3; Siehe auch Becker, Meise (2008): dass diese einfache Regel dennoch oft nicht befolgt und eingehalten wird, zeigen bspw. deren selbst zitierte Beispiele (S. 132 und S. 150), die ebenso nicht dieser Grundregel, die von den Autoren vertreten wird (S. 149), entsprechen. Einen abweichenden Vorschlag dazu machen Rummler, Remias, Rummler (2010), die ihre Prozesse mit Objekt und Partizip benennen (z. B. product/service launched, product/service sold, product/service delivered), um den erstellten Wertbeitrag herauszustreichen. Demgegenüber wird hier die Benennung über Objekt und Verb präferiert, da so das Prozessergebnis und die Tätigkeitsfolge zu seinem Erreichen klarer herausgearbeitet werden.

47


· · · ·

Standardmaschinen verkaufen Pokerspiele anbieten Industrieverpackungslösungen anbieten etc.

Für die Teilprozesse empfiehlt sich eine Bezeichnung nach dem Objekt und dem Verb der jeweils enthaltenen Aktivitäten, z. B.: · · · · · · · ·

Neukunden gewinnen Anfrage bearbeiten Auftrag anlegen Produkt fertigen Produkt liefern Lieferung fakturieren Rechnung verbuchen etc.

Diese sehr operative und einfache Empfehlung mag angesichts der Wichtigkeit der vorher diskutierten Themen banal erscheinen – ein Blick auf die Praxis zeigt jedoch, dass die überwiegende Mehrzahl von Prozessmodellen dagegen verstößt und damit der Grundstein für Verwechslungen gelegt wird. Und dies, obwohl diese Grundregel trivial einfach ist und seit Jahren zu den etablierten Grundregeln des Prozessmanagements zählt.77 Dennoch finden sich in den Prozessmodellen immer noch zahlreiche Prozesse wie „Buchhaltung“, „Materialwirtschaft“ oder „Einkauf“. Durch diese simple und effektive Methode können Verwechslungen weitgehend vermieden werden, da Unternehmensfunktionen und Abteilungen nie Verben enthalten. In diesem Sinn wird die Einhaltung dieser Benennungskonvention hier nochmals strikt empfohlen – Kompromisse können in diesem Punkt sehr rasch zu Missverständnissen und einer Vermischung der Sichten führen. Ein weiterer Fehler, der in der Praxis häufig auftritt, ist die Verwechslung von Prozessen mit jenem Ausschnitt der End-to-End-Prozesse, der für eine bestimmte Betrachtung im Fokus ist. So sprechen viele Unternehmen aktuell von ihren Orderto-Cash- oder ihren Purchase-to-Pay-Prozessen. So schick und klingend diese Bezeichnungen aus sein mögen, sie bergen die Gefahr in sich, dass nicht der gesamte End-to-End-Prozess betrachtet wird, sondern nur ein Teil davon. Denn Leistungserstellungsprozesse beginnen dem hier entwickelten End-to-End-Verständnis folgend eben 77 Siehe z. B. Rudolf Wilhelm (2007), S. 36. Eine zweite, alternative Möglichkeit für die Benennung der Teilprozesse wäre es, das Wort „Prozess“ immer direkt in die Prozessbezeichnung zu integrieren, also z. B. „Vertriebsprozess“, Fakturierungsprozess, etc. – auch damit kann jegliche Verwechslung einfach vermieden werden. Die Variante mit Objekt und Verb ist jedoch besser, da sie den Aktivitätscharakter der Prozesse stärker betont.

48

Identifizieren von End-to-End-Geschäftsprozessen

nicht erst beim Auftrag, sondern enthalten typischerweise auch vorgelagerte Teilprozesse für das Marketing der Produkte und für die Akquisition der Aufträge. Handelt es sich um Standardprodukte, die auf Lager gefertigt werden, so sind auch die Teilprozesse der Absatzplanung und der Fertigung dem Auftrag (order) vorgelagert. Ebenso beginnt ein Purchase-to-Pay-Prozess typischerweise nicht mit der Bestellung (purchase), sondern einem vorausgehenden Bedarf, der in einer Fachabteilung auftritt, dem Einkauf bekannt gemacht und dort zum Beispiel über alle Abteilungen zu Sammelbestellungen gebündelt wird. Es handelt sich bei beiden Termini daher bei genauer Betrachtung nicht um komplette End-to-End-Prozesse beziehungsweise Bezeichnungen dafür. Vielmehr bezeichnen sowohl Order-to-Cash als auch Purchase-to-Pay wichtige Ausschnitte von End-to-End-Prozessen, die für verschiedene Optimierungen im Zuge des Managens von Prozessen oder für den unternehmensübergreifenden Vergleich von Prozesskennzahlen mit anderen im Rahmen eines Benchmarking im Fokus stehen können. Die beiden enthaltenen Objekte (z. B. purchase und payment) bezeichnen dann den genauen Umfang der Betrachtung: Sie beginnt bei Purchase-to-Pay etwa bei der Bestellung und endet mit der Zahlung an den Lieferanten. Gerade in Verbindung mit Zeitund Kostenkennzahlen kann ein so definierter Betrachtungsumfang sehr hilfreich sein, insbesondere, wenn ein Vergleich mit anderen Unternehmen angestrebt wird. Die klar definierten Anfangs- und Endpunkte der Betrachtung ermöglichen so einen validen Vergleich, ohne auf die Unterschiede in der Abwicklung dazwischen eingehen zu müssen. Die genannten Termini sollten jedoch nicht ohne genaue Überlegung und ohne Hinterfragen als End-to-End-Prozesse angenommen und verwendet werden.78 Die teilweise Erweiterung der Bezeichnungen von „order-to-cash“ auf „request-to-cash“ oder Ähnlichem würde zwar den End-to-End-Fokus besser wahren, sinnvoller scheint jedoch die Nutzung dieser Termini entsprechend ihrer ursprünglichen Zielsetzung als abgegrenzte Teilabschnitte von End-to-End-Prozessen für Analyse und Vergleichszwecke.

2.3 Identifizieren von End-to-End-Geschäftsprozessen 2.3.1 Leistungserstellungsprozesse

Nachdem wir definiert haben, was genau ein End-to-End-Geschäftsprozess ist, geht es im ersten Schritt zur Anwendung um die Frage, wie die Geschäftsprozesse eines Unternehmens identifiziert werden können.79 Obwohl es sich dabei um etwas sehr 78 Auch Rummler, Ramais, Rummler (2010) tappen in diese Falle, indem sie den Order-to-Cash Prozess als end-to-end bezeichnen, obwohl die End-to-End-Perspektive vom Bedarf des Kunden zur Leistung für diesen in ihrem Ansatz doch nur eine Ebene höher im Value Creation System gegeben ist (S. 144). 79 Es wird hier der Begriff Prozessidentifikation verwendet. Im Englischen wird hierfür oft von process discovery gesprochen, um zum Ausdruck zu bringen, dass hierbei das implizite Wissen über die Prozesse aufgedeckt und explizit gemacht wird. Vgl. Weilkiens, Weiss, Grass (2010), S. 47. Ebenso Ould (2005), S. 14.

49


Grundlegendes handelt, ist dies eine der wohl schwierigsten und bisher in der theoretischen Entwicklung des Themas am wenigsten beleuchteten Herausforderungen.80 Als Thomas Davenport 1993 sein Buch über Process Innovation publizierte, stellte er mit dem Statement „the breadth of the research notwithstanding, process innovation remains more art than science“81 voran, dass die Forschung in diesem Thema erst am Beginn sei. Siebzehn Jahre später kann konstatiert werden, dass dies zumindest was die Prozessidentifikation betrifft, auch heute noch weitgehend zutrifft. Zwar wurden Tausende von Unternehmensprozessmodellen entwickelt und auch zahlreiche Referenzmodelle erarbeitet, die als Richtschnur dienen können; an klaren Vorgehensweisen und Kriterien, wie man die Prozesse eines Unternehmens identifiziert, fehlt es aber nach wie vor. Um dies zu illustrieren, nehme man nur eine beliebige Organisation und lasse fünf verschiedenen Experten die Prozesse dieses Unternehmens auflisten – man wird dabei mit größter Wahrscheinlichkeit völlig unterschiedliche Geschäftsprozessstrukturierungen erhalten. Womit sich natürlich die Frage stellt, ob dies zwingend so sein muss oder vielleicht doch an einem Manko im theoretischen Fundament des Prozessmanagementansatzes liegt. Zahlreiche Vertreter des Prozessmanagements umgehen dieses Problem, indem sie entweder gar nicht oder nur sehr oberflächlich auf die Prozessidentifikation eingehen.82 Im letzteren Fall wird dabei meist rein auf die methodischen Vorgehensalternativen eines deduktiven Top-down-Ansatzes und eines induktiven Bottom-up-Ansatzes verwiesen, ohne jedoch konkret zu sagen, woraus die konkreten Prozesse eines Unternehmens abgeleitet oder induktiv erhoben werden sollen.83 Dort, wo konkretere 80 Vgl. auch Bogaschewsky, Rollberg (1998, S. 207), die die Identifikation („Definition“) von Prozessen als den wesentlichsten und „vermutlich am stärksten mit Problemen behafteten Teil der Prozessanalyse“ sehen. Auch Klimmer (2007, S. 125 f.) konstatiert, dass das Identifizieren der unternehmensspezifischen Prozessstruktur schwierig sei, weil keine eindeutigen und objektiven Regeln zum Bestimmen von Unternehmensprozessen existieren. Auch Schreyögg (2006, S. 122) verweist darauf, dass die Identifikation von Prozessen bislang noch ein schwach bearbeitetes Gebiet ist. Detto Becker, Meise (2008), S. 123. 81 Davenport (1993), S. 18. 82 So wird dieses Thema etwa von der European Association of Business Process Management in ihrem Common Body of Knowledge überhaupt nicht behandelt (EABPM 2009). Auch Wagner, Patzak gehen darauf nicht ein, sondern sehen unter Prozessidentifikation im Wesentlichen die Festlegung der wichtigsten Informationen zur ersten Beschreibung der Prozesse (Wagner, Patzak 2007, S. 99 und S. 104 f.). Auch Wilhelm (2007) geht nicht darauf ein, wie man die Prozesse eines Unternehmens identifiziert. Mangler (2006) erwähnt das Vorgehen zum Finden der relevanten Geschäftsprozesse nur am Rande (S. 32 f.). Eine Ausnahme stellt hier in gewisser Hinsicht Knuppertz (2009) dar, der sich durchaus breiter mit dieser Problematik befasst und dabei auch an inhaltlichen Fragen des Unternehmens anknüpft, z. B. den Unternehmenszielen und Kunden- und Marktanforderungen. Insbesondere zu letzteren stellt Knuppertz dieselben Fragen nach den adressierten Anforderungen und den erbrachten Leistungen, wie sie hier als Kernkriterium für die Identifikation von Geschäftsprozessen herangezogen werden (S. 78). 83 Siehe z. B. Becker, Meise (2008, S. 123–126): Sie geben keine weiter gehenden Anleitungen, sondern verweisen nur auf eine allgemeine Prozessidentifikation, bei der die Prozesse top-down aus allge-

50


Ansatzpunkte hierfür gegeben werden, konzentrieren sie sich im Wesentlichen auf zwei Bereiche als Ausgangspunkt: · ·

Die Unternehmensstrategie Vorhandene Referenzmodelle

Der erste Ansatz knüpft bei der Idee der Wertketten von Michael Porter an. Entscheidend ist hierbei ausgehend von der Unternehmensstrategie das Konzept der Kernprozesse: der „Verknüpfung von zusammenhängenden Aktivitäten, Entscheidungen, Informationen und Materialflüssen, die zusammen den Wettbewerbsvorteil eines Unternehmens ausmachen.“84 Kernprozesse stiften einen wahrnehmbaren Kundennutzen, sind durch die unternehmensspezifische Nutzung von Ressourcen einmalig, dürfen nicht leicht durch andere imitierbar und ebenso nicht durch andere Problemlösungen ersetzbar sein. Kernprozesse sind somit die „Quelle eine nachhaltigen Wettbewerbsvorteils“85. Diese Kernprozesse sind diesem Ansatz folgend die wesentlichen Geschäftsprozesse des Unternehmens, die dann nur mehr um allfällige Supportprozesse ergänzt werden müssten.86 Der Vorteil dieses Vorgehens, der sofort ins Auge springt, ist, dass hier gleich von Beginn an ein klarer Bezug zur Strategie des Unternehmens hergestellt wird. Dies ist ganz wesentlich, da Geschäftsprozesse ein essenzielles Element des Geschäftsmodells von Unternehmen sind, gerade in der Praxis des Prozessmanagements diese Verknüpfung zur Unternehmensstrategie aber vielfach zu kurz kommt. Meist wird Prozessmanagement als reiner Verbesserungsansatz des operativen Geschäfts verstanden; Potenziale des Prozessmanagements für die Strategieentwicklung und -umsetzung bleiben dagegen meist ungenutzt. meingültigen Prozessen abgeleitet werden, und einer individuellen Prozessidentifikation, bei der die Prozesse induktiv in einem kreativen Akt identifiziert werden. Für diesen empfehlen die Autoren eine intensive Auseinandersetzung mit den Prozesszielen, worunter neben vielen anderen Aspekten auch die Frage fällt, welche Leistungen den Kunden angeboten werden. Ähnlich Weilkiens, Weiss, Grass (2010), die nur auf generische Herangehensweisen wie top-down vs. bottom-up oder zentral vs. verteilt und strukturiert vs. unstrukturiert verweisen, darüber hinaus aber ebenso keine konkreten Anknüpfungspunkte geben (S. 47–50). Auch Speck, Schnetgöke (2008, S. 198) verweisen nur auf die übliche Differenzierung in Top-down- und Bottom-up-Vorgehen ohne weitere Spezifizierung dieses Vorgehens. Detto Auch Klimmer (2007, S. 125 f.), der so wie andere Autoren trotz Anmerkung des Problems nicht über die grundsätzliche Unterscheidung eines Top-down- und eines Bottom-up-Vorgehens hinausgeht. Ebenso Schober (2002), S. 21–23, der auch eine Übersicht über die wichtigsten Vertreter gibt. Manche Autoren verstehen top-down und bottom-up auch anders in dem Sinn, ob die Prozesse vom Management festgelegt (top-down) oder von den Mitarbeitern erarbeitet werden (bottom-up). 84 Osterloh, Frost (2000), S. 34 ff. Vgl. auch Gaitanides (2007), S. 116–121 ebenso S. 157. Detto Schmelzer, Sesselmann (2010), S. 98. 85 Osterloh, Frost (2000), S. 34. 86 Osterloh, Frost (2000), S. 35, führen als Beispiel für solche Supportprozesse Instandhaltung, Gebäudemanagement oder Personalcatering an.

51


Gleichzeitig hat dieses Vorgehen jedoch auch klare Nachteile. Denn da sich Wettbewerbsvorteile meist nur auf bestimmte Schritte in der Leistungserstellung beziehen, würden auf diese Art keine vollständigen Leistungserstellungsprozesse entsprechend dem formulierten End-to-End-Prozessverständnis identifiziert, sondern eben nur die zur Unterscheidung von den Wettbewerbern wesentlichen Teilprozesse oder Teilprozessbündel. Teilprozesse, die für die Differenzierung vom Wettbewerb nicht wesentlich sind, würden damit durch den Rost fallen. Dementsprechend handelt es sich bei den Teilen der Wertkette von Porter auch nicht um Prozesse im hier verwendeten End-to-End-Verständnis, sondern um ausdifferenzierte Funktionen: So enthält Porters Modell etwa die Elemente Unternehmensinfrastruktur, Personalwirtschaft, Technologieentwicklung, Beschaffung, Eingangslogistik, Produktion, Marketing & Vertrieb, Ausgangslogistik und Kundendienst – allesamt gute Bekannte der traditionellen funktionalen Unternehmensgliederung. Insofern entspricht Porters Wertkette keiner wirklichen Prozesssicht, sie thematisiert jedoch, dass durch das Zusammenspiel dieser Elemente Wettbewerbsvorteile entstehen können.87 Eine komplette und durchgängige Identifikation der Geschäftsprozesse ist mit dem auf Michael Porters Wertkette aufbauenden strategischen Ansatz nicht möglich. So wichtig die Idee der Kernkompetenzen und Kernprozesse auch für das Unternehmen im Wettbewerb mit den anderen Anbietern ist – für den Kunden ist sie ohne Relevanz. Aus Sicht der Kunden zählt einzig und allein die vollständige und der Erwartung entsprechende Leistungserbringung. Dazu zählen jene Teilprozesse, in denen ein Unternehmen keine Kernkompetenz hat und die nicht zu den Kernprozessen zählen genauso wie diese. Anders formuliert: Wenn ein Unternehmen seine Kernkompetenz im Engineering und im Fertigen von speziellen Maschinenteilen hat, so wird der Kunde dennoch berechtigt sauer sein, wenn es bei der Lieferung zu Verzögerungen kommt oder wiederholt falsche Rechnungen gestellt werden, obwohl es sich dabei nicht um Kernprozesse handelt. Für den Kunden zählt einzig die komplette Kette zur Erbringung der gewünschten Leistung. Spätestens mit dem Schritt von einem Teilprozessverständnis zu einem echten End-to-End-Prozessverständnis ist dieses Vorgehen daher nicht mehr anwendbar. Die Identifikation der Nicht-Kernprozesse bleibt damit weitgehend im Dunkeln. Zudem ist festzuhalten, dass Kernkompetenzen von Unternehmen nicht nur in bestimmten Prozessen liegen können, sondern vielfach auch in einem bestimmten Know-how oder in der Beherrschung und Anwendung verschiedener Technologien begründet sind.88 Bei einer Ableitung der Geschäftsprozesse aus den Kernprozessen besteht daher auch eine gewisse Gefahr, Sachverhalte, die per Definition keine Prozesse sind, in das Prozessmodell aufzunehmen – es besteht somit auch ein Risiko einer Vermischung von Funktionen und Prozessen, wie es oben diskutiert wurde. 87 Siehe Gaitanides (2007), S. 119. 88 Vgl. Gaitanides (2007), S. 132–133.

52


Das Wertkettenmodell von Porter ist daher ein sehr guter und bewährter Ansatz zur Identifikation der Stärken von Unternehmen – wofür es ja auch gedacht ist und entwickelt wurde. Es ist jedoch kein brauchbarer Weg für die Identifikation der Geschäftsprozesse von Unternehmen und war dafür auch nie gedacht, da Geschäftsprozesse im Sinne eines End-to-End-Prozessverständnisses eben alle Teilschritte umfassen, die für eine Leistungserstellung erforderlich sind und nicht nur jene, bei denen das Unternehmen Kernkompetenzen hat.89 Wir verwerfen diesen Ansatz daher für die Identifikation der Prozesse, werden jedoch später bei der Diskussion von Prozessmanagement als Managementansatz im Zusammenhang mit einer strategieorientierten Steuerung und Verbesserung der Prozesse wieder darauf zurückkommen. Eine zweite deduktive Vorgehensweise zur Identifikation der Geschäftsprozesse eines Unternehmens geht von allgemein verfügbaren Referenzmodellen aus und schlägt vor, die Geschäftsprozesse eines konkreten Unternehmens aus solchen allgemein differenzierbaren Prozessen abzuleiten.90 Verfügbare Referenzmodelle hierfür sind etwa: ·

· · ·

das Process Classification Framework (PCF) des American Productivity and Quality Center (APQC), das sowohl branchenneutral als auch für eine Reihe von speziellen Branchen vorliegt91 das Value Reference Model der Value Chain Group (VCG)92, das Geschäftsprozessmodell für Industrieunternehmen (GMI)93 die Enhanced Telecom Operations Map (eTOM), ein generelles Rahmenmodell für Geschäftsprozesse von Telekommunikations- und IT-Unternehmen des TeleManagement Forum (TMF)94 89 Vgl. dazu auch die Kritik von Schreyögg (2006, S. 122) an der Identifikation der Prozesse anhand von Kernprozessen und Kernkompetenzen. Er verweist darauf, dass dieses Vorgehen zirkulär sei, weil man die Bedeutung von Prozessen ja erst dann kennen kann, wenn man sie kennt und ihre Wirkungen analysiert hat. 90 Z.B. Michael Gaitanides (2007), S. 151 f. Auch Schmelzer, Sesselmann (2010) verweisen darauf, dass die Nutzung von Referenz- oder Standardprozessmodellen im Rahmen einer deduktiven Prozessidentifikation hilfreich sein kann, sehen die deduktive Ableitung jedoch primär aus der Unternehmensstrategie (S. 122–123). Mangler (2006) verwendet dafür den Begriff der idealtypischen Prozessidentifikation (S. 26). 91 Die APQC bietet angepasste Referenzmodelle für Aerospace und Defense, Automotive, Banking, Broadcasting, Consumer Products, Education, Electric Utilities, Petroleum Downstream, Petroleum Upstream, Pharmaceutical und Telekommunikationsindustrie. Siehe www.apqc.org. Vgl. auch Spanyi (2007), S. 60 –63. 92 Siehe z. B. Weilkiens, Weiss, Grass (2010), S. 151–152 für eine kurze Zusammenfassung. 93 Vgl. dazu Schmelzer, Sesselmann (2010), S. 210. 94 Siehe z. B. TeleManagement Forum (2010) oder Cisco (2009) für eine Übersicht. Die originalen eTOM-Dokumente selbst sind zum Großteil nur für Mitglieder des TeleManagement Forums zugänglich. Das eTOM Modell bietet auf den oberen Levels vor allem Aufgaben- und Prozessgruppen. Die für die End-to-End-Sicht interessante Ablaufintegration findet sich in den Process Flows.

53


·

das Handels-H-Modell, ein Referenzmodell, das einen Ordnungsrahmen für die Modellierung betrieblicher Informationssysteme im Handel bietet.95 Die SAP Solution Maps der SAP AG, die für verschiedene Branchen Standardprozesse für die von SAP-Software abgedeckten Bereiche anbieten96 das Supply Chain Operations Reference Model (SCOR) des Supply Chain Councils (SCC) als branchenübergreifendes Referenzmodell für Supply Chains das von der International Group of Controlling entwickelte Controlling-Prozessmodell97 die Infrastructure Library des britischen Office of Government Commerce (OGC) für den IT-Betrieb (ITIL) für IT-Servicemanagementprozesse und das Cobit-Modell (Control Objectives for Information and related Technology) des IT Governance Institute für IT-Governanceprozesse

· · · · ·

Die Identifikation der Geschäftsprozesse eines Unternehmens anhand eines Referenzmodells passiert dann ganz einfach, indem das oder die betreffenden Referenzmodelle durchgegangen werden und bei jedem Prozess entschieden wird, ob er auch für das betreffende Unternehmen zutrifft oder nicht. Nicht benötigte Prozesse werden weggelassen, sodass am Ende ein reduziertes Referenzmodell entsteht. Dieses wird schließlich noch um Prozesse ergänzt, die für das Unternehmen notwendig sind, sich aber nicht im Referenzmodell finden, sodass am Ende ein unternehmensspezifisches Prozessmodell entsteht, in dem alle Geschäftsprozesse des betreffenden Unternehmens identifiziert sind. Die Vorteile dieses Vorgehens liegen vor allem im Zeitgewinn – es muss schließlich nicht alles von null weg neu entwickelt werden – und zum anderen in der Vergleichbarkeit mit anderen Unternehmen. Bei gleicher Abgrenzung der einzelnen Prozesse ist eine Ausgangslage gegeben, die in weiterer Folge ein Prozessbenchmarking mit anderen Unternehmen ermöglicht. Das Process Classification Framework bietet diese Möglichkeit etwa über eine angeschlossene Benchmarkdatenbank, die Open Standards Benchmarking Database, an; ebenso das Controlling-Prozessmodell, zum dem Horváth & Partners mit dem CFO-Panel eine entsprechende Benchmarkingplattform etabliert hat.98 Demgegenüber stehen bei dieser Art der Prozessidentifikation jedoch auch klare Grenzen und Nachteile: ·

Zum Ersten bieten manche der Referenzmodelle in erster Linie standardisierte Teilprozesse an, die für ein End-to-End-Prozessverständnis erst unternehmensspezifisch zu kompletten Leistungserstellungsprozessen zusammengestellt werden müssen. 95 96 97 98

54

Siehe Becker, Kugeler, Rosemann (2008), S. 106–107. Siehe Schmelzer, Sesselmann (2010), S. 213–214. Siehe International Group of Controlling (2011). Horváth & Partners, Stuttgart, siehe z. B. www.horvath-partners.com.


·

·

Zum Zweiten hat sich auch in den Referenzmodellen vielfach eine sehr funktional und prozessgruppenorientierte Sichtweise eingeschlichen, die für eine echte Endto-End-Sichtweise nur bedingt brauchbar ist.99 Drittens liegt das Erfolgsgeheimnis von Unternehmen zu einem guten Teil ja gerade darin, neue Leistungen und Prozesse zu erfinden und neue Marktchancen zu entdecken, die es noch nicht gibt. Insofern geht mit dem Aufbauen auf Referenzmodellen auch ein Risiko zum Verlust der eigenen Innovationskraft und Differenzierung einher. Amazon, Dell oder Ikea hätten ihre spezifischen Geschäfts- und Prozessmodelle vermutlich nie entwickelt, wenn sie rein auf bestehenden Referenzprozessmodellen wie etwa dem Handels-H-Modell aufgebaut hätten. Insofern sind Referenzprozessmodelle bestenfalls für nicht wettbewerbsrelevante Teile des Geschäfts oder für Nachahmer im Sinne einer „me-too“-Strategie ein sinnvoller Weg, jedoch nur bedingt für innovative Unternehmen.100

In jedem Fall müssen die herangezogenen Referenzprozesse aber an das jeweilige Unternehmen angepasst und mit den von ihm angebotenen Leistungen abgestimmt werden. Referenzprozessmodelle können damit ein wertvoller Input sein. Ähnlich wie bei Lego können sie standardisierte Bausteine bereitstellen, bei denen bereits einige Arbeit bezüglich der genauen Prozessabgrenzung erledigt ist und die einen gute Basis für den unternehmensübergreifenden Vergleich dieser Bausteine bieten. Der Einsatz dieser Teilprozesse aus Referenzprozessmodellen als Bausteine für das eigene Prozessdesign ist dabei insbesondere auf den Ebenen zwei und drei des Prozessmodells interessant. Darüber, auf Ebene 1, und auf den detaillierteren Ebenen (Ebenen 4 und 5) ist ihr Einsatz meist weniger hilfreich, da hier die unternehmensspezifischen End-to-End-Prozesse und Detailabläufe ausgestaltet werden müssen. Als standardisierte Bausteine auf den Ebenen zwei und drei können sie jedoch für ein unternehmensübergreifendes Prozessbenchmarking eine gute Basis bieten. Referenzmodelle bieten zudem als Checklisten eine Möglichkeit, die Vollständigkeit zu überprüfen und von der Erfahrung anderer bei der Prozessidentifikation zu profitieren. Durch die Standardisierung unterstützen sie den übergreifenden Erfahrungsaustausch und bieten vielfach auch weiter gehende Details zu den umfassten Prozessen. Die Identifikation der eigenen Prozesse kann so beschleunigt und qualitativ verbessert werden. Genau wie bei Lego liegt jedoch die Kunst nicht so sehr in den einzelnen Steinen als vielmehr darin, was man daraus macht. Am Ende erfolgt die Prozessidentifikation für eine echte End-to-End-Prozesssicht damit immer indivi99 Vgl. Spanyi (2007), S. 61, der z. B. darauf verweist, dass einige Firmen die Prozessbezeichnungen des PCF als zu funktional empfinden. 100 Vgl. Schmelzer, Sesselmann (2010), S. 211. Eine gegenteilige Meinung vertreten hier etwa Hess, Osterloh (1995, S. 167): Für sie eignen sich Referenzprozesse als Blaupausen durchaus auch für wettbewerbsrelevante Prozesse.

55


Abb. 13: Nutzung von Referenzmodellen auf den verschiedenen Ebenen des Prozessmodells

duell und induktiv auf Basis der Leistungen des betreffenden Unternehmens. Referenzmodelle können dies nur unterstützen, jedoch nicht ersetzen.101 Neben diesen deduktiven Vorgehensweisen gibt es auch induktive Ansätze, die im Kern vor allem auf folgenden Argumenten aufbauen: · · · ·

dem Verständnis von Prozessdesign als kreativem Akt der subjektiven Sicht, was ein Prozess ist und wo er genau endet der Sichtweise von Prozessen als soziale Konstruktionen und dem Verständnis der Prozessidentifikation als einem iterativen Prozess

Vertreter der ersten Herangehensweise sehen die Identifikation und Definition von Prozessen als einen intellektuellen und kreativen Akt, der mit Regeln und allgemeinen Kriterien nicht beschrieben werden kann. Sie scheinen dabei beim oben zitierten Statement 101 Vgl. Schmelzer, Sesselmann (2010), S. 201–202. Ebenso Knuppertz (2009), S. 126. Vgl. auch Spanyi (2007): „you cannot buy or borrow an enterprise level process schematic if you want to develop a shared understanding of how value is created and what are the critical interdependencies of departments. You have to build it – by yourselves – although you can get some thought provoking ideas from the reference sources“ (S. 59). Ebenso Wagner (2001, S. 7), für den ebenso Prozesslandschaften immer unternehmensspezifisch gestaltet sind, da sie die Besonderheiten und Zusammenhänge des Unternehmens darstellen. Auch für Bogaschewsky, Rollberg (1998) haben Prozesse singulären Charakter und müssen daher auf induktivem Weg situationsspezifisch konstruiert werden (S. 211). Vgl. auch Hammer (1997, S. 30): Auch für ihn hat jedes Unternehmen eigene, spezielle Geschäftsprozesse.

56


von Thomas Davenport, dass Prozessmanagement noch mehr eine Kunst als eine Wissenschaft sei, anzuknüpfen und dieses als unveränderliche Notwendigkeit in die Zukunft fortzuschreiben.102 So stößt etwa auch Michael Gaitanides zumindest teilweise in dasselbe Horn, indem er die Prozessidentifikation als kreativen und innovativen Akt sieht, der von erfahrenen Mitarbeitern oder Arbeitsgruppen erbracht werden muss.103 Das Verständnis von Geschäftsprozessen als sozialer Konstruktion wird insbesondere von Christian Hiller, Peter Minar-Hödel und Hansjörg Zahradnik vertreten, für die ein Prozess ist, „was (sinnvollerweise) als Prozess konstruiert wird.“104 Grund dafür ist, dass uns Menschen der direkte Zugang zur Realität fehlt. Wir nehmen sie nur über unsere Sinnesorgane wahr und konstruieren uns auf Basis dieser Wahrnehmungen ein Bild der Wirklichkeit. Damit können und werden die Wahrnehmungen von verschiedenen Beteiligten im Prozess unterschiedlich sein. Die sinnvolle Konstruktion ergibt sich somit erst durch die strukturierte und zielgerichtete Kommunikation zwischen diesen Beteiligten, bei der am Schluss – quasi als gemeinsame Vereinbarung – die Prozessbeschreibung steht. Diese wird weniger als getreue Beschreibung der Realität aufgefasst, sondern als von allen Beteiligten akzeptierte Vereinbarung darüber, wie das Zusammenspiel im Ablauf gesehen wird. Die Konstruktion ist also eine doppelte: einmal jene individuelle Konstruktion, in der sich der einzelne Prozessbeteiligte auf Basis seiner Wahrnehmung „sein“ Prozessbild konstruiert; und im zweiten Schritt die soziale Konstruktion, in der die Beteiligten ihre Prozessbilder im Wege der Kommunikation zu einem gemeinsamen Prozessbild abstimmen. Die Identifikation von Prozessen eines Unternehmens kann damit nicht allgemeingültig vorgegeben werden, 102 Vgl. etwa Becker, Meise (2008, S. 125), die neben der „allgemeinen“ Prozessidentifikation auf Basis von allgemeinen Frameworks und Referenzmodellen der Möglichkeit einer „individuellen“ Prozessidentifikation als kreative und innovative Handlung beschreiben, die keinem fest definierten Algorithmus unterliegt, sondern im Ergebnis von der subjektiven Einschätzung der durchführenden Personen abhängig ist, und dabei explizit auf Davenports Statement referenzieren. Davenport selbst unterstützt diese Sichtweise zumindest insofern, als er keine Entwicklung konkreter Kriterien für die Prozessidentifikation anregt, sondern in Anlehnung an Harrington ein pragmatisches Vorgehen zur Identifikation der Prozesse eines Unternehmens empfiehlt: Dabei sollen die Führungskräfte einfach die Prozesse, für die sie verantwortlich sind, notieren; diese Inputs werden dann analysiert und konsolidiert, sodass man auf eine Liste von 10–20 große Prozesse kommt (S. 30). Davenport sieht die Prozessidentifikation zudem als abhängig von der verfolgten Zielsetzung (S. 28) und als iterativen Prozess (S. 30). 103 Gaitanides (2007), S. 152. 104 Hiller, Minar-Hödel, Zahradnik (2010), S. 23 und S. 67–68. Auch Gaitanides (2007) untersucht den konstruktivistischen Ansatz im Hinblick auf die Prozessorganisation (S. 99–108). Auch Scheer, der mit seinem ARIS-Konzept einen wesentlichen Beitrag zur Strukturierung und zum standardisierten methodischen Vorgehen in der Modellierung von Prozessen geleistet hat, betont, dass jede Modellbildung durch subjektgebundene Konstruktion zustande kommt und somit keine einzigartige, allein gültige Lösung besitzt. Vgl. Scheer, Thomas (2009), S. 548. Ähnliche Feststellungen treffen auch zahlreiche andere Autoren im Prozessmanagement wie etwa Staud (2001), S. 6 und S. 22–23, für den die Detaillierungsebene der Betrachtung und die Länge von Geschäftsprozessen der Subjektivität unterworfen sind.

57


sondern hängt vom inhaltlichen und sozialen Kontext ab. Damit gibt es in diesem Verständnis auch keine objektiv richtige oder falsche Festlegung der Prozesse eines Unternehmens. Es gibt streng genommen gar keine Prozesse in dieser Sichtweise, sondern nur Prozessbeschreibungen als Mittel der ablauforganisatorischen Koordination.105 Da sich die Beteiligten und deren Wahrnehmungen auch ändern können, wird die Prozessidentifikation auch als iterativer Prozess gesehen. Unter dieser Prämisse ist es nicht so wesentlich, schon im ersten Schritt eine perfekte Prozessfestlegung zu erzielen. Vielmehr genügt ein einigermaßen guter erster Wurf, der dann in der Folge im Zuge des Arbeitens mit den Prozessen verändert und verbessert werden kann. Auch Thomas Davenport vertritt diese Sichtweise und hält fest: „the identification process should be understood to be explanatory and iterative“.106 Gerade für jemanden, der als Berater sein Brot verdient, sind diese Ansichten natürlich verführerisch, festigen sie doch den Status und die Einzigartigkeit des Beraterwissens und rücken diese in unerreichbare Sphären des Talents und der jahrelangen Erfahrung anstatt einfacher, erlernbarer Logiken und Kriterien. Rational gedacht sind diese Ansätze jedoch trotz im Kern richtiger Elemente unbefriedigend und halten einer logischen Prüfung nur bedingt stand. Selbst wenn es so wäre, dass Prozesse nur durch erfahrene Experten identifiziert werden können – was angesichts der Tatsache, dass Prozessdenken immer noch sehr jung und in fundierter Form wenig verbreitet ist, durchaus seine Berechtigung haben mag –, so müssten zumindest innerhalb dieser auserwählten Gruppe erfahrener Berater die Mitglieder bei gleicher Zielsetzung und im selben sozialen Kontext zu gleichen oder zumindest sehr ähnlichen Ergebnissen kommen. Dies ist in der Realität jedoch ebenso nicht der Fall. Auch wenn erfahrene Berater die Prozesse ein und desselben Unternehmens mit denselben Beteiligten auflisteten, erhielte man dabei mit größter Wahrscheinlichkeit völlig unterschiedliche Geschäftsprozessstrukturierungen. Sicherlich ist Prozessidentifikation zu einem Teil ein kreativer Akt. Dies hängt ja alleine schon damit zusammen, dass die Art und Abfolge, wie man Leistungen erstellen kann, auf verschiedenste Art und Weise erfolgen kann. Hier neue Wege zu finden, erfordert natürlich Kreativität – das liegt im Kern erfolgreichen Unternehmertums begründet. Gleichzeitig ist Prozessidentifikation aber auch nicht nur durch Kreativität zu erklären, sondern basiert zu einem guten Teil sehr wohl auf bestimmten Erfahrungswerten und Kriterien, die zumindest implizit angewendet werden. Die Analogie zum Unternehmen hält auch hier: Obwohl die Ausgestaltung jedes einzelnen Unternehmens sehr viel mit Kreativität zu tun hat, würde kein Mensch auf die Idee kommen, deshalb die gesamte Betriebswirtschaftslehre zu verwerfen. Objektive Kriterien für Prozessidentifikation und Kreativität schließen sich nicht aus. 105 Hiller, Minar-Hödel, Zahradnik (2010), S. 67–68. 106 Davenport (1993), S. 30.

58


Schwieriger ist dies mit der subjektiven Sicht, was als Prozess zu identifizieren ist. Natürlich trifft es zu, dass wir die Realität nur über unsere Sinne wahrnehmen und uns damit Bilder schaffen, auf Basis derer wir agieren. Das Argument der Subjektivität suggeriert jedoch, dass damit jegliche Freiheitsgrade gegeben wären. Das ist aber nicht der Fall. Zeigt man unterschiedlichen Personen Farbkarten, so kann es zwar sein, dass diese die Farbtöne etwas unterschiedlich beschreiben und wahrnehmen. Je nach sozialem Kontext werden sie auch verschiedene und unterschiedlich differenzierte Begriffe dafür haben. Zeigt man ihnen jedoch jeweils zwei Karten mit exakt demselben Farbton, so werden sie diese kaum unterschiedlich beschreiben. Das subjektiv entstehende Bild hat also nicht jegliche Freiheit der Wahrnehmung, vielmehr basiert es auf objektiven Inputs, die für alle gleich sind, und der subjektiven Wahrnehmung davon.107 Letztere führt dazu, dass verschiedene Beteiligte einen Prozess etwas unterschiedlich sehen oder – und das ist der häufigere Fall – bestimmte Aspekte eines Prozesses stärker wahrnehmen als andere. Subjektivität ist damit ein Faktor, mit dem man in der Prozessidentifikation umgehen muss. Der Schluss, dass es in der Realität deshalb keinen realen Prozess gäbe oder die Beschreibung eines Prozesses beliebig wäre, wäre jedoch der falsche. Entscheidend ist hier als notwendige Ergänzung zur subjektiven Sicht, welche Prozesse ein Unternehmen hat, das Konzept der sozialen Konstruktion. Denn bliebe es bei der subjektiven Wahrnehmung, was ein Prozess ist, dann wäre Prozessmanagement im Sinne des Strukturierens, Verbesserns und Steuerns von Abläufen zur Leistungserbringung mit mehreren Beteiligten kaum möglich. Erst durch die soziale Konstruktion der identifizierten Prozesse wird Prozessmanagement zu einem effektiven Organisationselement. Dennoch gilt auch hier, dass die soziale Konstruktion eines Prozesses nicht in jeglichem Freiheitsgrad von der Realität abweichen kann. Selbst wenn sich alle Prozessbeteiligten einig sind, dass ein Produkt erst nach der Zustellung an den Kunden entwickelt wird, wird das nicht möglich sein. Selbst wenn sich Vertrieb, Marketing und Logistik einigen, dass der Prozess mit der Auslieferung beginnt und man danach erst den Auftrag erfasst und am Ende die Werbekampagne für das Produkt startet, wird dies nicht sinnvoll sein. Die Beispiele sind natürlich lächerlich, das ist klar. Sie sind bewusst lächerlich gewählt, um zu zeigen, dass die soziale Konstruktion nicht beliebig ist, sondern in der realen Welt trotz subjektiver Sichten der Beteiligten und trotz Abstimmung in der Gruppe doch zu sehr ähnlichen Ergebnissen führen muss. Was schließlich das iterative Vorgehen betrifft, so ist auch dem zuzustimmen. Natürlich ist eine Liste von identifizierten Prozessen auf oberster Ebene nichts, was für alle Ewigkeit in Stein gemeißelt ist. Und natürlich lernen alle Beteiligten dazu und werden ihre Teilprozesse nach zwei, drei Jahren Erfahrung vielleicht anders struktu107 Vgl. in diesem Zusammenhang auch die sehr interessanten Erkenntnisse der Erforschung von Gesichtsausdrücken, der zufolge es Gesichtsausdrücke gibt, die von allen Menschen global gleich interpretiert werden – also sichtlich unabhängig sind von einer starken subjektiven Wahrnehmung oder sozialen Konstruktionen. Ekman (2011).

59


rieren als am Beginn der Einführung des Prozessdenkens. Im Sinne eines zielorientierten Vorgehens ist das Bekenntnis zu einer schrittweisen Weiterentwicklung sogar ein Stück weit hilfreich, weil damit der Erstentwurf nicht absolut perfekt sein muss und man im Sinne der beliebten 80:20-Regel auch den einen oder anderen offenen Punkt in der Prozessidentifikation akzeptieren kann, ohne alle Folgeaktivitäten bis zur finalen Klärung auf Eis zu legen. Dennoch sind auch diesem wohlgemeinten Argument Grenzen gesetzt: Eine Prozessliste, die nicht schon am Beginn einen ausreichend guten Qualitätsstandard hat und einigermaßen vollständig ist, wird kaum Akzeptanz finden. Und eine zu hohe Änderungsfrequenz einer initialen Prozessidentifikation, bei der alle paar Wochen ein Prozess dazu- oder wegkommt, wird rasch an Glaubwürdigkeit verlieren. In der Praxis ist es durchaus so, dass Prozesslandschaften in Releases weiter entwickelt und verändert werden. Die Änderungen sind jedoch meist kleinere und werden maximal einmal im Jahr vorgenommen. Insofern besitzt die initiale Prozessidentifikation doch eine relativ große Stabilität. Dies hängt vor allem mit den Entscheidungswegen in Unternehmen zusammen: Was einmal über alle Ebenen freigegeben wurde, wird nicht sofort am nächsten Tag wieder in völlig geänderter Form vorgelegt. Und es hängt sicher auch ein wenig mit der beschriebenen sozialen Konstruktion zusammen: Haben sich alle Beteiligten einmal auf bestimmte identifizierte Prozesse geeinigt und diese akzeptiert, so ist es meist gar nicht leicht, dies wieder zu ändern, selbst wenn man bemerkt, dass die Prozesslandschaft offenkundige Defizite aufweist. Fassen wir zusammen: Die Frage, wie man die Prozesse eines Unternehmens konkret identifiziert, ist bisher kaum strukturiert behandelt. Es gibt keine klaren Vorgehensweisen und Kriterien, die man in der praktischen Umsetzung heranziehen könnte. Der deduktive Ansatz im Sinne einer Ableitung der Prozesse aus der Strategie ist für ein echtes End-to-End-Verständnis von Prozessen nicht anwendbar und auch sonst aus Sicht des Prozessmanagements kritisch zu sehen. Referenzmodelle können für die Teilprozesse Input geben, die Zusammenstellung zu echten End-to-End-Prozessen und die Anpassung auf das konkrete Leistungsportfolio des Unternehmens müssen jedoch individuell erfolgen. Was die induktiven Vorschläge betrifft, so sind diese kaum im Detail ausgearbeitet, bringen aber durchaus interessante Aspekte ein. Argumente der Kreativität, Subjektivität, der sozialen Konstruktion und der Iteration bedeuten jedoch nicht, dass es keinerlei Kriterien für die Identifikation geben kann oder soll. Im Folgenden soll daher versucht werden, auf Basis der erarbeiteten End-to-EndDefinition von Geschäftsprozessen ein konkreteres Vorgehen vorzuschlagen. Zu einem Gutteil liegt die Wurzel dieses Problems im Mangel an einer guten und anerkannten Prozessdefinition, wie weiter oben angemerkt. Denn da es eine Vielzahl an unterschiedlichen Definitionen von Geschäftsprozessen gibt und viele davon – wie gezeigt wurde – zudem sehr vage sind und viel Interpretationsspielraum offen lassen, darf es nicht verwunden, wenn man in der praktischen Anwendung dieser Definitio60


nen zu ganz unterschiedlichen Ergebnissen kommt. Wer Prozesse etwa als strukturierte Bündel von Aufgaben definiert oder als Aktivitäten, die einen Input in einen Output transformieren, darf sich nicht wundern, wenn darunter jeder etwas anderes versteht und die Bündel und Outputs unterschiedlich festgelegt werden. Probieren wir daher die entwickelte End-to-End-Definition von Geschäftsprozessen aus und versuchen wir mit ihrer Hilfe Prozesse zu identifizieren. Wir haben einen Geschäftsprozess definiert als die Abfolge aller notwendigen und direkt mit dem Geschäftsfall verbundenen Tätigkeiten zur Erstellung einer Leistung für einen Kunden, mit der ein bestimmter Ausgangsbedarf dieses Kunden gedeckt wird. Ansatzpunkt für die Identifikation von Geschäftsprozessen sind daher insbesondere die beiden Eckpunkte eines Prozesses: der Ausgangsbedarf und die Leistung, mit der dieser Bedarf gedeckt wird. Anders formuliert: Die Leistungen eines Unternehmens oder einer Organisation, mit der diese die Bedarfe ihrer Kunden adressieren, sind der erste Ansatzpunkt für die Identifikation der Geschäftsprozesse.108 Erbringt ein Unternehmen beispielsweise nur eine einzige, bestimmte Leistung – etwa Taxifahrten zwischen dem Flughafen und verschiedenen Zielen in einer Stadt – oder hat es nur ein einziges Produkt, das es vertreibt und damit genau einen konkreten Bedarf adressiert – etwa Holzfässer für die Weinherstellung, so hat es genau einen End-to-End-Geschäftsprozess zur Erstellung dieser Leistung oder dieses Produkts. Wir wollen hierfür auch den Begriff Leistungserstellungsprozess einführen, um diesen Zusammenhang deutlich zu machen.109 Wie ist dies, wenn ein Unternehmen mehrere Produkte oder Leistungen vertreibt? – In diesem Fall würden wir eine Vielzahl von End-to-End-Geschäftsprozessen erhalten, je erbrachter Leistung genau einen. Die Anzahl der Leistungserstellungsprozesse entspricht der Anzahl der erbrachten Leistungen. Ausgang der Prozessidentifikation ist somit das Produkt- und Leistungsportfolio eines Unternehmens. 108 Vgl. dazu Scheer (1998): Er sieht den Ausgangspunkt der Geschäftsprozessmodellierung in der strategischen Unternehmensplanung, weil dort die Produktfelder und damit die Kernprozesse der Unternehmung festgelegt werden. „Da Produkte von Prozessen erzeugt werden, legen die Produktfelder die benötigten Geschäftsprozesse fest.“ (S. 59). Ebenso Schmelzer, Sesselmann (2010, S. 122–128): Auch für sie erfolgt die tatsächliche Identifikation der Geschäftsprozesse über die Beantwortung einer Reihe von Überlegungen zum Unternehmen, die in der Frage kulminieren: „Welche Geschäftsprozesse sind notwendig, um die von den Kunden (bzw. Stakeholdern) geforderten bzw. erwarteten Leistungen bereitzustellen?“ (S. 125). Vgl. dazu auch Österle (2010/1995, S. 66), der die Prozesse aus einer Analyse des Business Network ermittelt, bei der neben den Marktteilnehmern vor allem die Bedarfe der Kunden (user) und die diese Bedarfe adressierenden Marktoutputs herangezogen werden. 109 Die Bezeichnung „Leistungserstellungsprozesse“ findet sich z. B. bereits bei Bogaschewsky, Rollberg (1998, S. 209), ohne dass die Autoren diese Bezeichnung jedoch konzeptionell weiter verfolgen. Ähnlich auch bei Wagner (2001, S. 13). Vgl. dazu auch Knuppertz (2009), der den Begriff Leistungsprozess ganz ähnlich über die konkrete Erfüllung von Kundenanforderungen definiert (S. 45–47). Auch Gaitanides (2007) spricht an einer Stelle von „Leistungserstellungs- und -verwertungsprozessen“, ebenso jedoch ohne konzeptionelle weitere Ausarbeitung der Bezeichnung (S. 113).

61


Die Identifikation, welche End-to-End-Geschäftsprozesse ein Unternehmen hat, wird damit auf Basis der entwickelten Definition für Geschäftsprozesse schon deutlich klarer. Denn die Frage „Welche Leistungen oder Produkte bietet Ihr Unternehmen an?“ ist deutlich einfacher zu beantworten als „Welche Geschäftsprozesse hat Ihr Unternehmen?“ Produktbroschüren, Leistungskataloge, der Firmenfolder oder die Homepage des Unternehmens geben darauf bereits eine erste, übersichtliche Antwort. Dennoch ist auch die Frage, welche Leistungen und Produkte ein Unternehmen hat, nicht immer ganz leicht und eindeutig zu beantworten. Denn auch hier stellen sich die Frage der richtigen Identifikation der tatsächlichen Leistungen eines Unternehmens sowie die Frage der Aggregation von Leistungsvarianten und verschiedenen Abwandlungen von Leistungen zu Leistungstypen. Bleiben wir zuerst bei der richtigen Identifikation von Leistungen und denken wir uns einen Baumarkt, der 22.000 verschiedene Produkte für Heimwerker vertreibt. – Hat dieser Baumarkt damit auch 22.000 verschiedene End-to-End-Geschäftsprozesse? Um dies festzustellen, müssen wir wieder zu den Eckpunkten der Prozessdefinition zurückkehren. Was ist der Bedarf, den der Baumarkt adressiert? – Es ist der Bedarf von Leuten, die zu Hause etwas arbeiten oder basteln, verschiedene Werkzeuge und Materialien zu beschaffen, und dies ohne auf aufwändige Weise die jeweiligen Hersteller suchen und aufsuchen, ohne selbst Experte für diese Dinge sein und ohne alles gleich in großen Mengen kaufen zu müssen. Der Baumarkt bietet alle diese Dinge an einem Platz in der Nähe der Heimwerker, er bietet Beratung an und vertreibt alles in passenden kleinen Mengen. Die Leistung des Baumarktes ist also die beratungsunterstützte Nahversorgung von Heimwerkern mit Werkzeugen und Materialien. Die notwendigen Schritte zur Erstellung dieser Leistung sind somit der erste End-to-EndGeschäftsprozess des Baumarktes. Daneben bieten viele Baumärkte aber zum Beispiel auch ein spezielles Service für Handwerker an: Sie haben für sie bereits etwas früher geöffnet, damit sie vor ihrem Start auf den Baustellen noch fehlende Dinge besorgen können, und es gibt auch oft eine spezielle Abrechnung über eigene Kundenkarten und Monatsrechnungen, damit die einzelnen Handwerker nicht mit Firmengeld herumlaufen müssen. Diese Nahversorgung für Handwerker kann als zweite Leistung des Baumarkts klar abgegrenzt werden. Eine dritte Leistung wäre eventuell der Verleih von größeren Werkzeugen gegen Gebühr, der wiederum einen eigenen Bedarf mit einer spezifischen Leistung adressiert. Trotz der Vielzahl an Artikeln im Materialstamm sind es also doch nur eine Handvoll an Leistungen, die der Baumarkt erbringt und damit eine überschaubare Anzahl von End-to-End-Prozessen. Nehmen wir als zweites Beispiel einen Maschinenbauer, der ca. 300 verschiedene Typen von Verbrennungsmotoren herstellt, und zwar für Motorräder, Rasenmäher und spezielle kleine Zugmaschinen. Hat dieses Unternehmen damit nun 300 Geschäftsprozesse. Strenggenommen wäre dies so, da jeder Motor ja einen ganz spezifischen Bedarf adressiert. Tatsächlich lassen sich diese Bedarfe jedoch zu allgemeinen, 62


aggregierten Bedarfen zusammenfassen. Dies ist deshalb zulässig, weil die Kunden des Unternehmens vielfach einen Bedarf nach einer bestimmten Art Motor haben – eben zum Beispiel einem Rasenmähermotor – und erst in weiterer Folge diesen Bedarf so genau spezifizieren und detaillieren, dass innerhalb des Sortiments die genaue Type bestimmt werden kann. Meist handelt es sich bei Unternehmen mit sehr vielen Produkten bei diesen um geringfügig unterschiedliche Varianten ein und desselben Produkts die einen gemeinsamen allgemeinen Bedarf in unterschiedlicher Detailausprägung erfüllen, sodass sie für die Zwecke der Prozessidentifikation in Produktoder Leistungsgruppen zusammengefasst werden können. So kann etwa das beispielhafte Maschinenbauunternehmen durchaus 300 verschiedene Motoren im Portfolio haben. Es deckt damit aber aggregiert betrachtet dennoch nur den Bedarf nach einigen wenigen Arten von Maschinen ab, die zusammengefasst werden können: etwa Standardmotoren für Kleinmotorräder, für Sportmotorräder, für Rasenmäher und für kleine Zugmaschinen sowie kundenindividuell entwickelte Spezialmotoren. Kritiker mögen nun einwenden, dass sich das Problem der Identifikation von Geschäftsprozessen damit nur auf die Identifikation von Leistungen verlagert, ohne dadurch gelöst zu werden.110 Dies ist von der Theorie her auch durchaus zutreffend. In der Praxis ist es jedoch aus der Erfahrung heraus wesentlich leichter, mit Unternehmen ein einheitliches Verständnis über die Produkte und Leistungen eines Unternehmens herzustellen, als dies bei einem direkten Einstieg in die dahinter liegenden Prozesse der Fall ist. Produkte und Leistungen sowie die damit adressierten Bedarfe sind etwas, was den meisten Managern und Mitarbeitern in Unternehmen klarer bewusst ist und wo es weniger abweichende Auffassungen gibt. Insofern bietet dieser Zugang klare Vorteile; auch wenn das Problem der Identifikation und Aggregation damit nicht restlos gelöst wird, so wird es über den Weg der Leistungen an die Kunden doch handhabbarer und führt zu weniger Divergenzen als bei der direkten Frage nach der Auflistung von Prozessen. Zum Zweiten ist diese Zusammenfassung auch deshalb sinnvoll, weil Prozessmanagement als Organisationselement ja zur Strukturierung im Unternehmen und zum Managen der Komplexität beitragen soll. Würde jeder einzelne Motorentyp als Geschäftsprozess definiert, so könnte es diese Aufgabe der Komplexitätsreduktion nicht erfüllen. Dies zeigt sich insbesondere im Geschäftsprozessmodell, das die Basis für das Arbeiten mit Prozessen bildet. Solche Prozessmodelle dienen – wie Modelle ganz allgemein – der Reduktion der Komplexität, um Sachverhalte besser verstehen, kommunizieren und steuern zu können. Wenn wir uns ein Unternehmen mit 300 verschiedenen Leistungen oder Produkten vorstellen, so würde ein Unternehmensprozessmodell mit 300 verschiedenen Leistungserstellungsprozessen wenig hilfreich sein, zumal jeder dieser Prozesse ja weiter in Teilprozesse detailliert wird und sich die Anzahl der 110 Vgl. dazu auch die Kritik von Staud (2001, S. 23) am Vorschlag von Becker und Vossen zur Identifikation von Geschäftsprozessen anhand betriebswirtschaftlich relevanter Objekte.

63


einzelnen Prozessmodelle damit potenziert. Insofern führt auch das Bestreben nach Komplexitätsreduktion dazu, Produkte und Leistungen zu ähnlichen Produktgruppen und Leistungsarten zusammenzufassen. Ein Unternehmen das 300 verschiedene Typen von Elektromotoren herstellt, wird daher versuchen die dahinter liegenden 300 Leistungserstellungsprozesse zu aus Prozesssicht ähnlichen Gruppen zu aggregieren. Das Ausmaß der möglichen Aggregation hängt dabei von der Ebene des Prozessmodells ab: auf der obersten Ebene, wo es vor allem um das grundlegende integrative Prozessverständnis geht, kann die Unterscheidung von wenigen Produktgruppen ausreichen; auf detaillierteren Ebenen des Prozessmodells, auf denen es zum Beispiel um detaillierte Verfahrensanweisungen für die einzelnen Varianten geht, wird eine detailliertere Unterscheidung notwendig sein. Hierarchische Prozessmodelle bieten dafür die Möglichkeit, auf oberster Ebene gemeinsame und aggregierte Prozesse nach wenigen Typen zu definieren und diese dann auf den unteren Detaillierungsebenen weiter in verschiedene Varianten aufzugliedern. Der Ansatzpunkt für die Identifikation der End-to-End-Geschäftsprozesse sind also die unterschiedlichen Leistungen, die ein Unternehmen oder eine Organisation erbringt.111 Auch dieser Ansatz lässt nach wie vor einen gewissen Spielraum. Im Gegensatz zum eingangs zitierten Verständnis der Prozessidentifikation als einer Kunst von wenigen Experten gibt es jedoch deutlich mehr an Richtlinien für die Identifikation von Geschäftsprozessen: ·

Prinzipiell gibt es je erstelltem Produkt bzw. je erbrachter Leistung, mit der ein bestimmter, abgrenzbarer Kundenbedarf adressiert wird, einen Leistungserstellungsprozess Bedarfe und Leistungen können bei einer Vielzahl an Produkten und Leistungen zu allgemeineren, aggregierten Bedarfs- und Leistungs- bzw. Produktgruppen zusammengefasst werden, sofern diese Aggregation aus Kundensicht argumentierbar ist und der Komplexitätsreduktion des Prozessmodells dient.

·

111 Vgl. dazu Schmelzer, Sesselmann (2010), die ebenfalls Bedürfnisse und Produkte/Leistungen als wichtige Inputs für die Identifikation der Prozesse sehen (S. 125); ähnlich auch Wagner (2001, S. 5): Im Zusammenhang mit prozessorientierten Qualitätsmanagementsystemen stellt er fest, dass sich ausgehend von den an die Kunden gelieferten Produkten und erbrachten Dienstleistungen die Frage stellt, welche Aktivitäten hierfür erforderlich sind, und dass diese Frage damit zu den Prozessen eines Unternehmens führt. Bogaschewsky, Rollberg (1998, S. 212) verweisen darauf, dass identifizierte Prozesse einen „inhaltlich abgeschlossenen Erfüllungsvorgang“ darstellen sollen, sehen diesen jedoch als subjektiv bedingt – wendet man hier jedoch die Sichtweise aus dem Blickwinkel des Kunden an, so verschwindet diese Subjektivität und man gelangt zu einer End-to-End-Sichtweise. Vgl. auch Österle (2010/1995, S. 78), dessen Ansatz eine detaillierte Analyse der Outputs hinsichtlich der Prozesskunden und möglicher Mitbewerber umfasst und damit stärker dem hier verwendeten Leistungskonzept als dem sonst meist sehr technischen Output-Begriff entspricht. Österles Ansatz untersucht die Outputs auch anhand von Quality Profiles (S. 81–85), wobei sie auf Komponenten, aus denen sie bestehen sowie hinsichtlich wichtiger Kriterien (characteristics), deren Bedeutung für die Prozesskunden und den Vergleich zu den Outputs der relevanten Mitbewerber untersucht werden.

64


Abb. 14: Geschäftsfälle als Ausgangspunkt der Prozessidentifikation (1)

Leistungen und Produkte von Unternehmen sind meist sehr klar umrissen und unterliegen damit in der Praxis einem geringeren Interpretationsspielraum als eine unmittelbare Frage nach den Geschäftsprozessen. Der Weg zur Identifikation der Geschäftsprozesse eines Unternehmens oder einer Organisation führt daher bei der Anwendung eines End-to-End-Prozessverständnisses, wie es oben entwickelt wurde, über die Identifikation von deren Leistungen an externe Kunden, also über den Leistungskatalog. Da die Leistungen je Unternehmen und Organisation sehr verschieden sind, können sie nur individuell erhoben werden. Es muss hierfür direkt auf die erbrachten Kundenleistungen zurückgegriffen werden. Eine Identifikation der End-toEnd-Geschäftsprozesse eines Unternehmens auf oberster Ebene ist somit nur induktiv möglich.112 Geschäftsprozesse basieren auf den Leistungen, die für externe Kunden erbracht werden. Da sie vom Kundenbedarf ausgehen und alle notwendigen Schritte bis zur Deckung dieses Bedarfs durch die erbrachte Leistung umfassen, orientieren sie sich an der Abwicklung eines Geschäftsfalls.113 Das heißt, dass wirklich für jeden konkreten Fall eines Kundenbedarfs die Teile eines Geschäftsprozesses vom Kundenbedarf bis zur Leistung an den Kunden durchlaufen werden.114 Dieser Geschäftsfall kann in einem Unternehmen eine Anfrage sein, die vom ersten Kontakt über die Lieferung des Produkts oder die Erbringung einer Leistung bis hin zum Erhalt der Zahlung und aller notwendigen Schritte zur korrekten buchhalte112 Siehe Gaitanides (2007), S. 152. Für Bogaschewsky, Rollberg (1998, S. 211) müssen Prozesse auf induktivem Weg situationsspezifisch konstruiert werden und haben prinzipiell singulären Charakter. 113 Vgl. dazu Österle (2010/1995, S. 87), der vorschlägt, bei der Erhebung der Process Flows mit den Outputs zu starten und von dort Rückwärts die Aktivitäten aufzulisten, die gemeinsam diesen Output erstellen. 114 Eine echte End-to-End-Prozesssicht sieht Prozesse daher immer vom Kunden zum Kunden. Davon abweichend definieren manche Ansätze Prozesse vom Lieferanten zum Kunden. Vgl. dafür etwa Osterloh, Frost (2000), S. 37 oder auch die SIPOC Methode.

65


Abb. 15: Geschäftsfälle als Ausgangspunkt der Prozessidentifikation (2)

rischen Verbuchung dieses Geschäftsvorfalls geht. Er kann ein Akt sein, der vom eingehenden Antrag eines Bürgers über die verschiedenen Prüfungs- und Bewilligungsstufen bis hin zur Ausstellung eines Dokuments reicht, inklusive der Ablage und Archivierung des betreffenden Aktes am Ende und dem Kassieren der angefallenen Gebühren. Er kann genauso ein Darlehen sein, das von einem Bankkunden in seiner Filiale beim Kundenbetreuer angefragt wird und über die vorgegebenen standardisierten Schritte der Kreditvergabe bis hin zur Überweisung des Geldes und der Rückführung des Betrages am Ende der Kreditlaufzeit geht. Anders als bei einer problem- oder einer zielorientierten Prozessidentifikation umfasst diese leistungsorientierte Prozessidentifikation alle notwendigen Prozessschritte zur Erstellung und Erbringung einer Leistung unabhängig von einem aktuell zu lösenden Problem oder einem speziellen Projektvorhaben. Denn bei Ersteren werden Prozesse anhand einer bestimmten Problemstellung oder einer konkreten Zielsetzung für die Optimierung identifiziert, etwa zur Einführung eines neuen ERP-Systems oder zur Reduktion des gebundenen Kapitals. Dabei besteht die Gefahr, dass Teilprozesse, die für das betreffende Problem oder für die konkrete Zielsetzung nicht relevant sind, weggelassen werden. Der Prozess bleibt damit unvollständig, und Teile der Leistungserstellung werden aus der Betrachtung ausgegrenzt.115 Die leistungsorientierte Prozessidentifikation stellt sicher, dass alle notwendigen Teilprozesse zur Leistungserstellung identifiziert werden. Dies schließt jedoch nicht aus, dass eine spätere, darauf aufbauende Optimierung sich vor allem auf bestimmte Teilprozesse konzentriert oder die einzelnen Teilprozesse in unterschiedlichen Detailierungsgraden analysiert. Ein Beispiel hierfür wäre etwa eine Prozessoptimierung aus dem Gesichtspunkt der Optimierung der Kapitalbindung (working capital optimization), die vor allem auf jene Teilprozesse eingehen wird, die für die bessere Planung von Beständen oder die Reduktion der dafür kritischen Durchlaufzeiten wichtig sind. 115 Vgl. Bogaschewsky, Rollberg (1998, S. 216–217), die beide Vorgehensweisen, die problemorientierte und die zielorientierte Prozessidentifikation beschreiben und auch auf dieses Problem hinweisen, jedoch keine Lösung anbieten.

66


Werden die End-to-End-Geschäftsprozesse eines Unternehmens oder einer Organisation anhand der Leistungen identifiziert, so müssen mit diesen Prozessen die wesentlichen Geschäftsfälle des Unternehmens vollständig darstellbar sein. Die Endto-End-Prozesse enthalten hierbei alle notwendigen Teilprozesse, die zur Leistungserstellung notwendig sind und direkt mit den jeweiligen Geschäftsfällen verbunden sind. Wie bereits bei der Entwicklung der End-to-End-Definition von Geschäftsprozessen festgehalten wurde, zählen dazu nicht nur die üblichen Teilprozesse des Verkaufens, der Lieferung und der Verrechnung einer Leistung oder eines Produkts. Ergänzend zu diesen klassischen Teilprozessen umfasst ein echter End-to-End-Prozess auch die vorgelagerte Entwicklung des Produkts sowie eine eventuell vorausgehende Absatzplanung und Fertigung auf Lager. Ebenso zählen alle direkt für das Produkt oder die Leistung notwendigen Beschaffungen zum End-to-End-Prozess. Und am Ende umfasst er auch alle Schritte zur Verfolgung und Abwicklung des Zahlungseingangs sowie die debitorische, kostenrechnerische und steuerliche Verbuchung des Geschäftsfalls. Damit deckt ein End-to-End-Leistungserstellungsprozess alle für die Erbringung der Leistung notwendigen Schritte ab. Erst damit können alle weitergehenden Analysen und Optimierungen im Zuge des Prozessmanagements den Prozess in seiner Gesamtheit betrachten und so auch die klassischen Schnittstellenprobleme adressieren, wie sie in der Praxis häufig bestehen:116 ·

·

· ·

Etwa zwischen der Produktentwicklung, die bestimmte Produkteigenschaften festlegt, die später in der Lieferung oder Wartung des Produkts Probleme verursachen Zwischen dem Verkaufen von Leistungen und der späteren Lieferung oder Erbringung im Hinblick auf das klassische Dilemma zwischen Vertrieb und Produktion Zwischen Beschaffung und Produktion oder Montage, wo es ebenfalls häufig zu Schnittstellenproblemen kommt Schließlich zwischen der Auftragsabwicklung und der Buchhaltung, wo nicht oder falsch abgeschlossene Aufträge oft viel an administrativer Folgearbeit nach sich ziehen.

Zur Veranschaulichung, warum diese Teilprozesse ebenso Teil des gesamten End-toEnd-Prozesses sind, kann man sich dazu einen „Urprozess“ vorstellen, bei dem erst nach dem Bekanntwerden eines Kundenbedarfs das Produkt entwickelt und gefertigt wird. Dass in heutigen Prozessen die Produktentwicklung und die Fertigung im Sinne einer Lagerfertigung bereits oft vorangestellt sind, sind bereits erfolgte Optimierungen des gesamten End-to-End-Prozesses, durch die versucht wird, diese Teilprozesse im 116 Vgl. Rummler, Remias, Rummler (2010), die in diesem Zusammenhang vom „white space“ zwischen den Funktionen und funktionalen Teilprozessen sprechen (S. 66).

67


zeitlichen Ablauf ein Stück weit zu entkoppeln und die Schnittstellen so weniger anfällig zu gestalten. Da wir bereits mit diesen optimierten Prozessen aufgewachsen sind, ist uns dies jedoch vielfach nicht mehr bewusst. 2.3.2 Bereitstellungsprozesse

Neben den Prozessen zur Leistungserstellung gibt es in den Unternehmen jedoch auch weitere Prozesse, die notwendig sind, aber nicht unmittelbar und direkt mit Geschäftsfällen der externen Kunden zusammenhängen. Es sind dies zum einen Steuerungsprozesse, die für die Lenkung von Unternehmen und Organisationen erforderlich sind; zum anderen sind dies Prozesse, die allgemeine interne Leistungen bereitstellen, die nicht spezifisch für die konkreten Geschäftsfälle, sondern allgemein notwendig sind.117 Wird zum Beispiel für ein Produkt etwas zugekauft, so ist es Teil des betreffenden Geschäftsprozesses. Alle spezifisch für dieses Produkt notwendigen internen erbrachten oder extern beschafften Teilleistungen sind hier enthalten. Über diese direkten Teilleistungen hinaus gibt es jedoch auch eine Vielzahl an internen Leistungen, die nicht spezifisch mit dem Geschäftsfall verbunden sind, sondern als notwendige Rahmenbedingungen erforderlich sind und an zahlreichen oder allen Stellen im Geschäftsprozess benötigt werden. Hierzu einige Beispiele: ·

Ein Vertriebsmitarbeiter braucht für seine Arbeit ein Notebook, einen Blackberry sowie ein CRM-System. Diese benötigt er nicht als Teil der erbrachten Leistung und an einer speziellen Stelle im Geschäftsprozess. Vielmehr braucht er diese Dinge in vielen, vermutlich fast allen Teilprozessen und Prozessschritten zur Erfüllung seiner Arbeit. Sie sind somit nicht direkt, sondern indirekt notwendig für die Erbringung der Leistung an den Kunden. Ein Maschinenbauer hat für die Servicierung seiner an die Kunden verkauften Maschinen Vertriebsstandorte in verschiedenen Städten. Diese Büroinfrastruktur, die Büroeinrichtung, Mineralwasser und Kaffee in der Mitarbeiterküche sowie das Toilettenpapier auf den WCs sind nicht direkt für die Durchführung von Ser-

·

117 Vgl. dazu auch EABPM (2009), S. 47: Für die EABPM stellen Unterstützungsprozesse „die nötigen Ressourcen und die Infrastruktur für die Ausführungsprozesse bereit.“ Vgl. ebenso Osterloh, Frost (2000), die bei einer geringen Leistungsverflechtung zwischen Kern- und Supportprozessen letztere als eigenständige Leistung separierbar sehen (S. 36, ebenso S. 98). In der weitverbreiteten Konzeption von Supportprozessen im Sinne einer Bündelung von übergreifenden Teilprozessen, die nicht Kerngeschäft sind, entspricht dies einer indirekten Leistungsbeziehung. Eine direkte Leistungsbeziehung zwischen einem Kernprozess und einem Supportprozess, die auf der Prozessstrukturebene identifizierbar und modellierbar ist, wäre im hier entwickelten End-to-End-Verständnis hingegen eine Leistungsbeziehung zwischen zwei Teilprozessen einund desselben Leistungserstellungsprozesses, da Leistungen, die den Geschäftsfällen direkt zugeordnet werden können, nicht in Supportprozesse ausgelagert werden, sondern Teil des Leistungserstellungsprozesses sind, um die volle End-to-End-Integration zu erzielen. Vgl. dazu Speck, Schnetgöke (2008), S. 195–196.

68


Abb. 16: Typische Bereitstellungsprozesse

·

vicegeschäftsfällen notwendig. Sie bilden vielmehr indirekte Rahmenbedingungen innerhalb derer die Serviceprozesse durchgeführt werden. Eine Behörde braucht für die Erbringung ihrer Leistungen für die Bürger Mitarbeiter mit bestimmten Qualifikationen, z. B. mit verschiedenen speziellen Verwaltungsschulungen. Dass Mitarbeiter mit diesen Qualifikationen in ausreichendem Umfang und in der notwendigen Qualifikation zur Verfügung stehen, ist nicht direkt mit der Erstellung einer bestimmten Bewilligung oder eines bestimmten Bescheides für einen bestimmten Akt verbunden. Vielmehr ist dies eine indirekte generelle Rahmenbedingung, die geschaffen werden muss, damit die Leistungserstellungsprozesse generell erfüllt und damit die Leistungen an die Bürger erbracht werden können

Für diese Prozesse soll die Bezeichnung „Bereitstellungsprozesse“118 eingeführt werden. Bereitstellungsprozesse sind also Geschäftsprozesse, die einen internen Kunden haben. Sie stellen interne Leistungen bereit, die nicht direkt Teil der erbrachten Kundenleistung sind und den Leistungserstellungsprozessen nicht an einer bestimmten Stelle zugeordnet werden können. Vielmehr sind ihre Ergebnisse generelle Leistungen, die für die Durchführung aller Geschäftsprozesse erforderlich sind und quasi als Rahmenbedingung erfüllt sein müssen. Hierunter fallen zum Beispiel: · · · ·

Die Bereitstellung von Finanzmitteln in ausreichendem Umfang Die Bereitstellung von Personal im notwendigen Umfang und Qualifikation Die Bereitstellung von Gebäuden und Anlagen Die Bereitstellung von IT-Infrastruktur und Systemen mit entsprechender Verfügbarkeit und Funktionalität

118 Bogaschewsky, Rollberg (1998, S. 209) sprechen etwa im Zusammenhang mit allgemeinen Rahmenprozessen davon, dass es Geschäftsprozesse gibt, die die unternehmensinternen Voraussetzungen schaffen und nennen dafür als Beispiel etwa „geeignete Mitarbeiter, Anlagen und Gebäude [. . .] bereitzustellen [. . .] und zu finanzieren.“ Rummler, Remias, Rummler (2010) verwenden hierfür den Begriff der „contributing processes“ (S. 57), um herauszustreichen, dass es sich bei diesen Prozessen nicht um „second-class citizens“, sondern um wichtige Beiträge zum gesamten Value Creation System handelt, wobei sich ihr Beitrag eben nicht direkt an die externen Kunden, sondern an die primären Prozesse richtet.

69


Abb. 17: Bereitstellungsprozesse und ihre internen Leistungen

·

Die Bereitstellung von zugekauften Services und Waren, die nicht direkt für die Erstellung der Leistung an einer bestimmten Stelle im Prozess benötigt werden Die Bereitstellung von rechtlicher Expertise Die Bereitstellung von generellen Marketing- und PR-Mitteln und Kanälen

· ·

Aus Sicht der Leistungserstellungsprozesse handelt es sich bei diesen internen Leistungen um Kosten, die nicht direkt von der Anzahl ihrer Geschäftsfälle abhängig sind. Das heißt, die Kosten für diese Leistungen fallen innerhalb einer geplanten Periode in jedem Fall an, egal ob in den Leistungserstellungsprozessen viele oder wenige Geschäftsfälle abgewickelt werden. Für die Leistungserstellungsprozesse sind die durch die Bereitstellungsprozesse anfallenden Kosten daher Gemeinkosten, die nicht direkt auf die Produkte und Leistungen als Kostenträger zuordenbar sind. Auch die Bereitstellungprozesse werden grundsätzlich induktiv erhoben. Da der Großteil dieser generellen intern notwendigen Leistungen jedoch zwischen den Unternehmen und Organisationen nicht so stark variieren wird wie bei den Leistungserstellungsprozessen, kann man sich hier durchaus an Referenzmodellen orientieren.119 Die obige Darstellung gibt eine Übersicht über typische Bereitstellungprozesse. In Übereinstimmung mit der festgelegten Prozessdefinition, definieren sich auch die Bereitstellungsprozesse über die erbrachten Leistungen.120 Es handelt sich hierbei jedoch nicht um Leistungen an externe Kunden, sondern um Leistungen für interne Kunden. Auch für diese gilt, dass die internen Kunden grundsätzlich bereit sein müssen, für diese Leistungen etwas zu bezahlen, auch wenn dies in den internen Verrechnungssystemen nicht immer genau so abgebildet ist. In der Praxis erfolgt die Verrechnung dieser internen Leistungen vielfach noch über eine Schlüsselung der Gemeinkosten, ohne dass dabei verschiedene Prozessvarianten 119 Vgl. auch Hess, Osterloh (1995, S. 167): Sie sehen das wichtigste Einsatzfeld von Referenzprozessen im nichtkompetitiven Bereich der Prozesslandschaft. 120 Vgl. Gaitanides (2007): Für ihn besteht das Prozessmodell eines Unternehmens aus den kundenorientierten Kernleistungen und den sie unterstützenden Supportleistungen (S. 152).

70


für die einzelnen internen Kunden unterschieden werden. Gerade diese pauschale Verteilung führt vielfach zu Unzufriedenheit bei den Verantwortlichen für die Leistungserstellungsprozesse, da sie für diese, die meist eine marktseitige Ergebnisverantwortung tragen, kaum planbar, nicht transparent und damit auch nur schwer steuerbar sind. Das Verständnis der Bereitstellungsprozesse als interne End-to-End-Prozesse, die ebenfalls durch den Bedarf und die Leistung bestimmt sind, ermöglicht es, auch in der internen Zusammenarbeit eine entsprechende Kundenorientierung und ein bestimmtes Auftraggeber-/Auftragnehmerverhältnis zu etablieren.121 Dies erfolgt zum einen über die explizite Definition und Vereinbarung der erbrachten Leistungen. Ähnlich wie für die Geschäftsprozesse die Leistungen an die externen Kunden der Ausgangspunkt für die Prozessidentifikation waren, sind es für die Bereitstellungsprozesse die internen Leistungskataloge der Serviceeinheiten. Über die Anwendung der entwickelten End-to-End-Prozessdefinition können auch für diese internen Leistungsbeziehungen die Leistungen klar definiert und vereinbart sowie mit den dahinter liegenden Erstellungsprozessen verknüpft werden. Damit entsteht für die Bereitstellungsleistungen eine Deckungsgleichheit zwischen den internen Leistungsvereinbarungen in Form von Service Level Agreements und den dahinter liegenden Prozessen zur Erstellung dieser internen Leistungen.122 Über die eindeutige Verknüpfung mit den dahinter liegenden Prozessen zur Leistungserstellung und das Instrument der Prozesskostenrechnung können diese internen Leistungen zudem sauber kalkuliert, bei Bedarf auch nach Varianten unterschieden und bezüglich des Ressourcenverbrauchs transparent gemacht werden.123 2.3.3 Steuerungsprozesse

Auch bei den Steuerungsprozessen gilt prinzipiell, dass diese induktiv erhoben werden. Schließlich ist auch die Steuerung des Unternehmens etwas, was je nach Unternehmen individuell ausgestaltet sein kann. Dennoch gibt es auch hier auf Basis des etablierten Managementverständnisses Referenzprozesse, die für viele Unternehmen und Organisationen in gleicher oder ähnlicher Form in einem gewissen Ausmaß zutreffen. Denn kurz zusammengefasst geht es bei den Steuerungsprozessen darum, ein 121 Vgl. Schmelzer, Sesselmann (2010), S. 81. 122 Neben diesen Service Level Agreements für reine Bereitstellungsprozesse gibt es jedoch auch noch die Möglichkeit, dass Teile der Leistungserstellungsprozesse von anderen, teilweise funktional organisierten Einheiten erbracht werden. 123 Vgl. dazu Mayer (1996), S. 62–63, der den Grund für die Beschäftigung mit derartigen Prozessen, die in keinem unmittelbaren Zusammenhang zum operativen Geschäft stehen, v. a. darin sieht, „sie zu benchmarken, zu optimieren, als Leistungen zu verrechnen oder über Standards in die Budgetplanung einzubeziehen“. Insbesondere durch die prozesskostenorientierte Budgetplanung wird es möglich kosten- und mengenmäßige Änderungen sauber auseinanderzuhalten und über das zugrunde gelegte Mengen- und Preisgerüst die Planung in den Gemeinkostenbereichen zu versachlichen (S. 66).

71


Ziel zu haben und zur Erreichung dieses Ziels Ressourcen, Mitarbeiter, Geschäftspartner und andere Parameter so zu steuern, dass das Ziel des Unternehmens oder der Organisation erreicht wird.124 Dazu ist zum einen ein ergebnisorientierter Steuerungsprozess erforderlich. In diesem wird zuerst das Ziel genau definiert und eine Strategie zu seiner Erreichung entwickelt. Ist die Strategie definiert, so muss sie auf handhabbare Phasen herunter gebrochen werden, was meistens entlang der Periode des Geschäftsjahres mittels Mittelfristplänen und Jahresbudgets passiert. Hierbei werden auch die notwendigen Ressourcen geplant, die dann auch zur Aufgabenerfüllung, zur besseren Steuerung und zur Koordination in ihrem Zusammenspiel organisiert werden müssen. Dies betrifft sowohl ihre hierarchische Organisation als auch die Planung und das Design der Geschäftsprozesse.125 Auf Basis der definierten Budgets werden den wesentlichen Beteiligten – Bereichen oder auch Managern und Mitarbeitern – Ziele gesetzt, die erreicht werden sollen. Die Erreichung dieser Ziele auf Bereichs- und auch auf Mitarbeiterebene – also die Performance – wird in regelmäßigen Abständen überprüft.126 Zeigt diese Überprüfung, dass die Teilziele der Perioden (z. B. Monate oder Quartale) erreicht werden, läuft alles nach Plan. Werden die Teilziele nicht erreicht, so müssen Maßnahmen gesetzt und Anpassungen vorgenommen werden. Hierbei kann es sich um kleinere Korrekturen, um Anpassungen in geringem Umfang oder auch um größere Anpassungen handeln, die nur im Rahmen von speziellen Projekten umgesetzt werden können. Auch für diese Maßnahmen muss die Umsetzung und vor allem ihre Effektivität hinsichtlich der Erreichung der ursprünglichen Ziele wieder überprüft werden. Werden die Teilziele damit erreicht, läuft wieder alles nach Plan. Werden sie nicht erreicht, sind neue Maßnahmen oder eine Anpassung der Phasen zur Erreichung des Ziels notwendig. In jedem Fall gehört es zum Prozess des Managements, die Lehren (lessons learned) aus den gesetzten Maßnahmen und dem Ausmaß ihres Erfolgs oder Misserfolgs zu ziehen. Bei erfolgreichen Maßnahmen gehört es weiters zum Steuerungsprozess, dass diese erfolgreiche Maßnahmen und Rezepte im Wissen des Unternehmens oder der Institution verankert und – falls möglich – auf andere Bereiche oder Segmente transferiert werden. Neben der Reaktion auf Abweichungen vom geplanten Erfolg dient dieser Teil 124 Vgl. sehr ähnlich auch die Definition der EABPM (2009), S. 47: Für sie dienen Führungsprozesse „der Planung, Diagnose und Steuerung von Ausführungs- und Unterstützungsprozessen, sodass diese ihre betrieblichen, finanziellen und gesetzlichen Ziele erreichen“. Ähnlich auch Wagner, Patzak (2007, S. 65), für die die Aspekte der Willensbildung und Willensdurchsetzung v. a. in den Bereichen Planung, Zielsetzung, Führung, Mittelbereitstellung, Mitteldisposition, Controlling und Optimierung in den Managementprozessen zu berücksichtigen sind. Vgl. auch Nicolai (2009, S. 19): Sie zählt zur Managementfunktion die Bereiche Planung, Organisieren, Personaleinsatz, Führung und Kontrolle. 125 Im Rahmen der Steuerungsprozesse wird hier der funktionale Organisationsbegriff integriert, also die Tätigkeit des Organisierens (vgl. Klimmer 2007, S. 2 ff., bzw. Mangler 2006, S. 3 f.). 126 Vgl. dazu das Konzept des New Controlling von Peter Horváth, nach dem auch das Controlling prozessorientiert organisiert werden soll. Horváth (2009), S. 952.

72


Abb. 18: Referenzmodell eines ergebnisorientierten Managementprozesses

des Prozesses mit dem Setzen und Durchführen von Maßnahmen, deren Effektivitätskontrolle und dem Transfer der Erfahrungen analog auch der Strategieumsetzung. Die klassischen Bereiche der strategischen Steuerung und der operativen Steuerung sind in diesem ergebnisorientierten Steuerungsprozess damit entsprechend verknüpft, um die vielfach in der Praxis nicht ausreichend gegebene Integration beider Bereiche zu gewährleisten. Als Zweites ist neben dem ergebnisorientierten auch ein normativer Steuerungsprozess erforderlich, der die Einhaltung von für den Erfolg direkt oder indirekt notwendigen Regeln sicherstellt. In diesem Prozess müssen zu Beginn Regelungen erarbeitet, das heißt konzipiert, abgestimmt und beschlossen werden. Die erarbeiteten Regelungen werden in der Folge kommuniziert und geschult. Die Einhaltung der Regeln muss dann in den jeweiligen Leistungserstellungs- und Bereitstellungsprozessen erfolgen. Zur Kontrolle, ob dies auch in ausreichendem Maß der Fall ist, wird die Einhaltung der Regeln überprüft, zum Beispiel durch laufende Routinen, durch Stichprobentests oder durch spezielle Audits. Aus den Ergebnissen dieser Überprüfungen müssen wiederum Lehren gezogen werden, die zum Beispiel zu einer Überarbeitung der Regelungen,

Abb. 19: Referenzprozess für einen normativen Steuerungsprozess

73


Abb. 20: Interne Leistungen des ergebnisorientierten Steuerungsprozesses

einer nochmaligen oder anderen Kommunikation oder Schulung derselben oder auch einer Anpassung der Überprüfungsroutinen führen kann. Der Inhalt der Regelungen selbst kann dabei extern bestimmt sein, zum Beispiel zur Sicherstellung der Einhaltung von gesetzlichen oder verwaltungstechnischen Regelungen (z. B. HSEQ-Vorschriften, Sicherheitsnormen, Arbeitszeitbestimmungen, spezielle Branchennormen, . . .); es kann sich aber auch um intern motivierte Inhalte handeln, die das Unternehmen oder die Institution aus reinem Eigeninteresse für notwendig befindet (z. B. Unterschriftenregelung, Freigaberichtlinien für Bestellungen, Qualitätsrichtlinien, Reiserichtlinien, . . .). Werden im Unternehmen bestimmte Prozessnormen aus normativen Gesichtspunkten verbindlich angewendet (z. B. CMMI oder Spice), so fallen auch diese hierunter. Der normative Steuerungsprozess deckt damit die Komponente der Compliance oder Corporate Governance ab.127 Auch diese Steuerungsprozesse definieren sich über ihr Prozessergebnis. Wie schon bei den Bereitstellungsprozessen handelt es sich aber auch hier nicht um eine externe Leistung an einen Kunden, sondern um eine interne Leistung an die übrigen Geschäftsprozesse. Der ergebnisorientierte Steuerungsprozess stellt als Leistung eine 127 Vgl. dazu Schmelzer, Sesselmann (2010): Sie definieren Process Governance als „die unternehmensweit gültigen Regeln, Vorschriften, Werte und Grundsätze der Führung, Organisation und Überwachung der Geschäftsprozesse bzw. des Geschäftsprozessmanagements“ (S. 38); vgl. auch Weilkiens, Weiss, Grass (2010), die die unterschiedlichen Arten von Normen (extern, selbst auferlegt, . . .) unterscheiden und definieren (S. 145–147).

74


Abb. 21: Interne Leistungen des normativen Steuerungsprozesses

funktionierende Unternehmenssteuerung zur Verfügung. Auf der Ebene der Teilprozesse besteht diese etwa aus der Vision und Mission des Unternehmens, der Strategie zur Erreichung dieses Zieles, der Mittelfrist- und Jahresplanung, Berichten und Abweichungsanalysen zur Zielerreichung128, umgesetzten Anpassungsmaßnahmen, Nachprüfungen der Wirksamkeit solcher Maßnahmen sowie dem Aufbau und Transfer von entwickeltem Wissen. Der normative Steuerungsprozess stellt als Leistung hingegen die Compliance im Sinne einer effektiven Regelung aller intern und extern geforderten Sachverhalte sicher. Auf Ebene der Teilprozesse umfasst dies eine klare Übersicht über die zu regelnden Themen, verabschiedete Unternehmensrichtlinien für die betreffenden Themen, die durch Kommunikation und Training auch entsprechend bekannt sind und angewendet werden, Prüfergebnisse über ihre Einhaltung, den Wissensaufbau und -transfer sowie die Einarbeitung dieser Learnings in neue und verbesserte Versionen dieser Richtlinien. 2.3.4 Prozesskategorisierung

Es finden sich in Unternehmen und Organisationen also typischerweise drei Arten von Prozessen: ·

Leistungserstellungsprozesse zur Erbringung der Leistungen an die externen Kunden 128 Vgl. dazu das Konzept des New Controlling von Peter Horváth, demzufolge die einzelnen Controllingprozesse definierte und kalkulierte Produkte wie z. B. Monatsberichte hervorbringen, die den Kunden im Unternehmen angeboten werden. Horváth (2009), S. 952.

75


·

Bereitstellungsprozesse zur Erbringung genereller, indirekt notwendiger interner Rahmenbedingungen für die Leistungserstellung Steuerungsprozesse zur Steuerung der Leistungs- und Bereitstellungsprozesse entsprechend dem Ziel des Unternehmens oder der Organisation sowie zur Sicherstellung der Einhaltung extern und intern geforderter Normen

·

In der Literatur und in der etablierten Prozessmanagementpraxis findet sich demgegenüber häufig die Einteilung in Managementprozesse, Wertschöpfungs- oder Kernprozesse129 und Supportprozesse oder auch die Unterteilung in primäre und sekundäre Geschäftsprozesse130. Diese Kategorisierung wird hier bewusst nicht verwendet, da diese Begriffe in mehrerer Hinsicht mit falschen Konnotationen verbunden werden. Die Bezeichnung „Wertschöpfungsprozesse“ suggeriert, dass nur in diesen Prozessen Wert generiert wird. Die Wertschöpfung fokussiert dabei auf den Beitrag, den die jeweiligen Teilprozesse und Prozessschritte zum Wert für den Kunden leisten. Letzterer mündet dabei im von diesem erzielbaren Preis. Alle übrigen Prozesse gelten damit implizit als Overhead, der nur Kosten verursacht, aber nichts beiträgt, und somit auf ein Minimum reduziert oder gar gestrichen oder ausgelagert werden sollte. Diese vielfach vorherrschende und mit der üblichen Kategorisierung eng verknüpfte Ansicht ist jedoch falsch. Steuerungs- und Bereitstellungsprozesse sind für die Wertschöpfung und für die Existenz des Unternehmens genauso notwendig, wie die Leistungserstellungsprozesse.131 Letztere könnten ohne die ersten beiden nicht ausgeführt werden. Ohne Steuerungsprozesse würden Ziel und Leistungskontrolle fehlen, ohne die Bereitstellungsprozesse die notwendigen Rahmenbedingungen nicht gegeben sein. Und auch innerhalb der Teilprozesse zur Leistungserstellung kann der jeweilige Beitrag zur Wertschöpfung unterschiedlich sein. Dies gilt etwa für Teilprozesse der Auftragsakquisition, für den Fakturierungsprozess oder auch für den Teilprozess der Zustellung, der traditionell eher geringer Margen bringt. Sie alle schaffen per se vielleicht keinen sichtbaren Wert, ohne sie wäre aber die Wertschöpfung der erbrachten Leistung nicht möglich. Obwohl ihr Beitrag zur Wertschöpfung unter Umständen also gering ist, sind sie im Sinne einer End-to-End-Sicht für die Erstellung der Leistung für den Kunden dennoch notwendig. Gerade bei Anwendung einer End-toEnd-Sicht wirken also wertschöpfende und scheinbar weniger wertschöpfende Teilprozesse in der Leistungserstellung eng zusammen. 129 Z.B. Stöger (2009), S. 12. 130 Z.B. Stöger (2009), S. 74. 131 Vgl. dazu z. B. auch Mangler (2006): Er führt aus, dass über die Prozesssicht eine Marktorientierung entsteht, die dazu führt, dass auch unterstützende und indirekte Bereiche nicht mehr nur als Kostenfaktor aufgefasst werden, sondern – sofern sie einen internen Abnehmer für ihre Services finden und dessen Bedürfnisse durch ihre Leistungen befriedigen – auch zu einem wertschöpfenden Faktor werden (S. 27).

76


Zudem ist das Konzept der Wertschöpfung in Bezug auf Prozesse ein sehr problematisches. Konkret ist die Definition, was Wertschöpfung genau ist und wie sie gemessen werden kann, in der praktischen Umsetzung anhand von Prozessen eine enorme Herausforderung, für die es bislang keine etablierten und allgemein anerkannten Modelle gibt. Denken wir etwa nur an das Beispiel der Rechnungsstellung und der buchhalterischen Verbuchung von Geschäftsfällen: Würde man Kunden fragen, so würden sie vielleicht in der ersten Reaktion verneinen, dass diese Prozessschritte für sie einen Wert schaffen, für den sie auch zu bezahlen bereit sind. Da jedoch auch sie – falls es sich um Unternehmen handelt – zu einer ordnungsgemäßen Buchführung verpflichtet sind oder im Falle von späteren Reklamationen entsprechende Garantieregelungen in Anspruch nehmen wollen, haben sie bei genauer Überlegung sehr wohl ein Interesse an diesen Teilschritten. Und ruft der Kunde am Jahresende an, weil er eine Saldenbestätigung braucht, so hat sogar die Buchhaltung für ihn in diesem Moment einen gewissen Wert und liefert eine Leistung, die er benötigt. Wie bewertet man jedoch diese Wertschöpfung dieser Prozesse? – Wie die Beispiele zeigen, ist die Frage der Wertschöpfung von Teilprozessen und Prozessschritten deutlich komplexer und differenzierter, als dies auf den ersten Blick scheint. Denn für eine Bewertung der Wertschöpfung von Prozessen und Teilprozessen müssten nicht nur die Prozesskosten mit einiger Präzision bekannt sein, sondern auch die Erlöse auf die Teilprozesse verteilt werden. Dort wo es für Prozesse oder Teilprozesse einen echten Fremdvergleich mit am externen Markt angebotenen Leistungen gibt, kann dies noch einigermaßen valide durchgeführt werden. Für die Mehrzahl der Teilprozesse besteht diese Möglichkeit jedoch nicht. Die Verteilung der Erlöse auf die einzelnen Teilprozesse würde daher zu einem wesentlichen Teil der Willkür unterliegen – und damit in letzter Konsequenz auch die Bewertung der Wertschöpfung der Teilprozesse.132 Die vielfach verwendete Unterscheidung in Nutzleistungen, die direkt zur Wertsteigerung beitragen, Stützleistungen, die indirekt zur Wertsteigerung beitragen, Blindleistungen, die nicht zur Wertsteigerung beitragen, und Fehlleistungen, welche die Wertschöpfung sogar vermindern, ist hier auch nur bedingt hilfreich. Zwar ermöglicht sie durchaus eine grobe Einteilung der Teilprozesse nach ihrem Wertschöpfungsbeitrag. Auch hier ist in der Praxis die Einteilung der einzelnen Prozessschritte in diese Kategorien aber Interpretationssache und offen für Dispute.133 Ähnliches gilt für die Kategorisierung von Teilprozessen in der Wertstromanalyse in „werthaltig“, 132 Vgl. Bogaschewsky, Rollberg (1998, S. 288–289). Auch Klimmer (2007, S. 97) hält fest, dass bei Ansätzen, welche den Wertzuwachs oder die Wertschöpfung als wesentliches Merkmal von Prozessen sehen, meist offenbleibt, inwieweit dieses Kriterium für alle Ebenen der Prozesshierarchie sowie für alle Organisationstypen angewendet werden kann. 133 Vgl. Schmelzer, Sesselmann (2010), S. 139: Die beiden Autoren stellen dort zwar diese üblichen Kategorien der Nutz-, Stütz-, Blind- und Fehlleistung dar, ohne jedoch auf die grundlegende Problematik einzugehen, wie Wertschöpfung in den Prozessen tatsächlich sinnvoll gemessen werden kann. Vgl. auch Klimmer (2007), S. 263.

77


„nicht werthaltig“ und „nicht werthaltig aber notwendig“ – auch hier wird eine grobe Einteilung unterstützt, das generelle Problem der genauen Feststellung des Beitrags zur Wertschöpfung bleibt aber auch hier ungelöst, der genaue rechnerische Wertbeitrag ist auch damit nicht feststellbar. Insofern ist das Kriterium der Wertschöpfung keines, das bereits am Beginn der Maßstab für die Kategorisierung der Prozesse sein sollte, sondern vielmehr eines, das zu einem späteren Zeitpunkt, wenn die Prozesse einmal identifiziert und definiert sind, für Analysen und Optimierungen der Prozesse herangezogen werden kann – und auch dann mit der notwendigen Vorsicht und dem Bewusstsein über die beschriebenen Schwierigkeiten. Auch der alternativ häufig verwendete Begriff der „Kernprozesse“ ist in Zusammenhang mit dem hier entwickelten End-to-End-Verständnis von Geschäftsprozessen irreführend. Denn Kernprozesse bezeichnen jene Teilprozesse, in denen das Unternehmen spezielle Kernkompetenzen hat, die von strategischer Relevanz sind. Typischerweise ist dies jedoch nur für manche Teilprozesse in der Leistungserstellung der Fall, während andere zwar für die Erstellung der Leistung notwendig sind, jedoch ohne besondere Unterscheidung vom Wettbewerb durchgeführt werden. In manchen Fällen ist es sogar möglich, dass bestimmte normative Steuerungsprozesse oder auch Bereitstellungsprozesse wettbewerbsrelevant sind. Denken wir etwa nur an bestimmte Sicherheitsvorgaben bei Banken, mit denen sich diese von anderen Instituten als besonders seriös und sicher abgrenzen; an manche Glücksspielanbieter, die sich unter anderem über Normen zum Spielerschutz von anderen Marktteilnehmern unterscheiden; oder auch an Baufirmen, die in ihren Personalbereitstellungsprozessen über eine besondere Flexibilität und Skalierbarkeit verfügen, die ihnen gegenüber dem Wettbewerb einen Vorteil gibt. Gerade durch das Herausgreifen der Teilprozesse, die als Kernaufgaben gesehen werden, und der Verlagerung aller anderen Prozesse in die Supportprozesse, entstehen in der Praxis vielfach Prozessmodelle, die stark funktional- und aufgabenorientiert geprägt sind. Ein bereits initialer Fokus auf diese Kernprozesse und die damit verbundene geringere Priorität oder sogar das teilweise Weglassen der anderen Teilprozesse, die nicht als Kernprozesse gesehen werden, verhindert eine integrative wirkliche End-to-End-Sicht auf die Prozesse, wie sie hier entwickelt wird und die gerade einen der Hauptvorteile der Prozesssicht ausmacht.134 Die vorgeschlagene Bezeichnung „Leistungserstellungsprozesse“ vermeidet diese Fallstricke, da sie einfach neutral alle Teilprozesse auflistet, die für die Erstellung einer Leistung aus Sicht des Unternehmens notwendig sind. Die Frage, ob hier bestimmte 134 Ausgangspunkt für eine derartige Identifikation der Prozesse anhand ihres strategischen Beitrags ist vielfach ein Missverstehen des Wertkettenmodells von Porter. Dieses ist ein wesentliches Modell zur strategischen Analyse von Unternehmen und Organisationen, es ist jedoch nicht dafür gedacht, eine integrative Prozesssicht auf diese zu ermöglichen. Die Darstellung von Porter in einer integrierten Pfeilform, die sich damit mit der üblichen Prozessnotation deckt, mag zu diesem Missverständnis beigetragen haben.

78


Teilprozesse oder Prozessschritte weggelassen werden können beziehungsweise ebenso, ob sie spezielle Kernkompetenzen des Unternehmens verkörpern und damit strategisch relevant sind, ist eine, die später im Zuge der Analyse und Optimierung gestellt wird. Sie soll jedoch nicht schon von Beginn an die Prozessidentifikation beeinflussen. Der Begriff „Supportprozesse“, der häufig für jene Geschäftsprozesse Verwendung findet, die ihre Leistungen an interne Kunden erbringen, wäre von der Bezeichnung her prinzipiell durchaus geeignet, unterstützen doch die darunter subsumierten Prozesse durchaus die Leistungserstellung. Leider ist jedoch auch diese Bezeichnung aus der Praxis enorm vorbelastet. Denn zum einen werden in den Unternehmen Supportprozesse vielfach gleichgesetzt mit den bestehenden Servicefunktionen im Unternehmen. Es finden sich zum Beispiel häufig „Supportprozesse“ Buchhaltung, Materialwirtschaft, Personal und IT135. Das diesen Prozessen zugrundeliegende, sehr abteilungs- und funktionsbezogene Teilprozessverständnis widerspricht jedoch klar dem hier entwickelten End-to-End-Ansatz. Zum anderen schrillen beim Begriff „Supportprozess“ bei vielen Beteiligten bereits die Alarmglocken, da Supportprozesse in der Prozessmanagementliteratur vielfach als minderwertig und damit als Outsourcingkandidaten gelten.136 Auch dies ist jedoch nicht der Fall. Im Rahmen der hier entwickelten End-to-End-Sichtweise von Prozessen kann es genauso in der Leistungserstellung Teilprozesse geben, die besser ausgelagert werden; ebenso kann es – wie oben erwähnt – Bereitstellungsprozesse geben, die eine besondere Kernkompetenz verkörpern oder sonst aus anderen Gründen intern gehalten werden sollen. Mit der Kategorisierung der Prozesse in intelligence- und commodity-Prozesse wird weiter unten noch ein anderer Zugang für das Managen der Prozesse anhand dieser Bedeutung dargestellt. So wichtig diese Überlegung hinsichtlich Eigenerbringung oder Fremdbezug von Prozessleistungen auch ist, sie sollte nicht schon durch die Identifikation und Gruppierung der Geschäftsprozesse determiniert werden. Die grundsätzliche Prozessgliederung sollte vielmehr von derartigen Überlegungen im ersten Schritt nicht überlagert werden, da sonst das Risiko besteht, dass durch die Einbeziehung von Interessenslagen in Bezug auf diese Fragestellungen bereits am Beginn ein falsches Prozessmodell entsteht. Bereitstellungsprozesse, wie sie hier entwickelt wurden, sind zudem anders definiert: sie umfassen nicht alles, was landläufig als Overhead und Support gesehen 135 Siehe dazu auch Abschnitt 2.2.4 über die Abgrenzung von Unternehmensfunktionen. 136 Vgl. etwa Osterloh, Frost (2000), S. 35: Für sie leisten Supportprozesse keinen unmittelbaren Beitrag zum Kundennutzen, haben keine strategische Bedeutung und sind deshalb prinzipiell Kandidaten für Outsourcing. Vgl. auch Bogaschewsky, Rollberg (1998, S. 203), für die Supportprozesse aufgrund ihrer strategischen Bedeutungslosigkeit grundsätzlich für Auslagerungen zur Disposition stehen. Ebenso Hiller, Minar-Hödl, Zahradnik (2010), für die die unterstützenden Prozesse jener Bereich sind, in dem man Prozesse identifizieren kann, die sinnvollerweise ausgelagert werden (S. 25). Vgl. dazu auch Becker, Kahn (2008, S. 7), die explizit darauf hinweisen, dass der Begriff „Supportprozesse“ keineswegs als Abwertung zu verstehen ist – sichtlich ist ein derartiges explizites Statement notwendig.

79


wird, sondern die Bereitstellung jener internen Leistungen, die nicht direkt mit den Produkten oder Leistungen verbunden sind. Also allgemeine interne Leistungen, die quasi als Rahmenbedingungen gegeben sein müssen und die an vielen, ja fast allen Stellen der Leistungserstellungsprozesse erforderlich sind. So kann man etwa nicht sagen, dass ein Bürogebäude genau für diesen oder jenen Teilprozess einer Computerhandelsfirma benötigt wird – das Büro ist vielmehr eine generelle Grundbedingung für alle Teilprozesse. Dasselbe trifft auf die Fabrikanlagen einer Fertigung zu, weshalb auch die Wartung dieser Anlagen als ein allgemeiner Bereitstellungsprozess gilt. Alle direkt mit den Produkten und Leistungen verbundenen Teilprozesse werden hingegen im Sinn des End-to-End-Verständnisses als Teil der Leistungserstellung betrachtet und in die Leistungserstellungsprozesse integriert, also etwa die Beschaffung von Produktteilen, das Marketing für bestimmte Leistungen, ihre Lieferung oder die buchhalterische Verbuchung der Verkäufe und produktbezogenen Einkäufe. Um dieses fundamental andere Verständnis zum Ausdruck zu bringen und die beschriebenen Konnotationen möglichst zu vermeiden, wird hier statt „Supportprozesse“ der Begriff „Bereitstellungsprozesse“ eingeführt. Das Abgehen von dieser Bezeichnung soll damit auch den generellen Wechsel von einer funktionalen Teilprozesssicht zu einer echten End-to-End-Prozesssicht signalisieren und mithelfen, diese Verwechslungen und Vermischungen besser zu vermeiden. Ganz ähnlich verhält es sich auch mit der vielfach genutzten und etablierten Bezeichnung „Managementprozesse“. Sie wird in der Praxis des Prozessmanagements vielfach mit dem Management von Unternehmen und Organisationen im Sinne der aufbauorganisatorischen Hierarchie gleichgesetzt. Bei der Identifikation von Prozessen will daher jeder Bereich und jede Abteilung mit „ihren“ Prozessen in den Managementprozessen abgebildet sein; egal welcher Prozess, jeder will wenn irgendwie möglich in den Managementprozessen landen. Denn wer mit „seinen“ Teilprozessen zu den Managementprozessen zählt, der gehört – so die Annahme – zum Management und ist damit sicher. Auch das stimmt so nicht. Wie eingangs erwähnt, soll ein Prozessmodell sich klar von der funktionalen und der aufbauorganisatorischen Sicht abgrenzen, um eine dritte, wertvolle Sichtweise auf das Unternehmen zu bieten. Die Bezeichnung Managementprozesse – wie wohl in der Sache sicherlich richtig gewählt – weist dafür eine viel zu starke Konnotation zur Funktion und Ebene des Managements auf. Aus diesem Grund wird hier stattdessen der Begriff „Steuerungsprozesse“ verwendet. Dadurch wird die Steuerung des Unternehmens als Prozess stärker in den Fokus gerückt und die Möglichkeit zur aufbauorganisatorischen und funktionalen Missinterpretation deutlich verringert. Denn es gibt zwar auch eine Unternehmenssteuerung, für den prinzipiell genau das Gleiche gilt wie für den Begriff Management, dieser Begriff ist jedoch deutlich weniger etabliert und von Mitarbeitern aufbauorganisatorisch viel schwieriger einzuordnen. Zudem hat Steuerung, nicht zuletzt wegen der technischen Verwendung dieses Begriffs, vielmehr die Konnotation des Prozesses. Insofern wird dieser Bezeichnung hier der Vorzug gegeben. 80


Die Untergliederung in Leistungserstellungs-, Bereitstellungs- und Steuerungsprozesse stellt einen Versuch dar, die beschriebenen eingefahrenen Missverständnisse zu umgehen und von dem bisherigen funktionalen Teilprozessverständnis zu einer echten End-to-End-Prozesssicht zu kommen. Die Unterscheidung erfolgt dabei der entwickelten End-to-End-Definition entsprechend der Art der erbrachten Leistung: Leistungserstellungsprozesse erbringen eine verkaufbare Leistung an einen externen Kunden und umfassen alle Teilprozesse, die direkt mit dieser Leistung verbunden und für ihre Erstellung notwendig sind; Bereitstellungsprozesse erbringen indirekt notwendige interne Leistungen, die den Leistungserstellungsprozessen nicht an einer bestimmten Stelle zuordenbar sind, sondern allgemein, quasi als generelle Rahmenbedingungen notwendig sind; Steuerungsprozesse schließlich erbringen interne Leistungen in Form von Vorgaben, Plänen, Evaluierungen und Korrekturmaßnahmen zur Sicherstellung des Unternehmensziels. Ob es gelingt, mit dieser Untergliederung eine wirklich wertfreie oder zumindest weniger wertbehaftete Einteilung der Prozesse von Unternehmen und Organisationen zu erreichen, wird die Praxis zeigen. Wichtig sind jedoch weniger die hier konkret gewählte Bezeichnungen als vielmehr die Intention dahinter. Wesentlich ist, dass die Identifikation der Prozesse und die dabei vorgenommene Gruppierung nicht schon vorab eine Wertung vornimmt, sondern sich ausschließlich an den erbrachten Leistungen und der Abfolge der notwendigen Teilprozesse und Schritte dazu orientiert. Nur so kann eine durchgängige und integrative Ablauflogik im Sinne einer End-toEnd-Prozesssicht erreicht werden. Alternative Benennungsvorschläge, die dies noch besser erfüllen, sind daher jederzeit willkommen.

2.3.5 Erhebung und Detaillierung von Teilprozessen

Sind die Geschäftsprozesse eines Unternehmens oder einer Organisation auf der obersten Ebene anhand der Leistungen einmal identifiziert, so geht es im nächsten Schritt darum, diese weiter zu detaillieren. Dies erfolgt typischerweise durch die Untergliederung der Leistungserstellungs-, Steuerungs- und Bereitstellungsprozesse in Teilprozesse, die dieselbe Ablauflogik enthalten.

Abb. 22: Abgrenzung von Teilprozessen

81


Dieses Vorgehen ist soweit weitgehend etabliert. In der Praxis ergeben sich dabei jedoch vier wesentliche Problemstellungen: · · · ·

das Problem der mangelnden Ablauflogik auf der detaillierten Ebene die Frage, wo und nach welchen Regeln Teilprozesse zu schneiden sind die Frage nach Prozessvarianten die Frage nach der richtigen Detaillierungstiefe

Das erste Problem ist hierbei sehr weit verbreitet, ist aber das am einfachsten lösbare: Viele bestehende Prozessmodelle weisen auf der ersten Detaillierungsebene bereits keine klare Ablauflogik mehr auf. Anstatt einer klaren Sequenz zur Erstellung der definierten Leistung des jeweiligen Prozesses findet sich oft ein Sammelsurium an Teilprozessen, die sich untereinander in keine klare Abfolge bringen lassen, sondern irgendwie isoliert nebeneinander oder teilweise auch in einer hierarchischen Beziehung stehen. Grund dafür ist meist, dass bereits auf der obersten Ebene die Prozesse falsch – also nicht anhand klar definierter Leistungen – definiert wurden. Ist die Prozessidentifikation auf Ebene 1 in eine funktionale oder aufbauorganisatorische Gliederung abgerutscht, so ist es darunter in den Detailmodellen schwierig, die prozessuale Ablauflogik wieder herzustellen. Anstatt von durchgängigen Teilprozessen erfolgt dann meist eine Gliederung nach Aufgaben und Aufgabengruppen. Vielfach gelingt es dann erst auf tieferen Detaillierungsebenen für die Erledigung dieser Teilaufgaben wieder eine durchgängige Ablaufsequenz festzulegen und diese über Prozessschnittstellen miteinander zu verknüpfen. Auf den oberen Ebenen des Prozessmodells fehlt diese Durchgängigkeit jedoch. Derartige Unterteilungen entsprechen nicht einem End-to-End-Prozessmodell, sondern eher einer allgemeinen Gliederungsstruktur für die Fülle an Detailabläufen. Sind die Prozesse jedoch auf oberster Ebene richtig anhand von klaren Leistungen identifiziert, so muss in der Detaillierung nur sicher gestellt werden, dass die Durchgängigkeit der Leistungserstellung auch bei der Detaillierung der Teilprozesse erhalten bleibt. Hierfür wird zur Detaillierung eines Geschäftsprozesses gefragt: · · · ·

Was den Geschäftsprozess auslöst Welcher Teilprozess dann zuerst erfolgt, um die Leistung zu erstellen Welcher Teilprozess danach erfolgt usw.

Die Identifikation der Teilprozesse erfolgt somit durch die Frage, welche Schritte zur Leistungserstellung der Reihe nach notwendig sind. Auf diese Weise verfolgt man die Erstellung der Leistung aus der Sicht des Geschäftsfalles über alle Schritte zur Leistungserstellung, bis der Geschäftsfall komplett abgeschlossen ist. Analog erfolgt dies bei der weiteren Detaillierung der einzelnen Teilprozesse. Auch hier unterstützen die82


Abb. 23: Beibehaltung der Ablauflogik in der Detaillierung der Teilprozesse

selben einfachen Fragen wieder eine Identifikation der weiteren Teilprozesse und Prozessschritte: · · · · · ·

Welchen Bedarf erfüllt der Teilprozess für die anderen Teilprozesse oder für den Gesamtprozess und welche Teilleistung erbringt er? Was löst den Teilprozess aus? Welcher Prozessschritt erfolgt dann als erstes zur Erstellung dieser Teilleistung? Welcher Prozessschritt folgt dann? Welcher dann? usw.

Um dabei die Ablauflogik konsequent beizubehalten, empfiehlt sich in der Praxis ein Top-down-Vorgehen in der Detaillierung, bei dem zur Detaillierung eines Teilprozesses jeweils die Vorgänger- und Nachfolgerprozesse als Prozessschnittstellen mitgenommen werden. Damit ist von Beginn an sichergestellt, dass die Grenzen der jeweiligen Teilprozesse konsistent heruntergebrochen werden. Zur konkreten Erhebung der Abläufe anhand der skizzierten Fragen kommen dabei mehrere konkrete Vorgehensweisen in Betracht:137 · · ·

Gespräche mit Prozessbeteiligten (Interviews) Erhebungsworkshops Studium von vorhandenen Dokumenten (Dokumentenanalyse) 137 Vgl. dazu EABPM (2009), S. 76 ff. Ebenso Verner (2004).

83


· · ·

Fragebogenerhebungen Prozessbegehungen Laufzettel

Das wesentliche Mittel in der Praxis der Prozesserhebung sind Gespräche und Interviews mit den am jeweiligen Prozess Beteiligten.138 Da sie das Wissen über die tatsächlichen Abläufe oder zumindest jene Teilstücke davon haben, in denen sie aktiv mitarbeiten, wird keine Prozesserhebung ohne derartige Gespräche auskommen. Für Teilprozesse auf einer aggregierten Ebene, für Prozesse mit sehr vielen Beteiligten oder auch zur übergreifenden Konsolidierung der in Einzelgesprächen erhobenen Inputs zu einem Prozess empfehlen sich Workshops mit mehreren Prozessbeteiligten. Gerade für die übergreifende Konsolidierung und Validierung von Entwürfen ermöglichen sie durch die Präsenz aller Beteiligten am Prozess ein rasches Klären von noch offenen Fragen sowie eine einfache finale Abstimmung und Freigabe. Das Studium und die Nutzung von vorhandenen Dokumentationen (Dokumentenanalyse) ist hierbei vielfach ein sinnvoller zusätzlicher Input.139 Es sollte sinnvollerweise vor den jeweiligen Gesprächen, Interviews und Workshops erfolgen. Auf diese Weise werden mehrere Vorteile erzielt: Einerseits kann sich das Erhebungsteam bereits in den Ablauf und das fachspezifische Vokabular einarbeiten, sodass im Gespräch oder Workshop ein tieferes Verständnis gegeben ist und auch bereits gezielt Fragen zu Details gestellt werden können; die Erhebungsgespräche werden dadurch effizienter und effektiver; darüber hinaus wird dem Interviewpartner auch ein entsprechendes Interesse signalisiert sowie die Bereitschaft, auf bereits vorhandenen Dokumentationen aufzubauen – der häufige Vorwurf, dass bei einer Prozesserhebung Dinge zum zweiten oder dritten Mal gemacht werden, kann damit etwas entkräftet werden. Dennoch sind vorhandene Unterlagen immer nur als Input und Vorbereitung zu sehen, da sie meist nicht den letzten Aktualitätsstand haben und auch häufig aus bestimmten Zielsetzungen heraus und mit einem bestimmten Fokus entstanden sind, sodass sie häufig nur die Teilaspekte aus der Sicht dieser Zielsetzung umfassen. Liegen keine Dokumentationen vor, so kann es sinnvoll sein, bei den Gesprächspartnern bereits vor den einzelnen Gesprächen die wesentlichen Prozessschritte mithilfe einer strukturierten Fragebogenerhebung abzufragen.140 Hierfür genügt eine einfache Tabelle mit den wesentlichen Strukturierungselementen eines Prozesses (Prozessschritte, ausführende Stelle, unterstützende IT-Systeme, Inputs, Outputs, An138 Für eine detaillierte Darstellung der mündlichen Befragung und Interviewtechnik siehe insbes. Mangler (2006), S. 117–125. Ebenso Schmidt (2006), S. 162; Klimmer (2007), S. 239 ff. 139 Vgl. dazu die detaillierte Darstellung des Dokumentenstudiums bei Mangler (2006), S. 143–145. Ebenso Schmidt (2006), S. 162. Klimmer (2007), S. 236. 140 Vgl. dazu die detaillierte Darstellung der schriftlichen Befragung bei Mangler (2006), S. 126 ff. Mangler differenziert davon auch noch die Technik der Selbstaufschreibung (ebenda, S. 137–140). Ebenso Schmidt (2006), S. 162; Klimmer (2007), S. 236 ff. und S. 243 f.

84


Abb. 24: Vorgehen bei der Prozesserhebung

merkungen), um einen ersten Input zur Ablaufstruktur und zu den wesentlichen Ablaufschritten zu bekommen. Die hierfür verwendeten Tabellen müssen und sollen gar nicht alle Prozessaspekte umfassend abfragen, sondern sich im ersten Schritt auf einige wenige zentrale Strukturierungselemente konzentrieren. Denn umfassen sie zu viel, so sinkt erfahrungsgemäß die Akzeptanz bei den Adressaten sehr rasch und damit ebenso die Qualität und Brauchbarkeit der rückgesandten Fragebögen. Als alleiniges Erhebungselement sind Fragebögen daher für Prozesserhebungen nur in den seltensten Fällen einsetzbar. Ergänzend zu Erhebungsgesprächen und Workshops können im Einzelfall auch weitere empirische Erhebungsmethoden des genauen Ablaufes sinnvoll sein. So versetzt man sich etwa bei einer Prozessbegehung in einen konkreten Geschäftsfall hinein und „geht“ den Prozess mit diesem Geschäftsfall vom Anfang bis zum Ende ab.141 Da dieses Verfahren durchaus aufwendig ist – gerade etwa bei dislozierten Bearbeitungsstellen – wird es für die tatsächliche Erhebung von Prozessen nur selten angewandt. Es kann jedoch vor allem für die Validierung von Prozessen im Einzelfall durchaus sinnvoll sein. Ein wesentlicher Vorteil dieses Vorgehens ist dabei, dass auch wesentliche Umfeldfaktoren zum Prozess – etwa das Aussehen und die Organisation der Arbeitsplätze, ein persönlicher Eindruck von den Bearbeitern und den Arbeitsbe141 Vgl. dazu die detaillierte Darstellung der Technik der Beobachtung bei Mangler (2006), S. 130– 137. Ebenso Schmidt (2006), S. 162; Klimmer (2007), S. 244 f. Hiller, Minar-Hödl, Zahradnik (2010) unterscheiden hiervon noch als weiteren Spezialfall das Mystery Shopping, bei dem der Prozess praktisch anonym durchgespielt wird, indem man den Beteiligten einen Kundenfall vorspielt, ohne sie vorher zu informieren (S. 106).

85


dingungen, sichtbare Stapel oder Materialzwischenlager, etc. – erkannt werden, die später für die weitere Analyse und Optimierung sehr hilfreich sind und das Analysebild abrunden. Ganz ähnlich funktioniert das Laufzettelverfahren142, bei dem einem eingehenden realen Geschäftsfall ein Protokollzettel beigefügt wird, mit der Bitte, jeder Bearbeiter möge seine jeweiligen Schritte zur Abarbeitung sowie gegebenenfalls weitere Informationen dazu in diesen eintragen. Auf diese Weise entsteht ein ähnliches Ergebnis wie bei einer Prozessbegehung, jedoch mit geringerem Erhebungsaufwand, dafür jedoch auch ohne dass das Prozessteam wichtige qualitative Umfeldfaktoren mitbekommt. Das typische Standardvorgehen in Projekten in der Praxis beginnt mit der Dokumentenanalyse, auf Basis derer ein grundsätzliches Verständnis des Prozesses und ein erster Grobentwurf entsteht. Im zweiten Schritt wird der Prozess in Gesprächen und Interviews mit den Prozessbeteiligten erarbeitet. Durch die Konsolidierung dieser Interviewergebnisse entsteht ein weitgehend vollständiger Prozessentwurf. Dieser wird im dritten Schritt in einem Workshop mit Vertretern aller am Prozess beteiligten Gruppen nochmals durchgesprochen, validiert, ergänzt und finalisiert. Die übrigen Vorgehensweisen werden eher selten eingesetzt und wenn doch, dann meist ergänzend zu diesem Standardvorgehen. 2.3.6 Abgrenzen von Teilprozessen

Die zweite Problemstellung ist konzeptionell deutlich schwieriger: Wie und wo sollte man Teilprozesse genau schneiden, sprich die Grenzen zwischen verschiedenen Teilprozessen ziehen? Die Wichtigkeit einer klaren Abgrenzung wird fast von allen Vertretern des Prozessmanagements hervor gestrichen, es gibt jedoch kaum klare Vorgaben, wie diese Abgrenzung erfolgen soll und Kriterien, anhand derer man weiß, wo Prozesse geschnitten werden sollen. Aus der Erfahrung heraus definieren wir Prozesse zur Angebotserstellung, zur Auftragsanlage und zur Lieferung und Fakturierung. Warum aber definieren wir sie genau so? Warum legen wir stattdessen nicht einen Prozess der Angebots- und Auftragsanlage an. Oder warum schneiden wir den Prozess der Lieferung nicht in die Lieferung von der Produktion ins Großlager, den Transport von dort ins Zwischenlager und schließlich in die Zustellung von dort zum Kunden? Das Schneiden der Teilprozesse erfolgt in den Projekten und bei der Erstellung von Prozessmodellen meist intuitiv und auf Basis von bereits bekannten Beispielen. Wo diese Schnitte jedoch in der Diskussion hinterfragt werden, gibt es nur wenig an konzeptionell fundierten und etablierten Kriterien und Leitlinien für dieses Vorgehen.

142 Vgl. dazu die detaillierte Darstellung des Laufzettelverfahrens bei Mangler (2006), S. 140–143.

86


Vielfach wird der Übergang der Zuständigkeit von einer Abteilung zu einer anderen als Teilungskriterium angeführt.143 Gerade dies ist jedoch problematisch: Zum Einen hieße das, dass die Ablauforganisation der Prozesse anhand der Aufbauorganisation definiert wird. Dies würde dem Verständnis von Prozessmanagement und vor allem einer End-to-End-Prozesssicht widersprechen, die ja eine zusätzliche Sicht auf das Unternehmen unabhängig von der Aufbauorganisation bieten will. Zum Zweiten ist im Zuge der späteren Optimierung eine wesentliche Stoßrichtung für Verbesserungen in den Prozessen ja genau die Änderung von Zuständigkeiten in der Prozessausführung. Erfolgt jedoch bereits die Abgrenzung der Teilprozesse auf Basis der Zuständigkeiten, so sind Teilprozesse schon per Definition in einer geschlossenen Verantwortung. Wichtige Optimierungsfelder im Sinne der Ausführungsintegration bleiben damit intransparent und können nicht erkannt werden. Und würde man sie erkennen und Zuständigkeiten ändern, so müssten konsequenterweise auch die Abgrenzungen der Prozesse geändert werden. Beides wäre in keinster Weise sinnvoll und hilfreich. Für eine klare, kriterienbasierte Abgrenzung zwischen den Teilprozessen empfiehlt es sich, die Elemente der entwickelten Prozessdefinition in leicht abgewandelter Form auch auf die Teilprozesse anzuwenden. So wie jeder Geschäftsprozess erbringt auch jeder Teilprozess eine konkrete und abgrenzbare Teilleistung, die für die gesamte Leistungserstellung notwendig ist.144 Der Bedarf für den Teilprozess hat dabei seinen Ursprung in nachgelagerten Teilprozessen, die auch die „Kunden“ für die Leistung des Teilprozesses sind. Jede Teilleistung soll dabei etwas sein, wofür diese nachfolgenden Prozesse als Bedarfsquelle und Empfänger der Teilleistung theoretisch bereit wären, einen Preis zu zahlen. Denken wir etwa an den Teilprozess „Auftrag erfassen“: hier benötigt etwa der später folgende Teilprozess „Produkt fertigen“ die Daten zu Produkt und Menge, um möglichst frühzeitig Inputdaten für die Planung der Fertigung zu haben. Oder die Eingabe der Kostenstelle im Teilprozess „Bestellung erfassen“, die der später folgende Teilprozess „Eingangsrechnung verbuchen“ benötigt, um die erhaltene Eingangsrechnung kostenrechnerisch richtig zuzuordnen. Die Überlegung, dass die Teilprozesse, die „Kunden“ dieser Teilleistungen sind, dafür auch etwas bezahlen würden, ist hierbei vorerst einmal ein Hilfskonstrukt, da 143 Vgl. z. B. Knuppertz (2009), S. 100. 144 Vgl. dazu auch das Prinzip der Prozessgliederung von Fritz Nordsieck, nach dem die Gesamtaufgabe nach den Stufen der fortschreitenden Konkretisierung des Betriebszieles erfolgt und die so identifizierten Teilaufgaben relativ selbständige Abschnitte im Leistungserstellungsprozess sind. Siehe Schober (2002), S. 60. Einen sehr ähnlich konzipierten Vorschlag zur Abgrenzung von Teilprozessen machen Becker und Vossen 1996 (zit. nach Staud 2001, S. 23), die zur Entsubjektivierung der Grenzen von Prozessen betriebswirtschaftlich relevante Objekte definieren (z. B. Rechnung, Ware, . . .) und Prozesse als abgeschlossene Bearbeitung dieser Objekte sehen. Im Ergebnis sind beide Ansätze sehr ähnlich, hier wird jedoch mehr die Erstellung der Teilleistung und weniger das Objekt der Verrichtung, an dem diese erbracht wird, betont. Vgl. auch Knuppertz (2009), der ebenso die Bestimmung der wesentlichen Leistung als ein wesentliches Kriterium zur Abgrenzung von Prozessen sieht (S. 53).

87


im internen Verhältnis zwischen Teilprozessen üblicherweise ja keine Leistungsverrechnung stattfindet. Es gibt jedoch zwei spezielle Fälle, bei denen dies durchaus der Fall sein kann: ·

·

Zum einen, wenn Teilprozesse nicht von der für den betreffenden Leistungserstellungsprozess zuständigen Geschäftseinheit erbracht werden, sondern durch andere, zum Beispiel durch interne Serviceeinheiten (service center). In diesem Fall erfolgt typischerweise eine interne Verrechnung der Leistungen bzw. der damit verbundenen Kosten. Beispiele sind etwa die Durchführung der debitorischen Buchung von Geschäftsfällen durch ein Accounting Shared Service Center oder die Beschaffung von auftragsbezogenen Materialien und Baugruppen durch einen zentralen Einkauf. Die zu erbringenden Leistungen und Servicegrade hierfür sind in einem Service Level Agreement als Form einer internen Vereinbarung festgelegt. Zum anderen, wenn Teilprozesse tatsächlich nicht selbst, sondern durch externe Partner durchgeführt werden (outsourcing). Beispiele sind auch hier die buchhalterische Verbuchung von Geschäftsfällen oder zum Beispiel auch die Zustellung von Waren an die Kunden. Auch hier werden die Leistungen in einem Service Level Agreement oder einem entsprechenden Kooperationsvertrag festgelegt, die in diesem Fall jedoch die Verbindlichkeit kommerzieller Verträge haben.

Ein erstelltes Angebot ist zum Beispiel eine klar definierbare Teilleistung im Gesamtprozess, die eindeutig identifiziert werden kann. Sie ist erbracht, wenn das Angebot inklusive der Kalkulation, Bepreisung, den kommerziellen Bedingungen, der Freigabe und Unterschrift etc. vorliegt. Ebenso ist es mit der Anlage eines Auftrags: Auch hier ist der komplette im Auftragssystem erfasste Auftrag mit allen Positionen, Mengen, Preisen, Auftraggeber-, Zustellungs- und Rechnungsadressen sowie verifizierten Lieferterminen und einer an den Kunden geschickten Auftragsbestätigung eine klar umrissene Teilleistung, die identifiziert und abgegrenzt werden kann. Identifizierbare Teilleistungen sind also das wesentliche Kriterium für das Schneiden von Teilprozessen.

Abb. 25: Teilprozessabgrenzung über klar identifizierbare Teilleistungen

88


Analog wie schon bei der Prozessidentifikation auf der obersten Ebene stellt sich natürlich auch hier die Frage nach der richtigen Aggregation von Leistungen. So ist es etwa denkbar, ein erstelltes Angebot und einen erfassten Auftrag als eigenständige Teilleistungen zu differenzieren oder eine erstellte Faktura und eine erfolgte Zustellung eines Produkts. Ebenso könnten aber auch die Teilleistungen „finalisiertes Angebot und Auftrag“ oder „verrechnete und zugestellte Lieferung“ definiert werden. Das wesentliche Kriterium, das hier Anwendung findet, ist die klare Abgrenzbarkeit der Teilleistung. Können Angebot und Auftrag klar unterschieden werden und werden sie weitgehend unabhängig voneinander erstellt und bearbeitet, so ist eine Trennung dieser Teilleistungen und damit eine Aufteilung in die Prozesse „Angebot erstellen“ und „Auftrag erfassen“ sinnvoll. Sind beide jedoch so ineinander verwoben, dass eine klare Abgrenzung nicht möglich oder nicht sinnvoll ist, so sollten beide Prozessschritte in einem Teilprozess „Angebot und Auftrag bearbeiten“ zusammengefasst werden. Analog gilt dies auch für das Beispiel der Fakturierung und Lieferung: Sind beide so ineinander verwoben, dass eine sinnvolle Abgrenzung der beiden Teilleistungen nicht möglich ist – etwa, weil die Faktura gleichzeitig mit den Lieferpapieren erstellt und gedruckt sowie mit der Lieferung selbst zugestellt wird – so ist ein gemeinsamer Teilprozess „Lieferung fakturieren und zustellen“ abzugrenzen. Erfolgt etwa auch das Kassieren des Preises direkt bei der Zustellung, so ist auch dieses in den Teilprozess aufzunehmen. Ein zweites Kriterium für die Abgrenzung von Teilprozessen, das ergänzend herangezogen werden kann, sind Zählerwechsel bzw. Wechsel in der Aggregation bei den Objekten der Verrichtung. Zum Beispiel werden in einem Unternehmen Aufträge einzeln angenommen, dann gemeinsam einmal pro Woche geplant, gebündelt nach bestimmten Losen gefertigt und dann wieder einzeln ausgeliefert. Der jeweilige Zähler des Durchlaufes bzw. die Aggregation des Verrichtungsobjekts wechselt hier: Bei der Auftragsannahme erfolgt der Durchlauf je Geschäftsfall, bei der Planung einmal für alle aktuellen Geschäftsfälle in einem bestimmten Stadium, in der Fertigung dann für mehrere Geschäftsfälle gemeinsam in einem Los und am Ende in der Auslieferung wieder je Geschäftsfall. Die Fakturierung hingegen erfolgt vielleicht für einen Kunden jeweils für alle Geschäftsfälle eines Monats. Überall, wo der Durchlaufzähler wechselt und Geschäftsfälle für bestimmte Teilprozesse anders zusammengefasst und aggregiert werden, empfiehlt es sich, einen eigenständigen Teilprozess abzugrenzen. Dies erleichtert zum einen wieder die Definition des Ergebnisses des jeweiligen Teilprozesses. Zum anderen schafft es auch eine saubere Grundlage für spätere Datenanalysen der Teilprozesse, insbesondere auch für Prozesskostenanalysen und Simulationsläufe, bei denen dem Durchlaufzähler eine wesentliche Rolle zukommt und dieser innerhalb eines Teilprozesses konstant bleiben muss.145 145 Vgl. dazu auch Mayer (1996), der einen Hauptprozess als eine Kette homogener Aktivitäten versteht, die demselben Kosteneinflussfaktor unterliegt (S. 49).

89


Abb. 26: Teilprozessabgrenzung über unterschiedliche Zähler

Ein drittes, weniger inhaltlich-methodisches als eher pragmatisches Kriterium zum Schneiden von Teilprozessen ist die Anzahl der Teilprozesse. Ein wesentliches Ziel von Prozessmodellen ist es ja – analog zu Modellen generell – die Komplexität der Realität soweit zu vereinfachen, dass ein besseres Verständnis und damit auch in weiterer Folge ein besseres Zusammenspiel und eine bessere Steuerung der Abläufe erreicht wird. Es wäre daher generell wenig zielführend, einen Prozess in nur ein bis zwei oder aber in mehr als 20 Teilprozesse zu zergliedern. Ersteres würde wenig Erkenntnisgewinn gegenüber dem aggregierten Prozess selbst bringen, letzteres würde ab einer gewissen Anzahl von Teilprozessen zu einem Verlust an Übersicht führen. Eine zu geringe oder zu hohe Anzahl von Teilprozessen bei der Detaillierung ist daher aus pragmatischen Gründen wenig sinnvoll, weil es ab einem bestimmten Punkt die Zielsetzung der Modellerstellung zur Komplexitätsreduktion konterkariert. Es ist jedoch festzuhalten, dass dieses Kriterium den anderen beiden inhaltlichen Kriterien nachgelagert ist und es im konkreten Einzelfall durchaus Fälle geben kann, in denen es trotz allem sinnvoll sein kann, die Detaillierung mit sehr wenigen oder aber einer größeren Anzahl von Teilprozessen vorzunehmen. Die angeführten Kriterien verstehen sich als Versuch, das Schneiden von Prozessen aus dem Dunstkreis der mystischen Kunstfertigkeit ein wenig in den Bereich rationaler Kriterien zu holen. Mit der klaren Orientierung an Teilleistungen, dem Kriterium der möglichst klaren Abgrenzbarkeit dieser Teilleistungen, dem Zähleroder Aggregationswechsel bei den bearbeiteten Objekten sowie dem Hilfskonstrukt der Anzahl der Teilprozesse wurden einige Kriterien erarbeitet, die hier als Anhaltspunkt dienen können. Im aktuellen Stadium der Entwicklung dieser Kriterien sind sie sicher noch nicht perfekt für eine saubere kriterienbasierte Teilprozessabgrenzung und können daher die fachliche Arbeit und das Wissen der Prozessgestalter noch nicht ersetzen. Es ist jedoch ein erster Ansatz in diese Richtung, und es bleibt zu hoffen, dass dieser Versuch die Diskussion um sinnvolle Abgrenzungskriterien anstößt und so zu einem späteren Zeitpunkt entweder die hier angeführten Krite-

90


rien noch besser definiert und operationalisiert werden oder aber auch andere, noch bessere und konkretere Kriterien für das Schneiden von Teilprozessen vorliegen werden. 2.3.7 Prozessvarianten

Was die Frage nach Prozessvarianten betrifft, so kann diese mit der entwickelten Endto-End-Definition von Geschäftsprozessen sehr klar beantwortet werden: Überall, wo ein und dieselbe Leistung durch eine etwas anders geartete Ablauffolge erbracht wird, die Leistung als Ergebnis des Geschäftsprozesses zum Adressieren des auslösenden Bedarfs jedoch dieselbe ist, liegt eine Prozessvariante vor.146 Das Verbindende zwischen Prozessvarianten ist somit derselbe vorausgehende Bedarf und dasselbe Prozessergebnis; der Unterschied zwischen Ihnen liegt im Weg dorthin. Derartige Prozessvarianten können in der Praxis zum Beispiel durch folgende Umstände entstehen bzw. bedingt sein: · · · · · ·

andere Vertriebswege andere Fertigungstiefe bzw. Fremdzukauf satt Eigenfertigung verschiedene Kundensegmente kundenspezifische Abwicklungen Länderspezifika in der Abwicklung etc.

Wird etwa ein Bedarf nach bestimmten Materialien – bspw. Salz für die Winterstreuung auf den Straßen – durch eine Eigenfertigung – in diesem Fall: Salzabbau – erbracht, in manchen Fällen, etwa bei einem kurzfristigen, die Förderung übersteigenden Bedarf auch durch einen Zukauf bedient, so liegen zwei Prozessvarianten vor. Wird ein und dasselbe Produkt – nehmen wir beispielsweise ein Buch – einmal über den Buchhandel und parallel dazu über etablierte Internetplattformen vertrieben, so liegen zwei Prozessvarianten vor. Ebenso, wenn ein bestimmtes Produkt normalerweise über den Großhandel vertrieben wird, mit einem speziellen Kunden aufgrund der hohen Volumina aber eine Fertigung direkt auf seinem Betriebsgelände vereinbart ist.

146 Vgl. dazu auch Klimmer (2007, S. 96): Auch er spricht von Prozessvarianten im Zusammenhang mit unterschiedlichen Ablauffolgen. Anders Speck, Schnetgöke (2008, S. 208): Für sie ist eine Prozessvariante ein Prozess, der grundsätzlich denselben Ablauf darstellt, jedoch durch die Beschreibung dieser Abläufe für verschiedene Prozessobjekte Unterschiede in detaillierten Prozessstrukturen aufweist. Ebenso abweichend Kugeler, Vieting (2008), für die Prozessvarianten dieselbe zeitlich-logische Abfolge aufweisen und sich nur in den zugeordneten Stellen oder Organisationseinheiten unterscheiden (S. 251).

91


2.3.8 Prozessarchitektur und Detaillierungstiefe

Aus der Übersicht über die Leistungserstellungs-, Steuerungs- und Bereitstellungsprozesse sowie deren Detaillierung auf darunter liegenden Ebenen ergibt sich die Prozessarchitektur. Alle diese Prozessdefinitionen und -darstellungen bilden in Summe das Prozessmodell eines Unternehmens bzw. einer Organisation. Zur Unterscheidung der Ebenen hat sich vielfach auch eine differenzierte Benennung in Geschäftsprozesse, Hauptprozesse und Teilprozesse etabliert. Diese differenzierte Benennung hat vor allem einen pragmatischen Grund: die leichtere Unterscheidbarkeit der Ebenen in der Kommunikation zwischen den Beteiligten. Denn faktisch handelt es sich nur bei den Prozessen auf der obersten Ebene um End-to-End-Geschäftsprozesse, bei jeder wie auch immer gearteten weiteren Untergliederung dieser Geschäftsprozesse hingegen um Teilprozesse. Damit wird zum Ausdruck gebracht, dass jeder von ihnen nur einen Teil zur Gesamtleistung des Gesamtprozesses beiträgt oder beisteuert. Nur der Gesamtprozess geht tatsächlich vom einen Ende des Kundenbedarfs bis zum anderen Ende der kompletten Leistungserbringung und des betreffenden Geschäftsfalles. Werden jedoch alle Prozesse auf den Detaillierungsebenen des Prozessmodells als Teilprozesse bezeichnet, so ist es in der Diskussion oft schwierig sofort zu verstehen, auf welcher Detaillierungstiefe man sich gerade befindet. Insofern ist es durchaus sinnvoll, den Teilprozessen je Ebene eine unterschiedliche Bezeichnung zu geben. Vielfache Verwendung findet dabei die Benennung als Hauptprozesse und Teilprozesse für die Detaillierungsebenen 2 und 3. Für darunter liegende Detailbeschreibungen von Teilabläufen werden häufig die Begriffe detaillierter Process Flow, Workflow oder auch Detailprozess verwendet. Die unten im Überblick dargestellten Bezeichnungen stellen daher nur einen Vorschlag dar, der auch individuell angepasst werden kann. Um die Prozessarchitektur und den Zusammenhang der Prozessmodelle innerhalb dieser darzustellen, hat sich der Vergleich mit einer geographischen Landkarte bewährt: Die Prozessübersicht auf der obersten Ebene wäre dabei mit einer Weltkarte

Abb. 27: Prozesstypen und -bezeichnungen auf den Ebenen

92


vergleichbar, die Detaillierung jedes dieser Leistungserstellungs-, Steuerungs- und Bereitstellungsprozesse dann mit einer Karte eines Kontinents; die Detaillierung der Hauptprozesse in Teilprozesse kann dann mit Länderkarten verglichen werden; die Verfeinerung der Teilprozesse in Detailprozesse hingegen mit Karten einer Region oder Stadt, die noch detaillierteren Workflows dann mit Detailkarten von speziellen Straßenzügen. Dieser Vergleich mit geographischen Karten enthält auch einen ganz essenziellen Punkt, der in der Praxis bei der Erstellung von Prozessmodellen oft vernachlässigt wird: nämlich die vertikale inhaltliche Konsistenz. Darunter wird verstanden, dass der Inhalt auf den verschiedenen Ebenen grundsätzlich genau derselbe ist: Es handelt sich bei den verschiedenen Karten immer um die Erde bzw. im Prozessmanagement immer um die Geschäftsprozesse eines Unternehmens oder einer Organisation. Unterschiedlich ist jeweils nur der Ausschnitt, der betrachtet wird und damit verbunden auch die größere Detaillierungstiefe (der „Zoomfaktor“). Anders formuliert: Die Karten eines Kontinents, eines Landes, einer Stadt oder eines Straßenzuges bilden jeweils genau dieselbe Realität ab, sie zeigen nur unterschiedlich große Ausschnitte davon und einmal mehr und einmal weniger Details. Die Karten sind unter sich in der vertikalen Detaillierung jedoch inhaltlich konsistent. Es wäre nicht möglich, auf einer Länderkarte eine Stadt zu zeigen, die sich auf der übergeordneten Karte des Kontinents in einem ganz anderen Land befindet. Die vertikale Konsistenz von Prozessmodellen geht aber sogar noch weiter als jene von geographischen Karten. Denn bei letzteren ist es wegen der Überlappung von Ländern und Kontinenten sowie dem Faktum, dass Karten rechteckig sind, durchaus

Abb. 28: Prozessarchitektur

93


Abb. 29: Vertikale Konsistenz in der Prozessarchitektur

üblich, bestimmte Regionen auf mehreren Karten zu zeigen oder bei der Detaillierung auch einmal über den Ausschnitt der übergeordneten Karte hinauszugehen. Als Beispiel sei nur eine Asienkarte genannt (Level 1), die zum Beispiel nur einen Teil der Türkei zeigt, und eine detailliertere Karte der Türkei (Level 2), die das komplette Land inklusive des europäischen Teils zeigt; oder aber das Faktum, dass Bayern sowohl natürlich auf jeder Deutschlandkarte aber auch aufgrund der schuhförmigen Gestalt Österreichs zumindest zum Teil auch auf jeder Österreichkarte aufscheint. Bei der Detaillierung der Prozessmodelle sollte dies nicht so sein. Hier muss ein Detailmodell immer genau dieselben Grenzen haben, wie der Prozess oder Teilprozess, der damit detailliert wird.147 Wird ein Prozess auf einer Ebene an einer bestimmten Stelle geschnitten, so muss sich dieser Schnitt auch genau an derselben Stelle auf den darunter liegenden Detailmodellen wieder finden. Das ist wichtig, damit im Prozessmodell redundante Überlappungen und Lücken vermieden werden. Dies erleichtert zum einen die weitere Arbeit mit den Modellen und stellt die konsistente Wartung und Weiterentwicklung sicher. Zum anderen – und dies ist der viel wichtigere Punkt – ist bei der Zuteilung von Prozessverantwortungen für die Prozesse und Teilprozesse nur so gewährleistet, dass diese klar und überlappungsfrei definiert werden können. Um diese Konsistenz der Teilprozesse auf den detaillierteren Ebenen sicher zu stellen, also Lücken und Überlappungen zwischen aufeinanderfolgenden Teilprozes147 Thomas Davenport vertritt hier eine gegensätzliche Meinung (1993, S. 30): Für ihn muss das Herunterbrechen von breiten Prozessen auf ihre Subprozesse nicht perfekt sein: “a narrow process, for example, could cut across two broader processes”.

94


Abb. 30: Konsistentes Herunterbrechen der Prozesse

sen zu vermeiden, empfiehlt sich ein Top-down-Vorgehen in der Erstellung des Prozessmodells, bei dem die jeweiligen Vorgänger- und Nachfolgerprozesse als Prozessschnittstellen auf die nächste Detaillierungsebene mitgenommen werden. Eine der wesentlichen Schwierigkeiten bei der Erstellung eines Prozessmodells ist dabei das Sicherstellen von einigermaßen vergleichbaren Detaillierungstiefen auf den einzelnen Ebenen. Gerade dies ist jedoch einfach gesagt, in der Praxis aber nur äußerst schwer zu erreichen.148 Der Grund hierfür ist, dass die richtige Detaillierungsstufe kaum durch objektive Kriterien definiert werden kann. In der Praxis finden wir häufig Prozessmodelle, bei denen zum Beispiel der Teilprozess „Bestellung anlegen“ für einen Geschäftsprozess – zum Beispiel den Marketingprozess bei dem Leistungen von Marketingagenturen zugekauft werden – auf Ebene 3 zu finden ist; in einem anderen Geschäftsprozess – zum Beispiel einem Wartungsprozess für Maschinen, finden wir einen analogen Teilprozess „Bestellung anlegen“ erst auf Ebene 4. Natürlich handelt es sich nicht um den gleichen Teilprozess, denn einmal werden Marketingleistungen bestellt, das andere Mal Verschleißteile für Wartungsarbeiten. Dennoch würde man annehmen, dass beide aufgrund ihrer inhaltlichen Ähnlichkeit – bei beiden handelt es sich schließlich um Bestellvorgänge – eine vergleichbare Detaillierungstiefe haben und daher auf derselben Ebene aufscheinen sollten. 148 Vgl. Schwegmann, Laske (2008, S. 170), die ebenso darauf hinweisen, dass in der Prozessmodellierung ein einheitlicher Detaillierungsgrad anzustreben ist. Wie viele andere Autoren geben jedoch auch sie keine praktischen Hinweise, wie dies erreicht werden kann.

95


Mögliche Anhaltspunkte für eine vergleichbare Detaillierungstiefe sind: · · · ·

die Ressourcenbindung im Prozess die Ähnlichkeit der Teilprozesse die Ebene der Unterstützung in bestimmten IT-Systemen die Anzahl der Teilprozesse bei der Detaillierung

Als näherungsweise Maßzahl kann die Anzahl der im Teilprozess gebundenen Personalkapazitäten in Form von Vollzeitäquivalenten (FTE) herangezogen werden. Das heißt, die geschnittenen Teilprozesse sollten in etwa vergleichbare Ressourcenbindungen aufweisen. Dies schafft Teilprozesse mit vergleichbaren Kostenblöcken und erleichtert so in vieler Hinsicht die Vergleichbarkeit und die weitere Analyse im Zuge der Optimierung der Prozesse. Als grober Anhaltspunkt ist dies daher sicher ein praktikables Kriterium als Richtwert. Aber auch hier gilt, dass inhaltliche Kriterien vorgehen. Gibt es sinnvoll abgrenzbare Teilleistungen, so kann es im Einzelfall auch sinnvoll sein, bestimmte Teilprozesse doch mit abweichenden Ressourcenbindungen zu definieren. Ein zweites mögliches Kriterium ist die Vergleichbarkeit der Teilprozesse. Wie am obigen Beispiel der Bestellvorgänge illustriert, werden Teilprozesse, denen ähnliche Prozessschritte zugrunde liegen, von den Nutzern des Prozessmodells als in der Detaillierung vergleichbar gesehen. Bestellvorgänge, Fakturierungsvorgänge oder Liefervorgänge sowie bestimmte Verbuchungen von Geschäftsfällen sollten daher nach Möglichkeit auf ein und derselben Ebene im selben Detaillierungsgrad zu finden sein. Dies spielt auch mit dem dritten Hilfskonstrukt zusammen, das herangezogen werden kann: der Ebene der Unterstützung in bestimmten IT-Systemen. So kann es etwa helfen, die Ebene vier oder fünf mit den Transaktionsschritten des benutzten IT-Systems gleichzusetzen. Eine derartige Festlegung ist durchaus hilfreich, da die Ersteller des Prozessmodells diese Transaktionen meist kennen und sie gefühlsmäßig auf derselben Detaillierungsstufe einordnen. Allerdings ist hierbei auch Vorsicht geboten, da auch bei den Transaktionen von Systemen nicht immer dieselbe Flughöhe gegeben ist. So gibt es auch hier teilweise sehr detaillierte Transaktionen und daneben auch Sammeltransaktionen, die ein sehr weites Feld an Buchungen unterstützen. Ein viertes Hilfskonstrukt für eine vergleichbare Detaillierungstiefe ist eine Vorgabe der maximalen Anzahl von Teilprozessen je Ebene. Wird diese zum Beispiel auf maximal 10 Teilprozesse beschränkt, so darf der gesamte Umfang des zu detaillierenden Prozesses nur auf höchstens zehn Teilschritte unterteilt werden. Jedoch hilft dieses Formalkonstrukt auch nur bedingt, da die Vorgabe ja nicht vorschreibt, wie der Prozess unterteilt wird. Anstatt einer Unterteilung in zehn etwa gleich große Teilprozesse wäre also auch eine Untergliederung in neun etwas größere und einen sehr kleinen, detaillierten möglich. Dies würde die Regel erfüllen und doch zu einer ungleichen Detaillierung auf dieser Ebene führen. Gerade bei einer verteilten Erstellung 96


von Prozessmodellen kann diese Hilfestellung jedoch durchaus auch ein sinnvolles Hilfsmittel sein. Die beschriebenen Ansätze zur Sicherstellung einer vergleichbaren Detaillierungstiefe sind, wie klar ersichtlich, keine harten Kriterien, sondern vielmehr Hilfskonstruktionen. In der Praxis kann es durchaus hilfreich sein, derartige Größen als Richtwerte für die Definition von Teilprozessen an die Prozessteams auszugeben. Sie sollten jedoch nicht zu sklavisch befolgt, sondern immer mit einer klaren Priorität auf dem Prozessinhalt und den definierten Kernelementen für Prozesse und Teilprozesse angewendet werden. Die besten Ergebnisse im Sinne der Vergleichbarkeit der Detaillierungstiefe werden in der Praxis dadurch erzielt, dass die Prozesserhebung durch organisatorische Vorkehrungen entsprechend gelenkt wird: ·

·

·

zum einen durch die Unterlegung der Detaillierungsebenen durch Good-PracticeBeispiele. Dabei ist es durchaus sinnvoll, nicht nur ein illustratives Beispiel zu benennen, sondern mehrere typische Teilprozesse auf die entsprechenden Ebenen zuzuordnen und diese auch in entsprechenden Meetings allen Beteiligten vorzustellen und zu zeigen. Diese Beispiele illustrieren dann, welche Detaillierungstiefe auf den jeweiligen Ebenen geplant ist und erwartet wird. Verantwortliche für die Erhebung von anderen Teilprozessen können sich dann daran orientieren. Dieses „management by example“ hilft erfahrungsgemäß mehr als genaue Beschreibungen der einzelnen Ebenen, die von den Beteiligten häufig nicht gelesen werden. Ein zweites prozedurales Hilfsmittel ist eine sequentielle Erarbeitung des Prozessmodells. Meist stehen Projekte zur Erhebung von Prozessen unter hohem Zeitdruck. Da das Modell meist nur Basis und Ausgangspunkt für weitere Zielsetzungen ist (z. B. Optimierungen, Systemeinführungen, . . .) und diese Ausgangsbasis anders als ein Organigramm aber nicht griffbereit vorliegt, muss die Erstellung häufig sehr rasch erfolgen. Um dem gerecht zu werden, erfolgt die Detaillierung der einzelnen Geschäftsprozesse meist parallel durch verschiedene Teams, was zur Folge hat, dass oft zu wenig Zeit für einen kontinuierlichen Abgleich der Detaillierungstiefe bleibt und man sich auch kaum an einem internen Best-practiceBeispiel orientieren kann. Abhilfe bringt hier eine weniger enge zeitliche Planung sowie eine sequentielle Detaillierung der Geschäftsprozesse, bei der man die Ebenendefinition im Zuge der Detaillierung der ersten Prozesse noch schärfen und konkretisieren und diese Beispiele dann als Leitlinie für die Detaillierung der weiteren Prozesse heranziehen kann. Als dritter, sehr effektiver Ansatz hilft ein kleines, zentral geführtes und konstantes Team, das die Prozesserhebung mit den jeweiligen Bereichen und Abteilungen vornimmt, moderiert und koordiniert. Durch diese personelle Kontinuität kann das Wissen über die Detaillierungstiefen der bereits erstellten Prozessmodelle für weitere genutzt und so eine bessere Vergleichbarkeit erzielt werden. 97


Generell sollte man versuchen, mit insgesamt maximal fünf Detaillierungsebenen auszukommen. Alle Prozesse sollten dabei zumindest auf die Ebene zwei, eventuell drei heruntergebrochen werden. Ob sie darüber hinaus noch weiter detailliert werden, hängt von der verfolgten Zielsetzung ab. Werden die Prozessmodelle etwa als Organisationshandbuch, für konkrete Verfahrensanweisungen oder als Grundlage für die Einführung und Schulung von neuen IT-Applikationen verwendet, so ist eine größere Detaillierung (bis auf Ebene vier oder fünf ) notwendig. Bei Prozessen, wo dies nicht der Fall ist, sollte bereits mit Ebene zwei oder drei das Auslangen gefunden werden.149 Werden im Zuge von speziellen Projekten – zum Beispiel IT-Einführungsprojekten – detailliertere Prozessmodelle erstellt, so heißt dies nicht zwingend, dass diese in der Folge auf diesem Detaillierungsniveau aktuell gehalten werden müssen. Vielmehr ist jeweils von Fall zu Fall zu entscheiden, ob man die betreffenden Modelle dauerhaft in die Gesamtprozessarchitektur integrieren und damit auch aktuell halten will oder nicht. Eine mutige Entscheidung, bestimmte Modelle, die nur projektspezifisch benötigt wurden, nicht in die Prozessarchitektur aufzunehmen und nicht kontinuierlich zu pflegen, wird leider viel zu selten bewusst getroffen, sondern erst im Laufe der Zeit von der faktischen Entwicklung herbeigeführt. Technisch sollte die Erstellung eines Prozessmodells über mehrere Ebenen mit einem entsprechenden Prozessmanagement- oder Prozessmodellierungstool unterstützt werden. Rein inhaltlich gesehen kann dies natürlich auch mit den üblichen Mitteln der Officedokumentation (z. B. Textverarbeitungssystemen, Tabellenkalkulationssystemen oder Präsentationssoftware) erfolgen. Angesichts der Vielzahl der Modelle, die bei der Detaillierung der Geschäftsprozesse in mehreren Ebenen entstehen, und der großen Herausforderung, die Schnittstellen zwischen diesen sowie mehrfach vorkommenden Teilprozessen konsistent zu halten, empfiehlt sich jedoch der Einsatz von professionellen Tools, und zwar bereits bei der reinen Erstellung eines Prozessmodells selbst, unabhängig von späteren Optimierungsschritten. Es ist jedoch wichtig festzuhalten, dass derartige Tools dem Prozessteam die angesprochenen Problemstellungen und Herausforderungen der Prozessidentifikation und -detaillierung sowie in weiterer Folge das Managen der Prozesse nicht abnehmen können. Sie können einzig und alleine die Modellierungsarbeit effizienter machen und beim Auffinden von syntaktischen Inkonsistenzen unterstützen. Leider herrscht teilweise immer noch eine große Toolgläubigkeit vor, sodass oft mehr Interesse und Fokus auf dem jeweils gewählten Modellierungstool besteht als an den wirklichen Prozessinhalten und -zu149 Vgl. auch Bogaschewsky, Rollberg (1998, S. 220), für die die optimale Gliederungstiefe ebenfalls problemspezifisch zu bestimmen ist. Vgl. auch Österle (2010/1995), der in der Klarheit für alle am Prozess Beteiligten das wesentliche Kriterium für den notwendigen Detaillierungsgrad sieht: “a subprocess should be broken down until the flow is clear to the design team, the process circle and the process employees” (S. 91); im Umkehrschluss ist für ihn ein Prozess zu sehr detailliert, wenn aus der Detaillierung keine weiteren signifikanten Verbesserungen folgen und wenn die detaillierte Prozessbeschreibung von den am Prozess Beteiligten als überflüssig abgelehnt wird (S. 93).

98


sammenhängen.150 Fälle, wo die Frage nach dem Prozessmanagement im Unternehmen mit der Nennung des verwendeten Tools beantwortet wird, das Unternehmensprozessmodell vor allem unter dem Tool-Namen bei allen Mitarbeitern bekannt ist und sich interne Auseinandersetzungen vor allem um die Tool-Auswahl drehen, sind leider immer noch häufig anzutreffen.151 2.3.9 Modellierungsmethode

Die Frage, welche Modellierungsmethode zur Darstellung der Prozesse eingesetzt wird, ist dabei im Detail nicht so wesentlich, da die meisten heute etablierten Methoden die Grundelemente für ein sinnvolles Arbeiten mit Prozessen abdecken. Um dies herauszuarbeiten, soll zwischen dem Objektkonzept einer Methode und ihrer Notation unterschieden werden.152 Das Objektkonzept umfasst im Wesentlichen die Gruppe der für die Modellierung zur Verfügung stehenden Objekttypen sowie die Arten, wie diese untereinander in Beziehung gesetzt werden können. Anders als bei einem reinen Zeichnen von Prozessen werden hier bestimmte Objekttypen definiert, denen eine genaue betriebswirtschaftliche Bedeutung zugewiesen wird. Etwa die Objekttypen Prozessschritt, Ereignis oder Stelle. Die Bedeutung dieser Objekttypen ist genau definiert und voneinander abgegrenzt. Weiß man den Objekttyp eines Elements, so kann man seine Bedeutung im Rahmen der Methode unmittelbar verstehen, ohne dass dafür lange Erklärungen notwendig sind. Um die verschiedenen Objekttypen leicht erkennen zu können, werden ihnen bestimmte, klar definierte Symbole – die Notation – zugewiesen. So kann etwa ein Prozessschritt als Rechteck oder eine Verzweigung als Raute dargestellt werden. Ebenso könnten dieselben Objekte aber auch mit einem abgerundeten Rechteck und einem Kreis dargestellt werden. Jede Modellierungsmethode besteht also im Kern aus einer Liste definierter Objekttypen, den möglichen Beziehungen zwischen diesen Objekttypen sowie einem Set von Symbolen, mit dem die Objekt- und Beziehungstypen dargestellt werden und damit über ihre Form oder Farbe identifiziert werden können. 150 Vgl. Shoshana Zuboff zit. in Davenport (1993, S. 86): “There is still this childlike belief that technology will make things perfect”; ebenso Davenport (1993, S. 199, S. 207, S. 214–215); siehe auch Wilhelm (2007), S. 63: Seiner Ansicht nach kann die Frage, ob sich der Einsatz eines speziellen Modellierungstools lohnt, nicht allgemein beantwortet werden, sondern muss in jedem Fall individuell entschieden werden. Zu verschiedenen Arten der Prozessdokumentation in Textform, Tabellenform oder mit entsprechenden Modellierungsmethoden siehe Bergsmann in Horváth (2005), S. 53–60. Zu wichtigen Kriterien für die Auswahl von unterstützenden Softwaretools siehe Bergsmann, ebenda, S. 62–66; ebenso Rosemann, Schwegmann, Delfmann (2008), S. 90–93; Kuhlang (2010). 151 Vgl. dazu auch Rummler, Remias, Rummler (2010), die festhalten, dass “There is more interest in BPM software application packages than in the underlying processes” (S. 120). 152 Vgl. dazu auch Weske (2007), S. 77. Siehe dazu auch Weilkiens, Weiss, Grass (2010), die in den Unterlagen für die OCEB-Zertifizierung der OMG zwischen der konkreten Syntax (= Notation) und der abstrakten Syntax (= der Menge an definierten Objekttypen und deren strukturellem Zusammenhang) unterscheiden (S. 88).

99


In der Praxis entstehen dabei häufig sehr hitzige und langwierige Diskussionen über die Wahl der richtigen Modellierungsmethode, wobei Protagonisten der verschiedenen Methodenansätze jeweils ihre eigene Methode als die alleinig richtige promoten und verteidigen. Vergleicht man die einzelnen Methoden jedoch untereinander, so zeigt sich, dass sie im Großen und Ganzen alle die wesentlichen Elemente von Geschäftsprozessen abdecken. So verfügen alle gängigen Modellierungsmethoden über Objekttypen und Symbole für die wesentlichen Elemente eines Ablaufs. Hierzu zählen insbesondere: · · · · · · · ·

Prozessschritt (evtl. mit speziellen Formen für Entscheidungsschritte) Ereignis Verzweigungen Input Output Unterstützendes IT-System ausführendes Organisationselement (z. B. Stelle) Prozessschnittstellen als Absprungstellen zu anderen Prozessen

Der Unterschied liegt meist zum einen in der weiteren Differenzierung dieser Objekttypen – etwa der Unterscheidung zwischen manuellen und automatisierten Prozessschritten, der Ausdifferenzierung der Objekttypen nach verschiedenen Input- und Output-Arten oder der Zurverfügungstellung weiterer aufbauorganisatorischer Elemente neben der Stelle wie etwa Organisationseinheiten, Teams oder Rollen. Zum anderen liegt der Unterschied in ihrer Ergänzung um weitere, gänzlich andere Objekttypen, wie etwa Risiken, Kennzahlen, Kontrollpunkte, Wissenselemente oder Ähnliches. Dasselbe gilt auch für die Beziehungstypen. Auch hier sind es eine Handvoll grundlegender Beziehungen zwischen den genannten Objekttypen, die für ein sinnvolles Arbeiten mit Prozessen erforderlich sind. Soweit es daher das Objektkonzept betrifft, reichen die meisten Methoden für das grundsätzliche Erstellen eines Prozessmodells und für das Arbeiten mit den Prozessen aus. Erst dort, wo spezielle Anforderungen verlangt sind, werden weitere Objekttypen gebraucht. Da die meisten Anbieter von Prozessmodellierungstools aber auch auf die eine oder andere Weise eine kundenindividuelle Erweiterung des Objektkonzepts oder ihrer Objektbibliotheken anbieten, ist auch das meist keine harte Limitation. Abgesehen von diesen speziellen Objekttypen für besondere Zielsetzungen liegt der Unterschied zwischen den einzelnen Modellierungsmethoden damit vor allem in der Art der für die Objekte verwendeten Symbole. Während manche Methoden für die Prozessschritte Rechtecke einsetzen, verwenden andere abgerundete Rechtecke; für die Darstellung von Ereignissen finden sich abgerundete Rechtecke, Kreise oder Sechsecke, etc. Das schon fast banal wirkende Detaillierungsniveau dieser Formverwendung soll illustrieren, wie sinnlos in den meisten Fällen Methodendiskussionen in 100


Unternehmen sind. Für Anwendungen im High-End-Bereich mit sehr vielen speziellen Anforderungen macht die gewählte Methode sicher einen Unterschied – für 90% der Anwendungen in Unternehmen ist sie jedoch völlig irrelevant. Es entsteht daher vielfach der Eindruck, dass die Diskussion über die richtige Methode als Ersatzebene für die Diskussion über die jeweils präferierten Anbieter bestimmter Modellierungstools dient. Dabei ist jedoch zu bedenken, dass die heutigen Modellierungstools in der Konfiguration und Symboldarstellung schon sehr viel Flexibilität bieten. Anders als bei der Einführung der ersten Modellierungstools vor mehr als zehn Jahren ist daher die Wahl der jeweiligen Methode von der Wahl des betreffenden Tools heute weitgehend unabhängig. Als Beispiel müssen etwa heute im Modellierungstool ARIS nicht zwingend ereignisgesteuerte Prozessketten modelliert werden, und ebenso kann diese Methode in zahlreichen anderen Modellierungstools verwendet werden. Die Diskussion über die richtige Methode verdeckt dabei vielfach die wirklich wichtigen Themen des Prozessmanagements, wie etwa das eines richtigen End-to-End-Prozessverständnisses, der Verankerung der Prozessverantwortung in der Organisation oder des tatsächlichen Managens der Prozesse im Sinne eines echten Managementansatzes. Entscheidend ist bei der Wahl der Methode vielmehr, dass die verwendeten Symbole möglichst klar voneinander zu unterscheiden sind und von allen Adressaten leicht verstanden werden. Anknüpfungspunkte um dies sicherzustellen sind insbesondere Standardisierungsbestrebungen und weitverbreitete und bereits für viele Menschen bekannte Symbole. Unter den relevanten Standardisierungsbestrebungen ist hier vor allem die Business Process Management Notation – kurz: BPMN – zu nennen, mit der versucht wird, einen Standard für die Modellierung von Geschäftsprozessen zu schaffen.153 Dies ist sicherlich ein sehr sinnvolles und langfristig sehr nützliches Unterfangen. Problematisch ist jedoch, dass die BPMN sehr stark auf die direkte Nutzung von Modellen für das Generieren ausführbarer Software ausgerichtet ist. Hierfür wird ein Grad an Formalisierung und Exaktheit benötigt, den zumindest derzeit nur wenige Spezialisten leisten können. Insofern ist die BPMN in ihrer aktuellen Form selbst für BPMN-Experten nicht leicht anzuwenden154 und für Prozessmanager in den Unternehmen in einer formal exakten Anwendung vielfach zu komplex bzw. nur mit sehr intensiver Schulung einsetzbar. Dies sollte jedoch nicht davon abhalten, die in den Prozessmodellen verwendeten Symbole soweit möglich bereits an die BPMN anzu153 Für einen guten Überblick zur BPMN sowie ihrer praktischen Anwendung siehe Freund, Rücker, Henninger (2010). Ebenso Weske (2007), S. 205–225. 154 Siehe z. B. Freund, Rücker, Henninger (2010), S. XII. Eine weitere Limitation der BPMN ist, dass sie anders als andere Notationen Prozesse sehr stark innerhalb von Organisationseinheiten betrachtet und diese unternehmensübergreifend nur über den Nachrichtenfluss verbindet. Die organisationsübergreifende Sichtweise, die eine der Stärken des Prozessansatzes ausmacht, geht damit ein Stück weit verloren. Vgl. Weske (2007), S. 224.

101


gleichen, auch wenn man in der Syntax vielleicht noch nicht diese Exaktheit zugrunde legt, wie sie die BPMN verlangen würde. Über die Integration von BPMN in Prozessmanagementausbildungen werden vielleicht mittelfristig auch der Formalisierungsgrad und die Exaktheit dieser Notation leichter und weiter verbreitet sein. In Richtung der Object Management Group (OMG), welche die Standardisierung der BPMN übernommen hat und weiter treibt, wäre zu wünschen, dass man die Anwendung der BPMN nach verschiedenen Formalisierungsniveaus unterscheidet.155 Eine „light-Version“ der BPMN würde dann sicher sehr rasch Verbreitung finden und würde für den Bereich des Prozessmanagements vielfach ausreichen. Mit der „light-Version“ erstellte Prozessmodelle könnten bei Bedarf – dort wo es tatsächlich um eine Überführung in ausführbaren Programmcode geht – auf Basis des gesamten BPMNStandards komplettiert und weiter formalisiert werden. Zum Zweiten kommt in diesem Zusammenhang neben der BPMN auch den etablierten Normen über die Erstellung von Flussdiagrammen in der Informatik Bedeutung zu. Die DIN 66001 bzw. ISO 5807 (12) geben hier für den Bereich der Informatik standardisierte Symbole für die Erstellung von Flussdiagrammen zur Programmablaufplanung vor. Aufbauend auf diesen Normen sowie deren Anwendung bei der Darstellung von Prozessen im Rahmen der Erstellung von Qualitätsmanagementhandbüchern oder Systemanforderungsdokumenten, haben sich manche Symbole etabliert und werden heute auf breiter Basis verstanden. Hierzu zählen insbesondere die Raute für Verzweigungen im Ablauf, Rechtecke für die Darstellung von Prozessschritten oder ein gewellt abgeschnittenes Rechteck zur Darstellung von Dokumenten, die als Input oder Output dienen.156 Um eine möglichst leichte Lesbarkeit und Verständlichkeit zu gewährleisten und Missverständnisse zu vermeiden, sollte jede Methode diese Symbole in der vielfach vertrauten Bedeutung verwenden, keinesfalls jedoch in einer anderen. In Summe sollte ein Prozessmodell in einer Form dokumentiert sein, die den mit dem Prozessmanagement verfolgten grundsätzlichen und speziellen Zielsetzungen entspricht. Für die grundsätzlichen Zielsetzungen muss die Art der Dokumentation vor allem die Kommunikation über Prozessabläufe und -zusammenhänge erlauben, eine einheitliche Sprache für das Arbeiten mit Prozessen bereitstellen sowie das übergreifende Prozessdenken fördern. Wesentliche Kriterien an die verwendete Notation sind hierbei Klarheit, Verständlichkeit und Akzeptanz. Welche konkrete Methode dafür ausgewählt wird, ist dabei sekundär.157 Viel wesentlicher als dies ist vielmehr, dass die einmal gewählte Methode unternehmensweit 155 Man könnte sich dabei zum Beispiel am Ebenenkonzept der ARIS-Architektur von August-Wilhelm Scheer orientieren und den Formalisierungsgrad auf den Ebenen Fachkonzept, DV-Konzept und Implementierung unterschiedlich ausprägen. 156 Vgl. dazu z. B. auch Rudolf Wilhelm (2007), S. 44 ff. 157 Für weitere gut entwickelte Methoden siehe z. B. Ould (2005) mit seiner Riva Methode oder Scheer (1998) für die ARIS-Methode auf Basis von ereignisgesteuerten Prozessketten (eEPKs).

102


von allen Beteiligten einheitlich, konsistent und zielorientiert verwendet wird. In diesem Sinne ist ein Vorgehen zu empfehlen, das sich in vielerlei Hinsicht am wissenschaftstheoretischen Ansatz von Paul Feyerabend orientiert und nicht die Methoden in den Mittelpunkt rückt, sondern den zielorientierten Managementansatz. Paul Feyerabends im Rahmen der Analyse der Wissenschaftstheorie entwickeltes Diktum „anything goes“ in seinem Werk Against Method könnte – frei interpretiert – etwa folgendermaßen auf den Bereich der Prozessmodellierung angewendet werden: Es kommt nicht so sehr auf die konkret gewählte Methode an, sondern vielmehr auf die konsequente und zielstrebige Anwendung. Dazu gehört neben der methodischen Fundierung immer auch eine wesentliche Portion Überzeugungskraft, um andere von der neuen Sichtweise und von sinnvollen Änderungen zu überzeugen.158 Zusammenfassend sollte eine gewählte Modellierungsmethode folgende Kriterien erfüllen: · · · · · · ·

Abdeckung der grundlegenden Elemente eines Prozesses stringente Ableitung darüber hinaus gehender Anforderungen aus den gesetzten individuellen Zielen für das Prozessmanagement klare betriebswirtschaftliche Definition der verwendeten Objekte und Beziehungen Verwendung weit verbreiteter und etablierter Symbole in der gewohnten Bedeutung Orientierung an der BPMN – jedoch ohne zu weit gehender Übernahme der dort festgelegten hohen Formalisierungsanforderungen möglichst einfache Lesbarkeit und Verständlichkeit konsequente einheitliche Anwendung im gesamten Unternehmen

2.3.10 Prozessbeschreibung

Mit der Identifikation der Leistungserstellungs-, Bereitstellungs- und Steuerungsprozesse auf der obersten Ebene und ihrer konsistenten Detaillierung auf weiteren Ebenen ist das Grundgerüst für ein echtes End-to-End-Geschäftsprozessmodell erstellt. Jeder Geschäftsprozess ist in Teilprozesse untergliedert, und die Abfolgesequenz zwischen diesen ist definiert. Um die Prozesse auch für andere klar zu definieren und den Interpretationsspielraum über die Prozessgrenzen der Prozesse oder auch über die Zugehörigkeit verschiedener Prozessschritte zu den Teilprozessen möglichst gering zu halten, hat es sich in der Praxis bewährt, ergänzend zum reinen Ablaufbild Prozessbeschreibungen zu erstellen, die über die reine Abfolgelogik hinausgehen und wichtige Zusatzinformation zum jeweiligen Teilprozess enthalten. Hierzu gehört die kurze Ausformulierung der folgenden Elemente: 158 Vgl. Feyerabend (1993).

103


· · · ·

Ausgangsbedarf erstellte Leistung des Prozesses Kurzbeschreibung des Prozessumfangs gegebenenfalls Anwendungsbereich

Ausgangsbedarf und erstellte Leistung des Prozesses sind bereits ausführlich dargestellt worden. Um sicher zu gehen, dass auch andere einen bestimmten Prozess so verstehen wie beabsichtigt, sollten der Ausgangsbedarf des Kunden sowie die durch den Prozess erbrachte Leistung für den Kunden des Prozesses kurz ausformuliert werden, um über beide ein klares Verständnis zu schaffen. Dies gilt sowohl für die Geschäftsprozesse auf der obersten Ebene als auch für die Teilprozesse auf den darunter liegenden Detailebenen des Prozessmodells. Für den Teilprozess „Auftrag anlegen“ könnte das etwa der Bedarf sein, einen mit dem Kunden abgeschlossenen Auftrag transparent zu erfassen und zu dokumentieren, sodass er einerseits im Auftragsbestand erfasst ist und andererseits alle initialen Informationen, die zu seiner weiteren Bearbeitung notwendig sind, für weitere Teilprozesse zur Bearbeitung verfügbar sind. Die Leistung dieses Teilprozesses wäre es nun, diese wesentlichen Auftragsdaten in einer zentralen Datenbank für alle nachfolgenden Teilprozesse, die sich mit diesem Geschäftsfall befassen, zur Verfügung zu stellen. Die Kurzbeschreibung des Prozessumfangs ist eine Information, die bereits durch den Ausgangsbedarf, die erbrachte Leistung und die Benennung und Abfolgelogik des Prozesses gegeben ist. Da aber gerade die Bezeichnung von Teilprozessen und Prozessschritten in der Modellgraphik selbst aus Platzgründen sehr kurz sein muss, empfiehlt es sich den Prozess zusätzlich in ein paar wenigen Sätzen verbal zu beschreiben. Diese redundante Information soll dazu beitragen, die Identifikation des Prozesses sowie seine Grenzen zum Vorgänger- und Nachfolgerprozess noch einmal auf eine andere, zusätzliche Art festzuhalten, um so Missverständnissen vorzubeugen. Für den Beispielprozess „Auftrag anlegen“ könnte diese Kurzbeschreibung etwa so aussehen: Der Teilprozess „Auftrag anlegen“ beginnt mit dem Eingehen eines unterschriebenen Kundenauftragsformulars in der Innendienstabteilung und umfasst alle Schritte, die notwendig sind, um den Auftrag vollständig und transparent in der Auftragsdatenbank zu erfassen. Hierzu gehören insbesondere auch die Anlage des Kunden mit seinen Grundinformationen, falls es sich um einen Neukunden handelt, die Anlage aller Auftragspositionen mit Mengen und vereinbarten Preisen sowie die gewünschte Lieferadresse und der vereinbarte Lieferzeitpunkt. Der Prozess endet mit dem Speichern des komplett ausgefüllten Kundenauftragsformulars. Ab diesem Zeitpunkt sind alle erfassten Auftragsdaten für nachfolgende Prozesse verfügbar, und der Auftrag scheint im Auftragsbestand auf. Die hier beschriebenen Informationen zu einem Prozess werden – gemeinsam mit dem Prozessmodell und weiteren Informationen – in einem Prozesssteckbrief zusammengefasst. Mit diesem Prozesssteckbrief liegen die wesentlichsten Informationen für die Identifikation und erste Beschreibung des jeweiligen Prozesses oder Teil104


prozesses vor. Der Prozess ist damit auch für andere klar und verständlich identifiziert und abgegrenzt.159 Missverständnisse über den Inhalt von Prozessen oder die Zuordnung von Prozessschritten zu den Teilprozessen können so gegenüber der reinen Darstellung der Prozessabfolge in einem graphischen Modell deutlich reduziert werden. Zu einem späteren Zeitpunkt werden darin noch weitere Informationen zum Prozess – etwa bzgl. der Prozessverantwortung oder der Prozesssteuerung ergänzt. Für den Schritt der Prozessidentifikation sind die enthaltenen Informationen jedoch vorerst ausreichend. Technisch gesehen sollten Prozesssteckbriefe in dem Tool, mit dem das Prozessmodell erstellt wurde, als Informationen an den betreffenden Modellen hinterlegt werden (Modellattribute). Eine Ausgabe eines Prozesssteckbriefes auf Bildschirm oder in Papierform mit Angabe all dieser Informationen und der Modellgraphik sollte über eine entsprechende Reportfunktionalität des Tools erstellt werden. Eine manuelle Erstellung von Prozesssteckbriefen in einem Textverarbeitungssystem ist inhaltlich natürlich genauso möglich, vom Aufwand her jedoch ineffizient, sowohl in der Erstellung als auch in der laufenden Anpassung an Änderungen. Zudem sind Prozesssteckbriefe modellübergreifend ohne entsprechende Toolunterstützung kaum konsistent zu halten. Mit der erstellten Prozessdefinition, der Identifikation der Prozesse und ihrer konzeptionellen Darstellung in einem Prozessmodell auf mehreren Ebenen sowie der Detailbeschreibung der wichtigsten Informationen zu den Prozessen in Prozesssteckbriefen ist die Grundlage geschaffen für ein echtes End-to-End-Prozessmanagement. Ehe wir darauf aufbauend Prozessmanagement als Managementansatz konzipieren, soll im nächsten Abschnitt die Beziehung zwischen der entwickelten Prozesssicht und der aufbauorganisatorischen Struktur von Unternehmen und Organisationen hergestellt werden.

159 Vgl. dazu auch Hiller, Minar-Hödl, Zahradnik (2010), die hierfür eine gute Systematik für die Beschreibung der Grenzen von Prozessen in zeitlicher, sachlicher, räumlicher und sozialer Hinsicht anbieten (S. 97–103).

105

3 Prozessmanagement als Organisationselement 3.1 Möglichkeiten der Organisation von Unternehmen Traditionelles Prozessmanagement sieht sich meist als Alternative zur funktionalen Organisation160 im Sinne der Überwindung der funktionalen Silos.161 Dieses Bild der rein funktional organisierten Unternehmen ist heute aber nur mehr bedingt valide. Zwar hat das Bild der Silos unbestritten nach wie vor in vielen Unternehmen und Organisationen Gültigkeit, da in großen Bereichen nach wie vor Abgrenzungs- und Abschottungstendenzen beobachtet werden können. Aber die Silos sind schon lange nicht mehr nur funktional. Unternehmen verfügen heute über eine Vielzahl an differenzierten komplexen Organisationsstrukturen, in denen funktionale Aspekte nur eine mögliche Organisationsvariante sind. Prozessmanagement wird dabei vielfach gleichgesetzt mit einer Prozessorganisation162: einer ideal verstandenen Struktur der Aufbauorganisation, die sich vollständig an den Prozessen ausrichtet und damit alle Nachteile traditioneller Organisationsformen vermeidet. Ausgehend von der Annahme, dass Unternehmen funktional organisiert sind, wird daher ein 90-Grad-Shift der hierarchischen Organisationsstruktur auf eine Prozessorganisation gefordert.163 Auch diese Gleichsetzung greift zu kurz und reduziert Prozessmanagement auf den reinen Wegbereiter einer solchen idealen Prozessorganisation. Die Folge sind Ängste und Widerstände bei der Einführung von Prozessmanagement, da die Manager und Mitarbeiter einen Verlust von Macht und der gewohnten Aufbaustrukturen fürchten. Prozessmanagement muss jedoch keinesfalls zwingend zu einer Prozessorganisation führen. Abgesehen von diesen beiden Aspekten – der Überwindung funktionaler Silos sowie dem Ziel einer idealen Prozessorganisation als 90-Grad-Shift der bestehenden Funktionalorganisation – setzt sich der Großteil der Prozessmanagementliteratur jedoch nicht oder nur wenig mit den organisatorischen Grundfragen von Unterneh160 Der Organisationsbegriff wird hier in seiner instrumentalen (vgl. Klimmer 2007, S. 2 ff., Nicolai 2009, S 2 f., Spath 2009, S. 4) bzw. strukturalen (vgl. Mangler 2006, S. 3 f.) Bedeutung verwendet. 161 Vgl. z. B. Osterloh, Frost (2000), S. 29. 162 Der Begriff Prozessorganisation wird in Übereinstimmung mit der geläufigen Verwendung als Aufbauorganisation verstanden, welche die Gliederung anhand der Prozesse vornimmt, vgl. z. B. Hammer, Champy (1994) oder auch Osterloh, Frost (2000). Davon abweichend gibt es auch Autoren, die den Begriff Prozessorganisation mit dem Begriff Prozessmanagement gleichsetzen und darunter die gesamte Ablauforganisation verstehen sowie auch die Verantwortlichkeiten und Rollen zur Verbesserung der Prozesse (vgl. etwa Wilhelm 2007, Nicolai 2009, S. 18 oder S. 25). 163 Vgl. z. B. Osterloh, Frost (2000), S. 20 und S. 28 ff. Ebenso Hammer (1997, S. 13), für den das Reengineering in der Organisationsstruktur genau diese 90-Grad-Drehung auslöst.


107

Prozessmanagement als Organisationselement

men und Organisationen auseinander. Sie versucht nicht, differenzierte Antworten auf diese zu geben, und stellt vielfach auch keinerlei Verbindung zur bestehenden Organisationslehre her. Vielmehr wird die Prozessorganisation als ideales Zielbild im Sinne einer idealen Organisation, die alle Nachteile der traditionellen und bestehenden Organisation vermeiden würde, vorausgesetzt, ohne genau zu begründen, warum dies der Fall sein sollte. Dies ist umso erstaunlicher, als man eine neue Organisationsform ja daran messen müsste, ob sie die organisatorischen Grundfunktionen bisheriger Organisationsformen erfüllt und darüber hinaus auch noch einen signifikanten Mehrwert bietet. Dieser Mehrwert könnte vor allem in der Diskussion bestehender Organisationsansätze herausgearbeitet werden. Die bisherige Literatur zum Prozessmanagement tut – von wenigen Ausnahmen abgesehen164 – weder das eine noch das andere. Meist begnügen sich die Autoren damit, ein mehr oder weniger diffuses Idealbild einer Prozessorganisation zu zeichnen, um dann rasch auf praktische und methodische Details des Prozessmanagements überzugehen. Prozessmanagement in dieser Form ähnelt damit sehr rasch einer organisatorischen Heilsreligion, an die man entweder glauben muss oder eben nicht. Eine seriöse Analyse und Aufarbeitung des Themas muss jedoch genau von der organisatorischen Grundfragestellung ausgehen und danach fragen, welche Rolle der Ansatz des Prozessmanagements darin spielen kann. Im Folgenden wird daher versucht, dieses propagierte Ideal der Prozessorganisation von theoretischer und von praktischer Seite zu bewerten. Von theoretischer Seite werden hierfür allgemeine Ziele einer Organisationsstruktur herausgearbeitet und auf die Prozessorganisation angewandt. Von praktischer Seite wird versucht, die wenigen bekannten Beispiele für reale Prozessorganisationen unter die Lupe zu nehmen und gegen das Ideal einer Prozessorganisation auf der Basis von End-to-End-Prozessen zu spiegeln. 3.1.1 Allgemeine Ziele einer Organisationsstruktur

Was sind die organisatorischen Grundfragestellungen eines Unternehmens oder einer Institution? – Nun, einfach gesagt geht es dabei darum, warum ein Unternehmen oder eine Institution überhaupt eine Organisation im Sinne einer bestimmten Strukturierung welcher Art auch immer braucht und was diese bewirken soll. Nähern wir uns der ersten Fragestellung mit einem kleinen Gedankenexperiment: Stellen wir uns ein Unternehmen vor, das aus genau einem einzigen Mitarbeiter besteht, der wiederum genau einen einzigen Kundenauftrag hat. Stellen wir uns zusätzlich vor, dass der Auftrag ein ganz einfacher ist, z. B. das Fällen eines kleinen Baumes mit einer vorhandenen Axt. Braucht der Betreffende für die Bewältigung dieser Arbeit eine Organisation im Sinne einer Strukturierung und Koordination seiner Aufgabe? Wohl kaum. 164 Eine Ausnahme bilden hier teilweise z. B. Gaitanides (2007), Fischermanns (2006), Schober (2002), Mangler (2006) oder Kugeler, Vieting (2008).

108

Möglichkeiten der Organisation von Unternehmen

Erweitern wir das Experiment nun in verschiedene Richtungen: Wie sieht es zum Beispiel aus, wenn es nicht mehr um einen Baum geht, sondern um viele, sagen wir ein paar Hundert. Erweitern wir weiter und nehmen wir an, dass die Bäume nicht nur für einen Kunden gefällt werden, sondern für mehrere, verschiedene Abnehmer. Nehmen wir weiter an, dass es so viele Bäume sind, dass ein Mitarbeiter nicht ausreicht und das fiktive Unternehmen eine Vielzahl von Mitarbeitern benötigt, die zusammen und auch abwechselnd arbeiten müssen. Nehmen wir zudem an, dass es nicht nur um das Fällen der Bäume geht, sondern auch darum, das Holz in weiterer Folge zu Brettern zu verarbeiten und daraus Schiffe zu bauen. Denken wir uns schließlich noch, dass die Kunden nicht am selben Ort sind wie die Bäume und dass auch die notwendigen Arbeitsmittel erst erstellt oder beschafft werden müssen, um das kleine Gedankenexperiment abzuschließen. Es ist klar, dass dafür nun eine Strukturierung und Koordination der Arbeit in irgendeiner Form notwendig ist. Würden Hunderte von Mitarbeitern ohne Ordnung und Koordination Bäume fällen, um daraus Schiffe zu bauen, so würde das vermutlich sehr schnell ins Chaos führen.165 Die Notwendigkeit für eine Organisation im Sinne einer Strukturierung und Koordination der Arbeit folgt also aus der Komplexität der jeweiligen Aufgabe und der Anzahl der dafür notwendigen Beteiligten.166 Ist eine Aufgabe im idealtypischen Fall ganz einfach und kann von einem einzigen Beteiligten ohne große Planung erfüllt werden, ist keine Organisation erforderlich. Ist eine Aufgabe jedoch komplex, sodass sie nur durch das Zusammenwirken von vielen Beteiligten erfüllt werden kann, oder ergibt sich ihre Komplexität durch die Anzahl verschiedener Abnehmer, die räumliche Trennung, die komplizierte Beschaffung von Hilfsmitteln oder Rohstoffen oder schlichtweg durch die Komplexität der Aufgabe an sich mit verschiedenen zu koordinierenden Teilschritten, so ist Organisation notwendig. Je komplexer eine Aufgabe und je mehr Beteiligte zu Ihrer Erfüllung notwendig sind, desto mehr Bedarf besteht an einer sinnvollen Organisation bzw. desto größer ist der Nutzen einer solchen.167 Es ist darum nicht verwunderlich, dass wir die ersten bekannten Formen von Organisation in den großen Zivilisationen zum Erreichen großer Vorhaben, wie zum Beispiel dem Bau der Pyramiden oder der Führung von großen Heeren finden. Welche generellen Anforderungen aber muss eine solche Organisationsstruktur erfüllen? Aus dem beschriebenen Gedankenexperiment wurde bereits klar, dass sie die entstandene Komplexität für die Beteiligten reduzieren muss. Sie muss also Struk165 Vgl. Nicolai (2009), S. 39. 166 Vgl. Bogaschewsky, Rollberg (1998, S. 1), die den Grund für die Notwendigkeit der Schaffung von Organisationsstrukturen in der zielgerichteten Bewältigung von komplexen Gesamtaufgaben sehen. Ebenso Wagner, Patzak (2007), die die Notwendigkeit von Prozessorientierung in Unternehmen anhand eines Modells verschiedener Lebensphasen von Unternehmen herausarbeiten (S. 44 ff.). 167 Vgl. Frese (1995). Frese stellt in Anlehnung an Herbert Simon jedoch stark auf die Entscheidungskomplexität ab und weniger auf die Komplexität der Aufgabenausführung.

109


turen schaffen, die das Verhalten der einzelnen Beteiligten so ordnen und beeinflussen, dass trotz hoher Komplexität am Ende die Zielsetzung des Unternehmens oder der Institution möglichst effektiv und effizient erreicht wird. Im Detail tut dies eine Organisationsstruktur durch die Erfüllung folgender Funktionen:168 ·

·

Gliederungsfunktion (Differenzierung) Eine Organisationsstruktur muss die Aufgabe eines Unternehmens oder einer Institution in überschaubare Teile herunter brechen, die für die verschiedenen Teams und die einzelnen Beteiligten verständlich und – zumindest mit entsprechender Einschulung – erfüllbar sind. Bleiben wir beim Beispiel des Schiffbaus, so ist es für einen Einzelnen – von wenigen Ausnahmetalenten ausgenommen – kaum vorstellbar, wie man ein Schiff bauen soll. Erst durch die Gliederung der finalen Aufgabe – den Bau eines Schiffes – in verschiedene detaillierte Teilaufgaben wird die Aufgabe handhabbar und umsetzbar. Eine Organisationsstruktur muss diese Gliederungsaufgabe erfüllen und die Komplexität der Aufgabe auf handhabbare Teilaufgaben reduzieren.169 Integrationsfunktion (Effektivität, Koordination) Ergänzend zur Gliederung der zu erfüllenden Aufgaben muss es eine Organisationsstruktur ermöglichen, dass alle Beteiligten in ihren Aktivitäten zum Erreichen 168 Die ersten beiden Funktionen finden sich in der Literatur häufig als Probleme der Differenzierung und der Integration. Siehe z. B. Scheyögg (2006), S. 112 ff. Ebenso häufig werden die Sicherstellung von Effektivität und Effizienz als Grundfunktionen der Organisation angeführt. (vgl. z. B. Spath 2009, S. 7; Schmidt 2006, S. 17–18; Mangler 2006, S. 4). Nicolai (2009, S. 9 f.) definiert etwas andere Aufgaben der Organisation, die aber zumindest in Teilen den hier angeführten entsprechen (effizienter Arbeitsvollzug, Reduktion Konfliktpotenzial, Machtverteilung, Grenzen des Unternehmens, Sicherung der Entwicklungsfähigkeit), jedoch auch Funktionen enthalten, die hier nicht als eigenständige Ziele der Organisation gesehen werden (z. B. einheitliches Auftreten, kreative Entfaltung der Mitarbeiter, Selbstorganisation der Mitarbeiter), sondern in anderen Grundfunktionen subsumiert werden. Die von Nicolai (2009, S. 14) an anderer Stelle definierten Anforderungen an Organisationen sind in den hier definierten weitgehend abgedeckt; In der klassischen Organisationslehre formulierte Kosiol für Organisationen die Grundprinzipien der Zweckmäßigkeit (bestmögliche Erfüllung der gesetzten Ziele), der Technizität (mengenmäßige Ergiebigkeit) und der Rentabilität (ökonomische Ergiebigkeit). Letztere sind hier mit dem Produktivitätskriterium abgedeckt. Siehe Schober (2002), 66). Kugeler, Vieting (2008) verfolgen einen ähnlichen Ansatz wie hier, indem auch für sie Organisationsstrukturen bestimmte Ziele erfüllen müssen. Als solche gehen sie in Anlehnung an Frese von den drei Effizienzkriterien der Koordinationseffizienz, der Anpassungseffizienz und der Motivationseffizienz aus (S. 228–234). Die ersten beiden werden auch hier als Kriterien definiert; die Motivationseffizienz wird hier hingegen nicht als eigenständiges Kriterium zugrunde gelegt, da die dahinter liegenden Aspekte einer effektiven Zusammenarbeit im Hinblick auf das Unternehmensziel sowie ein größtmögliches Engagement der Mitarbeiter bereits mit der Effektivität (Integrationsfunktion) und der Effizienz (Produktivitätsfunktion) abgedeckt sind. 169 In der Organisationslehre wird dies unter dem Begriff der Aufgaben- und Arbeitsanalyse zusammengefasst. Siehe z. B. Mangler (2006), der beides unter dem Begriff der Sachanalyse zusammenfasst (S. 15–17). Bei anderen Autoren hat hierfür auch der Begriff der organisatorischen Differenzierung etabliert (vgl. z. B. Nicolai 2009, S. 26 f.); Schreyögg (2006), S. 112 ff.

110


·

·

der Gesamtaufgabe des Unternehmens oder der Institution beitragen und sich nicht gegenseitig behindern oder gegeneinander arbeiten. Dies ist eine notwendige Ergänzung zur beschriebenen Gliederungsfunktion.170 Während die eine dazu dient, die Aufgabe in handhabbare Teilaufgaben zu gliedern, stellt die Integrationsfunktion sicher, dass die Teilaufgaben nicht isoliert voneinander oder gar mit gegenseitig negativer Beeinflussung erfüllt werden, sondern so zusammenspielen, dass am Ende die Gesamtaufgabe im Sinne der Leistungserbringung an die Kunden und den Markt erfüllt wird.171 Die Koordinations- und Integrationsfunktion reicht dabei auch über die Grenzen des eigenen Unternehmens hinaus und umfasst auch die Zusammenarbeit mit Lieferanten, Kunden und anderen Geschäftspartnern.172 Produktivitätsfunktion (Effizienz) Neben diesen beiden Punkten der Gliederung und Integration muss eine Organisationsstruktur ein möglichst effizientes Arbeiten unterstützen. Das heißt, sie muss durch die Art der Arbeitsgliederung und der Zuordnung von Ressourcen und Verantwortung eine Erstellung der Leistung ermöglichen, die mit möglichst optimiertem Aufwand auskommt. Eine Organisationsstruktur, die eine Aufgabe gut untergliedert und das Zusammenspiel der Beteiligten sehr gut integriert und koordiniert, dies aber nur um den Preis enormer zusätzlicher Planungs- und Koordinationsaufwände schafft, würde wenig bringen. Insofern ist auch das Effizienzkriterium bereits eine Grundfunktion für Organisationsstrukturen.173 Steuerungsfunktion (Führungseffizienz) Die Organisationsstruktur muss viertens einen Rahmen bieten, der es ermöglicht, die individuellen Arbeiten zum Erreichen der Aufgabe eines Unternehmens oder einer Institution zu planen, zu überprüfen und im Hinblick auf den Einsatz von Ressourcen und Material sowie die entstehenden Aufwände zu steuern. Dies ergibt sich wiederum aus der Entwicklung der Größe: Große Organisationen und Institutionen benötigen eine Vielzahl an Beteiligten und an Ressourcen, die irgendwie gesteuert werden müssen. Zur Steuerung gehören dabei sowohl die Planung und die Überprüfung der Arbeitsleistung als auch die zeitliche Einteilung 170 In der Organisationslehre wird dies vielfach unter dem Begriff der Aufgaben- und Arbeitssynthese beschrieben. Neuerdings hat sich dafür auch der Begriff der organisatorischen Integration etabliert (z. B. Nicolai 2009, S. 27); Schreyögg (2006), S. 112 ff. Kugeler, Vieting (2008) sprechen in diesem Zusammenhang von der Koordinationseffizienz (S. 229–231). 171 In der Organisationslehre wird hierfür meist das Ziel der Effektivität verwendet. Z. B. Spath (2009), S. 7. Vgl. dazu auch Nicolai (2009, S. 14), die die Markt- und Wettbewerbsorientierung als wesentliche Anforderung an Organisationen sieht. 172 Vgl. dazu Nicolai (2009), S. 14: Sie definiert Netzwerkfähigkeit als eine der wesentlichen Anforderungen an eine Organisation. 173 Vgl. Spath (2009), S. 7; Schmid (2006), S. 17–18; Mangler (2006), S. 4; vgl. auch Nicolai (2009, S. 14), die Finanz- und Sachressourceneffizienz als eine wesentliche Anforderung an eine Organisation sieht. Auch die von Nicolai geforderte Wettbewerbsorientierung von Organisationen wird durch die Produktivitätsfunktion als Effizienzkriterium teilweise subsumiert.

111


·

·

·

der Teams bis hin zur Vereinbarung von Abwesenheiten und Urlauben. Zur Steuerung gehört aber auch ganz generell die Beeinflussung von Verhalten durch die Struktur. Die Untergliederung, die durch die Organisationsstruktur erfolgt, muss damit nicht nur der Aufgabenuntergliederung dienen, sondern auch das Management der Aufgabenerfüllung sowohl im gesamten als auch für die Teilaufgaben unterstützen. Eine gute Organisationsstruktur muss dabei die Komplexität dieser Steuerungsaufgabe möglichst gering halten.174 Identifikationsfunktion (Loyalitätsstiftung) Als fünften Punkt muss eine Organisationsstruktur für alle Beteiligten auch einen Rahmen zur Identifikation bieten und die Möglichkeit zur Ausbildung von Loyalitäten geben, die der generellen Aufgabenerfüllung zweckdienlich sind. Diese Funktion von Organisationsstrukturen trägt der Tatsache Rechnung, dass Unternehmen und Institutionen keine rein technischen Konstrukte sind, sondern aus Menschen bestehen, die ein Bedürfnis nach Zugehörigkeit, Identifikation und Motivation zur Erfüllung Ihrer Teilaufgaben haben. Die Einheiten, die gebildet werden, müssen dem Rechnung tragen und dafür eine entsprechende Basis bieten. Stabilitätsfunktion (Nachhaltigkeit) Eine Organisationsstruktur muss, sechstens, zur Stabilität des Unternehmens beitragen.175 Damit ist die Eigenschaft gemeint gleichartige Geschäftsfälle in gleichartiger Weise abzuwickeln und auf gleichartige oder ähnliche Einwirkungen von außen unter vergleichbaren Randbedingungen standardisiert zu reagieren.176 Nur wenn eine gewisse Stabilität gegeben ist, kann eine Geschäftstätigkeit in effektiver und effizienter Form dauerhaft erfolgen. Anpassungsfunktion (Flexibilität) Eine Organisationsstruktur muss in der Lage sein, nicht nur statisch die genannten Funktionen zu erfüllen, sondern muss auch eine bestimmte Flexibilität bieten, um einerseits Änderungen in der Umwelt überhaupt wahrzunehmen und andererseits auf diese Änderungen in den externen Faktoren angemessen reagieren und das Unternehmen auf diese anpassen zu können.177 Insofern muss eine gute 174 Nicolai (2009, 9) definiert anstatt der Steuerungsfunktion die „Verteilung, Legitimation und Sicherstellung von Macht“ als Grundaufgabe von Organisationen. Dies wird hier so nicht übernommen, da Macht für sich nicht als Ziel der Organisation gesehen wird, sondern nur als notwendiges Mittel, um die Aufgabengliederung, die Integration und vor allem die Steuerung zu gewährleisten. Auch Nicolai sieht jedoch an anderer Stelle diese Funktion von Organisationen „zu motivieren, zu steuern und zu disziplinieren“ (S. 10). An anderer Stelle definiert Nicolai (2009, S. 14) Führungsprozesseffizienz als wesentliche Anforderung an Organisationen. 175 Vgl. Nicolai (2009, S. 11), die die Anforderungen an eine Organisation vor allem anhand der beiden Anforderungen nach Stabilität und Flexibilität definiert sowie einem ausgewogenen Verhältnis zwischen beiden. 176 Vgl. Spath (2009), S. 7. 177 Vgl. Spath (2009), S. 7; Mangler (2006), S. 32. Kugeler, Vieting (2008) sprechen in diesem Zusammenhang von der Anpassungseffizienz von Organisationen (S. 231–233). Für Rummler, Brache

112


·

Organisationsstruktur nicht nur die aktuell statischen Herausforderungen der aktuellen Unternehmenssituation bestmöglich bedienen, sondern auch bereits den Kern für ihre Weiterentwicklung und Überwindung im Falle von Änderungen in diesen Herausforderungen in sich tragen. Sie trägt somit auch zur Sicherung der Entwicklungsfähigkeit des Unternehmens bei.178 Compliancefunktion (Normerfüllung) Neben den eigenen Anforderungen an eine Organisation gibt es auch extern verordnete Anforderungen, denen eine Organisation gerecht werden muss (gesetzliche Organisationspflichten)179. Hierunter fallen zum einen die generellen Organisationspflichten für Unternehmer und Führungskräfte, die sich aus der ordentlichen und gewissenhaften Geschäftsführung ergeben. Zweitens fallen hierunter organisatorische Vorgaben, die durch die jeweilige rechtliche Form bestimmt sind. Zum Dritten fallen hierunter spezielle externe Anforderungen an Unternehmen, die organisatorisch abgedeckt werden müssen, wie etwa im Hinblick auf Datenschutz, Arbeitssicherheit etc.

Neben diesen Grundfunktionen einer Organisation, die für alle Unternehmen und Institutionen gleichermaßen gelten, hat jedes Unternehmen aber auch spezielle Anforderungen an die Organisationsstruktur, die sich von Unternehmen zu Unternehmen unterscheiden. Diese speziellen Anforderungen an die Organisationsstruktur ergeben sich zum einen aus externen Faktoren.180 Hierzu zählen zum Beispiel die Anzahl, Art und geographischen Verteilung der Kunden. Ein Unternehmen, das nur für zwei Kunden im selben Land arbeitet, hat andere Anforderungen an die Organisationsstruktur als ein Unternehmen mit mehreren Hundert Kunden auf allen fünf Kontinenten. Ein weiterer externer Faktor ist die Art und Anzahl der Mitbewerber. Ein stark im internationalen Wettbewerb stehendes Unternehmen hat daher andere spezielle Anforderungen an die Organisationsstruktur als etwa ein Monopolbetrieb oder eine einzigartige Organisation, die in ihrem Themengebiet ganz alleine agiert. So sind etwa gut funktionierende Prozesse in einem Käufermarkt mit hohem Wettbewerbsdruck wichtiger als in einem Verkäufermarkt und bei geringem Wettbewerb.181 Ebenso spielt die Reife der

178 179 180

181

(1997) ist Anpassungsfähigkeit ein Musskriterium für Exzellenz in den Unternehmen (S. 12) und für Ihre Überlebensfähigkeit (S. 13). Vgl. auch Nicolai (2009, S. 11). Vgl. Nicolai (2009), S. 9. Siehe Klimmer (2007, S. 6): Er gibt einen guten Überblick über die allgemeinen gesetzlichen Organisationspflichten. Vgl. dazu auch Mangler (2006), der sehr ähnliche Einflussfaktoren auf die Organisationsstruktur von Unternehmen sieht (S. 11–13). Vgl. auch Bogaschewsky, Rollberg (1998), die allgemein festhalten, dass die Dynamik der Umweltbedingungen ein Faktor ist, der bei der Wahl der Organisationsform beachtet werden muss. Siehe dazu auch Rudolf Wilhelm (2007), S. 15–16, der im Wechsel vom Verkäufer- zum Käufermarkt den wesentlichen Grund für die heute größere Bedeutung des Prozessgedankens sieht.

113


jeweils bedienten Märkte eine Rolle für die Anforderungen an die Organisationsstruktur. Ein Unternehmen, das nur in einigen reifen und etwa gleich entwickelten Märkten Westeuropas aktiv ist, hat andere spezielle Anforderungen an die Organisationsstruktur als ein Unternehmen, das in verschiedenen Regionen Zentral- und Osteuropas aktiv ist und hier sowohl Aktivitäten in fast reifen Märkten wie etwa Slowenien oder der Tschechischen Republik, noch wachsenden Märkten wie etwa Kroatien und Rumänien und gerade erst geöffneten Pioniermärkten wie der Ukraine und Kirgistan hat. Weiters können auch technische Neuerungen die Organisationsstruktur maßgeblich beeinflussen – denken wir etwa nur an die modernen Kommunikationsmittel wie Mobiltelefone, E-Mail, Videokonferenzen oder Blackberrys, die es erst ermöglichen, zahlreiche Aufgaben ortsungebunden wahrzunehmen, gleichzeitig aber auch wieder die Notwendigkeit für neue Einheiten in der Organisation mit sich bringen, um diese neuen Mittel bereitzustellen und zu steuern (z. B. CIO-Funktion). Als letzten Punkt können auch noch gesellschaftliche Einflüsse wirken, die etwa über verschiedene spezielle gesetzliche Regelungen in einzelnen Ländern die Organisationsstruktur beeinflussen. Das bekannteste Beispiel hierfür war in den letzten Jahren die organisatorische Trennung von Vertrieb und Netz bei Energieversorgern zur Liberalisierung des Strommarktes. Zum anderen ergeben sich diese speziellen Organisationsanforderungen aus internen Faktoren des jeweiligen Unternehmens. Hierzu zählen etwa die Größe des Unternehmens, seine Strategie, die Struktur der Eigentümer, die Anzahl und Art der angebotenen Produkte oder Leistungen, sowie auch die Herkunft und Geschichte des Unternehmens oder der jeweiligen Teile. So hat eine Unternehmensgruppe, die eben aus dem Merger zweier eigenständiger Unternehmen entstanden ist, andere spezielle

Abb. 31: Anforderungen und Einflussfaktoren für eine Organisationsstruktur

114


Anforderungen an seine Organisation als eines, das vor keiner derartigen Herausforderung einer Zusammenführung steht. Ebenso benötigt ein börsennotiertes Unternehmen andere spezielle Organisationselemente als ein eigentümergeführter Betrieb oder eine Partnerorganisation. Auch die Art und Breite des Produktportfolios spielt hier eine Rolle: Ein Unternehmen, das nur ein spezielles Produkt anbietet, hat hier andere spezielle Organisationsanforderungen als ein Unternehmen, das eine Vielzahl von Produkten in verschiedenen Segmenten anbietet. Diese speziellen Anforderungen an die Organisation unterscheiden sich damit zwischen den Unternehmen und sind jeweils individuell ausgeprägt. 3.1.2 Grundlegende Elemente einer Organisationsstruktur

Um diese generellen und speziellen Anforderungen zu erfüllen, brauchen Unternehmen und Institutionen ab einer bestimmten Größe und Komplexität eine Organisationsstruktur. Zur Beschreibung dieser Organisationsstrukturen hat sich dabei die gedankliche Gliederung in Aufbau- und Ablauforganisation etabliert. Diese Gliederung ist prinzipiell positiv und hilfreich, eine Organisationsstruktur in einem Unternehmen oder einer Institution besteht jedoch aus mehreren und vielschichtigeren Elementen als nur aus einem Organigramm und Prozessen. Vielmehr besteht eine Organisationsstruktur zumindest aus folgenden Elementen: · · · · · ·

Aufbauorganisatorische Gliederung (Hierarchie, Leitungssystem) Ablauforganisatorische Gliederung (Prozesse) Vorgegebene Normen (Richtlinien) Informations-, Koordinations- und Entscheidungsstrukturen (Meetings und Boards) Einem etablierten Wertegerüst (Kultur) Eine Beförderungs- und Vergütungsstruktur (Karriere und Entlohnung)

Die aufbauorganisatorische Gliederung stellt die hierarchische Komponente der Organisationsstruktur dar. Mit ihr sind Entscheidungs-, Führungs- und Weisungsrechte verbunden. Das heißt, die Beziehungen in der Aufbauorganisation sind Beziehungen der Über- und Unterordnung im Sinne eines Vorgesetzten-Mitarbeiter-Verhältnisses. Darüber hinaus umfasst die Aufbauorganisation die grundsätzliche Gliederung und Bündelung der Aufgaben bzw. Teilaufgaben, die Stellenbildung, die Zuordnung von Aufgaben zu den Stellen sowie die Gestaltung der erforderlichen Informationen und Kommunikationsbeziehungen.182 Die Prozesse als ablauforganisatorische Gliederung stellen demgegenüber wie oben ausführlich beschrieben die kundenorientierte Sicht der Erstellung der Produkte und Leistungen in den Vordergrund. Ihre Beziehungen sind, wie im nächsten Ab182 Vgl. Mangler (2006), S. 7 f.; Schmidt (2006), S. 53 und S. 99.

115


schnitt ausgeführt wird, koordinativer und integrativer Natur, verbunden mit Strukturierungspflichten und Eskalationsrechten im Sinne einer Prozessverantwortung. Als drittes Element der Organisationsstruktur fungieren vorgegebene Normen, die meist in Form von Richtlinien vom Topmanagement verabschiedet und kommuniziert werden. Normen geben bestimmte Vorgaben bezüglich des Verhaltens in bestimmten Situationen, zum Beispiel Unterschriftenregelungen, Sicherheitsvorschriften, Einkaufsregelungen etc. Ihr Inhalt ist steuernder Natur und meist verbunden mit entsprechenden Überprüfungsroutinen und Eskalationsmöglichkeiten. Besprechungs- und Entscheidungsstrukturen (Meetings und Boards) stellen als viertes Element eine weitere wichtige koordinative Komponente der Organisationsstruktur dar. In Ihnen wird festgelegt, wer sich in welcher Frequenz mit wem zu welchen Themen trifft, um diese zu besprechen und anstehende Entscheidungen zu treffen. Die Beziehungen in solchen Meetings- und Entscheidungsstrukturen sind ebenfalls koordinativ, allerdings meist mit einer formalen und einer informellen hierarchischen Komponente: formell durch den Meetingsponsor, der in vielen Fällen als primus inter pares agiert oder aber zumindest ein Eskalationsrecht auf die nächsthöhere hierarchische Ebene hat; informell, da in Meetingstrukturen den Mitgliedern mit einer höheren hierarchischen Funktion meist faktisch ein höheres Gewicht zukommt. Insofern werden Besprechungsstrukturen von der Aufbauorganisation teilweise überlagert. Während die vier genannten Elemente explizit festgelegt und sichtbar sind (formale Organisation), gibt es auch Elemente der Organisationsstruktur, die unsichtbar sind, dennoch aber das Verhalten der Beteiligten maßgeblich beeinflussen (hidden structures): Es sind dies insbesondere die etablierte Unternehmenskultur sowie die Beförderungs- und Vergütungsstruktur.183 Die Unternehmenskultur umfasst das etablierte und gelebte Wertegerüst der Organisation. Also etwa, ob Transparenz ein generell gewünschter Aspekt ist; ob zwischen den Beteiligten eine starke Teamorientierung mit gegenseitiger Hilfe und Unterstützung oder eher ein gegenseitiger Wettbewerb besteht; ob man sich für interne Vereinbarungen auf die Gültigkeit von Gesagtem verlassen kann oder formelle Festlegungen notwendig sind. Ob eher über eine Basis des Vertrauens gesteuert wird mit nur stichprobenartigen Überprüfungen der korrekten Abwicklung bestimmter interner Abläufe oder ob eine transparente und feststehende Kontrolle gelebt wird, und so weiter.184 Die183 Siehe dazu Klimmer (2007, S. 7): Klimmer verwendet für die informelle Organisation das Bild des organisatorischen Eisbergs, bei dem nur wenig im Sinne der formalen Organisation sichtbar ist und vieles – die informale Organisation – unter der Oberfläche bleibt. Als Elemente der informalen Organisation nennt Klimmer explizit die tatsächliche Machtverteilung, das Ansehen von Personen und Stellen, ungeschriebene Gesetze, Werte und Einstellungen, Motivation, informelle Kommunikations- und Entscheidungsstrukturen und informelle Gruppen. Siehe ebenso Schreyögg (2006), S. 14 f., der in diesem Zusammenhang auch von emergenten Prozessen und Strukturen spricht (S. 417 ff.). 184 Zur Unternehmenskultur siehe Dierkes (2009); Schreyögg (2006), S. 448–484.

116


se gelebten Werte sind nicht mit der formalen Definition von Unternehmenswerten zu verwechseln, wie sie in vielen Unternehmen und Institutionen in den letzten Jahren formuliert wurden. Letztere stellen Versuche dar, die Werte über eine explizite Formulierung einerseits zu verstärken und andererseits auch in eine gewünschte Richtung zu entwickeln. Insofern stellen formulierte Werte meist ein Sollbild der Unternehmenskultur dar; sie sind somit ein Instrument der Werteentwicklung und nicht mit den Werten identisch. Entscheidend für die Organisationsstruktur ist vielmehr, welche Werte tatsächlich etabliert sind und gelebt werden. Als sechstes Element der Organisationsstruktur wirkt die Beförderungs- und Vergütungsstruktur auf das Verhalten und Zusammenspiel der Beteiligten ein. So ist etwa wesentlich, inwieweit die Vergütung leistungsorientiert erfolgt und ob diese Leistungen sehr individuell oder teamorientiert und auf die Zusammenarbeit gerichtet definiert werden. Ebenso wirkt die Frage, wer in der Organisation befördert wird und Karriere macht. Letzteres muss von den Kriterien her nicht deckungsgleich mit den formalen Vergütungsstrukturen sein. Vielmehr untermauert die faktische Beförderung von Personen das tatsächlich etablierte Wertegerüst im Unternehmen. Das Verhalten jener, die Karriere machen, wird als erfolgsversprechende Norm Teil der Kultur und von anderen übernommen. Zusammengenommen bilden diese Elemente die Organisationsstruktur von Unternehmen und Institutionen. Sie strukturiert und ordnet das Zusammenspiel der Beteiligten in der Organisation und wirkt auf das Verhalten. Dies jedoch nicht in einem deterministischen Sinn, sodass sich das Verhalten der Mitarbeiter direkt aus der Struktur ableiten ließe. Jeder Mitarbeiter ist vielmehr in seinem Verhalten in der Organisation frei. Durch die Struktur werden auf lange Sicht jedoch bestimmte Verhaltensweisen erfolgreich sein und sich somit durchsetzen und etablieren, während Verhalten, das nicht konform geht zu den genannten Elementen der Struktur auf lange Sicht nicht erfolgreich ist und teilweise sogar sanktioniert wird.185 3.1.3 Faktischer Primat der Aufbauorganisation

Traditionell kommt dabei der aufbauorganisatorischen Gliederung die höchste Bedeutung zu, sodass man durchaus von einem Primat der Aufbauorganisation sprechen kann.186 Auf Basis rein theoretischer Überlegungen ist dieser Primat falsch und zu kritisieren. Denn geht man von der zu erstellenden Leistung aus und gliedert diese auf Basis einer Prozesssicht in die notwendigen Teilprozesse und Prozessschritte, so würde man zuerst die ablauforganisatorische Gliederung, sprich die Prozesse, definieren, und erst auf Basis der Prozesse den einzelnen Prozessschritten Rollen zuteilen, 185 Vgl. dazu den strukturalistischen Ansatz von Kenneth N. Waltz (1979). 186 Dies konzedieren z. B. auch Osterloh, Frost (2000), S. 30: Sie sprechen auch davon, dass die Ablauforganisation faktisch von der Aufbauorganisation dominiert wird, fordern jedoch eine Umkehrung dieser Dominanz mit dem Slogan „structure follows process“ (S. 31).

117


die dann wieder zu Organisationseinheiten zusammengefasst werden. Die Aufbaustruktur sollte damit idealerweise aus der Ablaufstruktur folgen (structure follows process).187 So sehr dieser Ansatz zu befürworten und aus der theoretischen Perspektive überzeugend ist, muss doch festgestellt werden, dass in der Unternehmenspraxis der Aufbau und insbesondere die Zusammenlegung und Reorganisation von Unternehmen anders verlaufen und hierbei der Aufbauorganisation faktisch der klare Primat zukommt. Die Ursache dafür dürfte darin liegen, dass Unternehmen und Institutionen eben nicht nur technische Konstrukte sind, die am Reißbrett in idealer Weise entworfen werden, sondern soziale Konstrukte, die aus Menschen bestehen. Diese unterliegen neben anderen Trieben auch einem Machttrieb, der sich seit Jahrhunderten vor allem an der Größe des geführten Bereichs und der Anzahl der untergebenen Mitarbeiter misst.188 Insofern ist es trotz anderslautender theoretischer Schlussfolgerungen in der Unternehmensrealität fast die Regel, dass zuerst die aufbauorganisatorischen Strukturen definiert und erst dann die Prozesse im Detail ausgestaltet werden (process follows structure). Fälle, in denen nominierte Manager auf Basis einer Ablauflogik freiwillig Abteilungen und Mitarbeiter abgeben oder aber aus dieser Logik auf die Möglichkeit verzichten, weitere Abteilungen und Mitarbeiter unter ihre Führung zu bringen, sind Einzelfälle. Neben dem soziologischen Argument könnte ein weiterer Grund für diesen faktischen Primat der Aufbauorganisation die leichte Verständlichkeit aufbauorganisato187 Siehe dazu z. B. Hammer, Champy (1994), S. 118; ebenso Osterloh, Frost (2000), S. 31; Gaitanides (2000) vertritt die Meinung, dass Prozessmanagement „mittlerweise zum dominanten Paradigma der Reorganisation“ geworden ist (S. 1); ebenso Fischermanns (2006), S. 35–37: Er sieht aufgrund der größeren Bedeutung von Schnelligkeit, Reaktionsfähigkeit, Innovationsfähigkeit und Flexibilität heute einen Primat der Prozessorganisation über die Aufbauorganisation. Auch für Schmelzer, Sesselmann (2010) sollte in der Organisationsgestaltung die Struktur den Prozessen folgen (S. 176). Detto Jochem, Landgraf (2010), S. 63. Ebenso Becker, Kugeler, Rosemann (2008), die die Ableitung der Aufbauorganisation aus den erarbeiteten Sollprozessen als wichtigen Schritt sehen (S. 21). Ebenso Kugeler, Vieting (2008), S. 222. 188 Siehe dazu Wilhelm (2007), S. 11, der auch eine höhere Gewichtung der Aufbauorganisation konstatiert und den wesentlichen Grund hierfür darin sieht, dass diese die Interessen der Führungskräfte unmittelbarer betrifft und darüber entscheidet, wer im Betrieb etwas zu sagen hat. Ebenso Schmidt (2006), der konstatiert, dass es bei der Behandlung von grundlegenden Fragen der Struktur von Unternehmen oder Verwaltungen immer auch um Fragen des Einflusses und der Macht geht und ging – Schmidt sieht jedoch auch ein zunehmendes Bewusstsein für die Nachteile dieses Vorgehens in den letzten Jahren. Schmidt (2006), S. 83 f. Detto Fischermanns (2006), S. 37: Er spricht zwar von einem Primat der Prozessorganisation, anerkennt jedoch, dass Macht- und Statusfragen nach wie vor vor allem über die Aufbaustruktur beantwortet werden: „In Einstellungen, Werten und Normen vieler Führungskräfte ist es wohl nach wie vor wichtig, ‚wie viele Köpfe man unter sich hat‘ . . .“. Auch Kugeler, Vieting (2008) konzedieren, dass die Aufbauorganisation in der Praxis aus Gründen der Macht, der Position und des Ansehens oft einen besonderen Stellenwert einnimmt, bleiben aber dennoch bei ihrem Postulat, dass diese den Prozessen folgen soll (S. 224). Anders Hammer (1997): Er sieht hier sehr idealistisch mit dem prozessorientierten Unternehmen auch ein Ende der Machtposition und des Statusmonopols der Manager kommen (S. 120).

118


rischer Strukturen sein. Direkte Anweisungen auf Basis von Hierarchien entsprechen einer archaischen Urorganisation, die ohne große Einschulung und ohne einen hohen Ausbildungsstand oder Reifegrad verständlich ist. Stellt man dem gegenüber, dass Prozesse eine relativ neue Sichtweise auf Unternehmen sind, die es in expliziter Form erst seit weniger als einhundert Jahren gibt, die erst seit weniger als 20 Jahren einigermaßen etabliert ist und erst seit wenigen Jahren in den Schulen und Universitäten langsam Eingang in die Curricula findet, so darf es nicht verwundern, dass die Ablaufsicht weniger etabliert und verankert ist als die hierarchische Aufbausicht. Aus Sicht des Prozessmanagements bestehen daher aktuell zwei parallele Handlungsstränge: zum einen muss der aus der Theorie abgeleitete Primat der Ablauforganisation im Sinne des Postulats structure follows process weiter entwickelt werden. Zum anderen ist eine detailliertere Analyse der Gründe für den aktuellen faktischen Primat der Aufbauorganisation in der Unternehmenspraxis notwendig, da dieser sicher nicht nur an der wissenschaftlichen Unwissenheit der Manager liegt, sondern vermutlich in bestimmten Umständen und Ursachen begründet ist. Ergebnis dieser Analysen müssten entweder konkrete Vorschläge sein, wie man dem theoretischen Postulat zum Durchbruch zu verhelfen kann, oder aber ein Verwerfen dieses Postulats durch das Aufstellen eines neuen, besseren. Die dafür notwendigen Analysen müssten vermutlich neben Überlegungen der Organisationslehre und des Prozessmanagements auch soziologische und anthropologische Ansätze einbeziehen. In der Zwischenzeit empfiehlt es sich, auf Basis der Erfahrungen in der Unternehmenspraxis den faktischen Primat der Aufbauorganisation – zumindest für die Zeit bis zu einer Klärung des ersten Handlungsstranges – als Annahme zugrunde zu legen und auf dieser Basis Ansätze zu entwickeln, die den Unternehmen und Institutionen auf Basis dieser Annahme bei der Suche nach einer möglichst guten Organisationsstruktur helfen. Da die vorliegende Arbeit stärker praxisorientiert ist, verfolgt sie den zweiten Handlungsstrang. Es wird daher angenommen, dass es ausgenommen von wenigen Einzelfällen in der Praxis nicht möglich ist, die aufbauorganisatorische Gliederung komplett aus der ablauforganisatorischen Gliederung abzuleiten, wie dies theoretisch wünschenswert wäre, sondern, dass die aufbauorganisatorische Gliederung entweder schon vorgegeben oder aber im Design, der Weiterentwicklung und Änderung von Organisationsstrukturen der erste Schritt ist, der wesentliche Eckpfeiler vorgibt und demgegenüber andere Elemente wie auch die ablauforganisatorische Gliederung erst nachrangig gestaltet werden. Für Anhänger der Prozesssicht mag dies auf den ersten Blick eine zu pessimistische und wenig befriedigende Arbeitshypothese sein. Wie im Folgenden gezeigt wird, ermöglicht sie jedoch, den möglichen Nutzen und den Platz des Prozessmanagements in bereits bestehenden aufbauorganisatorischen Organisationsstrukturen in der Realität mindestens genauso deutlich zu erarbeiten, als dies der Fall wäre, wenn die Unternehmen bereits nach dem Postulat structure follows process agieren würden. Denn in al119


len Unternehmen gibt es bereits Organisationsstrukturen; nur in ganz wenigen Ausnahmefällen ist das Management von Unternehmen bereit, diese etablierten Aufbaustrukturen komplett über Board zu werfen und der Theorie folgend eine neue Aufbaustruktur auf Basis eines sauberen Prozessdesigns zu entwerfen. Das organisatorische Risiko eines solchen Unterfangens wäre vermutlich viel zu hoch verglichen mit den Nachteilen und Ineffizienzen bereits etablierter Aufbaustrukturen, die zudem auch über die rein aufbauorganisatorische Perspektive da und dort nachjustiert oder geändert werden können. In diesem Sinn soll der hier angenommene Primat der Aufbauorganisation als Hilfsmittel für die Einordnung des Prozessmanagements in den Gesamtrahmen der Organisationslehre dienen. Dies heißt keineswegs, dass damit der aus der Theorie begründete Primat der Ablauforganisation widerlegt, abgelehnt oder ignoriert wird. Er ist nur in einer Welt, die in der Realität sichtlich anders funktioniert, eine Annahme, die erst genauer ausgearbeitet und entwickelt werden muss, ehe sie als Basis für praktische Überlegungen zugrunde gelegt werden kann. Im jetzigen Stand der Ausarbeitung und mangelnder Validierung in der Unternehmensrealität wäre sie für den Zweck der vorliegenden Arbeit, nämlich die Einordnung des Prozessmanagements in den Rahmen real existierender Organisationsstrukturen, nicht hilfreich. 3.1.4 Möglichkeiten zur Gestaltung der Aufbauorganisation

Basierend auf der Arbeitshypothese des realen Primats der Aufbauorganisation versuchen wir in diesem Abschnitt herauszuarbeiten, wie die aufbauorganisatorische Gliederung von Unternehmen und Institutionen erfolgen kann. Im Wesentlichen stehen dafür folgende verschiedene Gesichtspunkte zur Strukturierung zur Verfügung:189 · · · ·

Nach den Tätigkeiten (Verrichtungen) Nach den Leistungen/Produkten Nach den Kunden Nach den Bezugsquellen

Eine Organisation nach Tätigkeiten (Verrichtungen)190 folgt der Zusammenfassung von Teilaufgaben nach ihrer Ähnlichkeit in der Verrichtung in bestimmten Funktionen. Seit dem berühmten Beispiel von Adam Smith mit der Nadelproduktion haben Heerscharen von Unternehmern und Planern versucht, Aufgaben so zu untergliedern, 189 Vgl. dazu auch Fischermanns (2006), der wie in der Organisationslehre üblich zwischen verrichtungsorientierter (funktionaler) und objektorientierter (divisionaler) Organisation unterscheidet. Als Objekte kommen für ihn dabei Produkte, Kunden und Regionen infrage. Vgl. ebenso Schmidt (2006), S. 71 ff. 190 Vgl. Frese (1995), S. 195 f.

120


dass leicht erlernbare Teilaufgaben entstehen, die größtmögliche Effizienz in der Verrichtung gewährleisten, oder aber dass Teilaufgaben, die sehr spezielle Fähigkeiten erfordern, bei entsprechend ausgebildeten Spezialisten gebündelt werden. Klassische Beispiele hierfür sind etwa Buchhaltung, Einkauf und Engineering. Ziel ist es dabei, nicht nur die Komplexität der Aufgabenerfüllung zu reduzieren, sondern auch, leichter Arbeiter zu finden, welche die einzelnen Aufgaben erledigen können, und ebenso, die jeweils günstigsten möglichen Ressourcen für die Durchführung einzusetzen, damit nicht teure Experten einfache Arbeits- oder Administrationsschritte durchführen. Eine Organisation nach den Produkten191 gliedert die Aufbaustruktur nach den Objekten der Leistungserstellung. Bei einer Bootswerft würde man demzufolge zum Beispiel eigene Geschäftseinheiten für Segelschiffe, für Sportboote und für Fischereiboote unterscheiden. Innerhalb jeder dieser Produktsparten würden alle notwendigen Teilaufgaben für die Erstellung dieser Produkte erbracht und erfüllt. So hätte hier idealtypischerweise jeder der drei Produktbereiche eine eigene Beschaffung, eine eigene Produktion, einen eigenen Vertrieb und auch eine eigene Buchhaltung und ein eigenes Controlling. In der Praxis wird dies auch als divisionale Organisation bezeichnet. Eine Organisation, die sich an den Kunden ausrichtet, ist in mehreren Ausprägungen denkbar. Einmal im Hinblick auf eine Untergliederung in verschiedene Kundengruppen, zum Beispiel Großkunden und Privatkunden, wie dies z. B. bei Banken häufig anzutreffen ist. Oder aber direkte und indirekte Kunden, wie wir es beispielsweise in der Mineralölbranche häufig vorfinden, wo ein Teil des Geschäfts mit bekannten großen Unternehmen abgewickelt wird, die das Unternehmen kennt, und der andere Teil mit einer Vielzahl an unbekannten Einzelkunden über das Tankstellennetz erfolgt. Eine spezielle Form der Kundengruppengliederung ist dabei jene, die sich an der Branche der Kunden ausrichtet und darauf die Struktur aufbaut. Ein Beispiel wäre hier etwa eine Untergliederung in Einheiten für die Bauindustrie, für die verarbeitende Industrie und für die chemische Industrie. Auch in diesen Fällen würde man von einer divisionalen Struktur sprechen, nicht zuletzt deshalb, weil sich die erbrachten Leistungen meist je nach Kundensegment etwas unterscheiden und damit auch hier im Prinzip eine Gliederung nach Produkten und Leistungen vorliegt. Eine andere spezielle und sehr häufige Form der Kundengruppengliederung ist jene nach der Herkunft der Kunden. In diesem Fall richtet sich die Struktur in einer regionalen Untergliederung an Regionen, Ländern, Ländergruppen oder Kontinenten aus (Regionalorganisation).192 Ein Beispiel wären hier etwa Geschäftseinheiten für die Region Westeuropa, Südeuropa, Osteuropa und Mittlerer Osten. Auch hier würden idealtypisch innerhalb der gebildeten Segmente alle Schritte für die jeweilige Leistungserbringung erfüllt. Die erbrachten Produkte und Leistungen wären in der idea191 Vgl. Frese (1995), S. 197 f. 192 Vgl. Frese (1995), S. 193 f.

121


len Ausprägung jedoch genau dieselben. Aus diesem Grund wird in diesem Fall von einer regionalen Struktur gesprochen. Auch hier gilt im Idealbild wieder, dass die regionalen Einheiten alle notwendigen Schritte zur Leistungserbringung umfassen und selbst erfüllen. Als Letztes wäre auch eine Strukturierung nach verschiedenen Bezugsquellen denkbar, also zum Beispiel in eine Geschäftseinheit, die ihre Rohstoffe aus Russland zukauft und eine andere, die dieselben Rohstoffe aus dem Mittleren Osten bezieht. Eine solche Strukturierung könnte vor allem in Geschäftsfeldern sinnvoll sein, bei denen dem Sourcing bestimmter Rohstoffe eine essenzielle Bedeutung zukommt und die Produkte nur innerhalb bestimmter Distanzen wirtschaftlich transportierbar sind. Aufgrund der regionalen Bündelung wird diese Form häufig als Huborganisation bezeichnet. Die Wahl des primären Organisationsprinzips für die Strukturierung – also ob im ersten Schritt nach Verrichtungen, Produkten, Kunden oder Bezugsquellen strukturiert wird – legt die Basis für das Design der jeweiligen Organisation. Innerhalb dieser Grundstruktur ist in weiterer Folge eine Ausprägung entlang der Dimension zentral-dezentral möglich. So kann etwa eine Organisationsstruktur, die sich an der geographischen Herkunft der Kunden ausrichtet zentral organisiert sein, in dem in der Zentrale unterschiedliche Gruppen für verschiedene Kundenregionen zuständig sind; alternativ kann sie auch rein dezentral organisiert sein, in dem diese Gruppen nicht zentral angesiedelt sind, sondern in den jeweiligen Kundenregionen in eigenen vollausgeprägten Niederlassungen sitzen. Und es sind auch unterschiedliche Zwischenformen mit einem unterschiedlichen Grad an Zentralisierung oder Dezentralisierung denkbar: etwa die Zusammenfassung von mehreren Ländern, die Bildung von länderübergreifenden Hubs oder Clustern etc. Egal für welches Organisationsprinzip man sich jedoch entscheidet und egal in welcher zentralen oder dezentralen Variante man es ausgestaltet: Keine dieser Organisationsformen ist perfekt. Jede hat ihre Vor- und ihre Nachteile. Vorteile im Sinne der mehr oder weniger guten Erfüllung der oben beschriebenen Grundfunktionen einer Organisation sowie der spezifischen organisatorischen Anforderungen des individuellen Unternehmens; Nachteile im Sinne von Nebeneffekten bei anderen dieser Grundfunktionen und speziellen Anforderungen. Es gibt damit keine ideale Organisationsstruktur für Unternehmen generell. Und es gibt auch keine ideale Organisationsstruktur für ein bestimmtes Unternehmen.193 Es gibt nur Organisations193 Vgl. dazu Spath (2009), S. 9: Auch er sieht abhängig von der jeweiligen Konstellation für Unternehmen spezifisch passende Organisationen: „Es gibt nicht die eine passend, immer gültige Organisation für alle Unternehmen“ (Ebenda). Anders als in den kontingenztheoretischen Ansätzen wird hier jedoch nicht davon ausgegangen, dass externe, situative Bedingungen die jeweilige Organisationsstruktur determinieren, sondern nur, dass sie als Einflussfaktoren in der Auswahl und im Design der Organisationsstruktur berücksichtigt werden und eine Rolle spielen. Vgl. Schreyögg (2006), S. 60–61.

122


strukturen, die für ein bestimmtes Unternehmen oder eine bestimmte Institution die jeweiligen generellen und spezifischen Anforderungen in einer spezifischen Situation bestmöglich unterstützen, d. h. die bestmögliche Balance zwischen Vor- und Nachteilen bieten. Da sich die Rahmenbedingungen von Unternehmen stetig ändern und sich Unternehmen auch kontinuierlich weiter entwickeln, ist eine Organisationsstruktur daher auch nichts Endgültiges. Vielmehr ist das regelmäßige Hinterfragen der bestehenden Organisation und deren Veränderung im Lichte neuer Rahmenbedingungen eine notwendige Managementaufgabe. Reorganisationen sind daher nicht deswegen notwendig, weil die jeweils „alte Organisation“ schlecht gewesen wäre, sondern weil sie für die neuen Rahmenbedingungen nicht mehr optimal ist in dem Sinne, dass sie im Vergleich mit anderen Organisationsmodellen nicht mehr das Optimum an möglichst großen Vorteilen und möglichst geringen Nachteilen bietet. Um diese bestmögliche Unterstützung zu erreichen, werden die oben dargestellten Grundformen in der Praxis auf vielfältige Weise kombiniert. Dies kann auf mehrere Arten erfolgen: · · ·

Durch Vermischung von mehreren Organisationsprinzipien auf derselben Ebene Durch Anwendung von mehreren Organisationsprinzipien auf unterschiedlichen Ebenen Durch die Kombination von mehreren Organisationsprinzipien in Form einer Matrix

Eine Möglichkeit der Kombination besteht darin, dass nicht alles entlang eines einzigen Organisationsprinzips strukturiert wird, sondern eine Vermischung von zwei oder mehreren Organisationsprinzipien vorgenommen wird. Etwa bei einem Unternehmen mit Geschäftsbereichen für Segelboote, für Yachten und für Sportboote, einer speziellen Geschäftseinheit für den aufstrebenden Markt in Asien sowie einer Einheit für die gemeinsame Abwicklung von Buchhaltung, Informationstechnologie und Personal. Eine andere Möglichkeit besteht in der Anwendung von mehreren Organisationsprinzipien auf unterschiedlichen Strukturebenen. Als Beispiel werden etwa die Geschäftsbereiche für Segelboote, für Yachten und für Sportboote auf der nächsten Ebene nach Funktionen strukturiert, sodass es in jeder Sparte jeweils eigene Einheiten für Vertrieb, Produktion, Service und Buchhaltung gibt. Die dritte, ebenfalls weitverbreitete Möglichkeit der Kombination besteht in der Anwendung einer Matrixorganisation im Sinne eines Mehrliniensystems, bei der zum Beispiel in einer Dimension nach den Produkten und in der anderen nach den jeweiligen Kundenregionen strukturiert wird.194 In der Praxis kristallisiert sich jedoch 194 Hierfür wird teilweise auch der Begriff der Dualstruktur verwendet. Vgl. z. B. Mangler (2006), S. 41 f.

123


meist eine der Dimensionen der Matrix als die de facto führende heraus, während die andere Dimension auf einige wenige, klar bestimmte Aspekte im Sinne einer fachlichen Richtlinienkompetenz beschränkt wird. Echte Doppel- und Mehrfachunterstellungen mit gleichberechtigten Dimensionen sind in der Praxis eher selten.195 Sie können nur in sehr reifen Organisationen dauerhaft funktionieren und benötigen insbesondere hochqualifizierte Mitarbeiter, eine hohe Sozialkompetenz aller Beteiligten, eine etablierte Konfliktkultur der Führungskräfte sowie funktionierende Eskalationsmechanismen.196 Auch unter Nutzung all dieser Kombinationsmöglichkeiten kann jedoch keine ideale Organisationsstruktur geschaffen werden. Der Grund hierfür liegt schlichtweg in der Untergliederung per se. Jede Untergliederung – wie auch immer gewählt – schafft kleinere Einheiten, die das Arbeiten und Steuern innerhalb dieser erleichtern, in dem sie sich gegenüber den anderen abgrenzen. Während die Untergliederung in Einheiten somit hilft, die Grundfunktionen der Gliederung, der Produktivität, der Steuerung und der Identifikation zu erfüllen, bringt sie notgedrungen auch Dysfunktionalitäten, allem voran in der Integrationsfunktion mit sich. Diese Dysfunktionalitäten können durch ergänzende Organisationselemente jedoch abgemildert werden. Beispiele für solche ergänzenden Organisationselemente sind zum Beispiel:197 · · · · · · · ·

Key Account Management Produkt Management Supply Chain Management Customer Relationship Management Lead-Buyer-Konzepte Projektorganisationen Länder Peer-Groups Spezielle Abstimmungs- und Koordinationsgremien

Ergänzend zur Primärorganisation, welche die grundsätzliche Aufbaustruktur festlegt, leisten diese ergänzenden Organisationselemente als Elemente der Sekundärorganisation einen wertvollen Beitrag. Diese Sekundärorganisation ist dabei eine Ergänzung und Überlagerung der Primärorganisation, die wie ein Netzwerk über die Grundstruktur ge195 Vgl. dazu Schmidt (2006) S. 70: Auch er hält fest, dass echte Doppel- oder Mehrfachunterstellungen sehr selten praktiziert werden. 196 Vgl. dazu Nicolai (2009), S. 122 f.; Schreyögg (2006), S. 178–192. Eine interessante Spielvariante einer Matrixorganisation erwähnt Klimmer (2007, S. 55): Für ihn müssen Matrixschnittstellen nicht zwingend als eigene organisatorische Einheiten existieren, sondern können auch aus „gemeinsam zu bewältigenden Abstimmungs- und Problembereichen“ bestehen. Die Organisationseinheiten arbeiten somit völlig getrennt voneinander, haben jedoch beim Auftreten bestimmter Probleme eine Verpflichtung zur gemeinsamen Lösungsfindung. Klimmer bezeichnet diese Spielvariante daher auch als „unvollständige Matrix“. 197 Vgl. auch Nicolai (2009), S. 131.

124


legt wird. Rollen in der Sekundärorganisation werden dabei häufig durch eigene Stäbe oder aber vielfach auch nur durch Linienverantwortliche als Zusatzaufgabe neben den anderen Aufgaben aus der Aufgabenhierarchie wahrgenommen.198 So können die Vorteile einer gewählten Primärstruktur erhalten bleiben, gleichzeitig aber die Nachteile dieser Strukturwahl abgefedert und gemildert werden.199 Der Vorteil solcher Elemente der Sekundärorganisation liegt vor allem in der Erfüllung der Integrations- und Koordinationsfunktion, die von der Primärorganisation aus den geschilderten Gründen nicht oder nur unzureichend erfüllt werden kann.200 3.1.5 Prozessorganisation – Ideal oder Mythos

Wie passen nun das Prozessmanagement und die viel zitierte Prozessorganisation in dieses Bild? – in zweierlei Hinsicht: Die klassische Prozessorganisation201, die oft als um 90 Grad gedrehte Organisationsstruktur der klassischen (d. h. funktional verstandenen) Organisation gesehen wird, entspricht bei Zugrundelegen eines End-to-End-Prozessverständnisses der Organisation nach Produkten, sprich einer Spartenorganisation. Denn wenn wir einen End-to-End-Prozess als Abfolge von Tätigkeiten zur Erbringung einer Leistung oder zur Erstellung eines Produkts definieren, so entspricht die Organisation nach Prozessen der Organisation nach den mit diesen Prozessen erbrachten Leistungen. Eine reine Prozessorganisation wäre somit eine Organisation, die sich auf der obersten Ebene 198 Zum Begriff der Primärorganisation siehe z. B. Nicolai (2009, S. 18 u. S. 111): Sie versteht unter der Primärorganisation die Grundstruktur des Unternehmens, die der Bearbeitung der üblichen, regelmäßigen Daueraufgaben und der Erreichung der kurzfristigen Unternehmensziele dient. Wesentliches Kernelement der Primärorganisation ist dabei die Aufbauorganisation. Neben der Primär- gibt es auch eine Sekundärorganisation, die der Erfüllung besonderer, bedeutsamer Aufgaben dient, die nicht unter die üblichen Routineaufgaben fallen. Sie besteht damit neben der und gleichzeitig zur Primärorganisation und unterstützt, überlagert und ergänzt diese. Als Beispiel nennt sie die Projektorganisation (Nicolai 2009, S. 18–19), vgl. auch Bogaschewsky, Rollberg 1998, S. 198). Zur Definition des Begriffs der Sekundärorganisation siehe auch Schmidt (2006), S. 79–81: Er sieht als Elemente der Sekundärorganisation vor allem Kollegien, Ausschüsse, Workshops und Projektgruppen. 199 Vgl. Nicolai (2009), S. 132, die das am Beispiel des Produktmanagements illustriert. Ebenso Klimmer (2007, S. 48, ebenso S. 64): Er versteht unter Sekundärorganisation die Ergänzung weiterer Strukturelemente, um Nachteile der Grundformen der Aufbauorganisation zu vermeiden. Auch Klimmer illustriert das Funktionieren der Sekundärorganisation anhand des Produktmanagements. 200 Vgl. auch Fischermanns (2006), S. 35. Er definiert die Sekundärorganisation als Einrichtungen, die die Hierarchie überlagern, zur Koordination von Aufgaben. 201 Prozessorganisation wird hier anknüpfend an die diesbezüglichen Vorschläge von Michael Hammer und James Champy im Sinne einer vollkommen an den Prozessen ausgerichteten Aufbauorganisation verstanden. Ähnlich dazu z. B. auch die Sichtweise von Lohoff und Lohoff 1994 (zit. nach Staud 2001, S. 20). Manche Autoren verwenden den Begriff auch anders, zum Beispiel synonym mit Prozessmanagement (vgl. etwa Rudolf Wilhelm 2007, Mangler 2006, S. 8, Schmidt 2006, S. 54, Nicolai 2009, S. 18).

125


Abb. 32: Prozessorganisation

nach Produkten oder Leistungen gliedert. Sie würde somit auf dieser Ebene mit einer divisionalen Struktur identisch sein.202 Der Unterschied erfolgt jedoch in der zweiten Strukturebene. Während eine typische divisionale Organisation sich auf der zweiten Ebene in Funktionen oder Teilprozesse entlang der Wertschöpfungskette strukturiert, erfolgt die Gliederung in einer Prozessorganisation durch die Bündelung von kompletten Prozessen in parallel arbeitenden Stellen oder Teams. Diese Stellen oder Teams übernehmen innerhalb der nach Produkten und Leistungen geschnittenen Bereiche die komplette Abarbeitung von bestimmten, ihnen zugeteilten Geschäftsfällen für die Kunden von Beginn bis Ende. Michael Gaitanides spricht in diesem Zusammenhang von einer „Rundumbearbeitung“ der Geschäftsfälle, ebenso Margit Osterloh und Jetta Frost.203 Diese Stellen oder Teams – vielfach „Prozess-„ oder „Case Teams“ bzw. „Case Worker“ genannt, bearbeiten die ihnen zugeteilten Vorgänge ganzheitlich von Anfang bis Ende.204 Dafür ist es natürlich erforderlich, dass sie über alle Fähigkeiten und alles notwendige Wissen zur 202 Vgl. auch Mayer, Fischer in Horváth & Partners (2005), S. 209. Vgl. ebenso Schmidt (2006), S. 74. Auch Schober (2002, S. 8) macht klar, dass bei der Prozessorganisation die funktionale Perspektive gegenüber der objektorientierten in den Hintergrund trete und sich dies aufbauorganisatorisch in einer divisionalen Struktur niederschlage. Zur divisionalen Struktur siehe z. B. Schreyögg (2006), S. 132 u. S. 145. 203 Siehe Gaitanides (2007), S. 52. Ebenso Osterloh, Frost (2000) S. 27, die dazu auf Frese, von Werder 1992 verweisen. 204 Zum Begriff des Case Workers und der Case Teams siehe Hammer, Champy (1994), S. 78–80 und S. 92–93; vgl. auch Osterloh, Frost (2000), S. 20–21; vgl. auch Fischermanns (2006), S. 32, der in diesem Zusammenhang von Objektzentralisation und einer ganzheitlichen Vorgangsbearbeitung spricht. Küting (1996) übersetzt den Begriff des Case Workers mit „Fallbearbeiter“ (S. 125).

126


kompletten Bearbeitung der Geschäftsfälle verfügen. Case Worker oder Case Teams müssten somit alle notwendigen Qualifikationen bündeln und in einer Person oder eben im betreffenden Team entsprechend vorhalten. Zur weiteren Untergliederung werden die Geschäftsfälle gegebenenfalls nach verschiedenen Typen oder Varianten unterschieden (Triage-Idee), also etwa nach der Komplexität der Fälle in schwierige, mittlere und Routineaufträge.205 Analysieren wir eine solche Organisationsstruktur anhand der definierten Grundfunktionen von Organisationsformen. Weiter oben wurde definiert, dass eine Organisationsstruktur die Komplexität für die Beteiligten reduzieren muss, sodass die Zielsetzung des Unternehmens oder der Institution möglichst effektiv und effizient erreicht wird. Hierfür wurden acht Grundfunktionen definiert, die erfüllt werden müssen: ·

·

die Gliederungsfunktion, mit der die komplexe Gesamtaufgabe in überschaubare und handhabbare Teile herunter gebrochen wird, würde durch eine Prozessorganisation nicht erfüllt. Denn jeder Case Worker bzw. jedes Case Team bearbeitet seine Geschäftsfälle komplett von Anfang bis Ende. Damit bleibt die gesamte Komplexität erhalten; das Case Team muss sie im Gesamten bewältigen ohne eine Untergliederung in Teilaufgaben. Durch die weitere Untergliederung der Geschäftsfälle nach Typen oder Varianten (Triage-Idee) kann dies etwas gemildert werden, dennoch bleibt auch damit die Komplexität der Rundumbearbeitung von Anfang bis Ende erhalten.206 Die Integrationsfunktion, mit der sichergestellt wird, dass Teilaufgaben nicht isoliert voneinander oder gar mit gegenseitig negativer Beeinflussung ausgeführt werden, sondern so zusammenspielen, dass am Ende die Gesamtaufgabe erfüllt wird, würde durch eine Prozessorganisation auf Basis einer End-to-End-Sicht der Geschäftsprozesse perfekt erfüllt. Denn im Case Team liegt die Verantwortung für die komplette Abarbeitung des Geschäftsfalles. Organisationsbrüche, Informationsverluste im Zuge der Bearbeitung oder Wartezeiten an den Übergabepunkten entfallen hier somit.207 205 Siehe Osterloh, Frost (2000), S. 50 ff. 206 Zur Triage-Idee siehe Hammer, Champy (1994), S. 83–84; Gaitanides (2007), S. 56–57; vgl. auch Osterloh, Frost (2000), die ebenfalls die Notwendigkeit einer weiteren Untergliederung der Prozesse sehen und dafür die Triage-Idee konzipieren. Darunter wird eine Untergliederung des Prozesses entweder nach funktionalen Teilprozessen (funktionale Segmentierung), nach Komplexität in komplexe, mittlere und Routinefälle (Segmentierung nach Problemhaftigkeit) oder nach Kundengruppen verstanden. 207 Dies ist jedoch nicht oder nur eingeschränkt der Fall, wenn keine End-to-End-Sicht der Geschäftsprozesse unterlegt wird. Vgl. dazu etwa Osterloh, Frost (2000), die in ihrer Prozesskonzeption nur die strategisch relevanten Kernprozesse auf Teilprozessebene zugrunde legen und alle Supportprozesse als eigene Module separieren. In diesem Fall kann die Koordinations- und Integrationsfunktion nur zum Teil erfüllt werden, Gräben und Brüche zwischen den Teilprozessen bleiben bestehen.

127


·

·

Die Erfüllung der Produktivitätsfunktion hängt von der Art des jeweiligen Geschäfts ab. Bei Geschäften, die eine Vielzahl von unterschiedlichen Fähigkeiten und verschiedenes Wissen erfordern, ist es kaum denkbar, dass eine hohe Effizienz erzielt wird, da Spezialisierungs- und Größendegressionsvorteile (economies of scale), die bei der häufigen Ausführung ein und desselben Prozessschrittes entstehen, nicht genutzt werden können.208 Insofern ist diese Grundfunktion bei vielen komplexen Produkten und Leistungen wohl mit einer Prozessorganisation nicht erfüllbar.209 Bei bestimmten Geschäftsarten, die nicht sehr viele verschiedene Fähigkeiten erfordern, eine hohe Variabilität in den Prozessen aufweisen und eine Fülle an verschiedenen, schwer strukturierbaren Informationen benötigen, die von einem Teilprozess an den anderen übergeben werden müssten, ist dies jedoch denkbar. Als Beispiel wäre hier etwa das Projektgeschäft in der Bauindustrie oder im Anlagenbau zu nennen, in der Projektteams einen Geschäftsfall von Anfang bis Ende im Rahmen von Projekten komplett abwickeln. Die Steuerungsfunktion, mit der ein Rahmen für die Planung, Überprüfung und Steuerung der eingesetzten Ressourcen, Materialen und Aufwände geboten wird, wäre durch eine Prozessorganisation nur bedingt erfüllt, und zwar abhängig von der Größe der Teams. Ist die zu erbringende Leistung wenig komplex, sodass die Teams aus einer Handvoll verschiedener Experten bestehen, so wäre die Steuerungsfunktion gut erfüllt. Derartige Teams können über einfache Kennzahlen, wie etwa die Anzahl der bearbeiteten Fälle sowie deren Durchlaufzeit relativ einfach gesteuert werden. Ist die zu erbringende Leistung jedoch komplex, so müssten die Teams aus einer Vielzahl von verschiedenen Experten bestehen. Erfolg oder Misserfolg wären damit durch einfache Kennzahlen zwar immer noch mess208 Vgl. dazu auch Osterloh, Frost (2000), die als Nachteil einer Prozessorganisation mit Segmentierung nach Kundengruppen festhalten, dass Spezialisierungsvorteile entfallen und es auch zu Doppelspurigkeiten kommen kann (S. 63). Ebenso Staud (2001, S. 20–21), der festhält, dass eine ideale Prozessorganisation in vollem Umfang in kaum einem Unternehmen umgesetzt wurde, und auch meint, dass eine derartige Umsetzung auch fraglich wäre, weil manche Ressourcen damit nicht effizient ausgelastet werden können. In der Praxis sei daher ein Kompromiss aus Prozess- und Funktionsorientierung die optimale Lösung. Auch Bogaschewsky, Rollberg (1998, S. 229–230) sehen diesen Trade-off, dass mit einer stärkeren organisatorischen Integration Spezialisierungsvorteile verloren gehen können, gehen jedoch ohne weitere Argumentation davon aus, dass „grundsätzlich“ davon auszugehen ist, dass dieser Verlust geringer wäre als die überproportional sinkenden Übergangszeiten. 209 Siehe dazu auch Mayer, Fischer in Horváth & Partners (2005), S. 214–217: Auch sie betonen klar, dass eine komplett prozessorientierte Aufbauorganisation in vielen Fällen wirtschaftlich nicht vorteilhaft wäre, dies v. a. aus Gründen der Spezialisierung, der Effizienz, der Auslastung und des Risikomanagements. Auch Osterloh, Frost (2000) anerkennen dies zumindest teilweise, in dem sie in ihren Beispielen für Prozessorganisationen diese nicht in Reinform implementiert haben, sondern auch hier Teilprozesse aus mehreren Geschäftsprozessen prozessübergreifend zusammenziehen und bündeln, so etwa den Prozess der Datenakquisition und des Datenmanagements im Beispiel des Statistischen Amtes des Kantons Zürich (S. 59 f.).

128


·

·

·

·

bar, die Gründe für Erfolg oder Misserfolg könnten jedoch nicht mehr dem ganzen Team zugeschrieben werden. Und eine Rückverfolgung auf einzelne Teammitglieder wäre nur sehr schwer denkbar ohne weitere teaminterne Untergliederung. Die Führungsspanne solcher großen Teams wäre zudem vermutlich in vielen Fällen über dem, was etablierten und machbaren Größen entspricht. Die Identifikationsfunktion, mit der für alle Beteiligten auch ein Rahmen zur Identifikation geboten und die Möglichkeit zur Ausbildung von Loyalitäten gegeben wird, ist für eine Prozessorganisation schwer einzuschätzen. Zwar stellen Prozessoder Caseteams durchaus Gruppen dar, mit denen das Bedürfnis nach Zugehörigkeit, Identifikation und Motivation erfüllt werden könnte. Es gäbe jedoch eine Vielzahl gleich strukturierter Prozess- oder Caseteams parallel und somit wenig Anknüpfungspunkte für eine Abgrenzung und Identitätsstiftung. Die Identifikation ist in solchen gleichartigen Teams sicherlich schwieriger zu gewährleisten als zum Beispiel in Einheiten mit spezifischen Aufgaben, wie etwa der Erfüllung einer bestimmten Funktion oder der Betreuung eines bestimmten Marktes oder Kundensegments. Ein bewusst genutzter Wettbewerb zwischen den Prozess- oder Caseteams könnte die Identifikation mit dem eigenen Team vielleicht unterstützen. Auch hier gilt jedoch, dass die Identifikation umso schwieriger wird, je größer die Teams aufgrund der Komplexität der Aufgabe sein müssen. Die Stabilitätsfunktion könnte über eine Prozessorganisation gut erfüllt werden, da mit ihr gleichartige Geschäftsfälle in gleichartiger Weise abgewickelt werden. Ebenso ist ein Reagieren auf Einwirkungen von außen in stabiler Weise auch von einer Prozessorganisation um nichts weniger zu erwarten als von anderen Strukturierungsformen. Die Anpassungsfunktion könnte durch eine Strukturierung entlang der Prozesse sehr gut erfüllt werden, steht doch bei dieser Art der Organisation der Unternehmensstruktur die Leistungs- und Kundenorientierung im Vordergrund.210 Damit werden marktseitige Änderungen unmittelbar wahrgenommen. Sofern es sich um kleinere Anpassungen handelt, können die Case Teams darauf autonom reagieren. Bei größeren Änderungen bietet das Instrument der Prozessoptimierung einen etablierten Rahmen für die Anpassung der Prozesse an neue Anforderungen. Auf diesem Weg können auch technologiegetriebene Änderungen rasch in den Prozessablauf aufgenommen und genutzt werden. Anders ist dies bei der Compliancefunktion. In einer funktionalen Organisation erfüllen nur überschaubare Teams bestimmte Aufgaben, sodass hier die Sicherstellung, dass dies entsprechend den Vorgaben erfolgt, relativ leicht herzustellen 210 Insofern sieht Schmidt (2006) in der zunehmenden Bedeutung von Flexibilität und Reaktionsgeschwindigkeit den wesentlichen Grund für die Zunahme des Stellenwerts der Ablauforganisation gegenüber der Aufbauorganisation. (S. 103). Auch Gaitanides (2007), sieht bei einer objektorientierten Spezialisierung, die im Sinne eines End-to-End-Verständnisses der Prozesse, mit einer Prozessorganisation zusammenfällt, eine höhere Flexibilität als einen der Vorteile (S. 78).

129


ist. Bei einer Prozessorganisation würden dieselben Aufgaben jedoch von einer Vielzahl von Mitarbeitern durchgeführt – im Extremfall von fast allen. Für die Sicherstellung derartiger normativer Vorgaben für bestimmte Aufgaben wäre eine Prozessorganisation daher deutlich weniger gut geeignet als beispielsweise eine funktionale Organisationsstruktur, bei der die Einheiten nicht auf die Kundenleistung, sondern ihre bestimmten Teilaufgaben konzentriert sind. Denken wir etwa nur an die Einhaltung von Rechnungslegungsvorschriften (z. B. IFRS), Einkaufsrichtlinien oder Sicherheitsvorschriften. Zusammengefasst würde eine reine Prozessorganisation die Grundfunktionen einer Organisationsstruktur nur sehr bedingt erfüllen, und zwar bei entsprechender geringer Komplexität der erbrachten Leistungen und wenig komplexen Vorschriften. Je höher jedoch die Komplexität der erbrachten Leistungen desto weniger würde eine reine Prozessorganisation diese Grundanforderungen erfüllen. Die Stärke der Prozessorganisation liegt dabei in der Effektivität der Leistungserbringung. Sprich: Dadurch, dass die Teams die Geschäftsfälle von Anfang bis Ende integrativ bearbeiten und dem Kunden direkt verantwortlich sind, ist die Wahrscheinlichkeit einer zufriedenstellenden Leistungserbringung sehr hoch. Gleichzeitig liegt die Schwäche der reinen Prozessorganisation jedoch in der Effizienz: Dadurch dass gleichartige Aufgaben nicht gebündelt, sondern von jedem Team eigenständig erbracht werden, ist die Wahrscheinlichkeit hoch, dass die Erfüllung dieser Aufgaben nicht eine so hohe Produktivität erreicht wie bei einer geschäftsfallübergreifenden Bündelung in Teams von spezialisierten Experten, die nur bestimmte Aufgaben erfüllen. Genauer gesagt ist dies immer genau dann der Fall, wenn die Produktivitätsverluste durch die Übergaben im Zuge der Leistungserbringung geringer sind als die Produktivitätsgewinne aufgrund der ständigen Wiederholung derselben Arbeitsschritte. Darüber hinaus würde eine solche reine Prozessorganisation auch Mehrinvestitionen durch die Verfügbarkeit von Maschinen und Anlagen für jedes Prozess- oder Caseteam erfordern.211 Aus diesem Grund wird sie bei anlagenintensiven Geschäftsfeldern vielfach keine ökonomisch sinnvolle Alternative darstellen. Ebenso zeigt sich ein Nachteil in der Personalkostenstruktur: Da alle Prozessschritte von denselben Experten im Zuge der Rundumbearbeitung erfüllt werden, bestimmt die Summe aus den für die einzelnen Prozessschritte notwendigen Qualifikationen das Anforderungsprofil für die erforderlichen Case Worker. Ist dies sehr umfassend, so werden die benötigten Mitarbeiter eher teuer sein; umfasst der Prozess zudem auch einfache Schritte, für die nur wenig Qualifikation notwendig ist, so werden teure Mitarbeiterressourcen für einfache Pro211 Vgl. z. B. Osterloh, Frost (2000), S. 44: Sie illustrieren am Bespiel von Gate Gourmet, dass im Zuge des Umbaus auf eine Prozessorganisation die bis dahin genutzte Großgeschirrwaschanlage durch mehrere kleinere und flexiblere Waschanlagen ersetzt wurde. In gleicher Weise wurde das Prozessteam für die Organisation von Catering für Executive Flüge mit einer eigenen Küche und einer eigenen Administration ausgestattet (S. 48).

130


zessschritte eingesetzt. Eine Prozessorganisation wäre daher wohl wiederum nur für Prozesse mit wenig komplexen Prozessschritten auf einem möglichst einheitlichen Anforderungsniveau wirtschaftlich sinnvoll, um nicht teure Ressourcen für einfache Tätigkeiten zu verschwenden oder die Mitarbeiter damit eventuell sogar zu unterfordern. Demgegenüber kann eingewendet werden, dass die Prozessorganisation dafür die Ineffizienzen an den sonst üblichen organisatorischen Schnittstellen vermeidet. Erfahrungsgemäß ist es jedoch einfacher, diese Schnittstellen zu optimieren und zu managen als Einzelbearbeitungen auf dieselbe Produktivität wie bei einer gebündelten Bearbeitung zu heben. Eine reine Prozessorganisation ist daher eine Organisationsstruktur, die nur für die Erbringung von sehr speziellen Leistungen geeignet ist: nämlich Leistungen mit einer relativ geringen Komplexität der Aufgabe, einer hohen Variabilität sowie einem hohen und schwer strukturierbaren Informationsgehalt in der Leistungserstellung.212 Sie findet sich daher in der Unternehmenspraxis auch nur in ganz wenigen Bereichen: bei kleinen Handwerksbetrieben, Ein-Mann-Firmen oder im komplexen Projektgeschäft. In mittleren und großen Unternehmen mit komplexen und standardisierbaren Leistungen ist eine Prozessorganisation in der Praxis in reiner Form jedoch kaum zu finden.213 Kein Wunder, würde dies doch eine Organisation sein, die zwar maximale Integration entlang der Prozesse bietet, gleichzeitig aber auf alle Vorteile zum Effizienzgewinn aus der funktionalen Bündelung von verrichtungsgleichen Aktivitäten und auf die damit verbundenen Kostenvorteile verzichtet.214 Insofern ist es bei genauer Überlegung nicht verwunderlich, dass es kaum Beispiele für eine echte Prozessorganisation gibt.215 Die wenigen bekannten Beispiele stellen selbst meist nur Prozessorganisationen für überschaubare Teilprozesse dar. Das am häufigsten genannte Beispiel ist dabei jenes von Michael Hammer von der IBM Credit, inzwischen IBM Global Finance. Michael Hammer und James Champy schildern dieses Beispiel als ein Referenzbeispiel für den Reengineering212 Vgl. Bogaschewsky, Rollberg (1998), die anmerken, dass sich die in der Literatur genannten Beispiele vor allem auf Unternehmen und Prozesse beziehen, bei denen der Informationsfluss und nicht der Materialfluss im Vordergrund steht (S. 253.) 213 Vgl. z. B. auch Hiller, Minar-Hödl, Zahradnik (2010), die festhalten, dass eine Prozessorganisation als Primärorganisation aus ihrer Sicht „relativ selten“ vorkommt. Auch Thomas Davenport (1993, S. 161), hielt fest: “We know of no Western organization that has made radical strides towards a process-based structure.” Davenport sieht den Grund darin jedoch v. a. darin, dass dies neben den Prozessinnovationen zu viel an Veränderung auf einmal wäre (S. 162). 214 Vgl. Bogaschewsky, Rollberg (1998, S. 252–253), die deshalb die Prozessorganisation, bei der komplette Prozesse von Einzelpersonen oder Teams betreut werden, nicht als per se vorteilhaft ansehen. 215 Vgl. auch Schmelzer, Sesselmann (2010): Auch sie halten fest, dass eine vollständige Überführung aller Funktionen in Geschäftsprozesse in der Praxis kaum anzutreffen ist (S. 182). Ihr Verständnis einer echten Prozessorganisation basiert jedoch nicht wie hier auf einer End-to-End-Sicht der Geschäftsprozesse, wie aus ihrem Beispiel des Geschäftsgebiets Computertomographie der Siemens AG ersichtlich ist (S. 183–184). Auch Jochem, Landgraf (2010) halten fest, dass in der Praxis nur wenige reine Prozessorganisationen zu finden sind (S. 72).

131


ansatz, bei dem die gesamte Durchführungsverantwortung für alle Prozessschritte zur Bewilligung einer Finanzierung für ein IT-Investment bei einem Case Worker – dem sogenannten Deal Structurer – zusammengefasst wurde.216 Die komplette organisatorische Integration und damit die Beseitigung der bis dahin vorhandenen Organisationsbrüche entsprechen ohne Zweifel dem Prinzip der Prozessorganisation. Sehen wir uns jedoch den Prozess der Kreditantragsbewilligung genau an. Was ist genau der Bedarf, der durch diesen Prozess adressiert wird? – Es ist einerseits der Bedarf des Kunden nach einer Finanzierung seiner IT-Investition und andererseits der Bedarf des Kreditgebers IBM Finance nach einer transparenten Bewertung der Risiken eines solchen Kredits. Wird dieser Bedarf durch den Prozess gedeckt? – Nun, der zweite, interne Bedarf ja; der erstere, echte Kundenbedarf im Sinne eines echten End-toEnd-Verständnisses jedoch nicht. Dieser Bedarf nach der Finanzierung wird erst durch die Bereitstellung des Kredits gedeckt. Und im Sinne des definierten End-toEnd-Verständnisses, das den kompletten Geschäftsfall umfasst, geht dieser über die regelmäßige Bezahlung der Raten bis zum Abschluss nach kompletter Rückführung. Dieser komplette Abwicklungsteil ist jedoch nicht in der Hoheit des Deal Structurers, sein Prozess geht nur von der Anfrage des Kunden bis zur Bewilligung oder Ablehnung der Finanzierung. Im Sinne eines End-to-End-Prozessverständnisses stellt dies nur einen Teilprozess in der gesamten Leistungserbringung für den Kunden dar. Dieser Teilprozess, der zuvor organisatorisch sehr stark zersplittert war, wurde mithilfe von entsprechender IT-Unterstützung in einer Stelle integriert. Aus Sicht der Ausgangslage einer funktional extrem zergliederten Organisation mag dies ein großer, revolutionärer Schritt gewesen sein. Aus heutiger Sicht mit dem etablierten Prozessdenken, vermag man den revolutionären Charakter kaum noch nachempfinden. Denn ein Vertriebsmann, der eine Kundenanfrage aufnimmt, prüft und am Schluss bewilligt oder abweist, ist in vielen Unternehmen völlig normal. Es handelt sich um nicht mehr und nicht weniger als einen integrierten Teilprozess, wie man sie heute häufig findet. Weitere Beispiele, die von Margit Osterloh und Jetta Frost vor einem Jahrzehnt vorgestellt wurden, sind Gate Gourmet, das Statistische Amt des Kantons Zürich und die Bank Leu. Gate Gourmet217 ist eines der führenden Airline-Catering-Unternehmen. Sein Geschäft ist die Ver- und Entsorgung von Flugzeugen mit Mahlzeiten, Getränken und anderen Artikeln. Vor dem Reengineering bestand die Organisationsstruktur im Wesentlichen aus funktional organisierten Einheiten: ·

Der Bereich „Operations“ war zuständig für Transport und Kabinenausrüstung, für das Geschirr, die Abwäscherei, die Getränke und den Bordverkauf 216 Siehe Hammer, Champy (1994), S. 57–61. 217 Siehe Osterloh, Frost (2000), S. 38–49.

132


· · · ·

Der Bereich „Einkauf und Logistik“ war für die Bestellungen und das Lagerwesen zuständig Der Bereich „Food Production“ verantwortete die komplette Küche bis hin zur Portionierung und dem Tray Setting Und als Viertes gab es noch den Bereich „Rechnungswesen und Informatik“ Daneben bestanden Zentralbereiche für Human Ressourcen, Qualität/Hygiene sowie Organisation/Koordination

Im Zuge eines Reengineering-Projektes ging es darum, den Weg, wie Gate Gourmet sein Geschäft macht, angesichts des immer härteren Wettbewerbs und Kostendrucks völlig neu zu überdenken. Dabei wurden Kernkompetenzen identifiziert, Optimierungen vorgenommen (z. B. Einführung des Flow-Line Prinzips für die Trolleys oder des Kiosk-Systems) und auch eine neue Organisationsstruktur entwickelt. In dieser bestanden fortan vier Bereiche, die anhand der identifizierten Kernprozesse gestaltet wurden. ·

·

·

·

Der Bereich „Equipment Handling“, in dem die wichtigste Kernkompetenz gebündelt wurde, umfasste nunmehr den kompletten logistischen Teilprozess der Ver- und Entsorgung der Flugzeuge inklusive dem Waschen des Geschirrs und der Steuerung der Trolleys. Der Bereich „Goods Supply & Preparation“ betreute den kompletten Prozess für die Bereitstellung der Mahlzeiten und von Non-Food-Artikeln und verantwortete damit den Warenfluss. Er stellt alle Speisen und Getränke in den bereitgestellten Trolleys bereit. Im Bereich „Customer Service Process“ kümmerte man sich um den kompletten Auftragsabwicklungsprozess vom Angebot bis zur Rechnung. Er deckte somit den Informationsfluss zur physischen Warenbewegung im Equipment-Handling-Prozess ab und umfasste dafür auch die Informatik Als vierter Bereich wurde der Kernprozess „Executive Flights“ eingerichtet, der für das spezielle Kundensegment Sonderflüge alle diese Leistungen für diese speziellen Zielgruppe bündelte

Daneben bestanden nach wie vor die Zentralbereiche Human Ressourcen, Rechnungswesen und Einkauf. Das Projekt hat die Leistungserstellung bei Gate Gourmet in vielen Bereichen deutlich effizienter gemacht sowie den Fokus auf die strategisch wichtigen Kernprozesse gelegt. Beschränken wir uns hier jedoch einmal rein auf die Neugestaltung der Aufbaustruktur: Handelt es sich bei dem neuen Organigramm um eine Prozessorganisation im Sinne eines End-to-End-Prozessverständnisses? – Nein. Bei näherer Analyse wird schnell klar, dass hier keine integrierte Prozessverantwortung für den kompletten End-to-End-Prozess vom Kunden zum Kunden vorliegt, auch wenn das von den Autoren teilweise so suggeriert wurde: So geht für sie etwa 133


der Equipment-Handling-Prozess „ohne Schnittstellen vom Kunden (Entnahme der gebrauchten Trolleys an Board) bis zum Kunden (Beladung des Flugzeugs mit neu aufgefüllten Trolleys“.218 Mit derselben Begründung hätte man jedoch auch den Prozess der Angebotsannahme (vom spezifizierten Menüauftrag des Kunden bis zur Auftragsbestätigung an den Kunden) oder jenen der Rechnungsstellung (von der Rechnung an den Kunden bis zur Zahlung vom Kunden) als eigenständige Prozesse abgrenzen können. Die Definition von end-to-end auf Basis festgelegter Kontaktpunkte deckt sich hier nicht mit dem vorausgehenden Bedarf und der komplett erbrachten Leistung, sondern ist aus Prozesssicht eher beliebig. Betrachten wir die Kundengeschäftsfälle, so zeigt sich, dass diese nach wie vor durch mehrere Bereich gehen. So durchlief ein Auftrag einer Airline für ein spezielles Menü vor dem Reengineering die Bereiche Food Production219, Einkauf/Logistik, Operations und Rechnungswesen. In der dann geschaffenen Prozessorganisation durchläuft er die Bereiche Customer Service, Goods Supply & Preparation, Equipment Handling, und Financial Services. Es handelt sich bei den neu geschaffenen Bereichen um organisatorisch integrierte Teilprozesse: weder Customer Service (in dem auch die gesamte Informatik als interne Dienstleistungsfunktion integriert wurde), noch Equipment Handling oder Goods Supply & Preparation erbringen komplette Leistungen für den Kunden im Sinne einer Rundumbearbeitung vom Bedarf zur Leistung. Die interessante Ausnahme stellt hier jedoch der dritte Kernprozess dar: „Executive Flights“. Anders als für alle anderen Flüge wird hier für spezielle Sonderflüge ein individuelles Catering angeboten, das komplett aus einem Team heraus abgewickelt wird. Das Team arbeitete dabei laut den Autoren auch mit einer eigenen Küche und einer eigenen Administration. Insgesamt umfasste dieser Prozess damals cirka sechs Mitarbeiter. Für diesen Prozess liegt auch nach dem hier entwickelten End-to-EndVerständnis eine echte Rundumbearbeitung im Sinne einer Prozessorganisation vor. Mit Ausnahme der Leistungserbringung für Executive Flights, wo dies anders ist, liegt somit auch in der geschaffenen Prozessorganisation keine komplette Verantwortung für den gesamten End-to-End-Prozess und die Leistungserbringung für den Kunden vor – und zwar aus guten Gründen nicht. Ausgehend von einem End-to-End-Prozessverständnis entspricht daher auch das Beispiel Gate Gourmet in Summe nicht einer echten Prozessorganisation. Vielmehr stellt das Beispiel eine gemischte Organisation aus integrierten Teilprozessen, (funktionalen) Zentralfunktionen und einem kleinen sehr speziellen Bereich einer echten Rundumbearbeitung dar. Sicherlich hat die Änderung viel zur Prozessorientierung im Unternehmen beigetragen und war in Summe ein großer Schritt vorwärts. Auch das Beispiel Gate Gourmet zeigt jedoch – wie Margit Osterloh und Jetta Frost auch selbst anmerken – dass die Schaffung einer reinen Prozess218 Osterloh, Frost (2000), S. 44. 219 Aus der kurzen Projektbeschreibung von Osterloh, Frost (2000) geht leider nicht hervor, wo vor dem Reengineering die Auftragsabwicklung stattfand.

134


Abb. 33: Organisation von Gate Gourmet vor und nach dem Reengineering Ende der 90er

organisation nicht sinnvoll wäre, sondern vielmehr eine möglichst gute Mischung aus Aufgabengliederung, funktionalen Bündelung und Prozessintegration gefunden werden muss, die für die jeweilige Situation des konkreten Unternehmens passt. Das zweite Beispiel, das Margit Osterloh und Jetta Frost in ihrem Buch vorstellen, ist das Statistische Zentralamt Zürich.220 Dieses ist insofern sehr interessant, als es in diesem Amt vor der Reorganisation relativ autonome Fachabteilungen für Statistiken in den Themenfeldern Bevölkerung & Wirtschaft, Finanzen & Politik, Steuern sowie Umwelt & Verkehr gegeben hat. Jede von ihnen war anscheinend selbständig für die komplette Erstellung von Statistiken im eigenen Themenfeld verantwortlich, und zwar von der Datenerhebung, über die Datenaufbereitung und die Berichterstellung bis hin zur Publikation. Laut den Autoren handelte es sich um „kleine Königreiche“. In der neuen Prozessorganisation wurde der Datenanalyse und -distributionsprozess als wichtigster Kernprozess identifiziert. Die Datenakquisition, die diesem vorgelagert ist, wurde für alle Statistikbereiche gebündelt, um eine doppelte Ansprache der Kunden zu vermeiden. Der Prozess der Datenauswertung wurde nach drei Komplexitätsgraden – komplex, mittelschwer und Routinefälle – unterschieden. Zudem wurden die alten bereichsspezifischen Datenbanken durch eine gemeinsame relationale Datenbank ersetzt. Darüber hinaus wurden die Kundenaufträge für bestimmte Datenauswertungen je nach Auslastungsgrad über die Teams immer wieder neu verteilt. Die früheren Abteilungsleiter wurden als Process Owner für die Prozesse installiert und standen auch als Experten für Spezialfragen zur Verfügung. 220 Siehe Osterloh, Frost (2000), S. 53–61.

135


Abb. 34: Organisation des Statistischen Amts Zürich vor und nach dem Reengineering Ende der 90er

Wurde damit eine Prozessorganisation im Sinne eines End-to-End-Verständnisses vom Bedarf des Kunden zur kompletten Erbringung der Leistung geschaffen? – Nein, ganz im Gegenteil erfüllte sogar die alte Organisation weitestgehend diese integrative Bearbeitung von eigenständigen Leistungen im Sinne von Statistiken für die einzelnen Themenfelder. Diese Organisation – eine Prozessorganisation – wurde sichtlich mangels schlechter Performance (Doppelgleisigkeiten, mangelnde Ausrichtung an der Kernkompetenz, . . .) durch eine hybride Organisationsform abgelöst, bei der Teilprozesse leistungsübergreifend gebündelt wurden. Dieses Beispiel zeigt damit noch viel deutlicher, dass eine reine Prozessorganisation eben nicht ideal ist und selbst bei kleineren Organisationen wie etwa dem Statistischen Zentralamt des Kantons Zürich mit damals rund 25 Mitarbeitern eine stärkere abteilungsübergreifende Bündelung von Teilprozessen zielführend sein kann. Das dritte Beispiel von Margit Osterloh und Jetta Frost betrifft die Bank Leu.221 Hier war die alte Organisation im Zahlungsverkehr sehr stark funktional nach den einzelnen Bearbeitungsschritten der Zahlungsverkehrsabwicklung untergliedert. Im Zuge der Einführung einer Prozessorganisation wurde der Kernprozess nach Kundengruppen segmentiert, sodass die Abwicklung des Zahlungsverkehrs für Privatkunden, für Firmenkunden und für Anlagekunden zusammengefasst wurde. Daneben wurden drei funktionale Teams für Schecks, Investigations und für den Verkauf von Produkten geschaffen, und zwar aus Gründen der Know-how-Spezialisierung, der Sicherstellung 221 Siehe Osterloh, Frost (2000), S. 64–71.

136


der Compliancefunktion – Osterloh und Frost sprechen in diesem Zusammenhang von einer unité de doctrine“ – sowie zur Ausnutzung von Größenvorteilen. Damit entstand in Summe eine matrixähnliche Organisationsstruktur mit teilweise integrierten Endto-End-Prozessen und der bewussten Herausnahme und funktionalen Bündelung von bestimmten Prozessschritten über alle Produkte. Die Bank Leu ist damit ein gutes Beispiel einerseits für den Sinn einer stärkeren organisatorischen Integration der Durchführungsverantwortung und gleichzeitig für den Unsinn einer reinen Prozessorganisation – denn selbst hier wurde der Vorteil von bestimmten funktionalen Bündelungen erkannt und im Gesamtentwurf aufgenommen. Margit Osterloh und Jetta Frost halten daher auch selbst bereits fest, dass eine Auflösung der funktionalen Einheiten zugunsten von funktionsübergreifenden Prozessen nur teilweise möglich ist und in vielen Bereichen auf die Vorteile einer funktionalen Spezialisierung nicht verzichtet werden kann. Die Folge einer reinen Prozessorganisation wären unwirtschaftliche Unterauslastungen, teure Doppelspurigkeiten, der Verzicht auf die Vorteile aus Größendegressionsvorteilen (economies of scale) sowie eine Schwierigkeit, bestimmte Normen in der Organisation effektiv umzusetzen (unité de doctrine).222 Ein neueres Beispiel einer Prozessorganisation ist die von Hermann Schmelzer und Wolfgang Sesselmann beschriebene Aufbauorganisation des Geschäftsgebiets Computertomografie (CT) der Siemens AG:223 Dabei wurden anstatt der früheren Struktur mit eigenen Abteilungen für die Kundenbetreuung, die Beschaffung und Logistik etc. sechs Prozesse mit einer entsprechenden Untergliederung in Teilprozesse eingeführt (siehe Abb. 35): · · · · · ·

Strategy to Engineering Requirement Specification (ERS) Engineering Sales Support Order to Billing Detector Business Executive Management

Wie schon in den vorherigen Beispielen ist auch hier leicht ersichtlich, dass keiner der definierten Prozesse einem echten End-to-End-Verständnis vom Kundenbedarf zur Leistungserbringung entspricht. Vielmehr handelt es sich auch hier um ein Beispiel für eine Prozessintegration auf Teilprozessebene. Jeder Kundengeschäftsfall durchläuft nicht nur genau einen der definierten Prozesse, sondern mehrere. Die in der Praxis in vielen Unternehmen bekannten Schnittstellenprobleme zwischen Produktentwicklung, Engineering und Vertrieb können auch hier nicht innerhalb der definierten Prozessverantwortung gelöst werden. 222 Siehe Osterloh, Frost S. 108–109. Vgl. auch Weilkiens, Weiss, Grass (2010), die ebenso anmerken, dass eine Konzentration auf die horizontale Struktur der Prozesse dazu führen kann, dass funktionale Expertise dupliziert wird (S. 63). 223 Schmelzer, Sesselmann (2010), S. 183–184.

137


Abb. 35: Prozessorganisation des Geschäftsfelds Computertomografie der Siemens AG224

Aber auch innerhalb der einzelnen Teilprozesse ist die klare Abfolge der Leistungserstellung nicht unbedingt überall für Außenstehende sofort ersichtlich: So scheint der Bereich Sales Support doch eher nach inhaltlichen Aufgaben als nach klaren Teilprozessen des Vertriebsprozesses gegliedert. Ein letztes Beispiel wird von Roland Gareis und Michael Stummer angeführt, und zwar anhand eines Anlagenbauunternehmens (siehe Abb. 36): Die Organisationsstruktur basiert dabei auf vier großen Prozessen „Customer Processes“, „Construction of large plants“, „Procurement processes“ und „Construction of small plants“. Auch bei diesen handelt es sich nicht um End-to-End-Prozesse im Sinne einer vollumfänglichen Leistungserbringung vom Kunden zum Kunden, sondern vielmehr um abgegrenzte Teilprozesse der Leistungserstellung. Innerhalb dieser besteht zumindest teilweise ein prozessualer Zusammenhang. Dabei scheint der Prozess für kleine Anlagen stärker prozessual integriert als jener für große Anlagen. Neben den vier Prozessen bestehen weiters Corporate Functions für Marketing, Accounting, Quality Management, Testing, IT, Research and Development, Improvement Management sowie Safety and the Environment. Ähnlich wie die bereits besprochenen Beispiele zeigt auch dieses Beispiel eine hybride Aufbauorganisation basierend auf der stärkeren Integration von Teilprozessen mit weiterhin bestehenden funktionalen Elementen. Nicht nur die theoretischen Überlegungen, sondern auch die bekannten Beispiele zeigen damit, dass eine reine Prozessorganisation nicht oder nur in sehr speziellen Bereichen und unter sehr speziellen Bedingungen sinnvoll ist. Es ist daher nicht verwunderlich, dass sich mehr als fünfzehn Jahre nach dem ersten Aufkommen der Forderung nach einem Shift der Organisation um 90 Grad und der Einführung einer Prozessorganisation zur Überwindung der traditionellen, funktionalen Strukturen, in der Praxis nach wie vor so gut wie keine Beispiele für eine echte Prozessorganisation 224 Schmelzer, Sesselmann (2010), S. 184.

138


Abb. 36: Prozessorganisation eines Anlagenbauunternehmens225

finden. Ganz im Gegenteil wäre eher ihre Existenz und zahlreiche Verbreitung etwas, was überraschen würde.226 Es ist daher blanker Unsinn, als ultimatives Ziel des Prozessmanagements einen 90-Grad-Shift der bestehenden Aufbauorganisation zu fordern. Teilweise wird dieses Ziel inzwischen etwas abgeschwächt durch die Darstellung von verschiedenen Ausprägungen der Prozessorganisation, wobei explizit oder implizit jedoch doch meist die reine Prozessorganisation entsprechend dem 90-Grad-Shift der Organisation als beste und anstrebenswerteste Form bestehen bleibt.227 225 Gareis, Stummer (2008), S. 206. 226 Vgl. auch Rudolf Wilhelm (2007), S. 19. Vgl. auch Hammer (1997, S. 141–149): Er führt als Beispiel für die Prozessorientierung American Football an und beschreibt die Prozessverantwortungen dabei im Detail. Gleichzeitig ist American Football jedoch auch eine jener Sportarten, in der es eine sehr hohe Spezialisierung in den Positionen der Spieler gibt. Insofern ist auch das Beispiel von Hammer ein Beleg, dass Spezialisierung und Prozessorientierung kein Widerspruch sein müssen, sondern dass erstere für bestimmte Kenntnisse notwendig ist und letztere die Integration herstellt. Das Beispiel widerspricht somit Hammers genereller These, dass die Prozessorientierung die Fragmentierung und funktionale Grenzen auflöst (s. z. B. S. 215). 227 Vgl. etwa Schmelzer, Sesselmann (2010), S. 176–187. Sie beschreiben etwa drei verschiedene Formen der Prozessorganisation: Die Einfluss-Prozessorganisation, die Matrix-Prozessorganisation und die reine Prozessorganisation, lassen jedoch keinen Zweifel daran, dass letztere das beste und konsequenteste Modell darstellt. Manche Autoren gehen auch dazu über, den Begriff der Prozessor-

139


Man mag solchen Forderungen zugutehalten, dass sie für eine stärkere prozessuale Integration über die Abteilungen hinweg plädieren und dies in dieser prägnanten Metapher zum Ausdruck bringen – als tatsächliches Zielbild für die Primärorganisation ist eine echte Prozessorganisation jedoch für die meisten Unternehmen kompletter Unfug. Die fehlende reale Existenz von Prozessorganisationen in der Praxis liegt daher nicht an der mangelnden Courage der Manager228, dem falschen funktionalen Mindset229 oder daran, dass das Prozessmanagement noch nicht lange genug etabliert ist. Sie liegt simpel daran, dass diese Organisationsform in Summe für kaum ein Unternehmen vorteilhaft wäre. Geary Rummler, Alan Remias und Richard Rummler bringen dies sehr plakativ auf den Punkt, wenn sie sagen „let’s be very clear: Organizing a business around processes is a bad idea.“230 Prozessintegration ist ein wesentlicher Aspekt in der Gestaltung von Organisationsstrukturen, aber eben nur einer von mehreren. Die Kunst des Organisationsdesigns besteht darin, diese für das jeweilige Unternehmen in seiner konkreten Situation in der bestmöglichen Weise zu kombinieren. Gute Prozessmanager sollten das wissen. Gute Manager wissen das schon lange.

3.2 Prozessverantwortung – Prozessmanagement als Element der Sekundärorganisation Unabhängig von der Möglichkeit einer reinen Prozessorganisation und dem Element der Prozessintegration für bestimmte Teilprozesse spielt aber Prozessmanagement auch noch eine zweite, viel wichtigere Rolle im Rahmen der Entwicklung von Organisationsstrukturen für Unternehmen: und zwar jene eines Organisationselements, das mithelfen kann, die Nachteile aus verschiedenen anderen Organisationsformen abzumildern. Shared Service Center sind zum Beispiel ein Organisationselement, das Unternehmen, die grundsätzlich nicht funktional organisiert sind, einen Weg bietet, für spezielle Teilprozesse von der Effizienz einer funktionalen Bündelung zu profitieren, ohne die gesamte Organisation auf eine funktionale Strukturierung zu ändern. Ein dezidiertes Produktmanagement ist ein ergänzendes Organisationselement, mit dem eine Organisation, die grundsätzlich nicht produktorientiert aufgestellt ist, die Zuganisation anders zu definieren. So z. B. Schmelzer, Sesselmann (2010), die unter Prozessorganisation „die Integration der Geschäftsprozesse in die Organisationsstruktur (Aufbauorganisation) des Unternehmens bzw. der jeweiligen Geschäftseinheit“ definieren (S. 176) – in diesem Sinn hat jedes Unternehmen eine Prozessorganisation. Ähnlich Kugeler, Vieting (2008), die anstatt von Prozessorganisation von prozessorientierter Organisation sprechen und deren Ausprägung von der individuellen Gewichtung der einzelnen Effizienzkriterien abhängig sehen – die von ihnen gestellt Frage, ob eine prozessorientierte Organisation Weg oder Ziel sei, bleibt unbeantwortet (S. 236–238). 228 Vgl. dazu z. B. Schmelzer, Sesselmann (2010), S. 76 und 186. 229 Vgl. Spanyi (2007), S. 107. 230 Rummler, Remias, Rummler (2010), S. 76.

140

Prozessverantwortung – Prozessmanagement als Element der Sekundärorganisation

sammenarbeit aus der Perspektive der Produkte über die einzelnen Bereiche und Abteilungen hinweg treiben und verbessern kann.231 Genauso ist Prozessmanagement ein Organisationselement, das es Unternehmen und Institutionen ermöglicht, die Nachteile abzufedern und abzumildern, die aus verschiedenen gewählten Aufbaustrukturen für die Integration der Leistungserbringung entstehen. Als ergänzendes Organisationselement der sogenannten Sekundärorganisation232 ist Prozessmanagement daher vor allem für jene Unternehmen und Institutionen sinnvoll und nutzbringend, die keine Prozessorganisation haben und diese auch nicht anstreben. Denn würden sie dies tun, könnten sie die Organisationsstruktur ja sofort in diesem Sinn ändern. Obwohl viele Unternehmen und Institutionen sich schon intensiv mit Prozessmanagement befasst und es in ihren Strukturen auf verschiedene Art und Weise verankert haben, wurde dies kaum je als Schritt zur Vorbereitung einer kompletten Prozessorganisation eingesetzt. Der Mythos von der Prozessorganisation, die das Endziel des Prozessmanagements sei, auf das dieses zwingend zusteuere, ist – wie gezeigt wurde – auf Basis organisationstheoretischer Grundlagen unbegründet und hat sich auch in der Praxis nicht bewahrheitet. Prozessmanagement ist weit davon entfernt, der Wegbereiter für die Einführung einer reinen Prozessorganisation zu sein. Ganz im Gegenteil bezieht Prozessmanagement seine Existenzberechtigung und seinen Wertbeitrag in der Unternehmenspraxis vielmehr gerade daraus, dass es keine Prozessorganisation gibt. Prozessmanagement ist daher ein Organisationselement der Sekundärorganisation, das einen wertvollen Beitrag leisten kann, die Mängel verschiedener anderer Organisationsformen im Hinblick auf die Integration und die effiziente und kundenorientierte Abarbeitung der Geschäftsfälle zu mildern. Welche Mängel sind dies konkret, die mit Prozessmanagement abgefedert werden können? Es sind dies insbesondere folgende Punkte an bestehenden Organisationsstrukturen, die uns aus dem Unternehmensalltag gut bekannt sind: · · · ·

Mangelnde übergreifende Verantwortung für die Leistungserbringung Mangelnde bereichsübergreifende Koordination bei konkreten Geschäftsfällen Unzureichende bereichsübergreifende Zusammenarbeit zur Weiterentwicklung von Prozessen aus einer End-to-End-Sicht Mangelnde Auskunftsfähigkeit über den Status von Geschäftsfällen bei bereichsübergreifender Bearbeitung

231 Vgl. z. B. Bogaschewsky, Rollberg (1998, S. 239), die hinsichtlich der Koordination von Prozessen auf eine Ausgestaltung wie im Produkt- oder Projektmanagement verweisen, bei der die Produktoder Projektmanager die prozessorientierte Koordination des Ablaufs übernehmen, während die Funktionsmanager für die Kapazitätsbereitstellung und -auslastung verantwortlich sind. 232 Vgl. dazu Nicolai (2009, S. 185), die ebenso die Ausgestaltung einer Prozessorganisation als Primärorganisation oder als Sekundärorganisation kurz umreißt.

141


Abb. 37: Gedankliche Trennung von Prozessdesign und Prozessdurchführung

Diese Mängel können mit dem End-to-End-Prozessmanagement durch die Definition einer klaren Prozessverantwortung adressiert und in ihren negativen Effekten abgefedert werden. Der Trick dafür ist die gedankliche Trennung von Prozessdesign und -optimierung einerseits und der Prozessausführung andererseits.233 Denn für die Prozessausführung kann in den allermeisten Fällen, wie im letzten Abschnitt gezeigt wurde, keine allumfassende Prozessverantwortung im Sinne einer kompletten Rundumbearbeitung vom Bedarf des Kunden bis zur vollständigen Erbringung der Leistung und aller Abwicklungsschritte hergestellt werden. Dafür sind die meisten erbrachten Leistungen zu komplex und die für die einzelnen Schritte der Leistungserbringung notwendigen Aktivitäten zu unterschiedlich. Trennt man von der Prozessausführung jedoch gedanklich die konzeptionelle Ebene des Prozessdesigns und der Prozessoptimierung, so ist es für diesen Bereich durchaus möglich, eine klare Prozessverantwortung zu definieren.234 Vielfach wird hier argumentiert, dass dies nicht möglich sei, weil ein Design und Verbessern der Prozesse ja nur von den Ausführenden selbst erfolgen kann. Das ist jedoch falsch. Denn zum einen heißt die Definition einer Prozessverantwortung für Design und Verbesserung ja nicht, dass alle anderen am Prozess Beteiligten deshalb ausgeschlossen und aus ihrer Verantwortung entlassen sind. Ganz im Gegenteil werden wir später beim Managen der Prozesse auf die Einbindung der am Prozess Beteiligten und die gemeinsame Optimierungsarbeit zurückkom233 Diese Trennung sowie der generelle Ansatz des Prozessmanagements, dass Prozesse durch bestimmte Experten im Management vorab geplant und optimiert werden und ihre Ausführung nicht einfach den am Prozess Beteiligten überlassen wird, folgt dem Ansatz des Scientific Management von Frederick Winslow Taylor (siehe Taylor 1911). 234 Vgl. dazu auch Neumann, Probst, Wernsmann (2008), für die Prozessverantwortung ebenso die Führung und Verbesserung von Prozessen beinhaltet und damit auch parallel zur Linienorganisation bestehen kann (S. 318–319).

142


Abb. 38: Einordnung der Prozessverantwortung in das Gesamtbild

men. Prozessverantwortung ist daher zu einem Gutteil eine Steuerungs- und Koordinationsverantwortung im Sinne des Initiierens, Treibens, Moderierens und Überwachens der Umsetzung. Zum anderen hat Organisationsgestaltung aber auch immer einen gewissen Vorgabecharakter, bei dem die Leistungserstellung im Unternehmen durch Entscheidungen von oben in gewissem Ausmaß strukturiert wird. So werden etwa Aufbauorganisationsstrukturen oder Unternehmensrichtlinien ja auch nicht alleine von den Beteiligten definiert, ohne die eine Umsetzung als nicht möglich gesehen würde. Nein, gute Organisationsgestaltung passiert unter Einbindung der Beteiligten, mit einer übergreifenden Koordination und mündet am Ende in einer Festlegung der Unternehmensführung. Für die Gestaltung und Weiterentwicklung der Geschäftsprozesse aus End-to-End-Sicht kann Prozessmanagement über die Definition von klaren Prozessverantwortungen genau diese übergreifende Koordination beitragen. Dies heißt nicht, dass die Einbindung der am Prozess Beteiligten oder die Verantwortung der Unternehmensführung dadurch weggelassen werden kann oder ersetzt wird. Ganz im Gegenteil: Die Mitwirkung der Beteiligten an einem Prozess ist auch auf der konzeptionellen Ebene ein essenzielles Element für erfolgreiche Prozessarbeit; ebenso ist die Führungsverantwortung des Managements in Bezug auf die Prozessgestaltung ein essenzieller Erfolgsfaktor für gute Prozesse und damit unersetzlich. Prozessmanagement kann über die Festlegung und das Leben von Prozessverantwortung als Organisationselement der Sekundärorganisation die Brücke zwischen beidem bilden. Die Unternehmensführung wird damit in Bezug auf die operative Arbeit zur Ausgestaltung der Prozesse entlastet, und die am Prozess Beteiligten werden über Bereichs- und Abteilungsgrenzen hinweg aus Prozesssicht koordiniert und gesteuert.

143


Zur Verankerung einer derartigen Prozessverantwortung haben sich in der Praxis drei Rollen als notwendig und sinnvoll erwiesen: · · ·

Process Owner Process Manager ein zentrales Prozessmanagementteam

Diese werden im Folgenden genauer ausgeführt. 3.2.1 Process Owner

Prozessverantwortung heißt, dass nach der erfolgten Identifikation der Prozesse, wie sie weiter oben eingehend dargestellt wurde, jedem Prozess ein Prozessverantwortlicher (Prozesseigner oder process owner) zugeteilt wird. Dieser Process Owner hat die Gesamtverantwortung über den jeweiligen Prozess aus End-to-End-Sicht und ist dem Kunden für das Ergebnis des Prozesses verantwortlich.235 Um dies sicherstellen zu können, könnte der Process Owner nun alle notwendigen Teilschritte für den Prozess mit seinen eigenen Ressourcen bewerkstelligen, also von der Entwicklung des Produkts über das Marketing und die Akquisition neuer Kunden, die Auftragsbearbeitung, Leistungserstellung, Zustellung, Fakturierung, buchhalterische Verbuchung, Abführen der Steuern, etc. etc. Manche dieser Schritte können in einem Unternehmensverbund produktübergreifend jedoch effizienter und besser erfüllt werden, als dies für den Process Owner und seinen End-to-End-Prozess selbst der Fall wäre. Würde er etwa die Buchhaltung für seine Geschäftsfälle selbst führen, so hätte er vermutlich nur wenige Buchhalter, müsste entsprechende Kapazitäten für Urlaub und Krankheitsfälle selbst vorhalten und könnte keine Größendegressionseffekte in der Produktivität erreichen, wie das ein Shared Service Center kann, in dem die Buchhaltungsaufgaben für alle Produkte des Unternehmens gebündelt werden und damit sowohl die Erledigung der Einzelschritte durch die hohe Frequenz als auch die Auslastung der Mitarbeiter durch die große Menge an Fällen optimiert werden kann. Für das Gesamtunternehmen wird es daher effizienter sein, manche Servicefunktionen über alle End-to-End-Prozesse zu bündeln und den leistungsverantwortlichen Bereichen als Service gegen interne Verrechnung anzubieten. Bei einem kostenmäßig entsprechend attraktiven Angebot wird der Process Owner diese Services auch in Anspruch nehmen und die entsprechenden Teilprozesse nicht mehr selbst erbringen, sondern durch die Service Center erbringen lassen. 235 Vgl. z. B. Osterloh, Frost (2000), S. 32, die ebenfalls je Prozess genau eine prozessverantwortliche Person, den Process Owner sehen. Für den normativen Steuerungsprozess ist der Prozess-Owner deckungsgleich mit dem Beauftragten der obersten Leitung, wie er in Qualitätsmanagementansätzen definiert ist und gefordert wird (vgl. Wagner 2001, S. 121).

144


Das heißt jedoch nicht, dass er damit nicht mehr die Gesamtverantwortung über den kompletten Prozess hat. Diese bleibt nach wie vor bei ihm. Mit der Übertragung von Teilprozessen wird lediglich die Ausführung dieser Teilleistungen an Bereichsexterne delegiert. Wie bei einer normalen Delegation von Aufgaben bleibt auch hier die Steuerungsverantwortung weiterhin beim Process Owner. Das heißt, er muss vorgeben und definieren, welche Teilleistungen er in welcher Qualität benötigt und die Erfüllung dieser Teilleistungen ergebnisbezogen überprüfen. Während er jedoch bei Teilprozessen, die im eigenen Bereich ausgeführt werden, auch auf die genaue Abfolge der Prozessschritte und auf die Ressourcenausstattung Einfluss nehmen kann, so gestaltet sich die Beziehung bei nach außen delegierten Teilprozessen wie eine Auftraggeber-/Auftragnehmerbeziehung: der Process Owner als Auftraggeber definiert die Anforderungen und prüft, ob die Qualität der Ergebnisse mit der getroffenen Vereinbarung übereinstimmt; die genaue Abfolge der Prozessschritte und die Ressourcenausstattung liegen jedoch in der Oberhoheit der übernehmenden Einheit als autonomem Auftragnehmer. Anforderungen, interne Preise für die Leistungen sowie Art der Überprüfung und Eskalationsstufen für eine derartige Auftraggeber-/Auftragnehmerbeziehung werden in entsprechenden Servicevereinbarungen (Service Level Agreements) vereinbart und festgeschrieben.236 Entspricht die Qualität der Ergebnisse längerfristig nicht den vereinbarten Standards oder kann der Process Owner die entsprechenden Teilprozesse selbst effizienter und kostengünstiger durchführen, so liegt es in seiner Entscheidungshoheit, die Ausführung wieder selbst im eigenen Bereich zu organisieren (also diese Teilprozesse aus seiner Sicht wieder „inzusourcen“). Da die Übernahme von Services durch Serviceeinheiten sich üblicherweise am Beginn erst einspielen muss und gerade neu geschaffene Serviceeinheiten eine gewisse Zeit brauchen, bis sich das interne Zusammenspiel so eingeschliffen hat, dass die Skalenvorteile tatsächlich genutzt werden können, werden üblicherweise am Beginn Übergangsfristen vereinbart, für die die Process Owner auf ihr Entscheidungsrecht zur Rückverlagerung verzichten. Erst nach dieser Übergangszeit – sinnvoll sind dafür in der Praxis zwischen 12 und 18 Monate – gilt das Entscheidungsrecht der Process Owner. Gibt es im bereichsübergreifenden Zusammenspiel Probleme in einem End-toEnd-Prozess, so liegt es in der Verantwortung des Process Owners, diese Probleme zu adressieren, zu analysieren, gemeinsam mit den Process Ownern der beteiligten Teilprozesse eine Lösung zu suchen und den Prozess zu optimieren.237 Der Process Owner hat damit eine wichtige koordinative Verantwortung für seinen Prozess, der er sich auch durch den Hinweis auf den möglichen Ursprung der Probleme in Teilprozessen, die nicht von seinen eigenen Mitarbeitern ausgeführt werden, nicht entziehen 236 Vgl. Gaitanides (2007), S. 77. 237 Vgl. dazu Rummler, Brache (1997): Für sie ist es eine der Hauptaufgaben von Managern, Schnittstellen zu managen (S. 9).

145


kann. Gibt es etwa in einem Geschäftsprozess „Anbieten von Standardmaschinen“ Probleme in der Verbuchung der Aufträge oder bei der korrekten Zuordnung von Teilzahlungen der Kunden zu den Aufträgen, so kann er dieses Problem nicht auf die Buchhaltung abschieben und diese beschuldigen. Als Process Owner ist es in so einer Situation seine Pflicht, alle Beteiligten an einen Tisch zu holen und herauszufinden, wo genau die Ursachen für diese Probleme liegen. Liegen sie in Teilprozessen, die in seinem eigenen Bereich durchgeführt werden, so ändert er dies direkt; liegen sie in Teilprozessen, die von anderen Bereichen durchgeführt werden, so vereinbart er gemeinsam mit den betroffenen Process Ownern entsprechende Veränderungen und Verbesserungsmaßnahmen. So kann es etwa sein, dass es Probleme in der Verbuchung der Aufträge gibt, weil es im Vertrieb keine akzeptierte Standardvorlage für Aufträge gibt, sondern jedes Vertriebsteam mit eigenen Formularen arbeitet, was Aufwand und Fehler verursacht. Oder es kann sein, dass Teilzahlungen in der Buchhaltung deshalb nicht zugeordnet werden können, weil die Zahlungspläne aus dem Angebot im Zuge der Verhandlungen noch geändert werden, diese Änderung vom Vertrieb aber nicht oder erst sehr spät im System aktualisiert wird, sodass die Buchhaltung noch mit alten Zahlungsplänen arbeitet, wenn die ersten Teilzahlungen eintreffen. Vielfach liegen die Ursachen für Probleme nicht im betroffenen Teilprozess, sondern in anderen, vorgelagerten Teilprozessen. Gerade deshalb ist die End-to-EndSicht über die gesamte Leistungserstellung so entscheidend. Denn nur so können teilprozessübergreifende Probleme erkannt und Verbesserungen erzielt werden. Die Umsetzung solcher Maßnahmen obliegt den jeweiligen Process Ownern der betroffenen Teilprozesse; das Nachverfolgen der Umsetzung und die Kontrolle, ob die Maßnahmen effektiv waren, liegt beim Process Owner des gesamten End-to-End-Prozesses. Sollte es einmal für den Process Owner des Gesamtprozesses nicht möglich sein, mit den Process Ownern beteiligter Teilprozesse eine Einigung zu finden, so fungiert der Vorstand oder die Geschäftsführung als Eskalationsstufe. In diesem Fall liegt es in der Verantwortung des Process Owners des gesamten End-to-End-Prozesses, das Problem an diese Ebene zu eskalieren und dort mit den gegensätzlichen Standpunkten und Argumenten für eine Entscheidung vorzulegen. Um eine faire Darstellung der Standpunkte zu gewährleisten, werden bei solchen Eskalationsmeetings sinnvollerweise auch die Process Owner der anderen betroffenen Teilprozesse direkt beigezogen. Diese Gesamtverantwortung über den Prozess gegenüber dem Kunden und die Koordinationsverantwortung für alle beteiligten Teilprozesse sind der Kern der Rolle des Process Owners. Die European Association of Business Process Management definiert einen Process Owner daher als „Person, die dauerhaft Verantwortung dafür trägt, komplette End-to-End-Prozesse erfolgreich zu gestalten, umzusetzen und auszuführen, und die Rechenschaft über den Erfolg des Prozesses ablegen muss“.238 238 Siehe EABPM (2009), S. 200. Vgl. auch Wagner, Patzak (2007), S. 80: Für sie ist der Prozessverantwortliche derjenige, „der den Prozess festlegt, freigibt und für dessen Umsetzung sorgt – somit die

146


Da End-to-End-Prozesse zu umfangreich sind und es nicht sinnvoll wäre, alle Teilprozesse für die Leistungserstellung selbst zu verantworten und durchzuführen, ist die Rolle eines Process Owners im End-to-End-Prozessmanagement eine sehr stark koordinative. Im Idealfall führt er ein Profit Center und kann – wie beschrieben – über die Frage der eigenen Durchführung oder des internen oder externen Zukaufs von Teilleistungen (make or buy) selbst und frei entscheiden. In vielen Fällen in der Praxis wird diese Entscheidung jedoch keine völlig freie sein. Die Rolle des Process Owners erfordert daher neben den formalen Rechten klassische Managementfähigkeiten, allen voran die Fähigkeit, andere zu koordinieren, zu führen und auch Einfluss auszuüben. Andrew Spanyi bringt dies sehr gut auf den Punkt, wenn er meint: „Process management cannot be effectively deployed in the absence of leadership talent and management discipline“.239 Zur Ausgestaltung dieser Verantwortung umfasst die Rollendefinition typischerweise folgende Punkte: Der Prozess Owner . . . ·

· · ·

· · ·

hat die Prozessverantwortung (Letztverantwortung) für die Leistungserbringung gegenüber dem Kunden. Dies umfasst die Koordinationsverantwortung und Ausführungsverantwortung für die Teilprozesse, die von seinen eigenen Mitarbeitern ausgeführt werden sowie die Koordinationsverantwortung für alle Teilprozesse, die von anderen Einheiten im Unternehmen zugeliefert werden. definiert auf Basis der Kunden- und Unternehmensvorgaben die strategischen und operativen Anforderungen an seine End-to-End-Prozesse setzt Ziele für seine End-to-End-Prozesse und überprüft deren Erreichung sowie die Prozessergebnisse seiner End-to-End-Prozesse entscheidet über wichtige Prozessänderungen und beauftragt diese: sofern sie nur Teilprozesse in seiner Durchführungsverantwortung betreffen autonom, falls sie auch Teilprozesse betreffen, die von anderen Einheiten durchgeführt werden, in Abstimmung mit den verantwortlichen Process Ownern für diese Teilprozesse stellt Ressourcen & Mitarbeiter für Teilprozesse in seiner Durchführungsverantwortung zur Verfügung entscheidet auf Basis wirtschaftlicher Überlegungen über die Auslagerung von Teilprozessen an andere Einheiten stellt sicher, dass für seine End-to-End-Prozesse eine aktuelle Prozessdokumentation sowie ausreichendes Prozesswissen vorhanden ist Verantwortung für den Prozess trägt und auch gegenüber der Unternehmensleitung Rechenschaft darüber ablegen muss“. 239 Spanyi (2007), S. 177. Ebenso S. 68–69. Vgl. auch Hammer (1997): Auch er beschreibt, dass der Prozessverantwortliche am Beginn seine Ziele nicht durch Weisungsbefugnisse, sondern durch Geltendmachen seines Einflusses erreicht. Anders als hier dargestellt, stellt dies für Hammer jedoch nur die initiale Phase dar, im Zuge der Institutionalisierung der Rollen sieht er den hier verworfenen 90-Grad-Shift der Organisationsstruktur von Koordinatoren hin zu Entscheidungsträgern mit Linienverantwortung (S. 119).

147


·

· · · · ·

arbeitet gezielt an der Verankerung & weiteren Entwicklung des Prozessmanagements im Unternehmen durch aktive Verbreitung des Prozessdenkens in seinem Wirkungsbereich nominiert für die Durchführung der operativen Arbeiten zur Erfüllung dieser Pflichten einen Prozessmanager für seine Prozesse setzt seinem Prozessmanager prozessbezogene Ziele und evaluiert deren Erreichung hält aktiven und regelmäßigen Kontakt zu seinem Prozessmanager stellt bei Wechseln die Know-how-Übergabe zum neuen Prozessmanager sicher fungiert als Eskalationsstelle für seinen Prozessmanager

Process Owner sind eine der wichtigsten notwendigen Voraussetzungen für ein funktionierendes Prozessmanagement.240 Was die Nominierung dieser wichtigen Position betrifft, so sind dies sinnvollerweise Manager auf der Ebene unmittelbar unter dem Vorstand oder der Geschäftsführung (also Vorstand –1 bzw. Geschäftsführung –1). In der Praxis ist die Nominierung von Process Ownern auf zu niedrigen Hierarchieebenen einer der wesentlichsten Fallstricke mit enormen Auswirkungen auf alle weiteren Aktivitäten im Prozessmanagement.241 Die Nominierung selbst erfolgt durch den Gesamtvorstand oder die Gesamtgeschäftsführung.242 3.2.2 Prozessmanager

Da es auf dieser Ebene nicht möglich sein wird, dass der Process Owner alle prozessbezogenen Aktivitäten wie zum Beispiel die Aufnahme von Ist-Prozessen, die Durchführung von Prozessoptimierungen oder die Abstimmung von Prozessdetails mit anderen Bereichen selbst erledigt, empfiehlt es sich für ihn, zur operativen Durchführung dieser Dinge einen Prozessmanager243 zu nominieren. Dieser Prozessmanager berichtet di240 Vgl. dazu z. B. auch EABPM (2009), S. 20. 241 Vgl. dazu auch Spanyi (2007), S. 100. Ebenso Schmelzer, Sesselmann (2010), S. 166. Vgl. auch Rummler, Ramias, Rummler (2010), S. 14 – anders als die Autoren, die Process Owner nur für die großen Kernprozesse als notwendig sehen, wird hier der Ansatz vertreten, für alle definierten Prozesse Process Owner zu nominieren, da es in der Praxis gerade auch mit Bereitstellungsprozessen oft Probleme gibt. 242 Hiller, Minar-Hödl, Zahradnik (2010) schlagen demgegenüber z. B. eine Nominierung durch den Prozesssteuerkreis (entspricht in etwa dem hier konzipierten Process Board) vor. Angesicht der hier vorgestellten Konzeption, bei der die Verantwortung für echte End-to-End-Prozesse mit sehr hochrangig besetzten Process Ownern erfolgt und diese im Process Board vertreten sind, wäre dies nicht sinnvoll. 243 Manche Autoren verwenden hierfür auch den Begriff „Prozessverantwortlicher“, z. B. Hiller, MinarHödl, Zahradnik (2010). Dem wird hier bewusst nicht gefolgt, da die Verantwortung für einen Prozess beim Process Owner liegt und dies durch die Bezeichnung nicht verwischt werden sollte. Eine erste Idee eines solchen Prozessmanagers findet sich bereits bei Frederick Winslow Taylor, der für

148


Abb. 39: Ausdifferenzierung der Prozessverantwortungsrollen

rekt an den Process Owner und ist in dieser Funktion als eine Stabsstelle in dessen Bereich eingerichtet. Er nimmt damit für den Process Owner die Ausführung der mit der Prozessverantwortung verbundenen operativen Arbeiten wahr. Er . . . · ·

· ·

· ·

setzt gemeinsam mit anderen an den Prozessen Beteiligten die vom Process Owner gesetzten Ziele um kennt seine Prozesse bzw. hat Kontakt zu Experten zu den einzelnen Teilprozessen oder Prozessschritten in seinem Bereich und kennt die Prozessschnittstellen seiner Prozesse arbeitet gezielt an der Transparenz, Qualität & laufenden Optimierung der Prozesse und der Prozessschnittstellen hält das Prozessmodell für seine Prozesse unter Einhaltung der gemeinsamen Methoden & Konventionen aktuell (Prozessdokumentation, Dokumente im Prozesszusammenhang), damit eine saubere Basis für die Prozessarbeit vorhanden und Prozesswissen auch unabhängig von einzelnen Beteiligten dokumentiert ist stellt die Einhaltung vereinbarter Prozesse und der Prozessergebnisse für seine Prozesse und Teilprozesse sowie die Behandlung von Prozessabweichungen sicher identifiziert Potenziale in den Prozessen und treibt die laufende Optimierung voran die Umsetzung neuer, optimierter Bewegungs- und Tätigkeitsabfolgen mehrere spezialisierte Trainer sieht, darunter auch einen „route clerk“, der für die Abfolge der einzelnen Schritte und die Weiterleitung der Arbeit zwischen den einzelnen Stationen zuständig ist (Taylor 1911, S. 96).

149


·

· ·

·

stimmt übergreifende Prozessänderungen bzw. Prozessänderungen mit Änderung des Prozessergebnisses für andere mit den betroffenen Prozessmanagern und dem zentralen Prozessmanagement ab klärt Prozessschnittstellen mit anderen Prozessmanagern und legt Mindeststandards für den Leistungsaustausch an diesen Prozessschnittstellen fest arbeitet gezielt an der Verankerung & weiteren Entwicklung des Prozessmanagements in der Gruppe, insbesondere durch Verbreitung des Prozessdenkens und des Prozessmanagementansatzes in seinem Bereich arbeitet aktiv mit anderen Prozessmanagern im Prozessnetzwerk zu Lösung übergreifender und gemeinsamer Fragen der Prozesse und des Prozessmanagements zusammen

Die Differenzierung der beiden Rollen des Process Owners und des Prozessmanagers ist somit eine operative Notwendigkeit, die sich aus dem Spagat zwischen notwendiger Entscheidungsautorität und erforderlicher zeitlicher Verfügbarkeit ergibt. Bei ganz kleinen Bereichen oder Firmen kann es auch einmal sein, dass beide Rollen zusammenfallen. In der Mehrzahl der Unternehmen ist diese Unterscheidung jedoch notwendig und sinnvoll. Wichtig ist jedoch, dass die Rolle des Prozessmanagers entsprechend der gedanklichen Trennung von Prozessausführung und Prozessdesign eine gestalterische ist, keine operative. Das heißt, der Prozessmanager ist für das Design und die Optimierung des Prozesses zuständig, nicht jedoch für das operative Durchführen oder Managen aller Prozessinstanzen die den Prozess durchlaufen. 3.2.3 Zentrales Prozessmanagementteam

Zur Koordination der Aktivitäten der Process Owner und Prozessmanager empfiehlt sich die Einrichtung einer dritten Rolle: des zentralen Prozessmanagementteams geführt durch den Chief Process Officer.244 Denn zum einen gibt es auch prozessübergreifende Vorfälle und Verbesserungsinitiativen zum anderen sollen alle prozessbezogenen Aktivitäten in einer Form erfolgen, die konsistent ist und einen gegenseitigen Austausch ermöglicht. So können etwa bestimmte Teilprozesse nicht nur ein einem Geschäftsprozess vorkommen, sondern in mehreren. Denken wir etwa an die Prüfung von Eingangsrechnungen. Sie passiert im Prozess „Generelle Materialien & Services bereitstellen“, ebenso in den Beschaffungsteilprozessen von „IT-Systeme bereitstellen“ und eventuell auch in verschiedenen Leistungserstellungsprozessen, in denen bestimmte Materialien oder Services kundenauftragsbezogen eingekauft werden. Eine Änderung in der 244 Die EABPM spricht in diesem Zusammenhang von einem BPM Office oder auch BPM Center of Excellence (siehe EABPM 2009, S. 208).

150


Eingangsrechnungsprüfung, etwa in Form der Umstellung auf ein Gutschriftenverfahren betrifft daher alle diese Prozesse. Genau für solche Fälle ist es sinnvoll, eine zentrale Stelle zu haben, die alle Beteiligten und Betroffenen informiert, gleichberechtigt einbezieht und koordiniert. Ebenso kann es sein, dass es zu Problemen in der täglichen Prozessabwicklung kommt, die prozessübergreifend sind. Etwa, weil Geschäftsprozesse über gemeinsam genutzte Ressourcen verfügen, bei denen es zu Engpässen kommt. Auch hier ist eine zentrale Koordinationsstelle sinnvoll, die solche Vorfälle aufgreift und gemeinsam mit allen Betroffenen analysiert und löst. Das zentrale Prozessmanagement nimmt hier die Rolle eines neutralen Moderators wahr, der zwischen den Prozessmanagern vermittelt und im Sinne des Gesamtoptimums einen Ausgleich herbeiführt. Neben diesen prozessübergreifenden Koordinationsaufgaben ist das zentrale Prozessmanagementteam aber auch notwendig, um das methodische Know-how für das Arbeiten mit Prozessen vorzuhalten und die methodische Konsistenz sicherzustellen. Denn die Prozessperspektive ist nach wie vor für viele Mitarbeiter etwas Ungewöhnliches und Neues. Sie sind gewohnt in Organigrammen und in Funktionen zu denken, ein echtes End-to-End-Prozessverständnis ist vielfach noch nicht ausreichend vorhanden und verankert. Insofern ist es die Aufgabe des zentralen Prozessmanagementteams dieses Prozessverständnis beizusteuern und in die Organisation zu tragen. Ebenso sind die Methoden des Prozessmanagements vielfach noch nicht oder nur unzureichend bekannt. Auch hier ist es die Aufgabe des zentralen Prozessmanagementteams, dieses methodische Wissen vorzuhalten und in den verschiedenen Prozessaktivitäten und Prozessoptimierungen einzubringen. Hierzu gehören etwa Fragen wie: · · · · · ·

Wie wird ein Prozess korrekt identifiziert und abgegrenzt? Wie können Prozesse sinnvoll und konsistent dargestellt und modelliert werden? Wann ist eine Modellierung im Detail sinnvoll, wann nicht? Wie kann man einen Prozess mit Prozesskennzahlen sinnvoll steuern? Wie werden diese definiert und gemessen? etc.

Zu all diesen Fragen ist es die Aufgabe des zentralen Prozessmanagementteams Wissen aufzubauen, Erfahrungen zu sammeln und diese dann den Prozesseignern und Prozessmanagern für ihre prozessbezogenen Aktivitäten zur Verfügung zu stellen. Hierbei ist es auch wichtig, dass innerhalb eines Unternehmens oder einer Organisation einheitliche Methoden etabliert sind und dass diese konsistent angewendet werden. Denken wir uns nur ein Beispiel, in dem ein Bereich seine Teilprozesse mit Flowcharts dokumentiert und eine Top-down-Prozesskostenanalyse durchführt, ein anderer Bereich verwendet hierfür die Wertstromanalyse und setzt für die Optimierung auf Instrumente des Lean-Ansatzes und ein dritter Bereich schwört auf entsprechende IT-Nähe der Prozessdesigns und verwendet hierfür die EPK-Methode, hinter151


legt mit bottom-up errechneten Prozesskosten. Alle diese Ansätze und Methoden haben für sich ihre Vorteile und Berechtigung. Parallel im selben Unternehmen angewendet ergeben sie jedoch ein methodisches Sammelsurium, bei dem die einzelnen Prozessmodelle, die Vorgehensweisen und die Ergebnisse nicht zusammenpassen. Man kann eine Methode dabei mit einer Sprache vergleichen, die es allen Beteiligten ermöglicht, mit Prozessen so zu arbeiten, dass man einander versteht und die Prozesse und Prozessschnittstellen übergreifend koordinieren kann. Würden nun wie oben beschrieben verschiedenste Methoden zum Einsatz kommen, so wäre dies vergleichbar einer Situation, in der jeder Bereich in einer anderen Sprache spräche. Die Verwirrung wäre vorprogrammiert und die Folgen drastisch, ein gegenseitiges Verstehen unmöglich. Oder denken wir uns ein Unternehmen, in dem jeder Bereich seine Kosten nach anderen Kostenarten und Konten gliedern und seine Deckungsbeiträge nach anderen Formeln berechnen würde. Berichte wären in keinster Weise vergleichbar und eine abgestimmte Steuerung unmöglich. Kein Mensch würde auf die Idee kommen, dies in einem gut geführten Unternehmen zuzulassen. Genau das ist jedoch im Prozessmanagement in vielen Unternehmen und größeren Konzernen nach wie vor der Fall. Obwohl es anhand der Vergleiche sehr deutlich wird, dass ein uneinheitliches und unkoordiniertes Vorgehen massive Verwirrung stiften kann und der übergreifende Nutzen des Prozessmanagements dabei weitgehend verloren geht, gibt es doch immer noch zahlreiche Unternehmen, die im Prozessmanagement keine verbindlichen gemeinsamen Methoden definiert haben oder aber diese nicht mit genügend Nachdruck durchsetzen. Gerade bei einer End-to-End-Perspektive auf die Geschäftsprozesse ist eine einheitliche Methodik absolut essenziell. Waren bei der bisher meist vorherrschenden Teilprozesssicht unterschiedliche Methoden innerhalb eines Unternehmens vielleicht noch tolerierbar, so ist dies bei einer End-to-End-Sicht ein schwerwiegendes Hindernis. Die Umsetzung solcher einheitlichen Methodenstandards ist eine klare Führungsaufgabe des Topmanagements und sollte konsequent verfolgt werden. Die Aufgaben des zentralen Prozessmanagementteams umfassen daher: · · · · ·

Die übergeordnete Koordination der Ziele, Projekte und Initiativen in den Endto-End-Prozessen Die Entwicklung der übergreifenden Prozessmanagementstrategie und der Jahresplanung für die Prozessaktivitäten gemeinsam mit den Prozessmanagern die Koordination zur Lösung von prozessübergreifenden Problemen und Änderungen die Unterstützung der Prozesseigner und Prozessmanager durch Vorhalten von entsprechendem methodischen Know-how im Prozessmanagement das Sammeln und Transferieren der Erfahrungen im Prozessmanagement innerhalb des Prozessnetzwerks sowie mit anderen Unternehmen

152


·

das Erarbeiten von gemeinsamen Prozessmanagementstandards gemeinsam mit den Prozessmanagern und das Sicherstellen der konsequenten Einhaltung dieser Standards zur Erhaltung der Vergleichbarkeit, Konsistenz und damit übergreifenden Nutzbarkeit aller Ergebnisse

Um dies zu erreichen, hat das zentrale Prozessmanagementteam meist auch weitere spezifische Zuständigkeiten und Verantwortlichkeiten, z. B.: · · ·

·

für die Erstellung und Weiterentwicklung des Prozessmodells gemeinsam mit den Prozessmanagern für die Erarbeitung von gemeinsamen Methodenstandards für die Prozessidentifikation, die Prozessbeschreibung und die Prozessoptimierung für die Auswahl und Bereitstellung von passenden Tools für das Arbeiten mit den Prozessen auf Basis der gemeinsam mit den Prozessmanagern definierten Anforderungen für die Organisation von Schulungen zu verschiedenen Prozessthemen

Gerade beim Prozessmodell hat es sich vielfach bewährt, dass das zentrale Prozessmanagementteam die Verantwortung für die oberen, sehr stark integrativen und bereichsübergreifenden Ebenen übernimmt und für diese Ebenen die Aktualisierung sicher stellt. 3.2.4 Strukturelle Verankerung der Rollen in der Organisation

Bezüglich der Verankerung dieser Rollen in der Organisation gibt es verschiedene Möglichkeiten und in der Praxis auch verschiedene Ausprägungen. Idealerweise sind die Prozessmanager in den jeweiligen Geschäftsbereichen angesiedelt. In der Praxis finden sich jedoch auch Konstellationen, in denen dies nicht der Fall ist und die Prozessmanager in einer zentralen Organisations- oder Prozessmanagementeinheit zugeordnet sind. Der Vorteil der ersten Variante ist vor allem eine gute Akzeptanz in den Geschäftsbereichen, aus der Praxis heraus einer der kritischsten Punkte zur erfolgreichen Implementierung von Prozessmanagement; gleichzeitig hat sie jedoch den Nachteil, dass es in dieser Variante schwieriger ist, entsprechendes methodisches Know-how und die Konsistenz im Vorgehen sicherzustellen. Dies ist genau der Vorteil der zweiten Variante, bei der die Prozessmanager Teil des zentralen Prozessmanagementteams sind und nur eine fachliche Zuordnung (dotted line) zu den Prozesseignern in den Geschäftsbereichen haben. Durch die Integration in das zentrale Prozessteam gelingt es meist sehr gut, eine hohe methodische Reife und Konsistenz zu erreichen. Gleichzeitig hat diese Variante jedoch das Risiko einer geringeren Akzeptanz in den Geschäftsbereichen, weil Prozessmanager in so einer Konstellation natürlich nicht als Teil der jeweiligen Bereiche gesehen werden.

153


Als in Summe vorteilhafteste Konstellation hat sich daher die Variante mit dezentralen Prozessmanagern und einer zentralen Koordination durch ein zentrales Prozessmanagement Team erwiesen. Hierbei sind die Prozessmanager in den jeweiligen Geschäftsbereichen angesiedelt und berichten dort direkt an ihre jeweiligen Process Owner.245 Zur Sicherstellung des methodischen Know-hows und der Konsistenz gibt es ergänzend ein zentrales Prozessmanagementteam. Die Prozessmanager sind disziplinarisch den Process Ownern unterstellt und arbeiten für diese. Daneben haben sie aber auch eine beschränkte fachliche Zuordnung (dotted line) zum zentralen Prozessmanagement, dem in Belangen der Methodik und der Konsistenz eine fachliche Richtlinienkompetenz und Weisungsbefugnis zukommt. Durch diese Konstellation ist sichergestellt, dass sich die Prozessmanager auf jene Prozesse konzentrieren, die dem geschäftsverantwortlichen Process Owner wichtig sind. Durch diesen direkten Beitrag und Nutzen für den Geschäftsbereich ist meist auch eine sehr hohe Akzeptanz in diesem gegeben. Die dotted line zum zentralen Prozessmanagement wirkt hier ergänzend als Korrektiv, um die Nachteile dieser dezentralen Anordnung im Sinne einer geringeren methodischen Fundierung oder einer Inkonsistenz durch zu hohe Bereichsindividualität abzufedern und zu minimieren. Auch was die Ansiedlung des zentralen Prozessmanagementteams betrifft, finden sich in der Praxis ganz unterschiedliche Varianten: Teilweise sind solche Teams in der Organisationsabteilung oder Betriebsorganisation angesiedelt, teilweise finden sie sich als Teil der IT- oder CIO-Organisation, in wenigen Fällen sind sie auch mit dem Qualitätsmanagement kombiniert, in Projektmanagementeinheiten integriert oder als komplett eigene und separate Einheiten angelegt, meist im Bereich des Finanzvorstands.246 Auf Basis der Erfahrungen in der Praxis hat jede dieser Varianten ihre Vorteile und lässt sich nicht per se ausschließen. So verhilft etwa eine Ansiedlung in der IT meist zu einer leichteren Umsetzung von Prozessänderungen in den unterstützenden IT-Systemen. Gleichzeitig besteht damit aber auch die Gefahr, dass Prozessmanagement auf die reine fachliche Anforderungsdefinition für IT-Applikationen reduziert wird und andere Aspekte zu kurz kommen. Dies ist vor allem bei einer Einrichtung als eigenständige separate Einheit im Finanzresort deutlich besser gewährleistet; zudem führt die Ansiedlung im Finanzresort zu einem erhöhten Performance- und Kostenfokus, mit dem der Nutzen der Prozessoptimierung und des Prozessmanagements generell stärker betont und transparent gemacht wird. Gleichzeitig erleichtert die Ansiedlung im Finanzresort typischerweise Kostenanalysen in Zusammenarbeit mit dem Controlling. Idealerweise ist das zentrale Prozessmanagement jedoch nicht in der IT angesiedelt, sondern als eigenständige Einheit direkt unter dem CEO organisiert. Sofern es 245 Vgl. dazu auch Mayer in Horváth & Partners (2005), S. 5: „Die Verantwortung für Prozesse muss in der Organisation selbst liegen und dort praktiziert werden.“ 246 Vgl. dazu IDS Scheer, Pierre Audoin Consultants (2007), S. 19.

154


Abb. 40: Alternative organisatorische Verankerungen der Prozessmanager

eine Organisationsabteilung gibt, die den Vorstand bei der Weiterentwicklung der aufbauorganisatorischen Belange unterstützt, ist eine Kombination mit dieser am sinnvollsten, da damit die Integration und Abstimmung des Prozessmanagements mit anderen Organisationsvorhaben und -instrumenten am besten gegeben ist.247 Denn damit ist gewährleistet, dass die aufbauorganisatorische und die ablauforganisatorische Sicht nicht separiert voneinander arbeiten, sondern gemeinsam und ohne Überlappungen behandelt werden. Da die IT-Agenden meist im Finanzresort angesiedelt sind, ergibt sich durch die unterschiedliche Ressortzuständigkeit dadurch zudem auch eine bessere interne Auftraggeber-/Auftragnehmerkonstellation: Das zentrale Prozessmanagement unterstützt die Geschäftsbereiche bei der Weiterentwicklung und Optimierung ihrer Geschäftsprozesse und damit auch bei der Definition der Anforderungen aus diesen Prozessen an die unterstützenden IT-Systeme. Die IT hingegen hat in so einer Konstellation mit den Prozessmanagern klare und durch das zentrale Prozessmanagement auch koordinierte Ansprechpartner in den Bereichen, die die internen Auftraggeber- und Mitwirkungspflichten bei Projekten und Änderungsvorschlägen übernehmen können, wie dies zum Beispiel auch in etablierten ITReferenzmodellen wie Cobit oder ITIL empfohlen ist. Kritisch kann in dieser Anordnung eventuell die Zusammenarbeit mit dem Controlling sein, mit dem gerade im 247 Vgl. Österle (2010/1995, S. 24–25): Für ihn sollte die Organisationsabteilung wieder die führende Rolle bei der Gestaltung der Ablauforganisation übernehmen, die sie vor der Informationsrevolution hatte.

155


Hinblick auf Prozesskosten und Prozesskennzahlen eine enge Abstimmung erforderlich ist. Hier kann jedoch eine enge Einbindung und regelmäßige Abstimmung und Information Abhilfe schaffen. Alternativ zur Ansiedlung des zentralen Prozessmanagements beim CEO finden wir es in der Praxis auch oft im Bereich des Finanzvorstands. Auch diese strukturelle Anordnung ist per se nicht auszuschließen und bringt meist eine leichtere Koordination mit dem Controlling und mit der IT. Die angesprochene klare Auftragnehmer-/ Auftraggeberbeziehung zur IT ist jedoch dann strukturell nicht so ausgeprägt und muss durch den CFO innerhalb seines Verantwortungsbereichs sichergestellt werden. Weiters kann bei so einer Anordnung auch das Risiko entstehen, dass das Prozessmanagement einen zu dominanten Kostenfokus entwickelt, während andere Aspekte, wie etwa die Prozessinnovation, die strategische Ausrichtung der Prozesse oder auch Optimierungen im Hinblick auf Zeit und Qualität an Priorität einbüßen. Unabhängig davon, in welchem Vorstands- oder Geschäftsführungsbereich das zentrale Prozessmanagement nun angesiedelt ist, sollte es in jedem Fall als Stabsstelle direkt an die oberste Führungsebene berichten. Denn zum einen ist die Strukturierung der Leistungserstellung eine klare Führungsaufgabe. Zum anderen erschwert eine Ansiedlung auf unteren Ebenen erfahrungsgemäß die Durchsetzung gemeinsamer Interessen und Standards. Erfolgreiches Prozessmanagement setzt ein Commitment des Topmanagements als entscheidenden Erfolgsfaktor voraus. Dies hält etwa auch die European Association of Business Process Management fest: „Selbst wenn Einzelne umfangreiche BPM-Kompetenzen bekommen und leistungsfähige Werkzeuge eingesetzt werden, wird BPM keinen nachhaltigen Erfolg bringen, wenn das Führungsverhalten, die Werte, die Überzeugungen und die Kultur nicht dazu beitragen“.248 Dieses Commitment muss in einer Ansiedlung des Themas auf entsprechend hoher Ebene sichtbar werden, um glaubwürdig zu sein. In Summe ist festzuhalten, dass der Erfolg solcher zentraler Prozessmanagementteams sicherlich stark von der strukturellen Einordnung in der Aufbaustruktur abhängt. Gleichzeitig ist dies aber nicht der einzige maßgebliche Einflussfaktor. Vielmehr hängt die Effektivität dieses zentralen Teams erfahrungsgemäß auch sehr stark vom Typ der handelnden Personen und deren Sozialkompetenz und integrativen Fähigkeiten über Abteilungsgrenzen hinweg ab. Insofern finden sich in der Praxis auch durchaus erfolgreiche und gut funktionierende zentrale Prozessmanagementteams, die von einer idealen strukturellen Anordnung als eigene Einheit direkt beim CEO abweichen.

248 EABPM (2009), S. 43.

156


3.2.5 Koordinationsmechanismen

Für das Zusammenspiel der definierten Rollen untereinander ist es notwendig, bestimmte Koordinationsmechanismen einzurichten. Hierzu gehören: · · · · ·

geschäftsbereichsinterne Prozess Jour Fixe Meetings Prozessmanagermeetings das prozessübergreifende Process Board der Process Owner ein etablierter Change Management Prozess ein transparentes Issue Management

Process Jour Fixe Meetings Das erste wesentliche Kernelement der Koordinationsmechanismen ist das geschäftsbereichsinterne Prozess Jour Fix Meeting. Es dient der Abstimmung zwischen Process Owner und Prozessmanager. Vorbereitet durch den Prozessmanager gibt der Process Owner hier seinem Prozessmanager die inhaltlichen Zielsetzungen, Schwerpunkte und Vorgaben für die operative Arbeit an den Prozessen, für die er verantwortlich ist. Gleichzeitig informiert der Prozessmanager seinen Process Owner über alle wesentlichen Prozessthemen. Dies kann einerseits Fragen zu rein bereichsinternen Teilprozessen betreffen, andererseits auch alle bereichsübergreifenden Themen inhaltlicher oder prozeduraler Art. Insbesondere dient das bereichsinterne Prozess Jour fixe Meeting auch dem Briefing des Process Owners im Hinblick auf anstehende Entscheidungspunkte für die Koordination zwischen den Process Ownern im Process Board bzw. natürlich auch für rein interne Entscheidungen bzgl. der eigenen Teilprozesse ohne Effekt auf die Schnittstellen zu anderen. Prozessmanager Meeting Das Prozessmanagermeeting ist eine regelmäßige Abstimmung zwischen allen Prozessmanagern in den Geschäftsbereichen. Verantwortlich für dieses Meeting ist das zentrale Prozessmanagement, das einlädt, die Agenda vorbereitet und das Meeting führt. Inhaltlich ist dies das Gremium für die operative Abstimmung aller übergreifenden Prozessthemen, sowohl inhaltlicher als auch methodischer Natur. Das heißt, es werden hier unter anderem folgende Punkte besprochen und bearbeitet: · · · ·

die Erarbeitung eines Vorschlags für die Prozessmanagementstrategie die Erarbeitung eines Vorschlags für das jährliche Arbeitsprogramm mit den Schwerpunkten im Prozessmanagement die Diskussion und Erarbeitung von Lösungsvorschlägen für übergreifende inhaltliche Prozessthemen (Änderungsanträge, Issues) ein bereichsübergreifender Informationsaustausch zu Prozessthemen und -initiativen (z. B. auch über personelle Wechsel in der Rolle der Prozessmanager)

157


· · · ·

die gemeinsame Erarbeitung von Maßnahmen zur Verbreitung des Prozessdenkens und des Prozessbewusstseins im Unternehmen die gemeinsame Erarbeitung von Maßnahmen zum Marketing des Prozessmanagements die gemeinsame Entwicklung von Anforderungen für die standardisierte Methodik, Vorgehensweisen und zur Unterstützung notwendige Tools das gemeinsame Ausarbeiten des Bedarfs an Unterstützung, Trainings und Coachings zu Prozessthemen

Je nach Umfang der Themen und Aktivitäten sind solche Prozessmanagertreffen im Normalfall alle zwei bis drei Monate sinnvoll. Process Board Die Vorschläge, welche die Runde der Prozessmanager erarbeitet, werden dem Process Board zur Entscheidung vorgelegt.249 In diesem Process Board treffen sich regelmäßig alle Process Owner unter der Führung des Sponsors des Prozessmanagements im Topmanagement. Daneben nimmt an diesem Meeting auch der Leiter des zentralen Prozessmanagementteams – in manchen Fällen auch als Chief Process Officer bezeichnet – teil, der das Meeting für den CEO vorbereitet, durch die Agenda führt und die Ergebnisse dokumentiert. Dieses Process Board ist somit das Entscheidungs- und Steuerungsgremium für alle übergreifenden Prozessfragen. Durch die hochrangige Besetzung ist gewährleistet, dass hier entsprechende Entscheidungen auch getroffen werden können. Sollte eine Entscheidung im Gremium aus irgendwelchen Gründen bei einem kontroversen Thema nicht möglich sein, so entscheidet die Stimme des Vorsitzenden des Gremiums oder die Entscheidung wird im Wege der Eskalation der Geschäftsführung oder dem Vorstand vorgelegt. Im Process Board werden somit insbesondere folgende Themen diskutiert und bearbeitet: · · ·

die Entscheidung über die Prozessmanagementstrategie die Entscheidung über das jährliche Arbeitsprogramm mit den Schwerpunkten im Prozessmanagement auf Basis des Vorschlags der Prozessmanager die Entscheidung von wesentlichen Lösungsvorschlägen für übergreifende inhaltliche Prozessthemen (Änderungsanträge, Issues) auf Basis von Vorschlägen des Prozessmanagermeetings 249 Die EABPM spricht in diesem Zusammenhang von einem Prozessrat (EABPM 2009, S. 207); auch Hammer (1997) nennt das Treffen der Prozessverantwortlichen „Prozessrat“ (S. 116); Hess, Osterloh (1995, S. 158) sprechen im Rahmen der Promet-Methode von einem Prozessausschuss, der die Arbeit des Prozessentwurfsteams koordiniert und überwacht sowie Grundsatzentscheidungen trifft. Hiller, Minar-Hödl, Zahradnik (2010) verwenden in Ihrer Konzeption einen Prozesssteuerkreis, der sehr ähnliche Aufgaben wahrnimmt, wie hier besprochen (S. 58–59). Vgl. dazu auch Weilkiens, Weiss, Grass (2010), die für das Etablieren des Prozessmanagements in der Organisation eine formale Steuerungseinheit (formal governing body) als notwendig sehen (S. 64).

158


· · ·

·

ein bereichsübergreifender Informationsaustausch zu wesentlichen Prozessthemen und -initiativen die Unterstützung der Maßnahmen zur Verbreitung des Prozessdenkens und des Prozessbewusstseins im Unternehmen Entscheidungen über die kapazitive und budgetäre Ausstattung im zentralen Prozessmanagement sowie Investitionen in das Prozessmanagement (z. B. Projektbudgets für Optimierungen, Toolanschaffungen, Trainingsinvestitionen, . . .) Entscheidungen über die Durchführung von Prozessassessments und -zertifizierungen

Die Meetings müssen dabei in Normalzeiten ohne größere Prozessänderungen nicht besonders lange dauern. Auch reicht für das Process Board in Normalzeiten ohne größere Dynamik und Projekte meist eine Frequenz von zwei bis vier Monaten durchaus aus. Sie sollten jedoch mit einer Regelmäßigkeit terminiert werden, die sie zu einer gewissen Routine werden lässt. Gelingt dies, so dienen sie der gesamten Prozessarbeit auch als wichtige Meilensteine, zu denen über die Fortschritte und Arbeiten berichtet wird, und entwickeln so einen motivierenden und steuernden Effekt für das gesamte Prozessnetzwerk. In der Praxis stellt sich oft die Frage, ob das Process Board tatsächlich ein eigenes Meeting sein muss, oder ob man es nicht einfach als weiteren Agendapunkt in bereits bestehende Meetingstrukturen integrieren kann, etwa in bereits bestehende Jour fixe Termine, Projektsteuerungsgremien oder Ähnliches. Prinzipiell wäre das sicher möglich. Es ist dabei jedoch zu bedenken, dass Fragen des Prozessmanagements meist keine so große aktuelle Dringlichkeit haben wie akute tagesgeschäftliche Fragen. Insofern besteht bei einer Integration in bereits bestehende Meetings die Gefahr, dass bei intensiven Diskussionen zu solchen akuten tagesgeschäftlichen Fragen dann oft zu wenig Zeit für die Prozessthemen bleibt. Insofern ist eine separate Einrichtung dieses Meetings klar zu bevorzugen.250 Trifft sich dieselbe Runde bereits zu einem Thema, kann das Process Board vor oder mit einem bestimmten Zeitpuffer im Anschluss an dieses bestehende Meeting terminiert werden, um die Terminkoordination zu vereinfachen, aber eben als eigenständiges Meeting mit eigener Agenda. Prozessänderungsprozess Neben den beschriebenen Meetingstrukturen sind auch zwei spezielle Prozesse zu etablieren: ein funktionierender Prozessänderungsprozess (Change Request Process) und ein Issue Management.

250 Der Ansicht von Rummler, Ramais, Rummler (2010), soweit wie möglich bereits bestehende Gremien und Meetingstrukturen zu nutzen (S. 167), kann aus den genannten Gründen nicht zugestimmt werden.

159


Der Change Request Prozess definiert, wie und von wem Änderungen in den Prozessen vorgenommen werden können. Gerade je detaillierter man in die Prozesse eintaucht, desto häufiger wird es notwendig sein, sie an neue Gegebenheiten anzupassen. Betreffen diese Änderungen nur einen Teilprozess, ohne dass die Prozessschnittstellen zu den vorgelagerten und nachgelagerten Prozessen betroffen sind, das heißt, ohne dass sich das Prozessergebnis und die Outputs des Teilprozesses in irgendeiner Weise ändern und ebenso der Auslöser und die benötigten Inputs unverändert bleiben, so kann der Prozess vom für den Teilprozess verantwortlichen Process Owner und seinem Prozess Manager autonom geändert werden. Sobald eine Änderung jedoch Auswirkungen auf das Prozessergebnis oder andere Teilprozesse hat, so ist die Änderung mit den Process Ownern bzw. den Prozessmanagern dieser Teilprozesse abzustimmen. Damit ist gewährleistet, dass Prozessänderungen nur koordiniert vorgenommen werden und nicht negative Nebenwirkungen auf andere Teilprozesse und somit den gesamten End-to-End-Geschäftsprozess entfalten. Damit diese Abstimmung gewährleistet ist, muss zum einen der Änderungsprozess klar definiert sein; zum anderen müssen die einzelnen Änderungen transparent nachvollziehbar behandelt werden. Dies ist notwendig, um zu wissen, ab wann eine Änderung in Kraft tritt und gilt. Zudem ist es aber auch essenziell, um in der Zusammenarbeit zwischen den Beteiligten des Prozessnetzwerks Vertrauen zu schaffen und aufzubauen. Die erste und wahrscheinlich größte Herausforderung in diesem Änderungsmanagementprozess liegt darin, Bestrebungen zum Ändern von Prozessen frühzeitig und flächendeckend zu erkennen. Denn vielfach werden Teilprozesse einfach abgeändert, ohne dass dies entsprechend transparent gemacht und mit anderen abgestimmt wird. Derartige Änderungen werden erst dann bekannt, wenn sie zu negativen Auswirkungen bei anderen am End-to-End-Prozess Beteiligten führen. Um dies zu verhindern, ist es essenziell, im Zuge der Einführung von Prozessmanagement und da-

Abb. 41: Prozess für Prozessänderungen

160


rüber hinaus ein Bewusstsein in der gesamten Organisation zu schaffen, dass Änderungen an den Prozessen etwas sind, was über das Prozessnetzwerk besprochen und abgestimmt werden muss. Dieses Bewusstsein ist der wesentliche Baustein für ein funktionierendes Änderungsmanagement für die Prozesse. Es ist etwas, was in der Unternehmenskultur etabliert und verankert werden muss. Ergänzend zu diesem Bewusstsein sind an den wesentlichen Stellen, bei denen Prozessänderungen auftauchen können, entsprechende Checkpunkte einzurichten. So kommen zum Beispiel Prozessänderungen in der Praxis häufig über Projekte (reine Fachprojekte ebenso wie IT-Projekte), über Strategieänderungen, über die Einführung neuer Produkte oder Leistungen oder bei kleineren Änderungen vielfach auch über den IT-Helpdesk, wo einzelne am Prozess Mitarbeitende Wünsche zu Prozessverbesserungen und Anpassungen an den unterstützenden Systemen deponieren. Über die Einbindung der Process Owner und der Prozessmanager an diesen Stellen sowie die Definition von Anzeichen für Prozessänderungen und die diesbezügliche Schulung von Beteiligten an den genannten Prozessen kann hier eine entsprechende Filterung und Kanalisierung erreicht werden. Konkrete Maßnahmen hierfür sind etwa: ·

· ·

·

·

·

die Einbindung der Prozessmanager in die Strategieentwicklung des jeweiligen Bereichs oder zumindest die Information der Prozessmanager über die festgelegte Strategie die Einbindung des zentralen Prozessmanagementteams in den Strategieprozess des Unternehmens (z. B. durch Einladung zur Teilnahme an einer Strategiekonferenz) die frühzeitige Information der Prozessmanager und des zentralen Prozessmanagementteams über alle neuen Projektinitiativen im Zuge des Projektgenehmigungsprozesses die frühzeitige Information der zuständigen Prozessmanager und des zentralen Prozessmanagementteams über Vorhaben zur Einführung neuer Produkte oder Leistungen die frühzeitige Information der zuständigen Prozessmanager und des zentralen Prozessmanagements über neue Partnerschaften und neue, größere Verträge mit Partnern auf Lieferanten und Kundenseite die Festlegung von klaren Kriterien für Change Requests in den IT-Systemen und die Integration der Prozessmanager in den Ticketprozess in dem Sinn, dass alle Tickets, die vom Typ her keine Fehlerbehebung oder Bedienungsfragen, sondern Änderungen oder Erweiterungen sind, an den zuständigen Prozessmanager gehen und erst nach dessen Freigabe umgesetzt werden.

Ziel dieser Festlegungen ist es, dass alle Initiativen und Ideen für Prozessänderungen den betreffenden Prozessmanagern und dem zentralen Prozessmanagement bekannt werden. Denn nur dann kann eine bewusste Analyse und koordinierte Entscheidung über derartige Änderungen an den Prozessen erfolgen. Da so eine Menge an solchen 161


Ideen und Initiativen für Änderungen in den Prozessen zusammenkommen, werden diese im ersten Schritt nach Relevanz und Wichtigkeit gefiltert und priorisiert. In der Analyse der Prozessänderungen ist es wichtig, das richtige Ausmaß an administrativem Aufwand zu finden. In vielen Unternehmen, in denen es derartige Änderungsprozesse schon gibt (vielfach allerdings beschränkt auf IT-Änderungen) sind die Anforderungen zur Beschreibung einer beantragten Änderung sehr umfangreich und umfassen auch oft Informationen, die der Initiator gar nicht weiß oder wissen kann. Wesentliche Inputs für eine fundierte Entscheidung über eine Prozessänderung sind: · · · · · ·

· · ·

ein aussagekräftiger Titel für die Änderung eine kurze, fachliche Beschreibung in zwei, drei Sätzen, worum es dabei geht eine kurze fachliche Begründung, warum die Änderung notwendig oder sinnvoll ist bei Änderungen, die aufgrund bestimmter Normen notwendig sind (z. B. gesetzliche Änderung, EU-Normen, . . .) die genaue Angabe der referenzierten Norm bei Änderungen, die strategisch bedingt sind, die Referenz zum betreffenden strategischen Ziel in der Unternehmensstrategie bei Änderungen, die nicht normativ begründet sind, eine kurze Wirtschaftlichkeitsrechnung (business case), was die Änderung bringt und/oder eine qualitative Beschreibung des Nutzens den geschätzten Aufwand und eventuelle externe Kosten für die Umsetzung den Namen und die Abteilung der Person, welche die Änderung beantragt sowie eine laufende Nummer (ID) zum einfacheren Referenzieren

Diese Angaben füllen kaum eine A4-Seite und genügen bei entsprechender inhaltlicher Qualität völlig, damit sich der oder die betroffenen Prozessmanager ein ausreichendes Bild über die beabsichtigte Änderung machen können. Sind diese Informationen vollständig vorhanden, so wird die Initiative zu einem offiziellen Änderungsantrag, der von den Prozessmanagern behandelt werden muss. Unvollständige Anträge werden hingegen zur Vervollständigung an den Beantragenden zurück gegeben mit der Bitte um Ergänzung. Die Prozessmanager analysieren in der Folge den Vorschlag und ergänzen dabei auch weitere für die Entscheidung wichtige Informationen, z. B.: · · · · · · ·

den betroffenen End-to-End-Prozess/die betroffenen End-to-End-Prozesse eventuelle Auswirkungen auf voroder nachgelagerte Teilprozesse mögliche Prozessrisiken aus der vorgeschlagenen Änderung den Typ der Änderung: teilprozessintern oder übergreifend den oder die zuständigen Prozessmanager den oder die zuständigen Process Owner den Status des Änderungsantrags (Idee, eingebracht, entscheidungsreif, abgelehnt, genehmigt, umgesetzt, geschlossen, verworfen)

162


Bei der Prüfung wird insbesondere die Begründung inklusive der darin enthaltenen Referenzen auf Normen oder Strategie bzw. die Kostenschätzung und die Wirtschaftlichkeitsbetrachtung auf Nachvollziehbarkeit, Plausibilität und spätere Überprüfbarkeit geprüft. Mit diesen Prüfungen und Ergänzungen kann die Änderung dann fundiert und begründet entschieden werden. Je nach Wichtigkeit, Auswirkung und Umfang der Änderung erfolgt diese Entscheidung entweder im Process Board, im Prozessmanager Meeting oder aber – bei rein teilprozessinternen Prozessänderungen ohne jedwede Auswirkungen auf voroder nachgelagerte Teilprozesse – durch den betreffenden Process Owner. In Verbindung mit dieser Entscheidung muss auch die Verantwortung für die Umsetzung und das dafür gegebenenfalls notwendige Budget definiert werden. Erst mit dieser Ergänzung erlangt die Entscheidung ihre Gültigkeit. Im dritten Schritt des Änderungsprozesses wird die beschlossene Prozessänderung umgesetzt. Hierzu zählen alle notwendigen Schritte zur Umsetzung, wie etwa die Änderung von Zuständigkeiten, die Zuweisung von Personalkapazitäten und anderen notwendigen Ressourcen, die Anpassung von unterstützenden IT-Systemen und – ganz essenziell – das Enabling aller von der Prozessänderung Betroffenen, damit sie den Prozess in seiner geänderten Form auch entsprechend durchführen können. Bei größeren Änderungen sind dafür gegebenenfalls eigene Trainings notwendig. Bei kleineren Änderungen kann die Einweisung in den neuen Ablauf auch über entsprechende Informationen und die Kommunikation in regelmäßigen Teammeetings der Betroffenen erfolgen. Zur Komplettierung des Änderungsprozesses fehlt schließlich noch der vierte und letzte Schritt: die Dokumentation und Kommunikation der Prozessänderung. Hierfür ist es notwendig, bestehende Prozessmodelle und auch ergänzende Prozessdokumente entsprechend anzupassen, damit sie wieder dem aktuellen Stand entsprechen. Dort wo dies notwendig ist, erfolgt dies im Zuge einer entsprechenden Versionierung und Archivierung der alten Version. Damit sind Prozessmodell und Prozessdokumentation wieder auf den aktuellen Stand für die weitere Arbeit mit den Prozessen. Ebenso wird die Änderung abschließend auch transparent kommuniziert, sodass auch jene, die am Prozess nicht direkt beteiligt sind, über die Änderung Bescheid wissen. Der oben im Überblick dargestellte Prozessänderungsprozess ist anhand der geschilderten Aspekte unternehmensspezifisch zu detaillieren und zu kommunizieren. Zur Unterstützung des Prozesses in der operativen Durchführung eignen sich insbesondere einfache multiuserfähige Listen in webbasierten Kollaborationsplattformen (z. B. Sharepoint, Documentum, . . .). Neben der Auflistung aller Änderungen mit entsprechenden Detailinformationen, wie sie oben beschrieben wurden, kann damit auch die Änderung wichtiger Statusfelder mit Benutzer und Datumsstempel festgehalten werden. Hierdurch ist gewährleistet, dass einerseits nur Berechtigte entsprechende Einträge ändern, andererseits sind die Informationen für alle abrufbar und nachvoll163


ziehbar. Änderungen und der Entscheidungsprozess über sie sind damit für alle transparent. Ebenso ist mit einer solchen Toolunterstützung eine einfache Sortierung, Gliederung und Auswertung der Änderungen nach verschiedenen Dimensionen möglich. Gleichzeitig sind derartige Tools sehr einfach zu bedienen und erfordern keine große Einschulung. Process Issue Management Als zweiter davon getrennter Prozess empfiehlt sich ein Prozess Issue Management. Dieses enthält alle offenen übergreifenden Fragen, zu denen ein Prozessmanager einen Input oder eine Entscheidung von einem anderen Prozessmanager benötigt (issues). Die Issues werden dabei in Kurzform mit einem Titel, einer kurzen Beschreibung in ein bis zwei Sätzen, dem zugeteilten Prozessmanager, von dem der Input erbeten wird, sowie einem Fristtermin festgehalten. Neben anderen Prozessmanagern können derartige Issues natürlich auch an das zentrale Prozessmanagementteam gerichtet sein oder von diesem aufgebracht werden. Die Liste der Issues ist ein Standardagendapunkt in den Prozessmanagermeetings. Natürlich wäre es auch möglich, diese Fragen rein informell und ohne Dokumentation zu klären. Durch das einfache Festhalten in einer Issue Liste ist jedoch wiederum eine Transparenz und Nachvollziehbarkeit gegeben, welche die Abarbeitung professionalisiert und verhindert, dass manche Punkte verloren gehen oder vielleicht auch verschleppt werden. Gerade in der oft heiklen bereichsübergreifenden Zusammenarbeit bei End-to-End-Prozessen hat sich dieses Instrument als sehr hilfreich erwiesen, zumal es mit minimalem Aufwand realisiert werden kann. Es kann durch die geschaffene Transparenz als vertrauensbildende Maßnahme in der bereichsübergreifenden Zusammenarbeit in den Prozessen gesehen werden. Entscheidend ist hier einfach die Konsequenz in der Nutzung. Diese kann insbesondere durch das zentrale Prozessmanagementteam gewährleistet werden, in dem dieses die Patenschaft über das Issue Management übernimmt, es regelmäßig in den Prozessmanagermeetings als fixen Agendapunkt mit den Prozessmanagern durchgeht und auch regelmäßige Berichte über überfällige oder schon lange offene Issues in der Liste erstellt und verteilt. Mit diesen definierten Rollen und Koordinationsmechanismen steht im Unternehmen ein schlagkräftiges Organisationselement der Sekundärorganisation zur Verfügung, das in verschiedensten aufbauorganisatorischen Strukturen einen essenziellen Beitrag zur reibungsloseren Leistungserstellung leisten kann. Ergänzend zur Nutzung funktionaler Spezialisierungsvorteile kann Prozessmanagement so die Integration im Unternehmen für die Leistungserstellung für den Kunden unterstützen. Darüber hinaus bietet das Prozessmanagement über die beschriebenen Verantwortlichkeiten und Koordinationsstrukturen auch eine institutionalisierte Möglichkeit für die Weiterentwicklung und Veränderung der Prozesse, um so auf Veränderungen in den Kun-

164


denbedürfnissen und in den Märkten zu reagieren.251 In Anlehnung an die Begrifflichkeiten in der IT könnte man die Gesamtheit der beschriebenen Rollen, Abstimmungsstrukturen und Prozessmanagementprozesse auch als Prozess Governance bezeichnen.252 Wie im nächsten Abschnitt gezeigt wird, liegt der Beitrag des Prozessmanagements dabei insbesondere in der Integrationsfunktion für die Organisationsstruktur des Unternehmens.

251 Vgl. dazu Hammer (1997, S. 270 ff.): Hammer sieht gerade in dieser institutionalisierten Fähigkeit zur Veränderung einen Schlüsselerfolgsfaktor für Unternehmen in der heutigen Zeit. Das hier beschriebene Verständnis von Prozessmanagement als Sekundärorganisation deckt sich daher in Bezug auf die Prozesse mit Hammers Konzept des Tiefensystems (Hammer selbst geht hier jedoch noch deutlich weiter bis zum zugrunde liegenden Wertesystem der Unternehmen). 252 Durch die Art, wie die Prozessverantwortung im vorgestellten Konzept verankert wrid, ist eine direkte Integration in das Business sicher gestellt. Auch wenn hier der Begriff der Process Governance verwendet wird, so deckt sich dies nicht mit isolierten und separaten Governancestrukturen, wie sie häufig im Zuge von integrierten Managementsystemen aufgebaut werden. Vgl. dazu auch die Kritik von Rummler, Remias, Rummler (2010) an einer solchen isolierten Process Governance, die damit auf den hier entwickelten Ansatz nicht zutrifft (S. 115).

165

4 Prozessmanagement als Integrationsinstrument Wird Prozessmanagement als Organisationselement so etabliert und gelebt wie im letzten Abschnitt beschrieben, so kann es einen signifikanten Beitrag zur Integration innerhalb des Unternehmens leisten. Innerhalb der verschiedenen Elemente der Organisationsstruktur kann Prozessmanagement hier vor allem die Integrationsfunktion erfüllen, die von der grundsätzlichen Gliederung und von anderen Elementen der Organisationsstruktur nicht oder nur unzureichend gewährleistet werden kann.253 Die Integration kann dabei über verschiedene Dimensionen gefördert werden: · · · · · · ·

über die Teilprozesse zur Leistungserstellung über verschiedene Organisationseinheiten hinweg über unterstützende IT-Systeme hinweg zwischen verschiedenen erbrachten Leistungen über Standorte hinweg über die verschiedenen Stufen der Wertschöpfung im Unternehmen über die Unternehmensgrenzen hinaus zu Lieferanten und Kunden

Diese Integrationsfunktion gewinnt insbesondere bei größeren Reorganisationen oder auch bei der Integration von zugekauften Firmen an Bedeutung und kann hierbei entscheidende Beiträge zur Reduktion von Reibungsverlusten sowie zur Realisierung des angestrebten Nutzens und der erwarteten Synergien leisten. Als Mittel, um diese Integration transparent zu machen, weiter zu entwickeln und Änderungen auf ihre integrativen Auswirkungen zu prüfen, dient dem Prozessmanagement dabei das Prozessmodell, und darin wiederum insbesondere die integrative Process Map (Prozesslandkarte).

4.1 Integration über die Teilprozesse zur Leistungserstellung Über das entwickelte End-to-End-Verständnis von Geschäftsprozessen sowie deren Untergliederung in klar abgrenzbare Teilprozesse schafft das Prozessmanagement eine Integration über die Teilprozesse der Leistungserstellung im Hinblick auf die Gesamtleistung für den Kunden. Der End-to-End-Prozessansatz adressiert damit konse253 Vgl. Wagner, Patzak (2007, S. 49 ff.): Sie stellen die Prozessorientierung anhand eines Lebensphasenmodells von Unternehmen dar und benennen dabei die dritte Phase, in der der Prozessorientierung sichtlich eine große Rolle zukommt, als „Integrationsphase“.


167

Prozessmanagement als Integrationsinstrument

quent das Problem der sequentiellen Interdependenz über die gesamte Leistungserstellung.254 Denn Ausgangspunkt ist der Bedarf für den Kunden. Anknüpfend an diesen dient der End-to-End-Prozess der Erstellung der benötigten Leistung zur Deckung des vorausgehenden Bedarfs. Dafür wird der End-to-End-Prozess wie beschrieben in Teilprozesse zerlegt. Auch diese werden über klar abgrenzbare Teilleistungen definiert, die Bedarfe von anderen Teilprozessen für die Erstellung der Leistung adressieren: Für jeden wird genau definiert, welchen Bedarf er in der gesamten Leistungserstellung deckt und welche Teilleistung er zu seiner Abdeckung beiträgt. Durch diese Definition der Teilprozesse anhand von Bedarf und erbrachter Teilleistung wird auch zwischen den einzelnen Teilprozessen der Leistungsaustausch in den Vordergrund gestellt. Zusätzlich werden die Teilprozesse untereinander im Rahmen des End-to-End-Prozesses auch in eine klare Abfolge gebracht, sodass auch die zeitlich-logische Beziehung zwischen ihnen festgelegt wird. Auf diese Weise werden die einzelnen Teilprozesse, die für die Erstellung der Leistung für den Kunden notwendig sind, untereinander in Beziehung gesetzt und integriert. Es ist genau diese Integration über die Teilprozesse zur gemeinsamen Leistungserstellung im Rahmen des End-to-End-Prozesses, die den Gegenpol zur erfolgten Untergliederung in einzelne handhabbare Teilprozesse bildet. Die Untergliederung unterstützt die Komplexitätsreduktion und schafft handhabbare Teilprozesse mit klaren Verantwortlichkeiten; die End-to-End-Sicht der Prozesse integriert die so geschaffenen Teilprozesse im Hinblick auf die gesamte Leistungserstellung für den Kunden. Probleme in der Integration der Leistungserstellung können damit erkannt und gezielt adressiert werden.255 Eben dadurch unterscheidet sich das End-to-End-Verständnis von Prozessen vom weithin etablierten Teilprozessverständnis: In Letzterem werden nur die Teilprozesse definiert, ohne jedoch deren Zusammenspiel und die Integration zwischen ihnen im Sinne der Erstellung der Gesamtleistung für den Kunden herzustellen. Es finden sich dann in den Prozesslandschaften und Prozessmodellen vielfach Prozesse wie „Auftragsabwicklung“, „Produktion“ und „Fakturierung“ ohne klares Bild über ihr wechselseitiges Zusammenspiel. Daneben werden meist völlig isoliert Supportprozesse wie „Buchhaltungsprozess“, „Materialwirtschaft durchführen“ oder „Be254 Vgl. Schreyögg (2006, S. 122 f.). Er sieht die Behandlung der verschiedenen Arten von Interdependenzen zwischen einzelnen Verrichtungen als eine wesentliche Aufgabe der Prozessanalyse, sofern diese über die Verrichtungsanalyse im Kosiolschen Sinn hinausgehen soll. Das von Schreyögg angeführte Problem der reziproken Interdependenz wird durch die konsequente Abfolge der Teilprozesse in das Problem der sequentiellen Interdependenz überführt und somit ebenfalls adressiert. Hammer, Champy (1994) sehen die Zusammenführung der spezialisierten Aufgaben zu kohärenten Unternehmensprozessen als zentralen Gedanken, der im industriellen Zeitalter hinter der Gründung und Gestaltung von Unternehmen steht (S. 12). 255 Vgl. dazu Rummler, Ramais, Rummler (2010): Sie sprechen in diesem Zusammenhang von „disconnects“ (S. 149).

168

Integration über Organisationseinheiten

schaffen“ abgebildet. Derart definierte Prozesse in einem Prozessmodell sind – falls es sich nicht überhaupt um eine Vermischung mit Unternehmensfunktionen handelt – nur Teilprozesse. Ohne die Integration in die gesamte Leistungserstellung können sie nur für sich alleine optimiert werden. Eine übergreifende Sicht und Optimierung der kompletten Wertkette zur Leistungserstellung ist damit nicht möglich. Diese Integration über die Teilprozesse zur Erstellung der Gesamtleistung für den Kunden kann erst mit einem echten End-to-End-Prozessverständnis erzielt werden.

4.2 Integration über Organisationseinheiten Eng in Zusammenhang mit der Integration der Teilprozesse steht auch der zweite Bereich, in dem Prozessmanagement zur Integration beiträgt: jener der Leistungserstellung über die einzelnen Organisationseinheiten hinweg.256 Denn mit der entwickelten End-to-End-Betrachtung der Prozesse werden die für die Erbringung der Leistungen notwendigen Teilprozesse und Schritte über alle aufbauorganisatorischen Grenzen hinweg verfolgt, solange bis die Leistung für den Kunden komplett ist. Dabei kann es sein, dass manche Teilprozesse nur von einer einzigen Organisationseinheit erbracht werden. Das heißt, dass für diesen Teilprozess keinerlei Organisationsbrüche bestehen. In diesem Fall fallen die Grenzen der Teilprozesse mit dem Übergang der Ausführungsverantwortung zusammen. In vielen Fällen wird es jedoch so sein, dass auch innerhalb der einzelnen Teilprozesse ein Zusammenspiel verschiedener Abteilungen und Stellen stattfindet. In diesen Fällen koordiniert das Prozessmanagement das Zusammenspiel dieser Prozessteilnehmer, indem es die genaue Abfolge, wer was wann im Zuge des Teilprozesses zu erledigen hat, für alle Beteiligten transparent macht und festlegt. Ebenso werden dafür auf detaillierter Ebene notwendige Inputs festgelegt, welche die entsprechenden Stellen für die Ausführung ihrer Prozessschritte benötigen. Die Prozesssicht integriert so die Leistungserstellung auch über die Grenzen der einzelnen Organisationseinheiten und zuständigen Stellen hinweg. Wie im letzten Kapitel gezeigt wurde, muss die Prozessintegration dabei nicht zwingend in einer kompletten Integration der Ausführungsverantwortung für den gesamten End-to-End-Prozess münden. Dort, wo Aufgaben sehr zersplittert organisiert sind und aufgrund der Art der erstellten Leistung an den Schnittstellen viel an Information, Zeit und Aufwand verloren geht, kann eine stärkere Integration der Ausführungszuständigkeit im Sinne der Beseitigung von Organisationsbrüchen und Schnitt256 Vgl. dazu v. a. Rummler, Brache (1995) und Rummler, Ramias, Rummler (2010), die Prozessmanagement ganz wesentlich als Instrument sehen, um den „weißen Zwischenraum“ (white space) in den Organigrammen zu managen. Vgl. auch Becker, Kahn (2008, S. 9): Für sie ist die horizontale Zusammenarbeit aller Beteiligten ein wichtiger Baustein der prozessorientierten Denkweise.

169


stellen durchaus sinnvoll und ein Mittel der Prozessoptimierung sein.257 Dies ist jedoch nicht zwingend so und muss auch nicht für den kompletten End-to-End-Prozess erfolgen. Wie im letzten Kapitel herausgearbeitet wurde, wäre diese Herstellung einer idealen Prozessorganisation sogar in den meisten Fällen kontraproduktiv und unwirtschaftlich. Die Integration kann vielmehr auch über die Abstimmung der Prozessschnittstellen, über die Vereinbarung von klaren Teilleistungen und notwendigen Inputs hierfür erfolgen. Prozessmanagement – und nur das Prozessmanagement – kann dies als Organisationselement erfüllen. Während die Gliederung der Aufbauorganisation hilft, die Komplexität zu reduzieren, die Aufgaben handhabbar und steuerbar zu machen und auch den einzelnen Mitarbeitern eine Heimat im Sinne der Identifikation zu geben, steuert das Prozessmanagement über die spezifische, an den Leistungen für den Kunden ausgerichtete End-to-End-Prozesssicht die erforderliche Integration über die verschiedenen aufbauorganisatorischen Elemente bei. Die Methodik, mit der diese Integration über verschiedene Organisationseinheiten einfach sichtbar gemacht werden kann, sind in erster Linie Swimlane-Modelle für die entsprechenden Prozesse auf den oberen Ebenen des Prozessmodells. Mit dieser einfachen Methodik kann das Prozessmanagement die Integration entlang der Wertschöpfungskette über die aufbauorganisatorischen Grenzen hinweg aufzeigen. Damit werden Prozessschnittstellen im Sinne organisatorischer Übergänge transparent. Dort, wo es zu viele oder unnötige Übergänge gibt, können diese reduziert werden. Dort, wo Übergänge aus wirtschaftlichen oder Compliancegründen notwendig oder sinnvoll sind, können sie aufgezeigt, abgestimmt und vereinbart werden.258 Gleichzeitig wird auch transparent, wenn Teilprozesse in der organisatorischen Durchführung unüblich zugeteilt sind. Beispiele hierfür sind etwa, wenn die Buchhaltung auch Teile der Fakturierung übernimmt, weil sich dies historisch so entwickelt hat; oder aber, wenn IT-Systeme von Fachabteilungen betrieben werden. Gerade das Zusammenspiel zwischen Geschäftseinheiten (business units), Service Einheiten (service functions) und Steuerungseinheiten (corporate functions) kann so sehr schön transparent gemacht und optimiert werden. Die Prozessschnittstellen sind jene Punkte, an denen der Prozessfluss die Swimlane wechselt. Sind hier die Übergaben für die Beteiligten nicht klar oder die entsprechenden Prozesse kritisch, so müssen hier Servicevereinbarungen über die jeweils zu erbringenden Teilleistungen sowie dafür notwendige Inputs getroffen werden. 257 So ist die Zusammenfassung von verschiedenen Aufgaben und Positionen z. B. eines der wesentlichen Mittel zur Prozessoptimierung im Ansatz des Prozess Reeingineering. Siehe Hammer, Champy (1994), S. 77 ff. 258 Weniger optimal ist hier hingegen die Darstellung in der Business Process Management Notation (BPMN) mit Pools. Denn hier werden in jedem Pool eigene Prozesse definiert, die nur über Nachrichtenflüsse gekoppelt sind. Damit entsteht der Eindruck getrennter und autonomer Prozesse, wo für den finalen Kunden als Leistungsempfänger allerdings nur ein Prozess zur Erbringung der Leistung besteht.

170

Integration über Organisationseinheiten

Abb. 42: Integration über Bereiche

Aber auch innerhalb der Bereiche kann das Zusammenspiel der einzelnen Teams, Abteilungen und Stellen mit der integrativen Prozesssicht transparent gemacht werden. Zwar ist in der Praxis meist die Integration auf der Bereichsebene zwischen Geschäftseinheiten, Service Einheiten und Steuerungseinheiten die größere Schwäche für die Effizienz der Leistungserbringung, gerade in größeren oder nicht historisch gewachsenen Bereichen ist aber auch die Integration innerhalb der Bereiche zwischen den einzelnen Abteilungen, Teams und Stellen manchmal noch eine Herausforderung. Diese Unterstützung der Integration über aufbauorganisatorische Zuständigkeiten hinweg kann in beliebigem Detail fortgesetzt werden. Auch auf detaillierteren Prozessebenen können damit organisatorische Übergänge der Ausführungsverantwortung – sogenannte Organisationsübergänge oder Organisationsbrüche259 – transparent gemacht und somit in der Folge entweder über klare Vereinbarungen verbessert und besser gesteuert oder durch Änderungen in der Ausführungsverantwortung überhaupt vermieden werden.

259 Teilweise findet sich in der Literatur hierfür auch der Begriff der Prozessschnittstelle (siehe z. B. Rudolf Wilhelm (2007), S. 67 f.), eine Verwendung, die jedoch irreführend ist. Denn unter Prozessschnittstelle wird üblicherweise der Absprung von einem Prozess zu einem verbundenen Prozess verstanden und nicht der Wechsel in der organisatorischen Zuständigkeit.

171


Abb. 43: Aufzeigen von Organisationsübergängen im Detailablauf

4.3 Integration über IT-Systeme Analog zur Integration über die Organisationseinheiten kann die End-to-End-Prozesssicht auch die Integration über verschiedene IT-Systeme in der Applikationslandschaft unterstützen. Auch hier kann die Integration auf verschiedenen Detaillierungsebenen aufgezeigt werden: Auf aggregierter Sicht erfolgt dies durch das Herausarbeiten der jeweiligen Systemunterstützung für ganze Hauptprozesse. Zur besseren Sichtbarkeit kann diese zum Beispiel wiederum in eine Swimlane-Darstellung nach den unterstützenden Systemen überführt werden. Andere Möglichkeiten

Abb. 44: Integration über IT-Systeme

172

Integration über IT-Systeme

sind etwa eine Darstellung der Applikationslandschaft nach Prozessen oder eine Prozess-System-Matrix. So werden integrative Prozessschnittstellen über die Grenzen der unterstützenden IT-Systeme hinweg transparent gemacht. Gerade in der aktuellen Phase der Entwicklung von IT-Applikationen, in der neben den zentralen ERP-Systemen vielfach spezielle Anwendungssysteme für bestimmte Teilbereiche eingesetzt werden, kommt dieser prozessbasierten, integrativen Sicht auf die IT-Unterstützung der Prozesse große Bedeutung zu. Denn erst damit kann das Zusammenspiel der einzelnen Anwendungen entlang des End-to-End-Prozesses geplant, transparent gemacht und verbessert werden. Die Entwicklung hin zu serviceorientierten Architekturen, durch die Systeme noch stärker modularisiert werden, wird dies noch verstärken und den Integrationsaspekt noch stärker als bisher in den Vordergrund rücken. Genau aus diesem Grund haben Anbieter von Integrationsplattformen in den letzten Jahren eigene Prozessplanungs- und -steuerungskomponenten entwickelt oder zugekauft. Auch diese Unterstützung der Integrationssicht hinsichtlich der unterstützenden IT-Systeme kann in beliebigem Detail fortgesetzt werden. Systemübergänge können damit aufgezeigt und die systemtechnische Integration verbessert werden. Es ist genau die Integrationsunterstützung auf dieser detaillierten Ebene, die sich Integrationstests bei der Einführung neuer IT-Systeme zunutze machen, um eine möglichst gute und durchgängig funktionierende Unterstützung der Geschäftsprozesse zu erreichen. Integrations- und Abnahmetests in IT-Einführungsprojekten verfügen daher bereits vielfach über die erforderliche echte End-to-End-Sicht der Prozesse und sind damit der entscheidende Test in IT-Projekten, ob ein entwickeltes System den Geschäftsanforderungen entspricht.

Abb. 45: Aufzeigen von Systemübergängen im Detailablauf

173


4.4 Integration über Produkte und Leistungen Die ersten drei Bereiche der Integration finden innerhalb des Erstellungsprozesses einer Leistung statt. Darüber hinaus kann Prozessmanagement auch die Integration zwischen den Leistungserstellungsprozessen verschiedener Produkte und Leistungen unterstützen. Denn in der End-to-End-Sicht werden Geschäftsprozesse als die Abfolge aller notwendigen Schritte zur Erstellung von Produkten und Leistungen für den Kunden definiert. Die Erstellung jedes Produkts untergliedert sich damit entlang der Ablauffolge in Teilprozesse. Produkt A, ein Produkt, das kundenauftragsbezogen gefertigt wird, besteht zum Beispiel aus den Teilprozessen „Maschine entwickeln“, „Auftrag akquirieren“, „Auftrag anlegen“, „Maschine auftragsbezogen fertigen“, „Maschine liefern“, „Produkt fakturieren“ und „Erlöse, Kosten und Steuern verbuchen“. Produkt B, eine Standardmaschine, die auf Lager gefertigt wird, besteht hingegen aus den Teilprozessen „Maschine entwickeln“, „Nachfrage planen“, „Maschine auf Lager fertigen“, „Auftrag akquirieren“, „Auftrag anlegen“, „Maschine liefern“, „Standardmaschine fakturieren“ und „Erlöse, Kosten und Steuern verbuchen“. Bei der Identifikation der Prozesse wird dabei erst einmal jeder Leistungserstellungsprozess für sich betrachtet. Sind alle Teilprozesse der einzelnen Leistungserstellungsprozesse identifiziert, so können sie gegenübergestellt werden. Bei dieser systematischen Gegenüberstellung der Teilprozesse für die beiden Produkte können gleiche oder ähnliche Teilprozesse identifiziert und so das Integrationspotenzial über die Produkte und Leistungen hinweg aufgezeigt werden. Können die als gleich identifizierten Prozesse tatsächlich über die Produkte hinweg integriert werden, so entsteht ein verschränktes Bild der beiden Leistungserstellungsprozesse, wie es in Abbildung 48 dargestellt ist.

Abb. 46: Integration über Produkte und Leistungen (1)

174

Integration über Produkte und Leistungen


Auch in diesem verschränkten Bild ist es über die Verzweigungen nach wie vor möglich beide Geschäftsfälle – sowohl den Verkauf einer Standardmaschine als auch den Verkauf einer kundenindividuell gefertigten Maschine – end-to-end durchzuspielen. Als Methodik, um eine generelle Übersicht für diese Integration zwischen Produkten und Leistungen zu bekommen, hat sich neben integrierten Wertschöpfungsketten eine Matrix zwischen den Produkten und den Teilprozessen bewährt (Produkt-Teilprozess-Matrix). In ihr werden für alle Leistungen oder Produkte die wesentlichen Teilprozesse auf aggregierter Ebene gegenübergestellt. Im angeführten Beispiel der Produkt-Teilprozessmatrix sind neben der bereits oben angeführten individuell gefertigten Maschine und den Standardmaschinen nun auch ein Service für die Maschinenwartung sowie die Lieferung von indivi-


175


Abb. 49: Produkt-Teilprozess-Matrix

duell gefertigten Ersatzteilen integriert. In der neben stehenden Abbildung ist anhand dieser vier Leistungen nochmals dargestellt, wie diese aus den einzelnen Leistungserstellungsprozessen produktübergreifend integriert und verschränkt werden können (siehe Abb. 50). Die Transparenz über gleiche oder ähnliche Teilprozesse ist der Ausgangspunkt für eine Integration über die einzelnen Produkte und Leistungen. Wie weit diese Integration in der Folge umgesetzt wird, ist natürlich wieder eine betriebswirtschaftliche Entscheidung. Das Spektrum an Möglichkeiten reicht hier von komplett voneinander unabhängigen Teilprozessen mit unabhängigen Ressourcen, die parallel existieren, über eine gewisse Koordination und den Austausch von erfolgreichen Vorgehensweisen (best practices) bis hin zu getrennten Teilprozessen mit gemeinsamer Ressourcennutzung oder einem gemeinsamen Teilprozess für beide Produkte. Der in der Praxis maßgebliche Faktor für den Grad der Integration ist hier meist das Ausmaß der durch die Integration erzielbaren Synergien.

176



4.5 Integration über gemeinsam genutzte Ressourcen Ein weiterer Bereich, in dem Prozessmanagement die Integration und die Transparenz über Zusammenhänge unterstützt, sind gemeinsam genutzte Ressourcen. Stellen wir uns etwa zwei völlig voneinander unabhängige End-to-End-Prozesse vor, bei denen allerdings für bestimmte Teilprozesse dieselben Ressourcen genutzt werden. Ziehen wir zur Illustration wieder das oben bereits verwendete Beispiel der beiden Maschinentypen eines Maschinenbauers heran: einmal eine auf Lager gefertigte Standardmaschine, daneben individuell auf Auftrag gefertigte Sondermaschinen. Neben der möglichen Integration bestimmter Teilprozesse kann es auch der Fall sein, dass voneinander unabhängige Teilprozesse – etwa die auftragsbezogene Fertigung und die Fertigung auf Lager – auf dieselben Ressourcen zurückgreifen, etwa dasselbe Fertigungsteam oder auch auf dieselben Maschinen und Produktionseinrichtungen. Durch die Zuteilung der Ressourcen zu den Teilprozessen und Prozessschritten, kann eine solche Nutzung von gemeinsamen Ressourcen transparent gemacht werden. Vielfach hilft hier schon die Transparenz alleine, um zum Beispiel bei Wartungsarbeiten oder auch Änderungen an bestimmten Ressourcen zu wissen, welche Prozesse von solchen Aktivitäten betroffen sind. Das Prozessmanagement kann solche Abhängigkeiten aufzeigen. Über die reine Transparenz hinaus kann dies jedoch auch verwendet werden, um die Auslastung von gemeinsam genutzten Ressourcen zu analysieren oder sogar eine prozessübergreifende Kapazitätsplanung zu installieren. Als Instrumente hierfür können im Detail Prozesssimulationen oder Prozessressourcenanalysen eingesetzt werden. Das Prozessmanagement als Integrationsinstrument bietet damit auch eine Möglichkeit zur Analyse von gemeinsam genutzten Ressourcen innerhalb

Abb. 51: Von unabhängigen Prozessen gemeinsam genutzte Ressourcen

178

Integration über Standorte

von End-to-End-Prozessen sowie zwischen ihnen und adressiert damit auch das Problem der gepoolten Interdependenz über die gesamte Leistungserstellung. 260

4.6 Integration über Standorte Als sechsten Bereich kann Prozessmanagement auch die Integration über verteilte Standorte unterstützen und zu ihrer Verbesserung beitragen. Soweit die einzelnen Teilprozesse zur Erstellung einer Leistung oder eines Produkts zum Teil zentral und zum Teil dezentral durchgeführt werden – zentrale und dezentrale Organisationseinheiten also in der Leistungserstellung zusammenwirken –, entspricht dies der bereits beschriebenen Integration über Organisationseinheiten, die an der Leistungserstellung beteiligt sind. Während diese meist als Bereiche und Abteilungen verstanden werden, sind sie in diesem Fall dann zum Beispiel die Zentrale und die dezentralen Niederlassungen. Ein Beispiel wäre etwa eine Unternehmensstruktur, in der die Akquisition von Aufträgen und die Auftragsanlage dezentral in den Vertriebsniederlassungen oder Filialen erfolgt, die Herstellung des Produkts und die Lieferung aber durch die Firmenzentrale und die Verbuchung der Geschäftsfälle in einem Shared Service Center. Die Integration über die Standorte hinweg kann aber durch das Prozessmanagement auch dann unterstützt werden, wenn die Leistungserstellung komplett autonom durch die dezentralen Standorte erfolgt. In diesem Fall werden dann dieselben Produkte oder Leistungen in jedem Standort vollständig erbracht. Egal ob diese Standorte nun selbst aufgebaut oder aber zugekauft wurden, zeigt sich in der Praxis häufig, dass die Erbringung derselben Leistungen oft sehr unterschiedlich erfolgt. Ein Teil dieser Unterschiede mag aus unterschiedlichen gesetzlichen Gegebenheiten resultieren, sofern sich die einzelnen Niederlassungen in verschiedenen legistischen Rechtsräumen befinden. Dies ist zum Beispiel bei Landesniederlassungen in verschiedenen Ländern der Fall, abhängig vom Geschäftsfeld und vom Grad der Föderalisierung eines Landes kann dies aber auch bei Niederlassungen in verschiedenen Bundesländern oder Bundesstaaten der Fall sein. Ein anderer Teil, die Ausführungsverantwortung für einzelne Prozessschritte kann bei sonst gleicher Prozessabfolge divergieren, wenn die Größe der jeweiligen Standorte stark unterschiedlich ist. So sind etwa in kleinen Niederlassungen die einzelnen Abteilungen und Funktionen häufig viel weniger ausdifferenziert als in großen Standorten, sodass es hier Unterschiede in 260 Vgl. Schreyögg (2006, S. 122 f.). Er sieht die Behandlung der verschiedenen Arten von Interdependenzen zwischen einzelnen Verrichtungen als eine wesentliche Aufgabe der Prozessanalyse, sofern diese über die Verrichtungsanalyse im Kosiolschen Sinn hinausgehen soll. Vgl. dazu auch Gaitanides (2007), für den einer der wesentlichen Beiträge des Prozessmanagements in der Vernetzung der Prozesse liegt, und dies wiederum v. a. in Zusammenhang mit Interdependenzen in der Ressourcenallokation (S. 261).

179


Abb. 52: Integration über Standorte (1)

der Zuordnung der Ausführungsverantwortung und der dafür notwendigen Personalressourcen geben kann – die grundsätzliche Prozessabfolge sollte davon jedoch nicht betroffen sein. Meist finden sich aber darüber hinaus auch eine Reihe weiterer Unterschiede in der Prozessabarbeitung, die nicht durch legistische Rahmenbedingungen oder die unterschiedliche Größe der Standorte begründet sind, sondern sich einfach im Laufe der Zeit so entwickelt haben. Für ein und dieselbe Leistung sind damit dezentral verschiedene Prozessvarianten im Einsatz. Da es durchaus eine begründete Annahme ist, dass nicht alle diese eingesetzten Prozessvarianten gleich effektiv und effizient sind, lohnt es sich, diese Varianten im Detail zu vergleichen. Ziel dabei ist es, interne Best Practices zu identifizieren und diese dann in allen Standorten zur Anwendung zu bringen, soweit dies möglich ist. Auf diese Weise kann Prozess Know-how, das an einem Standort entwickelt wurde, auch anderen Standorten zur Verfügung gestellt und so ein Wettbewerbsvorteil über alle Standorte genutzt werden. Für diesen Vergleich ist allerdings eine Gegenüberstellung der Prozesse auf einer detaillierten Ebene erforderlich. Gelingt es, einzelne Teilprozesse der Leistungserstellung über alle dezentralen Standorte weitestgehend zu harmonisieren, so schafft dies darüber hinaus die Basis für eine Bündelung dieser Teilprozesse in einem gemeinsamen Service Center oder übergreifenden regionalen Plattformen. Auf diese Weise können die bis dahin autonomen Leistungserstellungsprozesse der dezentralen Standorte untereinander verschränkt und stärker integriert werden. In Abb. 54 ist dies anhand der Verbuchung der Erlöse, Kosten und Steuern illustriert.

180

Integration über Standorte

Abb. 53: Prozessharmonisierung über Standorte (2)

In der Praxis erfolgt häufig eine Bündelung von gleichen Teilprozessen in Shared Service Einheiten, ohne die dahinter liegenden Detailabläufe wirklich zu harmonisieren. Natürlich können auch damit Effizienzgewinne erzielt werden, und zwar durch die meist höhere Produktivität in solchen spezialisierten Einheiten sowie durch die Optimierung von Ressourcenpuffern für Urlaubs- und Krankheitsvertretungen. Erfolgt jedoch keine Harmonisierung der Detailabläufe und auch der unterstützenden IT-Systeme, so können die mit solchen Einheiten verbundenen Skaleneffekte nur zum Teil genutzt werden. Ebenso bleibt das Potenzial aus der Optimierung der einzelnen lokalen Prozessvarianten damit ungenutzt. Serviceeinheiten, die ohne eine solche vorausgehende Harmonisierung der entsprechenden Teilprozesse etabliert werden, leiden damit

Abb. 54: Integration über Standorte (3)

181


Abb. 55: Schritte der Optimierung verteilter Organisationen (Horváth & Partners)

häufig an der zu hohen Prozesskomplexität der übernommenen Varianten sowie in der Folge an einer Verfehlung der mit ihrer Einrichtung erhofften Effizienzgewinne. Auf Basis von Projekterfahrungen kann zwischen einem Viertel und einem Drittel der mit der Einrichtung von solchen übergreifenden Serviceeinheiten verbundenen Optimierungspotenziale nur gehoben werden, wenn die Bündelung mit einer entsprechenden Harmonisierung der zu bündelnden Teilprozesse einhergeht.

Abb. 56: Aufsplitten voll ausgeprägter Landesorganisationen

182

Integration über die Wertschöpfung zu Lieferanten und Kunden

Erfolgt die Optimierung lokaler Prozesse entlang dieser Schritte, so kann am Ende statt voll ausgeprägter dezentraler Standorte oder Landesniederlassungen eine integrierte Organisation stehen, bei der lokal bedingte und kundennahe Teilprozesse nach wie vor in den Standorten durchgeführt werden, ortsunabhängige und kundenfernere Teilprozesse jedoch in regionalen oder zentralen Einheiten für mehrere Länder gemeinsam erbracht werden. Auf diese Art entstehen neue, integrierte Niederlassungen, die sich auf die kundennahen Kernaufgaben konzentrieren können. Gerade in sehr kleinen Märkten, wie etwa in den Ländern in Zentral- und Osteuropa können solche Optimierungsschritte einen wesentlichen Wettbewerbsvorteil in der kosteneffizienten Bearbeitung dieser kleinräumigen Märkte bringen.

4.7 Integration über die Wertschöpfung zu Lieferanten und Kunden Ein letzter Bereich, in dem die Prozessperspektive die Integration im Unternehmen unterstützen kann, ist die Integration über die Wertschöpfungskette über das eigene Unternehmen hinaus, also zu Lieferanten und Kunden. Über die definierte End-to-End-Sicht umfassen die Geschäftsprozesse alle notwendigen Teilprozesse für die Leistungserstellung, egal von wem diese erbracht werden. Damit umfassen sie auch Teilprozesse, die zur Durchführung an externe Partner ausgelagert sind. Wird etwa ein Teilprozess, der für die gesamte Leistungserbringung zum Kunden notwendig ist, durch einen Lieferanten oder Kooperationspartner erbracht, so bleibt dieser in der Prozesssicht des Leistungserstellungsprozesses erhalten. Zur besseren Darstellung, dass er ausgelagert wurde, wird er nur graphisch anders dargestellt. Im nachfolgenden Beispiel ist dies etwa am Teilprozess „Produkt liefern“ illustriert, der in diesem Fall nicht vom Unternehmen selbst, sondern von einem externen Partner durchgeführt wird. Obwohl der Teilprozess „Produkt liefern“ an einen Dritten ausgelagert ist und von diesem durchgeführt wird, so bleibt er dennoch Teil des gesamten Leistungserstellungsprozesses. Denn trotz Auslagerung liegt die Gesamtverantwortung für den End-to-End-Prozess und die durch ihn erstellte Leistung beim Unternehmen, das dem Kunden gegenüber die Leistung erbringt. Geht bei der Lieferung etwas schief so verantwortet dies das Unternehmen gegenüber dem Kunden und nicht der betreffende Lieferant. Letzteres kann sich gegenüber dem Lieferanten natürlich regressieren – für

Abb. 57: Integration zu Lieferanten und Kunden (1)

183


den Kunden ist dies jedoch unerheblich. Innerhalb des Unternehmens bleibt der Endto-End-Prozess damit in der Gesamtverantwortung des jeweiligen Process Owners dieses Prozesses. Dieser hat aufgrund irgendwelcher Gründe – es könnten dies zum Beispiel Kostenüberlegungen sein oder auch der Wunsch sich auf seine Kernkompetenz zu konzentrieren – beschlossen, diesen Teilprozess nicht selbst durchzuführen, sondern von einem externen Partner durchführen zu lassen und das Ergebnis als Teilleistung extern zuzukaufen. Die erwartete Leistung wird dabei vertraglich definiert und überprüft. Neben Volumen und Preis werden dabei auch die wesentlichen Leistungsparameter für die Erbringung dieser Teilleistung fixiert. Im konkreten Beispiel könnte dies etwa die Zustellung im Inland innerhalb von 48 Stunden sein und ein Prozentsatz falscher Lieferungen von weniger als 1% pro Jahr. Genau wie bei internen Leistungsvereinbarungen werden auch hier diese Parameter in Service Level Agreements vereinbart und festgeschrieben. Auf der Ausführungsebene ändert sich damit die Verantwortung des Process Owners: Er ist nicht mehr selbst mit seinen Teams für die Erbringung der betreffenden Teilleistung zuständig, sondern steuert nur mehr den externen Outsourcingpartner auf Basis des vereinbarten Service Level Agreements. Die Verantwortung des Process Owners auf der Design- und Optimierungsebene bleibt indessen bestehen. Kommt er zu einem späteren Zeitpunkt aufgrund geänderter Rahmenbedingungen zu dem Schluss, dass die externe Erbringung dieses Teilprozesses nicht mehr die beste und wirtschaftlichste Lösung ist, so kann er dies wieder ändern und entweder einen anderen Outsourcingpartner suchen oder aber den Teilprozess auch wieder selbst mit eigenen Ressourcen übernehmen (insourcing). Die Integration von Geschäftspartnern kann jedoch nicht nur innerhalb der definierten Leistungserstellung erfolgen. Es ist genauso möglich, dass wesentliche voroder nachgelagerte Prozesse in die Darstellung der Leistungserbringung mit einbezogen werden, um die Integration transparent, bewusst und steuerbar zu machen.261 Im nachfolgenden Beispiel ist dies etwa an der Produktion von kritischem Rohmaterial und der Montage und Integration der gelieferten Teile in eine Gesamtanlage dargestellt. Die Produktion kritischer Rohmaterialien ist ein vorgelagerter Teilprozess eines Lieferanten, der für die eigene Leistungserstellung von kritischer Bedeutung ist. Bei dem nachgelagerten Prozess „Montage & Integration in Gesamtanlage“ handelt es sich hingegen um einen direkt anknüpfenden Kundenprozess, dessen Erfolg für die generelle Kundenzufriedenheit mit der Leistungserbringung durch das Unternehmen wichtig ist. Beide Beispiele zeigen, dass die Prozesssicht auch über die beiden Enden hinausgehen und die Integration zu wichtigen Lieferanten- und Kundenprozessen herstellen kann. Natürlich wird man dabei nicht jeden möglichen vor- und nachgelagerten Prozess in das eigene Prozessmodell mit aufnehmen. Dies wäre weder möglich noch sinnvoll. 261 Vgl. dazu etwa Hammer (2002).

184

Integrative Process Map

Abb. 58: Integration zu Lieferanten und Kunden (2)

Für ausgewählte, kritische oder besonders wesentliche vor- und nachgelagerte Prozesse kann diese Aufnahme in das Prozessmodell jedoch hilfreich sein und so die Integration zu wichtigen Lieferanten und Kunden über die eigene Wertschöpfung hinaus transparent und steuerbar machen. Zur selektiven Kommunikation von Prozessdetails an die jeweiligen Partner kann dabei das Konzept von privaten Prozessen hilfreich sein. Dabei können Prozesse in zwei Darstellungsvarianten betrachtet werden: einmal mit allen Informationen über den jeweiligen Geschäftsprozess (privater Prozess) und einmal in einer abgeleiteten und reduzierten Form, die nur jene Prozessinformationen enthält, die der Partner im Zuge der Zusammenarbeit benötigt und bekommen soll.262 Damit können sogar unternehmensübergreifend gemeinsame Prozessmodelle genutzt werden, ohne zu viele Details über die konkrete interne Abwicklung preiszugeben. Gerade diese Möglichkeit, nicht durch die Grenzen des eigenen Unternehmens eingeschränkt zu sein, sondern in wichtigen Bereichen auch über sie hinausgehen zu können, ist eine wesentliche Stärke der Prozesssicht und des Prozessmodells, die durch die aufbauorganisatorische Sichtweise nicht erfüllt werden kann.

4.8 Integrative Process Map Als Mittel, um die in den vorherigen Abschnitten beschriebene Integration transparent, optimierbar und steuerbar zu machen, kann auf Basis eines Prozessmodells und der darin abgebildeten Prozesse für die erbrachten Leistungen eine integrative Process Map263 erstellt werden. 262 Siehe Loos, Balzert, Werth (2010), S. 468. 263 Andrew Spanyi (2007) spricht in diesem Zusammenhang von einer schematischen Darstellung (schematic), die den Fluss der großen, cross-funktionalen Aktivitäten definiert, welche den Wert für den Kunden generieren (S. 13).

185


Hierbei muss vorausgeschickt werden, dass es bereits in vielen Unternehmen und Organisationen Prozesslandkarten gibt. Der Großteil davon wird jedoch nur als Gliederung für die detaillierten Prozessbeschreibungen, funktionalen Elemente sowie anderen organisatorischen Objekte verstanden und genutzt.264 Obwohl alle mit denselben Symbolen in den Prozesslandkarten dargestellt werden, handelt es sich dabei um Elemente ganz unterschiedlichen Typs. Darüber hinaus finden sich in den Prozesslandkarten vielfach auch völlig andere Objekte, wie etwa „EDV“, „Prüfsystem“ oder „Kundenzufriedenheit“, bei denen es sich definitiv nicht um Prozesse handelt. Rudolf Wilhelm bringt dies sehr pointiert auf den Punkt, wenn er schreibt: „Manchmal findet man auch in den Prozesslandkarten – mit dem üblichen ‚Prozess‘-Symbol dargestellt – Bezeichnungen wie ‚Kundenorientierung‘, ‚Qualität‘, ‚Dokumente‘ usw. Was damit gesagt werden soll, ist schleierhaft. Jedenfalls handelt es sich bei den genannten Begriffen ganz offensichtlich nicht um Prozesse.“265 In Verbindung mit einem Prozessverständnis, das Prozesse nicht in einem echten End-to-End-Zusammenhang, sondern aus einer funktional geprägten Teilprozesssicht sieht, kann eine solche Prozesslandkarte die angesprochene Unterstützung für die Integrations- und Koordinationsfunktion nicht oder nur sehr eingeschränkt leisten. Es dürfte nicht zuletzt dieser Umstand sein, warum viele bestehende Prozesslandkarten von den Mitarbeitern in den Unternehmen als wenig wertvoll gesehen werden, zeigen sie doch meist als rein funktionale Gliederungsmodelle eine Realität, die bei allen Mitarbeitern hinreichend bekannt ist und eben nichts oder nur wenig zu einer neuen Sichtweise und zur Integration über die einzelnen Aspekte beitragen kann. Der hier vorgestellte Ansatz unterscheidet sich signifikant von anderen Strukturierungsvorschlägen, die etwa auf der obersten Ebene des Prozessmodells nur einen allgemeinen Ordnungsrahmen im Sinne einer frei gestaltbaren Gliederung der einzelnen Teilprozesse und Teilprozessgruppen zum Inhalt haben. Derartige Ordnungsrahmen und Gliederungsmodelle reflektieren meist mehr die Aufbaustruktur oder die funktionale Gliederung als die Prozesssicht und widersprechen damit dem hier entwickelten End-to-End-Prozessverständnis. Entscheidend ist daher neben dem echten End-to-End-Verständnis von Geschäftsprozessen die Frage, wie eine gute Process Map aufgebaut sein muss, damit sie diese Funktion erfüllen kann und somit einen echten Mehrwert bietet. Hierfür können einige Designkriterien aufgestellt werden, die beachtet werden müssen: Im Kern der Process Map stehen die Leistungen für die Kunden und die dafür notwendigen Leistungserstellungsprozesse. Natürlich können auf der obersten Ebene nicht alle Haupt- und Nebenleistungen, die von einem Unternehmen irgendwo einmal erbracht werden oder wurden, dargestellt werden. Die Process Map sollte viel264 Becker, Meise (2008) sprechen daher auch von einem Ordnungsrahmen anstatt einer Prozesslandkarte und sehen diesen v. a. aus der Perspektive der Wahrnehmung. 265 Rudolf Wilhelm (2007), S. 37–38. Siehe auch Spanyi (2007), der feststellt, dass nur wenige Unternehmen eine integrative Darstellung ihrer cross-funktionalen Prozesse haben (S. 13).

186


mehr die wesentlichen Leistungen oder Leistungstypen und deren Leistungserstellungsprozesse umfassen, welche die eigentliche Geschäftstätigkeit des Unternehmens ausmachen, und so die prozessrelevanten Elemente des Geschäftsmodells klar zum Ausdruck bringen. Ein Modell ist schließlich nicht die Realität. Gerade dieser Punkt ist in der Praxis oft eine große Herausforderung, und es gelingt nur wenigen Prozesslandkarten, sich auf das wirklich Wesentliche zu beschränken. Fälschlicherweise wird oft versucht, die Realität möglichst genau abzubilden und damit jeden noch so unwesentlichen Prozess bereits in der Prozesslandkarte abzudecken. Dies ist aber nicht nur gar nicht notwendig, sondern sogar kontraproduktiv. Denn ein Modell hat nicht den Anspruch, die Realität detailgetreu abzubilden, sondern ganz im Gegenteil: Das Modell abstrahiert von der Realität und lässt soviel wie möglich an Details weg, um den Fokus auf die wenigen wesentlichen Kernelemente zu legen. Nur so kann es die Komplexität reduzieren und als Rahmen für die Steuerung dienen. Die dargestellten Leistungserstellungsprozesse werden dabei nicht nur einfach aufgelistet, sondern inklusive ihrer Detaillierung in die erste Ebene der Teilprozesse gezeigt, damit die Integration in der Wertschöpfungskette sichtbar wird. Eine integrative Process Map stellt daher nicht nur die Elemente einer Ebene in der Prozessarchitektur dar, sondern zeigt bewusst die Ebene 1 und 2 zur Darstellung der Integration – daher auch die hier verwendete Bezeichnung „integrative Process Map“.266 Dabei ist auch in der Process Map analog zu den Prozessmodellen auf den Ebenen zwei und drei der Ablauf, sprich die Struktur aus Folgebeziehungen zwischen den einzelnen Elementen herauszuarbeiten. Eine Process Map muss bereits auf der obersten Ebene den wesentlichen Ablauf der Wertschöpfungskette des Unternehmens zeigen. Eine reine Ansammlung von Elementen ohne klare definierte Folgebeziehungen ist zu wenig.267 266 Vgl. Schmelzer, Sesselmann (2010): Auch sie empfehlen, Prozesslandkarten auf Teilprozesse der nächsten Ebene auszudehnen, da dies aufschlussreicher sei (S. 83). Allerdings gehen sie in ihrer Konzeption nicht von echten End-to-End-Prozessen aus, sondern beginnen – anders als hier – erst mit der Ebene der Teilprozesse (vgl. Abb. 2.14 auf S. 82). Rummler, Remias, Rummler (2010) schlagen für dieselbe Zielsetzung ihr Konzept der Value Creation Architecture vor, die auf ihrem Level 2 mit dem Value Creation System ebenso eine End-to-End-Perspektive entwickelt, dabei allerdings durch die drei vorgeschlagenen Standardbausteine „product/service launched“, „product/ service sold“ und „product/service delivered“ sehr allgemein bleibt und die interessanten Unternehmensspezifika erst auf den unteren Teilprozessebenen integriert. Damit besteht erst wieder das Risiko, dass sich das Interesse auf die unteren Ebenen der abgegrenzten Teilprozesse verlagert. Demgegenüber holt das Konzept der integrativen Process Map, wie es hier entwickelt wurde, die Unternehmensspezifika bereits auf die oberste Ebene, um die Integration der Wertschöpfung in den Vordergrund zu holen und das Spezifische an der Leistungserstellung der Unternehmen klar herauszuarbeiten. 267 Vgl. Rudolf Wilhelm (2007), S. 34–36. Er stellt dort unter Bezugnahme auf die DIN ISO 9001 2000 fest, dass eine Prozesslandkarte die Abfolge und Wechselwirkung der Prozesse eines Betriebs darstellt. Vgl. auch Wagner, Patzak (2007, S. 69), für die in einer Prozesslandschaft auch das Gedankengut einer durchgängigen Prozesskette im Vordergrund steht. Becker, Kugeler, Rosemann

187


Abb. 59: Integrative Process Map und Prozessarchitektur

Entsprechend der erarbeiteten Prozessdefinition enthalten die Leistungserstellungsprozesse dabei nicht nur die Teilprozesse, die von dem jeweiligen Unternehmen selbst erbracht werden, sondern alle Teilprozesse, die für die Erstellung der Leistung notwendig sind. Auch Teilprozesse, die von externen Partnern erbracht werden, sind enthalten. Es wird somit die komplette Wertschöpfungskette aus Sicht der von Kunden angefragten Leistung dargestellt. Zum einfachen Hervorheben der eigenen Wertschöpfung gegenüber zugekauften Wertschöpfungsteilen werden die von externen Partnern erbrachten Teilprozesse jedoch sinnvollerweise graphisch anders dargestellt. Damit zeigt die Process Map nicht nur, was ein Unternehmen macht und womit es sein Geld verdient, sondern auch was es nicht macht und ausgelagert hat. Gleichzeitig werden von mehreren Leistungserstellungsprozessen gemeinsam genutzte Teilprozesse auch verschränkt dargestellt. Damit wird neben der Integration in der Wertschöpfungskette auch die Integration über die verschiedenen Leistungen und Produkte hinweg transparent. Auf diese Weise entsteht ein aggregiertes und verschränktes Prozessbild, das die wichtigsten Kernelemente der vertikalen Integration und der horizontalen Diversifikation entlang der Wertkette sowie die Verknüpfung aller Teilprozesse über Prozessschnittstellen ersichtlich macht.268 Wie dargestellt wurde, (2008) betonen, dass Organisationen, die im Wettbewerb stehen, ein transparentes Bild der eigenen Wertschöpfungskette benötigen (S. 9). 268 Vgl. Nicolai (2009, S. 206): Auch für sie zeigt eine Prozesslandschaft den Zusammenhang zwischen den Prozessen sowie die Schnittstellen, welche die einzelnen Prozesse verbinden. Eine integrative Process Map wie hier dargestellt erfüllt somit auch die Anforderung der ISO-Qualitätsnormen, nicht nur die Prozesse eines Unternehmens, sondern auch ihre Abfolge und Wechselwirkungen festzulegen (vgl. dazu ISO 9001–2000 Kapitel 4.1 zit. in Wagner 2001, S. 95). Einen alternativen

188


folgt also auch das End-to-End-Prozessmanagement dem Grundprinzip der Analyse und Synthese, wie dies in der klassischen Organisationslehre in Bezug auf Aufgaben und Arbeiten etabliert ist. Zuerst werden die End-to-End-Geschäftsprozesse identifiziert und auf einzelne Teilprozesse herunter gebrochen. Dann werden gleiche Teilprozesse produkt- und standortübergreifend integriert.269 Abbildung 60 zeigt ein Beispiel für eine solche integrative Process Map. Ergänzend zu diesen inhaltlichen Kriterien für das Design seien auch die formalen Punkte nochmals erwähnt, die bereits bei der Erarbeitung der Prozessdefinition ausführlich besprochen wurden. Vielfach spiegeln Prozesslandschaften die Aufbauorganisation des Unternehmens wieder, indem entweder direkt Organisationseinheiten repräsentiert sind oder aber zumindest jede Organisationseinheit „ihren“ Prozess auf der obersten Ebene hat. Dies mag unternehmensdiplomatisch sinnvoll sein – für ein richtig verstandenes Prozessmanagement und für das Erzielen des Nutzens aus der Prozesssicht ist es jedoch unbrauchbar. Wenn sich jeder in seinem „Prozesskästchen“ wieder findet, mag das die Harmonie sichern – eine zusätzliche Sicht auf das Unternehmen bringt es jedoch nicht. Und genau darin liegt ja eine wesentliche Stärke des Prozessmanagementansatzes. Ebenso häufig wie die Prozesslandschaft mit dem Organigramm vermischt wird, findet sich auch die Vermengung von funktionalen und prozessualen Elementen. Kaum eine Prozesslandkarte, die nicht „Finance & Accounting“ oder „Materialwirtschaft“ enthält. Beides sind jedoch Unternehmensfunktionen und nicht Geschäftsprozesse, wie bereits im ersten Kapitel ausführlich besprochen wurde. Auch hier gilt wiederum: Wenn die Process Map nur bereits Bekanntes bietet, kann sie ihren added value durch eine zusätzliche und neue Sicht auf das Unternehmen im Sinne der Ablaufintegration nicht erbringen. Als guter Test für eine integrative Process Map kann man typische Geschäftsfälle für die abgebildeten Leistungen nehmen und sie anhand des dargestellten Ablaufs der Leistungserstellung durchspielen. Ist die Process Map gut, so gelingt dies. Muss man dafür abseits der dargestellten Abfolge irgendwo zu einem isolierten Teilprozess springen, so stimmt irgendetwas noch nicht. Ein zweiter guter Test ist es, die integrative Process Map den teilnehmenden Bereichen zu zeigen: Deuten diese mit den Worten „da sind wir“ auf einen der Teilprozesse und ignorieren den Rest, so stimmt ebenso irgendetwas noch nicht. Bei einer guten integrativen Process Map sind die einzelnen Bereiche meist in mehreren, verschiedenen Teilprozessen eingebunden – etwa der Vertrieb im Teilprozess „Neukunden gewinnen“, in „Bestandskunden betreuen“ und in „Leistungen fakturieren“. Ansatz dazu entwickelt etwa Gareis (2008, S. 91–93): Da er in seiner Konzeption der Process Map keine Abfolge und Leistungsbeziehungen wie hier dargestellt anwendet, sondern die Prozesse nur isoliert nebeneinanderstellt (vgl. S. 89–90), benötigt er als zusätzliches Konstrukt das Network of Processes, mit dem dieses Manko ausgeglichen wird. 269 Vgl. Nicolai (2009), S. 36.

189

Abb. 60: Illustration einer integrativen Process Map


Oder die Buchhaltung in den Beschaffungs- (® Eingangsrechnungen verbuchen) und Vertriebsprozessen (® Ausgangsrechnungen verbuchen) sowie im Prozess „Anlagen bereitstellen“ (® Anlagen aktivieren) und über die Erstellung der Bilanz und der Gewinn- und Verlustrechnung auch im Prozess „Performance steuern“. Dies zu erkennen – wo man überall involviert ist – braucht meistens ein paar Minuten und mehr als einen flüchtigen Blick. Ist dies der Fall und findet sich der jeweilige Bereich nach kurzer Überlegung in den jeweiligen Schritten der Leistungserstellung, so ist dies meist ein guter Hinweis, dass die Process Map gelungen ist. 270 Wird eine integrative Process Map in dieser Weise erstellt, so kann dies zu einer wesentlichen Verbesserung der Integration im Unternehmen beitragen. Denn sie zeigt dann: · · · · · · ·

welche Leistungen das Unternehmen erbringt wie diese erbracht werden was davon selbst gemacht wird und was nicht wie die einzelnen Schritte der Leistungserbringung zusammenhängen271 wo Prozesse über die Leistungen integriert sind und wo nicht welche wichtigen Prozessvarianten bestehen (z. B. Eigenfertigung vs. Zukauf ) wo es wichtige Schnittstellen zu Lieferanten und Kunden gibt

Dieses Übersichtsbild bildet dann nicht nur eine saubere Basis für das gesamte Prozessmodell und alle darunter liegenden Detailprozesse. Es hilft auch mit, die integrative Prozesssicht auf das Unternehmen zu etablieren, die wirklich die cross-funktionale und teilprozessübergreifende Wertschöpfungskette des Unternehmens aus Sicht der Kunden darstellt.272 Damit wird die Prozesssicht zu einer zusätzlichen, ergänzenden Managementsicht auf das Unternehmen.273 Neben der aufbauorganisatorischen und der funktionalen Sicht auf das Unternehmen steuert die Prozesssicht vor allem die Kundenausrichtung und die Integration der Leistungserstellung bei. Da die Process Map auch den Rahmen für die weitere Detaillierung und das weitere Arbeiten mit den Prozessen bildet, ist es entscheidend, hier Zeit zu investieren und die wichtigen Zusammenhänge richtig herauszuarbeiten. Werden Prozesse auf der 270 Vgl. dazu das plakative Statement von Michael Hammer (1997), dass ein Prozess als Faustregel mindestens drei Menschen verärgern muss – ansonsten sei es kein Prozess (S. 31). 271 Vgl. auch Knuppertz (2009), für den ebenso die Leistungsprozesse und deren Reihenfolge ein wesentliches Element der Prozesslandschaft sind (S. 58). 272 Vgl. dazu Spanyi (2007). Andrew Spanyi ist einer der wenigen Vertreter des Prozessmanagements, der eine echte End-to-End-Sicht der Geschäftsprozesse zugrunde legt und Prozessmanagement als die Fähigkeit und Ansätze sieht, diese großen, cross-funktionalen Prozesse zu managen. Für Spanyi ist dafür allen voran eine Änderung in der geistigen Haltung (mindset) der Manager notwendig, die seiner Meinung nach aktuell immer noch eine einseitige Befangenheit für die funktionale Sichtweise (functional bias) haben (S. 16–17). 273 Vgl. Spanyi (2007), S. 22 und S. 110–111.

191


obersten Ebene nicht entsprechend integriert, sondern isoliert dargestellt, so setzt sich dies auf allen Detailebenen fort und die Integrationsfunktion kann für diesen Teil nicht oder nur sehr bedingt erfüllt werden. Einem korrekten Design der Process Map kommt daher für das gesamte Prozessmanagementsystem eine entscheidende Bedeutung zu.274

4.9 Integration nach größeren Reorganisationen Der Wert dieser integrativen Sicht kommt insbesondere nach größeren Reorganisationsprojekten zum Tragen. Wie weiter oben erwähnt, kommt der Aufbauorganisation in der Unternehmensrealität vielfach ein realer Primat zu. Reorganisationen erfolgen in der Praxis primär über die Umstrukturierung der Aufbauorganisation. Hierbei werden auf Basis verschiedener Analyse- und Einflussfaktoren Bereiche zusammengefasst oder anders geschnitten, Abteilungen neuen Bereichen zugeschlagen, Einheiten zentralisiert oder auch wieder dezentralisiert und so fort. Gemäß dem in der gängigen Prozessmanagementliteratur vertretenen Postulat structure follows process müssten derartige Reorganisationen auf einer umfassenden Prozessanalyse basieren, aufgrund der die Zuständigkeiten für die einzelnen Prozesse, Teilprozesse und Prozessschritte neu in aufbauorganisatorischen Einheiten zusammengefasst werden. Dies ist jedoch in der Realität bis auf wenige Ausnahmefälle nicht der Fall. Vielmehr hat es sich etabliert und bewährt, die Aufbauorganisation anhand strukturgestalterischer Überlegungen neu zu formen. Die Ansiedlung von bestimmten Bereichen oder Abteilungen folgt dabei sowohl inhaltlichen Überlegungen der Anforderungen des jeweiligen Unternehmens als auch Anregungen aus dem Vergleich mit Trends im Markt und ausgewählten vergleichbaren Unternehmen. Dies ist unter anderem auch deshalb notwendig, weil die prozessorientierte Analyse zwar Inputs geben könnte, welche Prozessschritte und Teilprozesse sinnvollerweise in denselben Einheiten zusammengefasst werden sollten oder eben nicht; es kann jedoch aus den Prozessen heraus nur bedingt eine Antwort auf die konkrete Ansiedlung der so empfohlenen Einheiten innerhalb der hierarchischen Gesamtstruktur gegeben werden. Ein Beispiel: Anhand der Analyse der Prozesse für die Bereitstellung von IT-Systemen kann zum Beispiel eine Empfehlung gegeben werden, welche Teilprozesse und Prozessschritte von der IT und welche von den anfordernden Fachabteilungen wahrgenommen werden sollen; ebenso ist es auf Basis von Best Practices, wie sie zum Beispiel in den ITILund Cobit-Referenzmodellen abgebildet sind, möglich, eine Empfehlung über die differenzierte Ausgestaltung der Stellen innerhalb der IT zu geben. Die grundsätzliche Frage, wie ein IT-Bereich zu gliedern ist und in welchem Vorstandsressort er am besten 274 Vgl. dazu auch Rummler, Ramias, Rummler (2010): “The design and management of work at Level 2, the Value Creation System level of the Value Creation Hierarchy, is critical. If this isn’t done properly, all the process and management work at subsequent levels are forever compromised” (S. 54).

192

Integration nach größeren Reorganisationen

angesiedelt ist, kann jedoch aus den Prozessen heraus nicht beantwortet werden. Dies erfolgt typischerweise über Inputs aus der fachlich-inhaltlichen Diskussion über die Rolle von IT-Abteilungen sowie über erfolgreiche Best Practice Beispiele. Dies gilt in analoger Weise auch für andere Bereiche im Unternehmen. Reorganisationen werden daher fast immer über die Aufbauorganisation vorgenommen. Änderungen im Zuge solcher Reorganisationen führen jedoch beim beschriebenen Vorgehen klarerweise dazu, dass das etablierte und eingespielte Zusammenspiel der verschiedenen unternehmensinternen und -externen Einheiten in der Leistungserstellung zerrissen wird. Aus diesem Grund ist es bei aufbauorganisationsgetriebenen Reorganisationen notwendig, nachgelagert den Fokus auf die Re-Integration der Prozesse zu legen. Dabei muss analysiert werden, welche Auswirkung die Änderungen der Reorganisation der Aufbaustruktur auf die einzelnen End-to-End-Prozesse haben. Da Änderungen der Aufgaben und der damit bis dahin verbundenen Mitarbeiter nicht immer kongruent sind, entsteht durch die Änderungen auch oft eine Situation, in der in den einzelnen Prozessen nicht mehr klar ist, wer nun genau welche Teilprozesse und Prozessschritte durchführt und für sie verantwortlich zeichnet. Es ist kein Einzelfall, dass bestimmte Mitarbeiter dann gebeten werden, weiterhin bestimmte alte Aufgaben zu erfüllen, obwohl diese nicht mehr zu ihrer neuen Stelle passen, bloß weil sonst niemand Bescheid weiß und die Rahmenbedingungen für eine Durchführung in der neuen Struktur im Zuge der Reorganisation einfach nicht geschaffen wurden. Aber auch dort, wo ein grundsätzliches Verständnis über die prinzipielle Aufgabenverteilung bestehen bleibt, müssen Details des Leistungsaustausches an den Prozessschnittstellen neu erarbeitet, abgestimmt und vereinbart werden.

Abb. 61: Prozessmanagement als Instrument zur Re-Integration der Prozesse nach Restrukturierungen

193


Aufgrund der Unterstützung der Integrationsfunktion kann genau dies durch das Prozessmanagement besser als durch jeden anderen Ansatz unterstützt werden. Das Mittel zum Aufzeigen und Abstimmen der neu entstandenen oder geänderten Prozessschnittstellen ist hierfür wiederum das Prozessmodell, allen voran die oberen Aggregationsebenen mit dem Mittel der Swimlanes. Hat ein Unternehmen bereits ein aktuelles Prozessmodell mit einer echten End-to-End-Prozesssicht, so ist es ein Leichtes, dieses mit den jeweils Beteiligten durchzugehen, die Änderungen in den Prozessen, die durch die Reorganisation entstanden sind, zu identifizieren und diese organisatorischen Schnittstellen neu zu regeln. Diese Regelungen im Sinne der Abstimmung des neuen Prozessverlaufs und der Vereinbarung der Prozessschnittstellen entsprechen dem klassischen funktionalen Verständnis von Organisation. Da hierbei mit dem Prozessmodell und eventuellen Service-Level-Agreements zwischen allen Beteiligten Vereinbarungen getroffen werden, deckt sich dies sowohl mit dem klassischen Verständnis des Organisierens als auch dem modernen Verständnis von Prozessen als sozialer Konstruktion. Das Prozessmodell kann damit einen wertvollen Beitrag zur erfolgreichen Umsetzung von Reorganisationen leisten.

4.10 Integration bei Firmenakquisitionen Ein weiteres spezielles Einsatzfeld, bei dem das Prozessmanagement die Integrationsfunktion unterstützen kann, ist die Integration von zugekauften Unternehmen oder Firmenteilen. Akquisitionen sind ein gängiges Mittel das eigene interne Wachstum durch den Zukauf von bereits etablierten anderen Unternehmen zu ergänzen. Dabei können Akquisitionen das eigene Leistungsportfolio aus Prozesssicht auf unterschiedliche Weise ergänzen: · · ·

durch eine Erweiterung um bisher selbst nicht abgedeckte Teilprozesse der Wertschöpfung (Erweiterung der vertikalen Integration) durch eine Erweiterung des Produkt- und Leistungsportfolios (Erweiterung der horizontale Diversifikation) oder auch durch eine geographische Ausdehnung des eigenen Wirkungskreises mit den bereits bestehenden Produkten (geographische Diversifikation).

Über das Prozessmodell lassen sich solche Zukäufe gegenüber verschiedenen Stakeholdergruppen sehr schön darstellen und erklären. Zum einen wird so die Ergänzung zur bisherigen Wertschöpfung deutlich, zum anderen wird aber auch der Integrationsbedarf für eine erfolgreiche Integration transparent.275 275 Vgl. Spanyi (2007), der festhält, dass die erfolgreiche Integration von Akquisitionen Prozessdenken und Prozessaktivitäten erfordert (S. 43).

194

Integration bei Firmenakquisitionen

Abb. 62: Prozessmanagement als Instrument zur Integration von Akquisitionen

Bei einer Erweiterung der Tiefe der Leistungserstellung durch Zukauf von Einheiten, die voroder nachgelagerte Teilprozesse der Wertschöpfung abdecken, besteht der Integrationsbedarf zum einen in der sauberen Eingliederung dieser neuen Teilprozesse in die eigene Wertschöpfungskette. Zum anderen müssen zum Erzielen der mit dem Zukauf verbundenen Synergieeffekte die ähnlichen Teilprozesse der Leistungserstellung und die ähnlichen Bereitstellungsprozesse standardisiert und – falls sinnvoll – organisatorisch gebündelt werden. Zum Dritten sind die Steuerungsprozesse soweit zu harmonisieren, dass rasch eine effektive Steuerung des zugekauften Geschäfts und der damit verbundenen Einheiten gegeben ist. Bei einer Erweiterung des Produkt- und Leistungsportfolios (Erweiterung der horizontalen Diversifikation) besteht der Integrationsbedarf hauptsächlich in der Integration der Teilprozesse zwischen den bisherigen und den neuen Produkten und Leistungen. Daneben besteht der Integrationsbedarf in den Bereitstellungs- und Steuerungsprozessen wie im ersten Fall. Bei einer rein geographischen Ausdehnung des eigenen Wirkungskreises in neue Märkte und Länder auf Basis des bereits bisherigen und bestehenden Produkt- und Leistungsportfolios liegt der Integrationsbedarf vor allem in der Harmonisierung und Standardisierung der Prozesse. In diesem Fall muss das erfolgreiche bestehende Prozessmodell möglichst rasch auf die zugekauften Teile ausgerollt werden. Dieses Ausrollen der eigenen Prozesse ermöglicht es, jene Leistungserstellungsprozesse, in denen das Unternehmen aufgrund seiner Kompetenzen einen Wettbewerbsvorteil hat, auch in den neuen Märkten zum Einsatz zu bringen und diesen Wettbewerbsvorteil auch dort auszuspielen. Gleichzeitig schafft die Basis der Standardisierung in den Leistungs- und Bereitstellungsprozessen die Möglichkeit auch hier standortübergreifend Synergien durch eine Bündelung von Teilprozessen zu erzielen, wie dies weiter oben bereits zur Integration über Standorte hinweg erörtert wurde. Entscheidend ist dabei herauszufinden, welche lokalen Spezifika legal notwendig oder aber in den betreffenden Märkten aufgrund der lokalen Gegebenheiten erfolgskritisch sind. Werden diese nicht oder

195


nicht vollständig erkannt, kann eine Prozessharmonisierung zu weit gehen und zu einem Misserfolg führen. Werden die Prozesse hingegen zu wenig harmonisiert, so bleiben Vorteile aus eigenen Stärken in den Prozessen und Synergien aus einer Prozessbündelung ungenutzt. Unternehmen, die auf eine volle Integration von Zukäufen in der Post Merger Phase verzichten, gehen damit zwar unter Umständen weniger Risiko ein, nutzen aber gleichzeitig auch nur einen Teil der möglichen Chancen aus dem Zukauf.276 Neben den notwendigen lokalen Prozessvarianten können dabei auch Teilprozesse im zugekauften Unternehmen identifiziert werden, die den eigenen überlegen sind. In diesem Fall sind diese als neue interne best practice zu definieren und möglichst rasch im Prozessmodell des Unternehmens und den bisherigen Ländern zu implementieren (roll-back). Wie dargestellt wurde, kann Prozessmanagement auf Basis einer End-to-End-Sicht und dem Verständnis als ergänzendem Organisationselement im Gesamtzusammenhang der Unternehmensorganisation vor allem die Integrationsfunktion im Unternehmen unterstützen. Dies auf vielerlei Weise: über die Integration der Teilprozesse zur Leistungserstellung, über Organisationseinheiten und unterstützende IT-Applikationen, über verschiedene Leistungen, über Standorte, über gemeinsam genutzte Ressourcen sowie zu Kunden und Lieferanten. Gerade durch diese integrative Funktion kann das Prozessmanagement einen wichtigen Beitrag leisten, der eine sinnvolle Ergänzung zur aufbauorganisatorischen Gliederung und zur funktionalen Sichtweise darstellt. Gerade im Wettbewerb ist eine effektive Integration ein wesentlicher Erfolgsfaktor für Unternehmen.277 Als Mittel dafür dient in erster Linie ein auf Basis des Endto-End-Verständnisses aufgebautes Prozessmodell, an dessen Spitze eine integrative Process Map steht. Ein derartiges Prozessmodell kann nicht nur die Transparenz über die Wertketten der einzelnen Leistungen und deren Verflechtung herstellen, sondern auch in speziellen Unternehmenssituationen, wie etwa größeren Reorganisationen oder bei der Integration zugekaufter Firmen, eine wertvolle Hilfe sein.

276 Vgl. dazu auch Rummler, Remias, Rummler (2010): Für sie ist das Bild über die Zusammenhänge der Prozesse zur Wertschöpfung ein mächtiger Rahmen zur Unterstützung von Managemententscheidungen, u. a. auch für die Integration von Zukäufen, um zu sehen, welche Teile des Value Creation System integriert werden sollen und welche nicht (S. 55). 277 Becker, Kugeler, Rosemann (2008): Sie halten fest, dass Branchenbeste nicht selten den höchsten Integrationsgrad der im Prozess beteiligten Personen aufweisen (S. 9).

196

5 Prozessmanagement als Managementansatz 5.1 Managementverständnis von Prozessmanagement Nachdem Prozesse im Sinne eines echten End-to-End-Verständnisses definiert wurden und eine Einordnung des Prozessmanagements auf Basis dieses Prozessverständnisses in die Organisation von Unternehmen versucht wurde, soll im folgenden Teil nun der Fokus auf das kontinuierliche Arbeiten in der Perspektive der Prozesse gelegt werden: den Prozess des Prozessmanagements, und hier wiederum vor allem auf den zweiten Teil des Begriffs: auf das Management.278 Der Grund für diesen hier gewählten Fokus liegt vor allem darin, dass bisher Prozessmanagement sehr stark auf das Erlernen und Anwenden von bestimmten Methoden reduziert wurde. Dies könnte zumindest zum Teil auf der vielfachen Anlehnung von Entwicklungen im Prozessmanagement an jene im Projektmanagement beruhen oder davon zumindest beeinflusst sein.279 Da im Projektmanagement am Beginn sehr stark über traditionelle Autorität gemanagt wurde und dies dazu führte, dass viele Projekte in Misserfolgen mündeten, wurde viel Zeit und Energie darauf verwandt, entsprechende Methoden und Standards des Projektmanagements zu entwickeln, zu verbreiten und zu etablieren, um den Projektmanagern das richtige Handwerkszeug zum erfolgreichen Managen von Projekten zur Verfügung zu stellen. Internationale Standards wie PMI oder Prince II sowie die darauf aufbauenden und in fast allen Unternehmen inzwischen etablierten Projektmanagementhandbücher sind Ausdruck dieser Entwicklung. Ähnlich wurde auch im Prozessmanagement viel in die Entwicklung und Bereitstellung von entsprechenden Methoden zum Arbeiten mit Prozessen investiert. Die Fülle an Methodenhandbüchern, methodenfokussierten Lehrgängen und Ausbildungen sowie die zunehmenden Personenzertifizierungen280 für Prozessmanagement sind Ausdruck davon. Insbesondere im SixSigma-Ansatz wurde die 278 Vgl. Rummler, Ramias, Rummler (2010), S. 20: Sie kritisieren insbesondere, dass die Anbieter von Prozessmodellierungssoftware den Begriff Geschäftsprozessmanagement übernommen haben, sodass heute viele Leute bei „BPM“ automatisch annehmen, man spreche über die Software, und dies habe mit „Management“ wenig zu tun. In den Worten der Autoren: „it is hard for us to see the M in BPM.“ (S. 20). Natürlich können Softwaretools wichtige Unterstützung leisten, aber „it is a major mistake to confuse the assistance with the management“ (S. 21). 279 Konstrukte wie Prozesszertifizierungen, die dahinter stehenden zeitlich befristeten Zertifizierungsmodelle oder auch Wissenssammlungen wie ein Body of Knowledge zeigen hier ganz deutliche Anleihen und Parallelitäten auf. 280 Z. B. die Zertifizierung zum OMG Certified Expert in Business Process Management (OCEB), siehe Weilkens, Weiss, Grass (2010); die Zertifizierung der European Association of Business Process Management EABPM zum Certified Business Process Professional (CBPP), siehe EABPM (2009);


197

Prozessmanagement als Managementansatz

Schulung und richtige Anwendung von Methoden sehr intensiv vorangetrieben und über die Idee der verschiedenen Ausbildungsstufen (belts) mit einem sehr intelligenten und motivierenden Modell der persönlichen Entwicklung verbunden. So wichtig dieser Beitrag der Methodenentwicklung und -ausbildung aber auch ist, so greift er doch für sich alleine zu kurz. Durch den starken Fokus auf die Methoden und auch vielfach die nicht zielführende Diskussion über die „richtigen“ Methoden, Ansätze und Werkzeugsets, ist der Aspekt des Managements im Prozessmanagement in den letzten Jahren vielfach zu kurz gekommen und vernachlässigt worden. Etwas überzeichnet könnte man festhalten, dass eine Vielzahl der Prozessmanager in den Unternehmen heute methodisch gut ausgebildet sind, aber ihre Prozesse nicht wirklich managen. Sie sind Methodenanwender und Werkzeugverwalter, aber keine Manager. Es sei nochmals betont, dass gut entwickelte und entsprechend beherrschte Methoden absolut wichtig sind. Sie sind jedoch nicht das Einzige und auch nicht das Wichtigste. Aus diesem Grund soll hier weniger auf die Methoden an sich eingegangen werden – dafür gibt es eine Vielzahl von guten Büchern in der vorhandenen Prozessmanagementliteratur –,vielmehr soll der Fokus im Folgenden stark auf den Managementaspekt des Prozessmanagements, auf das wirkliche Managen der Prozesse gelegt werden. Was Management ist und nicht ist, ist in der Literatur ausreichend diskutiert und definiert und muss hier nicht im Detail wiederholt werden. Kurz zusammengefasst geht es im Konzept des Managements darum, ein Ziel zu haben und zur Erreichung dieses Ziels Ressourcen, Mitarbeiter, Geschäftspartner und andere Parameter so zu steuern, dass das jeweilige Ziel erreicht wird. Ein wesentliches Element dabei ist es, Dinge nicht selbst zu tun, sondern durch andere tun zu lassen. Management heißt damit, die Leistungserstellung durch andere zu planen, zu organisieren, zu unterstützen und zu steuern.281 Im Abschnitt 2.3.3 wurden hierfür zwei Steuerungsprozesse entwickelt: ein ergebnisorientierte Steuerungsprozess und ein normativer Steuerungsprozess. Im ergebnisorientierten Steuerungsprozess wird zuerst das Ziel genau definiert und eine Strategie zu seiner Erreichung entwickelt. Ist diese Strategie definiert, so muss sie auf handhabbare Phasen herunter gebrochen und organisiert werden. Auf Basis dieser werden den wesentlichen Beteiligten – Bereichen oder auch Managern und Mitarbeitern – Ziele geoder die Zertifizierung zum Process Manager und Senior Process Manager der Gesellschaft für Prozessmanagement, siehe http://www.prozesse.at/ sowie Wagner, Patzak (2007). 281 Vgl. dazu z. B. Bogaschewsky, Rollberg (1998), die im Rahmen ihres prozessorientierten Managements den Begriff Management Synonym mit Unternehmensführung verwenden und für die der Managementprozess folgende Grundtätigkeiten umfasst: Ziele erkennen, vereinbaren, konkretisieren und durchsetzen, Entscheidungen treffen, durchsetzen und koordinieren, Aufgaben und Zuständigkeiten delegieren und koordinieren, die Aufgabenerfüllung kontrollieren und Mitarbeiter motivieren (S. 29). Vgl. dazu auch den von der OMG zugrunde gelegten Managementbegriff bei Weilkiens, Weiss, Grass (2010), S. 19.

198

Managementverständnis von Prozessmanagement

setzt, die erreicht werden sollen. Die Erreichung dieser Ziele auf Bereichs- und auch auf Mitarbeiterebene – also die Performance – wird in regelmäßigen Abständen überprüft. Zeigt diese Überprüfung, dass die Teilziele der Perioden (z. B. Monate oder Quartale) erreicht werden, läuft alles nach Plan. Werden die Teilziele nicht erreicht, so müssen Maßnahmen gesetzt und Anpassungen vorgenommen werden. Auch für diese Maßnahmen muss die Umsetzung und vor allem ihre Effektivität hinsichtlich der Erreichung der ursprünglichen Ziele wieder überprüft werden. Werden die Teilziele damit erreicht, läuft wieder alles nach Plan. Werden sie nicht erreicht, sind neue Maßnahmen oder eine Anpassung der Phasen zur Erreichung des Ziels notwendig. In jedem Fall gehört es zum Prozess des Managements, die Lehren (lessons learned) aus den gesetzten Maßnahmen und dem Ausmaß ihres Erfolgs oder Misserfolgs zu ziehen. Bei erfolgreichen Maßnahmen gehört es weiters zum Steuerungsprozess, diese im Wissen des Unternehmens oder der Institution zu verankern und – falls möglich – auf andere Bereiche oder Segmente zu transferieren. Daneben wurde ein normativer Steuerungsprozess entwickelt, der die Einhaltung von für den Erfolg direkt oder indirekt notwendigen Regeln sicherstellt. In diesem Prozess müssen zu Beginn Regelungen erarbeitet, das heißt konzipiert, abgestimmt und beschlossen werden. Die erarbeiteten Regelungen werden in der Folge kommuniziert und geschult. Die Einhaltung der Regeln muss dann in den jeweiligen Leistungserstellungs- und Bereitstellungsprozessen erfolgen. Zur Kontrolle, ob dies auch in ausreichendem Maß der Fall ist, wird die Einhaltung der Regeln überprüft. Aus den Ergebnissen dieser Überprüfungen müssen wiederum Lehren gezogen werden, die zum Beispiel zu einer Überarbeitung der Regelungen, einer nochmaligen oder anderen Kommunikation oder Schulung derselben oder auch einer Anpassung der Überprüfungsroutinen führen können. Wenden wir diese Konkretisierung des Managementbegriffs auf das Prozessmanagement an, so heißt dies nichts anderes, als dass diese einzelnen Schritte auf die Prozessdimension des Unternehmens umgelegt und konkretisiert werden. Prozessmanagement hat damit grundsätzlich genau denselben Inhalt wie das generelle Management im Unternehmen, nur eben bezogen auf das Objekt der Geschäftsprozesse. Es bedeutet die echte Planung und Steuerung der Geschäftsprozesse eines Unternehmens oder einer Institution im Rahmen des generellen Prozesses der Unternehmenssteuerung, um bestimmte Ziele zu erreichen.282 282 Vgl. Becker, Kahn (2008, S. 8), für die Prozessmanagement der Planung, Steuerung und Kontrolle von inner- und überbetrieblichen Prozessen dient. Siehe auch Wagner (2001, S. 13), der in Anlehnung an die Definition des Begriffs Management nach Fayol die Planung, Organisation, Führung, Mittelbereitstellung, Kontrolle und Steuerung sowie die ständige Verbesserung als Elemente des Prozessmanagements sieht. Anknüpfend an die QM-Normen definiert Wagner in der Folge allerdings neben den Managementprozessen eigene Mess-, Analyse- und Verbesserungsprozesse – ein Ansatz, dem hier nicht gefolgt wird, da diese Teil des normalen Steuerungsprozesses sind. Für Österle (2010/ 1995) heißt Prozessmanagement das Setzen von Zielen für die Prozesse, die Messung der Ausführung

199


Prozessmanagement ist damit nicht gleichzusetzen mit der Modellierung der Geschäftsprozesse im Unternehmen und dem Aufbau und der Wartung der damit verbundenen Prozessmodelle. Ebenso ist es nicht identisch mit dem Aufbau von sogenannten Managementsystemen, die meist primär auf die Umsetzung und Erfüllung von bestimmten Normen – etwa im Qualitäts-, Umwelt-, Gesundheits- und Sicherheitsmanagement oder im Risikomanagement – abzielen und weniger auf ein echtes Managen der Prozesse.283 Dasselbe gilt für die isolierte Nominierung eines Zuständigen „Mr. oder Ms. Process“, also einer Person, die für das Prozessmanagement im Unternehmen nominiert wird und dieses wahrnehmen soll, ohne echte Verankerung der Prozessverantwortung in der Organisation und ohne echte Steuerungsfunktion. Auch Prozessdesign, Prozessoptimierung, Prozesskostenrechnung, Prozessmonitoring und Prozesscontrolling sind nicht gleichzusetzen mit Prozessmanagement. Vielmehr handelt es sich bei all diesen Konzepten um Elemente und Mittel des Prozessmanagements, die in seinem Rahmen eingesetzt werden und es bei bestimmten Fragestellungen unterstützen können. Zahlreiche Unternehmen und Institutionen haben in den letzten Jahren „Prozessmanagement eingeführt“ – nur in den allerwenigsten werden die Geschäftsprozesse jedoch entsprechend dem oben formulierten Verständnis tatsächlich gemanagt. Meist beschränkte sich die Einführung auf durchaus wohlgemeinte Initiativen zum Aufbau eines Prozessmodells oder blieb trotz weiter und umfassender gesteckter Zielsetzungen in diesem stecken. Da bei solchen Initiativen der Nutzen ausbleibt, werden viele auch wieder eingestellt.284 Manche Unternehmen sind über die reine Prozessmodellierung und -dokumentation inzwischen hinausgegangen und legen einen größeren Fokus auf die gezielte Optimierung von Prozessen. Ohne einen generellen Managementanspruch, wie in den beiden Steuerungsprozessen oben definiert, bleibt es jedoch auch hier bei punktuellen Initiativen ohne nachhaltige Verankerung – man kann daher auch in diesen Fällen nicht von einem echten Prozessmanagement sprechen. Diese nur bedingte Umsetzung von Prozessmanagement in der Realität liegt zu einem Teil in dem bereits angesprochenen Fokus auf die Entwicklung, Verbesserung und Schulung von methodischen Grundlagen begründet. Zum anderen haben sich viele Proponenten des Prozessmanagements in den letzten Jahren auch sehr stark an verschiedenen Normsystemen, insbesondere den ISO-Qualitätsnormen orientiert. Derart entwickelte und eingeführte Prozessmanagementsysteme fokussieren meist stark auf den normativen Steuerungsprozess und vernachlässigen den ergebnisorientierten Steuerungsprozess. Im Sinne des klassischen Managementverständnisses, demzufolge ein auf Basis ausgewählter Performanceindikatoren und der Vergleich mit den Zielwerten sowie das Machen von Vorschlägen für Verbesserungen (S. 19, S. 54, S. 105). 283 Für eine gute Übersicht relevanter Normen, für die Prozesse eine Rolle spielen, siehe z. B. Wagner, Patzak (2007), S. 355–356. 284 Rummler, Ramias, Rummler (2010), S. 14–15: Auch für sie ist die Modellierung von Geschäftsprozessen zu einer eigenen Industrie ausgeufert. Diese Fehlentwicklung wurde für sie durch Programme wie ISO 9001 ff. sowie CMMI und andere Reifegradmodelle noch angeheizt.

200

Managementverständnis von Prozessmanagement

Abb. 63: Isolierte Elemente des Prozessmanagements in der Praxis

Unternehmen zwar natürlich auch Normen befolgen, in erster Linie aber Ergebnisse erwirtschaften muss, kommt aber gerade dem ergebnisorientierten Steuerungsprozess die größere Bedeutung im Konzept des Managements zu. Auch bei solchen Prozessmanagementsystemen ist es daher nur sehr eingeschränkt zulässig von echtem Prozessmanagement zu sprechen. Wer selbst in einer Managementfunktion aktiv ist, weiß zudem, dass methodische Grundlagen zwar wichtig, keineswegs jedoch hinreichend sind. Management besteht neben methodischen Grundlagen vielmehr auch darin, Leadership zu zeigen: d. h. eine Vision zu haben, andere begeistern und überzeugen zu können, über eine gewisse Hartnäckigkeit und Durchhaltefähigkeit zu verfügen und andere in ihrem Verhalten beeinflussen zu können, teilweise über Motivation und Lob, teilweise aber auch über Kritik, Sanktion und gegebenenfalls harte Maßnahmen bis hin zur Trennung von Beteiligten. Manager sind deshalb nicht Personen, die es allen recht machen und zu allen nett sein wollen. Manager sind vielmehr extrem zielstrebige Personen, denen es gelingt, mit ihrem Wissen, ihren Methoden und Ansätzen in vieler Hinsicht aber vor allem durch ihre Autorität, ihr Charisma und ihren Willen andere dazu zu bringen, das zu tun, was zur Erreichung der gesteckten Ziele notwendig ist. Gute Manager sind keine Methodenexperten, sondern Machertypen mit klaren Zielen und großem Antrieb, etwas zu erreichen. Diese personenbasierte Dimension des Managements kommt im aktuell gelebten Prozessmanagement in vielen Unternehmen zu kurz und ist gegenüber der rein methodischen Kompetenz vielfach stark unterrepräsentiert. Auf Topebene, wo diese Eigenschaften gegeben wären, stehen Geschäftsprozesse und Prozessthemen meistens nicht im Fokus; auf den operativen Ebenen überwiegt hingegen meist der Methoden-

201


und Werkzeugfokus. Genau deshalb ist es so entscheidend, auf der Ebene unter dem Topmanagement die Process Owner zu installieren, als Bindeglied zwischen dem klaren Managementfokus und der operativen Umsetzung. Es wäre sicher deutlich erfolgsversprechender, Personen in zentrale Verantwortungen für Prozessmanagement zu nominieren, die nicht nur methodische Kenntnisse des Prozessmanagements, sondern vor allem auch diese grundlegenden Managementfähigkeiten mitbringen. Nur dann werden sie ihre Funktion so wahrnehmen, dass die Prozesse nicht nur dokumentiert und inkrementell verbessert sowie relevante Normen eingehalten und Zertifizierungen erreicht oder erneuert werden, sondern dass die Prozesse im Sinne des beschriebenen Managementverständnisses auch tatsächlich gesteuert und gemanagt werden und so einen Beitrag zur Integration und zur Gesamtperformance leisten. Im Folgenden soll daher Prozessmanagement in doppelter Hinsicht als Managementansatz entwickelt werden: einmal in Bezug auf das Managen des Prozessmanagements und zum Zweiten in Bezug auf ein echtes Managen der Prozesse.285 Der zweite Teil – das Managen der Prozesse – entspricht dabei den bereits vielfach etablierten Modellen der Prozessgestaltung oder des Process Lifecycles, jedoch mit einer deutlich stärkeren Akzentuierung des Managementaspekts und der Ziel- und Performanceorientierung. Dabei geht es nicht um eine kontinuierliche Verbesserung, bei der alle Prozesse generell immer weiter verbessert werden. Prozesse Managen als Managementansatz legt hier Ziele fest und optimiert dann die wesentlichen Prozesse auf diese Ziele hin, um eine Steigerung der Prozessperformance für diese operativ oder strategisch wichtigen Prozessaspekte zu erreichen; gleichzeitig hat dieses Verständnis damit auch einen „Mut zur Lücke“ wie es im Management wichtig ist: Es werden nicht alle Prozesse optimiert; ebenso wird nicht ständig verbessert; und es ist auch nicht erstrebenswert, bei allen Prozessen immer besser zu werden – bei manchen Prozessen reicht das aktuelle Performanceniveau aus, und es ist sinnvoller, die Ressourcen in andere Themen zu investieren als in weitere Verbesserungsschritte, die vielleicht nicht notwendig sind oder zumindest im Vergleich zu anderen Verbesserungen einen viel geringeren Hebel bringen. Der erste Teil – das Managen des Prozessmanagements – zielt demgegenüber auf die bewusste und zielorientierte Steuerung des Prozessnetzwerks und des gesamten Prozessportfolios im Unternehmen. Dazu zählen die Process Owner, die Prozessmanager und auch das zentrale Prozessmanagementteam sowie die Festlegung der generellen Schwerpunkte für die Arbeit an den Prozessen. Natürlich haben alle diese Rolleninhaber, wo es sie gibt, persönliche Ziel- und Entwicklungsgespräche. Nur in den wenigsten Fällen pas285 Gareis, Stummer (2008) sehen eine sehr ähnliche Unterscheidung in Macro- und Micro-Prozessmanagement. Das erstere befasst sich für sie mit dem Prozessportfolio, dem Aufbau von BPM Standards und der notwendigen Rollen wie Prozessmanager; Micro-Prozessmanagement bezieht sich für sie hingegen auf die Planung und Steuerung konkreter Prozesse. Für jeden Bereich werden von den Autoren spezifische Werkzeuge beschrieben und empfohlen. Demgegenüber geht es hier weniger um die jeweils eingesetzten Werkzeuge als vielmehr um den Managementanspruch auf beiden Ebenen, einmal für das Prozessmanagement als Ganzes und zum anderen in Bezug auf bestimmte wichtige Prozesse.

202

Managen des Prozessmanagements

sen diese jedoch zu einer kohärenten Zielsetzung des Prozessmanagements als Ganzes zusammen. Neben dem gezielten Managen der wesentlichsten Prozesse ist daher auch ein Managen des Prozessmanagements als solchem notwendig für den Erfolg von Prozessmanagement als echtem Managementansatz.

5.2 Managen des Prozessmanagements 5.2.1 Ziele des Prozessmanagements festlegen

Am Beginn der Einführung von Prozessmanagement steht die Festlegung der konkreten Ziele, die damit erreicht werden sollen. Das mag banal erscheinen, ist es jedoch nicht. Denn kaum ein betriebswirtschaftliches Konzept ist so breit in seiner Auslegung wie jenes des Prozessmanagements; mit kaum einem Managementansatz werden so unterschiedliche Vorstellungen und Erwartungen verbunden. So reicht das Spektrum der mit Prozessmanagement assoziierten Ziele von der Herstellung von Transparenz über die Abläufe, die Verbesserung bestimmter organisatorischer Schnittstellen, die Optimierung bestimmter Prozesse im Hinblick auf Zeit, Qualität oder Kosten, die stärkere Standardisierung und Harmonisierung und die Einführung von Prozesskostenrechnungssystemen bis hin zu einer radikalen Änderung der Organisationsstruktur oder der gesamten Wertschöpfung, der einfacheren Umsetzung von Anforderungen der Fachabteilungen in den IT-Applikationen, der Einführung von Workflowsystemen oder dem Erfüllen von bestimmten Zertifizierungen oder Compliancevorgaben. Der Grund für diesen breiten Interpretationsspielraum liegt zum einen im Konzept selbst: sagt doch Prozessmanagement nur, dass man sich bewusst um die Prozesse kümmert, diese steuert und gegebenenfalls verbessert, nicht jedoch im Hinblick worauf sie verbessert werden sollen. Zum anderen werden mit dem Konzept Prozessmanagement vielfach auch Inhalte verbunden, die sich teilweise mit ihm überlappen oder auch nur am Rande damit zu tun haben, jedoch – weil sie irgendwie auch die Prozesse betreffen – darunter subsumiert werden, um die positive Konnotation des Konzepts für diese Vorhaben zu nutzen.286 Würde man daher zehn verschiedene Manager fragen, warum sie Prozessmanagement einführen und was sie davon erwarten, so würde man mit größter Wahrscheinlichkeit ganz unterschiedliche Antworten auf diese Frage bekommen. Nicht anders wäre es, würde man die operativen Prozessmanager fragen.287 Aus diesem Grund ist es vor dem Start jeglicher Aktivitäten wichtig, die Erwartungen an das Prozessmanagement zu kennen, die Ziele des Prozessmanagements für das jeweilige Unternehmen klar festzulegen und diese auch zu kommunizieren. Als Mittel dafür hat 286 Vgl. dazu Osterloh, Frost (2000), die für das Konzept des Business Reengineerings in ähnlicher Weise festhalten, dass es nicht als „Allzweckwerkzeug“ beansprucht werden darf (S. 7). 287 Vgl. Hiller, Minar-Hödel, Zahradnik (2010), die ebenso herausstreichen, dass Unternehmen sehr unterschiedliche Erwartungen haben, wenn sie sich mit Prozessmanagement zu beschäftigen beginnen (S. 17).

203


es sich bewährt, Stakeholderinterviews mit den wichtigsten Managern und Betroffenen im Unternehmen zu führen. Hierbei kann ein Zieleportfolio hilfreich sein, das einen Überblick über die wichtigsten, mit dem Prozessmanagement verfolgbaren Ziele gibt. Anhand dieses Zieleportfolios kann sehr einfach eine Ist-Analyse über den aktuellen Status dieser möglichen Zieldimensionen durchgeführt werden. Ergänzend zum Ist-Stand wird auch die angestrebte kurz- und langfristige Zielposition in den betreffenden Dimensionen besprochen und aufgenommen. Kurzfristig heißt dabei, dass die betreffenden Ziele innerhalb von 12–18 Monaten erreicht werden sollen; langfristige Zielniveaus gelten auf einen Zeitraum von ca. 3 Jahren. Aus der Summe der Rückmeldungen und Inputs aus den Gesprächen ergibt sich so ein Zielportfolio, das deutlich macht, wo die Schwerpunkte des Prozessmanagements liegen sollen und was damit erreicht werden soll. Gleichzeitig werden hiermit auch manche Ziele niedrig priorisiert oder sogar ausgeschlossen, sodass auch klar ist, was mit dem Prozessmanagement nicht angestrebt werden soll.288 Zur Verdeutlichung der Ergebnisse sowie zur einprägsameren Kommunikation der angestrebten Zielsetzungen des Prozessmanagements empfiehlt es sich, die so festgelegte Zielposition auch in Form eines Zielbildes (Vision) für das Prozessmanagement auszuformulieren.289 Eine klar erarbeitete Zielsetzung für das Prozessmanagement ist eine saubere Grundlage für die Planung und Durchführung aller weitere Schritte und Arbeiten. Sie kann im Zuge aller weiteren Schritte und Aktivitäten immer wieder als Referenzrahmen herangezogen werden, etwa, wenn es darum geht, bestimmte Aktivitäten und Initiativen zu starten, bestimmte Methoden zu entwickeln oder auch unterstützende Tools mit bestimmten Funktionalitäten anzuschaffen. Unterbleibt die strukturierte und klare Festlegung der Zielposition für das Prozessmanagement, so werden Aktivitäten erfahrungsgemäß von manchen Beteiligten immer wieder infrage gestellt. In manchen Fällen wird sogar die Sinnhaftigkeit des Prozessmanagements generell wieder aufgegriffen und hinterfragt. Diese zeitraubenden und nicht wertstiftenden Diskussionen in der Umsetzung können vermieden werden, wenn die Ziele am Beginn sauber abgestimmt, vereinbart und kommuniziert werden. 5.2.2 Prozessmanagementstrategie festlegen

Ausgehend von diesem Zielbild muss die Prozessmanagement-Strategie erarbeitet werden, mit der das Zielbild erreicht werden soll. 288 Vgl. dazu auch Hiller, Minar-Hödl, Zahradnik (2010), die dasselbe Problem der unterschiedlichen Stakeholdererwartungen auch thematisieren und dafür eine ähnlich strukturierte Tabelle möglicher Motivationsfaktoren als Instrument zur Erhebung der Motivationen heranziehen (S. 82). 289 Vgl. dazu die Wichtigkeit der Formulierung einer Vision im Reengineering-Ansatz von Michael Hammer und James Champy. Hammer, Champy (1994), S. 212–217; ebenso Davenport (1993, S. 115–135).

204

Abb. 64: Schema für ein Prozessmanagement Zieleportfolio


Abb. 65: Beispiele für konkrete Prozessmanagement-Zieleportfolios

Hierfür muss einerseits analysiert werden, welche Veränderungen und Schritte notwendig sind, um das Zielbild zu erreichen. Ausgangspunkt dafür ist das Ergebnis der Stakeholderanalyse und dabei insbesondere das herausgearbeitete Delta zwischen der aktuellen Ausgangslage und dem Zielbild. Wird etwa dem Ziel Transparenz eine hohe Priorität gegeben, die Ist-Situation ist jedoch so, dass im Bereich Transparenz zwar ein Prozessmodell vorhanden jedoch nicht mehr ganz auf dem aktuellsten Stand ist und zudem neu hinzugekommene Geschäftsbereiche noch nicht abdeckt sind, so ergibt sich ein notwendiger Schwerpunkt in der Aktualisierung und Vervollständigung des Prozessmodells für den notwendigen Detaillierungsgrad. Oder ist zum Beispiel der Bereich Effizienzsteigerung von höchster Priorität, so gilt es, ein entsprechendes Vorgehen zur gezielten Optimierung der Effizienz von Prozessen einzuführen, im Unternehmen zu verankern und durch das zentrale Prozessmanagementteam zu unterstützen. Dies betrifft jedoch nur den instrumentellen Teil der Strategie zur Umsetzung. Ergänzend dazu muss andererseits auch der inhaltliche Fokus für die Aktivitäten festgelegt werden. Das heißt, es muss definiert werden, welche Prozesse vor allem im Fokus der Aktivitäten stehen sollen und welche nicht.290 Denn es wäre vom Standpunkt der dafür notwendigen Ressourcen unsinnig, alle Prozesse bis in das letzte Detail zu definieren und ebenso die Optimierungsziele auf alle Prozesse gleichermaßen anzuwenden.291 Ge290 Vgl. auch Davenport (1993), S. 29. 291 Vgl. dazu Nicolai (2009), S. 205: Auch sie verweist darauf, dass meist nicht alle Prozesse in eine Prozessanalyse einbezogen werden, sieht dies jedoch in der Begrenztheit finanzieller und personel-

206


Abb. 66: Über- und Unterorganisation in Bezug auf Geschäftsprozesse292

rade dieser allumfassende Anspruch, alle Prozesse ständig und immer weiter zu verbessern ist einer der wesentlichen Irrwege des vielfach etablierten Prozessmanagements, der dem Verständnis als echtem Managementansatz diametral widerspricht. Ganz im Gegenteil dazu sollen Prozessstandards, Prozessvorgaben und Prozessoptimierung dort eingesetzt und angewandt werden, wo dies im Sinne eines fokussierten Managementansatzes sinnvoll und zielführend ist, und wo im Hinblick auf die Performance des Unternehmens in seiner strategischen Entwicklung und im operativen Wettbewerbsumfeld der größte Hebel erzielt werden kann. Erfolgt dies zu wenig, so entsteht in Bezug auf die Ablauforganisation und die Prozesssteuerung eine Unterorganisation; das heißt, dass Potenziale in den Prozessen für eine verbesserte Gesamtperformance ungenutzt bleiben. Erfolgt es zu viel, indem zum Beispiel alle Prozesse gleichermaßen definiert und mit Kennzahlen gesteuert werden, so verfällt das Unternehmen in die klassische Form der Überorganisation293 oder Übersteuerung. ler Ressourcen begründet und nicht so sehr im konkreten Management- und Optimierungsbedarf der Prozesse. 292 In Anlehnung an die Darstellung bei Nicolai (2009), S. 11. 293 Vgl. dazu das Substitutionsprinzip von Gutenberg, das in der Organisationslehre lange etabliert ist (siehe z. B. Nicolai 2009, S. 11, Schreyögg 2006, S. 111), im Prozessmanagement jedoch bisher kaum berücksichtig wurde – eine Ausnahme stellen hier in gewisser Hinsicht Becker, Kugeler, Rosemann (2008, S. 47–49) dar, die in ihren Grundsätzen ordnungsgemäßer Prozessmodellierung über die Grundsätze der Relevanz und der Wirtschaftlichkeit ähnliche Aspekte berücksichtigen. Auch Klimmer (2007, S. 140) weist darauf hin, dass es weder möglich noch wirtschaftlich sei, alle Prozesse in einem Unternehmen permanent mit Prozesskennzahlen zu messen, beschränkt sich bzgl. der zu treffenden Auswahl jedoch nur sehr kurz auf die Wichtigkeit für die Anforderungen externer Kunden sowie für strategische Erfolgsfaktoren. Ein Beispiel für eine derartige Überorganisation ist etwa

207


Durch den mangelnden Managementfokus im Prozessmanagement finden wir in der Praxis derzeit beide Ausprägungen vor: In Unternehmen, die Prozessmanagement schon eingeführt haben und es für wichtig finden, erfolgt häufig eine Modellierung sämtlicher Geschäftsprozesse in mehreren Detaillierungsebenen; ebenso werden in weiterer Folge oft für alle Geschäftsprozesse Prozesskennzahlen festgelegt. Im Sinne des hier vertretenen Managementansatzes von Prozessmanagement ist dies eine klassische Form der Überorganisation in Bezug auf die Geschäftsprozesse. Anstatt zu einer besseren Integration und Steuerung führt dies eher zu einem Verlust an Fokus und Überblick. Andrew Spanyi bringt dies sehr treffend auf den Punkt: „When organizations attempt to measure far too many performance metrics it can lead to the company experiencing blurred vision, and this stands in the way of clarity and focus“.294 Die Folge ist häufig ein generelles Ignorieren der durch das Prozessmanagement festgelegten Prozessabläufe, -standards und -kennzahlen.295 Das Prozessmanagement führt dann ein paralleles Eigenleben neben dem normalen Geschäftsbetrieb. Weiters führt eine solche Überorganisation auch zu einem überhohen Aufwand für die Aktualisierung der Prozessdokumente und die Messung und Auswertung der Prozesskennzahlen. Ab einem gewissen Punkt kann es sein, dass dieser Aufwand als so überbordend empfunden wird, dass das komplette Prozessmanagement wegen des zu geringen Nutzens auf einmal wieder beiseitegeschoben und eingestampft wird. In Unternehmen, die dem Prozessmanagement noch immer skeptisch gegenüberstehen, finden sich hingegen meist nur sehr rudimentäre Regelungen über die Abläufe, die sich zum Beispiel auf Unterschriftenregelungen, Einkaufsvorschriften oder bestimmte Sicherheitsrichtlinien beschränken, während die Detailorganisation der Abläufe selbst den jeweiligen Prozessbeteiligten überlassen bleibt und damit vielfach unterschiedlich, ineffizient und ad hoc passiert. In diesem Fall liegt möglicherweise eine Unterorganisation der Geschäftsprozesse vor, mit der Folge, dass Effizienz- und Effektivitätsvorteile nicht gehoben werden können und die Geschäftsfälle meist sehr individuell und suboptimal abgewickelt werden. Dies äußert sich häufig in unklaren Zuständigkeiten, Schleifen in der Abarbeitung, Verschwendung von Ressourcen, erhöhtem Koordinationsaufwand im Einzelfall, hohen Prozesskosten und langen Durchlaufzeiten.296 Füermann, Dammasch (2008), die empfehlen, für jeden Prozess mehrere aussagekräftige Kennzahlen zu definieren (S. 64). 294 Spanyi (2007), S. 135. 295 Hier unterscheiden sich die Folgen von Überorganisation im Prozessmanagement von denen einer Überorganisation in der Aufbauorganisation oder bei Unternehmensrichtlinien. Während Regelungen in letzteren befolgt werden müssen und daher dann oft zu fehlender Motivation, Unflexibilität, fehlender Eigeninitiative etc. führen (siehe z. B. Nicolai 2009, S. 13), werden Regelungen im Prozessmanagement meist weniger als zwingende Vorgaben empfunden und daher vielfach einfach ignoriert. 296 Im Falle von Unterorganisation decken sich daher die Folgen in Bezug auf die Prozesse mit jenen, die auch in anderen Bereichen der Organisation beobachtet werden (vgl. Nicolai 2009, S. 13).

208


Abb. 67: Prozessmanagementziele und Prozessfokus

Was die Auswahl der Prozesse, die im Fokus des Prozessmanagements stehen sollen, betrifft, so können Prozesse aufgrund operativer oder auch strategischer Überlegungen hierfür selektiert werden. Aus operativer Sicht wird der Schwerpunkt dort zu legen sein, wo die größten Optimierungspotenziale im Hinblick auf die gesetzten Ziele zu finden sind.297 Ist das Ziel also etwa vor allem, Transparenz zu schaffen, so werden jene Prozesse ausgewählt, zu denen es bei den Prozessbeteiligten das wenigste Überblickswissen, wenig Kenntnis über die Zusammenhänge und auch die wenigste Dokumentation gibt. Liegt die Erwartung hauptsächlich auf einer Effizienzsteigerung, so werden vor allem jene Prozesse ausgewählt, bei denen die meisten Ressourcen gebunden sind und wo die Einschätzung der Beteiligten größere Ineffizienzen vermuten lässt. Liegt der Fokus hingegen auf einer Qualitätssteigerung, so werden vor allem jene Prozesse in das Arbeitsprogramm aufgenommen werden, bei denen es häufig zu Ausschuss, Fehlern oder Reklamationen kommt und wo diese aus Kundensicht besonders kritisch sind. Aus strategischer Sicht werden die Teilprozesse, die hauptsächlich im Fokus liegen sollen, aus der Unternehmensstrategie abgeleitet. Das heißt, es wird ausgehend von der definierten Strategie überlegt, was die einzelnen Ziele und Elemente der Strategie für die identifizierten Prozesse des Unternehmens bedeuten; im ersten Schritt werden dabei jene Prozesse herausgefiltert, denen für die Umsetzung der strategischen Ziele besondere Relevanz zukommt. Hat ein Unternehmen etwa regionale Expansionspläne 297 Die EABPM spricht in diesem Zusammenhang von Process Portfolio Management (EABPM 2009, S. 221).

209


Abb. 68: Strategic Process Alignment Matrix von Horváth & Partners298

und nur einen Produktionsstandort so kommt unter Umständen den Logistik- und Distributionsprozessen erhöhte Relevanz für die weitere Expansion zu; ist der Aufbau eines zweiten Produktionsstandorts Teil der Expansionsstrategie, so bekommen die Standardisierung der Produktionsprozesse und ein übergreifender Planungsprozess zentrale Bedeutung aus der Strategie heraus. Im zweiten Schritt wird analysiert, wie weit diese für die Strategie besonders relevanten Teilprozesse der Prozesslandschaft für das Erreichen der strategischen Ziele bereits entsprechend ausgestaltet sind. Das heißt, ob ihre Prozessperformance ausreicht, um die strategischen Ziele entsprechend zu unterstützen oder ob hier gegebenenfalls Optimierungsbedarf besteht. Dabei wird auch überprüft, ob der Fokus der Prozesse und ihre Priorität in der operativen Abwicklung mit den Anforderungen aus der Strategie übereinstimmen.299

298 Quelle: Horváth & Partners. 299 Vgl. dazu auch Fischermans (2006), S. 20–22. Fischermanns unterscheidet im Gegensatz zum hier beschriebenen Vorgehen eine deduktive und eine induktive Vorgehensweise, wobei er der ersteren die Realisierung größerer Veränderungen zutraut. Der Ansatz, das Unternehmensprozessmodell deduktiv aus der Strategie zu entwickeln wir jedoch hier als zu theoretisch gesehen, denn in den wenigsten Fällen ist ein Unternehmen bereit, sein Prozessmodell komplett wegzuwerfen und aus der Strategie heraus neu zu entwickeln. Der hier vorgestellte Ansatz eines Matchens der Strategie mit den bestehenden Prozessen ist hier realistischer und zielführender, zumal auch hiermit größere Änderungsbedarfe aufgezeigt und initiiert werden können. Vgl. dazu auch Hammer (1997): Für ihn ist eine Strategie ohne die für die Umsetzung erforderlichen Prozesse nicht mehr „als eine Litanei schöner Worte“ (S. 135).

210


Abb. 69: Commodity und Intelligence Prozesse (Horváth & Partners)

Um diese Schwerpunkte des Prozessmanagements aus der Strategie heraus zu ermitteln, werden die Prozesse aus dem Prozessmodell den strategischen Zielen des Unternehmens gegenübergestellt. In der so entstehenden Matrix kann auf einfache Weise erarbeitet werden, welchen Prozessen für die Erreichung der Strategie eine hohe Relevanz zukommt. Im zweiten Schritt wird evaluiert, ob die Prozesse im derzeitigen Status die für die Strategieumsetzung notwendigen Anforderungen bereits erfüllen oder ob Handlungs- und Verbesserungsbedarf besteht.300 Konkrete Verbesserungspotenziale im Hinblick auf die Strategie können dabei auch gleich aufgenommen und für die weitere Festlegung des Arbeitsprogramms gespeichert werden. Um die angesprochenen strategischen Aspekte für das differenzierte Managen der Geschäftsprozesse einzubeziehen, ist es auch sinnvoll, die einzelnen Teilprozesse zusätzlich noch nach ihrer strategischen Relevanz zu kategorisieren. Eine der wichtigsten Einteilungen ist dabei jene in Prozesse, die für das Unternehmen strategisch wichtig sind und jene, für die dies nicht zutrifft. In der Praxis hat sich hierzu die Unterscheidung der Prozesse in Intelligence- und Commodity-Prozesse bewährt: Commodity-Prozesse sind Prozesse, bei denen keine Notwendigkeit zur Differenzierung vom Wettbewerb besteht; sie sind meist nicht spezifisch für die jeweilige Branche oder das jeweilige Geschäftsfeld, sondern sind vielfach Prozesse, die sich in vielen oder allen Branchen finden. In den meisten Fällen handelt es sich dabei um Bereitstel300 Vgl. dazu auch Currle, Schwertner in Horváth & Partners (2005), S. 29–34. Auch Hiller, MinarHödl, Zahradnik (2010) streichen heraus, dass jedes Unternehmen regelmäßig hinterfragen sollte, inwiefern seine Prozesse zur strategischen Ausrichtung passen (S. 84).

211


lungsprozesse oder auch um notwendige Teilprozesse, die diese unterstützen, jedoch nicht leistungsspezifisch sind, z. B. Lieferungs- oder Fakturierungsprozesse. Meist weisen Commodity-Prozesse auch eine hohe Wiederholfrequenz auf. Demgegenüber sind Intelligence-Prozesse notwendig für die Differenzierung vom Mitbewerb und stellen häufig einen Teil der Einzigartigkeit des jeweiligen Unternehmens dar (unique selling proposition – USP). Sie sind in den meisten Fällen spezifisch für die Branche oder das jeweilige Geschäftsfeld und kritisch für den Erfolg des Unternehmens, entweder weil sie den Kern der Leistungserstellung ausmachen oder aber, weil sie erfolgskritische Steuerungs- oder Bereitstellungsaktivitäten umfassen. Während es bei Commodity-Prozessen häufig Industriestandards gibt, die verfügbar sind und an denen man sich orientieren kann, gilt dies nicht für Intelligence-Prozesse: Sie sind unternehmensindividuell, einzigartig und häufig auch ein gut gehütetes Unternehmenswissen. Alternativ zur Kategorie der Intelligence-Prozesse haben sich auch die Begriffe Schlüsselprozesse und Kernprozesse301 etabliert, die im Wesentlichen mit dieser deckungsgleich sind. Werden alle identifizierten Teilprozesse auf den oberen drei Ebenen des Prozessmodells in diese beiden Gruppen eingeteilt, so können später beim Managen der Prozesse differenzierte Ziele und Maßnahmen für die Prozesse im Fokus gesetzt werden. So werden etwa für Commodity-Prozesse häufig Effizienz- und Kostenziele im Vordergrund stehen, während bei Intelligence-Prozessen (oder Schlüsselprozessen) eher Steuerungsaspekte und die strategische Weiterentwicklung im Fokus sind. Dies kann in der Folge auch für weiter gehende Aktivitäten als brauchbares Raster herangezogen werden, etwa wenn es darum geht, wo und wie weit standardisiert werden soll, wo Investitionen in die Weiterentwicklung von unterstützenden IT-Systemen getätigt werden sollen oder wo man versucht, bestehende, historisch gewachsene Komplexitäten eventuell sogar wieder auf branchenübergreifende Standards rückzubauen. Rein praktisch kann die Kategorisierung in die beiden Gruppen im Prozessmodell durch unterschiedliche Einfärbung oder z. B. durch Anbringen eines Schlüsselsymbols bei den Intelligence-Prozessen erfolgen und so gleich auf den ersten Blick zeigen, um welche Art von Prozessen es sich jeweils handelt. Es soll jedoch nicht der Eindruck vermittelt werden, dass Prozessmanagement nur der Strategieumsetzung und der Optimierung des operativen Geschäfts dient. Vielmehr kann Prozessmanagement über Prozessinnovationen durchaus auch einen wertvollen Beitrag zur Strategieentwicklung leisten.302 Wenn man die erfolgreichsten 301 Vgl. Gaitanides (2007), S. 138, ebenso S. 146, der den Begriff Kernprozess verwendet; detto Schmelzer, Seselmann (2010), S. 98–99; siehe auch Wagner, Patzak (2007), die den Begriff „Schlüsselprozesse“ benutzen (S. 66). Becker, Kugeler, Rosemann (2008) verwenden ebenso den Begriff „Kernprozess“, jedoch in einer anderen Bedeutung: Für sie ist ein Kernprozess „ein Prozess, dessen Aktivitäten direkten Bezug zum Produkt eines Unternehmens besitzen und damit einen Beitrag zur Wertschöpfung im Unternehmen leisten“ (S. 7). 302 Vgl. dazu auch Knuppertz (2009), S. 179–181, der ebenso die Bedeutung des Prozessmanagements für die Strategie und das Geschäftsmodell von Unternehmen herausstreicht. Ebenso Hammer

212


Unternehmen des letzten Jahrzehnts analysiert, so sind darunter viele, die aufgrund einer bestimmten Produktinnovation erfolgreich waren. Daneben finden sich aber auch zahlreiche Beispiele, wo es Unternehmen mit bereits etablierten Produkten rein durch Prozessinnovationen bzw. innovative Prozessmodelle an die Spitze geschafft haben: So hat amazon.com nicht das Buch und Dell nicht den Computer revolutioniert; beide haben jedoch die neuen Möglichkeiten der Technik genutzt, um bereits etablierte Produkte über ganz neue Prozessmodelle zu vertreiben. Ähnlich ist es mit Ikea: Auch das bekannte Möbelhaus hat nicht die Möbel an sich neu erfunden, sondern auf der Idee, den bis dahin für notwendig befundenen Teilprozess der Montage wegzulassen, ein neues Geschäftsmodell entwickelt. Prozessmanagement kann daher sehr wohl auch einen wichtigen, in manchen Fällen sogar entscheidenden Beitrag zur Strategieentwicklung leisten. Das vielfach in Anlehnung an das Statement von Alfred Chandler vorgebrachte Argument „process follows strategy“303 trifft daher nur bedingt zu. Denn wie die genannten Beispiele zeigen, ist die Beziehung zwischen Strategie und Geschäftsprozessen keine Einbahnstraße, sondern verläuft in beide Richtungen: natürlich müssen die Geschäftsprozesse – wie gezeigt wurde – mit der Strategie in Einklang gebracht und nach dieser ausgerichtet werden. Darüber hinaus können neue, innovative Geschäftsprozesse aber wiederum ebenso Inputs für die Strategie geben und das Geschäftsmodell weiter entwickeln. Das Prozessmanagement ist damit nicht nur Erfüller der Strategie, es kann auch ein wesentlicher Mitgestalter sein. Gerade die Schaffung innovativer Prozesse und spezieller, im Wettbewerb hinsichtlich Zeit, Kosten und Qualität überlegener Ablaufstrukturen kann Kernkompetenzen schaffen, die ein essenzieller Bestandteil der Strategie sind.304 Gerade in der Unternehmenspraxis kommt dieser Aspekt vielfach zu kurz. Prozessmanagement wird hier meist als reine Optimierung der bestehenden Abläufe gesehen und in das Operations-Eck geschoben, während sich andere um die Weiterentwicklung der Strategie kümmern.305 Wird Prozessmanagement wie hier dargestellt als echter Managementansatz verstanden, so wird auch diese Dimension aktiv genutzt. Intelligentes Prozessmanagement bezieht daher die Process Owner und das zentrale Prozessmanagement in den Strategieprozess ein.

(1997), der hierzu verschiedene Möglichkeiten der Strategiegestaltung aus den Prozessen anführt (S. 251–257). 303 Siehe z. B. Osterloh, Frost (2000), S. 37. 304 Vgl. dazu Bogaschewsky, Rollberg (1998, S. 200–203), die ebenso die Beziehung zwischen Strategie und Prozessen nicht als Einbahnstraße, sondern mehr als Interdependenz sehen, insbesondere wenn nicht ein marktorientierter, sondern ein ressourcenbasierter Strategieansatz zugrunde gelegt wird. 305 So war 2009 lt. dem BPTrends-Report „The State of Business Process Management – 2010“ nur in 19% das Topmanagement aus strategischen Gründen am Geschäftsprozessmanagement interessiert; dies bedeutete sogar einen Rückgang gegenüber 2007 (26%) und 2005 (28%). Wolf, Harmon (2010), S. 14.

213


Abb. 70: Zielkonkretisierung für das Prozessmanagement mittels einer Prozessmanagement Scorecard

In Summe legt die Prozessmanagementstrategie den Veränderungsbedarf zur Erreichung des Zielbildes fest, und zwar sowohl was die instrumentelle Verankerung des Prozessmanagements als auch was den Fokus auf bestimmte Prozesse betrifft.306 Sie wird von den Prozessmanagern gemeinsam unter Führung und Moderation des zentralen Prozessmanagementteams erarbeitet und schließlich vom Process Board beschlossen und freigegeben. Zur klaren Formulierung und Kommunikation der Prozessmanagementstrategie sowie zur Verfolgung des Fortschritts in ihrer Umsetzung können etablierte Instrumente wie etwa eine Balanced Scorecard verwendet werden. Damit ist die Strategie für das Prozessmanagement klar festgelegt und für alle Beteiligten nachvollziehbar. Sie kann einfach und verständlich kommuniziert werden, und auch der Fortschritt in der Umsetzung ist transparent überprüfbar. 5.2.3 Planung für das Prozessmanagement erstellen

Die Strategie deckt üblicherweise einen Zeithorizont von ca. 3 Jahren ab und ist nur mit einer groben Zeitleiste im Sinne einer Prozessmanagement Roadmap hinterlegt. Zur erfolgreichen Realisierung ist es daher notwendig, die in dieser Roadmap vorgesehenen Vorhaben auf ein Jahresprogramm herunter zu brechen und mit entsprechenden Ressourcen und Budgets zu konkretisieren.307 306 Vgl. Hiller, Minar-Hödl, Zahradnik (2010), die ebenso den Fokus im Prozessmanagement herausstreichen und am Beginn festlegen, welche Prozesse im Rahmen der Zielsetzung zuerst betrachtet werden müssen; diese werden von ihnen als „Fokusprozesse“ bezeichnet (S. 91). 307 Vgl. dazu das Element des Policy Deployments im Kaizen-Ansatz, bei dem die Geschäftsleitung zu Jahresbeginn die zu verfolgenden Ziele formuliert, wobei diese neben den generellen Unterneh-

214


Die in der Prozessmanagementstrategie festgelegten Projekte und Maßnahmen werden daher zeitlich im Detail geplant und priorisiert. Ebenso werden sie für die Umsetzung konkretisiert und in Teilschritte und Meilensteine detailliert. So entsteht ein detailliertes Jahresprogramm für die Aktivitäten des Prozessmanagements. Dieses Jahresprogramm umfasst · · · · ·

die geplanten Projekte zur Prozessoptimierung geplante Erweiterungen oder Aktualisierungen des Prozessmodells vorgesehene Prozess Audits und Prozessanalysen Trainingsmaßnahmen im Prozessmanagement und alle weiteren geplanten Maßnahmen im Prozessmanagement

Das Jahresprogramm muss in der Folge mit den zur Umsetzung notwendigen Ressourcen und Budgets hinterlegt und ausgestattet werden. Insofern sollte die Jahresplanung des Prozessmanagements analog zur Planung von Projekten Teil des jährlichen Planungsprozesses sein. Damit ist sichergestellt, dass die notwendigen Mittel für die Umsetzung vorgesehen sind. Ist dies gegeben, so können gleichzeitig auch die notwendigen Investitionen für Prozessanpassungen und die geschätzten Effekte des Prozessmanagements auf Umsatz und Kosten, insofern sie schon soweit konkretisierbar sind bzw. in der zu diesem Zeitpunkt möglichen Genauigkeit, ebenfalls in die Planung einfließen. Typischerweise werden realisierte Effekte aus Prozessoptimierungsmaßnahmen dabei zeitlich versetzt eingeplant, da sich auch Prozessverbesserungen im operativen Betrieb erst einschwingen müssen. Ebenso können durch Prozessverbesserungen wegfallende Personal- oder Sachkosten meist nicht sofort am Tag eins realisiert werden, sondern bedürfen einer gewissen Übergangszeit für ihre Realisierung. Meist ist dafür eine zeitliche Verzögerung von ca. 6 Monaten realistisch. Die notwendige Ressourcenausstattung hängt dabei natürlich vom Umfang der geplanten Aktivitäten ab. Sofern keine großen Programme für Prozessänderungen, Integrationsvorhaben oder größere IT-Vorhaben geplant sind, reicht fürdie normalenAktivitäten im Prozessmanagement ein Prozessmanager je Bereich aus. Dieser sollte erfahrungsgemäß ca. 50–60% seiner Zeit für Prozessmanagementaufgaben zur Verfügung haben, damit wirklich etwas bewegt werden kann. Im zentralen Prozessmanagementteam finden sich in der Praxis je nach Unternehmensgröße Teams zwischen 1–3 bei mittleren und 10–20 Mitarbeitern bei Großunternehmen. Als ungefährer Richtwert kann man etwa von 0,5 bis 1 FTE im zentralen Prozessmanagement je 1000 Mitarbeiter des Gesamtunternehmens ausgehen. In dieser Größenordnung rechnet sich diese Investition bei entsprechender Steuerung für das Unternehmen. menszielen auch Ziele umfassen, die die Verbesserung des Unternehmens durch Kaizenmaßnahmen betreffen. Teufel (2009), S. 679. Vgl. auch Spanyi (2007), der in diesem Zusammenhang von einem „process management plan“ spricht (S. 65).

215


Auch die generelle Roadmap und das konkrete Jahresprogramm werden analog zur Prozessmanagementstrategie von den Prozessmanagern unter Führung und Moderation des zentralen Prozessmanagementteams erarbeitet und dann vom Process Board beschlossen und freigegeben. Sofern Änderungen oder Ergänzungen im Prozessmanagementnetzwerk notwendig sind, sollten auch diese in diesem Zusammenhang durchgeführt werden. Hierunter fallen etwa die Nominierung neuer Process Owner, das Einfordern der Nominierung neuer Prozess Manager, dort wo es Änderungen gegeben hat, sowie eventuelle Änderungen oder Nachbesetzungen im zentralen Prozessmanagement Team. Auch das Terminieren der Process Board Meetings für das Jahr sowie der Process Manager Meetings sollte im gleichen Zeitraum erfolgen, um eine frühzeitige Planung zu unterstützen. 5.2.4 Zielvereinbarungen festlegen

Für den Erfolg des Prozessmanagements im Unternehmen ist das Commitment des Managements absolut entscheidend. Anders formuliert: Prozessmanagement ist etwas, was nur von oberster Stelle des Topmanagements beschlossen und intern beauftragt werden kann. Dies deckt sich auch mit dem generellen Verständnis des Organisationsdesigns, das ebenso als zentrale Aufgabe des Topmanagements gesehen wird. Zwar können Initiativen für Prozessmanagement auf niedrigeren hierarchischen Ebenen durchaus auch positive Effekte bringen.308 Ein wirkliches End-to-End-Prozessmanagement als Managementansatz mit entsprechender Prozessverantwortung, wie dies weiter oben beschrieben wurde, ist jedoch nur durch Entscheidung des Topmanagements möglich. Insofern kommt dem Commitment auf der obersten Ebene im hier verwendeten Prozessmanagementverständnis eine zentrale Bedeutung zu.309 Entscheidend ist jedoch, dieses Commitment auch auf die darunter liegenden Ebenen weiter zu geben. Hier trägt zum einen die aktive Einbeziehung der beteiligten Process Owner und Process Manager im Prozessnetzwerk bei. Zur Sicherstellung der effektiven Umsetzung sollten diese Rollenverantwortungen und die vereinbarten Ziele für das Prozessmanagement aber auch in den Zielvereinbarungen der betreffenden Manager und Mitarbeiter verankert werden: in den Zielvereinbarungen der Process Owner auf der Ebene unter dem Vorstand, durch diese in den Zielvereinbarungen

308 Vgl. dazu BPM Maturity Model EDEN e.V. (2009, S. 9 f.). Das Modell EDEN bietet auf Basis seiner Positionierungsmatrix insbesondere auch Wege, wie man von einem bottom-up getriebenen Prozessmanagement zu einem Top-down-Prozessmanagement mit Commitment des Topmanagements gelangen kann. Im Reengineering-Ansatz wird ein Bottom-up-Vorgehen hingegen a priori ausgeschlossen, vgl. Hammer, Champy (1994), S. 284. 309 Vgl. dazu auch BPM Maturity Model EDEN e.V. (2009, S. 20), wo zwar auch Wege eines Prozessmanagements ohne Commitment des Topmanagements reflektiert werden, aber ebenso die Ansicht vertreten wird, dass dieses ab einem gewissen Grad notwendig ist.

216


der Prozessmanager in den einzelnen Bereichen sowie auch in den Zielvereinbarungen des zentralen Prozessmanagements.310 Die Erfahrung lehrt: Was in die Zielvereinbarungen Eingang findet, passiert. Insofern sollte dieses hoch effektive Instrument auch für das Prozessmanagement zum Einsatz kommen, sofern Prozessmanagement als Managementinstrument eingesetzt werden soll. Es ist klar, dass gerade für die Process Owner die Ziele aus dem Jahresprogramm für das Prozessmanagement für sich genommen nicht immer die höchste Priorität und Gewichtung unter den Zielen haben werden. Wenn sie jedoch wie dargestellt aus den strategischen und operativen Zielsetzungen abgeleitet werden, spielen sie meist mit den anderen definierten Zielen der Manager zusammen. Damit ist auch bei geringerer Gewichtung eine entsprechende Unterstützung gegeben. Und dort, wo dies nicht der Fall ist, zeigt die Praxis, dass durchaus auch weniger gewichtete Ziele einen entsprechenden Fokus bekommen, sofern sie nur überhaupt in der Zielvereinbarung festgeschrieben sind. Denn gerade, wenn größere Geschäftsziele nicht vollumfänglich erreicht werden können, werden die betroffenen Manager danach trachten, sich zumindest in den von externen Faktoren weniger abhängigen Nebenzielen keine Blöße zu geben. Die Integration der Ziele des Jahresprogramms für das Prozessmanagement in die individuellen Zielvereinbarungen der beteiligten Manager im Prozessnetzwerk ist daher ein ganz wesentliches Element für eine nachhaltige Verankerung und erfolgreiche Umsetzung der beschlossenen Maßnahmen. 5.2.5 Performance des Prozessmanagements monitoren und analysieren

Analog zu anderen Zielen in Zielvereinbarungen werden auch die Ziele des Prozessmanagements regelmäßig überprüft. Dies kann auf Basis der definierten Prozessmanagement Scorecard sowie auf Basis des vereinbarten Jahresprogramms mit den festgelegten Budgets und abgeschätzten Effekten erfolgen. Zeitlich ist diese Einschätzung dabei in die jeweiligen Reportingzyklen zu integrieren, sodass die Zielerreichung genauso wie bei anderen Themen etwa quartalsweise oder halbjährlich überprüft und notfalls gegengesteuert wird. Ein Statusbericht über den aktuellen Stand der Zielerreichung und Budgetausnutzung sollte einmal im Quartal fixer Bestandteil der Agenda im Process Board sein. Für die Abschätzung der erzielten qualitativen Effekte können dabei Rückmeldungen der Fachbereiche oder – wo konkret anwendbar und entsprechend auf die wirklichen Prozessaspekte detailliert – auch der Kunden direkt herangezogen werden. Alternativ kann die Leistung des Prozessmanagements auch in eine interne Servicezufriedenheitsanalyse integriert werden, falls so etwas bereits durchgeführt wird. Für die Abschätzung der quantitativen Effekte ist hingegen eine entsprechende Kennzahlenerhebung oder -messung notwendig. 310 Vgl. dazu Werkzeug 7 von Michael Chang, der rät, Prozessverbesserungen mit Bonuszahlungen und Auszeichnungen zu verbinden (zit. in Weilkiens, Weiss, Grass (2010), S. 61.

217


Abb. 71: Prozesskosten als Mittel zum Tracken von Benefits bei veränderlichen Mengen

Wo quantitative Effekte über Kosteneinsparungen oder Effizienzsteigerungen definiert sind, ist die Entwicklung eines Benefit Trackings gemeinsam mit dem Controlling erforderlich. Hierbei werden Standards benötigt, nach denen Wirtschaftlichkeitsberechnungen von Projekten und Maßnahmen abgeschätzt und vereinbart werden. Zu diesem Zweck haben viele Unternehmen bereits entsprechende Projektantrags- und Bewilligungsprozesse, die derartige Wirtschaftlichkeitsabschätzungen beinhalten. In vielen Fällen stellen diese jedoch zu sehr auf die Berechnung von entsprechenden Profitabilitätskennzahlen und die damit verbundenen Aspekte wie Abzinsung, CashFlow-Wirksamkeit etc. ab, verstehen sich primär als Instrumente der einmaligen Entscheidungsunterstützung und vernachlässigen demgegenüber die wirkliche Nachvollziehbarkeit und Wiederauffindbarkeit der erzielten Effekte in den Ergebnisberichten. Insofern ist bereits bei der Abschätzung der Profitabilitäts- und Effizienzeffekte darauf zu achten, wo und wie diese nach erfolgter Realisierung nachvollzogen und überprüft werden können. Bei harten Einsparungseffekten, wie etwa dem Abbau von Mitarbeitern oder dem Wegfall von Sachkosten, die einem Prozess direkt zurechenbar sind, ist dies meist rein auf Basis von Kostenstellenberichten und Personalberichten transparent nachvollziehbar. In vielen Fällen wird mit einer Optimierung von Prozessen jedoch ein Effizienzgewinn erzielt, der nicht direkt zu einem solchen Mitarbeiterabbau oder Kostenwegfall führt. Vielmehr wird es durch die Prozessoptimierung möglich, dass mit gleichbleibender Mitarbeiteranzahl zunehmende Mengen von Geschäftsfällen bearbeitet werden oder aber Mitarbeiterressourcen wieder für andere Tätigkeiten frei werden und so zur Agilität des Unternehmens im Markt beitragen können. Zum Nachvollziehen von solchen Effizienzgewinnen ist eine Prozesskostenrechnung das ideale Instrument. Liegen die Effizienzgewinne vor allem im Bereich der Personalkapazitäten

218


so muss dabei nicht mit Vollkosten gerechnet werden, sondern kann sich die Überprüfung auch pragmatisch auf die reinen Personalkapazitäten im Sinn von Vollzeitmitarbeiteräquivalenten (FTE) beschränken. Die Prozesskostenrechnung ist damit nicht nur ein Werkzeug des Controllings für verschiedene andere Zwecke – wie etwa prozesskostenbasierte Leistungsverrechnung, Preisgestaltung oder Kundenprofitabilitätsrechnung –, sondern sie ist für das Prozessmanagement vor allem auch ein zentrales Element zum Nachvollziehen und zur Überprüfung seiner Wirksamkeit im Hinblick auf angestrebte Kosten- und Effizienzeffekte aus der Prozessoptimierung. 311 Dabei hilft sie insbesondere, Effizienzgewinne in einem dynamischen Umfeld der Geschäftsentwicklung und der Aufbauorganisation immer noch nachverfolgen zu können. Denn wenn etwa parallel zu Optimierungsaktivitäten in den Prozessen auch organisatorische Änderungen stattfinden oder aber von den entsprechenden Bereichen und Abteilungen neue Leistungen und Produkte gelauncht werden, sind Optimierungseffekte rein über die aufbauorganisatorische Sicht – sprich Kostenstellen und Personalstand – nicht mehr bzw. nur mehr mit einem nicht vertretbar hohen Aufwand und einer dennoch relativ hohen verbleibenden Unsicherheit nachvollziehbar. Durch den Shift der Sichtweise auf die Prozesse ist dies mit dem Mittel der Prozesskostenanalyse selbst in einem dynamischen organisatorischen Umfeld immer noch mit einer relativ guten Validität möglich. Sinnvollerweise erfolgt die Überprüfung der Zielerreichung im Prozessmanagement anhand der vereinbarten Prozessmanagementstrategie und des verabschiedeten Jahresprogramms für das Prozessmanagement quartalsweise im Process Board. Hier wird die Abarbeitung der geplanten Maßnahmen überprüft, der notwendige Mitteleinsatz überwacht und die Ausrichtung aller Aktivitäten an den angestrebten Zielsetzungen sicher gestellt. Wie im normalen Managementprozess so gilt auch hier: zeigt sich während des Jahres, dass der vereinbarte Jahresplan nicht erfüllt werden kann oder die daraus erwarteten Effekte nicht realistisch sind, so sind Korrekturen vorzunehmen. Auch für diese Korrekturmaßnahmen muss wiederum die Wirksamkeit überprüft werden. Spätestens am Ende des Jahres sollten die Lehren aus dem gewählten Vorgehen und den durchgeführten Prozessmanagementaktivitäten im Rahmen eines Lessons Learned Workshops gezogen werden. Ziel ist es dabei einerseits, die Planung und Zielsetzung im nächsten Jahr noch zu verbessern; andererseits geht es auch darum, erfolgreiche Vorgehen und Maßnahmen in der Wissensbasis zu verankern und – falls möglich – auf andere Bereiche zu transferieren. Zur generellen Einschätzung des Fortschritts im Prozessmanagement kann dabei in größeren zeitlichen Abständen auch ein Prozessreifegrad-Assessment der Organisation eine sinnvolle Bewertung über den erzielten Fortschritt bringen. Auf Basis von 311 Vgl. dazu Horváth & Partner (1998). Für den Unterschied zwischen dem Ansatz der Prozesskostenrechnung und jenem des Activity Based Costing siehe Gaiser (1998).

219


etablierten Reifegradmodellen wie etwa CMMI, Spice/ISO 15504 oder EDEN312 können dabei auch ganze Organisationen und der Status ihres Prozessmanagements einer solchen Bewertung unterzogen werden. Dabei sind jedoch im Sinne des hier vertretenen Managementansatzes wiederum zwei wesentliche Anmerkungen zu treffen: ·

·

Zum Ersten ist nicht der absolute Reifegrad des Prozessmanagements einer Organisation maßgeblich, sondern das Delta zwischen dessen Ist-Einschätzung und dem angestrebten Soll-Niveau.313 Gut ist also nicht ein Unternehmen, das in allen Bewertungsdimensionen den höchsten Reifegrad erreicht hat – ganz im Gegenteil. Gut ist jenes Unternehmen, das dem angestrebten Reifegrad möglichst nahe kommt, ohne diesen jedoch zu übertreffen. Hier muss über einen Zeitraum von drei Jahren ein klarer Fortschritt ersichtlich sein, sprich das Delta muss signifikant kleiner werden. Um hier allzu positive Selbsteinschätzungen zu vermeiden, können gerade externe Assessments eine objektivere Bewertung sicher stellen. Zum Zweiten müssen derartige Reifegradassessments mit einer klaren Zielsetzung der Verbesserung erfolgen und ohne dass dem finalen Zertifikat eine große Bedeutung zugemessen wird. Denn ist dies der Fall, richten sich alle Aktivitäten nur mehr auf die Erreichung und Erhaltung des Zertifikats aus, das Prozessmanagement wird damit Selbstzweck und nicht-wertschöpfender Ballast. Um dies sicher zu vermeiden, kann es sinnvoll sein, externe Prozessassessments auf Basis eines Reifegradmodells durchzuführen, ohne damit eine Zertifizierung anzustreben.

Prozessreifegradassessments müssen also mit einer klaren Zielsetzung und einem echten Managementverständnis eingesetzt werden. Leider ist dies oft nicht der Fall. Vielmehr zeigt sich in der Praxis, dass Zertifizierungen des Prozessreifegrades von Organisationen vielfach von mittleren oder unteren Hierarchieebenen betrieben werden und primär der Darstellung und der internen und externen Signalwirkung dienen, ähnlich wie dies für viele Qualitätsmanagementzertifizierungen der Fall ist. Ein so verstandener Einsatz von Prozessassessments entspricht nicht einem echten Managementansatz und ist Zeit- und Budgetverschwendung. Richtig eingesetzt können Reifegradassessments jedoch sehr sinnvolle Instrumente zum Controlling des Prozessmanagements und des damit erzielten Fortschritts sein. Um dies sicherzustellen, sollte eine Beauftragung immer vom Process Board als Steuerungsgremium erfolgen und nicht etwa durch das zentrale Prozessmanagementteam oder einzelne Teams und Experten.

312 Siehe z. B. BPM Maturity Model EDEN e.V. (2009). 313 Vgl. BPM Maturity Model EDEN e.V. (2009, S. 7).

220


5.2.6 Normen des Prozessmanagements festlegen

Ergänzend zur ergebnisorientierten Steuerung des Prozessmanagements ist es – analog zur generellen Unternehmenssteuerung – auch notwendig, bestimmte normative Vorgaben für das Prozessmanagement zu machen. Dies betrifft zum Beispiel die methodischen Grundlagen im Hinblick auf das Arbeiten mit Prozessen. Hierzu zählt in erster Linie die Art und Weise, wie Prozesse dokumentiert werden. Dabei geht es nicht um die Frage der optimalen Methode, sondern einfach um die Einheitlichkeit. Denn wenn ein Bereich die Prozesse mit Methode A und ein anderer Bereich mit Methode B dokumentiert und bearbeitet, gäbe es keine Konsistenz zwischen den dokumentierten Prozessen. Gerade diese ist aber notwendig, um die Integrationsfunktion zu unterstützen. Wenn jeder Bereich mit anderen Methoden und isolierten Prozessmodellen agiert, kann das Prozessmanagement diese wichtige Funktion nicht erfüllen. Insofern ist die Festlegung und Sicherstellung von einheitlichen Standards für die Darstellung, Dokumentation und auch weitere Arbeit mit den Prozessen eine absolut essenzielle Grundvoraussetzung für den Erfolg des Prozessmanagements. Die Betonung liegt dabei auch auf der Sicherstellung dieser einheitlichen Standards. Denn einheitliche Methoden, die in Prozesshandbüchern festgelegt sind, sind inzwischen durchaus weit verbreitet. Mindestens genauso weit verbreitet ist jedoch auch die Unart, derartige Standards und Konventionen nicht einzuhalten, sondern sie zu umgehen, auszuhebeln oder überhaupt zu ignorieren. Dies erfolgt in vielen Fällen durch interne Abteilungen, die methodisch andere Wege gehen wollen und ausscheren; in anderen Fällen werden methodische Standards über Board geworfen, weil für bestimmte Projekte beigezogene externe Experten ihre eigenen Methodenkästen mitbringen. Beides ist fatal und mit höchster Konsequenz zu vermeiden und zu verhindern. Leider wird ein derartiges Ausscheren vom Topmanagement meist nicht sanktioniert, sondern toleriert oder als unwesentlich abgetan. Die negativen Konsequenzen einer solchen Nicht-Einhaltung sind jedoch schwerwiegend: ein einheitlicher Standard für das Arbeiten mit Prozessen ist eine notwendige Grundvoraussetzung für den Erfolg des Prozessmanagements; Bereiche, die diese Standards nicht einhalten und Manager, die ihre Einhaltung nicht ausreichend sicherstellen, entziehen dem Prozessmanagement eine essenzielle Erfolgsvoraussetzung. Wird in bestimmten Bereichen oder für einzelne Projekte davon abgegangen, so ist eine spätere Nutzung für andere Bereiche und eine Integration in den bereits bestehenden Rahmen des Prozessmanagements meist nur mit sehr hohem Aufwand möglich, sodass dies häufig unterbleibt. Insofern sind diese Ergebnisse dann für die generelle Entwicklung des Prozessmanagements im Unternehmen verloren und können nicht oder zumindest nur sehr schwer weiter genutzt werden. Was sind nun diese grundlegenden Standards, die hierunter fallen? – Konkret geht es dabei insbesondere um:

221


· · · · · · · · ·

die grundsätzliche verwendete Methodik der Prozessmodellierung eine einheitliche Verwendung der Begriffe im Prozessmanagement die konkrete individuelle Ausgestaltung dieser Methodik in entsprechenden Modellierungskonventionen314 die Eingliederung in das unternehmensweite Gesamtprozessmodell die Einhaltung der festgelegten Prozesshierarchie die Einhaltung von vergleichbaren Detaillierungsniveaus Standards für Prozessdokumente wie etwa Prozesssteckbriefe, Rollenbeschreibungen, etc. die Verwendung desselben Tools innerhalb des gemeinsamen Modellierungs-Setups zur Sicherstellung der technischen Integration der Einsatz von standardisierten Vorgehensweisen, Methoden und Ansätzen für die Optimierung und die Messung der Prozesse

Unter den letzten Punkt fällt insbesondere das im vorhergehenden Abschnitt angesprochene Benefit Tracking der Optimierungseffekte. In vielen Unternehmen gibt es heute noch keine einheitlichen Standards, was genau als Optimierungseffekt zählt und wie diese zu bewerten sind. Manche Bereiche zählen daher nur echte, harte Einsparungen im Sinne echter Ausgabenreduktionen; andere beziehen auch Effizienz- und Produktivitätsgewinne ein; wieder andere zählen auch breit verteilte Optimierungseffekte, die nur schwer bis gar nicht nachvollziehbar sind. Durch diese unterschiedliche Bewertung und Nachverfolgung ist es jedoch unmöglich, verschiedene Optimierungsprojekte untereinander hinsichtlich ihrer Optimierungsbeiträge zu vergleichen oder sich ein konsolidiertes Gesamtbild über die erzielten Verbesserungen zu machen. Um dies zu ermöglichen, werden gemeinsame Standards für das Bewerten und Tracken von Benefits benötigt. Dazu zählen standardisierte Personalkostensätze, gleich angewandte Berechnungslogiken und einheitlich verwendete Kostenarten. Als Mittel, um trotz dieser Standardisierung unterschiedliche Arten von Optimierungseffekten einbeziehen und auch transparent unterscheiden zu können, können verschiedene Benefit-Typen unterschieden werden. Merkmale für diese Unterscheidung sind etwa: · ·

·

die Art der eingesparten Kosten (z. B. Personalkosten, Sachkosten, . . .) ob diese mit einer Reduktion des Personalstandes erzielt wird oder nicht (z. B. FTE-Reduktion oder Reduktion der Personalkosten durch Verlagerung in Niedriglohnländer ohne absolute Reduktion des Personalstandes) ob bestehende Kosten wegfallen oder nur künftige, zu erwartende Kosten vermieden werden können, die derzeit noch nicht bestehen (z. B. Einsparung der War314 Siehe dazu im Detail Rosemann, Schwegmann, Delfmann (2008), S. 76 ff.

222


·

·

tungskosten einer bestehenden Softwareapplikation vs. Vermeidung höherer künftiger Softwarewartungskosten nach Auslaufen der Standardwartung) ob die Kosteneinsparungen cashflow-relevant sind oder nicht (z. B. Einsparung von Personal, das abgebaut wird vs. Effizienzsteigerung im Prozess ohne Abbaumöglichkeit) nach dem Grad der Nachvollziehbarkeit (z. B. direkt einem Prozess oder bestimmten Kostenstellen zuordenbar vs. breit gestreute Optimierungseffekte durch eine verbesserte Dokumentensuche, bei denen angenommen wird, dass jeder Mitarbeiter pro Jahr 5 Minuten Suchzeit einspart)

Ergänzend können die einzelnen Benefits auch noch nach Härtegraden in der Umsetzung gruppiert werden, um einen noch besseren Überblick zu bekommen, wie konkret die einzelnen Effekte sind. So können manche etwa noch im Status einer ersten Idee sein, andere sind bereits durch entsprechende Analysen verifiziert, wieder andere sind in Umsetzung oder bereits umgesetzt, aber noch ohne vollständige Realisierung der damit verbundenen Benefits. Zur Sicherstellung der Einhaltung solcher Standards im Prozessmanagement ist es natürlich erforderlich, die Prozessmanager in die Definition und Weiterentwicklung der gemeinsamen Standards entsprechend einzubinden. Idealerweise resultieren die gewählten Methoden, Konventionen und Tools aus einer gemeinsamen Diskussion und einem gemeinsamen Auswahlprozess. Das zentrale Prozessmanagementteam als Hüter der gemeinsamen Standards kann diese daher nicht im Alleingang festsetzen. Ist dies doch der Fall, so darf man sich über mangelnde Akzeptanz in der Organisation nicht wundern. Schließlich sind gerade die Erfahrung und der Input der Prozessmanger ein wichtiger Aspekt und auch ein wertvoller Beitrag für die Auswahl und Festlegung von praxistauglichen Methoden und Standards. Sind die Standards einmal festgelegt, so sollte ihre Einhaltung auch entsprechend geprüft werden. Sollte es vorkommen, dass sie irgendwo im Unternehmen beim Arbeiten mit Prozessen nicht eingehalten werden, so sollte dies unmittelbar an das Management eskaliert und von diesem auch mit klaren Worten sanktioniert werden. Dies ist deshalb wichtig, weil die Einforderung der Einhaltung der Standards sowie die eventuelle Sanktionierung der Nicht-Einhaltung nicht vom zentralen Prozessmanagementteam alleine, sondern nur gemeinsam mit dem Sponsor des Prozessmanagements im Topmanagement effektiv sichergestellt werden kann. Wird dies – wie leider in der Praxis oft der Fall – ohne entsprechende Managementunterstützung nur an das zentrale Prozessmanagement delegiert, so muss dieses eine Aufgabe wahrnehmen, für das ihm meist die notwendige Autorität fehlt und die zudem für die Akzeptanz dieses Teams in der Organisation kontraproduktiv ist – nur zu leicht bekommt das zentrale Team damit den Stempel des Behinderers, sind doch die negativen Effekte so einer Nicht-Einhaltung den betreffenden Akteuren meist nicht bewusst und auch nicht so wichtig. 223


Parallel zu dieser konsequenten Einforderung der Einhaltung der festgelegten Standards sollte es zumindest einmal jährlich im Kreis der Prozessmanager einen Lessons Learned Workshop geben, bei dem das bestehende Standardset auf Basis der gemachten Erfahrungen aber auch neuer externer Trends und Entwicklungen bewertet und hinterfragt wird. Diese Überprüfung stellt sicher, dass die Standards nicht starr sind, sondern dem Bedarf entsprechend weiter entwickelt werden. Zudem stellt sie den Auslass für Unzufriedenheit mit den bestehenden Ansätzen dar und kanalisiert diese für eine nutzbringende Weiterentwicklung im entsprechenden Expertenkreis.

5.3 Managen der Prozesse Im vorhergehenden Abschnitt wurde versucht, den oft vernachlässigten Aspekt des Managens des Prozessmanagements darzustellen. Als zweiten Teil des Verständnisses von Prozessmanagement als Managementansatz soll es im Folgenden nun um dieses Verständnis als Managementansatz im Hinblick auf die konkrete Steuerung und Optimierung von Prozessen gehen.315 Im Zentrum steht dabei wiederum die Erstellung von Leistungen für die Kunden, die mit den Prozessen erfolgt. Dabei werden für die wesentlichen Prozesse Ziele definiert und die Prozessperformance hinsichtlich dieser Zielsetzungen gemessen und analysiert. Als Prozessperformance wird also die Leistung eines Prozesses im Hinblick auf die für diesen Prozess definierten Ziele verstanden.316 Besteht zum angestrebten Ziel eine Lücke, wird der Prozess in der Folge gezielt optimiert. Zur Überprüfung der Wirksamkeit der Optimierung wird anschließend die Prozessperformance nochmals überprüft. Darüber hinaus werden die Lehren aus der Prozessoptimierung gezogen und die Erfahrungen falls möglich auf andere Prozesse transferiert.

Abb. 72: Managen von Prozessen

315 Hess, Osterloh (1995) sprechen in diesem Zusammenhang von „Prozessführung“ (S. 155). 316 Vgl. dazu auch Mayer in Horváth & Partners (2005), S. 3 ff.

224

Managen der Prozesse

5.3.1 Ziele für Prozesse festlegen

Der entscheidende Punkt für ein echtes Managen der Prozesse ist dabei ein konsequent zielorientiertes Vorgehen. Dabei werden nicht alle Prozesse im Detail modelliert und auch nicht alle Prozesse kontinuierlich und ständig verbessert, sondern es erfolgt bei den ausgewählten Prozessen, die gemanagt werden sollen, eine Bündelung und Fokussierung der Kräfte und Aktivitäten auf die Erreichung erfolgskritischer Prozessziele. Aufbauend auf der generellen Zielsetzung des Prozessmanagements werden daher für die wesentlichen Prozesse, die im Fokus sein sollen, im ersten Schritt klare Prozessziele definiert.317 Diese Prozessziele müssen bei den Anforderungen der Kunden des Prozesses sowie den Anforderungen aus der Strategie ansetzen. In ihrer Ausprägung orientieren sie sich am grundsätzlichen Zieledreieck Zeit – Qualität – Kosten, für die jeweils ein bestimmtes Anspruchsniveau definiert wird.318 Die Zielsetzung wird dabei entsprechend konkretisiert. Beispiele für solche Konkretisierungen von Prozesszielen sind etwa: · · · · · · ·

ein bestimmtes Prozesskostenniveau als Beitrag für eine bestimmte Profitabilität ein bestimmtes Niveau maximaler Ausschuss- oder Defaultkosten eine bestimmte zeitliche Zielsetzung für die Durchlaufzeit als Wettbewerbsvorteil im Sinne einer schnelleren Lieferfähigkeit eine bestimmte zeitliche Vorgabe für die Entwicklung neuer Produkte und Leistungen oder neuer Varianten davon im Sinne einer angestrebten time-to-market ein bestimmter Anspruch hinsichtlich Prozessstabilität als Qualitätsmerkmal nach außen als Teil des Geschäftsmodells ein bestimmtes Maximalniveau bzgl. fehlerhafter Produkte oder Reklamationen etc.

317 Vgl. dazu auch Hiller, Minar-Hödl, Zahradnik (2010), die auch die Wichtigkeit der Festlegung der zukünftigen Ziele, die mit einem Prozess verfolgt werden sollen, vor der Optimierung betonen (S. 70). Ähnlich Stöger (2009), der ebenso die Bedeutung klarer Prozessziele am Beginn unterstreicht (S. 121). Dies deckt sich auch mit dem Standardvorgehen von Six Sigma, bei dem ebenso am Beginn jeder Verbesserung in der Define-Phase klar die angestrebten Ziele festgelegt werden, siehe z. B. Weilkiens, Weiss, Grass (2010), S. 156–157. Vgl. auch Knuppertz (2009), S. 131. Spanyi (2007) bringt diese Zielorientierung sehr treffend durch die Frage auf den Punkt: “Which of our key processes need to be improved, and by how much, in order to achieve our goals?” (S. 21). Ebenso Rummler, Remias, Rummler (2010), in deren Ansatz ebenso zuerst festgelegt wird, welche Performance für einen Prozess oder Teilprozess notwendig ist, um die übergeordneten Businessziele zu erreichen (S. 106). Siehe auch Rummler, Brache (1997, S. 22 und S. 47). 318 Eine interessante Abwandlung des Zieldreiecks entwickelt Nicolai (2009, S. 196), in dem sie neben den drei oben angeführten auch noch die Innovationsfähigkeit als vierte Dimension aufnimmt. Österle (2010/1995, S. 109) ergänzt hingegen als vierte Dimension die Flexibilität. Ebenso Buchenau (2010), S. 325. Binner (1997) sieht neben Kosten, Zeiten, Qualität und Flexibilität noch die Dimensionen Produktivität und Service (S. 1–14).

225


Abb. 73: Zieldreieck für die Optimierung und Steuerung von Prozessen

Um herauszufinden, welche Ziele für einen Prozess verfolgt werden sollten, ist es am besten, die Empfänger der Leistung zu fragen, was ihnen wichtig ist: die Kunden des Prozesses, welche die Empfänger der erbrachten Leistung sind. Kernfragen sind dabei: Warum ist den Kunden die Leistung wichtig? Wofür wird sie benötigt? Welche Aspekte an der Leistung und ihrer Erbringung sind besonders wichtig für die Kunden? In den Worten von Michael Hammer und James Champy: „Ein ReengineeringTeam muss daher die Kunden besser verstehen als diese sich selbst.“319 Die Zielsetzung für den Prozess orientiert sich fundamental daran, was die durch ihn erbrachte Leistung für den Kunden erfüllen muss.320 Wichtig ist dabei, dass nicht einfach Ziele gesetzt werden, die einfach etwas höher liegen als der vermutete Ist-Zustand, quasi um einen Ansporn zu geben, noch ein Stückchen besser zu werden. Dies wäre der falsche Ansatz. Richtige Prozessziele auf Basis eines echten Managementverständnisses werden aus der Notwendigkeit strategischer und operativer Überlegungen abgeleitet. Auf Basis einer solchen Ableitung kann es zum Beispiel sein, dass eine Lieferfähigkeit innerhalb von 24 Stunden gefordert ist, eine Durchlaufzeit von maximal 20 Wochen bis zum Marktstart neuer Updates oder – aus Überlegungen der Zielpreisfindung (target costing) ein bestimmtes maximales Kostenniveau für die betreffenden Prozesskosten. Die Festlegung des Zieles und des Zielwertes muss also im Hinblick auf die Kundenanforderungen, die betriebliche Notwendigkeit und die Gesamtperformance des Unternehmens im Markt definiert werden. Eine reine Maximierungsvorgabe wäre hier nicht zielführend und würde dem 319 Hammer, Champy (1994), S. 182, vgl. auch S. 177–178. 320 Vgl. Hammer, Champy (1994), S. 183, ebenso S. 239.

226


Verständnis von Prozessmanagement als einem echten Managementansatz widersprechen. Michael Gaitanides bringt dies sehr treffend auf den Punkt, wenn er schreibt: „Da die Leistung eines Geschäftsprozesses immer an den Kundenbedürfnissen zu beurteilen ist, kann es nicht um Minimierung oder Maximierung der Performancegrößen gehen, sondern immer nur um die Übereinstimmung mit definierten Vorgaben, der „conformance to customer requirements“.321 Nur wenn diese Relation zu den aus Kunden- und Performancesicht notwendigen Leistungsniveaus gegeben ist, handelt es sich um sinnvolle Ziele und echte steuerungsrelevante Größen.322 Um negative Nebenwirkungen zu kontrollieren, sollten dabei gleichzeitig auch Zielgrößen oder Mindestniveaus für die anderen beiden Zieldimensionen soweit wie möglich festgelegt werden. Zum Beispiel, wenn das hauptsächliche Prozessziel eine Kostenreduktion auf ein bestimmtes Prozesskostenniveau ist, so sollte festgelegt werden, welche Wichtigkeit in diesem Zusammenhang den anderen beiden Dimensionen Qualität und Zeit zukommt und welche Ziel- oder Mindestniveaus hier notwendig sind. So kann es etwa der Fall sein, dass die zeitliche Dimension weniger wichtig ist, und die Qualität als ausreichend empfunden wird. Das konkrete Prozessziel hieße dann etwa: „Reduktion der Prozesskosten auf xx EUR Prozesskostensatz bei gleichbleibender Qualität – Auswirkungen auf die Lieferzeit bis max. 6 Wochen können in Kauf genommen werden“. Zur Messung des festgelegten Prozesszieles werden Prozesskennzahlen festgelegt. Da die Prozesskennzahlen das festgelegte Ziel messen und dieses aus den operativen und strategischen Notwendigkeiten für die Prozesse abgeleitet werden, definieren sich Prozesskennzahlen über ihre Steuerungsrelevanz. Sie werden nicht festgelegt, weil man für jeden Prozess per Definition Prozesskennzahlen braucht, wie dies als breit etablierter state-of-the-art des Prozessmanagements gilt. Diese Definition von Kennzahlen per default widerspricht einem Prozessmanagement als Managementansatz diametral. Kein Manager setzt Kennzahlen um ihrer selbst oder um eines Standards willen fest. Ganz im Gegenteil: Prozesskennzahlen werden festgelegt, weil für einen bestimmten, wichtigen Prozess ein bestimmtes Ziel verfolgt wird und erfolgskritisch ist. Die Kennzahl dient einzig zur Sicherstellung der Steuerung und Kontrolle der Zielerreichung im Sinne des Diktums „you can only manage, what you measure“. 321 Gaitanides (2007), S. 205. 322 Ein Prozessmanagementverständnis, das dem hier vertretenen Ansatz entspricht, findet sich etwa teilweise bei der EABPM, die es als Aufgabe des Process Owners sieht, ein gewünschtes Leistungsniveau für seine Prozesse festzulegen und dann die Abweichungen zwischen der aktuellen und der gewünschten Leistung zu bewerten (EABPM 2009, S. 223). Ähnlich auch Hiller, Minar-Hödl, Zahradnik (2010), die für jeden Prozess fünf bis sieben „Leitwerte“ mit entsprechenden Zielwerten definieren, hinsichtlich derer der Prozess entwickelt werden soll (S. 113–115); hilfreich ist hier auch das von den Autoren vorgestellte Korrelationsdiagramm zur Analyse, welche Leitwerte gut als Hebel und welche gut als Indikator für die Zielerreichung geeignet sind (S. 115). Ähnlich auch BPM Maturity Model EDEN e.V. (2009), in dem in Bezug auf die Reifegradstufen festgehalten wird, dass es in vielen Fällen nicht erforderlich ist, das maximal Mögliche anzustreben (S. 7).

227


Nur wenn dies gewährleistet ist, besteht auch ein nachhaltiges Interesse an den Prozesskennzahlen, sodass sie im täglichen Betrieb tatsächlich genutzt und verwendet werden. In vielen Unternehmen werden aktuell viel zu viele Prozesskennzahlen festgelegt. In den meisten Fällen orientiert man sich dabei an Sammlungen gängiger Prozesskennzahlen, wie man sie in der Literatur findet.323 Häufig werden pro Prozess auch gleich mehrere, oft fünf oder mehr verschiedene Prozesskennzahlen definiert, ohne diese jedoch aus einem konkreten Steuerungsbedarf herzuleiten.324 Vielfach wird unter Prozessmanagern auch gefragt, welche Prozesskennzahlen man einsetzt und ob man diese oder jene Kennzahl verwendet. Die interessante vorgelagerte Frage müsste vielmehr sein: Welche Zielsetzungen werden in Bezug auf bestimmte Prozesse verfolgt? Und dann in Bezug auf die Kennzahl: Mit welchen Kennzahlen wird die betreffende Zielsetzung – zum Beispiel eine bestimmte Durchlaufzeit in einem Helpdeskprozess eines IT-Dienstleisters – adäquat gemessen? Ohne konkretes Prozessziel definierte Prozesskennzahlen sind vom ersten Tag an zum Scheitern verurteilt – schlichtweg, weil sie niemand braucht. Die einzig wesentliche Frage bei der Festlegung von Prozesskennzahlen ist daher: Was ist das Ziel, das im Hinblick auf einen Prozess erreicht werden soll? Dies ist eine Frage, die vom jeweiligen Prozessmanager mit seinem Process Owner erarbeitet werden muss. Ist diese Frage beantwortet, kann anhand der Zielsetzung eine geeignete Kennzahl definiert werden. Für diese Auswahl und Definition von geeigneten Prozesskennzahlen gibt es eine Reihe von Kriterien aus der Praxis, welche die Festlegung einer guten Prozesskennzahl unterstützen können:325 · · · · ·

Effektivität: die Kennzahl ist für das Management ein wesentlicher Steuerungsgewinn Validität: die Kennzahl misst tatsächlich das Gewollte Reliabilität: die Kennzahl ist konstant wiederholbar (zeitlich, örtlich, zwischen Einheiten) und wird auch von allen Beteiligten gleich interpretiert Integriertheit: die Kennzahl umfasst die wesentlichen Aspekte des betreffenden Prozesses im Sinne einer End-to-End-Abdeckung Detaillierungsgrad: die Kennzahl ist auf dem richtigen Detaillierungsniveau, um aussagekräftig zu sein und als Basis für korrektive Handlungen dienen zu können 323 Siehe z. B. Stausberg (2006). Vgl. auch Spany (2007), S. 135. 324 Vgl. auch Wilhelm (2007), S. 81. Auch er merkt an, dass Prozesskennzahlen vielfach sehr beliebig ohne klares Ziel festgelegt werden und dass ihre Messung nicht in einen Analyse- und Verbesserungskreislauf integriert ist. Ebenso Fischermanns (2006), S. 25, der unter dem Verweis auf das Motto: „Plane nur, was Du auch steuerst“, ebenso empfiehlt, nur wenige wichtige Prozesskennzahlen zu definieren. 325 Zu Kriterien für Prozess Performance Kennzahlen siehe auch EABPM (2009), S. 149; Wagner (2001), S. 55.

228


· · · · ·

Verständlichkeit: die Kennzahl soll für alle Beteiligten möglichst leicht verständlich sein und einen erkennbaren Bezug zur Prozessleistung haben Kompatibilität: die Kennzahl ist kompatibel mit dem übrigen Steuerungssystem Wirtschaftlichkeit: der Nutzen der Kennzahl übersteigt den Aufwand für ihre Messung Messbarkeit: sie kann zumindest in regelmäßigen Abständen gemessen werden Behavioral Fit: sie verursacht keinen signifikanten Anreiz für ungewolltes Verhalten

Werden diese Kriterien eingehalten, so ist die Chance groß, tatsächlich die „richtige“ Prozesskennzahl zu wählen bzw. die Prozesskennzahl richtig zu definieren. Das definitiv wichtigste Kriterium ist jedoch mit Abstand das erste: Nur wenn eine Prozesskennzahl im Hinblick auf die Steuerung des Geschäfts effektiv ist, indem sie für das betreffende Management einen Steuerungsgewinn gegenüber dem bisherigen Instrumentarium des Reporting gibt, ist es gerechtfertigt, sie zu etablieren.326 In der Realität wird leider immer noch viel zu oft das Kriterium der technischen Messbarkeit als oberste Maxime herangezogen, meist, weil man für die Implementierung von Prozesskennzahlen nach Möglichkeit nicht viel Aufwand generieren will. Dies ist jedoch der falsche Ansatz. Vielmehr gilt: Wenn man etwas steuern will, was mit dem bisherigen Instrumentarium nicht gesteuert werden kann, so muss es das Ziel sein, den betreffenden Sachverhalt messbar zu machen. Es gilt ganz klar: what you can’t measure, you can’t manage. Im Umkehrschluss bedeutet dieser Satz: if you want to manage something, make it measurable. Wenn man etwas erreichen und steuern will, so muss man es in irgendeiner Form messbar machen. Neben der Frage der Messbarkeit stellt in der Praxis nicht so sehr die Definition der Kennzahl an sich die große Herausforderung dar, sondern vielmehr die konkrete Operationalisierung der festgelegten Kennzahlendefinition auf die verschiedenen vorkommenden Geschäftsfälle. So kann man etwa die Lieferzeit einfach als Zeit zwischen Auftragseingang und Lieferung des Produkts definieren. Die Herausforderung in der Praxis ist jedoch oft die genaue Festlegung der Grenzen und der Messpunkte in dieser Definition: Gilt etwa als Auftragseingang eines Auftrags das Erfassungsdatum im System, der zeitliche Eingangsstempel am EDI-Server oder aber der Zeitstempel der Auftragsannahme; und wie ist das bei Rahmenverträgen mit Abrufen, bei denen der Kunde sein Produkt bei Bedarf einfach vom Auslieferungslager abholt und die Aufträge erst nachträglich im System erfasst werden? Oder wie sollen vom Kunden wieder stornierte Aufträge für die Berechnung der durchschnittlichen Lieferzeit berücksichtigt 326 Vgl. dazu Schmelzer, Sesselmann (2010): Sie fragen sich, warum das Prozesscontrolling in der Praxis eine geringe Reife hat. Anstatt die Frage nach den Steuerungsbedarfen des Managements zu stellen, sehen sie den Grund jedoch in der mangelnden Serviceorientierung des Controllings und dem Fehlen ausreichend guter IT-Tools (S. 305) – beiden Argumenten kann hier nicht gefolgt werden.

229


werden, wenn das Storno erst nach der Auslieferung erfolgt ist. Es ist notwendig, diese Detailfragen vor dem konkreten Hintergrund der möglichen Abwicklungsvarianten zu analysieren und hierfür entsprechende Festlegungen zu treffen. Tut man dies nicht gleich zu Beginn, so liefern die ersten Messungen meist Ergebnisse, die nicht plausibel und nicht nachvollziehbar sind – und spätestens dann muss die Behandlung dieser Details nachgeholt werden. 5.3.2 Prozessperformance messen und analysieren

Erst wenn Ziele und Kennzahlen für einen Prozess festgelegt sind, erfolgt die Erhebung des aktuellen Status.327 Dafür wird die Messung der festgelegten Kennzahl veranlasst, die Werte der einzelnen Prozessdurchläufe (Instanzen) werden gesammelt, auf den Prozess aggregiert und mit der definierten Kennzahl ausgewertet. Je nach Anzahl der Prozessdurchläufe, der damit verbundenen Datenmenge und der angestrebten Frequenz der Messung kann dies mit einfachen Mitteln oder auch mit professionellen Instrumenten für Prozesskostenanalyse oder Prozess Performance Monitoring erfolgen. Einfache Messungen können etwa über eine einfache Datenextraktion, Datenkonsolidierung und Datenanalyse in einer Tabellenkalkulation oder einer einfachen Datenbankumgebung erfolgen, etwa in Microsoft Excel oder Microsoft Access. Bei etwas höheren Ansprüchen an die Auswertung und Analyse der Daten können diese auch in spezialisierte Tools zur statistischen Datenanalyse geladen werden, wie sie vor allem in Lean- und SixSigma-Ansätzen etabliert sind (z. B. MiniTab, SigmaXL, . . .). Soll die Messung hingegen kontinuierlich erfolgen, so eignen sich dafür Werkzeuge für Process Performance Monitoring und Process Mining. Mit diesen Werkzeugen werden permanente Messpunkte und Datenextraktoren zu verschiedenen vorgelagerten operativen Systemen, etwa zu einem CRM-System, einem ERP-System oder auch einer Workflowanwendung, sowie anderen Messstellen (etwa Zeitstempelanlagen, Barcodescanner, RFID-Anlagen, etc.) hergestellt. Über diese Datenadapter werden die Daten aus den Messstellen oder aus den operativen Systemen, die entsprechende Zeitstempel mitschreiben, extrahiert und in ein entsprechendes Process Data Warehouse geladen. Im Unterschied zu normalen Data Warehouses stellt dieses die Daten aus den einzelnen Prozessfragmenten wieder zu kompletten Prozessinstanzen zusammen. Das heißt zum Beispiel, dass die einzelnen Prozessfragmente Angebot erstellen, Auftrag anlegen, Auftrag beliefern und Lieferung fakturieren anhand eines ge327 Die EABPM sieht Prozessanalysen z. B. durch „besondere Vorkommnisse“ ausgelöst, wie etwa eine Änderung der Unternehmensstrategie, unzureichende Prozessleistung, neue Technologien, Anlaufrisiken, Fusionen/Übernahmen oder verbindliche Vorgaben (EABPM 2009, S. 88–89). Bei genauerer Überlegung lassen sich alle diese „Vorkommnisse“ auf entsprechende Deltas zwischen den Prozesszielen und der Ist-Performance zurückführen. Die Formulierung über die gesetzten Ziele wird jedoch klar präferiert, da sie dem zugrunde gelegten Managementverständnis besser entspricht als das reine Reagieren auf besondere Vorkommnisse.

230


meinsamen, durchgängigen Schlüssels – etwa der Auftragsnummer eines bestimmten Geschäftsfalles – zu einer gemeinsamen Prozessinstanz zusammengestellt und gespeichert werden. Erst damit entsteht aus den Bausteinen der beteiligten Teilprozesse und Funktionen ein Datenwürfel, der es erlaubt, die Daten aus der Sicht der Prozesse zu analysieren. Denn in den operativen Systemen und Messpunkten ist jeweils nur ein Teil des gesamten End-to-End-Prozesses abgebildet. Erst durch die Rekonstruktion des gesamten End-to-End-Prozesses aus den einzelnen Prozessteilen entsteht eine Datenbasis, die die Analyse des Prozesses aus einer echten Prozessperspektive ermöglicht. Die einzelnen Prozessinstanzen sind dann anhand verschiedener Auswertungsdimensionen und Kennzahlen auswertbar. Damit kann ein klassischer Controllingansatz angewendet werden, jedoch mit den Geschäftsprozessen als Analyseobjekt.328 Welche Auswertungsdimensionen und -parameter dafür eingesetzt werden, hängt wiederum primär vom Analyse- und Steuerungsbedarf ab. Decken die Quellsysteme bestimmte für die Analyse notwendige und interessante Dimensionen nicht ab, so muss überlegt werden sie hierfür entsprechend zu erweitern. Mit Process Mining kann über diese Analysen und Reports anhand definierter Auswertungsdimensionen hinaus noch nach weiteren Mustern in den Prozessdaten gesucht werden, die Anhaltspunkte für Verbesserungen geben.329 Manche IT-Systeme, mit denen aus der Modellierung heraus die operative Ausführung von Prozessen direkt unterstützt wird, haben derartige Monitoring- und Analysesysteme bereits integriert und liefern diese mit.330 Sofern also ein Prozess am Beginn nicht messbar erscheint, weil er noch nicht durchgängig oder ausreichend mit IT-Systemen unterstützt wird, kann der Einsatz eines solchen Business Process Management Systems eine gute Möglichkeit darstellen, diesen Prozess einerseits stärker zu strukturieren und zu automatisieren und andererseits auch die Basis für eine entsprechende Messung und Steuerung des Prozesses zu schaffen. Anders als Prozess Monitoring Systeme, die die Prozessdaten aus den operativen Systemen extrahieren und erst zu kompletten End-to-End-Prozessinstanzen rekonstruieren müssen, schreiben diese Systeme die wesentlichen Daten für die unterstützten Prozesse gleich direkt in einer Prozesssicht mit. Damit verfügen sie über eine saubere und leicht zugängliche Basis für die Prozessmessung ohne große Schnittstellenprogrammierung zu anderen Quellsystemen. Wird ein solches kontinuierliches Process Monitoring eingerichtet, so kann damit die vorhandene Unternehmenssteuerung erweitert und verfeinert werden. Denn die klassischen Instrumente der Unternehmenssteuerung basieren im Wesentlichen auf aggregierten und nachlaufenden Kennzahlen: Erlöse und Kosten von verschiedenen Bereichen, Regionen oder Produktfeldern sind erst bekannt, wenn die Leistungen 328 Vgl. dazu Loos, Balzert, Werth (2010). Die Autoren führen dort insbesondere die Architektur zum Controlling von Geschäftsprozessen im Detail aus. 329 Vgl. Loos, Balzert, Werth (2010), S. 452. 330 Vgl. Shoshana Zuboff zit. in Davenport (1993), S. 74.

231


entsprechend erbracht und verbucht sind. Meistens liegen entsprechende Berichte monatlich jeweils ein bis zwei Wochen nach Monatsende vor und werden dann analysiert und besprochen. Mit einem kontinuierlichen Prozess Monitoring ist es möglich, hier für die wesentlichen und kritischen Prozesse eine detailliertere Steuerung aufzubauen. Diese bietet dann nicht nur ex-post Informationen, sondern kann wöchentlich, täglich oder im Extremfall sogar in Realtime Detailinformationen über die Abarbeitung der Geschäftsfälle in diesen erfolgskritischen Prozessen bieten. Die entsprechenden Prozesskennzahlen gehen dabei nicht nur auf Erlöse und Kosten, sondern können verschiedenste Mengen-, Zeit- oder Qualitätsaspekte umfassen, die sich erst viel später in der Abarbeitung in Erlösen und Kosten niederschlagen. Insofern kann das Prozessmanagement mit dem Prozessmonitoring eine vorgelagerte und detailliertere Steuerung auf Basis von Frühindikatoren anbieten, die das traditionelle Steuerungssystem ergänzen. Natürlich ist auch hier Vorsicht geboten: Trotz der generellen, technischen Möglichkeiten machen solche detaillierten Prozesssteuerungssysteme nur Sinn, wenn sie einen realen Steuerungsbedarf adressieren und vom Management verlangt und genutzt werden. Da in der Unternehmenspraxis die meisten Berichte ohnehin schon weit mehr an Kennzahlen und Auswertungen enthalten, als jeder Manager überblicken kann, sollte jede zusätzliche Erweiterung nur sehr bedächtig bzw. in Verbindung mit der Wegnahme anderer, nicht genutzter Kennzahlen erfolgen. Nur dann ist gewährleistet, dass das Prozessmonitoring tatsächlich einen Steuerungsgewinn bietet und nachhaltig verankert wird. Ist dies nicht der Fall, verkommt es zu einem zusätzlichen technischen Gimmick ohne wirkliche Relevanz, das bei Änderungen in den Verantwortlichkeiten auch rasch wieder eingestellt wird. Sind die Daten aus einer Prozesssicht verfügbar, so werden sie entsprechend analysiert. Am Beginn steht dabei klarerweise der Blick auf die definierten Kennzahlen für die gesetzten Prozessziele: Wo steht man in Bezug auf die gesetzten Ziele? Wie hoch ist die Lücke (gap) zum angestrebten Zielwert?331 Wo steht man eventuell auch im Hinblick auf die anderen Zieldimensionen, die es in Bezug auf negative Auswirkungen zu kontrollieren gilt. An diesen ersten Analyseschritt schließt sich die Detailanalyse an, bei der die Datenbasis im Detail untersucht wird. Hierfür werden Kennzahlen auf verschiedene Auswertungsdimensionen herunter gebrochen, etwa auf Länder, Regionen, Produkt- oder Leistungsgruppen, Teams, Monate, Kundengruppen oder Ähnliches. Meist erfolgt diese Detailanalyse nur für jene Kennzahlen, bei denen ein größerer Gap zum Zielwert besteht. Die Detailanalyse dient dann der Ursacheneingrenzung, um zu sehen, wo genau der Grund für die Verfehlung des Zieles liegt. So kann es etwa sein, dass eine angestrebte Lieferzeit von 30 Tagen für alle Produktgruppen in den Regionen Nord, Ost und Süd erreicht wurde, und die Verfehlung dieses Werts in der Region West die Lücke begründet. Innerhalb der Region West zeigt 331 Vgl. EABPM (2009), S. 153: Die EABPM spricht in diesem Zusammenhang von einer Prozessleistungslücke.

232


die Detailanalyse, dass die Lieferzeit vor allem mit der Kundengruppe der Zwischenhändler problematisch war, während sie bei den großen Direktkunden fast den Zielwert erreicht hat, und so fort. Auf diese Weise kann der Grund für eine Zielverfehlung eingegrenzt werden. Die Daten können die Ursachenanalyse sowohl für die Hypothesenfindung als auch für die Hypothesenfalsifizierung unterstützen. Die Analyse der Prozessdaten muss sich jedoch nicht nur auf die Lücken konzentrieren, sondern kann durchaus auch bei Zielen, wo die Zielwerte der definierten Kennzahlen erreicht wurden, einen Blick auf die Detaildaten anhand verschiedener Auswertungsdimensionen werfen. Vielfach ist es so, dass ein Ziel im gesamten nur deshalb erreicht wurde, weil der Prozess für bestimmte Produkte, Regionen, Kundengruppen etc. deutlich besser performte als angestrebt und diese Überperformance die Unterperformance anderer Geschäftsfälle ausgleicht. Es lohnt sich daher auch hier eine kurze Analyse der Daten im Detail, da damit eventuell bereits vorbeugend eine künftige Unterschreitung des definierten Zielniveaus verhindert werden kann. Dort, wo größere Lücken aufgezeigt werden, wird im nächsten Schritt eine Prozessoptimierung aufgesetzt. 5.3.3 Prozess optimieren

Zeigt die gemessene Performance anhand der Kennzahlen ein signifikantes Delta zum angestrebten Zielwert, so setzt die nächste Phase der Arbeit an den Prozessen ein: die Optimierung. Auch bisher wurden in den Unternehmen schon zahlreiche Prozessoptimierungen durchgeführt. Nur in den allerwenigsten Fällen handelte es sich dabei jedoch um eine Optimierung von kompletten End-to-End-Prozessen. Zwar gehört es zum etablierten Wissen, dass eine isolierte Optimierung nicht zielführend ist, ja sogar gefährlich sein kann, weil dabei die Gefahr besteht, dass nur der betreffende Teilprozess optimiert wird und dabei gegebenenfalls Verschlechterungen für voroder nachgelagerte Prozesse entstehen. Dennoch sind fast alle durchgeführten Optimierungsvorhaben genau solche Optimierungen von Teilprozessen. Da werden etwa die Einkaufsprozesse optimiert, die Vertriebsprozesse verbessert oder die Logistikprozesse radikal erneuert. Echte Optimierungsprojekte, die einen gesamten End-to-End-Prozess der Leistungserstellung umfassen, gibt es jedoch nur selten.332 Die Optimierung eines End-to-End-Prozesses erfolgt dabei sinnvollerweise über eine Bottom-up-Optimierung mit Einbindung von wichtigen am Prozess Beteiligten. Vielfach wird diesem Vorgehen auch ein Top-down-Vorgehen als Alternative gegenübergestellt. Bei diesem Top-down-Vorgehen erfolgt die Optimierung im Wesentlichen ohne Einbindung der Beteiligten und ohne detaillierte Prozessanalyse. Vielmehr wird die Ressourcenbindung im Prozess mittels Fremdvergleich (benchmar332 Vgl. Spanyi (2007), S. 52. Ebenso Rummler, Remias, Rummler (2010), S. 70 und S. 91.

233


king) überprüft und infrage gestellt. Über ein so festgestelltes Delta wird sodann Druck aufgebaut und eine Ressourcenreduktion in Richtung des Benchmarkwertes vorgenommen. Der konkrete Ablauf dahinter wird dabei jedoch oft nicht geändert – vielmehr besteht die Annahme, dass bei entsprechender Ressourcenkürzung auf ein vergleichsweise adäquates Niveau sich die am Prozess Beteiligten den Prozess unter diesem Druck in weiterer Folge entsprechend selbst optimieren werden. In der Praxis zeigt sich das diese Rechnung aber nur teilweise aufgeht: Leerkapazitäten können so sicherlich entfernt werden; in manchen Fällen mag es auch gelingen, dass die am Prozess Beteiligten in der Folge den Ablauf tatsächlich straffen, um mit den geringeren Ressourcen zurechtzukommen; häufig erfolgt jedoch auch eine reine Verschiebung von Aufwänden oder einfach ein Weglassen von bestimmten Teilleistungen oder Beiträgen. Ein derartiges Vorgehen führt daher nicht selten zu einer Verschlechterung der Qualität in der Abwicklung. Echte Prozessverbesserungen im Sinne einer nachhaltigen Ablaufoptimierung sind auf diese Weise jedoch meist nicht zu erzielen. Erfolgt doch eine detaillierte Analyse des Detailablaufs und eine Umstellung im Prozess, so wird diese in einem Top-down-Vorgehen durch ein in den operativen Prozess nicht involviertes Projektteam durchgeführt. So erstellte optimierte Sollprozesse liegen dann zwar häufig sehr nahe an einem Idealprozess und sehen oft radikale Änderungen vor. Da operative Zwänge und Notwendigkeiten im Detail dabei jedoch häufig nicht ausreichend bedacht oder auch falsch eingeschätzt werden, können diese Sollprozesse in der Folge oft so nicht umgesetzt werden und stoßen auch bei den Beteiligten auf große Ablehnung. Dort wo ein Top-down-Vorgehen tatsächlich in den Detailablauf einsteigt, besteht daher immer ein hohes Umsetzungs- und Akzeptanzrisiko. Aus diesem Grund haben Top-down-Ansätze durchaus ihre Berechtigung für die rasche Beseitigung von Leerkapazitäten – etwa in Krisenzeiten zur Anpassung der Ressourcen als Reaktion auf eine drastisch geänderte Nachfragesituation – für eine echte Ablaufoptimierung mit nachhaltiger Umsetzung und Akzeptanz in der Organisation sind sie jedoch nicht geeignet.333 Die bewährte Vorgehensweise für die Optimierung von Prozessen ist daher eine geführte Bottom-up-Optimierung. Dabei wird die Optimierung gemeinsam mit den am Prozess Beteiligten durchgeführt, diese werden dabei jedoch nicht alleine gelassen, sondern von Prozessexperten geführt und methodisch unterstützt.334 Die geführte Bottom-up-Optimierung folgt dabei folgenden sechs Schritten (siehe Abb. 74).

333 Zum Thema Prozesstransformation durch Top-down-Restrukturierung siehe z. B. Grönke in Horváth & Partners (2005), S. 87–105. 334 Vgl. dazu etwa auch Kieninger (1998) sowie Becker, Schmidt (2005), S. 107–122. Wagner (2001), S. 48. Auch der Ansatz des Scientific Managements von Frederick Winslow Taylor folgt im Wesentlichen dieser Idee (Taylor 1911). Taylor konzentriert sich zwar vor allem auf Bewegungen und einfache Arbeitsabläufe, sieht aber durchaus auch die konkrete Abfolge der einzelnen Schritte und die dafür genutzten Arbeitsgeräte als wesentlichen Hebel (S. 91).

234

Abb. 74: Vorgehen in der Prozessoptimierung


Im ersten Schritt wird dabei ein entsprechendes Prozessoptimierungsteam aufgesetzt und zusammengestellt. Dieses besteht aus:335 · · · · ·

einem Teamleiter einem Moderator erfahrenen Vertretern aus den am Prozess beteiligten Abteilungen einem Vertreter des Controllings evtl. einem Vertreter aus der IT

Der Teamleiter sollte ein akzeptierter Manager aus dem mittleren Management sein, zum Beispiel einer der Abteilungsleiter einer beteiligten Abteilung. Er sollte schon einige Zeit im Unternehmen sein und über eine entsprechende Akzeptanz und Autorität verfügen. Seine Aufgabe ist es, quasi als Projektleiter des Optimierungsvorhabens, das Optimierungsteam zu leiten und mit ihm den Optimierungsauftrag zu erfüllen. In weiterer Folge wird er auch für die Umsetzung der erarbeiteten Verbesserungsmaßnahmen und Prozessänderungen verantwortlich sein. Im Gegensatz zum Teamleiter soll der Moderator nicht am Prozess beteiligt sein, um ohne eigene Interessen das Optimierungsteam moderieren zu können. Neben der Moderation ist es seine Rolle, die Optimierungsarbeit methodisch zu unterstützen, die Ideenfindung zu initiieren und zu führen, bestehende Ablaufstrukturen infrage zu stellen und den Teamleiter in der entsprechenden Vor- und Nachbereitung von Teamworkshops zu unterstützen. Diese Rolle wird daher idealerweise von einem Vertreter des zentralen Prozessmanagementteams oder von einem externen Berater wahrgenommen. Bei den Vertretern aus den beteiligten Bereichen und Abteilungen kommt es auf zwei Dinge an: einerseits auf ihre Detailkenntnis des Ablaufes für die konkrete Arbeit in der Optimierung. Diese ist wichtig, um Verbesserungsideen auf ihre Machbarkeit zu überprüfen und alle wichtigen Aspekte des Geschäfts einzubeziehen. Andererseits kommt es auch auf Ihre Stellung und Akzeptanz in den Abteilungen an, damit die Verbesserungen, die mit Ihrer Mitarbeit erarbeitet werden, auch in ihren Abteilungen entsprechend auf Akzeptanz stoßen. Insofern sollten für Prozessoptimierungsteams erfahrene und gut verankerte Mitarbeiter der betreffenden Fachabteilungen nominiert werden. Dabei sollten alle beteiligten Bereiche gleich vertreten sein, idealerweise jeweils mit einem oder maximal zwei Teilnehmern, je nach der Anzahl der beteiligten Bereiche, damit das Optimierungsteam in Summe nicht zu groß wird. Die Einbindung des Controllings ist nicht immer und nicht unbedingt durchgängig erforderlich. Bei Optimierungen, die vor allem Kosten- und Effizienzziele verfolgen, sollte das Controlling jedoch zumindest punktuell und vor allem bei der Konkre335 Vgl. Becker, Schmidt in Horváth & Partners (2005), S. 111–113. Ebenso Mayer (1996), S. 60–62. Vgl. dazu auch den Ansatz des gruppenorientierten Kaizen, bei dem ebenfalls zur Optimierung eine Gruppe aus den am Prozess beteiligten Personen gebildet wird. Siehe Teufel (2009), S. 680.

236


tisierung der Verbesserungen an den Workshops teilnehmen, um die damit erzielten Einsparungen und Effizienzgewinne zu verstehen und gleichzeitig die korrekte Abschätzung der kostentechnischen Auswirkungen sicher zu stellen. Auf diese Weise ist eine konsistente Abschätzung der Benefits entsprechend den dafür gültigen Standardvorgehensweisen, Standardkostensätzen und -kostenarten gewährleistet. Bei Prozessoptimierungen, bei denen zu vermuten ist, dass ein Teil des Verbesserungspotenzials in den unterstützenden IT Systemen liegt, empfiehlt es sich weiters, auch einen Vertreter der IT in das Team zu nominieren. Für die rein fachliche Optimierung des Prozesses wäre dies zwar nicht zwingend erforderlich. Durch die Einbindung kann aber auch in Richtung der IT-Systeme die Machbarkeit frühzeitig überprüft und zudem auch die Akzeptanz der Vorschläge in der IT für die spätere ITtechnische Umsetzung besser gewährleistet werden. Ergänzend zum Prozessoptimierungsteam wird – insbesondere bei umfangreicheren Prozessoptimierungen – ein Lenkungsausschuss als Steuerungsgremium eingerichtet. Er besteht aus dem beauftragenden Process Owner, der gleichzeitig der Sponsor der Optimierung und somit auch der Vorsitzende und Meetingowner des Lenkungsausschusses ist, sowie 3–5 weiteren Managern. Je nach dem zu optimierenden Prozess sind dies typischerweise andere betroffene Process Owner im Unternehmen oder aber Leiter wichtiger betroffener Abteilungen. Bei übergreifenden Prozessen mit dezentral ausgeführten Teilprozessen ist es auch sinnvoll, einen Vertreter einer Niederlassung in den Lenkungsausschuss zu nominieren. Der Lenkungsausschuss erfüllt im Wesentlichen dieselben Aufgaben wie Lenkungsausschüsse in anderen Projekten: Er erteilt den Projektauftrag mit dem Optimierungsziel, bewilligt das Vorgehen und die Terminplanung, lässt sich über den Fortschritt der Arbeit des Teams berichten und steuert dabei die Richtung dieser Aktivitäten soweit notwendig, nimmt Teilergebnisse ab und entscheidet am Ende über die vorgeschlagenen Optimierungsmaßnahmen und den neuen Sollprozess. Während Teilprozessoptimierungen sich meist innerhalb von bestimmten Bereichen oder Abteilungen abspielen und daher oft ohne Lenkungsausschuss durchgeführt werden, kommt diesem bei einer End-to-End-Optimierung von Geschäftsprozessen eine erfolgskritische Bedeutung zu. Denn nur hier können auf Managementebene entsprechende Entscheidungen getroffen und aufkommende Konflikte zielorientiert behandelt werden. Den Optimierungsauftrag erhält das Prozessoptimierungsteam vom zuständigen Prozess Owner. Das grundsätzliche Vorhaben wird von ihm mit den anderen Process Ownern im Vorfeld im Process Board abgestimmt. Der Optimierungsauftrag muss folgende Punkte enthalten: · · · ·

eine kurze Zusammenfassung des Ist-Standes des Prozesses die angestrebte Zielsetzung der Prozessoptimierung eine kurze Begründung dieser Zielsetzung Budget- und Zeitrahmen

237


Dieser Optimierungsauftrag ist der Auftrag des Prozess Owners an das Prozessoptimierungsteam. Er ist somit der Ausgangspunkt der Optimierung und wird im Kickoff Meeting dem Optimierungsteam vorgestellt und übergeben. Idealerweise sollte dies auch tatsächlich durch den Process Owner selbst erfolgen, um dem Auftrag das entsprechende Gewicht zu verleihen und auch das Commitment des Managements zur Optimierung entsprechend zu dokumentieren. Ohne dieses Commitment des Managements ist die Gefahr eines Scheiterns oder zumindest das Risiko, dass die Ziele nur zu einem Teil erreicht werden, sehr groß.336 Beim Aufsetzen des Optimierungsteams hat es sich bewährt, kurze Stakeholdergespräche mit den beteiligten Process Ownern, Bereichs- und Abteilungsleitern zu führen. Einerseits dienen diese Gespräche dazu, eine entsprechende Unterstützung für die Optimierung zu bereiten, andererseits auch dazu Erwartungen, Interessen und Bedenken frühzeitig kennenzulernen und aufzugreifen. Zum Dritten wird in diesen Vorbereitungsgesprächen die Bitte um Nominierung entsprechender Teammitglieder platziert und das Idealprofil für diese Teammitglieder kommuniziert, wie dies oben beschrieben wurde. Des Weiteren werden in der ersten Phase die Arbeiten des Optimierungsteams vorbereitet, etwa durch Recherche der Unterlagen und Prozessmodelle zum Ist-Prozess, die Vorbereitung der Projektablage und gegebenenfalls das Einbeziehen eines externen Beraters. Ist dies erfolgt, so wird der Kick-off Workshop vorbereitet. In diesem Kick-off geht es darum, den Optimierungsauftrag an das Optimierungsteam zu übergeben, die Wichtigkeit der Optimierung herauszustreichen und ein gemeinsames Verständnis über die Eckpunkte der Optimierung herzustellen. Die Vorstellung des Optimierungsauftrags erfolgt dabei idealerweise durch den beauftragenden Process Owner persönlich. Hinsichtlich des gemeinsamen Verständnisses sind vor allem eine einheitliche Interpretation des Auftrags, der damit verfolgten Ziele und angewendeten Messkriterien sowie über den genauen Umfang und die Grenzen des zu optimierenden Prozesses herzustellen. Teilergebnis dieser Phase ist ein arbeitsfähiges Optimierungsteam. Auf den Kick-off folgt in Phase zwei die Herstellung einer ausreichenden Transparenz und eines gemeinsamen Verständnisses über den Ist-Prozess als Ausgangslage. Hierfür werden vorbereitend alle Prozessmodelle, Dokumentationen und Unterlagen zusammengetragen und gesichtet, die den betreffenden Prozess beschreiben. Gibt es bereits ein Prozessmodell mit aktuellen Detailablaufmodellen, so ist dies rasch erledigt. Gibt es dieses nicht und ist auch keine aktuelle oder nur eine partielle Dokumentation vorhanden, so muss in vorbereitenden Meetings mit den Beteiligten der Ist-Prozess stückweise zusammengetragen werden. Dieser Ent336 Vgl. dazu auch Rudolf Wilhelm (2007), S. 60 in Bezug auf das Optimierungsziel der Standardisierung von Prozessen. Ebenso EABPM (2009, S. 142), für die der wichtigste Faktor zur Prozessgestaltung die aktive Beteiligung und führende Rolle des Top-Managements ist.

238


wurf des Ist-Prozesses wird im zweiten gemeinsamen Workshop durchgesprochen, ergänzt und finalisiert. Diese Transparenz über den Prozess ist eine wesentliche Grundlage für die weiteren Schritte. 337 Dabei können bereits auffallende Schwachstellen festgehalten und für die spätere Schwachstellenanalyse vermerkt werden. Zielt die Optimierung vor allem auf eine Kosten- und Effizienzverbesserung, so schließt sich an die Detailerhebung des Ist-Prozesses auch eine Erhebung der Prozesskosten oder zumindest der gebundenen Ressourcen in Form von Mitarbeitervollzeitäquivalenten (FTE) an. Die Prozesskostenrechnung ist im Rahmen des Prozessmanagements damit ein wichtiges Instrument zur Herstellung der Prozesstransparenz. Anders als für andere Einsatzzwecke der Prozesskostenrechnung reicht für die Prozessoptimierung jedoch vielfach eine etwas vereinfachte und pragmatischere Vorgehensweise aus, als dies etwa für Zwecke der Kalkulation, der Leistungsverrechnung oder einer prozessorientierten Deckungsbeitragsrechnung erforderlich ist. In manchen Fällen, in denen sehr personalintensive Prozesse optimiert werden sollen, beschränkt man sich daher auf die Analyse der in den Prozessen gebundenen Ressourcen und die damit verbundenen Personalkosten; andere Kostenarten müssen demgegenüber dort einbezogen werden, wo Potenziale und Maßnahmen auch in anderen Faktoren als den Personalressourcen vermutete werden. Insofern ist wichtig, dass die Prozesskostenrechnung ein Instrument des Prozessmanagements aber auch ein Instrument des Kostenmanagements im Controlling sein kann.338 Im Zusammenhang des Prozesskostenmanagements kann die Prozesskostenrechnung zur Herstellung der Transparenz und zur Analyse der Prozesse aus Kostengesichtspunkten eingesetzt werden. Ist dies der Fall, so bildet sie gleichzeitig auch die Grundlage für die kostenmäßige Bewertung der erzielten Optimierungseffekte und deren späterer Nachverfolgung und Validierung im Rahmen des Benefit Trackings.339 Darüber hinaus kann mit dem Mittel der Prozesskostenrechnung auch die Planung der für einen Prozess notwendigen Personalressourcen erfolgen. Geht man bei der normalen Anwendung der Prozesskostenanalyse davon aus, dass die Mengen der Kostentreiber und die Kostenstellenkosten als Inputgrößen dienen und daraus die Prozesskostensätze ermittelt werden, so dreht sich hier die Berechnungslogik um: 337 Prozesstransparenz ist jedoch in diesem Sinn nur ein Hilfsmittel für das Managen der Prozesse und daher nicht mit diesem gleichzusetzen. Siehe auch Mayer, Brenner in Horváth & Partners (2005), S. 20. 338 Für eine Darstellung der unterschiedlichen Handlungsfelder der Prozesskostenrechnung sowie der konkreten Anwendung siehe etwa Mayer, Coners, von der Hardt in Horváth & Partners (2005), S. 123–158. 339 Vgl. dazu auch die davon abweichende Sichtweise im Kaizen: Anders als im hier vorgestellten Managementansatz von Prozessmanagement stehen dabei nicht Einsparungen oder quantifizierbare Verbesserungen des Prozesses im Vordergrund, sondern die motivierende Wirkung auf das Mitarbeiterverhalten. Siehe Teufel (2009), S. 680.

239


Abb. 75: Mengenabhängige Variabilisierung der Kosten durch den Prozesskostenansatz

Aus den Prozesskostensätzen und der Ressourcenbeanspruchung je Prozessinstanz werden über abgeschätzte künftige Mengen die gesamt notwendigen Personalkapazitäten in den beteiligten Kostenstellen abgeschätzt. Dieses Vorgehen kann vor allem in Zeiten einer sehr dynamischen Geschäftsentwicklung – etwa in starken Wachstumsphasen oder auch in Krisenzeiten mit stark einbrechenden und dann wieder steigenden Auftragsmengen – ein sehr hilfreiches Instrument zur Abschätzung der optimalen Ressourcenausstattung sein. Denn erfolgt der Aufbau der Ressourcen zu langsam, so können dadurch Geschäftschancen verloren gehen, was insbesondere in Zeiten des Aufschwungs nach einer Krise einen Nachteil gegenüber den Wettbewerbern bedeuten kann. Wird der Ressourcenaufbau jedoch zu rasch vorgenommen, so kann dies zu verminderten Erträgen und im Extremfall sogar zu Risiken für das Unternehmen als solches führen.340 Die Prozesskostenbetrachtung liefert so die Basis für eine sachgerechte Planung und Anpassung der notwendigen Ressourcen und Kapazitäten.341 Die Daten der vorausgegangenen Prozessmessung fließen hier natürlich mit ein und sind ein weiterer Baustein für die Prozesstransparenz; je nach Erfordernis werden sie jedoch auch noch um weitere Detaildaten zum Prozess ergänzt. In der Praxis wird gerade von Vorständen und Geschäftsführern immer wieder die Frage gestellt, ob denn eine derart genaue Ist-Erhebung des Prozesses tatsächlich notwendig sei. Es wäre doch effizienter, sich gleich auf den Sollprozess zu konzentrieren, ohne vorhergehende Ist-Erhebung. Zudem würde die Beschäftigung mit dem Ist-Prozess 340 Siehe dazu auch Bergsmann, Brenner (2008). 341 Vgl. Mayer (1996): „Mit der Prozesskostenrechnung kann die Redimensionierung der Kapazität als Folge reduzierter Prozeßmenge unmittelbar auf die Kostenstelle heruntergebrochen werden, Voraussetzung für eine sachgerechte Kapazitätsanpassung“ (S. 59).

240


Abb. 76: Vorteile einer Erhebung der Ist-Prozesse

die Kreativität doch nur einschränken, und man wolle den Ist-Prozess ja so oder so in der Form nicht beibehalten.342 Prinzipiell ist dies natürlich möglich, jedoch nicht empfehlenswert. Denn zum einen bedeutet das Weglassen der Ist-Analyse den Verzicht auf die Bewertung und Überprüfung der erzielten Optimierungseffekte. Ein solches Benefit Tracking bedingt eine klare Ausgangslage (baseline), die nur durch den Ist-Prozess und die Ist-Prozesskosten möglich ist. Zum anderen läuft eine Optimierung, die sich ohne Ist-Analyse sofort in das Solldesign stürzt, Gefahr, dass die einzelnen Beteiligten im Team von einem unterschiedlichen Wissensstand ausgehen. Denn meistens haben nur ganz wenige den End-to-End-Überblick über einen Prozess. Das gemeinsame Erarbeiten des Ist-Prozesses schafft daher einen gemeinsamen Wissensstand und trägt auch vielfach schon für sich alleine signifikant dazu bei, bereits vor dem Design des Sollprozesses ein echtes End-to-End-Verständnis für einen Prozess zu entwerfen. Zudem tauchen alle Beteiligten damit in die Details des Prozesses ein und laufen damit weniger Gefahr, einen Sollprozess und Optimierungsmaßnahmen zu entwickeln, die sich in weiterer Folge als nicht umsetzbar herausstellen. Darüber hinaus wird durch die Erarbeitung des Ist-Prozesses eine klare Brücke vom derzeitigen Prozess zum künftigen, optimierten Prozess hergestellt, die die Umsetzung und das Verständnis über die durch die Optimierung geplanten Änderungen unterstützt. Damit ist bereits eine wesentliche Grundlage für das Change Management für den neuen Prozess geschaffen. Dass die intensive Beschäftigung mit dem Ist-Prozess ein Risiko bedeutet, zu sehr im Bestehenden verhaftet zu bleiben, ist durchaus der Fall – diesem Risiko kann jedoch durch einen neutralen Moderator im Team bewusst gegengesteuert werden. Eine Erhebung des Ist-Prozesses ist daher ein sehr sinnvoller Schritt – ein Weglassen der Ist-Erhebung ist mit wesentlichen Nachteilen verbun342 Siehe dazu z. B. auch Schmelzer, Sesselmann (2010), für die eine zu intensive Auseinandersetzung mit dem Istzustand den Blick auf bessere Alternativen verdecke (S. 133). Vgl. auch Hammer, Champy (1994).

241


den.343 Geary Rummler, Alan Ramias und Richard Rummler bringen dies sehr treffend auf den Punkt: „one should always understand the condition of an existing ‚is‘ process before deciding how much surgery is required“.344 In Verbindung mit der Transparenz über den bestehenden Prozess und dessen Leistungsfähigkeit ist es vielfach interessant, die eigene Prozessperformance mit der anderer Unternehmen zu vergleichen. Als Mittel hierfür kann ein Prozessbenchmarking hilfreich sein.345 Dabei werden die Werte des betrachteten Prozesses für die definierten Prozesskennzahlen mit Werten vergleichbarer Prozesse innerhalb oder außerhalb des Unternehmens gegenübergestellt. Die Vergleichbarkeit ist dabei über eine vergleichbare Leistung des jeweiligen Prozesses zu definieren, das heißt, ob der Vergleichsprozess eine Leistung als Prozessergebnis erbringt, die mit der Leistung des zu analysierenden eigenen Prozesses substituierbar oder gleichwertig wäre. Nicht wesentlich für die Vergleichbarkeit ist hingegen der konkrete Ablauf des jeweiligen Prozesses. Innerhalb eines Unternehmens kann dies zum Beispiel durch einen Vergleich einund desselben Prozesses in verschiedenen Niederlassungen erfolgen, mit dem dieselbe Prozessleistung erbracht wird, also etwa ein Vergleich des Prozesses „Ersatzteile anbieten“ in der Niederlassung Wien mit demselben Prozess in den Niederlassungen Salzburg und Prag im Hinblick auf die Durchlaufzeit oder die Prozesskosten. Ebenso ist ein Vergleich mit anderen Unternehmen möglich, die Herausforderung besteht hier jedoch im Finden geeigneter Partner sowie entsprechender Benchmarkdaten. Aktuell in Benchmarkdatenbanken verfügbare Daten beziehen sich meist nicht auf End-toEnd-Prozesse, sondern auf Funktionen, wie etwa Debitorenbuchhaltung, Kreditorenbuchhaltung, oder Einkauf. Dort wo eine wirkliche Prozessorientierung in den Benchmarkdaten vorliegt, handelt es sich meist um detaillierte Teilprozesse, wie etwa Bestellabwicklung, Eingangsrechnungsverbuchung oder Fakturierung. Der Großteil der Benchmarkvergleiche erfolgt in der Praxis daher auch auf funktionaler oder Teilprozessebene. Dies ist per se keineswegs schlecht, da ja auch Funktionen oder Teilprozesse mit dem Mittel des Benchmarkings verglichen und darauf aufbauend optimiert werden können. Der hier vertretene Ansatz, dass sowohl die Funktions- als auch die Prozesssicht auf das Unternehmen wichtige und sich gegenseitig ergänzende Perspektiven sind, ermöglicht dies. Vorsicht sollte jedoch bei der Bezeichnung der jeweiligen Benchmarkingvorhaben gelten: Vieles, was in den Unternehmen heute als „Prozess343 Vgl. dazu auch Klimmer (2007, S. 128): Für ihn ist die Transparenz der existierenden bzw. neu zu gestaltenden Prozesse für eine effektive und effiziente Prozessgestaltung unabdingbar. Vgl. auch Schwegmann, Laske (2008, S. 155 f.), die ebenso eine – wenn auch rudimentäre – Ist-Modellierung für sinnvoll halten. Vgl. auch Österle (2010/1995, S. 94): Für ihn ist die Erhebung des Ist-Standes zur Überprüfung der Vollständigkeit sowie zur Erklärung der Veränderungen durch den neuen Soll-Prozess erforderlich. 344 Rummler, Ramias, Rummler (2010), S. 13 und S. 138. Ähnlich auch Verner (2004), Davenport (1993), S. 137–138. 345 Siehe dazu z. B. Renner (2005); Schimank (1998); Küting (1996); Kohl (2001), Bogaschewsky, Rollberg (1998), S. 273–283.

242


benchmarking“ durchgeführt wird, vergleicht nicht Prozesse im Sinne der hier entwickelten Definition, sondern Unternehmensfunktionen und Teilfunktionen. Aufgrund der Verfügbarkeit von Benchmarkdaten ist dies derzeit auch kaum anders möglich. Dort wo man ein echtes Prozessbenchmarking durchführen will, muss man sich entweder auf konkrete Teilprozesse konzentrieren oder aber – wenn tatsächlich komplette End-to-End-Prozesse einem Benchmarking unterzogen werden sollen, ein eigenes Benchmarkingprojekt starten. Beratungsunternehmen können hier die Funktion von neutralen Vermittlern zwischen den Benchmarkpartnern übernehmen. Neben der Sicherstellung der Vergleichbarkeit der Benchmarks ist die zweite große Herausforderung die Art der Nutzung der Benchmarks. So sind Benchmarks nicht per Definition gleichzusetzen mit den angestrebten Zielwerten. Sie sind vielmehr Orientierungspunkte, um die eigene Prozessperformance besser einschätzen zu können. Gleichzeitig fungieren sie auch als Katalysatoren für die Analyse und für die Optimierungsdiskussion, da bei entsprechender valider Vergleichbarkeit natürlich die Frage im Raum steht, warum man selbst schlechter abschneidet als der Benchmarkpartner oder der anonyme Benchmarkwert. Dies führt einerseits zur Identifikation von Faktoren, mit denen Unterschiede erklärt werden können: Zum Beispiel hat man den eigenen Standort etwa in einer Region mit höheren Lohnkosten als andere oder hat durch Auslagerung bei dislozierten Lieferanten etwas längere Transportzeiten einzurechnen. Andererseits kann die Lücke zum Benchmark auch genutzt werden, um die Dynamik bei der Suche nach Verbesserungsansätzen zu unterstützen. Dies kann sowohl durch neue Ideen als auch durch das Hinterfragen der identifizierten Erklärungsfaktoren erfolgen. Werden Benchmarks zur Messung der Prozessperformance eingesetzt, so sind diese beiden Punkte – die Vergleichbarkeit sowie die Interpretation der Benchmarks – erfolgskritisch. Um diese Faktoren ausreichend sicher zu stellen, empfiehlt sich für ein ernstzunehmendes Benchmarking, dieses mit einem externen Partner als Projekt aufzusetzen und durchzuführen. Nur dann können diese beiden Erfolgsfaktoren mit der geforderten Sorgfalt beachtet und berücksichtigt werden.346 Das Ergebnis der Phase der Prozessoptimierung ist eine ausreichende Transparenz über den Ist-Ablauf und dessen Leistungsfähigkeit sowie ein gemeinsamer Wissensstand über den Ist-Prozess in einer echten End-to-End-Sicht. Im dritten Schritt der Optimierung erfolgen die Schwachstellenanalyse und das Design eines neuen Sollprozesses. Hierfür werden in einem Workshop im Team die Schwachstellen strukturiert erhoben und konsolidiert. Gleichzeitig werden auch jene Teile oder Aspekte des Prozesses festgehalten, die gut funktionieren und beibehalten werden sollten.347 Die einzelnen Inputs der Beteiligten werden dabei im Team einge346 Siehe dazu z. B. Renner in Horváth & Partners (2005), S. 69–82. 347 Vgl. Klimmer (2007, S. 132). Ebenso Hiller, Minar-Hödl, Zahradnik (2010), S. 97.

243


bracht, besprochen und schließlich gewichtet. Für die weitere Arbeit ist es zudem sinnvoll, die identifizierten Schwachstellen kurz zu beschreiben, um auch zu einem späteren Zeitpunkt noch genau zu wissen, was genau gemeint war und auch um unter den Teilnehmern ein gemeinsames Verständnis der Schwachstellen zu erreichen und unterschiedlichen Interpretationen vorzubeugen. Bewährt haben sich dafür einfache Vorlagen zur Schwachstellendokumentation, die folgende Informationen kurz und im Überblick festhalten:348 · · · · ·

Name der Schwachstelle kurze Beschreibung in zwei bis drei Sätzen betroffene Stellen oder Abteilungen eine laufende Nummer zum leichteren Referenzieren gegebenenfalls bereits eine Klassifizierung in einige Schwachstellentypen – z. B. Ablaufstruktur, IT-Unterstützung, Kapazitäten, Qualifikation, . . . Dies ist vor allem bei einer größeren Anzahl identifizierter Schwachstellen zur Gliederung hilfreich.

Damit entsteht eine gemeinsame Sicht des Teams auf die Schwachstellen im Prozess und die wichtigsten Knackpunkte. Aufbauend darauf wird ein neuer Sollprozess erarbeitet. Hierbei kommt dem Moderator die wichtige Rolle zu, von der Analyse der realen Situation nun auf einen kreativen Teil der Optimierung umzuschwenken. Die Ideenfindung für Verbesserungen und Prozessänderungen kann dabei mit einem einfachen Brainstorming oder Brainwriting starten.349 Als Rahmen für die Überlegungen dient dabei die Vorstellung von einem Idealprozess ohne einschränkende Rahmenbedingungen.350 Dies ist sinnvoll, um nicht nur kleinere, sondern durchaus auch radikalere und weitreichendere Prozessänderungen in Betracht zu ziehen. Gerade in dieser Hinsicht hat der Moderator die Aufgabe eines Challengers, der Bisheriges und Gewohntes ohne Rücksicht auf irgendwelche Interessen hinterfragt und auch unkonventionelle und auf den ersten Blick unrealistische Ideen und Anregungen einbringt. In einer strukturierten Diskussion wird so der Ist-Prozess mit seinen Schwachstellen durchgegangen und versucht, über Änderungen im Prozess diese zu beseitigen und den Prozess im Hinblick auf die gesetzte Zielsetzung zu verbessern. Das Ergebnis dieser Diskussion sind Maßnahmen, mit denen der Prozess verändert und vom Ist-Zustand in das Soll-Design überführt wird. Die so aufgebrachten Vorschläge werden im Team diskutiert und auf ihre Umsetzbarkeit und mögliche Wirkung analysiert. Dabei werden auch die für die Umsetzung notwendigen Investitionen und Aufwände abgeschätzt, ebenso wie die daraus zu erwarten348 Vgl. dazu Schwegmann, Laske (2008), S. 180. 349 Für eine Beschreibung von in der Organisationslehre etablierten Kreativtechniken und ihrer spezifischen Vor- und Nachteile siehe z. B. Klimmer (2007), S. 272–278. 350 Vgl. Mayer (1996), S. 61; ebenso z. B. Speck, Schnetgöke (2008), S. 209–210.

244


den Benefits und Auswirkungen auf die Zielsetzung im Sinne der definierten Prozesskennzahlen. Die Identifikation der Schwachstellen und die Erarbeitung des Sollprozesses kann dabei mit verschiedenen Methoden und Ansätzen unterstützt werden. Hierfür kommen etwa die bewährten Instrumente der Workshopmoderation infrage, wie sie meist in der klassischen Prozessoptimierung zum Einsatz kommen. Alternativ können hierbei aber auch zum Beispiel die verschiedenen Werkzeuge des Kaizen oder des Leanund SixSigma-Ansatzes genutzt werden.351 Die Frage ist dabei weniger, welche die „richtigen“ Methoden und Werkzeuge für eine erfolgreiche Optimierung sind. Genauso, wie in der Heimarbeit manche Leute lieber diese Zange und andere lieber eine andere verwenden, können durchaus mit verschiedenen Werkzeugen und Vorgehensweisen gute Ergebnisse erzielt werden. Entscheidend ist hier vielmehr, dass die Arbeit und der Einsatz mit einer entsprechenden Zielorientierung und Konsequenz erfolgt. Sicher sind manche Methoden für manche Problemstellungen und manche Situationen prinzipiell besser geeignet als andere; mindestens genauso wichtig wie diese grundsätzliche Eignung ist jedoch der Fit der Methode zum Optimierungsteam, die Beherrschung der jeweiligen Instrumente und der Glaube an ihre Wirksamkeit. Gerade beim Einsatz komplexerer Methoden besteht die Gefahr, dass bei suboptimaler Beherrschung oder einer Ablehnung durch Teile des Teams trotz der methodischen Richtigkeit und Eignung keine optimalen Ergebnisse erzielt werden. Leider wird viel zu oft die Auswahl und Anwendung einer bestimmten Methode als Richtungsstreit zelebriert, die wichtiger genommen wird als die Erreichung der gesetzten Zielsetzung. Kurz: ob Lean-, SixSigma, klassische Optimierung oder andere Methoden – es ist sekundär, welcher Ansatz verwendet wird, solange die jeweilige Methode nur von allen mitgetragen, konsequent verfolgt, professionell angewendet und mit einer guten Portion Begeisterung eingesetzt wird. Frei nach dem Motto des methodischen Anarchismus von Paul Feyerabend: anything goes – . . . solange es mit Konsequenz, Nachdruck und Überzeugung umgesetzt wird.352 Zum Vergleich verschiedener Alternativen des Sollprozesses sowie zur Abschätzung der benötigten Kapazitäten kann es im Einzelfall sinnvoll sein, eine Prozesssimulation durchzuführen. Um sinnvolle Ergebnisse zu erzielen, müssen dafür jedoch einige Rahmenbedingungen erfüllt sein: So müssen die dazu verwendeten Prozessmodelle exakt und mit einem ausreichenden Formalisierungsgrad vorliegen, teilweise 351 Vgl. dazu z. B. die Darstellung der sieben Verschwendungsarten im Kaizen-Ansatz bei Teufel (2009), S. 682 f. Oder etwa die 7M-Methode bei Wagner (2001), S. 40–41. 352 Paul Feyerabend (1993); Vgl. dazu z. B. auch die Haltung der EABPM, die in ihrer Übersicht verschiedene Methoden darstellt aber festhält, dass es jedem Experten selbst überlassen bleiben soll, die für die jeweilige Aufgabenstellung und das jeweilige Umfeld passenden Instrumente, Tools und Vorgehensweisen auszuwählen. Dies gilt für die EABPM insbesondere auch für die verwendete Darstellungsform, soweit diese in der Lage ist, die relevanten Sachverhalte abzubilden. EABPM (2009), S. 25.

245

Abb. 77: Gestaltungsparameter für die Prozessoptimierung


müssen sie auch besonderen Modellierungskonventionen genügen, damit sie durch die Simulationstools verarbeitet werden können.353 Darüber hinaus müssen ausreichend gute Daten für die notwendigen Simulationsparameter vorliegen: Dies reicht etwa von den Mengengerüsten der Instanzen und ihrer Verteilung über die Periode (Tage, Woche, . . .), über die Ressourcen und ihre Verfügbarkeiten und die notwendigen Bearbeitungszeiten je Prozessschritt bis hin zu den exakten Bedingungen oder Wahrscheinlichkeiten bei Prozessverzweigungen. Beides – sowohl die Exaktheit der Modelle sowie auch die Verfügbarkeit ausreichend guter Daten ist in der Praxis oft problematisch.354 Prozesssimulationen sind daher zwar verlockend, in vieler Hinsicht aber sehr risikoreich und gefährlich. Denn gibt es im Simulationsmodell oder den zugrunde gelegten Inputdaten signifikante Fehler, so kann dies zu falschen Entscheidungen und zur Implementierung von suboptimalen Prozessdesigns führen. Wenn überhaupt, sollten Prozesssimulationen daher nur gemeinsam mit erfahrenden Experten oder Beratern durchgeführt werden. Aufgrund der angeführten Komplexität und des mit einer Simulation verbundenen Aufwands sollte daher immer vorab geprüft werden, ob die erwarteten Analyseergebnisse nicht auch auf anderem Weg ohne Simulation mit ausreichender Näherung erarbeitet werden können – nur wenn dies nicht der Fall ist, die Analyseergebnisse für eine Entscheidungsfindung wirklich notwendig sind und den damit verbundenen Aufwand rechtfertigen, sollte eine Prozesssimulation durchgeführt werden.355 In Schritt vier des Optimierungsvorgehens erfolgen schließlich die Maßnahmenausarbeitung und die Umsetzungsplanung. Hierfür werden nochmals die Machbarkeit und die notwendigen Voraussetzungen für die Umsetzung der Maßnahmen untersucht. Es werden die für die Umsetzung notwendigen Aufwände abgeschätzt. Ebenso wird der damit erwartete Benefit für den Prozess im Sinne der festgelegten Zielsetzung für den Prozess in Bezug auf eine Zeit-, Kosten- oder Qualitätsverbesserung detailliert und mit entsprechenden Berechnungen hinterlegt. Als Teilergebnis des Schritts vier liegen entscheidungsreife Maßnahmenvorschläge vor, die gemeinsam zur Optimierung des Prozesses und zur Erreichung des angestrebten Solldesigns führen. Im optimalen Fall reichen die gefundenen Verbesserungen und der neue Sollprozess aus, um die Zielsetzung des Auftraggebers zu erfüllen. Ist dies nicht der Fall, so muss aufgezeigt werden, wie weit die Lücke durch die Maßnahmen geschlossen werden kann. Dieser Vorschlag wird dann dem jeweiligen Process Owner oder dem Process Board zur Entscheidung vorgelegt. Im Falle eines positiven Beschlusses wird gleichzei353 So ist etwa bei der Nutzung der Methode der ereignisgesteuerten Prozessketten (EPK) für die Simulation eine konsequente Abfolge von Ereignis-Funktion-Ereignis gefordert, während für eine reine Organisationsmodellierung sonst Trivialereignisse zwischen Funktionen ohne Verzweigung üblicherweise weggelassen werden. 354 Vgl. auch Speck, Schnetgöke (2008), S. 215–217. 355 Vgl. Rabe, Knothe (2010), S. 476–477. Für ein Vorgehensmodell für Prozesssimulationen siehe Neumann, Rosemann, Schwegmann (2008), S. 438–440.

247


Abb. 78: Maßnahmenpriorisierungsportfolio

tig auch das Budget für die Umsetzungsaufwände bereitgestellt und bewilligt sowie das Commitment zu den durch die Optimierung erwarteten Verbesserungen nochmals eingeholt und bekräftigt. Dieses betrifft dann sowohl die für die Umsetzung notwendigen Ressourcen und Investments als auch die erwarteten Benefits und Verbesserungen. Ergebnis dieses Schritts ist ein Umsetzungsauftrag für die beschlossenen Optimierungsmaßnahmen. Als Verantwortlicher für die Umsetzung wird damit idealerweise der Leiter des Optimierungsteams beauftragt, um damit einerseits Kontinuität sicherzustellen andererseits durch diese Festlegung auch bereits in der Designphase sicherzustellen, dass nur Vorschläge vorgelegt werden, die tatsächlich auch umsetzbar sind. Die Umsetzung der Maßnahmen wird dann mit den üblichen Mitteln der Projektarbeit begleitet, insbesondere einem Status- und Fortschrittsreporting an den Auftraggeber. Begleitend sind in dieser Phase Maßnahmen zur Vorbereitung der Organisation auf die Prozessänderungen vorzusehen: also Kommunikation der Neuerungen, gegebenenfalls auch Maßnahmen zum Change Management und zum Training der am Prozess Beteiligten. Gerade der Schulung neuer Prozesse kommt hier eine entscheidende Bedeutung für die erfolgreiche Implementierung zu.356 Hierfür empfiehlt es sich, anschließend an den Beschluss der vorgeschlagenen Prozessänderungen eine Auswirkungsanalyse durchzuführen.357 Bei dieser wird für die beschlossenen Änderungen analysiert, wer von der Änderung betroffen ist und wie die Aufnahme dieser Änderung eingeschätzt wird. Darauf aufbauend werden Maßnahmen zur Unterstützung der Veränderung konzipiert und eingeplant. 356 Vgl. dazu auch Taylor (1911). 357 Vgl. Klimmer (2007), S. 137.

248


Abb. 79: Beispiel für eine Auswirkungsanalyse 5.3.4 Verbesserung der Prozessperformance überprüfen

Sind die Maßnahmen zur Optimierung des Prozesses vollständig umgesetzt, so muss ihre Wirksamkeit im Hinblick auf eine Verbesserung der Prozessperformance überprüft werden.358 Dies erfolgt meist durch eine nochmalige Messung der vereinbarten Kennzahlen zur Feststellung, ob die Zielsetzung für den Prozess nun erreicht wird. Sinnvollerweise erfolgt diese Messung nicht unmittelbar nach dem Start des neuen Prozesses (go-live), sondern erst nach einer Einschwungphase von etwa 3–6 Monaten. Durch das Nachvollziehen der im Umsetzungsauftrag zugesagten Benefits und die Nachkalkulation des Umsetzungsprojekts werden die Effekte der Optimierung validiert. Diese Validierung erfolgt idealerweise durch das Controlling, weshalb auch oben angemerkt wurde, dass eine Teilnahme des Controllings im Zuge der Analyseund Designphase zumindest punktuell sinnvoll ist. Bei besonders kritischen Prozessen kann es auch sinnvoll sein, die Zielerreichung nicht nur einmalig, sondern dauerhaft zu überprüfen und zu kontrollieren. Ist dies der Fall, so wird für die dauerhafte Prozesssteuerung die Prozessmessung für den betreffenden Prozess auch permanent eingerichtet.359 In diesem Fall werden die Messungen der festgelegten Prozesskennzahlen dann nicht nur vor und nach der Optimierung gemessen, sondern auch darüber hinaus in regelmäßigen Abständen. Um die Prozesssteuerung dauerhaft zu etablieren, sollten die Prozesskennzahlen in das bestehende Reporting integriert werden. Das heißt, dass entsprechende Auswertungen dann in die jeweiligen Quartals-, Monats-, Wochen- oder Tagesreports aufgenommen und gleich wie allen anderen Kennzahlen in die Performanceanalyse und -gespräche 358 Fischermanns spricht in diesem Zusammenhang von Prozessbewertung. Fischermanns (2006), S. 23. 359 Eine gute Definition für Prozesssteuerung findet sich bei Scheer: Für ihn heißt „Prozesse steuern“, dass der Prozessverantwortliche dem Kunden Auskunft über den Status seines Prozesses geben kann, die Ressourcen optimal einsetzt sowie Prozessdurchlaufzeiten und Prozessqualitäten laufend kontrolliert“ (Scheer 1998, S. 77). Prozessmonitoring meint hingegen nur einen Teil davon, nämlich dass „den an der Ausführung des Geschäftsprozesses beteiligten und berechtigten Mitarbeitern aktuelle Statusinformationen über die laufenden Geschäftsprozesse gegeben“ wird. (Ebenda).

249


einbezogen werden. Erst mit einer derartigen dauerhaften Messung der Prozessperformance wird ein dauerhaftes Managen der Prozesse etabliert. Der beschriebene Prozess bleibt dabei jedoch prinzipiell derselbe: Die Prozessperformance wird gemessen, im Falle von Lücken zu den angestrebten Zielen wird der Prozess optimiert, anschließend wird die Wirksamkeit der Optimierungsmaßnahmen durch eine neuerliche Prozessmessung überprüft und die Lehren aus der Optimierung gezogen und transferiert. Damit wird der Prozess permanent gesteuert und gemanagt. Über diese Stufe der aktiven Prozesssteuerung hinaus ist auch noch eine weitere Stufe des Prozessmanagements vorstellbar: jene der Selbstregelung der Prozesse. In diesem Fall werden Strukturen und Regelprüfungen in den Prozess integriert, die im Fall bestimmter besonderer Ereignisse oder bei bestimmten Abweichungen von den Zielwerten automatisch Änderungen auslösen, mit welchen die Balance und Stabilität des Prozesses wiederhergestellt wird. Dies entspricht vom Konzept her einem Überdruckventil in einem Heizkessel: Dieses wird nur aktiv, wenn im Kessel zu viel Druck entsteht und lässt in diesem Fall solange Druck ab, bis der normale Betriebsdruck wieder erreicht ist. Bei Prozessen wäre dies etwa denkbar in Form einer automatisierten Zuteilung zusätzlicher Ressourcen für einen Prozess bei Überschreitung einer bestimmten Durchlauf- oder Wartezeit. Oder in Form einer automatischen Umstellung auf ein anderes Arbeitszeit- oder Schichtmodell abhängig von der Anzahl der gestarteten Prozessinstanzen. Um den Unterschied zwischen Prozesssteuerung und Prozessregelung herauszuarbeiten, können wir ein einfaches Beispiel aus dem Alltag des Einkaufens nehmen: Jeder kennt vermutlich die Situation, wenn man in kleineren Supermärkten zur Kasse geht und nur eine von drei oder vier Kassen offen ist. In diesem Fall sammelt sich rasch eine Schlange. Erst wenn die eine, durch die immer länger werdende Schlange überforderte Kassierin eine Taste drückt, läutet es im hinteren Teil des Marktes oder im Lager, um einer der Kolleginnen damit zu signalisieren, dass sie zum Aufmachen einer weiteren Kasse vorne gebraucht wird. Meist erfolgt dieses Läuten erst, nachdem die ersten Kunden in der Schlange ihrem Unmut über die lange Wartezeit Luft gemacht und laut nach einer weiteren Kasse verlangt haben. Diese Form der Reaktion entspricht einer klassischen aktiven Prozesssteuerung: Erst wenn etwas passiert ist oder ein Zielwert verfehlt wird, wird aktiv eingegriffen und damit die Prozessperformance wieder in die erforderlichen Grenzen gebracht. Dabei wäre es ganz leicht, diesen Unmut zu verhindern: Über Zähl-Drehkreuze am Eingang und am Ausgang wäre jederzeit feststellbar, wie viele Kunden zu einem bestimmten Zeitpunkt im Markt sind. Ebenso könnten bei den Kassen mit wenig Aufwand Lichtschranken eingerichtet werden, die das Überschreiten einer bestimmten Länge der Schlange anzeigen. Übersteigt die Anzahl der Kunden im Markt einen bestimmten Wert oder erreicht die Schlange bei den Kassen eine bestimmte Länge, könnte so schon frühzeitig ein Signal an das Mitarbeiterteam gehen. Dann würde bereits eine weitere Kasse offen sein, wenn viele Kunden zur Kasse gehen, oder zumin250


dest eine weitere Kassierin nach vorne kommen, bevor sich die Ungeduld der Kunden entlädt. Zudem würde die Aufforderung, bei der Kasse auszuhelfen, nicht von einer Kollegin kommen müssen, die sich damit vielleicht bei den anderen unbeliebt macht, sondern vom Prozess selbst ausgelöst werden. Dies wäre ein Beispiel für eine Prozessregelung, bei der im Prozess selbst verankerte Strukturen und Prüfungen bei Überschreitung von bestimmten Performancewerten dafür sorgen, dass die Prozessperformance wieder in die akzeptablen Grenzwerte zurückgeführt wird. Solche Prozessregelungen sind jedoch in der Praxis – obwohl im technischen Bereich der Prozesssteuerung Gang und Gäbe – bei betriebswirtschaftlichen Prozessen noch sehr selten zu finden. In der Praxis werden Prozesskennzahlen nach wie vor sehr oft isoliert und völlig unabhängig vom sonstigen Berichtswesen erhoben und berichtet. Dies führt vielfach dazu, dass die Prozesskennzahlen nicht als Teil des Steuerungssystems gesehen und weniger wichtig genommen werden. Ebenso hängt in diesen Fällen das Wissen um die Erhebung und Auswertung der Prozesskennzahlen sowie die Bedienung damit verbundener Prozess Monitoring Tools vielfach an einzelnen Personen. Verlassen diese das Unternehmen oder bekommen sie innerhalb des Unternehmens neue Aufgaben, so sterben die Prozessmessungen oft rasch wieder oder versanden. Um dies zu verhindern und die Messung der Prozessperformance wirklich dauerhaft zu verankern ist eine Integration in das normale und etablierte Berichtswesen notwendig. Erwähnt sei schließlich auch noch eine besondere Art der Überprüfung von Prozessen: das Prozessaudit.360 Ein solches kommt vor allem dann zum Einsatz, wenn das Ziel für einen Prozess weniger eine Verbesserung in der einen oder anderen Dimension ist, sondern darin liegt, einen Prozess möglichst zu standardisieren und damit eine hohe Prozesssicherheit und -stabilität zu erreichen Auch in diesem Fall kann die Überprüfung mit entsprechenden Messwerkzeugen des Prozess Performance Monitorings erfolgen, sofern diese neben der Messung der Kennzahlen auch ein Bild über die konkrete Abarbeitung der einzelnen Prozessinstanzen liefern. Stehen solche Werkzeuge nicht zur Verfügung, so kann dies mithilfe eines Prozessaudits erfolgen. Ebenso erfolgt die Überprüfung der Prozessleistung und erzielter Verbesserungen typischerweise mittels eines Prozessaudits, wenn die angestrebten Verbesserungen vor allem qualitativer Natur und somit einer technischen Messung nicht zugänglich sind. Darüber hinaus kann es auch eine technische Prozessmessung ersetzen, wenn diese im konkreten Fall nur mit sehr großem Aufwand zu realisieren und damit unwirtschaftlich wäre. Bei einem Prozessaudit wird ein neutraler – interner oder externer – Auditor bestimmt, der in einer Vor-Ort-Besichtigung der einzelnen Bearbeitungsstellen für den betreffenden Prozess und durch Gespräche mit den am Prozessbeteiligten ein Bild über die tatsächliche Abwicklung des Prozesses in der täglichen Praxis erhebt. Der Au360 Siehe dazu z. B. Rudolf Wilhelm (2007), S. 73 ff. Ebenso Klimmer (2007), S. 142 f.

251


ditor muss dabei wirklich eine neutrale Position einnehmen, das heißt, er darf selbst keine Interessen an dem betreffenden Prozess haben. Neben externen Auditoren und Prozessexperten kommen daher hierfür auch vor allem Experten aus dem zentralen Prozessmanagementteam infrage oder auch Prozessmanager aus nicht betroffenen Bereichen. Keinesfalls sollte der bestimmte Auditor jedoch aus einer der am Prozess beteiligten Abteilungen kommen oder aus dem Kreis der Prozesskunden. Haben Mitglieder des zentralen Prozessmanagementteams vorher an einer Standardisierung des betreffenden Prozesses in einem Optimierungsteam mitgewirkt, so scheiden auch sie als neutrale Auditoren aus. Bei einer solchen Prozessauditierung geht es vor allem darum zu sehen, ob ein definierter Standardprozess in der Praxis auch tatsächlich gelebt wird und die darin festgelegten Standards und Vorgaben eingehalten werden. Die Ergebnisse werden in einem Auditbericht festgehalten, der den Grad der Einhaltung des Standardprozesses dokumentiert. Ebenso dokumentiert der Auditbericht, wo in der gelebten Praxis genau die Abweichungen vom Standardprozess festgestellt wurden sowie aus welchen Ursachen hier der Standardprozess nicht eingehalten wurde oder eingehalten werden konnte. Gerade diese Ergebnisse des Audits sind in weiterer Folge ein wichtiger Input für die Verbesserung und Weiterentwicklung des Standardprozesses und der Prozessvorgaben. Unabhängig von der Überprüfung der Effektivität von Verbesserungen können solche Prozessaudits auch für die Herstellung der Transparenz am Beginn der Optimierung ein wertvolles Mittel sein. Wichtig ist in jedem Fall wieder eine konkrete und klare Zielsetzung, die mit dem Prozessaudit verfolgt wird. 5.3.5 Learnings ziehen und transferieren

Neben der Validierung der Benefits steht am Ende auch ein kurzes Resümee über die Erfahrungen der Prozessoptimierung (lessons learned) sowie eventuell ein Transfer dieser Erfahrungen auf andere, ähnlich gelagerte Prozesse. Die Aufgabe, diese Lessons Learned festzuhalten, in künftigen Prozessoptimierungen wieder einzubringen und auch auf andere Prozesse zu transferieren, liegt in der Verantwortung des zentralen Prozessmanagementteams.361 Zur Erhebung der Lessons Learned empfiehlt sich ein kurzer strukturierter Workshop mit dem Optimierungsteam nach erfolgter Verifizierung der erreichten Verbesserungen der Prozessperformance. Hierbei werden nicht nur negative Lehren im Sinne von Dingen, die man das nächste Mal anders machen würde, festgehalten. Genauso wichtig ist es, auch die positiven Punkte festzuhalten, die bei folgenden Prozessoptimierungen in jedem Fall wiederholt und beibehalten werden sollten. Die Er361 Die Standardisierung von erfolgreichen Problemlösungen ist etwa auch Teil des Kaizen-Ansatzes. Vgl. Klimmer (2007), S. 139.

252


gebnisse werden übersichtlich dokumentiert und in der Folge an alle Prozessmanager im Unternehmen verteilt. Über mehrere Prozessoptimierungen entsteht daraus eine Lessons-Learned-Checkliste, die ständig wieder genutzt und erweitert wird. Diese Liste verkörpert somit das unternehmensspezifische Anwendungswissen für die Optimierung von Prozessen. Bei folgenden Prozessoptimierungen obliegt es dem zentralen Prozessmanagementteam, diese dokumentierten Lessons Learned wieder herauszuholen und bewusst zu prüfen, ob sie im Set-up der neuen Optimierung relevant sind und berücksichtigt wurden. Zur konsequenten Überprüfung empfiehlt es sich hierbei, die Liste der Lessons Learned wirklich Punkt für Punkt durchzugehen und diese als erfüllt, nicht erfüllt oder nicht relevant zu kennzeichnen. Diese abgehakte Checkliste sollte dem ersten Statusbericht der jeweiligen Optimierung als Anhang beigelegt werden und gegebenenfalls vom zuständigen Process Owner oder vom Process Board eingefordert werden. Wurde zur Überprüfung der Prozesseinhaltung ein Prozessaudit durchgeführt, so werden in diesem Schritt die Ergebnisse des Audits dahin gehend überprüft, ob der vorgegebene Standardprozess und die begleitenden Prozessvorgaben ausreichend geeignet sind, das Ziel der Prozesssicherheit und -stabilität zu gewährleisten. Hier kann es im Sinne von Lessons Learned sinnvoll sein, den Standardprozess zu ändern oder zu ergänzen, die entsprechenden Prozessvorgaben anzupassen oder auch nur die Kommunikation und Schulung des vorgegebenen Standardprozesses zu intensivieren. Mit diesem Schritt schließt sich der Zyklus des gezielten Managens von Prozessen. Wie gezeigt wurde, geht es dabei nicht um bestimmte Methoden oder Werkzeuge, sondern um ein klares zielorientiertes Vorgehen, das sich je nach Bedarf dieser Methoden und Werkzeuge bedient. Geary Rummler, Alan Ramias und Richard Rummler bringen dies gut auf den Punkt: „the ultimate objective of any such effort is the improvement of the performance of a process – the closing of some measureable gap in process results“.362 Die grundsätzliche Vorgehensweise folgt dabei jedoch immer der Abfolge „Ziel festlegen – Transparenz herstellen – Schwachstellen identifizieren – Sollprozess festlegen – Maßnahmen zur Überführung des Ist-Prozesses in den Soll-Prozess entwickeln – Maßnahmenumsetzung entscheiden – Maßnahmen umsetzen – Effektivität überprüfen – Learnings ziehen“. Dies ist der wesentliche Prozess des Managens von Prozessen. In der Praxis gibt es verschiedene Vorgehensmodelle, welche dieses zielorientierte Vorgehen im Sinne eines echten Managens der Prozesse unterstützen. Beispiele hierfür sind etwa der Deming-Zyklus „Planen (Plan) – Tun (Do) – Überprüfen (Check) – Handeln (Act)“ – auch PDCA-Zyklus genannt, das SixSigma-Vorgehensmodell DMAIC: Define – Measure – Analyse – Improve – Control oder auch die Rummler 362 Rummler, Ramias, Rummler (2010), S. 135.

253


Process Methodology363. Neben diesen bekannten Beispielen existieren unzählige Varianten davon, die von verschiedenen Prozessmanagement-Autoren und Beratungshäusern propagiert und eingesetzt werden. Entscheidend ist dabei nicht, welches dieser konkreten Modelle man verwendet, sondern vielmehr, dass es dem grundsätzlichen Managementvorgehen entspricht, wie es hier vorgestellt wurde, und die beschriebenen Elemente in der richtigen Reihenfolge enthält. Entscheidend sind insbesondere die klare Zielorientierung, das Verständnis der verwendeten Methoden und Werkzeuge als reine Mittel zum Zweck sowie die finale Überprüfung der Effektivität. Diskussionen über das beste und richtige Vorgehensmodell sind daher überflüssig und nicht wertschöpfend – entscheidend ist, dass der Managementfokus im gewählten Vorgehen klar im Vordergrund steht und konsequent durchgehalten wird. Nur dann handelt es sich um ein echtes Prozessmanagement, das diesem Begriff auch tatsächlich gerecht wird. Wird Prozessmanagement so verstanden, so wird es jederzeit das Ohr des Managements im Unternehmen finden und als wertvolle zusätzliche Steuerungssicht einen wertvollen Beitrag zur Unternehmensperformance leisten.

363 Für die Rummler Process Methodology siehe Rummler, Ramias, Rummler (2010), S. 131 ff. Für das DMAIC-Modell siehe z. B. Bornhöft, Faulhaber (2010), S. 38–82.

254

6 Zusammenfassung und Ausblick In diesem Buch wurde versucht, das derzeitige Prozessmanagementverständnis, das im Wesentlichen auf Teilprozessen aufbaut und vielfach Prozesse mit Unternehmensfunktionen vermischt, weiter zu entwickeln und auf eine saubere Basis zu stellen. Hierfür wurde mit zahlreichen Ansichten des etablierten Prozessmanagementparadigmas bewusst gebrochen: ·

·

·

·

·

Prozesse sind nicht beliebig definierbar, sie sind nicht einfach beliebige InputOutput-Transformationen, sondern orientieren sich am Bedarf des Kunden und an der Leistung für diesen Unternehmensfunktionen und Prozesse sind keine unversöhnlichen Gegensätze, sondern beides notwendige und einander ergänzende Sichten der Strukturierung von Unternehmen Die Prozessorganisation ist kein anzustrebendes Ziel und auch nicht die notwendige Folge des Prozessmanagements, sondern – von wenigen Ausnahmen abgesehen – eine höchst ineffiziente Organisationsform, die deshalb in der Praxis auch kaum vorkommt Prozessmanagement ist kein Gegenparadigma zur klassischen (funktionalen) Aufbauorganisation, sondern ein Organisationselement der Sekundärorganisation, das gemeinsam mit anderen zusammenwirkt und vor allem die Integrationsfunktion im Unternehmen unterstützen kann Echtes Prozessmanagement verbessert nicht alle Prozesse ständig und strebt nicht für alle Prozesse die höchsten Reifegrade an, sondern konzentriert sich auf die wichtigen Prozesse und entwickelt diese zielorientiert weiter

Diese Brüche sind notwendig, da das etablierte Prozessverständnis und Prozessmanagement an seine Grenzen stößt. Denn bisher wurden Prozesse fast ausschließlich als Teilprozesse (z. B. Auftragsabwicklungsprozess, Zustellungsprozess, Fakturierungsprozess, etc.) oder entlang funktionaler Bereiche (z. B. Vertriebsprozesse, Einkaufsprozesse, Produktionsprozesse, . . .) definiert. Alle diese Prozesse sind jedoch nur Teile größerer Leistungserstellungsprozesse, für die sie entsprechend zusammenwirken. Diese integrative Sichtweise vom Bedarf des Kunden am Beginn (das eine Ende) bis zur Deckung dieses Bedarfs durch die erbrachte Leistung oder das Produkt (das andere Ende) findet sich bisher nur ansatzweise in der Literatur und ebenso wenig in der Praxis des Prozessmanagements. Dort werden Geschäftsprozesse fast ausschließlich als Teilprozesse definiert und gesehen. Das führt dazu, dass der wirkliche Nutzen aus dem Prozessmanagement, die Integration der Leistungserstellung über die Abteilungen hinweg nur sehr bedingt er-


255

Zusammenfassung und Ausblick

kannt und gehoben wird. Zwar ist es mit dem traditionellen Teilprozess-Ansatz gelungen, das Prozessdenken in den Unternehmen zu initiieren, Teilprozesse besser zu integrieren und diese Teilprozesse auch gerade unter Nutzung der Möglichkeiten moderner Informationssysteme zu verbessern. Diese Potenziale sind jedoch in den meisten Unternehmen nun ausgeschöpft. Eine weitere signifikante Optimierung kann nur erreicht werden, wenn die Unternehmen nun den Schritt von der Teilprozesssicht auf die Sicht der gesamten End-to-End-Prozesse der Leistungserstellung machen. Erst damit können Optimierungspotenziale an den Schnittstellen – etwa zwischen Produktentwicklung und Lieferung oder zwischen Vertrieb und Buchhaltung – gehoben werden. Das Buch hat daher versucht, das aktuelle Verständnis von Prozessmanagement zu einem echten Management von End-to-End-Prozessen weiter zu entwickeln, und zwar in viererlei Hinsicht: ·

· · ·

durch die Schärfung des Prozesskonzeptes im Sinne echter End-to-EndGeschäftsprozesse vom Bedarf des Kunden bis zur Leistungserbringung und kompletten Abwicklung des Geschäftsfalles durch die Einordnung des Prozessmanagements in das Gesamtdesign der Strukturgestaltung im Unternehmen, die Gegenstand der Organisationslehre ist durch das Herausarbeiten des besonderen Beitrags als Integrationselement, den das Prozessmanagement in diesem Gesamtbild beisteuern kann und schließlich durch die Betonung des Managementaspekts von Prozessmanagement im Sinne eines echten Managementverständnisses

Erst über dieses weiter entwickelte Verständnis von Geschäftsprozessen in einer Endto-End-Sicht kann der wirkliche Nutzen von Prozessmanagement für das gesamte Unternehmen erreicht werden. Dieser liegt allen voran in der Integration als Ergänzung zur Aufgabengliederung, die durch die Aufbauorganisation erfolgt. Prozessmanagement ist damit nicht – wie traditionell im Prozessmanagement propagiert – ein Alternativszenario zur funktionalen Organisation, sondern vielmehr ein Organisationselement, das hilft, in verschiedenen aufbauorganisatorischen Strukturen die Integration im Sinne der Effektivität und der Effizienz der Leistungserbringung wieder herzustellen und zu verbessern. Existierten Prozessmanagement und Organisationslehre bisher parallel nebeneinander, ohne dass sich das eine Themenfeld intensiver mit dem anderen auseinandersetzte, so erfolgt damit die Zusammenführung beider Themenbereiche als einander ergänzende Designansätze für die Performancesteigerung im Unternehmen. Da der entwickelte End-to-End-Ansatz für Prozessmanagement sehr umfassend ist, ist es in der Praxis notwendig zu fokussieren. Und hier kommt der letzte wesentliche Punkt des Buches im Verständnis von Prozessmanagement ins Spiel: jenes von Prozessmanagement als echtem Managementansatz. Dabei werden nicht alle Prozesse 256


dokumentiert, ständig weiter verbessert und gemessen, sondern es wird ein bewusster Fokus auf die entscheidenden, geschäftskritischen Prozesse gelegt. Sowohl diese Fokusprozesse als auch das Prozessmanagement an sich werden zielorientiert geführt und an ihrem Beitrag zur Unternehmensperformance gemessen. Analog zum generellen Verständnis von Management, das auch nicht alle Dinge ständig im Fokus hat, sondern versucht, sich auf die richtigen Dinge zum richtigen Zeitpunkt zu konzentrieren, wird Prozessmanagement so zu einem zielorientierten, fokussierten und echten Managementansatz entwickelt. Dabei stehen nicht ständige Verbesserungen oder Normen im Vordergrund, sondern einzig die Zielerreichung in Relation zu den gestellten Ansprüchen sowie der Beitrag zur Unternehmensperformance und -steuerung. Wird das Prozessmanagement so verstanden, so kann es einen eigenständigen und sehr wertvollen Beitrag im Unternehmen leisten: jenen der Integration und des Verständnisses der Leistungserstellung im Sinne der gesamten Wertkette und jenen der detaillierten Steuerung erfolgskritischer Prozesse. Gerade in der aktuellen Situation sieht sich das Prozessmanagement dem Dilemma des eigenen Nutzens massiv gegenüber: Der ursprüngliche Beitrag aus der Optimierung von Teilprozessen ist weitestgehend erschöpft; die darüber hinausgehenden Nutzenversprechungen vielfach zu schwammig und zu unkonkret, als dass sie das Gehör des Topmanagements erreichten. Gerade durch die Weiterentwicklung des Prozessverständnisses zu echten End-to-End-Prozessen und der stringenteren Definition des Konzepts an sich, kann der Wertbeitrag des Prozessmanagements klar herausgearbeitet werden: Er liegt in der Integration der Leistungserstellung im Unternehmen, im funktionsübergreifenden Verständnis der Wertkette, in der End-to-End-Optimierung dieser Wertkette über alle Bereiche und Abteilungen sowie in der Erweiterung der Managementperspektive um eine weitere Sicht, und zwar eine, die nahe am Geschäft ist, eine starke Kundenorientierung aufweist und ergänzend zu den etablierten Finanzinformationen eine geschäftsnahe und vorlaufende Steuerung bieten kann. All dies sind Beiträge, die weder die aufbauorganisatorische noch die funktionale Sicht auf das Unternehmen leisten können. Genau dafür braucht es Prozessmanagement. Erich Frese hat in seinem Standardwerk über die Grundlagen der Organisation herausgestrichen, dass sich organisatorische Gestaltung immer in einem Spannungsfeld vollzieht: Einerseits besteht durch die begrenzten Kapazitäten und Fähigkeiten der Ausführenden ein Zwang zur Arbeitsteilung; andererseits steht dem die Überwindung der nachteiligen Folgen der Arbeitsteilung durch Integrationsmaßnahmen im Hinblick auf die Ziele der Organisation gegenüber. Für Frese, einen Vertreter der klassischen Organisationslehre ist die „Unvollkommenheit der Integration [. . .] das Merkmal jeder organisatorischen Regelung.“364 End-to-End-Prozessmanagement, so wie es hier entwickelt wurde, kann einen signifikanten Beitrag leisten, diese Unvollkommenheit der Integration zu vermindern. Es ist somit das gleichberechtigte Pendant zur Aufbauorganisation. 364 Frese (1995), S. 6.

257


In diesem Verständnis ist das Prozessmanagement auch für das Organisationsdesign ein wertvolles Element. Gerade die Organisationslehre hält vielfach leider immer noch an der traditionellen Aufgabenanalyse fest.365 Diese ist als Analyseinstrument zur Verbesserung bestehender Organisationen sicherlich nach wie vor sinnvoll. Als Mittel zur generellen Gestaltung der Organisationsstruktur hat sie jedoch ihre Bedeutung sehr stark eingebüßt und wird in der Praxis so nicht verwendet. Organisationsstrukturen werden heute nicht mehr auf Basis der Durchführung einer Aufgabenanalyse und -synthese entwickelt, sondern auf Basis von Objekten wie Produkten, Märkten, Kunden und generell bekannten Unternehmensfunktionen zusammengestellt. Damit geht die bereichs- und abteilungsübergreifende Sichtweise jedoch verloren.366 Gerade die vielfache Ignoranz bewährter organisationstheoretischer Ansätze, der Radikalismus in Bezug auf die Aufbauorganisation und die bewusste Positionierung als Gegenpol zur klassischen Organisationslehre haben jedoch verhindert, dass sich Vertreter der Organisationslehre eingehender mit dem Prozessmanagementansatz beschäftigt haben. Durch das Verwerfen mancher dieser Positionen und die Einordnung in die Organisationslehre wird das Prozessmanagement auch für diese ein interessantes Element im Gesamtdesign von Unternehmen.367 Wer braucht also Prozessmanagement? – Auf Basis des bisher Gesagten liegt die Antwort auf diese Frage auf der Hand: Es sind jene Unternehmen und Institutionen, die eine stärkere Kundenorientierung anstreben, die ihre interne Integration verbessern wollen und die aufgrund ihres gewählten Organisationsdesigns Ineffizienzen und Ineffektivitäten in ihren abteilungs-, funktions- und bereichsübergreifenden Abläufen erleben. Jene Unternehmen und Institutionen, bei denen durch die Optimierung anderer Organisationsziele oder auch durch andere Entwicklungen – beispielsweise Merger oder Unternehmensaufspaltungen – die Prozessintegration leidet oder beschädigt wurde. Und es sind auch jene Unternehmen und Institutionen, die besondere Steuerungsbedürfnisse haben, für welche die traditionelle Unternehmenssteuerung im Sinne des üblichen Berichtswesens und der etablierten Kosten-/Leistungsrechnung zu schwerfällig und zu wenig am Geschäft ausgerichtet ist. Da in den mehr und mehr käufergetriebenen Märkten gerade die Integration und das Verständnis, die eigene Leistungserstellung schnell und flexibel an dynamische Marktänderungen anzupassen künftig eine der wesentlichen Herausforderungen für den Erfolg von Unternehmen sein werden, darf vermutet werden, dass auch das Pro365 Vgl. z. B. Nicolai (2009), S. 29 ff. 366 Vgl. auch Nicolai (2009), S. 182: Sie beschreibt die Vorgehensweise zum Design der Ablauforganisation nach Nordsieck mithilfe der Arbeitsanalyse und -synthese, die jedoch innerhalb der einzelnen Aufgabenbereiche stattfindet, sodass der Blick über Abteilungsgrenzen hinweg verloren geht. 367 Auf Basis meines Eindrucks ist der Gegensatz zwischen Organisationslehre und Prozessmanagement in der Lehre und Literatur deutlich stärker ausgeprägt als in der Praxis. Hier haben zahlreiche Organisationsentwickler schon lange erkannt, dass beides zusammengehört und dieses in ihren Unternehmen auch so realisiert.

258


zessmanagement und die Prozessorientierung in den Unternehmen weiter an Bedeutung gewinnen. Knut Bleicher bringt es daher auf den Punkt, wenn er es als vordringliche Notwendigkeit sieht, dem Management Konzepte anzubieten, welche die Integration schon von vornherein unterstützen, und dazu festhält: „Für die konzeptionelle Durchdringung der dabei auftretenden Interdependenzen bedarf es eines Bezugsrahmens, der Orientierung und Transparenz für die Integrationsnotwendigkeiten arbeitsteilig differenzierter Systeme schafft“.368 Prozessmanagement auf der Basis von End-to-End-Geschäftsprozessen und verstanden als echter Managementansatz kann genau das leisten.369

368 Bleicher (2009), S. 154. 369 Bleicher selbst verweist auf die Notwendigkeit der Integration durch Strukturen und hier u. a. auf die Ablauforganisation als einem wesentlichen Baustein. Bleicher (2009), S. 157. Vgl. auch Rummler, Remias, Rummler (2010): Auch sie sehen in der End-to-End-Integration der Prozesse (ihrer „Value Creation Architecture“) die Zukunft des Prozessdenkens (S. 95).

259

Literaturverzeichnis Ahlrichs Frank, Knuppertz Thilo (2006): Controlling von Geschäftsprozessen. Prozessorientierte Unternehmenssteuerung umsetzen, Stuttgart. Babbage Charles (1832): On the Economy of Machinery and Manufacturers, Reprint by The Echo Library, Cirencester 2005. Becker Jörg, Kugeler Martin, Rosemann Michael (Hg.) (2008): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung, 6. überarb. u. erw. Aufl., Berlin/ Heidelberg. Becker Jörg, Kahn Dieter (2008): Der Prozess im Fokus. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 3–16. Becker Jörg, Meise Volker (2008): Strategie und Ordnungsrahmen. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 105–154. Becker Ralph, Schmidt Hilmar (2005): Teamorientierte Geschäfsprozessoptimierung. In: Horváth & Partners (2005), a. a. O., S. 107–122. Bergsmann Stefan, Grabek Anna, Brenner Markus (2005): Transparenz durch Prozessanalyse und -modellierung. In: Horváth & Partners (2005), a. a. O., S. 47–68. Bergsmann Stefan, Brenner Markus (2008): Flexible Cost Modeling – Wie ein gutes Prozessmanagement zum Bewältigen der aktuellen Wirtschaftskrise beitragen kann. In: Newsletter der Gesellschaft für Prozessmanagement, Wien, Dezember 2008. Berknau Carsten, Hirschmann Petra (Hg.) (1996): Kostenorientiertes Geschäftsprozessmanagement, München. Binner Hartmut F. (1997): Integriertes Organisations- und Prozeßmanagement, München. Bleicher Knut (2009): Integrationsmanagement. In: Bullinger et al. (2009), a. a. O., S. 153–164. Boch Wolfgang et al. (2006): ITIL. Zertifizierung nach BS 15000/ISO 20000, Bonn. Bogaschewsky Ronald, Rollberg Roland (1998): Prozessorientiertes Management, Berlin et al. Bornhöft Frank, Faulhaber Norbert (2010): Lean Six Sigma erfolgreich implementieren, Frankfurt a. M. BPM Maturity Model EDEN e.V. (2009): EDEN – Reifegradmodell. Prozessorientierung im Unternehmen, o.O. Bruhn Manfred (2009): Das Unternehmen in der Dienstleistungsgesellschaft. In: Bullinger et al. (2009), a. a. O., S. 45–58. Buchenau Gerrit (2010): Referenzmodellbasiertes GPM für Großunternehmen. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 321–351. Bullinger Hans-Jörg et al. (Hg.) (2009): Handbuch der Unternehmensorganisation. Strategien, Planung, Umsetzung, 3. neu bearb. Aufl., Berlin/Heidelberg. Burton et al. (2010): Designing Organizations. 21st Century Approaches, New York. Chang James F. (2006): Business Process Management Systems. Strategy and Implementation, Boca Raton/New York.

261

Literaturverzeichnis

Cilek Peter (2009): Wirtschaftlichkeit im Prozessmanagement. Ein integriertes Modell zur Bewertung von Geschäftsprozessverbesserungen, Saarbrücken. Cisco (2009): Introduction to the eTOM. White Paper, o.O. Davenport Thomas H. (1993): Process Innovation. Reengineering Work trough Information Technology, Boston. Dierkes Meinolf (2009): Theorie und praktischer Nutzen von Unternehmenskultur. In: Bullinger et al. (2009), a. a. O., S. 165–182. Drucker Peter F. (2004): Was ist Management? 2. Auflage, München. Ekman Paul (2011): Ich weiß, dass Du Lügst. Was Gesichter verraten, Reinbek. Ellringmann Horst (2000): Geschäftsprozesse ganzheitlich managen. Leistungsstarke, kundenorientierte Arbeitsabläufe durch Integration von Qualitätssicherung, Umweltschutz und Arbeitssicherheit, Köln. European Association Of Business Process Management EABPM (Hg) (2009): Business Process Management Common Body of Knowledge – BPM CBOK®. Leitfaden für das Prozessmanagement, Gießen. Feyerabend Paul (1993): Against Method, 3rd edition, London/New York. Fischermanns Guido (2006): Praxishandbuch Prozessmanagement, 6. völlig neu bearb. Aufl., Gießen. Frese Erich (1995): Grundlagen der Organisation. Konzept – Prinzipien – Strukturen, 6. Überarb. Aufl., Wiesbaden. Freund Jakob, Rücker Bernd, Henninger Peter (2010): Praxishandbuch BPMN, München. Fürmann Timo, Dammasch Carsten (2008): Prozessmanagement. Anleitung zur ständigen Prozessverbesserung, 3. Auflage, München. Gaiser Bernd (1998): Prozeßkostenrechnung und Activity Based Costing (ABC). In: Horváth & Partner (1998), S. 65–77. Gaitanides Michael (2007): Prozessorganisation, 2. Auflage, München. Gareis Roland, Stummer Michael (2008): Processes & Projects, Wien. Hammer Michael, Champy James (1994): Business Reengineering. Die Radikalkur für das Unternehmen, München. Hammer Michael (1997): Das prozessorientierte Unternehmen. Die Arbeitswelt nach dem Reengineering, München. Hammer Michael (2002): Der Weg zum supereffizienten Unternehmen. In: Harvard Business Manager 2/2002, S. 40–52. Hess Thomas, Österle Hubert (1995): Methoden des Business Process Redesign: Aktueller Stand und Entwicklungsperspektiven, Wiederabdruck in Österle et al. (2004), a. a. O., S. 151–170. Hiller Christina, Minar-Hödl Peter, Zahradnik Hansjörg (2010): Prozessmanagement. Komplexe Prozesse einfach steuern, Wien. Horváth Peter (2009): Erneuerung des Controllings. In: Bullinger et al. (2009), a. a. O., S. 949–956.

262


Horváth & Partner (Hg.) (1998): Prozesskostenmanagement, München. Horváth & Partners (Hg.) (2005): Prozessmanagement umsetzen. Durch nachhaltige Prozessperformance Umsatz steigern und Kosten senken, Stuttgart. IDS Scheer AG/Pierre Audoin Consultants (2007): Business Process Report 2007. Geschäftsprozessmanagement in Deutschland, Österreich und der Schweiz, Saarbrücken/München. IDS Scheer AG/Pierre Audoin Consultants (2006): Business Process Report 2006, Saarbrücken/ München. International Group of Controlling (Hg.) (2011): Controlling-Prozessmodell. Ein Leitfaden für die Beschreibung und Gestaltung von Controlling-Prozessen, Freiburg/Berlin/München. Jochem Roland, Landgraf Katja (2010): Die Prozessorganisation. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 55–75. Jochem Roland, Mertins Kai, Knothe Thomas (Hg.) (2010): Prozessmanagement. Strategien, Methoden, Umsetzung, Düsseldorf. Jörns Carsten T. (2003): Übergreifende Koordination zum Fulfillment im Supply Chain Netzwerk. In: Scheer, Abolhassan, Bosch (2003), a. a. O., S. 43–71. Kieninger Michael (1998): Reengineering und Prozessoptimierung. In: Horváth & Partner (1998), a. a. O., S. 29–45. Kieser Alfred, Walgenbach Peter (2010): Organisation, 6. Aufl., Stuttgart. Klimmer Matthias (2007): Unternehmensorganisation. Eine kompakte und praxisnahe Einführung, 2. vollst. überarb. u. erw. Aufl., Herne. Knuppertz Thilo (2009): Prozessmanagement für Dummies, Weinheim. Knuppertz Thilo, Schnägelberger Sven, Clauberg Katharina (2011): Umfrage Status Quo Prozessmanagement 2011/2012, März 2011 Köln. Kohl Gernot (2001): Prozessbenchmarking. In: Wagner (2001), a. a. O., S. 253–262. Kohl Ina, Orth Ronald (2010): Prozessmanagement und Wissensmanagement. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 169–192. Kugeler Martin, Vieting Michael (2008): Gestaltung einer prozessorientierten Aufbauorganisation. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 221–267. Kuhlang Peter (2010): GPM – Geschäftsprozessmanagement-Tools. Marktstudie 2010 und Auswahlunterstützung, Wien/Graz. Kuhn Axel, Hellingrath Bernd (2009): Auftragsmanagement in Netzwerken: Supply Chain Management. In: Bullinger et al. (2009), a. a. O., S. 384–407. Küpper Hans-Ulrich (1982): Ablauforganisation, Stuttgart/New York. Küting Karlheinz (1996): Benchmarking von Geschäftsprozessen als Instrument der Geschäftsprozessanalyse. In: Berkau, Hirschmann (1996), a. a. O., S. 121–140. Ledolter Johannes (2010): Qualität und Produktion. In: Mayrhofer, Meyer, Titscher (2010), a. a. O., S. 327–344. Leffingwell William Henry (1917): Supplements To Scientific Office Management, Kessinger Publishing’s Legacy Reprints.

263


Loos Peter, Balzert Silke, Werth Dirk (2010): Controlling von Geschäftsprozessen. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 443–472. Mangler Wolf-Dieter (2006): Prozessorganisation und Organisationsgestaltung, Norderstedt. Mayer Reinhold (1996): Prozeßkostenrechnung und Prozeß(kosten)optimierung als integrierter Ansatz – Methodik und Anwendungsempfehlungen. In: Berknau, Hirschmann (1996), a. a. O., S. 43–67. Mayer Reinhold (2005): Prozessmanagement: Erfolg durch Steigerung der Prozessperformance. In: Horváth & Partners (2005), a. a. O., S. 1–6. Mayer Reinhold, Brenner Markus (2005): Das Horváth & Partners-Konzept zur Umsetzung des Prozessmanagements. In: Horváth & Partners (2005), a. a. O., S. 17–23. Mayer Reinhold, Coners André, Von der Hardt Gerrit (2005): Anwendungsfelder und Aufbau einer Prozesskostenrechnung. In: Horváth & Partners (2005), a. a. O., S. 123–140. Mayrhofer Wolfgang, Meyer Michael, Titscher Stefan (Hg.) (2010): Praxis der Organisationsanalyse. Anwendungsfelder und Methoden, Wien. Nicolai Christiana (2009): Betriebliche Organisation, Stuttgart. Neumann Stefan, Probst Christian, Wernsmann Clemens (2008): Kontinuierliches Prozessmanagement. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 299–325. Neumann Stefan, Rosemann Michael, Schwegmann Ansgar (2008): Simulation von Geschäftsprozessen. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 435–453. Niemann Jörg (2009): Life Cycle Management – Das Paradigma der ganzheitlichen Produktlebenslaufbetrachtung. In: Bullinger et al. (2009), a. a. O., S. 224–236. Niemann Jörg (2009a): Ökonomische Bewertung von Produktlebensläufen – Vom Life Cycle Costing zum Life Cycle Controlling. In: Bullinger et al. (2009), a. a. O., S. 294–307. Österle Hubert et al. (Hg) (2004): Business Engineering. Die ersten 15 Jahre, Berlin u. a. Österle Hubert (2010/1995): Business in the Information Age. Heading for New Processes, Berlin et al. Ould Martyn A. (2005): Business Process Management. A Rigorous Approach, Swindon/ Tampa. Rabe Markus, Knothe Thomas (2010): Geschäftsprozess-Simulation. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 473–490. Renner Andreas (2005): Potenzialermittlung durch Benchmarking. In: Horváth & Partners (2005), a. a. O., S. 69–86. Rosemann Michael, Schwegmann Ansgar, Delfmann Patrick (2008): Vorbereitung der Prozessmodellierung. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 45–103. Rummler Geary A., Ramias Alan J., Rummler Richard A. (2010): White Space Revisited. Creating Value Through Process, San Francisco. Rummler Geary A., Brache Alan P. (1995): Improving Performance. How to Manage the White Space on the Organization Chart, Second Edition, San Francisco. Scheer August-Wilhelm (1997): Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse, 7. durchges. Aufl., Berlin et al.

264


Scheer August-Wilhelm (1998): ARIS – Vom Geschäftsprozess zum Anwendungssystem, 3. völlig neubearb. u. erw. Aufl., Berlin et al. Scheer August-Wilhelm, Jost Wolfram (2002): ARIS in der Praxis. Gestaltung, Implementierung und Optimierung von Geschäftsprozessen, Berlin/Heidelberg. Scheer August-Wilhelm, Abolhassan Ferri, Bosch Wolfgang (Hg.) (2003): Real-Time Enterprise, Berlin/Heidelberg. Scheer August Wilhelm et al. (2003a): Change Management im Unternehmen. Prozessveränderungen erfolgreich managen, Berlin/Heidelberg. Scheer August-Wilhelm et.al. (Hg.) (2005): Corporate Performance Management, Berlin/Heidelberg. Scheer August-Wilhelm, Thomas Oliver (2009): Verfahren und Werkzeuge der Informationsmodellierung. In: Bullinger et al. (2009), a. a. O., S. 544–568. Schimank Christof (1998): Komplexitätsmanagement und Process-Benchmarking. In: Horváth & Partner (1998), a. a. O., S. 47–64. Schmelzer Hermann J., Sesselmann Wolfgang (2010): Geschäftsprozessmanagement in der Praxis. Kunden zufrieden stellen, Produktivität steigern, Wert erhöhen, 7. überarb. u. erw. Aufl., München. Schmidt Götz (2006): Organisatorische Grundbegriffe, Gießen. Schober Holger (2002): Prozessorganisation: Theoretische Grundlagen und Gestaltungsoptionen, Wiesbaden. Schreyögg Georg (2006): Organisation. 4. Auflage, Nachdruck 2006, Wiesbaden. Schwegmann Ansgar, Laske Michael (2008): Istmodellierung und Istanalyse. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 155–184. Seidlmeier Heinrich (2002): Prozessmodellierung mit ARIS®, Braunschweig/Wiesbaden. Seidenschwarz Werner (Hg.) (2008): Marktorientiertes Prozessmanagement, 2. Auflage, München. Siegel Jon (2008): What is the Definition of Business Process?, OCEB Certification Program White Paper, Object Management Group, o.O. Smith Adam (1999): Der Wohlstand der Nationen, 8. Auflage, München. Smith Howard, Finegar Peter (2007): Business Process Management. The Third Wave, Tampa. Spanyi Andrew (2007): More for Less. The Power of Process Management, Tampa. Spath Dieter (2009): Grundlagen der Unternehmensgestaltung. In: Bullinger et al. (2009), a. a. O., S. 3–24. Speck Mario, Schnetgöke Norbert (2008): Sollmodellierung und Prozessoptimierung. In: Becker, Kugeler, Rosemann (2008), a. a. O., S. 185–220. Stark Rainer, Kind Christian (2010): Prozessmanagement in der Produktentstehung. In: Jochem, Mertins, Knothe (2010), a. a. O., S. 377–411. Staud Josef (2001): Geschäftsprozessanalyse. Ereignisgesteuerte Prozessketten und objektorientierte Geschäftsprozessmodellierung für Betriebswirtschaftliche Standardsoftware, 2. überarb. u. erw. Aufl., Berlin/Heidelberg.

265


Stausberg Michael (2006): Das Handbuch der Prozesskennzahlen, Kissing. Stöger Roman (2009): Prozessmanagement. Qualität, Produktivität, Konkurrenzfähigkeit, 2. Aufl., Stuttgart. Taylor Frederick Winslow (1911): The Principles of Scientific Management, BiblioBazaar Reproduktion, o.O. TeleManagement Forum (2010): The Business Process Framework. High-Level Guide for Managers, o.O. Teufel Peter (2009): Der Prozess der ständigen Verbesserung (Kaizen) und dessen Einführung. In: Bullinger et al. (2009), a. a. O., S. 676–695. Tissberger Tobias (2007): Von der Prozesskostenrechnung zum Prozessmanagement. Theoretische Methoden und ihre Anwendung, Saarbrücken. Van der Alst Will, Desel Jörg, Oberweis Andreas (Hg.) (2000): Business Process Management. Model, Techniques, and Empirical Studies, Berlin et al. Verner Laury (2004): The Challenge of Process Discovery. In: BPTrends May 2004. Wagner Karl (Hg.) (2001): PQM – Prozessorientiertes Qualitäts-Management. Leitfaden zur Umsetzung der ISO 9001:2000, München/Wien. Wagner Karl W., Patzak Gerold (2007): Performance Excellence. Der Praxisleitfaden zum effektiven Prozessmanagement, München. Walter Johann (2009): Geschäftsprozessmanagement umsetzen. Prozesse am Kunden orientieren, transparent und flexible gestalten, München. Waltz Kenneth (1979): Theory of International Politics, New York et.al. Weilkiens Tim, Weiss Christian, Grass Andrea (2010): Basiswissen Geschäftsprozessmanagement. Aus- und Weiterbildung zum OMG Certified Expert in Business Process Management (OCEB) – Fundamental Level, Heidelberg. Weske Mathias (2007): Business Process Management. Concepts, Languages, Architectures, Berlin/Heidelberg/New York. Wilhelm Rudolf (2007): Prozessorganisation, 2. überarb. Aufl., München/Wien. Wolf Celia, Harmon Paul (2010): The State of Business Process Management, o.O.

266

Abbildungsverzeichnis Abb. 1: Abb. 2: Abb. 3: Abb. 4: Abb. 5: Abb. 6: Abb. 7: Abb. 8: Abb. 9: Abb. 10: Abb. 11: Abb. 12: Abb. 13: Abb. 14: Abb. 15: Abb. 16: Abb. 17: Abb. 18: Abb. 19: Abb. 20: Abb. 21: Abb. 22: Abb. 23: Abb. 24: Abb. 25: Abb. 26: Abb. 27: Abb. 28: Abb. 29: Abb. 30: Abb. 31: Abb. 32: Abb. 33: Abb. 34: Abb. 35: Abb. 36:

Entwicklung des Prozessmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition Geschäftsprozess (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition Geschäftsprozess (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition Geschäftsprozess (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition Geschäftsprozess (4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geschäftsprozesssicht und Kundenorientierung (1) . . . . . . . . . . . . . . . . . . Geschäftsprozesssicht und Kundenorientierung (2) . . . . . . . . . . . . . . . . . . Geschäftsprozesssicht und Mitarbeiterorientierung . . . . . . . . . . . . . . . . . . Anwendung der Prozesskriterien auf die Buchhaltung . . . . . . . . . . . . . . . . Anwendung der Prozesskriterien auf die Debitorenbuchhaltung . . . . . . . . Geschäftsprozesssicht und funktionale Gliederung . . . . . . . . . . . . . . . . . . Drei Sichten auf Organisationen aus dem Blickwinkel der Organisationsgestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nutzung von Referenzmodellen auf den verschiedenen Ebenen des Prozessmodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Geschäftsfälle als Ausgangspunkt der Prozessidentifikation (1) . . . . . . . . . Geschäftsfälle als Ausgangspunkt der Prozessidentifikation (2) . . . . . . . . . Typische Bereitstellungsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bereitstellungsprozesse und ihre internen Leistungen . . . . . . . . . . . . . . . . Referenzmodell eines ergebnisorientierten Managementprozesses . . . . . . . Referenzprozess für einen normativen Steuerungsprozess . . . . . . . . . . . . . Internen Leistungen des ergebnisorientierten Steuerungsprozesses . . . . . . . Internen Leistungen des normativen Steuerungsprozesses . . . . . . . . . . . . . Abgrenzung von Teilprozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beibehaltung der Ablauflogik in der Detaillierung der Teilprozesse . . . . . . . Vorgehen bei der Prozesserhebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Teilprozessabgrenzung über klar identifizierbare Teilleistungen . . . . . . . . . Teilprozessabgrenzung über unterschiedliche Zähler . . . . . . . . . . . . . . . . . Prozesstypen und -bezeichnungen auf den Ebenen . . . . . . . . . . . . . . . . . . Prozessarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vertikale Konsistenz in der Prozessarchitektur . . . . . . . . . . . . . . . . . . . . . Konsistentes Herunterbrechen der Prozesse . . . . . . . . . . . . . . . . . . . . . . . Anforderungen und Einflussfaktoren für eine Organisationsstruktur . . . . . Prozessorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation von Gate Gourmet vor und nach dem Reengineering . . . . . . Organisation des Statistischen Amts Zürich vor und nach dem Reengineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozessorganisation des Geschäftsfelds Computertomografie der Siemens AG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozessorganisation eines Anlagenbauunternehmens . . . . . . . . . . . . . . . .

8 22 23 24 28 31 33 34 36 38 39 47 56 65 66 69 70 73 73 74 75 81 83 85 88 90 92 93 94 95 114 126 135 136 138 139

267

Abbildungsverzeichnis

Abb. 37: Abb. 38: Abb. 39: Abb. 40: Abb. 41: Abb. 42: Abb. 43: Abb. 44: Abb. 45: Abb. 46: Abb. 47: Abb. 48: Abb. 49: Abb. 50: Abb. 51: Abb. 52: Abb. 53: Abb. 54: Abb. 55: Abb. 56: Abb. 57: Abb. 58: Abb. 59: Abb. 60: Abb. 61: Abb. 62: Abb. 63: Abb. 64: Abb. 65: Abb. 66: Abb. 67: Abb. 68: Abb. 69: Abb. 70: Abb. 71: Abb. 72: Abb. 73: Abb. 74: Abb. 75: Abb. 76:

268

Gedankliche Trennung von Prozessdesign und Prozessdurchführung . . . . . Einordnung der Prozessverantwortung in das Gesamtbild . . . . . . . . . . . . . Ausdifferenzierung der Prozessverantwortungsrollen . . . . . . . . . . . . . . . . . Alternative organisatorische Verankerungen der Prozessmanager . . . . . . . . Prozess für Prozessänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration über Bereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufzeigen von Organisationsübergängen im Detailablauf . . . . . . . . . . . . . . Integration über IT-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Aufzeigen von Systemübergängen im Detailablauf . . . . . . . . . . . . . . . . . . . Integration über Produkte und Leistungen (1) . . . . . . . . . . . . . . . . . . . . . Integration über Produkte und Leistungen (2) . . . . . . . . . . . . . . . . . . . . . Integration über Produkte und Leistungen (3) . . . . . . . . . . . . . . . . . . . . . Produkt-Teilprozess-Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration über Produkte und Leistungen (4) . . . . . . . . . . . . . . . . . . . . . Von unabhängigen Prozessen gemeinsam genutzte Ressourcen . . . . . . . . . Integration über Standorte (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozessharmonisierung über Standorte (2) . . . . . . . . . . . . . . . . . . . . . . . . Integration über Standorte (3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schritte der organisatorischen Optimierung verteilter Organisationen . . . . Aufsplitten voll ausgeprägter Landesorganisationen . . . . . . . . . . . . . . . . . . Integration zu Lieferanten und Kunden (1) . . . . . . . . . . . . . . . . . . . . . . . Integration zu Lieferanten und Kunden (2) . . . . . . . . . . . . . . . . . . . . . . . Integrative Process Map und Prozessarchitektur . . . . . . . . . . . . . . . . . . . . Illustration einer integrativen Process Map . . . . . . . . . . . . . . . . . . . . . . . . Prozessmanagement als Instrument zur Re-Integration der Prozesse nach Restrukturierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozessmanagement als Instrument zur Integration von Akquisitionen . . . Isolierte Elemente des Prozessmanagements in der Praxis . . . . . . . . . . . . . Schema für ein Prozessmanagement Zieleportfolio . . . . . . . . . . . . . . . . . . Beispiele für konkrete Prozessmanagement-Zieleportfolios . . . . . . . . . . . . Über- und Unterorganisation in Bezug auf Geschäftsprozesse . . . . . . . . . . Prozessmanagementziele und Prozessfokus . . . . . . . . . . . . . . . . . . . . . . . . Strategic Process Alignment Matrix von Horváth & Partners . . . . . . . . . . . Commodity und Intelligence Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . Zielkonkretisierung für das Prozessmanagement mittels einer Prozessmanagement Scorecard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozesskosten als Mittel zum Tracken von Benefits bei veränderlichen Mengen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managen von Prozessen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zieldreieck für die Optimierung und Steuerung von Prozessen . . . . . . . . . Vorgehen in der Prozessoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mengenabhängige Variabilisierung der Kosten durch den Prozesskostenansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorteile einer Erhebung der Ist-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . .

142 143 149 155 160 171 172 172 173 174 175 175 176 177 178 180 181 181 182 182 183 185 188 190 193 195 201 205 206 207 209 210 211 214 218 224 226 235 240 241

Abbildungsverzeichnis

Abb. 77: Abb. 78: Abb. 79:

Gestaltungsparameter für die Prozessoptimierung . . . . . . . . . . . . . . . . . . . Maßnahmenpriorisierungsportfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel für eine Auswirkungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . .

246 248 249

269

Sachverzeichnis A ablauforganisatorische Gliederung 115 aufbauorganisatorische Gliederung 115 Auswirkungsanalyse 248 B Beförderungs- und Vergütungsstruktur 117 Benefit Tracking 218, 222 Besprechungs- und Entscheidungsstrukturen 116 Business Process Management Notation 101 Business Process Management Systems 231 C Case Team 127 Case Worker 126–127, 130, 132 Commodity-Prozesse 211 Corporate Functions 41 Customer Relation Management 41 D Differenzierung 110 DIN 66001 102 divisionale Organisation 121 Dokumentenanalyse 84 E Effektivität 110 Effizienz 111 Ereignis 20 ereignisgesteuerte Prozessketten 3, 101 ergebnisorientierter Steuerungsprozess 72 F Flexibilität 112 Fragebogenerhebung 84 Führungseffizienz 111

G Geschäftsfall 24, 65 H Härtegrade 223 hidden structures 116 Huborganisation 122 I Input-Output-Transformation 255 Inputs 20 Intelligence Prozesse 211 Interviews 84 ISO 5807 102 Ist-Erhebung 240 K Kaizen 214, 236, 239, 245, 252, 266 Kernprozesse 78 Koordination 110 Kundenzufriedenheit 32 L Laufzettelverfahren 86 lessons learned 252 Loyalitätsstiftung 112 M Management Commitment 156 Managementprozesse 80 Maßnahmenausarbeitung 247 Methoden 245 Mitarbeiterzufriedenheit 34 N normativer Steuerungsprozess 73 Normen 116 Normerfüllung 113 Notation 99

271

Sachverzeichnis

O Objektkonzept 99 Optimierungsauftrag 237 Order-to-Cash 48 Organisationslehre 2–3, 5, 8–9, 108, 110–111, 119–120, 189, 207, 244, 256, 258 Outputs 21, 61 P Primärorganisation 124 private Prozesse 185 Process Mining 231 Process Monitoring 231 Process Performance Monitoring 230 Product Lifecycle Management 43 Produkt-Teilprozess-Matrix 175 Prozess Governance 165 Prozessaudit 251 Prozessbegehung 85 Prozessbenchmarking 242 Prozessinnovationen 212 Prozesskennzahlen 228 Prozesskostenrechnung 239 Prozessmodell 92 Prozessmodellierungstool 98 Prozessoptimierungsteam 236 Prozessregelung 250 Prozessreifegrad-Assessment 219 Prozesssimulation 245 Prozesssteckbrief 104 Prozesssteuerung 249 Purchase-to-Pay 48 R Reengineering 107, 132–136, 204, 216, 226, 262–263, 267

272

Referenzmodelle 53 Regionalorganisation 121 Ressourcenzuordnung 29 Rundumbearbeitung 126–127, 130, 134, 142 S Schwachstellenanalyse 243 Sekundärorganisation 124 Shared Service Center 40 SixSigma 7, 197, 230, 245, 253 Sollprozess 244 Strategic Process Alignment Matrix 210 Supply Chain Management 42 Supportprozesse 79 Swimlane-Darstellung 170 T Teilleistung 87 U Überorganisation 208 Unternehmenskultur 116 Unterorganisation 208 V Verrichtungen 120 Vision 204 W Wertkette von Michael Porter 51 Wertschöpfungsprozesse 76 Z Zentralfunktionen 41 Zieleportfolio 204

End-to-End-Geschäftsprozessmanagement: Organisationselement - Integrationsinstrument - Managementansatz

Recommend Documents