Prozessmanagement Für Experten: Franz Bayer Harald Kühn HRSG

Franz Bayer
Harald Kühn Hrsg.
Prozessmanagement
für Experten
Impulse für aktuelle und wiederkehrende Themen
Prozessmanagement für Experten
Franz Bayer · Harald Kühn
Herausgeber
Prozessmanagement für
Experten
Impulse für aktuelle und wiederkehrende
Themen
Herausgeber
Franz Bayer
Harald Kühn
BOC Information Technologies Consulting AG
Wien, Österreich
ISBN 978-3-642-36994-0 ISBN 978-3-642-36995-7 (eBook)

DOI 10.1007/978-3-642-36995-7
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Springer Gabler
© Springer-Verlag Berlin Heidelberg 2013
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht
ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags.
Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die
Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk

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ürften.
Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier
Springer Gabler ist eine Marke von Springer DE. Springer DE ist Teil der Fachverlagsgruppe
Springer Science+Business Media
www.springer-gabler.de
Geleitwort
Forschungsergebnisse in die industrielle Praxis überzuleiten, wenn diese neu für ihre
Anwender und noch nicht intuitiv zugänglich sind, ist eine Herausforderung.
Das liegt daran, dass eine erfolgreiche Ergebnisüberleitung durch drei Aspekte
bedingt wird, die gleichzeitig und über einen längeren Zeitraum zutreffen müssen:
• Es bedarf der Kontinuität einer Forschungsrichtung und -gruppe.
• Es bedarf zur Praxisumsetzung Menschen, die sowohl fachlich als auch sozial von aus-
geprägter Kompetenz sind.
• Es bedarf der Anwendbarkeit der Forschungsergebnisse im gewählten Anwendungsbereich.
Dieses Buch setzt sich mit dem Anwendungsbereich „Prozessmanagement“ auseinander,
welches sich von einer forschungsrelevanten Disziplin der 1990er-Jahre zu einem allgemein
akzeptierten Managementinstrument in der unternehmerischen Praxis entwickelt hat.
Prozessmanagement ist keine Disziplin der exakten Wissenschaften. Wenn Forschung
und Entwicklung in diesem Kontext Erfolg haben sollen, müssen Forschungsergebnisse auf-
grund von Beobachtungen, durch Experimente und auf Basis von Anwendungserfahrungen
empirisch weiterführend untersucht und fortentwickelt werden. Die Entwicklung von
Methoden und Verfahren für diverse Aspekte des Prozessmanagements ist daher kein
Selbstzweck der wissenschaftlichen Arbeit. Die universitären Ergebnisse sind vielmehr dann
erfolgreich, wenn die geschaffenen Grundlagen in der Praxis erprobt und auf breiter Basis
angewendet werden. Das Management von Geschäftsprozessen ist eine dieser Disziplinen,
in der eine Brücke zwischen Forschung und Anwendung nachhaltig etabliert wurde.
Ob und welche Inhalte dieses Buchs für den jeweiligen Leser relevant sind, wage
ich nicht zu beurteilen, da der Wert der Inhalte immer subjektiv empfunden wird. Aus
Forschungssicht sind die Themen des Buchs allerdings von ausgeprägter Bedeutung. Das
liegt unter anderem auch daran, dass die Autoren das Prozessmanagement nicht nur
erlernt und an diversen Einrichtungen selbst gelehrt, sondern es auch in seiner Ganzheit
über viele Jahre erfolgreich praktiziert haben. Sie behandeln immer wiederkehrende
Themen, die den Kern der prozessorientierten Unternehmensführung und -steuerung
betreffen. Besonders hervorzuheben ist, dass dieses Buch in einer Unternehmensgruppe
entstanden ist, die es bis heute geschafft hat, weiterhin sowohl forschungs- als auch
praxisnah zu sein.
V
VI Geleitwort
Warum sollten Sie dieses Buch lesen? Wenn Sie ein Prozessmanagement-Experte
sind, zeigt es Ihnen, wie andere Experten diese Materie interpretiert und angewendet
haben. Wenn Sie am Beginn Ihres Wegs zum Prozessmanagement stehen, bietet es Ihnen
die Möglichkeit, ein Experte zu werden. Denn wie auch schon Sokrates sagte, „es ist keine
Schande nichts zu wissen, wohl aber, nichts lernen zu wollen“.
Den Herausgebern, Autoren und allen Mitwirkenden ist es gelungen, dieses Werk
zusätzlich zu ihren unternehmensspezifischen Aufgaben zu realisieren. Dies ist nicht nur
in der Motivation und Disziplin jedes Beteiligten zu begründen, sondern auch in der aus-
gezeichneten Zusammenarbeit als Gruppe.
Ihnen allen gilt mein größter Dank!
Januar 2013 Dimitris Karagiannis

Universität Wien
Wien, Österreich
Vorwort
Seit der Gründung der BOC Gruppe im Jahre 1995 sind wir im Umfeld des
Prozessmanagements in den unterschiedlichsten Rollen und Positionen tätig. Im
Rahmen dieser Tätigkeiten hatten wir das Glück, in einer Vielzahl von spannenden
Projekten und Initiativen mit einer großen Anzahl an interessanten Personen und
Kollegen zu mannigfaltigen Prozessthemen arbeiten und gestalten zu dürfen.
Warum haben wir uns nun entschieden, ein BOC Buch zum Thema Prozessmanagement
zu veröffentlichen, zumal es auf dem deutschsprachigen als auch internationalen Buchmarkt
mittlerweile eine stattliche Anzahl an guten Büchern zu beinahe allen Facetten des
Prozessmanagements gibt? Wir hatten hierzu vorrangig drei Beweggründe.
Im Laufe der Jahre wurden wir in unseren Beratungsprojekten von unseren Kunden
immer wieder gefragt, ob es eine publizierte Zusammenstellung der von uns in Projekten
erfolgreich genutzten und praxiserprobten Vorgehensweisen, Handlungsempfehlungen
und Techniken gibt. Hierzu mussten wir bisher immer auf unsere Whitepapers, unsere
Einzelpublikationen in den verschiedensten Fachzeitschriften, Konferenzen und Workshops
sowie unsere Beitragskapitel in anderen Büchern verweisen.
Als Zweites sehen wir, dass andere Prozessmanagement-Bücher teilweise an einem
bestimmten Punkt „aufhören“ und nur das „Was?“, aber nicht das „Wie?“ beschreiben.
An dieser Stelle setzt das vorliegende Buch an und geht „einen Schritt weiter“, um zu
den im Buch behandelten Themen konkrete Handlungsempfehlungen und Techniken
vorzustellen. Sie erhalten Antworten auf Fragen, wie bspw. „Wie erstelle ich eine gute
Prozesslandkarte?“, „Wie identifiziere und etabliere ich die Prozessverantwortung für einen
Prozess?“, „Wie integriere ich Compliance-Anforderungen in das Prozessmanagement?“
oder „Wie ermittle ich den Personalbedarf für einen bestimmten Prozess?“.
Der dritte Grund ist, dass derzeit Prozessmanagement sowie andere Managementansätze
oftmals isoliert voneinander betrachtet und eingesetzt werden. Diese müssen aus unse-
rer Sicht allerdings im Sinne eines integrierten Managementsystems im Zusammenhang
genutzt werden. Hierzu stellen wir für vier weitere Managementansätze die Integration mit
dem Prozessmanagement vor.
Wir haben für dieses Buch die Form einer Herausgeberschaft gewählt, da wir der
Überzeugung sind, nur damit den Zielen des Buchs gerecht zu werden. Zum einen ist
es dadurch besser möglich, einzelne Kapitel unabhängig voneinander zu lesen, was am
VII
VIII Vorwort
ehesten der Nutzung im Arbeitsalltag entspricht. Zum anderen sind die spezifischen
Kapitel von den jeweiligen Praxisexperten verfasst und gehen so den „einen Schritt wei-
ter“, um Ihnen nicht nur allgemeingültige Beispiele, sondern konkretes und erfolgreich
umgesetztes Erfahrungswissen weitergeben zu können.
Zur Entstehung dieses Buchs haben viele Personen beigetragen, denen wir allen ein
herzliches „Dankeschön!“ aussprechen wollen.
Zuerst möchten wir allen Autoren danken, die mit ihrem tollen Einsatz und Fleiß,
oft zusätzlich zum üblichen Tagesgeschäft, die Inhalte des Buchs produziert haben. Das
Buch ist Ergebnis einer ausgesprochenen Teamleistung.
Folgende Autoren haben beigetragen (in alphabetischer Reihenfolge): Lea Appelhans,
Julia Auer, Daniel Bouché, Dr. Franz Bayer, Kai-Helmut Eckert, Tim Farcher, Dr. Anke
Gericke, Erik Guschlbauer, Eckart Hagenloch, Vedran Hrgovcic, Dr. Lutz Kirchner,
Robert Klose, Dr. Harald Kühn, Marcus Landgraf, Manfred Lenhardt, Dr. Christian
Lichka, Christoph Moser, Stefan Müller, Thomas Müllner, Dr. Marion Murzek, Christoph
Prackwieser, Michael Puncochar, Tobias Rausch, Mario Scherber, Stefanie Schmidt, Markus
Schneider, Robert Strobl, Wilfrid Utz, Angelika Widowitz, Dr. Robert Woitsch und Eva Wolf.
Die Autorennamen finden Sie ebenfalls zu Beginn jedes Kapitels inkl. des E-Mail-
Kontakts der jeweiligen Leitautorin bzw. des Leitautors.
Ein besonderer Dank gilt Frau Dr. Anke Gericke, die mit unermüdlicher
Hartnäckigkeit die Zügel des Projekts in ihren Händen hielt und mit viel Charme vor-
antrieb. Ebenfalls gilt unser Dank Frau Julia Burger, Frau Alexandra Rupacher und in
besonderem Maße Herrn David Hauer, die v. a. in der Endphase des Projekts für viele
organisatorische und konsolidierende Tätigkeiten eine tolle Arbeit geleistet haben.
Wir möchten außerdem allen Kollegen in der BOC Gruppe danken, die mit ihren
Ideen, Erfahrungen und Diskussionen zu den diversen Themen beigetragen haben.
Ebenfalls möchten wir allen unseren Kunden und Partnern danken, die im Rahmen
ihrer Projekte viele der im Buch vorgestellten Ansätze zur Anwendung und positiven
Validierung gebracht haben.
Weiterhin möchten wir Herrn Michael Bursik und Frau Janina Sobolewski danken,
die seitens des Verlags immer tolle Ansprechpartner waren und mit Rat und Tat zu
allen möglichen Fragen im Umfeld des Buchs jederzeit schnell und kompetent zur Seite
standen.
Ein abschließender, aber ganz besonderer Dank gilt o. Univ. Prof. Dr. Prof. h.c.
Dimitris Karagiannis, der durch die Gründung der BOC Gruppe als Spin-off der
Universität Wien die Umgebung geschaffen hat, auf Basis derer viele der im Buch vorge-
stellten Ideen entstanden sind und in der Praxis umgesetzt werden konnten.
Wir wünschen Ihnen beim Lesen viel Vergnügen und hoffen, dass wir den einen oder
anderen Impuls für Ihre Prozessmanagement-Aktivitäten geben können.
Januar 2013 Dr. Franz Bayer und Dr. Harald Kühn

BOC Information Technologies Consulting AG
Wien, Österreich
Inhaltsverzeichnis
Teil I Einführung
1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Anke Gericke, Franz Bayer und Harald Kühn
1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Fokus und Zielgruppe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Der Process Management Life Cycle im Kontext integrierter
Managementsysteme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Leseempfehlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Der Lebenszyklus des Prozessmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Anke Gericke, Franz Bayer, Harald Kühn, Tobias Rausch
und Robert Strobl
2.1 Überblick über den Lebenszyklus des Prozessmanagements . . . . . . . . . . . . . 12
2.1.1 Einordnung der Begrifflichkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Die Phasen des Process Management Life Cycle. . . . . . . . . . . . . . . . . 12
2.1.3 Anwendung des Process Management Life Cycle. . . . . . . . . . . . . . . . 14
2.2 Die Rollen im Rahmen des Prozessmanagements . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Wesentliche Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Weitere involvierte Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Einordnung des Process Management Life Cycle. . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Die Phasen des Process Management Life Cycle. . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.1 Prozessstrategie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.2 Prozessdokumentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.3 Prozessoptimierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.4 Prozessumsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.5 Prozessdurchführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.6 Prozesscontrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
IX
X Inhaltsverzeichnis
Teil II Prozessstrategie
3 Prinzipien für die Gestaltung der Prozessarchitektur. . . . . . . . . . . . . . . . . . . . . . 37

Franz Bayer, Lea Appelhans und Eva Wolf
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Zusammenspiel Unternehmensstrategie und Prozessstrategie. . . . . . . . . . . . 39
3.3 Nutzenaspekte der Prozesslandkarte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Vorgehen zur Gestaltung der Prozesslandkarte . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.1 Das Konzept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2 Techniken zur Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.3 Umsetzung der Struktur mit der Prozesslandkarte. . . . . . . . . . . . . . . 47
3.4.4 Techniken zur Bewertung von Prozesslandkarten . . . . . . . . . . . . . . . 47
3.5 Regelung von Verantwortung in der Prozessarchitektur. . . . . . . . . . . . . . . . . 50
3.6 Ausgewählte Beispiele zur Verwendung der Prozesslandkarte. . . . . . . . . . . . 51
3.6.1 Standardisierung und Harmonisierung. . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.2 Sourcing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6.3 Benchmarking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.6.4 Postmerger-Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4 Umsetzung eines zielorientierten Prozessmanagements. . . . . . . . . . . . . . . . . . . . 57
Robert Strobl und Angelika Widowitz
4.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Vorgehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1 Methodische Anleitung zur Umsetzung eines zielorientierten
Prozessmanagements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.2 Strategische Ziele analysieren und Prozesse strategisch
gewichten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.3 Strategische Prozessziele ableiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.4 Operative Prozessziele ableiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.5 Controlling-System initialisieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3 Involvierte Rollen und deren Aufgaben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4 Angewandte Technik: Festlegung der Prozessverantwortung . . . . . . . . . . . . 68
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Teil III Prozessdokumentation

5 Gestaltungs- und Modellierungsrichtlinien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Daniel Bouché, Manfred Lenhardt und Stefanie Schmidt
5.1 Motivation und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Grundsätze ordnungsmäßiger Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.1 Grundsatz der Richtigkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Inhaltsverzeichnis XI
5.2.2 Grundsatz der Relevanz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.3 Grundsatz der Wirtschaftlichkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.4 Grundsatz der Klarheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.5 Grundsatz der Vergleichbarkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.6 Grundsatz des systematischen Aufbaus. . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3 Gestaltungsrichtlinien für Geschäftsprozessmodelle. . . . . . . . . . . . . . . . . . . . 81
5.3.1 Detaillierungsgrad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3.2 Wiederverwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4 Modellierungsrichtlinien für Geschäftsprozessmodelle. . . . . . . . . . . . . . . . . . 87
5.5 Erfolgsfaktoren von Gestaltungs- und Modellierungsrichtlinien. . . . . . . . . . 89
5.6 Qualitätssicherung von Geschäftsprozessmodellen. . . . . . . . . . . . . . . . . . . . . 89
5.7 Vorgehensschritte und Verantwortlichkeiten. . . . . . . . . . . . . . . . . . . . . . . . . . 90
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6 BPMN als Bestandteil der BPMS-Modellierungsmethode. . . . . . . . . . . . . . . . . . 93
Marion Murzek, Tobias Rausch und Harald Kühn
6.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.2 Die BPMS-Modellierungsmethode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.2.1 Prozesslandkarte und Produktmodell. . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2.2 Ablauforganisation – Prozesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.2.3 Aufbauorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.2.4 IT, Dokumente und Ressourcen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.2.5 Risiken und Kontrollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3 BPMN 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.3.1 Übersicht und Zielsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.3.2 Stärken und Schwächen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4 Einbettung der BPMN 2.0 in die BPMS-Modellierungsmethode. . . . . . . . . . 101
6.5 Best Practice-Einsatz der BPMS-Modellierungsmethode mit BPMN 2.0. . . . 104
6.5.1 Darstellung von Kommunikationsflüssen (Konversationen) . . . . . . 105
6.5.2 Darstellung von Choreographien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.5.3 Darstellung von Prozessabläufen und Kollaborationen. . . . . . . . . . . 107
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7 Prozess-Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Markus Schneider und Julia Auer
7.1 Herausforderung und Nutzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.2 Vorgehensweise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.3 Compliance-Scoping durchführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4 Compliance-Bewertungen normieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.5 Scoring-Qualität sicherstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.6 Compliance-Assessment durchführen und Compliance-Reporting
aufbereiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.6.1 Heat Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
XII Inhaltsverzeichnis
7.6.2 Process Passports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7.6.3 Process Portfolios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.7 Prozess-Compliance anhand eines Anwendungsbeispiels. . . . . . . . . . . . . . . 127
7.7.1 Ausgangslage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.7.2 Exkurs: Prozessorientiertes Qualitätsmanagement und
das EFQM®-Modell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.7.3 Compliance-Scoping bei der Mustermann GmbH durchführen. . . . 129
7.7.4 Compliance-Assessment durchführen . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.7.5 Compliance-Reporting durchführen. . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.8 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Teil IV Prozessoptimierung
8 Quantitative Analyse und Planung von Prozessen. . . . . . . . . . . . . . . . . . . . . . . . . 137
Harald Kühn und Franz Bayer
8.1 Klassifikation von Verfahren zur Prozessanalyse. . . . . . . . . . . . . . . . . . . . . . . 137
8.2 Phasenmodell zur quantitativen Analyse und Planung
von Prozessen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.2.1 Zieldefinition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8.2.2 Modellerstellung/-adaption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
8.2.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.2.4 Auswertung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.2.5 Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
8.3 Betrachtungsobjekte in der quantitativen Analyse von Prozessen. . . . . . . . . 142
8.3.1 Analyseobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
8.3.2 Quantitative Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
8.4 Ausgewählte Techniken zur quantitativen Analyse von Prozessen. . . . . . . . 147
8.4.1 Statische Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
8.4.2 Dynamische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9 Prozessbasierte Personalbedarfsermittlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Marcus Landgraf und Manfred Lenhardt
9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.1.1 Überblick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
9.1.2 Motivation der prozessbasierten Personalbedarfsermittlung . . . . . . 160
9.1.3 Abgrenzungen und Definitionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
9.2 Berechnungsmodelle in der prozessbasierten
Personalbedarfsermittlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
9.2.1 Grundmodell der Personalbedarfsermittlung . . . . . . . . . . . . . . . . . . . 162
9.2.2 Erweiterte Modelle in der Personalbedarfsermittlung . . . . . . . . . . . . 164
Inhaltsverzeichnis XIII
9.3 Ergebnisdarstellung in der prozessbasierten

Personalbedarfsermittlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.3.1 Prozessbasiertes Ergebnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.3.2 Funktionales Ergebnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
9.3.3 Ergebnisse als Mischformen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
9.4 Erhebung der Berechnungsparameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.4.1 Geschäftsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.4.2 Bearbeitungszeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.4.3 Mengen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.4.4 Jahresarbeitszeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.5 Ausgewählte Fragestellungen im Kontext der
Personalbedarfsermittlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
10 Prozesskostenrechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Christoph Prackwieser und Kai-Helmut Eckert
10.1 Motivation für den Einsatz der Prozesskostenrechnung. . . . . . . . . . . . . . . 187
10.2 Einsatzgebiete und Ziele der Prozesskostenrechnung. . . . . . . . . . . . . . . . . 188
10.3 Einordnung der Prozesskostenrechnung in den Process
Management Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
10.4 Beteiligte Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
10.5 Grundlagen Kostenarten und Prozesskostenrechnung. . . . . . . . . . . . . . . . 191
10.5.1 Grundlagen der Kostenrechnung . . . . . . . . . . . . . . . . . . . . . . . . . . 191
10.5.2 Activity-based Costing und Prozesskostenrechnung. . . . . . . . . . 193
10.6 Vorgehensmodell für die Prozesskostenrechnung. . . . . . . . . . . . . . . . . . . . 194
10.6.1 Allgemeines Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
10.6.2 Umlageverfahren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
10.6.3 Praxisbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
10.6.4 Bewertung der Prozesskostenrechnung. . . . . . . . . . . . . . . . . . . . . 200
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
11 Organisatorische Prozessoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Eva Wolf, Lea Appelhans und Robert Klose
11.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
11.2 Betrachtungsgegenstand der organisatorischen Prozessoptimierung. . . . 204
11.3 Vorgehensweise zur Prozessoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.4 Ist-Erhebung von Prozessmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.4.1 Produkt-Prozess-Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
11.4.2 Kooperations- bzw. Kommunikationsbilder. . . . . . . . . . . . . . . . . 209
11.4.3 Detaillierte Prozessablaufmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . 209
11.5 Bewertung und Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.5.1 Checklisten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
11.5.2 Interviews mit Fachexperten für die einzelnen Prozesse. . . . . . . 212
XIV Inhaltsverzeichnis
11.5.3 Kundenumfragen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

11.5.4 Benchmarking und Nutzung von Referenzprozessen . . . . . . . . . 213
11.5.5 Verbesserungsmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
11.5.6 Ermittlung von Optimierungspotenzialen mit Hilfe
von Ishikawa-Diagrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
11.5.7 Ermittlung von Optimierungspotenzialen anhand von
Reifegradmodellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
11.6 Soll-Konzeption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
11.7 Umsetzung der Maßnahmen und Dokumentation
der Soll-Prozesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Teil V Prozessumsetzung
12 Organisatorische Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Eckart Hagenloch, Stefan Müller und Mario Scherber
12.1 Prozessumsetzung als Teil des Process Management Life Cycle. . . . . . . . 226
12.2 Rahmenbedingungen und Herausforderungen der
Prozessumsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
12.3 Umsetzungsplanung und Umsetzungsformen. . . . . . . . . . . . . . . . . . . . . . . 228
12.4 Erfolgsfaktoren bei der Umsetzungsplanung/-durchführung . . . . . . . . . . 230
12.4.1 Identifikation der Adressaten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
12.4.2 Zeitliche Gestaltung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
12.4.3 Personelle Gestaltung (Ressourcen). . . . . . . . . . . . . . . . . . . . . . . . 232
12.4.4 Formen der Einbindung (I-K-B-Modell). . . . . . . . . . . . . . . . . . . . 232
12.4.5 Festgelegte Medien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
12.4.6 Interaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
12.5 Veränderungsmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
12.5.1 Veränderungsmanagement im Kontext des
Prozessmanagements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
12.5.2 Möglichkeit der Vereinfachung wiederkehrender Phasen. . . . . 239
12.5.3 Veränderungsverläufe und Reaktion der Beteiligten. . . . . . . . . . 241
12.5.4 Eisbergmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
12.5.5 Umgang mit Widerständen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
12.6 Prozessmarketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
13 Technische Umsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Tobias Rausch, Michael Puncochar, Kai-Helmut Eckert
und Christoph Moser
13.1 Überblick und Zielsetzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
13.2 Einführung/Implementierung von (neuen) IT-Anwendungen. . . . . . . . . 253
13.2.1 Klassifikation von IT-Anwendungen. . . . . . . . . . . . . . . . . . . . . . . 253
Inhaltsverzeichnis XV
13.2.2 Einführung von Standardsoftware/ERP-Systemen. . . . . . . . . . . . 254

13.2.3 Technische Umsetzung von Prozessen mittels
Workflow-Systemen und Prozess-Engines . . . . . . . . . . . . . . . . . . 256
13.2.4 Technische Umsetzung von Prozessen mit
Individualsoftware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
13.3 Entwicklung von Individualsoftware anhand eines Best
Practice-Projekts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
13.3.1 Spezifikationsmethode und Vorgehensmodell. . . . . . . . . . . . . . . 260
13.3.2 Vorgehen zum Anforderungsmanagement im Rahmen
der kontinuierlichen Weiterentwicklung. . . . . . . . . . . . . . . . . . . . 266
13.4 Zusammenfassung zur technischen Umsetzung von Prozessen . . . . . . . . 269
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Teil VI Prozessdurchführung und Prozesscontrolling

14 Umsetzung des Prozesscontrollings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Erik Guschlbauer und Christian Lichka
14.1 Motivation und Zielsetzung des Prozesscontrollings . . . . . . . . . . . . . . . . . 274
14.2 Einbettung des Prozesscontrollings in eine prozessorientierte
Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
14.3 Die Kennzahl – eingebettet in ein System. . . . . . . . . . . . . . . . . . . . . . . . . . . 277
14.3.1 Die strategische Variable „Ziel“. . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
14.3.2 Die strategische Variable „Kennzahl“. . . . . . . . . . . . . . . . . . . . . . . 277
14.3.3 Das Kennzahlensystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
14.4 Einbettung von Kennzahlensystemen in Management-Szenarien
am Beispiel des Prozessmanagements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
14.4.1 Definition von Anforderungen und der Erwartungshaltung . . . . 281
14.4.2 Initiale Einführung des Prozesscontrollings . . . . . . . . . . . . . . . . . 282
14.4.3 Controlling und Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
14.4.4 Periodische Reviews. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
14.5 Technische und organisatorische Lösungen zur Integration. . . . . . . . . . . 286
14.5.1 IT-gestütztes Prozesscontrolling. . . . . . . . . . . . . . . . . . . . . . . . . . . 286
14.5.2 Techniken zur Prozessanalyse basierend auf Kennzahlen. . . . . . 288
14.5.3 Vorgehensmodell zur Prozesscontrolling-Einführung . . . . . . . . 288
14.6 Erfolgsfaktoren des Prozesscontrollings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Teil VII Integrierte Managementsysteme

15 Integration strategisches Management und Prozessmanagement . . . . . . . . . 295
Christian Lichka und Erik Guschlbauer
15.1 Strategisches Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
XVI Inhaltsverzeichnis
15.1.1 Definition und Abgrenzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

15.1.2 „Uniqueness“ ist der Schlüssel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
15.2 Prozessmanagement: Das Fundament des strategischen
Managements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
15.3 Methoden zur Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
15.3.1 Balanced Scorecard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
15.3.2 Zielorientiertes Prozessmanagement . . . . . . . . . . . . . . . . . . . . . . . 305
15.4 „Perfect World“: Wie die Integration aussehen könnte . . . . . . . . . . . . . . . 306
15.5 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
16 Integration von Prozessmanagement und Unternehmensarchitektur-
Management – Konzepte und Vorgehensweisen zum Business
IT Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Christoph Moser und Lutz Kirchner
16.1 Motivation und Grundlagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
16.2 Eine stabile Grundlage für das Business IT Alignment. . . . . . . . . . . . . . . . 317
16.3 Vorgehensmodell für das Business IT Alignment. . . . . . . . . . . . . . . . . . . . 320
16.3.1 Phasen der Architecture Development Method. . . . . . . . . . . . . . 320
16.3.2 Ausgewählte Phasen und Ergebnistypen. . . . . . . . . . . . . . . . . . . . 323
16.4 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
17 Integration von Prozess- und Risikomanagement durch das Interne
Kontrollsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Thomas Müllner, Tim Farcher und Robert Strobl
17.1 Überblick über die Gestaltung der Integration. . . . . . . . . . . . . . . . . . . . . . . 334
17.2 Aufbau und Vorgehensmodell des Internen Kontrollsystems. . . . . . . . . . 335
17.2.1 Aufbau des Internen Kontrollsystems . . . . . . . . . . . . . . . . . . . . . . 335
17.2.2 Vorgehensmodell des Internen Kontrollsystems – Der
IKS-Life Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
17.2.3 Integration von Prozess- und Risikomanagement durch
den IKS-Life Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
17.3 Das Interne Kontrollsystem als Erfolgsfaktor des
Prozessmanagements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
17.3.1 Prozessstrategie: Das Interne Kontrollsystem unterstützt
den Prozessverantwortlichen bei der Erreichung
der Prozessziele. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
17.3.2 Prozessdokumentation: Analyse der operationellen
Risiken im Geschäftsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
17.3.3 Prozessoptimierung: Optimierung der Geschäftsprozesse
durch den IKS-Life Cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Inhaltsverzeichnis XVII
17.3.4 Prozessumsetzung: Überwachung der Prozessumsetzung

durch das Interne Kontrollsystem. . . . . . . . . . . . . . . . . . . . . . . . . . 349
17.3.5 Prozessdurchführung: Sicherstellung der ordnungsgemäßen,
effektiven und effizienten Prozessdurchführung durch das
Interne Kontrollsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
17.3.6 Prozesscontrolling: Bewertung der Zielerreichung durch das
Interne Kontrollsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
17.4 Optimierung des Internen Kontrollsystems durch das
Risikomanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
17.4.1 Funktion der Kontrolle prüfen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
17.4.2 Evaluierung der Organisation des Internen
Kontrollsystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
18 Integration von Prozess- und Wissensmanagement . . . . . . . . . . . . . . . . . . . . . 355
Robert Woitsch, Wilfrid Utz und Vedran Hrgovcic
18.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
18.2 Empfohlene Grundlagen und Begriffsabstimmung. . . . . . . . . . . . . . . . . . . 357
18.3 Wissensmanagement als Rahmenwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
18.3.1 Überblick über das Wissensmanagement-Rahmenwerk. . . . . . . 358
18.3.2 Definition der Ziele und Systemgrenzen . . . . . . . . . . . . . . . . . . . . 361
18.3.3 Modellieren der Wissensprodukte . . . . . . . . . . . . . . . . . . . . . . . . . 361
18.3.4 Projektorientierte Vorbereitung und Aufbau . . . . . . . . . . . . . . . . 365
18.3.5 Operativer Betrieb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
18.4 Wissensbilanz als Steuerungsinstrument. . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
18.4.1 Überblick über die Wissensbilanz. . . . . . . . . . . . . . . . . . . . . . . . . . 366
18.4.2 Beschreibung der Ausgangslage. . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
18.4.3 Spezifikation der Ziele und Erkennen von
Wirkungszusammenhängen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
18.4.4 Operative Datenanbindung und Steuerung durch die
Wissensbilanz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
18.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Teil VIII Abschluss

19 Zusammenfassung und Ausblick auf wichtige Trends. . . . . . . . . . . . . . . . . . . . 375
Anhang 1: ADONIS:Community Edition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Anhang 2: ADOit:Community Edition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Sachverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Abkürzungsverzeichnis
ABC Activity-based Costing

ACD Automatic Call Distribution
ACM Association for Computing Machinery
ACS Aviation Core System
ADM Architecture Development Method
ARIS Architektur integrierter Informationssysteme
BA Beschallungsanlage
BPEL Business Process Execution Language
BPM Business Process Management
BPMN Business Process Model and Notation
BPMN DI BPMN Diagram Interchange
BPMS Business Process Management Systems
BPR Business Process Re-Engineering
BSC Balanced Scorecard
BZ Bearbeitungszeit
CBOK Common Body of Knowledge
CIM Computation Independent Model
CIRS Critical Incidents Reporting System
CMMI Capability Maturity Model Integration
COBIT Control Objectives for Information and Related Technology
COSO Committee of Sponsoring Organizations of the Treadway
Commission
CPO Chief Process Officer
CR Change Request
DEMI Durchführungsverantwortung, Ergebnisverantwortung,
Mitarbeit/Mitwirkung, (zu) Informieren
DoDAF Department of Defense Architecture Framework
DOM Domänenobjektmodell
EABPM European Association of Business Process Management
EC Electronic Cash/Eurocheque
EDI Electronic Data Interchange
XIX
XX Abkürzungsverzeichnis
EFQM European Foundation for Quality Management

EPK Ereignisgesteuerte Prozesskette
ERP Enterprise Resource Planning
eTOM enhanced Telecom Operations Map
FA führungsrelevante Arbeitsanteile
FEA Federal Enterprise Architecture
FIDS Flight Information Display System
FMA Finanzmarktaufsicht
FMEA Failure Mode and Effects Analysis (deutsch: Fehlermöglichkeits-
und Einflussanalyse)
FSP Führungsspanne
GAZ Gesamtarbeitszeit
Gesamt-JPBKAP Gesamt-Jahres-Personalbedarfskapazität
GoM Grundsätze ordnungsmäßiger Modellierung
GOM Geschäftsobjektmodell
GPM Geschäftsprozessmanagement
GRC Governance, Risk & Compliance
GUI Graphical User Interface (deutsch: grafische Benutzeroberfläche)
IKS Internes Kontrollsystem
ISACA Information Systems Audit and Control Association
ISO International Organization for Standardization
IT Informationstechnologie
ITIL IT Infrastructure Library
itSMF IT Service Management Forum
JGAZ Jahres-Gesamtarbeitszeit
JPBKAP Jahres-Personalbedarfskapazität
JUKAP Jahres-Unternehmenskapazität
KGSt Kommunale Gemeinschaftsstelle für Verwaltungsmanagement
KPI/KPeI Key Performance Indicator
KPrI Key Process Indicator
KVP Kontinuierlicher Verbesserungsprozess
lmi leistungsmengeninduziert
lmn leistungsmengenneutral
M Menge
MaRisk Mindestanforderungen für das Risikomanagement
MDA Model Driven Architecture
OASIS Organization for the Advancement of Structured Information
Standards
OeNB Oesterreichische Nationalbank
OGC Office of Government Commerce
OLAP Online Analytical Processing
OMG Object Management Group
Abkürzungsverzeichnis XXI
P-FMEA Process Failure Mode and Effects Analysis (deutsch:

Prozess-Fehlermöglichkeits- und Einflussanalyse)
P-PBE prozessbasierte Personalbedarfsermittlung
PAG Prozess-Assessment für Geschäftsprozesse
PAU Prozess-Assessment für Unternehmen
PDCA-Zyklus „Plan – Do – Check – Act“-Zyklus
PfM Prozesspfadmenge
PIM Platform Independent Model
PM Prozessmenge
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
PMLC Process Management Life Cycle
PSM Platform Specific Model
QVP Qualifikationsverteilung pro Prozess
RACI Responsible, Accountable, Consulted, Informed (deutsch:
siehe DEMI)
RPZ Risikoprioritätszahl
SCS Society for Computer Simulation
SIPOC Supplier – Input – Process – Output – Customer (deutsch:
Lieferant – Einsatzfaktor – Prozess – Ergebnis – Kunde)
SLA Service Level Agreement (deutsch: Dienstgütevereinbarung)
SMART Specific – Measurable – Accepted – Realistic – Timely (deutsch:
spezifische Zielsetzung – Messbarkeit – Ableitbarkeit und aktive
Beeinflussbarkeit – realistische Zielsetzung – Terminierung)
SOA serviceorientierte Architektur
SOP Standard Operating Procedure (deutsch: Arbeitsanweisung)
t Zeit
TOGAF The Open Group Architecture Framework
TQM Total Quality Management
UAZ Unternehmensarbeitszeit
UML Unified Modeling Language
XML Extensible Markup Language
XPDL XML Process Definition Language
Teil I
Einführung
Einleitung
1
Anke Gericke, Franz Bayer und Harald Kühn
Zusammenfassung
Es wird das vorliegende Beitragswerk „Prozessmanagement für Experten“ moti-
viert und der Fokus sowie die Zielgruppe des Buchs beschrieben. Zusätzlich wird
eine Leseempfehlung gegeben, welche Kapitel für welche Tätigkeitsbereiche im
Unternehmen interessant sein könnten. Vor dem Hintergrund unserer praktischen
Erfahrungen und Erkenntnisse werden einzelne Aspekte des Prozessmanagements
herausgegriffen und vertiefend behandelt. Dabei werden sowohl aktuell diskutierte
Themen adressiert als auch solche, die immer wieder in Projekten nachgefragt werden.
Um die ausgewählten Themen in einem Gesamtkontext zu positionieren, verwenden
wir den Ansatz des Process Management Life Cycle (PMLC). Darüber hinaus nehmen
wir unter dem Stichwort „Integrierte Managementsysteme“ eine Positionierung des
Prozessmanagements zu anderen Managementansätzen vor. Im Fokus stehen dabei
das strategische Management, das Risikomanagement, das Unternehmensarchitektur-
Management sowie das Wissensmanagement, für welche jeweils eine Integration mit
dem Prozessmanagement beschrieben wird.
1.1 Motivation
Prozessmanagement ist nicht neu. Bereits seit Jahrzehnten wird Prozessmanagement in den
verschiedensten Branchen mit unterschiedlichen Reifegraden und diversen Schwerpunkten
betrieben. Ursprünglich kommend aus der Ablauforganisation haben sich Anfang der
1990er-Jahre insbesondere Business Process Re-Engineering-Ansätze etabliert, die sich seit
den 2000er-Jahren zu ganzheitlichen und kontinuierlichen Prozessmanagement-Ansätzen
A. Gericke (*) · F. Bayer · H. Kühn

BOC Information Technologies Consulting AG, Operngasse 20b, 1040 Wien, Österreich
e-mail: anke.gericke@boc-group.com
F. Bayer und H. Kühn (Hrsg.), Prozessmanagement für Experten, 3

DOI: 10.1007/978-3-642-36995-7_1, © Springer-Verlag Berlin Heidelberg 2013
4 A. Gericke et al.
weiterentwickelt haben. Treiber dieser Entwicklung ist zum einen die immer weiter fort-
schreitende Automatisierung von Prozessen durch Systeme und Technologien, wie
Standardsoftware, Workflow-Systeme oder dem Cloud Computing. Zum anderen hat sich
das Prozessmanagement von einem reinen Organisations- und Optimierungsinstrument
hin zu einem Führungsinstrument entwickelt und ist heute in den Führungsebenen der
Unternehmen als Managementansatz etabliert.
Es wurde bereits eine Vielzahl an Büchern zum Prozessmanagement veröffent-
licht. Zum Teil handelt es sich hierbei um umfangreiche Kompendien, die sehr detail-
liert, umfangreich und vereinzelt auch recht theoretisch Prozessmanagement-Ansätze
beschreiben. Darüber hinaus existieren zahlreiche Bücher, die einen klaren Fokus auf die
Prozessoptimierung legen.
Warum also ein weiteres Buch zu diesem Thema? Alle Autoren dieser Heraus
geberschaft sind seit vielen Jahren im Prozessmanagement tätig und haben zu
allen im Buch adressierten Themen zahlreiche Projekte sowohl in internationalen
Großkonzernen als auch im Mittelstand durchgeführt. Aus dieser Erfahrung her-
aus hat sich gezeigt, dass andere Werke teilweise an einem bestimmten Punkt „aufhö-
ren“. Als ein typisches Beispiel ist die Ableitung bzw. Erstellung einer Prozesslandkarte
zu nennen. Die Notwendigkeit einer Prozesslandkarte für das weitere Vorgehen
im Prozessmanagement-Zyklus wird meist betont und es wird vielmals auf die
Unterscheidung von Management-, Kern- sowie Unterstützungsprozessen hingewie-
sen. Eine weitergehende Hilfestellung für die Ableitung einer Prozesslandkarte, die
dem jeweiligen Unternehmen mit dessen Geschäftsmodell und Unternehmensstrategie
gerecht wird, wird oftmals nicht oder lediglich rudimentär gegeben. Dabei fehlen
zumeist detaillierte Hinweise, mittels welcher Dimensionen und welcher Schritte eine für
ein Unternehmen individuelle Prozesslandkarte abgeleitet werden kann. Ein ähnliches
Bild zeichnet sich auch für diverse andere Fragestellungen aus dem Prozessmanagement.
An diesem Punkt setzt das vorliegende Buch an und geht „einen Schritt weiter“, um kon-
krete Vorgehensweisen, Empfehlungen und Techniken für aktuelle als auch immer wie-
der in Projekten nachgefragte Themen im Prozessmanagement vorzustellen.
Darüber hinaus werden das Prozessmanagement sowie andere Managementansätze
oftmals isoliert voneinander betrachtet. Im Unternehmen bzw. einer Organisation treffen
jedoch täglich diverse Managementansätze aufeinander, die einer Integration bedürfen. In
diesem Zusammenhang spielt nicht nur die Berücksichtigung des Risikomanagements eine
Rolle. Auch das strategische Management, Unternehmensarchitektur-Management sowie
das Wissensmanagement weisen Berührungspunkte mit dem Prozessmanagement auf.
1.2 Fokus und Zielgruppe
Vor dem Hintergrund der beschriebenen Erfahrungen und Erkenntnisse ist das Buch als
Herausgeberschaft konzipiert. Es werden einzelne, wichtige Aspekte des Prozessmanage
ments herausgegriffen und vertiefend behandelt. Die Kapitel des Buchs können getrennt
1 Einleitung 5
voneinander gelesen werden, um so dem Arbeitsalltag gerecht zu werden und eine schnelle
Vertiefung des jeweiligen Themenfelds zu ermöglichen. Es wird dabei grundlegendes Wissen
zum Thema Prozessmanagement vorausgesetzt, da kein vollständiger Prozessmanagement-
Ansatz beschrieben wird. Stattdessen skizzieren wir den von uns verwendeten Ansatz des
Process Management Life Cycle (PMLC), um die ausgewählten Themen des Buchs im
Gesamtkontext des Prozessmanagement-Lebenszyklus zu positionieren.
Darüber hinaus nehmen wir unter dem Stichwort „Integrierte Managementsysteme“
eine Positionierung des Prozessmanagements zu anderen Managementansätzen vor.
Im Fokus stehen dabei das strategische Management, das Risikomanagement, das
Unternehmensarchitektur-Management sowie das Wissensmanagement, für welche
jeweils eine Integration mit dem Prozessmanagement beschrieben wird.
In den Kapiteln sind Erfahrungen aus vielen Praxisjahren festgehalten, die das Buch so
zu einem nützlichen Hilfsmittel und Impulsgeber machen. Die Themen sind dabei insbeson-
dere für Unternehmen bzw. Organisationen interessant, die in Bezug auf ihren umgesetzten
Prozessmanagement-Ansatz einen mittleren bis höheren Reifegrad besitzen. Als Konsequenz
bedeutet dies, dass unsere Publikation weniger als Einstiegswerk ins Prozessmanagement
gedacht ist, sondern vielmehr Prozessverantwortliche, Prozessexperten und Prozessberater
im Rahmen eines fortgeschrittenen Prozessmanagements ansprechen soll.
1.3 Der Process Management Life Cycle im Kontext

integrierter Managementsysteme
Bei der Umsetzung eines kontinuierlichen Prozessmanagements können diverse Vorge

hensmodelle zur Anwendung kommen (vgl. ebenso Abschn. 2.3). Wir verwenden hierzu
das Vorgehensmodell des Process Management Life Cycle, welches auf Basis des in den
1990er-Jahren entwickelten Business Process Management Systems-Rahmenwerks
(BPMS-Rahmenwerk) entstanden ist (Karagiannis 1995; Karagiannis et al. 1996; Junginger
2000; Kühn und Karagiannis 2001). Der PMLC besteht aus den Phasen Prozessstrategie,
Prozessdokumentation, Prozessoptimierung, Prozessumsetzung, Prozessdurchführung
und Prozesscontrolling. Zur Illustration von Modellierungsbeispielen werden im Buch
durchgängig Grafiken aus den BOC Management Office®-Werkzeugen ADONIS®, ADOit®
und ADOscore®genutzt.
Im folgenden Kap. 2 werden die genannten Phasen des PMLC sowie die daran betei-
ligten Rollen im Prozessmanagement zunächst kurz skizziert. Die einzelnen Phasen des
Vorgehensmodells bilden die Grundlage, um die in diesem Buch ausgewählten Themen
zu positionieren.
In den Kap. 3 und 4 werden Aspekte der Prozessstrategie aufgegriffen. Im Anschluss
daran widmen sich die Kap. 5 und 6 der Prozessdokumentation bzw. der Modellierung
von Prozessen. Auch Kap. 7 zum Thema Prozess-Compliance ist der Phase der Prozessdo
kumentation zugeordnet, da die Nachweiserbringung über die Einhaltung bestimmter
Compliance-Anforderungen häufig über eine Prozessdokumentation vorgenommen wird.
6 A. Gericke et al.
Unter Zuhilfenahme dokumentierter Prozesse kann eine Prozessoptimierung angesto-

ßen werden. Hierzu beschreiben die Kap. 8, 9 und 10 ausgewählte quantitative Techniken,
während sich Kap. 11 schwerpunktmäßig auf qualitative Techniken zur Optimierung von
Prozessen konzentriert.
Die im Rahmen einer Prozessoptimierung gestalteten Soll-Prozesse bedürfen einer
Umsetzung im Unternehmen. Diese Umsetzung kann sowohl organisatorische (vgl.
Kap. 12) als auch technische Dimensionen (vgl. Kap. 13) betreffen. Im Anschluss an
die Umsetzung der veränderten Prozesse erfolgt die Durchführung der Prozesse im
Regelbetrieb.
Während der Prozessdurchführung können ebenso bereits Daten gesammelt
werden, die in das Prozesscontrolling einfließen. Kapitel 14 greift die Auswertung
von Prozesskennzahlen in der Phase des Prozesscontrollings auf. Die gewonnenen
Analyseergebnisse sowie die daraus abgeleiteten Maßnahmen stoßen gleichzeitig einen
neuen Durchlauf des Process Management Life Cycle an, wobei bei einem erneuten
Durchlauf ggf. einzelne Phasen übersprungen werden (vgl. ebenso Abschn. 2.1.3).
Der Process Management Life Cycle oder besser gesagt das Prozessmanagement als
Managementansatz sollte nicht nur für sich allein betrachtet werden. Stattdessen bedarf
es einer Integration mit anderen in Organisationen eingesetzten Managementansätzen.
Innerhalb des strategischen Managements wird die Unternehmensstrategie eines
Unternehmens entwickelt. Diese hat unmittelbare Auswirkungen auf die vom Unter
nehmen verfolgte Prozessstrategie bzw. die ausgeführten Prozesse. Kapitel 15 greift die-
sen Zusammenhang auf und beschreibt Methoden der Integration.
Die Prozesse wiederum werden häufig durch IT-Systeme unterstützt, die inner-
halb des IT-Managements verwaltet werden. In diesem Zusammenhang spielt der
Ansatz des Unternehmensarchitektur-Managements eine wesentliche Rolle, da er
auf einer eher hohen Abstraktionsebene u. a. versucht, die Ausrichtung der IT auf die
Prozesse unter Berücksichtigung der Unternehmensstrategie zu verbessern. Kapitel 16
adressiert dieses Business IT Alignment und beschreibt Berührungspunkte zum
Prozessmanagement.
Ähnlich wie mit dem Unternehmensarchitektur-Management, welches Strategie-,
Prozess- und IT-Aspekte beinhaltet, verhält es sich mit dem Risiko- und dem
Wissensmanagement. Kapitel 17 widmet sich dem Risikomanagement und beschreibt
eine Integration mit dem Prozessmanagement durch das Interne Kontrollsystem
(IKS). Die Integration des Prozessmanagements mit dem Wissensmanagement und die
Nutzung von Wissensbilanzen wird in Kap. 18 thematisiert.
Abbildung 1.1 veranschaulicht noch einmal den Process Management Life Cycle
im Kontext integrierter Managementsysteme. Für die im Text aufgeführten und in der
Abbildung platzierten Kapitel stellt Tab. 1.1 eine inhaltliche Kurzangabe bereit.
1 Einleitung 7
1
Integrierte Managementsysteme
Strategisches Management
15 18
2
Prozessmanagement
3 4
Prozess- 17
strategie
Unternehmensarchitektur-Management
5
14 6
Prozess- 7
Wissensmanagement
Prozess-
Risikomanagement
controlling dokumentation
Process
Management
Life Cycle
Prozess- Prozess- 8
durchführung optimierung 9
10
11
Prozess-
umsetzung
13 12
16
IT-Management
19
Abb. 1.1 Aufbau des Buchs

8 A. Gericke et al.
Tab. 1.1 Erläuterung der einzelnen Buchkapitel

1 Einleitung
In der Einleitung wird die Idee des Buchs motiviert und auf den Fokus sowie die Zielgruppe
eingegangen. Es wird eine Positionierung des Process Management Life Cycle im Kontext
integrierter Managementsysteme vorgenommen.
2 Der Lebenszyklus des Prozessmanagements
Kapitel 2 erläutert den Process Management Life Cycle, der den Rahmen für das Buch aufspannt.
Anhand des Lebenszyklus werden die Kapitel dieses Buchs eingeordnet. Zusätzlich geht das Kapi-
tel auf die im Prozessmanagement verwendeten Rollen ein.
3 Prinzipien für die Gestaltung der Prozessarchitektur
Ein zentrales Element des Prozessmanagement-Ansatzes einer Organisation stellt dessen
Prozessarchitektur und hierbei insbesondere die Prozesslandkarte dar. Kapitel 3 geht der Frage
nach, wie Prozesslandkarten strukturiert, abgeleitet und eingesetzt werden können.
4 Umsetzung eines zielorientierten Prozessmanagements
Der Einsatz des Prozessmanagements zielt neben der Optimierung der Prozesse auch auf die
Ausrichtung der Prozesse auf die Unternehmensstrategie ab. Um dies zu unterstützen, beschreibt
Kap. 4 ein Vorgehen zur Ableitung von Prozesszielen. Darüber hinaus wird eine Technik zur
Ableitung der Prozessverantwortung vorgestellt.
5 Gestaltungs- und Modellierungsrichtlinien
Kapitel 5 erläutert Gestaltungs- und Modellierungsrichtlinien, die innerhalb der Prozessmodel-
lierung eingesetzt werden sollten, um die Einheitlichkeit, Lesbarkeit und Verständlichkeit der
dokumentierten Prozesse sicherzustellen bzw. zu erhöhen.
6 BPMN als Bestandteil der BPMS-Modellierungsmethode
In Kap. 6 wird eine Übersicht zur BPMS-Modellierungsmethode gegeben. Zusätzlich werden die
BPMN 2.0-Diagrammtypen in die BPMS-Modellierungsmethode eingebettet. Hierdurch wird auf
der einen Seite die BPMN ebenso für fachliche Einsatzszenarien nutzbar gemacht. Auf der anderen
Seite wird dadurch die Modellierung ausführungsrelevanter, technischer Aspekte ermöglicht.
7 Prozess-Compliance
Die Nachweiserbringung zur Einhaltung von Compliance-Anforderungen bindet zunehmend
mehr Ressourcen in Organisationen. Kapitel 7 stellt ein Vorgehen vor, wie unter Zuhilfenahme
dokumentierter Prozesse/Prozesslandkarten dieser Herausforderung begegnet werden kann.
8 Quantitative Analyse und Planung von Prozessen
Innerhalb der Prozessoptimierung spielt die quantitative Analyse von Prozessen eine wichtige Rolle,
die in Kap. 8 aufgegriffen wird. Neben einem Phasenmodell werden Techniken der statischen und
dynamischen Analyse, wie z. B. rechnerische Auswertung oder Simulation, betrachtet.
9 Prozessbasierte Personalbedarfsermittlung
Im Zuge einer Prozessoptimierung kann ebenso eine prozessbasierte Personalbedarfsermittlung
zum Einsatz kommen. Kapitel 9 beschreibt eine Vorgehensweise sowie Berechnungsmöglichkeiten
und setzt sich mit Herausforderungen dieser Technik auseinander.
10 Prozesskostenrechnung
Eine weitere Technik zur Unterstützung der Prozessoptimierung stellt die Prozesskostenrechnung
dar. In Kap. 10 wird ein praxiserprobtes Vorgehensmodell zur Durchführung einer Prozesskosten-
rechnung inkl. Anwendungsbeispiel beschrieben.
(Fortsetzung)
1 Einleitung 9
Tab. 1.1 (Fortsetzung)
11 Organisatorische Prozessoptimierung
Im Gegensatz zu den quantitativen Ansätzen zur Prozessoptimierung wird in Kap. 11 die organisa-
torische Prozessoptimierung beleuchtet. Hierbei wird schwerpunktmäßig auf qualitative Techni-
ken zur Optimierung von Prozessen eingegangen.
12 Organisatorische Umsetzung
Kapitel 12 widmet sich der organisatorischen Umsetzung von Prozessänderungen und geht auf
die Umsetzungsplanung und -durchführung ein. Darüber hinaus wird das Thema Veränderungs
management im Kontext von Prozessanpassungen bzw. der Einführung von Soll-Prozessen
adressiert.
13 Technische Umsetzung
Als Pendant zur organisatorischen Umsetzung wird in Kap. 13 die technische Umsetzung bei
Prozessänderungen beschrieben. Es werden verschiedene Methoden zur Einführung/Implemen-
tierung von IT-Anwendungen sowie ein Best Practice-Projekt vorgestellt.
14 Umsetzung des Prozesscontrollings
Eingebettet in den PMLC wird in Kap. 14 der Prozesscontrolling-Regelkreis bestehend aus der
initialen Einführung, dem Controlling sowie einem Review beschrieben. Ergänzend wird u. a. auf
Aspekte eines IT-gestützten Prozesscontrollings eingegangen.
15 Integration strategisches Management und Prozessmanagement
Kapitel 15 widmet sich dem Thema der Integration des strategischen Managements und des
Prozessmanagements. Für deren Integration wird die Methode der Balanced Scorecard beschrie-
ben sowie der Bezug zum zielorientierten Prozessmanagement hergestellt.
16 Integration von Prozessmanagement und Unternehmensarchitektur-Management –
Konzepte und Vorgehensweisen zum Business IT Alignment
Vor dem Hintergrund einer besseren Unterstützung des Business IT Alignment wird in Kap. 16
die Integration von Geschäftsprozess- und Unternehmensarchitektur-Management beschrieben.
Dafür wird die TOGAF® Architecture Development Method herangezogen und durch Beispiele
unterlegt.
17 Integration von Prozess- und Risikomanagement durch das Interne Kontrollsystem
Die Integration von Prozess- und Risikomanagement ist Gegenstand von Kap. 17. Hierbei wird
das Interne Kontrollsystem (IKS) als Bindeglied zwischen diesen beiden Managementansätzen
betrachtet.
18 Integration von Prozess- und Wissensmanagement
Kapitel 18 widmet sich der Integration des Prozessmanagements mit dem Wissensmanagement.
Hierfür wird eine Vorgehensweise und ein Modellierungsrahmen für das Unternehmenswissen
vorgestellt. Einen besonderen Aspekt bildet dabei die Wissensbilanz.
19 Zusammenfassung und Ausblick auf wichtige Trends
In Kap. 19 wird eine kurze Zusammenfassung gegeben und einige aus Sicht der Herausgeber
wichtige Trends skizziert.
10 A. Gericke et al.
1.4 Leseempfehlung
In den zuvor vorgestellten Kapiteln werden einzelne Themen detailliert beschrieben.

Der Zusammenhang der Kapitel untereinander kann über den Process Management Life
Cycle hergestellt werden.
Das Buch richtet sich an Experten, die ihr Tätigkeitsfeld im Prozessmanagement bzw.
angrenzenden Disziplinen haben. Tabelle 1.2 enthält eine Übersicht, welche Kapitel
besonders für welche Bereiche interessant sein könnten.
Tab. 1.2 Leseempfehlung

Bereich Kapitelempfehlung
Betriebsorganisation/Inhouse Consulting Kap. 2, 3, 4, 8, 9, 10, 11, 12 und 18
Fachbereich Kap. 2, 5, 7 und 11
Controlling Kap. 2, 4, 14 und 15
Unternehmensentwicklung Kap. 2, 3, 4, 15 und 18
IT Kap. 2, 6, 13 und 16
IKS/Risikomanagement/Qualitätsmanagement Kap. 2, 7 und 17
Die Kapitel enthalten Handlungsempfehlungen, wie das entsprechende Thema adres-

siert bzw. umgesetzt werden kann. Neben der Vorgehensbeschreibung wird auch ein
Bezug zu den Rollen des Prozessmanagements hergestellt. Detaillierte Techniken und/
oder Erfolgsfaktoren sowie zahlreiche Beispiele ergänzen die jeweiligen Kapitel.
Die Kapitel sind in einem sachlichen Sprachstil geschrieben und beinhalten eine
Übersicht der zitierten Literatur am Ende jedes Kapitels. Die Kapitel können unab-
hängig voneinander gelesen werden. Ergänzend sind an passenden Stellen Verweise
auf andere Kapitel enthalten, um den komplexen Zusammenhängen innerhalb des
Prozessmanagements und angrenzender Managementansätze Rechnung zu tragen sowie
dem Leser den Einstieg in verwandte Themen zu erleichtern.
Literatur
Junginger S (2000) Modellierung von Geschäftsprozessen: State-of-the-Art, neuere Entwicklungen

und Forschungspotenziale. BPMS-Bericht, Abteilung Knowledge Engineering, Institut für
Informatik und Wirtschaftsinformatik, Universität Wien, Wien
Karagiannis D (1995) BPMS: Business Process Management Systems. ACM SIGOIS Bull 16(1):10–13
Karagiannis D, Junginger S, Strobl R (1996) Introduction to Business Process Management
Systems Concepts. In: Scholz-Reiter B, Stickel E (Hrsg) Business Process Modelling. Springer,
Berlin, S 81–106
Kühn H, Karagiannis D (2001) Modellierung und Simulation von Geschäftsprozessen. WISU
30(8–9/01):1161–1170
Der Lebenszyklus des
Prozessmanagements 2
Anke Gericke, Franz Bayer, Harald Kühn, Tobias Rausch
und Robert Strobl
Zusammenfassung
Der Process Management Life Cycle (PMLC) stellt ein zyklisches Vorgehensmodell für
das Prozessmanagement dar und unterstützt Unternehmen darin, durch Geschäfts
prozessmanagement den Unternehmenserfolg zu steigern. Der PMLC besteht aus
den sechs Phasen Prozessstrategie, Prozessdokumentation, Prozessoptimierung,
Prozessumsetzung, Prozessdurchführung und Prozesscontrolling, die im Einzelnen
kurz erläutert werden. Darüber hinaus werden die Anwendungsmöglichkeiten des
PMLC sowie die Rollen beschrieben, die unterschiedliche Aufgaben im Rahmen des
Prozessmanagements wahrnehmen. Zu diesen Rollen zählen primär der Chief Process
Officer, der Prozessverantwortliche, der Prozessexperte, der Prozessmitarbeiter, der
Prozessberater und der Prozesscontroller. Zum einen gibt dieses Kapitel einen kompak-
ten Überblick über einen Prozessmanagement-Ansatz. Zum anderen ist dieses Kapitel
die Grundlage für die weitere Strukturierung des vorliegenden Buchs. Einzelne Themen,
die in den vorgestellten Phasen des PMLC lediglich angerissen werden können, werden
in den folgenden Kapiteln des Buchs vertieft. Der Bezug der einzelnen Themen unterei-
nander kann über den PMLC und die involvierten Rollen stets hergestellt werden.
A. Gericke (*) · F. Bayer · H. Kühn · T. Rausch

e-mail: anke.gericke@boc-group.com
R. Strobl
BOC Unternehmensberatung GmbH, Rabensteig 2, 1010 Wien, Österreich

2.1 Überblick über den Lebenszyklus des

Prozessmanagements
2.1.1 Einordnung der Begrifflichkeiten
Unternehmen unterliegen einem kontinuierlichen Wandel. Die Gründe hierfür sind

vielfältig, wie bspw. Änderungen der Märkte, in denen Unternehmen agieren, oder
Veränderungen in den strategischen Zielsetzungen. Um mit diesen Veränderungen
umgehen zu können, müssen Unternehmen nicht nur ihre strategische Ausrichtung und
ihre Unternehmensziele im Auge behalten, sondern ebenso ihre Geschäftsprozesse kon-
tinuierlich überprüfen und anpassen. Dafür eignet sich ein zyklisches Vorgehensmodell
wie der Process Management Life Cycle (PMLC).
Definition
Unter einem Prozess (synonym: Geschäftsprozess) wird eine Abfolge von Aktivitäten
verstanden, die von Akteuren durchgeführt und zur Erstellung eines definierten Ergeb-
nisses benötigt werden. Innerhalb der Aktivitäten werden Artefakte, wie z. B. Formu-
lare oder Informationen, unter Zuhilfenahme von Ressourcen bearbeitet. (Junginger
2000; Kühn und Karagiannis 2001)
Der PMLC hilft Unternehmen, ihre Geschäftsprozesse kontinuierlich zu ver-

bessern, wobei Geschäftsprozesse sowohl Kernprozesse als auch Management-
und Unterstützungsprozesse umfassen können. Der PMLC kann im gesamten
Unternehmen, aber auch nur in ausgewählten Bereichen angewendet werden. Dieser
strukturierte und einfach anwendbare Ansatz unterstützt Unternehmen darin, durch
Geschäftsprozessmanagement ihren Unternehmenserfolg zu steigern.
Definition
Unter Prozessmanagement (synonym: Geschäftsprozessmanagement) wird grundsätzlich
die Planung, Steuerung, Ausführung und Kontrolle aller Geschäftsprozesse unter Berück-
sichtigung des Umfelds verstanden. Das Umfeld beinhaltet z. B. die Unternehmensstrate-
gie, die Aufbauorganisation, technische Ressourcen und die Informationstechnologie (IT).
2.1.2 Die Phasen des Process Management Life Cycle
Um die Aufgaben des Prozessmanagements erfolgreich umsetzen zu können, bietet der PMLC
ein sechsstufiges Vorgehen bestehend aus den Phasen Prozessstrategie, Prozessdokumentation,
Prozessoptimierung, Prozessumsetzung, Prozessdurchführung und Prozesscontrolling (vgl.
ebenso Petzmann et al. 2007). Abbildung 2.1 visualisiert die Phasen in ihrem Zyklus.
2 Der Lebenszyklus des Prozessmanagements 13
Abb. 2.1 Der Process

Management Life Cycle
(PMLC) Prozess-
strategie
Prozess- Prozess-
Prozess- Prozess-
durchführung optimierung
Prozess-
umsetzung
Die Inhalte der einzelnen Phasen werden an dieser Stelle skizziert, ehe in den folgenden
Abschnitten detaillierter darauf eingegangen wird. Die Phasen des PMLC bilden nicht nur
eine einfache „Hülle“. Angereichert durch Methoden, Techniken und Werkzeuge werden
in den folgenden Kapiteln des Buchs konkrete Ansätze vorgestellt, die beschreiben, wie
innerhalb der einzelnen Phasen bzw. bei Teilaspekten davon vorzugehen ist.
Die Phase der Prozessstrategie (vgl. ebenso Abschn. 2.4.1) setzt auf der Unterneh
mensstrategie und den darin formulierten Unternehmenszielen auf und definiert, wie
diese Ziele mithilfe der Geschäftsprozesse eines Unternehmens erreicht werden kön-
nen. Um einen Überblick über die im Unternehmen vorhandenen Geschäftsprozesse zu
erhalten, wird eine Prozesslandkarte aufgestellt. Für ausgewählte Prozesse werden dann
Prozessziele und messbare Kennzahlen abgeleitet.
In der sich anschließenden Phase der Prozessdokumentation (vgl. ebenso Abschn. 2.4.2)
werden die Ist-Prozesse (in Einzelfällen auch Soll-Prozesse, vgl. Abschn. 2.1.3) des
Unternehmens erhoben, dokumentiert und veröffentlicht. Die Dokumentation erfolgt mit-
tels Modellen, wobei Modellierungsrichtlinien eine einheitliche Darstellung sicherstellen.
Dadurch wird nicht nur eine konsistente Abbildung der vorliegenden Sachverhalte, son-
dern ebenso eine leichtere Lesbarkeit der Geschäftsprozessmodelle ermöglicht. Neben der
reinen Modellierung der Prozessabläufe können ebenso Zuordnungen zu Elementen, wie
Organisationseinheiten, Rollen, Dokumenten oder IT-Ressourcen, erfolgen.
Basierend auf der Prozessdokumentation werden in der Phase der Prozessoptimierung
(vgl. ebenso Abschn. 2.4.3) die Ist-Prozesse des Unternehmens analysiert. Darauf aufbau-
end werden mögliche Kandidaten für Prozessoptimierungen priorisiert. Die ausgewählten
Prozesskandidaten werden dann in separaten Projekten einer Prozessoptimierung unterzo-
gen, wobei die Effizienz und Effektivität der Prozesse im Sinne der definierten Prozessziele
verbessert werden soll. Als Grundlage hierfür können Ergebnisse von Performance-Analysen
aus der Phase des Prozesscontrollings herangezogen werden – sofern der PMLC bereits zum
wiederholten Male durchgeführt wird. Für die Prozessoptimierung und die daraus resultie-
rende Erarbeitung von Soll-Prozessen stehen zahlreiche Instrumente zur Verfügung (z. B.
Produkt-/Prozessübersicht, Personalbedarfsermittlung, Prozesskostenrechnung).
In der Prozessumsetzung (vgl. ebenso Abschn. 2.4.4) werden die zuvor erarbei-
teten Soll-Prozesse sowohl in organisatorischer als auch in technischer Hinsicht im
Unternehmen eingeführt und verankert. Es muss dafür Sorge getragen werden, dass
die definierten Soll-Prozesse unternehmensweit „gelebt“ werden, da sie ab diesem
Zeitpunkt die neuen Ist-Prozesse darstellen. Häufig erfolgt die Umsetzung der verän-
derten Prozesse noch im Rahmen der in der vorherigen Phase aufgesetzten, jeweiligen
Prozessoptimierungs-Projekte, wobei insbesondere Konzepte und Techniken aus dem
Veränderungsmanagement berücksichtigt und eingebunden werden sollten.
In der Phase der Prozessdurchführung (vgl. ebenso Abschn. 2.4.5) werden die aktu-
ell geltenden Ist-Prozesse im Rahmen des täglichen Geschäfts des Unternehmens aus-
geführt. Während der Durchführung der Prozesse können Monitoring-Daten für
das sich anschließende Prozesscontrolling aufgezeichnet werden. Alternativ können
ebenso „manuelle“ Prozessaudits durchgeführt werden, bei denen die Compliance bzgl.
bestimmter Vorgaben anhand von Assessments überprüft wird.
Schließlich werden diese Daten im Rahmen des Prozesscontrollings (vgl. ebenso
Abschn. 2.4.6) regelmäßig ausgewertet und hinsichtlich der definierten Prozessziele, Kenn
zahlen oder Vorgaben analysiert und bewertet (z. B. hinsichtlich Kosten oder Nutzen). Die
Ergebnisse dienen der Steuerung der Prozesse im Unternehmen und bilden die Grundlage
für das erneute Durchlaufen des PMLC, insbesondere der Phase der Prozessoptimierung.
2.1.3 Anwendung des Process Management Life Cycle
Um einen kontinuierlichen Prozessmanagement- und Prozessverbesserungs-Ansatz

nachhaltig im Unternehmen zu etablieren, sollten die im vorangegangenen Abschnitt
beschriebenen Phasen des PMLC in der definierten Reihenfolge durchgeführt und regel-
mäßig wiederholt werden.
Je nach Situation im Unternehmen, insbesondere zu Beginn eines kontinuierli-
chen Prozessmanagement-Ansatzes, kann es jedoch auch sinnvoll sein, einzelne Phasen
des vorgestellten Vorgehensmodells zu überspringen. So ist es zum Beispiel denkbar,
nach dem Durchlaufen der Phase der Prozessstrategie und einer allerersten, groben
Prozessdokumentation bereits in die Phase des Prozesscontrollings zu springen, um eine
erste Aussage in Bezug auf die Einhaltung der definierten Prozessziele zu erhalten. Im
Anschluss an diesen verkürzten Durchlauf des PMLC kann ein vollständiger Durchlauf
des Vorgehensmodells erfolgen, in dem dann auch Prozesse optimiert und die identifi-
zierten Soll-Prozesse umgesetzt werden. Abbildung 2.2 veranschaulicht noch einmal den
beschriebenen Sachverhalt.
Abb. 2.2 Überspringen von

Phasen im PMLC
Prozess-
strategie
Prozess- Prozess-
Prozess- Prozess-
Prozess-
umsetzung
In einzelnen Fällen ist es ebenso möglich, dass im Rahmen der Prozessdokumentation

keine Ist-Prozesse, sondern bereits Soll-Prozesse dokumentiert werden. In diesem Fall
kann die Phase der Prozessoptimierung übersprungen und direkt mit der Umsetzung
der Soll-Prozesse begonnen werden. Bei diesem „Grüne Wiese“-Ansatz ist jedoch zu
beachten, dass Soll-Prozesse nicht ohne eine entsprechende Informationsbasis erstellt
werden können. Folglich müssten zumindest Prozess-Steckbriefe oder Best Practice-
Modelle, die an die Situation im Unternehmen angepasst werden können, vorhanden
sein. Diese sollten durch Personen ergänzt werden, die die Modellierung unterstützen
und über ausgesprochenes Experten- bzw. Domänenwissen verfügen.
Der PMLC stellt einen Prozessmanagement-Ansatz dar, der die Ziele der Unterneh
mensstrategie auf Prozesse herunterbricht und umsetzt. Hierfür steht ein Vorgehensmodell
bestehend aus den oben genannten sechs Phasen inkl. diverser Techniken und Werkzeuge
zur Verfügung. Bezüglich der Phasen der Optimierung und der Umsetzung von Prozessen
wurde bereits im vorangegangenen Abschnitt angeführt, dass diese Schritte oftmals in
separaten Prozessoptimierungs-Projekten durchgeführt werden. Innerhalb dieser Projekte
wiederum werden zumeist ebenso Vorgehens- bzw. Phasenmodelle angewendet, um
die Projekte effizient abwickeln zu können. Als Beispiele für solche Vorgehensmodelle
im Rahmen eines Prozessoptimierungs-Projekts können das Phasenmodell des Six
Sigma-Ansatzes (vgl. Nr. 1 in Abb. 2.3 sowie Abschn. 2.3) oder das Phasenmodell des
Deming-Kreises (vgl. Nr. 3 in Abb. 2.3 sowie Abschn. 2.3) genannt werden. Aber auch
die Phasen des PMLC können als Vorgehensmodell dienen (vgl. Nr. 2 in Abb. 2.3). Im
Unterschied zur Anwendung des PMLC als Prozessmanagement-Ansatz werden im
Rahmen von Prozessoptimierungs-Projekten zumeist lediglich die PMLC-Phasen als
Mittel zur Strukturierung der Prozessoptimierungs-Projekte verwendet. Techniken und

Werkzeuge aus dem PMLC können zum Teil in Prozessoptimierungs-Projekten ebenso
verwendet werden; sie werden jedoch häufig um Techniken aus anderen Optimierungs
ansätzen ergänzt. Ein weiterer Unterschied besteht darin, dass die unterschiedlichen
Vorgehensmodelle bei Prozessoptimierungs-Projekten im Gegensatz zum PMLC als
Prozessmanagement-Ansatz nur auf einen bzw. einige wenige Prozesse angewendet wer-
den. Abbildung 2.3 soll diesen Zusammenhang noch einmal verdeutlichen.
PMLC als
Prozessmanagement-Ansatz
Unternehmensstrategie
Vorgehensmodelle für
Prozessoptimierungs-/
umsetzungsprojekte
Phasen nach
Define Six Sigma
Control Measure
Improve Analyze
2
Phasen
Prozess- des PMLC
strategie
3
Phasen des
DEMING-Zyklus ACT PLAN Prozess- Prozess-
Prozess- Prozess-
Prozess-
CHECK DO umsetzung
Abb. 2.3 Der PMLC als Prozessmanagement-Ansatz vs. als Vorgehensmodell für Optimierungs-/
Umsetzungsprojekte
2.2 Die Rollen im Rahmen des Prozessmanagements
2.2.1 Wesentliche Rollen
Im Rahmen des Prozessmanagements können im Allgemeinen die folgenden Rollen

unterschieden werden:
• Chief Process Officer/Prozesssponsor

• Prozessverantwortlicher
• Prozessexperte
• Prozessmitarbeiter
• Prozessberater
• Prozesscontroller
Die Rolle des Chief Process Officer (CPO) bzw. des Prozesssponsors bezieht sich auf das
gesamte Prozessmanagement-System im Unternehmen. Der CPO trägt die Verantwortung
für die Verbesserung und Weiterentwicklung des Prozessmanagements im Unternehmen.
Darüber hinaus koordiniert er unternehmensübergreifende Geschäftsprozesse und unter-
stützt oder verantwortet strategische Prozessänderungen. Die Geschäftsleitung eines
Unternehmens sollte als Sponsor des Prozessmanagements auftreten und die Verant
wortung für die Ergebnisse des gesamten Prozessmanagement-Systems besitzen. Folglich
sollte auch die Rolle des Chief Process Officer durch die Geschäftsleitung repräsentiert
werden. Da die genannten Aufgaben eines CPO je nach Unternehmensgröße sehr umfang-
reich werden können, kann die Geschäftsleitung die Rolle des CPO auch delegieren, bspw.
an eine Stabsstelle oder eine Organisationsabteilung.
Der Prozessverantwortliche ist für ausgewählte Geschäftsprozesse des Unternehmens
verantwortlich. Seine Verantwortung bezieht sich dabei auf die Erreichung der
Prozessziele, die Durchführung der Prozesse sowie die Gestaltung der Prozesse.
Außerdem ist er für die Einhaltung von Normen, Richtlinien etc., die sich auf die Prozesse
beziehen, verantwortlich. Folglich muss der Prozessverantwortliche die Compliance sei-
ner Prozesse gewährleisten.
Der Prozessexperte besitzt ein tiefes Know-how eines Geschäftsprozesses und unter-
stützt damit insbesondere den Prozessverantwortlichen. Er gibt fachlichen Input für die
Geschäftsprozessmodellierung und führt sie ggf. selbst durch. Die Rolle des Prozess
experten ist im Fachbereich angesiedelt und bezieht sich auf ausgewählte Prozesse aus
dem jeweiligen Fachbereich.
Der Prozessmitarbeiter ist für die operative Ausführung der Geschäftsprozesse zustän-
dig. Er gilt als fachlicher Wissensträger und kann den Prozessexperten in seiner organi-
satorischen Arbeit als wertvoller Inputgeber unterstützen.
Die Rolle des Prozessberaters ist in der Regel als Stabsstelle oder in der Organi
sationsabteilung eines Unternehmens angesiedelt. Sie bezieht sich auf das gesamte
Prozessmanagement-System des Unternehmens. Der Prozessberater unterstützt die
anderen Rollen in methodischer Hinsicht und ist für das Training zu Prozessmethoden
und -tools verantwortlich. Er unterstützt die Planung und Durchführung von Prozess
management- bzw. Prozessverbesserungs-Projekten und führt die Organisation und
Moderation von Prozessmanagement-Workshops durch. Der Prozessberater kann
ebenso innerhalb der Geschäftsprozessmodellierung als Unterstützung und zur methodi-
schen Qualitätssicherung eingesetzt werden.
Der Prozesscontroller führt das Reporting hinsichtlich der Erreichung der Prozessziele
sowie der Umsetzung der festgelegten Maßnahmen durch. Je nach Unternehmen
kann die Ausgestaltung und Verankerung dieser Rolle sehr unterschiedlich sein.
Manche Unternehmen führen die Rolle des Prozesscontrollers explizit ein, insbeson-
dere wenn quantitative Auswertungen bezüglich der Prozesse durchgeführt werden
sollen. Der Aufgabenbereich des Prozesscontrollers kann sich dabei über alle Prozesse
der Prozesslandkarte erstrecken. In diesem Fall ist die Rolle meist als Stabsstelle oder in
der Organisationsabteilung des Unternehmens verankert und die Erstellung von pro-
zessübergreifenden Analysen steht im Vordergrund. Alternativ kann sich die Rolle
des Prozesscontrollers auch nur auf ausgewählte Prozesse des Unternehmens bezie-
hen. Bei dieser Rollenausgestaltung unterstützt der Prozesscontroller zumeist den
Chief Process
Prozessberater
Officer unterstützt
gibt
wirkt mit bei
ist verantwortlich für methodische
Verbesserungen
Unterstützung
Prozessmanagement-System gibt
fachlichen
erhebt/analysiert Daten Input
Prozess- Konkreter modelliert

Prozessexperte
controller Geschäftsprozess
unterstützt
führt aus ist verantwortlich für
Prozess-
verantwortlicher
Prozess-
mitarbeiter unterstützt
Abb. 2.4 Das Zusammenspiel der wesentlichen Rollen im Rahmen des Prozessmanagements
Prozessverantwortlichen. In der Praxis hat sich gezeigt, dass durch die Trennung der bei-
den Rollen Prozessverantwortlicher und Prozesscontroller oftmals eine höhere Objektivität
bzgl. der Aussagen der Prozessauswertungen erzielt wird. Schließlich kann auch auf die
explizite Ausgestaltung der Rolle eines Prozesscontrollers verzichtet werden, indem die mit
dieser Rolle verbundenen Aufgaben bspw. von Controllern aus dem zentralen Controlling
wahrgenommen werden.
Abbildung 2.4 zeigt die beschriebene Interaktion zwischen den vorgestellten Rollen
des Prozessmanagements.
2.2.2 Weitere involvierte Rollen
Im Kontext des Prozessmanagements besteht die Möglichkeit – je nach Größe des

Unternehmens – die zuvor beschriebenen Rollen zu detaillieren. In größeren Unternehmen
kann beispielsweise eine Spezialisierung der Rolle des Prozessexperten hinsichtlich der
Produkte, Sparten etc. des Unternehmens sinnvoll sein. Darüber hinaus können bei sehr
großen (umfassenden) Prozessen in Unternehmen Teil-Prozessverantwortliche ernannt
werden, die den Prozessverantwortlichen unterstützen.
Das Prozessmanagement steht nicht losgelöst von anderen Managementansätzen im
Unternehmen. So weist es insbesondere Schnittstellen zum strategischen Management,
Risikomanagement, Wissensmanagement, Unternehmensarchitektur-Management und
anderen Bereichen innerhalb der IT, wie z. B. dem IT-Servicemanagement, auf. In diesen
Kontexten können beispielsweise die folgenden Rollen relevant werden:
• Zielverantwortlicher
• Risikomanager
• Risikobewerter
• Qualitätsmanager
• Compliance-Manager
• Safety-/Security-Manager
• Unternehmensarchitekt
• Business-Analyst
• IT-Architekt
• IT-Analyst
• IT-Servicemanager
Die Rollendefinitionen müssen in den jeweiligen Unternehmensbereichen/Domänen

erfolgen, sollten aber mit den Rollen des Prozessmanagements abgestimmt wer-
den, um Überschneidungen in den Aufgaben der Rollen zu verhindern. Dies ist ins-
besondere im Kontext integrierter Managementsysteme (vgl. Kap. 15, 16, 17 und 18)
sicherzustellen.
2.3 Einordnung des Process Management Life Cycle
Das Thema Prozessmanagement hat sich seit den 1990er-Jahren des letzten Jahrtausends
aus verschiedenen Disziplinen und Ansätzen heraus entwickelt. Maßgebliche Beispiele
hierzu sind das Business Process Re-Engineering, die Automatisierung von Prozessen
mittels Workflow-Management-Systemen sowie das Qualitätsmanagement.
Die Anfänge des Business Process Re-Engineering (BPR) wurden zu Beginn der
1990er-Jahre im Wesentlichen durch Davenport (1993) sowie Hammer und Champy
(1993) gemacht (Harmon 2007b). Verschiedenen BPR-Ansätzen ist gemein, dass sie eine
radikale Veränderung der Prozesse im Unternehmen fordern, um eine größtmögliche
Verbesserung der Prozessleistung zu erzielen.
Mehr oder minder parallel zur BPR-Entwicklung stand zunehmend die Unterstützung
von Prozessen durch IT bzw. Workflow-Management-Systeme im Fokus von Forschung
und Praxis. Als Rahmenwerke, die diesen Aspekt berücksichtigen, sind beispielhaft
der Ansatz bezüglich der Architektur integrierter Informationssysteme (ARIS) (Scheer
1992, 1999; Scheer et al. 2005) und das Business Process Management Systems (BPMS)-
Paradigma (Karagiannis 1995; Karagiannis et al. 1996; Junginger 2000; Kühn und
Karagiannis 2001) zu nennen.
Das Qualitätsmanagement hat sich unabhängig vom Prozessmanagement entwickelt
und erste Ansätze diesbezüglich datieren bereits deutlich früher. So hat der Deming-Kreis,
der auf den Shewart-Zyklus zurückgeht, seine Wurzeln in den 1950er-Jahren (Deming
2000; Kamiske und Brauer 2008). Der Deming-Kreis ist auch unter der Bezeichnung
PDCA-Zyklus bekannt, da er die vier Phasen Plan – Do – Check – Act umfasst (Schmitt
und Pfeifer 2010). Der Zyklus findet ebenso Anwendung beim Kontinuierlichen
Verbesserungsprozess (KVP), der wiederum auf den Kaizen-Ansatz (Imai 1986) zurück-
geht (Witt und Witt 2007). Der KVP und der Kaizen-Ansatz zielen nicht nur auf die konti-
nuierliche Verbesserung von Prozessen in Unternehmen, sondern z. B. auch auf Produkte
ab, werden aber vielfach im Prozess-Kontext im Sinne eines Prozessmanagement-Ansatzes
eingesetzt. Ebenfalls seinen Ursprung im Qualitätsmanagement hat der Six Sigma-Ansatz
(vgl. z. B. Pyzdek und Keller 2009; Toutenburg und Knöfel 2009; Gygi et al. 2010). Six
Sigma folgt den Phasen Define – Measure – Analyze – Improve – Control, um Prozesse zu
verbessern. Dabei kommen insbesondere statistische Verfahren zum Einsatz.
In Forschung und Praxis gibt es aktuell kein standardisiertes Vorgehen für die
Durchführung von Prozessmanagement in Unternehmen. Die existierenden Prozess
management-Zyklen/-Kreisläufe gehen jedoch mehr oder minder stark auf die vorgestell-
ten Ansätze zurück und ähneln sich in ihren Phasen und deren Ablauf.
Der in diesem Kapitel vorgestellte Process Management Life Cycle wurde maß-
geblich durch das oben genannte BPMS-Rahmenwerk beeinflusst. Die Phasen ent-
sprechen im Wesentlichen denen des BPMS-Rahmenwerks. Lediglich die Phase des
Gestaltungsprozesses wurde im PMLC verfeinert und es werden hier die Phasen der
Prozessdokumentation und der Prozessoptimierung unterschieden. Abbildung 2.5 ver-
anschaulicht den Zusammenhang der beiden Ansätze.
Prozess-
strategie
Strategischer
Entscheidungsprozess
Prozess-
dokumentation
Gestaltungsprozess
Prozess-
optimierung
Bewertungs- und Prozess-
Kontrollprozess controlling
Prozess- Umsetzungsprozess
umsetzung
Prozess-
Ausführungsprozess
durchführung
Abb. 2.5 Der PMLC und seine Einbettung in das BPMS-Rahmenwerk (aufbauend auf Karagiannis
1995; Karagiannis et al. 1996)
Ähnliche Vorgehensmodelle im Vergleich zum vorgestellten PMLC finden sich bei-

spielsweise in (European Association of Business Process Management EABPM 2009),
(Freund et al. 2010) und (Wagner und Patzak 2007) sowie in etwas detaillierterer Form
in (Harmon 2007a) oder (Smith und Fingar 2003) und in leicht reduzierter Form in
(Bucher und Winter 2009).
In Ergänzung zu diesen Vorgehensmodellen existieren zahlreiche Ansätze, die in ihrem
Vorgehen bereits bestimmte Schwerpunkte setzen. So betonen Becker et al. (2008) über
den gesamten Prozessmanagement-Zyklus hinweg das Thema der Prozessmodellierung.
Zusätzlich wird bei ihnen der Entwicklung einer prozessorientierten Aufbauorganisation
eine separate Phase im Vorgehen gewidmet (Becker et al. 2008). Im Gegensatz dazu
kommt bei Schmelzer und Sesselmann (2008) die Prozessmodellierung bzw. -dokumen-
tation nur punktuell zum Einsatz. Slama und Nelius (2011) konzentrieren sich bei ihrem
Ansatz auf ein Vorgehen zur Verknüpfung von Prozessmanagement und serviceorien-
tierten Architekturen (SOA). Währenddessen legt zur Mühlen (2004) im Rahmen des
Prozessmanagements den Fokus auf das Prozesscontrolling sowie die Prozessunterstützung
mittels Workflow-Management-Systemen.
Der PMLC ist ein häufig in der Praxis eingesetzter Prozessmanagement-Ansatz,

der im Folgenden detailliert wird. Zu den einzelnen Phasen werden Vorgehensweisen,
Techniken, Werkzeuge und Erfolgsfaktoren beschrieben sowie illustrierende Beispiele
präsentiert. Beim PMLC steht nicht nur das „Was muss getan werden?“, sondern insbe-
sondere auch das „Wie muss etwas getan werden?“ im Vordergrund. Der PMLC fokus-
siert auf ein kontinuierliches Prozessmanagement, bietet aber gleichzeitig genügend
Flexibilität, einzelne Phasen zu überspringen und ist somit in verschiedenen Situationen
des Prozessmanagements anwendbar.
2.4 Die Phasen des Process Management Life Cycle
2.4.1 Prozessstrategie
Die Situation vieler Unternehmen ist dadurch gekennzeichnet, dass die Umwelt- und Rah
menbedingungen immer vielschichtiger werden. Hinzukommend erfolgt oftmals eine
Fokussierung auf die Ergebniszahlen, um den gestiegenen Erwartungen der Investoren
gerecht zu werden. Neben diesen externen Gegebenheiten stehen Unternehmen intern
immer häufiger vor der Herausforderung, bei einer eher heterogenen Anwendungs- und
Informationslandschaft entscheidungsrelevante Informationen zum richtigen Zeitpunkt zur
Verfügung stellen zu können.
Als ein Lösungsansatz bietet das Prozessmanagement die Möglichkeit, die Unterneh
mensstrategie „auf die Straße“ zu bekommen, indem es die Unternehmensziele auf
Prozesse herunterbricht (vgl. ebenso Kap. 4). Hierdurch wird nicht nur das strategi-
sche Denken gefördert, sondern es werden damit auch quantitative und qualitative
Steuerungsgrößen vorgegeben. Diese wiederum sorgen für eine höhere Transparenz und
bessere Kommunizierbarkeit des Steuerungssystems.
Um dies zu realisieren, muss der Chief Process Officer, ggf. mit Unterstützung aus
dem Bereich Unternehmensentwicklung, zunächst die Unternehmensstrategie und
deren Ziele analysieren. Auf dieser Grundlage kann er Gestaltungsprinzipien für die
Prozessarchitektur ableiten. Diese Gestaltungsprinzipien können sehr vielfältig sein –
von der Festlegung einer Prozessoptimierungs-Strategie (Re-Engineering der Prozesse
vs. kontinuierliche Prozessverbesserung) über Festlegungen zur Prozessstandardisierung
bis hin zu Prinzipien bzgl. Prozess-Outsourcing. Parallel dazu können der Prozessberater
und die Prozessexperten sowie die Prozessverantwortlichen eine Prozesslandkarte für
das Unternehmen aufstellen (vgl. ebenso Abschn. 3.4). Darauf aufbauend erfolgt die
Identifikation der Prozesse, die im Rahmen der aktuellen Prozessmanagement-Initiative
berücksichtigt werden sollen. Die Unternehmensziele werden dann gemeinsam durch
den Zielverantwortlichen und den Prozessverantwortlichen sowie falls notwendig
mit Unterstützung aus dem Bereich Unternehmensentwicklung auf die ausgewählten
Prozesse heruntergebrochen und in Form von strategischen/operativen Prozesszielen
dokumentiert.
Tab. 2.1 Vorgehen in der Phase der Prozessstrategie sowie durchführende Rollen
Nr. Vorgehensschritte Durchführende Rollen
1. Unternehmensstrategie und -ziele Chief Process Officer, ggf. mit Unterstützung
analysieren und Gestaltungsprinzipien aus dem Bereich Unternehmensentwicklung
für die Prozessarchitektur ableiten
2. Prozesslandkarte aufstellen Prozessberater, Prozessexperte,
Prozessverantwortlicher
3. Wichtige Prozesse identifizieren Chief Process Officer, Zielverantwortlicher,
Prozessverantwortlicher, ggf. Prozessexperte
4. Ziele auf einzelne Prozesse herunterbrechen: Zielverantwortlicher,
Prozessziele (strategisch/operativ) sowie Prozessverantwortlicher, ggf. mit
ggf. Kennzahlen festlegen Unterstützung aus dem Bereich
Unternehmensentwicklung
Zusätzlich zu den Prozesszielen sollten auch Kennzahlen sowie Zielwerte für diese
Kennzahlen definiert werden, mit deren Hilfe die Erreichung der Prozessziele gemessen
werden kann.
Je nachdem, ob man das erste Mal die Phase der Prozessstrategie durchläuft und
somit erst beginnt, ein Prozessmanagement im Unternehmen aufzusetzen, oder ob der
PMLC bereits mehrfach durchlaufen wurde, besitzt die Ableitung von Kennzahlen unter-
schiedliche Bedeutung. Zu Beginn sollte die Ableitung von Gestaltungsprinzipien und
Prozesszielen im Vordergrund stehen. Die Festlegung von Prozesskennzahlen ist oftmals –
auch mangels einer vorhandenen Prozessdokumentation – gar nicht möglich. Mit zuneh-
mender Reife des Prozessmanagements kann dann ein Kennzahlensystem entwickelt
werden, welches schrittweise aus den Gestaltungsprinzipien/Zielvorgaben abgeleitet wird.
Tabelle 2.1 fasst das beschriebene Vorgehen im Rahmen der Phase der Prozess
strategie noch einmal zusammen.
Im Zuge des mehrmaligen Durchlaufens des PMLC müssen die definierten
Prozessziele regelmäßig auf ihre Wirksamkeit geprüft und an Strategieveränderungen
angepasst werden.
2.4.2 Prozessdokumentation
Prozesse werden häufig in Form von Modellen dokumentiert, um ein Abbild der
Unternehmensabläufe zu ermöglichen. Die Gründe für die Prozessdokumentation sind
vielfältig: Zum einen bilden dokumentierte Prozesse einen Teil des Wissensmanagements,
da die Unternehmensabläufe selbst als Wissen des Unternehmens betrachtet werden
können (vgl. Kap. 18). Dokumentierte Prozesse stellen in diesem Zusammenhang zum
Beispiel die Grundlage für die Schulung (neuer) Mitarbeiter dar. Zum anderen können auf
der Basis existierender Prozessmodelle Prozessanalysen und -optimierungen durchgeführt
Tab. 2.2 Typische Detaillierungsebenen der Prozessmodellierung

Ebene Beschreibung Anwendungsgebiete
(Beispiele)
Ebene 1: Es wird ein grober Überblick über den Qualitätsmanagement,
Verantwortlichkeiten Sachverhalt gegeben, indem die organisatorische
(DEMI/RACI) und/oder wesentlichen Aktivitäten, die zum Reorganisation (z. B.
Inputs/Outputs (SIPOC) Prozessziel führen, dokumentiert werden. Aufgabenzuordnung)
Aktivitäten beschreiben meist die Erstellung
einzelner fachlicher Ergebnisse. Die
Dokumentation kann mit Fokus auf die
Verantwortlichkeiten (DEMI/RACI)
und/oder mit Fokus auf die Inputs und
Outputs eines Prozesses (SIPOC) erfolgen.
Ebene 2: Die Aktivitäten werden i. d. R. von einem Prozessorientierte
Bearbeiter- und Akteur durchgeführt, d. h. es wird eine neue Reorganisation,
Medienwechsel Aktivität modelliert, wenn der Bearbeiter Prozesskostenrechnung,
wechselt. Ein zusätzliches Kriterium sind Personalbedarfsplanung,
Medienwechsel. Einzelne Aktivitäten prozessorientierter
erstellen oft kein allein verwertbares Aufbau eines Internen
Ergebnis. Kontrollsystems (IKS)
Ebene 3: Analog zu Ebene 2 werden Aktivitäten Arbeitsanweisungen,
Ununterbrechbarkeit i. d. R. von einem Akteur durchgeführt, IT-Spezifikation
wobei eine Aktivität als ununterbrechbare
Tätigkeit beschrieben wird. Sie produziert
ein fachliches Zwischenergebnis.
werden. Darüber hinaus werden dokumentierte Prozesse im Rahmen der prozessba-

sierten Anforderungsdefinition und der sich anschließenden Softwareentwicklung ver-
wendet. Prozessmodelle können ebenso für die Kapazitätsplanung (Ressourcen) und die
Einsatzvorbereitung (Aufgabenverteilung) verwendet werden. Schließlich stellen die doku-
mentierten Prozesse die Grundlage für das Monitoring der Prozess-Performance dar.
In der Phase der Prozessdokumentation ist es zuerst notwendig, den Detaillierungs
grad der Prozessmodelle festzulegen. Dieser ist insbesondere von der Prozessstrategie
bzw. den Gestaltungsprinzipien abhängig und sollte daher vom Chief Process Officer
und dem Prozessberater bestimmt werden. In der Praxis kann häufig zwischen drei ver-
schiedenen Detaillierungsebenen unterschieden werden, die in Tab. 2.2 charakterisiert
werden (vgl. ebenso Abschn. 5.3.1). Für die bei den verschiedenen Detaillierungsebenen
angegebenen Anwendungsgebiete kann es je nach Fall ebenso erforderlich sein, auf eine
höhere oder tiefere Ebene zu wechseln.
Im Anschluss an die Festlegung des Detaillierungsgrads müssen der Prozessexperte und/
oder der Prozessberater – als diejenigen, die die Prozessdokumentation vornehmen – mit
den definierten Gestaltungs- und Modellierungsrichtlinien (vgl. ebenso Kap. 5) vertraut
gemacht werden. In den Modellierungsrichtlinien wird insbesondere festgelegt, mit welcher
Tab. 2.3 Vorgehen in der Phase der Prozessdokumentation sowie durchführende Rollen
1. Detaillierungsgrad für die Chief Process Officer,
Prozessdokumentation festlegen Prozessberater
2. Gestaltungs- und Modellierungsrichtlinien Prozessberater
erstellen und vermitteln
3. Prozesse modellieren/dokumentieren Prozessexperte, Input durch
und dabei Gestaltungs-/ Prozessmitarbeiter
Modellierungsrichtlinien anwenden
4. Qualitätssicherung auf die Prozessberater,
dokumentierten Prozesse durchführen Prozessverantwortlicher
(methodisch und inhaltlich) oder Prozessexperte
5. Prozessmodelle veröffentlichen Prozessberater
Modellierungssprache wie zu modellieren ist. Mit diesem Rüstzeug können die Prozesse
dokumentiert werden, wobei der Input von Prozessmitarbeitern herangezogen werden kann.
Zusätzlich zur reinen Dokumentation des Prozessablaufs kann die Dokumentation weitere
Aufgaben umfassen, wie z. B.:
• Zuordnen der organisatorischen Ressourcen,

• Modellieren der Schnittstellen,
• Aufzeigen der Integration von Informationstechnologie und Informationen,
• Schaffen von Transparenz über kritische/wichtige Aktivitäten und
• Zuordnen von Risiken und Kontrollen.
Die dokumentierten Prozesse sollten einer Qualitätssicherung unterzogen werden,

wobei zwischen einer formalen und einer inhaltlichen Qualitätssicherung unterschie-
den werden kann. Bei der formalen Qualitätssicherung wird durch den Prozessberater
insbesondere die Einhaltung der Gestaltungs- und Modellierungsrichtlinien geprüft. Im
Rahmen der inhaltlichen Qualitätssicherung wird durch den Prozessberater sowie den
Prozessverantwortlichen und/oder den Prozessexperten geprüft, inwieweit die model-
lierten Prozesse die tatsächlichen bzw. geplanten Unternehmensabläufe korrekt wie-
dergeben. Schließlich kann die Prozessdokumentation veröffentlicht werden, um die
Prozesse als Kommunikations- und Informationsplattform zu nutzen.
Zusammenfassend zeigt Tab. 2.3 das skizzierte Vorgehen in der Phase der Prozess
dokumentation auf.
2.4.3 Prozessoptimierung
In der Phase der Prozessoptimierung sollen die Prozesse im Sinne der definierten
Prozessziele optimiert werden. Im Detail bedeutet dies, die Prozesse stärker auf die
Tab. 2.4 Identifikation potenzieller Schwachstellen auf Basis der Prozessdokumentation

viele Rückfragen Warteschleifen viele Schnittstellen
fehlende Verantwortlichkeiten viele Berichts-/ lange Rüst-/Vorbereitungszeiten
Genehmigungsstufen
ungeplante Aufgaben lange Suchzeiten Mehrfacheingabe von Daten
nicht-kompatible IT-Systeme unklare Aufgaben Verfehlen der Prozessziele
komplizierte Organisationen fehlende Qualitätsmessung hoher Grad an Arbeitsteilung
Unternehmensstrategie auszurichten (Optimierung der Effektivität) und dafür zu sorgen,

dass die Prozesse möglichst fehlerfrei, rasch und kostengünstig ablaufen (Optimierung
der Effizienz). Unabhängig davon können auch andere Treiber Prozessoptimierungen
auslösen. Hierzu zählen zum Beispiel:
• die Einführung eines IT-Systems,

• ansteigende Kosten für Compliance-Anforderungen,
• die Durchführung einer internationalen Prozessstandardisierung oder
• Merger and Acquisitions.
Zunächst wird der Ist-Zustand der Prozesse analysiert. Die in der vorherigen Phase erstellte
Prozessdokumentation bildet hierfür die Grundlage. Die potenziellen Schwachstellen in
Prozessen können vielfältig sein. Tabelle 2.4 gibt einen Überblick über mögliche Schwach
stellen, die sich aus einer Prozessdokumentation „ablesen“ lassen.
Die Analyse der Ist-Prozesse schließt neben dem Erkennen potenzieller
Schwachstellen in den Prozessen auch das Ableiten von möglichen Sofortmaßnahmen
(engl. Quick Wins) ein. Weiterhin sollte die Grundlage für weiterführende Kosten-
Nutzen-Analysen geschaffen werden.
In einem zweiten Schritt erfolgt die Zusammenstellung und Priorisierung möglicher
Prozessoptimierungs-Projekte. Für die Bewertung bzw. Priorisierung dieser Projekte
können herangezogen werden:
• die strategische Relevanz,

• das Ergebnis der Kosten-Nutzen-Analysen,
• die Anzahl der Prozessdurchläufe bzw. Transaktionen,
• die jeweilige Risikoeinschätzung der Prozesse,
• die Größe des jeweiligen Handlungsbedarfs sowie
• involvierte Interessensgruppen.
Um die Prozessoptimierungs-Projekte zusammenstellen und/oder priorisieren zu können,

kann auf eine sogenannte Heat Map zurückgegriffen werden. Diese kann sowohl auf die
Unternehmensprozesse als auch auf bereits zusammengestellte Prozessoptimierungs-Projekte
angewendet werden. Gemäß dem Ampel-Prinzip „Rot-Gelb-Grün“ werden in einer Heat Map
Abb. 2.6 Ausschnitt einer Heat Map zur Beurteilung des Optimierungspotenzials
die kritischen/relevanten von den unkritischen/nicht relevanten Unternehmensprozessen

bzw. Prozessoptimierungs-Projekten unterschieden. Abbildung 2.6 veranschaulicht eine Heat
Map, in der die Kernprozesse eines Unternehmens hinsichtlich ihres Verbesserungspotenzials
eingeschätzt werden.
Nach erfolgreicher Priorisierung und Festlegung der anzugehenden Prozessoptimie
rungen ist es ebenfalls Bestandteil des zweiten Vorgehensschritts, das Projektmanagement
für die zu realisierenden Projekte zu initialisieren. Pro Prozessoptimierungs-Projekt müssen
neben dem Projektumfang, d. h. dem zu optimierenden Prozess, auch die Projektorganisation
sowie die Projektziele festgelegt werden. Bezüglich der Projektorganisation ist es insbeson-
dere die Aufgabe des Chief Process Officer, dafür zu sorgen, dass die benötigten Ressourcen
für die Durchführung der einzelnen Prozessoptimierungs-Projekte zur Verfügung gestellt
werden. Unter dem Projektziel wird das Verbesserungsziel verstanden, welches durch die
Optimierung des Prozesses erreicht werden soll. Die so definierten Projektaufträge werden an
(verschiedene) Projektteams übergeben.
Die Projektteams führen schließlich die Prozessoptimierungs-Projekte durch, welche
im Allgemeinen durch die betroffenen Prozessverantwortlichen verantwortet werden. Für
die Durchführung der Prozessoptimierungs-Projekte können wiederum eigene Vorgehens-
oder Phasenmodelle zur Strukturierung angewendet werden (vgl. ebenso Abschn. 2.1.3).
So ist es bspw. denkbar, im Rahmen eines Optimierungsprojekts das Phasenmodell des Six
Sigma-Ansatzes anzuwenden, während in einem zweiten Optimierungsprojekt die Phasen

des PMLC zur Anwendung kommen. Unabhängig vom Vorgehensmodell, das angewen-
det wird, müssen im Rahmen eines jeden Optimierungsprojekts zunächst die Probleme
des Prozesses noch einmal im Detail untersucht werden, so dass die Problemursachen
identifiziert werden können. Mit diesem Wissen werden dann Soll-Prozessvarianten erar-
beitet, wobei der Prozessmitarbeiter und/oder der Prozessexperte wertvollen Input lie-
fern können. Bei der Optimierung des Prozesses kann unterschieden werden, ob allein
die Aktivitäten inkl. deren Ablauf optimiert werden (Prozessoptimierung im engeren
Sinne) oder ob sich die Optimierung ebenso auf die dem Prozess zugeordneten Elemente,
wie z. B. Informationen, Aufbauor ganisation, Informationstechnologie etc. konzent-
riert (Prozessoptimierung im weiteren Sinne). Die verschiedenen Soll-Prozessvarianten
sollten danach Gap- und Risiko-Analysen bzw. Machbarkeitsstudien unterzogen wer-
den, um zu prüfen, wie realistisch die Realisierung der einzelnen Prozessvarianten ist.
Auf dieser Grundlage können die Soll-Prozessvarianten bewertet und priorisiert wer-
den. Es liegt nun in der Verantwortung des Prozessverantwortlichen bzw. bei gro-
ßen, strategischen Projekten auch in der Verantwortung des Chief Process Officer, die
Verbesserungsmaßnahmen zu überprüfen und die beste Variante für die Umsetzung
freizugeben.
Während des gesamten Prozessoptimierungs-Projekts steht der Prozessberater dem
Projektteam unterstützend zur Seite, indem er beispielsweise Workshops moderiert oder
bei der Auswahl und Anwendung von Prozessoptimierungs-Techniken sein methodi-
sches Wissen zum Einsatz bringt.
Bei allen Phasen eines Prozessoptimierungs-Projekts können diverse Techniken
aus den verschiedensten Disziplinen (wie z. B. Qualitätsmanagement, Innovations
management, Organisationsentwicklung) zum Einsatz kommen. Zu diesen Techniken
zählen z. B. Kundeninterviews, Ursache-Wirkungs-Diagramme, Prozesssimulationen,
Wertschöpfungsanalysen, Prozesskosten-Analysen, Personal bedarfsplanungen, Brain
storming, Gap-Analysen, Kosten-Nutzen-Analysen oder statistische Analysen (vgl.
hierzu ebenso Kap. 8, 9, 10 und 11). Tabelle 2.5 fasst das beschriebene Vorgehen noch
einmal zusammen.
Tab. 2.5 Vorgehen in der Phase der Prozessoptimierung sowie durchführende Rollen
1. Ist-Zustand der Prozesse analysieren Prozessberater,
2. Mögliche Prozessoptimierungs-Projekte Prozessberater, Chief
priorisieren Process Officer
3. Prozessoptimierungs-Projekte durchführen Prozessverantwortlicher,
Prozessberater, Prozessexperte,
Prozessmitarbeiter, ggf. weitere
Rollen im Projekt
2.4.4 Prozessumsetzung
Nachdem der Prozessverantwortliche den Soll-Prozess freigegeben hat, erfolgt die

Umsetzung des Prozesses im Unternehmen. Wie bereits in Abschn. 2.1.2 erwähnt,
erfolgt die Umsetzung der veränderten Prozesse häufig noch im Rahmen der in der
vorherigen Phase aufgesetzten, jeweiligen Prozessoptimierungs-Projekte. Folglich fin-
den bei der Umsetzung auch die Vorgehensschritte und Techniken des im jeweiligen
Prozessoptimierungs-Projekt gewählten Phasenmodells/Vorgehensmodells Anwendung.
Unabhängig davon sollten bei allen Prozessveränderungen die Prozessmitarbeiter,
die unmittelbar am betroffenen Prozess beteiligt sind, involviert und ebenso bzgl. des
Soll-Prozesses geschult werden. Die Einbeziehung von Veränderungsmanagement-
Ansätzen ist hierbei ebenso von Vorteil. Die Umsetzung der Soll-Prozesse selbst kann
sowohl organisatorische (vgl. ebenso Kap. 12) als auch technische Veränderungen (vgl.
ebenso Kap. 13) nach sich ziehen. Organisatorische Veränderungen können Änderungen
am Prozess, d. h. an den Aktivitäten bzw. deren Ablauf, oder Anpassungen an der
Aufbauorganisation nach sich ziehen. Bezüglich der Veränderung der IT wird häufig
zwischen drei Szenarien unterschieden:
1. Einführung von Standardsoftware/ERP-Systemen

2. Technische Umsetzung von Prozessen mittels Workflow-Systemen oder Prozess-Engines
3. Technische Umsetzung von Prozessen mit Individualsoftware
Im Zuge der Prozessumsetzung sollte sichergestellt werden, dass die Prozess

dokumentation aktualisiert wurde und die Soll-Prozessdokumentation der aktuellen
Ist-Dokumentation entspricht. Die Prozessdokumentation ist nicht nur die Grundlage
für zukünftige Analysen, sondern sie kann ebenso im Rahmen von technischen
Veränderungen als Bestandteil der Anforderungsspezifikation und/oder zur Generierung
von Workflow-Graphen verwendet werden.
Im Anschluss an die Umsetzung der Veränderungen wird der neue Prozess „zum
Leben erweckt“ und die Prozessmitarbeiter führen den Prozess durch. Für einen
bestimmten Zeitraum (Pilot-Phase) sollte der implementierte Soll-Prozess überwacht
und ggf. steuernd eingegriffen werden. Je nach Situation kann es sinnvoll sein, ein
Reporting zur Performance des neuen Prozesses zu erstellen.
Nach Beendigung der Pilot-Phase kann der implementierte Soll-Prozess durch den
Projektleiter in die Linienorganisation übergeben werden. Somit ist auch das jeweilige
Prozessoptimierungs-Projekt beendet.
2.4.5 Prozessdurchführung
In der Phase der Prozessdurchführung steht die tägliche Durchführung der Geschäfts
prozesse durch die Prozessmitarbeiter im Vordergrund. Als Unterstützung der Prozess
durchführung hat es sich in der Praxis bewährt, sogenannte Arbeitsanweisungen (engl.
Tab. 2.6 Vorgehen in der Phase der Prozessdurchführung sowie durchführende Rollen
1. Prozesse im Tagesgeschäft durchführen Prozessmitarbeiter
2a. Messdaten zu Prozesskennzahlen Prozesscontroller, Prozessmitarbeiter,
erheben Prozessverantwortlicher
2b. Prozess-Assessments durchführen Prozesscontroller, ggf. Mitarbeiter aus
der Revision
3. Kurzfristige Problemlösung im Prozessverantwortlicher
Tagesgeschäft umsetzen
Standard Operating Procedures – SOP) auf Basis der Prozessdokumentation zu erstel-

len. Diese Anweisungen präzisieren zum Teil den Prozessablauf, klären Fragen zu
Ausnahmesituationen (Eskalationsprozesse) und beschreiben bei wichtigen Freigabe-/
Genehmigungsverfahren, wie deren genaue Regeln aussehen.
Parallel zur Durchführung der Prozesse sollten Messdaten zu den Prozesskennzahlen
erhoben werden. Mit diesen lässt sich die Performance der Prozesse in der sich anschlie-
ßenden Phase des Prozesscontrollings ermitteln. Zusätzlich oder als Alternative zu die-
sem eher datenzentrierten Prozesscontrolling-Ansatz können „manuelle“ Prozessaudits
durchgeführt werden. Hierbei wird anhand von Assessments überprüft, inwieweit
bestimmte Vorgaben durch die Prozesse eingehalten werden.
Der dritte Vorgehensschritt betrifft die kurzfristige Problemlösung im Tagesgeschäft.
Der Prozessverantwortliche sollte dafür Sorge tragen, dass kleine Probleme im
Tagesgeschäft schnell gelöst und auch direkt im Prozess umgesetzt werden.
Tabelle 2.6 fasst die Vorgehensschritte sowie die daran beteiligten Rollen noch einmal
zusammen.
Während des gesamten Durchlaufens des PMLC, aber insbesondere im Rahmen der
Prozessdurchführung, sollte der Prozessberater die Verankerung des Prozessmanagement-
Gedankens im Unternehmen fördern. Dies kann er beispielsweise durch kontinuierliche
Weiterbildungsmaßnahmen zum Thema Prozessmanagement realisieren.
2.4.6 Prozesscontrolling
Innerhalb der Phase des Prozesscontrollings erfolgt die Bewertung und Kontrolle der
Performance der Geschäftsprozesse des Unternehmens. Dies geschieht unabhängig von
den darunter liegenden Organisationsstrukturen. Mithilfe des Prozesscontrollings kön-
nen die Prozesse in die „richtige Richtung“, d. h. strategiekonform, gesteuert werden.
Im Sinne eines integrierten Ansatzes sollte das Prozesscontrolling deshalb auch mit dem
Unternehmenscontrolling abgestimmt werden.
Zunächst müssen die während der Prozessdurchführung gesammelten Mess
daten bzw. die Daten aus den Prozess-Assessments aufbereitet und aggregiert werden.
Tab. 2.7 Vorgehen in der Phase des Prozesscontrollings sowie durchführende Rollen
1. Daten aufbereiten und aggregieren Prozesscontroller/Prozessberater,
2. Analysen durchführen und Ergebnisse Prozesscontroller/Prozessberater,
aufbereiten Prozessverantwortlicher
3. Konsequenzen diskutieren und Chief Process Officer,
veranlassen (Maßnahmen definieren) Prozessverantwortlicher
4. Ergebnisse der Analyse kommunizieren Chief Process Officer,
Möglicherweise müssen sogar zusätzliche Daten erhoben werden, so dass die Performance
und/oder Compliance der Prozesse bewertet werden kann. Ergänzende Instrumente zur
Datenerhebung können beispielsweise Interviews mit Prozessmitarbeitern und/oder
Prozessverantwortlichen oder aber die Analyse bzw. Begutachtung von Prozessergebnissen
sein. Wichtig ist, dass die Datenerhebungen bzw. Messungen regelmäßig durchgeführt
werden.
Im folgenden Schritt werden die aufbereiteten Daten analysiert und ihre Ergebnisse
entsprechend aufbereitet. Die Ergebnisse sollten darüber Aufschluss geben, inwieweit
die in den Prozesskennzahlen definierten Zielwerte durch die Prozesse erreicht bzw.
inwieweit die für die Prozesse definierten Vorgaben eingehalten werden. Sowohl bei der
Aufbereitung als auch bei der Analyse der Daten erhält der Prozessverantwortliche metho-
dische Unterstützung durch den Prozesscontroller und/oder den Prozessberater. Sie stel-
len ebenso entsprechende Instrumente für die Performance-Analyse bereit. Darüber
hinaus verwendet der Prozesscontroller/Prozessberater Erkenntnisse aus der Prozess-
Performance-Analyse bzw. dem Prozess-Assessment, um diese in Form von Lessons
Learned aufzubereiten und den Wissenstransfer im Prozessmanagement im Unternehmen
sicherzustellen.
Anschließend diskutiert der Prozessverantwortliche mit dem Chief Process Officer die
Ergebnisse und es wird festgelegt, welche Konsequenzen aus den Zielerreichungsgraden
der einzelnen Prozesskennzahlen bzw. den Ergebnissen der Prozess-Assessments gezo-
gen werden und in welcher Form diese umzusetzen sind.
Schließlich sollten die Ergebnisse auch veröffentlicht und kommuniziert werden.
Je nach Positionierung des Prozessmanagements geschieht dies zum Teil bis hin zur
Geschäftsleitung des Unternehmens. Das beschriebene Vorgehen wird in Tab. 2.7 noch-
mals dargestellt.
Der Bewertungs- und Kontrollprozess schließt den Process Management Life Cycle.
Im Sinne des Zyklus des PMLC fließen die gewonnenen Prozesscontrolling-Ergebnisse
jedoch in einen neuen Kreislauf und werden insbesondere in der Prozessstrategie, der
Prozessoptimierung sowie ggf. der Prozessdokumentation – sofern Prozesskennzahlen
dokumentiert werden – weiter verwendet.
2.5 Zusammenfassung
Dieses Kapitel stellt den Process Management Life Cycle als ein zyklisches Vorgehensmodell
vor, mit dessen Hilfe Unternehmen ihre Geschäftsprozesse managen, d. h. kontinuierlich
überprüfen und anpassen, können. Der PMLC umfasst die sechs Phasen Prozessstrategie,
Prozessdokumentation, Prozessoptimierung, Prozessumsetzung, Prozessdurchführung und
Prozesscontrolling. Die einzelnen Phasen werden erläutert und dabei die unterschiedli-
chen Aufgaben der involvierten Rollen aufgeführt. Innerhalb des Prozessmanagements
werden primär die Rollen Chief Process Officer, Prozessverantwortlicher, Prozessexperte,
Prozessmitarbeiter, Prozessberater und Prozesscontroller unterschieden. Weitere Rollen,
wie z. B. Risikobewerter oder Unternehmensarchitekt, können ebenso involviert sein.
Wie bereits in Abschn. 1.3 beschrieben, bildet dieses Kapitel die Grundlage für die
weitere Strukturierung des vorliegenden Buchs. Einzelne Themen, die in den vorgestell-
ten Phasen des PMLC lediglich angerissen werden konnten, werden in den folgenden
Kapiteln des Buchs vertieft. Der Bezug der einzelnen Themen untereinander kann über
den PMLC und die involvierten Rollen stets hergestellt werden.
Literatur
Becker J, Kugeler M, Rosemann M (2008) Prozessmanagement: Ein Leitfaden zur prozessorientier-

ten Organisationsgestaltung, 6. Aufl. Springer, Berlin
Bucher T, Winter R (2009) Geschäftsprozessmanagement – Einsatz, Weiterentwicklung und
Anpassungsmöglichkeiten aus Methodiksicht. In: Reinheimer S (Hrsg) Prozessmanagement,
HMD – Praxis der Wirtschaftsinformatik, Bd 266. dpunkt, Heidelberg, S 5–16
Davenport T-H (1993) Process Innovation: Reengineering Work through Information Technology.
Harvard Business School Press, Boston
Deming W-E (2000) Out of the Crisis. MIT Press, Cambridge
European Association of Business Process Management EABPM (Hrsg) (2009) Business
Process Management: Common Body of Knowledge – BPM CBOK®: Leitfaden für das
Prozessmanagement Version 2.0, Dr. Götz Schmidt, Gießen
Freund J, Rücker B, Henninger T (2010) Praxishandbuch BPMN. Carl Hanser, München
Gygi C, DeClaro N, Williams B (2010) Six Sigma für Dummies, 2. Aufl. Wiley, Hoboken
Hammer M, Champy J (1993) Reengineering the Corporation: A Manifesto for Business Revolution,
3. Aufl. HarperBusiness Essentials, New York
Harmon P (2007a) An Overview on Some Business Process Methodologies. Bus Process Trends 5(13)
Harmon P (2007b) Business Process Methodologies. Bus Process Trends 5(20)
Imai M (1986) Kaizen: The Key to Japan’s Competitive Success. McGraw-Hill, New York
Kamiske G-F, Brauer J-P (2008) Qualitätsmanagement von A bis Z: Erläuterungen moderner
Begriffe des Qualitätsmanagements, 6. Aufl. Carl Hanser, München
Karagiannis D (1995) BPMS: Business Process Management Systems. ACM SIGOIS Bull
16(1):10–13

Berlin, S 81–106
30(8–9/01):1161–1170
Petzmann A, Puncochar M, Kuplich C, Orensanz D (2007) Applying MDA Concepts to Business
Process Management. In: Fischer L (Hrsg) 2007 BPM and Workflow Handbook. Future
Strategies, Lighthouse Point, S 103–116
Pyzdek T, Keller P (2009) The Six Sigma Handbook, 3. Aufl. McGraw-Hill, New York
Scheer A-W (1992) Architektur integrierter Informationssysteme, 2. Aufl. Springer, Berlin
Scheer A-W (1999) ARIS: Business Process Frameworks, 3. Aufl. Springer, Berlin
Scheer A-W, Jost W, Wagner K (Hrsg) (2005) Von Prozessmodellen zu lauffähigen Anwendungen:
ARIS in der Praxis. Springer, Berlin
Schmelzer H-J, Sesselmann W (2008) Geschäftsprozessmanagement in der Praxis: Kunden zufrie-
den stellen, Produktivität steigern, Wert erhöhen, 6. Aufl. Carl Hanser, München
Schmitt R, Pfeifer T (2010) Qualitätsmanagement. Strategien, Methoden, Techniken, 4. Aufl. Carl
Hanser, München
Slama D, Nelius R (2011) Enterprise BPM: Erfolgsrezepte für unternehmensweites Prozess
management. dpunkt, Heidelberg
Smith H, Fingar P (2003) Business Process Management: the third wave. Meghan-Kiffer, Tampa
Toutenburg H, Knöfel P (2009) Six Sigma: Methoden und Statistik für die Praxis, 2. Aufl. Springer,
Berlin
Wagner K-W, Patzak G (2007) Performance Excellence: Der Praxisleitfaden zum effektiven Prozess
management. Carl Hanser, München
Witt J, Witt T (2007) Werkzeuge des Qualitätsmanagements in der KVP-Praxis. Symposion
Publishing, Düsseldorf
zur Mühlen M (2004) Workflow-based Process Controlling: Foundation, Design, and Application
of Workflow-driven Process Information Systems. Logos, Berlin
Teil II
Prozessstrategie
Prinzipien für die Gestaltung der
Prozessarchitektur 3
Franz Bayer, Lea Appelhans und Eva Wolf
Zusammenfassung
Die Prozessarchitektur ermöglicht eine strukturierte Sicht auf die Prozesse einer
Organisation. Bei ihrer Gestaltung kommen sowohl fachliche als auch methodische
Prinzipien zum Einsatz. Die Prozessarchitektur muss in ihrer Struktur und in ihrem
Umfang die Unternehmensstrategie widerspiegeln. Nur so wird sie auch zu einem per-
manent genutzten Instrument des Managements, mit dem Prozessverantwortliche
festgelegt und die Prozesse geplant und gesteuert werden können. Neben der
Steuerung bietet die Prozessarchitektur darüber hinaus noch weitere Nutzenaspekte
wie Information, Transparenz sowie prozessübergreifende Optimierung. Das folgende
Kapitel beleuchtet diese Aspekte und zeigt eine Vorgehensweise sowie Techniken zur
Strukturierung der Prozessarchitektur bzw. der obersten Ebene der Prozesslandkarten
auf. Anhand verschiedener Verwendungsbeispiele wird erläutert, was eine „gute“
Prozessarchitektur ausmacht, wie Prozessverantwortung umgesetzt werden kann und in
welchen Praxisszenarien die Prozessarchitektur von besonderer Bedeutung ist.
3.1 Einleitung
Die Sicht auf ein Unternehmen bzw. eine Organisation auf Basis von Prozessen wird über
eine gut strukturierte Prozessarchitektur erreicht. Die Ordnung dieser Prozessarchitektur
kann auf Basis von unterschiedlichen Gestaltungsprinzipien erfolgen. Es können Prinzipien
angewendet werden, die aus bekannten Methoden des Prozessmanagements resultieren, aber
auch Prinzipien, die sich in einer Branche für das Management der Prozesse bewährt haben.
F. Bayer (*)
e-mail: franz.bayer@boc-eu.com
L. Appelhans · E. Wolf
BOC Information Technologies Consulting GmbH, Voßstraße 22, 10117 Berlin, Deutschland

38 F. Bayer et al.
Das Ergebnis dieser Ordnung der Prozesse auf Basis von geeigneten Gestaltungsprinzipien
wird als Prozessarchitektur bezeichnet. Auf den obersten Ebenen dieser Architektur findet
man die Prozesslandkarte, in die alle weiteren Prozesse einsortiert werden.
Die Gestaltungsprinzipien können grob in zwei Kategorien unterteilt werden:
Einerseits sprechen wir von methodischen Gestaltungsprinzipien, die bspw. eine
Gestaltung entlang der Managementprozesse, Kernprozesse und Unterstützungsprozesse
Abb. 3.1 Eine Prozesslandkarte der Versicherungsbranche

3 Prinzipien für die Gestaltung der Prozessarchitektur 39
vorgibt. Andererseits ist eine rein methodische Gestaltung nicht zielführend, da die
wesentlichen Nutzenaspekte der Architektur nur teilweise berücksichtigt werden.
Aus diesem Grund sind auch fachliche Gestaltungsprinzipien zu überlegen, die sich
aus der Unternehmensstrategie ableiten. Ein einfaches Prinzip wäre die Umsetzung
eines Branchenstandards, der eine klare Struktur der Ordnung für die Gestaltung der
Prozessarchitektur des Unternehmens auf Basis des Branchenwissens vorgibt. Für eine
Vielzahl von Branchen finden sich meist auf den obersten Ebenen der Prozessarchitektur
Best Practice-Prozesslandkarten in den Angeboten von Beratungsunternehmen (vgl.
Abb. 3.1), Interessensvertretungen und Verbänden.
Die Prozessarchitektur ist ein wesentlicher Bestandteil der gesamten Geschäfts
architektur des Unternehmens. Da es in der Regel sehr unterschiedliche Auffassungen
in den Organisationen über die Gestaltung der gesamten Geschäftsarchitektur gibt, ist die
Prozessarchitektur sehr häufig der gemeinsame Nenner, auf dem sich Ziele, Strategien,
Schwerpunkte der geschäftlichen Entwicklung, Benchmarks etc. auf ihren unterschiedli-
chen Ebenen abbilden lassen. Aus diesem Grund ist die Gestaltung der Prozessarchitektur
sehr eng mit der Umsetzung der Unternehmensstrategie verbunden (vgl. ebenso
Kap. 4). Eine „gute“ Prozessarchitektur ist das Spiegelbild der Unternehmensstrategie
und lässt Schwerpunkte der Strategie deutlich erkennen. Eine Postmerger-Integration,
Sourcing-Modelle oder vergleichbare Strukturen in den Kernprozessen für Branchen-
Benchmarks sind Beispiele für diese Strategien, die bereits auf den obersten Ebenen der
Prozessarchitektur, der Prozesslandkarte, entnommen werden können. Die Prozessarchi
tektur zeigt in diesen Fällen einen klar strukturierten Bereich der Kernprozesse und
deren Wertschöpfung auch auf den obersten Ebenen der Prozessarchitektur. Prozessver
antwortung und Schnittstellenübersichten geben eine transparente Übersicht über das
Zusammenwirken der Prozesse in der Architektur in der eigenen Organisation und teil-
weise auch über die Organisationsgrenzen hinweg. Damit wird die Prozesslandkarte
als Repräsentant der Prozessarchitektur auf den obersten Ebenen zu einem wertvollen
Instrument für viele Aufgaben der Unternehmensführung und Kommunikation.
3.2 Zusammenspiel Unternehmensstrategie

und Prozessstrategie
Die Unternehmensstrategie gibt Wege zur Zielerreichung für alle Geschäftsbereiche vor.
Funktionsorientierte und geschäftsbereichsspezifische Vorgaben müssen mit ihren Ursache-
Wirkungs-Beziehungen für alle Teile des Geschäftsmodells überprüft werden. Dies schließt auch
deren Wirkungszusammenhänge auf allen Wertschöpfungsebenen des Unternehmens ein.
Die Architektur der Wertschöpfung wird bereits auf sehr hoher Abstraktionsebene
dadurch festgelegt, dass Geschäftsprozesse als Kernprozesse des Unternehmens gesehen
werden oder lediglich unterstützenden Charakter haben, dass Wertschöpfungsprozesse
vertikal oder horizontal integriert werden müssen oder dass sie ggf. im Umkehrschluss
Kandidaten für ein Outsourcing sind.
40 F. Bayer et al.
Beispiel
Auch wenn eine Online-Bank über ihre zentralen Funktionen mit klassischen Retail-
Banken vergleichbar ist, so weichen nicht nur die Produktportfolios, sondern insbe-
sondere auch die Architektur der Wertschöpfung und damit die Prozessarchitektur
voneinander ab. So werden im Online-Banking vor allem administrative Prozesse in die
Kundenverantwortung ausgelagert. Das Zusammenspiel mit den Backoffice-Prozessen
muss bei einer 24/7-Verfügbarkeit diesen besonderen Anforderungen genügen.
Die Gestaltung der Prozessarchitektur und auf oberster Ebene der Prozesslandkarten ist
daher nicht nur ein Dokumentationsinstrument zur Gestaltung und Navigation durch
die Prozesse des Unternehmens, sie ist ein Managementinstrument mit ganz besonderer
Bedeutung für die Erklärung, Gestaltung und Führung der Wertschöpfungszusammenhänge.
Dabei darf die Prozesslandkarte nicht nur in flachen Tabellenstrukturen abgebildet wer-
den und lediglich als Inventarisierungssystem für Prozesskataloge dienen! Prozesse müssen
bereits auf dieser abstrakten Wertschöpfungsebene strukturiert und gestaltet werden. Die
Prozesslandkarte muss einige allgemeine Nutzenaspekte erfüllen, damit man von einem
erfolgreichen Einsatz dieses Instruments im Geschäftsprozessmanagement sprechen kann.
Diese Nutzenaspekte werden in Abschn. 3.3 erläutert. Sobald die relevanten Nutzenaspekte
für das Unternehmen klar definiert sind, kann mit den Überlegungen zur Gestaltung und
Strukturierung der Prozesslandkarte begonnen werden. Dabei liefert die Dekomposition
des Geschäftsmodells in seine einzelnen Kernelemente die grundlegenden Merkmale für die
Strukturierung. Welche Merkmale aus dem Marktangebot, den Organisationsstrukturen,
dem Ressourcenmodell, dem Finanzierungsmodell, dem Erlösmodell etc. letztlich für
die Gestaltung in Frage kommen und welche eine sinnvolle Auswahl darstellen, wird in
Abschn. 3.4 behandelt. Damit die Prozesslandkarte erfolgreich als Steuerungsinstrument für
das Geschäftsprozessmanagement und als Kommunikationsinstrument für die Überwachung
der Unternehmensstrategie genutzt werden kann, müssen Verantwortlichkeiten auf allen
Ebenen der Prozessarchitektur definiert werden. Abschnitt 3.5 gibt einen ersten Einblick
in die Regelung von Verantwortlichkeiten auf der Ebene der Prozesslandkarten. Mit der
Zuordnung der Verantwortlichen wird das Instrument Prozesslandkarte letztlich operationa-
lisierbar. Eine Auswahl von Anwendungsbeispielen für den Einsatz der Prozesslandkarte als
Gestaltungs- und Steuerungsinstrument wird in Abschn. 3.6 vorgestellt.
3.3 Nutzenaspekte der Prozesslandkarte
Die Nutzenaspekte einer Prozesslandkarte umfassen generell drei Ebenen, welche nach-
folgend erläutert werden. Sie erstrecken sich von der eher operativ ausgerichteten Ebene
(Transparenz und Information), hin zu einer taktischen (Optimierung) und strategi-
schen Ebene (Steuerung).
Als anschaulich erweist sich in diesem Kontext ein pyramidaler Aufbau der
Nutzenaspekte (vgl. Abb. 3.2), denn die Basis stellt in erster Linie die Information und
Abb. 3.2 Nutzenaspekte der

Prozesslandkarte
Steuerung
Optimierung
Information & Transparenz
die Schaffung von Transparenz dar. Darauf aufbauend dient die Prozesslandkarte eben-
falls als Optimierungs- und auf oberster (Management-)Ebene als Steuerungsinstrument.
Nachfolgend werden diese Nutzenaspekte im Detail erläutert.
Information und Transparenz

Die Prozesslandkarte als Informationsinstrument bildet den ersten Nutzenaspekt, denn
eine strukturiert abgebildete Prozessübersicht schafft einen schnellen Überblick über
die Geschäftsprozesse eines Unternehmens. Daneben dient sie insbesondere auch als
Navigationsinstrument im Rahmen der Prozesspublikation, um einen schnellen Einstieg
in die Prozessarchitektur zu ermöglichen.
Neben der Möglichkeit, gezielt nach Prozessen zu suchen, stellt die Prozesslandkarte
eine Grundlage für die Einarbeitung neuer Mitarbeiter eines Unternehmens dar, indem
sie alle Geschäftsprozesse in konsolidierter Form bereitstellt.
Zusätzlich schaffen Prozesslandkarten durch Möglichkeiten der Gruppierung und
eines hierarchischen Aufbaus Transparenz über die gesamte Prozessorganisation eines
Unternehmens.
Unterschiedliche Gestaltungsansätze ermöglichen es, die Prozessstrategie eines
Unternehmens anhand der Landkarte abzubilden. So können entweder End-to-End-
Beziehungen, Wertschöpfungsketten oder auch nur Teile von Prozesslandkarten-
Standards, wie z. B. eTOM® (TeleManagement Forum 2013a), SCOR® (Supply Chain
Council 2012) oder ITIL® (IT Service Management Forum (itSMF) 2007), abgebildet
werden. Der Scope der Prozessmodellierung und -optimierung spiegelt sich also auch in
der Struktur der Landkarte wider.
Darüber hinaus ist die Ableitung von Prinzipien aus der Unternehmensstrategie
notwendig, welche für die Gestaltung bzw. das Design einzelner Prozesse aus der Pro
zesslandkarte herangezogen werden können. Für die Umsetzung dieser Gestaltungs
prinzipien können in Folge Gestaltungs- und Modellierungsrichtlinien herangezogen
werden (vgl. Kap. 5).
42 F. Bayer et al.
Optimierung
Die Mitte der Pyramide bildet der Nutzenaspekt „Optimierung“. Aufbauend auf dem
Informations- und Transparenz-Aspekt bietet eine Prozesslandkarte die Möglichkeit,
prozessübergreifende Optimierungspotenziale zu identifizieren. Insbesondere eine
Vereinheitlichung und Harmonisierung der bestehenden Prozesse ist mit Hilfe dieser
Sicht „aus der Vogelperspektive“ möglich. Im Rahmen einer tiefergehenden Analyse
können beispielsweise Prozesse identifiziert werden, die aufgrund ihrer Ähnlichkeit
zusammengefasst werden können, oder aber solche, die wegen stärkerer Differenzen in
mehrere Prozesse aufgeteilt werden müssen.
Steuerung
Der dritte Nutzenaspekt betrifft die Möglichkeit der Nutzung der Prozesslandkarte als
Steuerungsinstrument. Dieser beinhaltet folgende Einsatzmöglichkeiten:
• Über die Verbindung zu den Organigrammen kann eine eindeutige Zuordnung

der Prozessverantwortlichkeiten durchgeführt werden. Auf diese Weise dient die
Prozesslandkarte der entsprechenden Leitung (den Prozessverantwortlichen) als
Instrument zur operativen Beurteilung und Bewertung „ihrer“ Geschäftsprozesse.
• Die Integrationsplattform Prozesslandkarte kann als Prozesssteuerungs- und
Führungssystem dienen. Die Prozesslandkarte kann hierbei z. B. für die Aggregation
von Kennzahlen aus der Ablaufebene und Bildung von Management-Dashboards ver-
wendet werden.
Insgesamt beeinflusst der Aufbau der Prozessstruktur wesentlich, wie eine Organisation
über Prozesse strukturiert und geführt wird und wie das Management der Geschäftsprozesse
betrieben wird. Aus diesem Grund ist eine strukturierte Darstellung der Prozessarchitektur
ein wichtiger Meilenstein auf dem Weg zur Sichtbarkeit und Akzeptanz des Prozess
managements in der Organisation.
3.4 Vorgehen zur Gestaltung der Prozesslandkarte
Unterschiedliche Merkmale beeinflussen die Gestaltung einer Prozesslandkarte. Diese

Merkmale werden auch Determinanten genannt und lassen sich aus den Organisations
strukturen oder dem Marktangebot einer Organisation ableiten.
Um zu definieren, welche Merkmale für die Gestaltung der Prozesslandkarte herange-
zogen werden sollen, ist eine konzeptionelle Vorgehensweise empfehlenswert, welche in
den folgenden Abschnitten erläutert wird.
3.4.1 Das Konzept
Prozessmerkmale (Determinanten) stellen Einflussgrößen dar, die über einen Prozessablauf

entscheiden. Das Konzept beinhaltet die folgenden Schritte:
1. Identifizierung der (branchenabhängigen) Prozessmerkmale

2. Reihung der Prozessmerkmale nach ihrer Wichtigkeit
3. Entscheidung darüber, welche Prozessmerkmale zu separaten Prozessen und welche
lediglich zu separaten Pfaden im Prozessablauf führen
Die Prozessmerkmale sind häufig abhängig von der Branche, in der ein Unternehmen
tätig ist. So sind die Prozesse eines Unternehmens im Finanzdienstleistungssektor meist
nach anderen Kriterien geschnitten als jene eines produzierenden Unternehmens.
Nachfolgend sollen mögliche Merkmale zur Strukturierung einer Prozesslandkarte in
aller Kürze vorgestellt werden:
• Strukturierung nach Vertriebskanälen
findet häufig im Dienstleistungssektor Anwendung, z. B. Filiale/Shop, Callcenter, Internet.
• Strukturierung nach Organisationseinheiten/Verantwortlichkeiten
z. B. in der öffentlichen Verwaltung nach Ämtern oder Ministerien oder auch nach
Frontoffice/Backoffice.
• Strukturierung nach Produkten
in der öffentlichen Verwaltung nach den Dienstleistungen für den Bürger, wie
z. B. Namens-, Personenstands- und Staatsangehörigkeitsangelegenheiten oder
Fahrerlaubnisangelegenheiten.
• Strukturierung nach Produktlebenszyklus
z. B. Eröffnung, Änderung, Auflösung eines Vertrags.
• Strukturierung nach Kundengruppen
z. B. nach Privat- und Firmenkunden.
• Strukturierung nach IT-Systemen
liegt der Schwerpunkt z. B. auf dem Anwendungsportfolio-Management, so können
Prozesslandkarten auch nach IT-Systemen strukturiert werden.
• Strukturierung nach Wertschöpfungsketten
häufig in der Produktion, z. B. Beschaffung, Montage, Qualitätsprüfung, Verkauf.
Beispiel
Eine Versicherung hat ihre Prozesslandkarte nach dem Produktlebenszyklus struktu-
riert. Folgende Logik wurde zugrunde gelegt:
• Vertrieb: umfasst alle Arten der Anbahnung des Produktverkaufs.
•
Vertragsabschluss: umfasst alle Vertragseröffnungs-Prozesse, z. B. Vertragsab
schluss einer privaten Rentenversicherung.
• Vertragsänderung: umfasst alle Änderungsprozesse, z. B. Adressänderungen.
•
Leistung: umfasst alle Leistungsprozesse, z. B. die Auszahlung einer Lebens-
versicherung.
•
Information: umfasst alle Kundeninformations-Prozesse, z. B. Erstellung der jähr-
lichen Wertaufstellung.
•
Vertragsauflösung: umfasst alle Vertragsschließungs-Prozesse, z. B. Kündigung
einer Haftpflichtversicherung.
44 F. Bayer et al.
Vertrieb Vertrags- Vertrags- Leistung Information Vertrags-

abschluss änderung auflösung
Vertragsabschluss-Prozesse
Spezifischer Vertragsabschluss-Prozess
Abb. 3.3 Beispiel für die Strukturierung einer Prozesslandkarte
Die daraus resultierende Logik spiegelt sich ebenfalls in der Prozesslandkarte wider (vgl.
Abb. 3.3).
Beispiel
Ein Unternehmen hat seine Prozesse nach mehreren Prozessmerkmalen struk-
turiert (Vertriebskanal, Produktgruppe, Lebenszyklus, Organisationseinheiten/
Verantwortlichkeiten). Als schwierig erwies sich in diesem Kontext die Darstellung
aller Merkmale auf Ebene der Prozesslandkarte. Daher entschied man sich für die
Lösung einer multidimensionalen Prozesslandkarte: Über eine Filterung nach unter-
schiedlichen Merkmalsausprägungen konnte nun gewählt werden, welche Merkmale
die Landkarte zeigen soll.
3.4.2 Techniken zur Strukturierung
In einem ersten Schritt ist es notwendig, zentrale Merkmale (vgl. Abschn. 3.4.1), die auf
der Prozesslandkarte abgebildet werden sollen, festzulegen. Merkmale, wie Produkte
oder Vertriebskanäle, sind in jeder Organisation zu finden und sind prädestiniert für die
Strukturierung einer Prozesslandkarte auf oberster Ebene. Für die weitere Detaillierung
muss eine Entscheidung darüber getroffen werden, welche Prozessvarianten gebil-
det werden sollen („Schneidung“ von Prozessen). Dabei können Merkmale wie
Produktlebenszyklus, Kundentypen oder Produktparameter eine Rolle spielen.
Als Hilfestellung zur Identifikation der Prozessvarianten eignet sich eine Matrix-
Technik, welche beispielsweise das Merkmal Produkt den Prozessen gegenüberstellt.
Eine Produkt-Prozess-Matrix hilft dabei, produktübergreifende Geschäftsprozesse

und die Bildung von Prozessvarianten zu identifizieren. Zusätzlich unterstützt sie die
Prüfung auf Vollständigkeit der Geschäftsprozesse.
Zur Bildung der Matrix werden die Produkte (oder Produktgruppen) als Spalten
und die vorläufig identifizierten Prozesse in den Zeilen abgebildet. Durch Ankreuzen
der Kombinationen „Welche Prozesse werden für das jeweilige Produkt benötigt?“
erhält man Prozesse, die für ein spezifisches Produkt erforderlich sind. Da nicht alle
Kombinationen als eigenständige Geschäftsprozesse modelliert werden sollen, werden
Gruppierungen herausgearbeitet, für die der Prozessablauf standardisiert werden soll
bzw. kann.
Im Beispiel in Abb. 3.4 wird Prozess 1 nur für Produkt 1 benötigt. Prozess 2 hinge-
gen ist für alle drei Produkte relevant. Nach dieser Feststellung erfolgt die Überlegung,
ob der Prozess für alle drei Produkte den gleichen Ablauf hat (der Idealfall der
Harmonisierung) oder ob es eventuell sogar drei unterschiedliche Prozesse aufgrund der
Variantenbildung geben muss. In diesem Beispiel wurde festgestellt, dass der Prozess 2
für die weitere Prozessmodellierung in eine Variante A und eine Variante B aufgeteilt
werden soll.
Die Produkt-Prozess-Matrix stellt in diesem Kontext nur ein Beispiel dar. Bei Bedarf
kann zusätzlich für andere Prozess-Determinanten, wie z. B. Vertriebskanäle (Kanal-
Prozess-Matrix) oder Standorte (Organisation-Prozess-Matrix), ein Vollständigkeitscheck
anhand einer Matrix durchgeführt werden. Die Vorgehensweise ist analog zur Produkt-
Prozess-Matrix (vgl. Abb. 3.4).
Nach der Identifikation der Prozessmerkmale erfolgt hier im zweiten Schritt die Reihung
dieser nach ihrer Wichtigkeit (vgl. Abschn. 3.4.1). In diesem Kontext ist zu unterstreichen,
dass die Kriterien zur Priorisierung von Prozessmerkmalen stark von der Betrachtungsweise
bzw. von der Zielsetzung der Prozessmodellierung abhängen. So sind z. B. aus Vertriebs-
und Kundensicht eher Merkmale wie Kundengruppe oder Produkte interessant.
Abb. 3.4 Produkt-Prozess-

Produkt 1
Produkt 2
Produkt 3
Matrix
Produkte
Prozesse
Prozess 1 x
Prozess 2 x x x Prozess B
Prozess 3 x x
Prozess A
46 F. Bayer et al.
Abb. 3.5 Strukturierung in Prozess „Konto Privatkunde eröffnen“

separate Geschäftsprozesse
Prozess „Konto Firmenkunde eröffnen“
Abb. 3.6 Strukturierung mit Prozess „Konto eröffnen Privat -/Firmenkunde“

Hilfe von alternativen Pfaden
Privat - oder Firmenkunde?
Bei der Entwicklung einer integrativen Prozesslandkarte sollte dennoch die End-
to-End-Betrachtung im Auge behalten werden, um eine übergreifende Sicht auf die
Unternehmensprozesse zu ermöglichen. Ist das Ziel erreicht worden, einen durchgehen-
den Prozessfluss „vom Kunden zum Kunden“ darzustellen, sollten sich zumindest auf
Ebene der Kernprozesse ausschließlich End-to-End-Prozesse wiederfinden. Auf Ebene
der Unterstützungsprozesse kann es durchaus möglich sein, dass einzelne Teilprozesse
„isoliert“ sind.
Zuletzt erfolgt im dritten Schritt die Entscheidung darüber, welche Prozessmerkmale
zu separaten Prozessen und welche lediglich zu separaten Pfaden im Prozessablauf
führen. Bei der Prozesserhebung und -dokumentation führen unterschiedliche
Merkmalsausprägungen, beispielsweise das Merkmal Kundengruppe (Privatkunden,
Firmenkunden), entweder zu separaten Prozessen (vgl. Abb. 3.5) oder zu Entscheidungen
innerhalb von Prozessen (vgl. Abb. 3.6).
Im Sinne einer möglichst weitgehenden Prozessharmonisierung sollen die Prozesse
merkmalübergreifend ausgestaltet werden, d. h. Merkmale werden möglichst als Pfade
innerhalb eines übergreifenden Prozesses dargestellt. Prozessvarianten für einzelne
Merkmalsausprägungen sollten nur dann in einem separaten Modell abgebildet werden,
wenn die Komplexität des Hauptprozesses sonst zu groß und dieser damit unleserlich wird.
Nach der Analyse der Prozessvarianten müssen die Merkmale final festgelegt wer-
den. Dabei gilt es zu entscheiden, ob die Merkmale auf der Prozesslandkarte selbst
vorkommen oder ob sie als Varianten anhand von Entscheidungen innerhalb eines
Prozesses dargestellt werden. In einem letzten Schritt muss die Reihenfolge der
Merkmale auf der Prozesslandkarte festgelegt werden.
3.4.3 Umsetzung der Struktur mit der Prozesslandkarte
Eine Prozesslandkarte betrachtet die Geschäftsprozesse „aus der Vogelperspektive“, d. h.

sie abstrahiert über den Ablauf einzelner Prozesse. Dabei werden Prozesse oder Gruppen
von Prozessen durch grafische Elemente repräsentiert. Die Prozesslandkarte kann meh-
rere Ebenen umfassen. In einem nicht zu großen Untersuchungsbereich kann es ausrei-
chen, die Prozesslandkarte auf einer Ebene darzustellen. Bei höherer Komplexität sind in
der Regel bis zu drei oder vier Ebenen erforderlich.
3.4.4 Techniken zur Bewertung von Prozesslandkarten
Wurden die Prozesse mit Hilfe der Merkmale grob strukturiert, müssen in einem nächs-
ten Schritt die weiteren Merkmale überprüft werden. Zur Prüfung auf Vollständigkeit
eignet sich sowohl eine methodische als auch eine fachliche Vorgehensweise, um eventu-
ell noch fehlende Prozesse zu identifizieren.
Methodische Assessments
Eine Kategorisierung soll eine Vollständigkeitskontrolle ermöglichen, aus der ersichtlich
wird, wo „Lücken“ in der Prozessabdeckung bestehen. Entschließt sich beispielsweise ein
Unternehmen, seine Prozesse nach Vertriebskanälen und Produkten zu strukturieren, so
könnte ein Vollständigkeitscheck folgendermaßen durchgeführt werden.
Abbildung 3.7 zeigt, dass bestimmte Produkte nicht in allen Vertriebskanälen zur
Verfügung stehen. Diese Lücken müssen entsprechend interpretiert werden. Dabei kom-
men grundsätzlich zwei Möglichkeiten in Betracht:
1. Die Kombination wurde „vergessen“.

Folge: Für diese Kombination muss ein weiterer Prozess modelliert werden oder sie
muss in einen bestehenden Prozess über Entscheidungen/alternative Pfade mit aufge-
nommen werden.
2. Die Kombination existiert fachlich nicht (Beispiel aus dem Bankensektor: Eine
Baufinanzierung kann nicht über das Callcenter abgeschlossen werden).
Folge: Die Lücke kann bestehen bleiben. Es ist keine weitere Modellierung erforderlich.
Fachliche Assessments
Wie bereits in der Einleitung dieses Kapitels erwähnt, spiegelt eine gute Prozessarchitektur
die Unternehmensstrategie eines Unternehmens sowie deren Schwerpunkte wider.
Eine einfache Übernahme eines bereits existierenden Architektur-Standards ohne
48 F. Bayer et al.
Produkte
Vertriebskanäle
Abb. 3.7 Vollständigkeitsprüfung anhand einer Merkmals-Matrix
Ständige Verbesserung des Qualitätsmanagement-Systems
Kunde Kunde
Verantwortung der
Leitung
Management von Messung, Analyse

Anforderungen
Ressourcen und Verbesserung
Anforderungen Produktrealisierung
Abb. 3.8 Fachlich unzureichend strukturierte Prozesslandkarte
Berücksichtigung unternehmensspezifischer Besonderheiten ist nicht zielführend und

lässt wichtige Aspekte der Unternehmensstrategie außer Acht.
Ein Beispiel für eine fachlich unzureichend strukturierte Prozessarchitektur, die
inhaltlich nicht weit über einen typischen Management-Zyklus hinausgeht, ist in
Abb. 3.8 dargestellt. Diese Form der Landkarte ist allgemeiner Art und lässt keine
Rückschlüsse auf die Unternehmensstrategie, Branche oder etwaige Kernprozesse des
Unternehmens zu.
Als fachliche Hilfestellung für die Gestaltung einer guten Prozessarchitektur kann bei-
spielsweise eine Checkliste herangezogen werden, welche die Kernelemente einer gelun-
genen Prozesslandkarte abfragt. Fragestellungen könnten sein:
Abb. 3.9 Fachlich gut strukturierte Prozesslandkarte
• Lässt sich die spezifische Unternehmensbranche (z. B. Produktionsunternehmen,

Bank, Versicherung, IT-Service-Provider) erkennen?
• Lassen sich Schwerpunkte der geschäftlichen Entwicklung erkennen?
• Sind die Kernprozesse des Unternehmens identifizierbar?
• Können in den Kernprozessen die End-to-End-Prozesse identifiziert werden?
• Sind die von den Kernprozessen gemeinsam genutzten Teilprozesse ersichtlich?
• Sind die Prozessverantwortlichen auf der Landkarte erkennbar?
• Erlaubt die Prozesslandkarte Rückschlüsse auf die fachlichen Gestaltungsprinzipien,
wie z. B. Produktstrategien, Vertriebsstrategien oder Sourcing-Überlegungen?
Unter Berücksichtigung dieser Fragestellungen kann eine fachlich gut strukturierte

Prozessarchitektur entwickelt werden.
Abbildung 3.9 zeigt eine gelungene Prozesslandkarte. Darin können z. B. sowohl die
Branche als auch die Kernprozesse des Unternehmens identifiziert werden. Ebenfalls ist
eine End-to-End-Sicht der Kernleistungen des Unternehmens in der Landkarte enthalten.
50 F. Bayer et al.
Idealerweise spiegelt eine Landkarte ebenfalls die Prozessverantwortung wider. Die

verschiedenen Aspekte zur Regelung von Verantwortung in der Prozessarchitektur wer-
den im nachfolgenden Abschnitt beschrieben.
3.5 Regelung von Verantwortung in der Prozessarchitektur
Prozessmanagement als Managementansatz kann nur dann erfolgreich umgesetzt wer-

den, wenn die damit einhergehenden Verantwortlichkeiten innerhalb der Organisation
klar geregelt sind. Die Aufteilung der Aufgaben des Geschäftsprozessmanagements auf
einzelne Verantwortliche erfolgt auf Basis eines Rollenkonzepts, welches in Abschn. 2.2
näher beschrieben ist.
Für die Gestaltung der Prozessarchitektur ist die permanente, strategische Rolle Chief
Process Officer (CPO) verantwortlich (vgl. Abschn. 2.2.1).
Die operative Pflege und Weiterentwicklung der Prozesslandkarte wird in größeren
Unternehmen häufig an eine Stabstelle des CPO übertragen. Dieser sog. Prozessland
karten-Koordinator untersteht dem Chief Process Officer direkt und trägt die
Verantwortung für die Struktur, Vollständigkeit und Aktualität der Prozesslandkarte des
Unternehmens. Kenntnisse über die Zielsetzungen des Geschäftsprozessmanagements
im Unternehmen, aber auch über die spezifische Geschäftsprozessmanagement-Methode
sind für diese Rolle unabdingbar. Eine weitere wichtige Aufgabe des CPO besteht darin,
den Anstoß für die Benennung eines Prozessverantwortlichen für jeden Geschäftsprozess
zu geben. Hierzu wird in Abschn. 4.4 eine Technik vorgestellt, um die Auswahl eines
Prozessverantwortlichen anhand konstruktiver Regeln zu unterstützen.
Ohne die Etablierung von Prozessverantwortlichen (engl. Process Owner) bleibt das
Prozessmanagement meist ein Konzept ohne Konsequenz und ohne wirklichen operati-
ven Nutzen. Der Prozessverantwortliche ist für die ganzheitliche Planung, Gestaltung und
Steuerung „seines“ Geschäftsprozesses verantwortlich. Er trägt dabei für diesen ebenfalls
die Ergebnisverantwortung und berichtet direkt an den Chief Process Officer. Idealerweise
vereinbart der CPO mit dem Prozessverantwortlichen Prozess- und Ergebnis- bzw.
Kostenziele, die in die Zielvereinbarung des Prozessverantwortlichen integriert werden
(vgl. ebenso Abschn. 2.4.1).
Die Herausforderung dieser stringenten Prozessorganisation ist die funktions- und
abteilungsübergreifende Abwicklung der Prozesse. Überträgt man die Prozessverant
wortung dem Inhaber einer Funktion oder dem Leiter einer Abteilung, hat dieser häu-
fig nicht alle erforderlichen Kompetenzen, um das gesamte Management des Prozesses
zu übernehmen. Daher müssen auf Basis der Prozessarchitektur Kompetenzen klar
kommuniziert und ggf. organisatorisch sichergestellt werden, dass die übergreifenden
Prozessthemen regelmäßig besprochen und entschieden werden.
Die ganzheitliche Verantwortung des Prozessverantwortlichen beinhaltet neben der
fachlichen und qualitativen Verantwortung auch die Verantwortung dafür, dass
• der Geschäftsprozess die rechtlichen Grundlagen und Rahmenbedingungen erfüllt,

• interne Dienstanweisungen und Vorschriften eingehalten werden,
• die prozessausführenden Organisationseinheiten personell angemessen ausgestattet sind,
• der Geschäftsprozess angemessen durch technische Ressourcen, Dokumente und IT-
Anwendungen/IT-Systeme unterstützt wird und
• die Schnittstellen zu anderen Geschäftsprozessen identifiziert, detailliert beschrieben
und gegebenenfalls über die Definition von Prozess-SLAs (Service Level Agreements)
sichergestellt sind.
Dem letzten Punkt kommt im Kontext der Prozessarchitektur besondere Bedeutung zu

(vgl. ebenso Abschn. 3.6.2 zum Sourcing). Gerade die Gestaltung von Schnittstellen zu
anderen internen oder externen Prozessen birgt häufig enormes Optimierungspotenzial.
Der Prozessverantwortliche benötigt daher nicht nur detaillierte Kenntnisse über den von
ihm zu verantwortenden Geschäftsprozess bezüglich dessen fachlichen Ablaufs, rechtlicher
Anforderungen und Rahmenbedingungen, verwendeter Dokumente und IT-Anwendungen,
sondern auch einen Überblick über die gesamte Prozessarchitektur des Unternehmens. Bei
Konflikten zwischen verschiedenen Prozessverantwortlichen, insbesondere im Kontext von
Schnittstellen, aber auch in Bezug auf übergreifende oder wiederverwendbare Prozesse, ist
der Prozesslandkarten-Koordinator der zentrale Ansprechpartner (vgl. ebenso Abschn. 4.4).
Die Informationen über die Prozessarchitektur sind ebenfalls für die Rolle des
Unternehmensarchitekten relevant. Die Interaktion zwischen Prozessarchitektur und
Unternehmensarchitektur ist in Kap. 16 beschrieben.
3.6 Ausgewählte Beispiele zur Verwendung der

Prozesslandkarte
Wie bereits in Abschn. 3.2 motiviert, ist die Prozesslandkarte ein Instrument für
das Management. Bereits auf abstrakter Ebene der Wertschöpfungsarchitektur des
Unternehmens werden Strategien für die Gestaltung der Geschäftsprozesse und für
deren Zusammenspiel definiert. In den folgenden Abschnitten sind vier ausgewählte
Anwendungsszenarien zu finden, für die eine gute Prozesslandkarte das Fundament für
alle Entscheidungen über die Ausrichtung der Geschäftsprozesse darstellt.
3.6.1 Standardisierung und Harmonisierung
Auf den unteren Ebenen der Prozesslandkarte werden sich immer wieder Prozesse fin-
den, die gleich oder ähnlich in verschiedenen Unternehmensbereichen ablaufen. Die
Prozesslandkarte als Informationsmedium hilft dabei zu erkennen, welche Prozesse
Standardisierungspotenzial aufweisen. Häufig kann jedoch nicht der gesamte Prozess,
sondern lediglich Teile davon standardisiert werden. In diesem Fall sprechen wir von
52 F. Bayer et al.
einer Harmonisierung oder Angleichung der Prozesse. Dies ermöglicht gleichermaßen

eine Verschlankung sowie Wiederverwendung der im Prozess genutzten Dokumente
und IT-Services (vgl. auch Gestaltungsrichtlinien in Kap. 5).
Wiederverwendbare (Sub-)Prozesse und Prozess-Patterns sollten in der Prozessarchitektur
in einer eigenen Landkarte kategorisiert werden. Nur so ist es möglich, bei einer Prozess-
Restrukturierung und bei der Definition von neuen Prozessen auf vorhandene, bereits in der
Organisation etablierte oder IT-technisch umgesetzte (Sub-)Prozesse und Musterlösungen
zurückzugreifen, anstatt diese erneut zu designen. Um zu gewährleisten, dass auch wiederver-
wendbare Prozessteile optimiert und weiterentwickelt werden, müssen auch hierfür Prozess-
bzw. Pattern-Verantwortliche festgelegt werden. Möchte ein Prozessverantwortlicher einen
wiederverwendbaren Subprozess nutzen, hat aber noch Anforderungen daran, muss er erken-
nen können, an wen diese Anforderungen zu richten sind.
3.6.2 Sourcing
Jede Neugestaltung der Wertschöpfung eines Unternehmens beginnt mit der Prozesslandkarte.
Insbesondere Sourcing-Maßnahmen sind ohne Kenntnis der Prozesslandkarte nicht plan- und
steuerbar. Dabei ist es unwesentlich, ob in- oder outgesourced werden soll. In beiden Fällen
ist der Scope nur auf einer in der Organisation anerkannten Prozesslandkarte mit ihren Kern-
und Unterstützungsprozessen festzustellen. Darüber hinaus müssen Schnittstellen identifiziert
und bewertet werden. Neben Integrationsstrategien müssen Service Level Agreements gezielt
an diesen Schnittstellen definiert und später überwacht werden können.
Eine Reihe von Unterstützungsprozessen sind gute Kandidaten für ein Sourcing,
da sie in Unternehmen mehrfach verwendet werden (Shared Services) und durch ihre
Ausgliederung aus den Kernprozessen bereits mit den relevanten Schnittstellen ver-
sehen wurden. Buchhaltung, Lohnverrechnung, Personalmanagement, Prozesse der
Informationstechnologie oder des Gebäudemanagements sind nur einige Beispiele, die
für viele Unternehmen nicht im Kern der Wertschöpfung stehen und damit Kandidaten
für Sourcing-Strategien sind.
Während wenig arbeitsteilige Prozesse, wie z. B. die Lohnverrechnung, klare Input-/
Output-Beziehungen aufweisen, müssen sehr arbeitsteilige Prozesse, wie z. B. die Service
management-Prozesse der IT (vgl. die COBIT-Prozessarchitektur (Information Systems Audit
and Control Association (ISACA) 2013) oder die ITIL® Best Practices (IT Service Management
Forum (itSMF) 2007)), auf der Prozesslandkarte gut vorstrukturiert werden, um die Input-/
Output-Beziehungen der zugrunde liegenden Prozesse klar spezifizieren zu können.
3.6.3 Benchmarking
Benchmarking im Kontext des Prozessmanagements kann definiert werden als ein sys-
tematischer und kontinuierlicher Prozess, bei dem Geschäftsprozesse über mehrere
Customer
Strategy, Infrastructure Operations

& Product
Strategy Operations
Supplier/Partner Relationship Management

Supply Chain Development & Management
& Commit Support &
Resource Development & Management
Resource Management & Operations

Service Development & Management
Customer Relationship Management

(Application , Computing & Network)
(Application , Computing & Network)

Service Management & Operations
Readiness
Marketing & Offer Management
Fulfillment
Infrastructure
Lifecycle
Management Assurance
Product Billing &

Lifecycle Revenue
Management Management
Enterprise Management
Strategic & Enterprise Knowledge &

Enterprise Risk
Enterprise Effectiveness Research
Management
Planning Management Management
Stakeholder & Human

Financial & Asset
External Relations Resources
Management
Management Management
Abb. 3.10 Prozesslandkarte nach dem eTOM® Business Process Framework (TeleManagement
Forum 2013b)
vergleichbare Organisationsbereiche oder organisationsübergreifend verglichen werden.

Dabei sollen die Unterschiede und die Möglichkeiten zur Verbesserung aufgezeigt sowie
wettbewerbsorientierte Zielvorgaben ermittelt werden.
In zahlreichen Branchen werden Vergleichsmodelle auf Basis von Prozesslandkarten
erstellt. Neben den COBIT- (Information Systems Audit and Control Association (ISACA)
2013) und ITIL® Best Practice-Modellen (IT Service Management Forum (itSMF) 2007)
der IT-Branche können weitere Initiativen, wie z. B. das SCOR®-Modell aus dem Supply
Chain Management (Supply Chain Council 2012) oder das eTOM®-Prozessmodell
(vgl. Abb. 3.10) aus der Telekommunikationsbranche (TeleManagement Forum 2013a)
erwähnt werden. Mit diesen Referenzstrukturen kann die Prozessarchitektur einzelner
Unternehmen der Branche strukturell bewertet werden und mit Hilfe von detaillierten
Prozessaudits bis auf Ablaufebene bewertet und auf ihre Vergleichbarkeit geprüft werden.
54 F. Bayer et al.
In der Praxis ist es allerdings sehr aufwändig, eine Vergleichbarkeit von Prozessen
auf Ablaufebene herzustellen. Beim organisationsübergreifenden Benchmarking wer-
den detaillierte Ablaufinformationen von den am Benchmarking-Projekt teilnehmenden
Unternehmen in der Regel auch gar nicht preisgegeben. Das organisationsübergreifende
Benchmarking beschränkt sich daher meist auf Prozesszeiten und Prozesskosten.
In der Initialisierungsphase eines Benchmarkings werden die zu vergleichenden
Prozesse bestimmt. Hierbei ist die Prozesslandkarte das wichtigste Instrument, um die-
jenigen Prozesse zu identifizieren, die den Prozessen der anderen Unternehmen entspre-
chen. Auf Landkartenebene lassen sich die zu vergleichenden Prozessfelder gut abgrenzen
und die entsprechenden Prozesse zusammenstellen. Dabei werden in einem sogenannten
Strukturvergleichs-Modell die Prozesslandkarten der Unternehmen gegenübergestellt.
Beispiel
Ein IT-Dienstleister im Bankenumfeld möchte seinen Kunden ein Prozess-Bench
marking ermöglichen. Dazu hat er eine bankübergreifende Prozesslandkarte erstellt.
Jeder seiner Kunden kann seine eigenen Prozesse dann einem der Prozesse aus der
übergreifenden Prozesslandkarte zuordnen. So entsteht eine Vergleichbarkeit, obwohl
jedes Bankinstitut seine Prozessstruktur anders schneidet und seine Prozesse indivi-
duell ausgestaltet.
Beispiel
Ein Versicherungsunternehmen möchte seine Prozesse mit jenen anderer
Versicherungsunternehmen vergleichen. Dazu möchte es den Benchmarking-Katalog
einer Unternehmensberatung nutzen, welcher in der Versicherungsbranche bereits
etabliert ist. Um eine genaue Vergleichbarkeit zu erreichen, müssen alle Prozesse so
geschnitten werden, dass sie sich genau einem Prozessfeld des Katalogs zuordnen
lassen. Die Prozessstruktur wurde daher von vorneherein so aufgebaut, dass sie dem
Benchmarking-Katalog entspricht.
Auch in der operativen Phase des Benchmarkings kann die Prozesslandkarte genutzt
werden. Sowohl Zeiten als auch Kosten können auf Prozesslandkarten-Ebene am jewei-
ligen Prozess hinterlegt werden. Die Daten können dabei aus den darunter liegenden
Prozessen hochaggregiert werden.
3.6.4 Postmerger-Integration
Mit der Fusion zweier Unternehmen geht immer das Ziel einher, durch die
Harmonisierung von Prozessen, aber auch von Produkten, Dokumenten und IT-
Anwendungen, Skaleneffekte zu erzielen und Kosten einzusparen. Hierbei sind die
Prozesslandkarten der fusionierten Unternehmen ein wichtiges Instrument, da auf dieser
abstrakten Ebene Gemeinsamkeiten leichter erkennbar sind und Unterschiede entspre-

chend der in Abschn. 3.4.1 und 3.4.2 vorgestellten Dimensionen kategorisiert und für die
Zusammenführung der Unternehmen positioniert werden können.
Zudem ist erkennbar, welches die Kernprozesse des jeweiligen Unternehmens sind
und welche Prozesse in den Unternehmen jeweils ausgelagert wurden. Idealerweise sind
auch die Prozessverantwortlichen auf der Prozesslandkarte erkennbar und können in
den Entscheidungsprozessen direkt adressiert werden.
Auf dieser Basis können grundlegende Prioritäten für Zusammenführungen bestimmt,
ihre Dringlichkeit und Nachhaltigkeit beurteilt und über kurzfristige Maßnahmen für
den Transformationsprozess und das erforderliche Veränderungsmanagement entschie-
den werden. Ohne Kenntnisse über die Prozessarchitekturen der Unternehmen und
die Ziel-Prozesslandkarte können Entscheidungen über den Transformationsprozess
nur auf funktionaler Ebene, d. h. auf Basis von Organisationszusammenführungen,
Anwendungskonsolidierungen oder Standortfestlegungen ohne deren Wertschöpfungs
beitrag für die Prozessarchitektur und letztlich das Geschäftsmodell getroffen werden.
Literatur
Information Systems Audit and Control Association (ISACA) (2013) COBIT 4.1: Framework for IT
Governance and Control. http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx.
Zugegriffen: 07. Jan 2013
IT Service Management Forum (itSMF) (2007) An Introductory Overview of ITIL® V3,
Dokumentation, Wokingham. http://www.best-management-practice.com/gempdf/itsmf_an_
introductory_overview_of_itil_v3.pdf. Zugegriffen: 07. Jan 2013
Supply Chain Council (2012) What is SCOR? http://supply-chain.org/scor. Zugegriffen: 06. Jan 2013
TeleManagement Forum (2013a) Business Process Framework (eTOM). http://www.tmforum.org/
BusinessProcessFramework/1647/home.html. Zugegriffen: 07. Jan 2013
TeleManagement Forum (2013b) Business Process Framework (eTOM) In Depth. http://www.tmf
orum.org/InDepth/6637/home.html. Zugegriffen: 13. Jan 2013
Umsetzung eines zielorientierten
Prozessmanagements 4
Robert Strobl und Angelika Widowitz
Zusammenfassung
Das Kapitel vertieft die relevanten Aspekte der Phase Prozessstrategie des Process
Management Life Cycle: In der Einleitung wird motiviert, warum nachhaltiges
Prozessmanagement in Unternehmen immer mit den strategischen Zielen verknüpft sein
muss. Im Folgenden wird ein Vorgehensmodell beschrieben, wie aus der Strategie eines
Unternehmens die Prozessziele abgeleitet werden können. Im ersten Schritt werden die
Unternehmensprozesse im Hinblick auf ihre Strategierelevanz priorisiert. Danach erfolgt
die Formulierung der strategischen und operativen Prozessziele. Die darauffolgende
Überleitung in die weiteren Phasen des PMLC wird kurz erläutert und entsprechende
Verweise zu den spezifischen Kapiteln gesetzt. Neben dem Vorgehensmodell wird ins-
besondere auch auf die relevanten Rollen und deren Aufgaben im zielorientierten
Prozessmanagement eingegangen. Als weitere praktische Handlungsanleitungen werden
Checklisten zur Beurteilung der Güte von Prozesszielen vorgestellt sowie eine Technik
zur Festlegung von Prozessverantwortlichkeiten und Schnittstellenabstimmung erläutert.
4.1 Motivation
Erfolgreiches und nachhaltiges Prozessmanagement zeichnet sich gerade dadurch aus,

dass es neben der ständigen Optimierung der operativen Abläufe auch die Prozesse
auf die Unternehmensstrategie ausrichtet und deren Umsetzung so konsistent bis in die
R. Strobl (*) · A. Widowitz

e-mail: robert.strobl@boc-at.com

58 R. Strobl und A. Widowitz
einzelnen konkreten Geschäftsabläufe unterstützt. Darüber hinaus soll es selbst wiede-

rum Input für strategische Weiterentwicklungen, wie z. B. Prozessinnovationen und neue
Geschäftsmodelle, leisten, die das Unternehmen in seiner strategischen Entwicklung weiter
bringen (Bergsmann 2012).
Im Rahmen der Umsetzung eines zielorientierten Prozessmanagements steht die
Definition im Vordergrund, welche Unternehmensstrategien und -ziele verfolgt wer-
den sollen, und wie die Prozesse diese Zielerreichung unterstützen können und sollen.
Der Fokus liegt auf der strategischen Priorisierung von Prozessen und der Ableitung von
Prozesszielen aus den strategischen Zielen des Unternehmens. Das Vorgehen stellt einen
wichtigen Schritt in der Operationalisierung der Strategie dar. Gerade hier zeigt sich in
Unternehmen oft eine wesentliche Schwachstelle.
Jedes Unternehmen benötigt eine formulierte Strategie, um sich in die richtige
Richtung entwickeln zu können. Im strategischen Entscheidungsprozess werden aus
der formulierten Unternehmensstrategie strategische Ziele entwickelt und strategische
Handlungsfelder und Initiativen festgelegt.
Im Folgenden muss untersucht werden, welche Unternehmensprozesse die Zielerreichung
und somit die Strategie unterstützen. Hierbei werden die Kernprozesse natürlich eine wesent-
liche Rolle spielen, aber auch Unterstützungs- und Managementprozesse müssen diesbezüg-
lich untersucht werden. Des Weiteren muss eine regelmäßige Überprüfung der Kernprozesse
bezüglich ihres Beitrags zur Strategieumsetzung durchgeführt werden. Wie auch bei allen
anderen Phasen des PMLC (vgl. Abschn. 2.4) liegt ein wesentlicher Erfolgsfaktor in der akti-
ven Mitgestaltung durch die Prozessverantwortlichen, Teilprozessverantwortlichen und
Prozessmitarbeiter zur Erreichung der Ziele in ihrer täglichen Prozessarbeit.
4.2 Vorgehen
4.2.1 Methodische Anleitung zur Umsetzung eines zielorientierten

Prozessmanagements
Eine Vorgehensweise, um der Herausforderung des zielorientierten Prozessmanage

ments zu begegnen, stellt Abb. 4.1 vor. Diese Vorgehensweise beschreibt die groben
Teilschritte, welche typischerweise im zielorientierten Prozessmanagement betrachtet
werden müssen.
Das Vorgehensmodell zur Entwicklung und Bewertung von Prozesszielen gliedert
sich in vier Teilschritte:
1. Strategische Ziele analysieren und Prozesse strategisch gewichten

In diesem Schritt werden in Zusammenarbeit der Zielverantwortlichen und der Prozess
verantwortlichen die relevanten Prozessgruppen/Prozesse bzgl. der Zielvorgaben
identifiziert und priorisiert. Da in den meisten Unternehmen die strategische
4 Umsetzung eines zielorientierten Prozessmanagements 59
Teilschritte des Vorgehensmodells

Prozess-
zur Umsetzung eines
strategie
zielorientierten Prozessmanagements
Strategische Ziele
analysieren Strategische Operative Controlling -
und Prozesse Prozessziele Prozessziele System
strategisch ableiten ableiten initialisieren
gewichten
Abb. 4.1 Vorgehensmodell für die Entwicklung von Prozesszielen
Zielverantwortung der funktionalen, hierarchischen Organisationstruktur folgt, sind

dies Bereichs- und Abteilungsleiter. Bei etwaigen Konflikten bzw. Abstimmungen unter-
stützt hier der Chief Process Officer.
2. Strategische Prozessziele ableiten
Auf Prozessgruppenebene oder Hauptprozessebene werden die strategischen Prozessziele
definiert und beschrieben. Diese Aufgabe liegt beim Prozessverantwortlichen, der seinen
Vorschlag mit Zielverantwortlichen abstimmen muss.
3. Operative Prozessziele ableiten
Hierbei geht es um das Herunterbrechen der strategischen Prozessziele auf opera-
tive Prozessziele. Diese Tätigkeit umfasst auch die Prozesszielvereinbarung mit den
Teilprozessverantwortlichen und Prozessmitarbeitern.
4. Controlling-System initialisieren
Auf Basis der festgelegten operativen Prozessziele werden hier Kandidaten für
Kennzahlen gesammelt und schließlich nach einer Kosten-Nutzen-Analyse festgelegt.
Die Fortsetzung des PMLC erfolgt daraufhin unter dem Gesichtspunkt der Festlegungen
in der Phase der Prozessstrategie (vgl. ebenso Kap. 2). Alle weiteren Schritte sollten in
Einklang mit der Zielfestlegung erfolgen.
4.2.2 Strategische Ziele analysieren und Prozesse strategisch

gewichten
Im ersten Schritt gilt es, die funktional orientierte Zielsicht auf die Unternehmensprozesse
abzustimmen. Eine strategische Zielvereinbarung findet heutzutage in den meisten
Unternehmen auf Basis der Aufbauorganisation statt: Die Bereichs- und Abteilungsleiter
stimmen die entsprechenden Ziele mit ihren Vorgesetzten ab. Diese aufbauorganisa-
torisch abgestimmte Zielhierarchie bildet die Vorgabe für den Einstieg in die Phase
Prozessstrategie.
Mithilfe der Unternehmensprozesslandkarte (vgl. ebenso Kap. 3) erfolgt nun die
Abstimmung der Zielverantwortlichen mit den Prozessverantwortlichen. Der Chief
Process Officer dient hier als Moderator bzw. Eskalationsinstanz und zur Abstimmung
der Schnittstellen zwischen verschiedenen Prozessverantwortlichen.
Der Zielverantwortliche identifiziert gemeinsam mit den Prozessverantwortlichen
die wichtigen Prozesse. Als Input hat er mehrere Informationen zur Verfügung: die
Prozesslandkarte, die Prozessabläufe, Auswertungen etc. Es werden z. B. gemeinsam mit
den Prozessverantwortlichen jene Prozesse identifiziert, welche vom entsprechenden stra-
tegischen Ziel betroffen sind und beeinflusst werden.
Die Prozessgruppen bzw. Hauptprozesse werden in einer Matrixdarstellung im
Hinblick auf die strategischen Ziele gewichtet. Auf der horizontalen Achse werden
die strategischen Ziele (z. B. nach den Perspektiven der Balanced Scorecard (Kaplan
und Norton 1992) (vgl. ebenso Kap. 15)) aufgelistet. Auf der vertikalen Achse wer-
den die Prozessgruppen bzw. Hauptprozesse dokumentiert. In dieser Matrix kann
dann eine erste Zuordnung als auch eine folgende strategische Gewichtung der
Prozesse (Scoping) erfolgen. Daraus ergeben sich drei wesentliche Erkenntnisse zur
Weiterarbeit:
• Die strategische Gewichtung von Prozessen spiegelt ihre strategische Bedeutung

wider, d. h. diese Prozesse stellen Kandidaten für eine Priorisierung dar.
• Die strategischen Ziele, die in vielen Prozessgruppen relevant sind, müssen zur
Konkretisierung aus der Prozesssicht verfeinert werden.
• Wenn strategische Ziele für viele oder fast alle Prozessgruppen relevant sind, müssen
diese u. U. für eine realistische Gewichtung schon hier feiner ausgearbeitet werden.
Durch das Scoping der Prozesse wird für den Zielverantwortlichen klar ersichtlich, welche
Prozesse direkt von den Zielvorgaben betroffen sind. Der jeweilige Prozessverantwortliche
erhält dementsprechend eine klare Auswertung, welche Anforderungen an „seine“
Prozesse gestellt werden.
In der Literatur findet man zu diesem Thema auch den Begriff des Prozessportfolio-
Managements: Mit dem Prozessportfolio-Management versucht man sämtliche Unterneh
mensprozesse in einer konsolidierten Sichtweise zu bewerten und zu steuern, um damit
Prioritäten für die Weiterentwicklung von Prozessen zu vergeben (European Association of
Business Process Management EABPM 2009).
Abbildung 4.2 zeigt die oben beschriebene Technik der Priorisierung von
Prozessgruppen bzgl. der strategischen Zielvorgaben in anschaulicher Form. Die
Priorisierungsmatrix zeigt in der linken Spalte die definierten strategischen Ziele
und in den entsprechenden Zeilen die Priorisierungsgewichtung zu den einzelnen
Unternehmensprozessen der Prozesslandkarte.
Management- Kern- Unterstützungs-

BSC-Perspektive/ prozesse prozesse prozesse
Strategisches Ziel
M1 M2 M3 M4 M5 M6 K1 K2 K3 K4 K5 K6 S1 S2 S3 S4 S5 S6
Finanzperspektive
Profitabilität steigern … … …… … … … …
IKS und Risikomgmt. unternehmensweit einf. 1 1 0 2 2 2 2 2 1 1 2 2 1 1 0 1 1 0
… … … … … … …
Kundenperspektive
Kundenzufriedenheit erhöhen … … … … … …
… … … … … … …
Prozessperspektive
Prozessstandardisierung implementieren 0 0 0 0 0 0 2 2 2 2 2 2 1 2 1 2 1 1
Produktvereinfachung durchsetzen … … … … … …
Prozesskosten verringern 0 0 1 1 1 0 1 1 2 2 1 1 2 0 0 0 0 0
…
Interne Perspektive
Vertriebsproduktivität erhöhen … … … … …
Mitarbeiterbindung erhöhen … … ……
…
Abb. 4.2 Priorisierungsmatrix „Strategische Ziele“ – „Prozesse“
Beispiel
• Im Zuge eines Audits durch eine Wirtschaftsprüfung wurde festgestellt, dass die
Umsetzung der gesetzlichen IKS-Vorgaben im Unternehmen Lücken aufweist.
Insbesondere muss hier auf die Prozesse des Rechnungswesens (M4, M5) und der
Budgetierung (M6), die Kernprozesse Verkauf (K1) und Bestellmanagement (K2)
sowie Auslieferung (K5, K6) abgezielt werden.
• Das vom Aufsichtsrat beschlossene Kostenziel für 2015 kann am wahrscheinlichsten
in den Prozessen Beschaffung (K3), Lagerverwaltung (K4) und Facility Management
(S1) erzielt werden. Hier soll in Folge auf die Prozesskosten fokussiert werden.
• Die Standardisierung der Kernprozesse über alle internationalen Betriebsstätten
betrifft die Prozesse K1 bis K6 sowie die Unterstützungsprozesse Personal
verwaltung (S2) und IT-Management (S4).
4.2.3 Strategische Prozessziele ableiten
Nach der Priorisierung der Prozessgruppen und Hauptprozesse auf Basis der strategischen
Ziele müssen die strategischen Prozessziele ausformuliert werden. Oft ist der „Gap“ von
den strategischen Unternehmenszielen zu strategischen Prozesszielen sehr groß, sodass
man sich als Basis für die Formulierung der strategischen Prozessziele folgender drei
Stoßrichtungen bedienen kann:
• Kundenfokus,
• Qualitätsführerschaft und
• Kostenführerschaft.
Strategische Prozessziele, die unter den Aspekt Kundenfokus fallen, sind bspw. die
Vereinfachung/Vereinheitlichung der Kanäle oder die Verringerung von Response-
Zeiten bei Angebotsannahmen. Eine Qualitätsführerschaft drückt sich im Rahmen
von strategischen Prozesszielen z. B. immer wieder in Form von Fehlervermeidungs-
Zielen aus. Die Kostenführerschaft konzentriert sich im Prozessbereich auf Ziele zum
Minimieren von Prozesskosten. Dies kann durch eine effiziente Bearbeitung erfolgen oder
durch die Integration von Sourcing-Vorhaben auf Prozessebene.
Die festgelegten strategischen Prozessziele werden dann im Rahmen eines
„Strategie-Checks“ mit den Zielverantwortlichen final verabschiedet. Der Chief Process
Officer stellt die Gesamtsicht und Homogenität im Sinne der Gesamt-Prozesslandkarte
sicher.
4.2.4 Operative Prozessziele ableiten
Nach der Abstimmung der strategischen Prozessziele erfolgt das Herunterbrechen

der strategischen auf die operativen Prozessziele. Diese Aufgabe liegt beim Prozess
verantwortlichen, der „seine“ Teilprozessverantwortlichen koordinieren muss, sofern
diese in der Organisation vorhanden bzw. durch die Komplexität der Prozesse bedingt
sind.
Ähnlich wie beim Management by Objectives-Konzept wird in Abfolge der Pro
zesshierarchie vom Haupt- zu den Teilprozessen eine Zielvereinbarung mit den
Teilprozessverantwortlichen bis hin zu den Prozessmitarbeitern etabliert. Da die invol-
vierten (Teil-)Prozessverantwortlichen meistens auf Basis der Prozessschnittstellen defi-
niert werden, erfolgen hier sehr oft Zielvereinbarungen im Rahmen von Service Level
Agreements auf Teilprozessebene. Die Formulierung der prozessorientierten Service
Level Agreements soll dann wieder in den Kategorien Kundenzufriedenheit, Qualität
und Kosten durchgeführt werden (vgl. Abschn. 4.2.3).
Die Einbindung der Teilprozessverantwortlichen mit deren Fachexpertise und
Praxiswissen ermöglicht es, die Relevanz der operativen Prozessziele zu steigern. Bei der
Erarbeitung und Formulierung von operativen Prozesszielen gibt es einige Grundsätze,
die sich in der Praxis bewährt haben. Es braucht in Summe fünf Grundsätze, die mit der
Formel SMART abgekürzt werden können (Doran 1981; Stöger 2009):
• Spezifische Zielsetzung: Ziele sollen konkret und ergebnisorientiert sein!

• Messbarkeit: „Only what can be measured, gets done!“
• Ableitbarkeit und aktive Beeinflussbarkeit: Jedes Ziel muss einen konkreten Anknüp
fungspunkt an ein oder mehrere strategische Zielfelder haben.
• Realistische Zielsetzung: Es soll erkennbar sein, welche Methodik, Verfahren und
Ressourcen zu verwenden sind.
• Terminierung: Ziele müssen einen entsprechenden Zeitbezug haben, sodass man diese
zu bestimmten Wiedervorlageterminen überprüfen kann.
In Abb. 4.3 sollen Beispiele die Beurteilung von operativen Prozesszielen nach dem
SMART-Prinzip erläutern.
Operatives
Prozess Beurteilung bzgl. SMART
Prozessziel
S - Völlige Beliebigkeit bei der Beurteilung
Die Organisation ist M - Keine Quantifizierung möglich, kein Messverfahren

mit dem
Unternehmen
Prozessgedanken A - Keine operationalisierte Strategie
führen
durchdrungen.
Keine Möglichkeit, die realistische Zielsetzung
R ?
abzuschätzen
T - Kein Termin festgelegt
S + Beurteilung der Zielerreichung möglich

Bis Jahresende
Messbarkeit gegeben (z. B. Zahl der
verwenden alle M +
Vertriebsmitarbeiter, die das Tool verwenden)
Vertriebsmitarbeiter
Außendienst Aus strategischem Ziel "Produktivitätssteigerung"
das neue Leistungs- A +
steuern abgeleitet
erfassungs-Tool und
wenden das R + Realistische, aber doch ambitionierte Zielsetzung
Auswertungstool an.
T + Konkreter Endtermin genannt
Beurteilung der Zielerreichung möglich (z. B.
S +
Prüfung des Releaseplans)
Der Releaseplan wird
M + Messbarkeit gegeben
regelmäßig geprüft
Innovation und pro neuer
A ? …
managen Leistung wird eine
bestehende Leistung
R ? …
gestrichen.
T - Kein Termin angegeben ("... regelmäßig ...")
S + Ziel ist konkret und spezifisch

Die Freischaltung des
M + Messbarkeit ist gut möglich
e-Shops bewirkt 5 %
Vertriebs-
mehr Umsatz und Zusammenhang zwischen "Freischaltung" und
leistung A -
15 % weniger "Umsatzsteigerung"?
durchführen
Zeitaufwand im Keine Möglichkeit die realistische Zielsetzung
R ?
Vertriebsservice. abzuschätzen
T - Kein Endtermin angegeben
Abb. 4.3 Beispiele von SMARTen operativen Prozesszielen (Stöger 2009, S. 124)
Prozessname: Prozessverantwortlicher:
Übergeordneter Prozess:
Auswirkungen
Beschreibung des Ziels Häufigkeit und
Lfd. Name Anderes Ziel, Qualität Kennzahl/
(inkl. kritischer Zuständigkeit
Nr. des Ziels Kosten, Zeit, Messbarkeit
Erfolgsfaktoren) der Messung
Kundenzufriedenheit
Abb. 4.4 Dokumentationsmuster für operative Prozessziele
Für jedes operative Prozessziel sollten die folgenden Informationen erhoben und fest-
gehalten werden:
• Name des Ziels und kurze Beschreibung

• Positive/negative Auswirkungen auf andere Ziele oder allgemeine Ziele, wie Qualität,
Kosten, Zeit und Kundenzufriedenheit
• Erste Ideen und Konzepte zu Kennzahlen und deren Messbarkeit
• Erste Ideen zur Zuständigkeit für die Messung der Kennzahlen
Abbildung 4.4 zeigt eine mögliche Dokumentationsform der operativen Prozessziele.
4.2.5 Controlling-System initialisieren
Schon in dieser Phase werden Vorarbeiten für die Phase des Prozesscontrollings (vgl.
Abschn. 2.4.6 sowie Kap. 14) durchgeführt. Hierbei geht es zu Beginn um die „rich-
tige“ Definition von Prozesskennzahlen. Diese sollen die Erreichung der operativen
Prozessziele treiben. Folgende Kennzahlentypen werden zur Messung der Prozessziele
genutzt:
• Kennzahlen in Bezug auf Durchlaufzeiten: externe Kundensicht

• Kennzahlen in Bezug auf Mengen: Wie oft wird der Prozess durchgeführt?
• Kennzahlen bei Entscheidungen: z. B. Korrektur-Quote
• Kennzahlen für Kapazitäten: z. B. Arbeitsaufwand für bestimmte Aktivitäten
• Kennzahlen in Bezug auf Kosten: Personalkosten eines Prozesses pro Jahr
Die Durchlaufzeit eines Prozesses fokussiert auf die „Außensicht“ (Kundenperspektive).

Sie ist die Summe aller Bearbeitungszeiten, Warte- und Liegezeiten sowie Transportzeiten.
Beschreibung
Name/Beschreibung
der Kennzahl:
Einheit, Art, Zielwert:
Gesamtverantwortlicher:
Vereinbarter Service Level:
Begrenzungszeitraum
und -art:
Schwellwert Grün/Gelb
und Gelb/Rot:
Verantwortung
Messgrößen: (Teil-)Größen, die Bezugs- Daten-
Einheit Wert für Daten-
die Kennzahl definieren zeitraum quelle
bereitstellung
1
2
Berichtsverantwortlichkeiten
und Berichtsintervalle:
Aktion und Eskalation bei
Erreichen des Warnwerts:
Abb. 4.5 Dokumentationsmuster für Kennzahlen
Durchlaufzeiten können auf unterschiedlichen Ebenen gemessen werden (Gesamtprozess,

Teilprozess, Prozessfragment, Aktivität) (vgl. Abschn. 8.3.2).
Die Messung von Mengen bzw. Häufigkeiten fokussiert auf die (interne) Kapazi
tätsperspektive. Mengen bzw. Häufigkeiten können aus unterschiedlichen Sichten
gemessen werden:
• Durchschnittliche Häufigkeit pro Zeitperiode

• Kumulierte Menge pro Zeitperiode
• Verhältnis zu anderen Häufigkeiten
Abbildung 4.5 zeigt ein Dokumentationsmuster für Kennzahlen.

Für die Beurteilung der Güte einer Kennzahl kann die Checkliste genutzt werden, die
in Abb. 4.6 dargestellt ist.
Ja Nein Kriterium
Mit der Messgröße kann das Erreichen des Ziels abgelesen werden.
Die Entwicklung der Messgröße hinsichtlich des Prozessziels ist durch den
Verantwortlichen maßgeblich beeinflussbar.
Das Verhalten der Mitarbeiter wird in die gewünschte Richtung beeinflusst.
Das Kosten-Nutzen-Verhältnis der implementierten Kennzahl ist positiv.
Die prinzipielle Erhebbarkeit der Messgröße ist gewährleistet.
Es ist eine IT-gestützte Erhebung der Kennzahl möglich.
Die Messgröße ist (kurzfristig oder langfristig) beeinflussbar.
Die Datenquelle ist genau spezifiziert.
Es liegen der Messgröße mathematische Formeln zugrunde.
Die Frequenz der Messung ist geklärt.
Eine eindeutige Interpretation der Kennzahl ist unternehmensweit möglich.
Es werden Output-Größen anstelle von Input-Größen verwendet

(d. h. unmittelbare Messung der Leistung anstatt Messung der Input-Faktoren).
Abb. 4.6 Checkliste zur Beurteilung der Güte einer Kennzahl
4.3 Involvierte Rollen und deren Aufgaben
Abbildung 4.7 soll die beteiligten Rollen im zielorientierten Prozessmanagement auflis-

ten und deren Aufgaben grob zusammenfassen.
Der kritische Aspekt im Rahmen des zielorientierten Prozessmanagements liegt in
der Zusammenarbeit der Bereichs-/Abteilungsleiter, dem Chief Process Officer und den
jeweiligen Prozessverantwortlichen. Dieser „Schnittpunkt“ ist für alle funktional orga-
nisierten Unternehmen relevant, in denen funktionale Hierarchien parallel neben der
Prozessorganisation existieren.
Um die Abstimmung an den Schnittpunkten effizient und effektiv durchzuführen,
können für die einzelnen Rollen folgende Aufgaben zusammengefasst werden:
• Die Prozessverantwortlichen müssen die Umsetzung der strategischen Anforderungen
in den Prozessen in Abstimmung mit den Zielverantwortlichen sicherstellen. Es
werden Prozessziele vereinbart und abgeleitet. Der Chief Process Officer behält die
Gesamtsicht im Auge und unterstützt in der Qualitätssicherung der Zielfestlegungen.
Er schafft dann auch unternehmensweit die Rahmenbedingungen für einen kontinu-
ierlichen Verbesserungsprozess.
Abb. 4.7 Überblick über die beteiligten Rollen im zielorientierten Prozessmanagement
• Der Prozessverantwortliche leitet die strategischen Prozessziele mit dem Chief

Process Officer ab und vereinbart je nach Komplexität des Prozesses operative
Prozessziele mit Teilprozessverantwortlichen und Prozessmitarbeitern.
• Die Teilprozessverantwortlichen sind für die Abstimmung und Verfeinerung der
operativen Prozessziele verantwortlich. Der Chief Process Officer unterstützt fach-
lich die Prozessverantwortlichen und Teilprozessverantwortlichen und stellt die
Qualitätssicherung der Ziele sicher.
4.4 Angewandte Technik: Festlegung der

Prozessverantwortung
Im Rahmen der Zielfestlegung für Prozesse ist die Abstimmung von Prozessverantwortlichen
untereinander bzw. Prozessverantwortlichen zu „ihren“ Teilprozessverantwortlichen ein
wesentlicher Erfolgsfaktor. Hierbei stellt sich immer wieder die „Schneidung“ von Prozessen
als kritisches Element heraus. Im Folgenden soll hier eine Technik vorgestellt werden, mit
der die fachliche „Prozessschneidung“ leichter erfolgen kann. Diese Technik kann auch
genutzt werden, um die Zuweisung von Verantwortlichen in einer Prozessarchitektur durch-
zuführen (vgl. Abschn. 3.5).
Meistens werden die Prozessverantwortlichen aus den Reihen der Bereichs- oder
Abteilungsverantwortlichen ernannt. Folglich werden die Aufgaben der hierarchischen
Funktion um eine Prozessfunktion erweitert.
Zur Beantwortung der Frage „Wer ist Prozessverantwortlicher für Prozess X?“ müs-
sen im Vorfeld zwei Punkte geklärt werden:
• Erfolgt die Ausführung des Prozesses in der jeweiligen betrachteten Organisations

einheit des Kandidaten zur Prozessverantwortung (z. B. Abteilungsleiter)?
• Wer gibt die fachliche Vorgabe für die Durchführung des jeweiligen (Teil-)Prozesses und
dessen Aktivitäten? (Welche Aktivität ist wie, wann und von wem durchzuführen?)
Die Beantwortung dieser Punkte kann in einer Matrix visualisiert werden (vgl. Abb. 4.8).
Ja
„Gebe“ White Box: Ja
Prozessverantwortung
Fachliche Vorgabe
„Gebe“ Black Box: Nein
„Bekomme“ Black Box: Ja
Keine
Prozess-
verantwortung
„Bekomme“ White Box: Nein
Nein Ausführung in „eigener“ Ja

Organisationseinheit
Abb. 4.8 Matrix zur Festlegung der Prozessverantwortung

Die Matrix kann folgendermaßen gelesen werden:
• Liegt die Ausführung der Tätigkeiten eines Prozesses in der betrachteten

Organisationseinheit, in der auch die fachlichen Vorgaben für diesen Prozess definiert
werden, so liegt in dieser Organisationseinheit auch die Prozessverantwortung (rech-
ter, oberer Quadrant).
• Liegt die Ausführung der Tätigkeiten eines Prozesses nicht in der betrachteten
Organisationseinheit und werden die fachlichen Vorgaben auch nicht von der
betrachteten Organisationseinheit vorgegeben, dann liegt die Prozessverantwortung
mit Sicherheit in einer anderen Organisationseinheit (linker, unterer Quadrant).
Streitfälle ergeben sich in den zwei anderen Quadranten:
• Die Ausführung der Tätigkeiten eines Prozesses liegt in der betrachteten Orga
nisationseinheit, aber die fachlichen Vorgaben werden von einer anderen Organisa
tionseinheit definiert.
• Die Ausführung der Tätigkeiten eines Prozesses liegt in einer anderen Organi
sationseinheit, aber die betrachtete Organisationseinheit gibt die fachlichen Vorgaben.
Zur Festlegung der Prozessverantwortung für diese Streitfälle hat sich die Black Box-/White
Box-Herangehensweise als vorteilhaft erwiesen.
Eine Black Box-Vorgabe liegt dann vor, wenn nur das Prozessergebnis definiert
wird, aber die eigentlichen Tätigkeiten, wie dieses zu erreichen ist, nicht vorgegeben
werden. Wird also die Vorgabe „nur“ in Bezug auf die Form des Ergebnisses gemacht,
die genaue Festlegung, welche Schritte hier durchgeführt werden sollen, liegt aber im
Verantwortungsbereich der betrachteten Organisationseinheit, dann liegt auch die
Prozessverantwortung in der ausführenden Organisationseinheit.
Wird umgekehrt neben dem Prozessergebnis auch die Ausführung der eigentlichen
Schritte genau vorgegeben (White Box-Vorgabe), dann liegt die Prozessverantwortung
nicht in der ausführenden Organisationseinheit, sondern bei der Organisationseinheit,
die die fachliche Vorgabe gibt (und somit die fachliche Verantwortung besitzt).
Beispiel
Ein Beispiel für ergebnisorientierte Vorgaben (Black Box-Vorgaben) kann wie folgt illus-
triert werden: Bevor der Prozess „Rechnungsbuchung“ im Bereich „Cash Management“
starten kann, müssen die vorgelagerten Tätigkeiten vom Eingang bis hin zur Indizierung
der Rechnungen abgeschlossen werden. Diese Tätigkeiten werden im Bereich „Zentrale
Services“ durchgeführt. Da vom Bereich „Cash Management“ lediglich das Ergebnis
definiert wird, das an dieser Stelle übergeben wird, wird die Prozessverantwortung des
Prozesses „Dokumentenerfassung/-archivierung/-vernichtung“ dem Bereich „Zentrale
Services“ zugeordnet. Die eingehende Rechnung muss gescannt, vorerfasst und indi-
ziert sein. Für den Bereich „Zentrale Services“ besteht jedoch Gestaltungsspielraum, wie
dieses Ergebnis prozessual zu erzielen ist. Der Bereich „Cash Management“ definiert
hierfür nur Ergebnisvorgaben an den Bereich „Zentrale Services“, in welchen festgelegt

wird, wie der Input für den Bereich „Cash Management“ auszusehen hat. Die Trennlinie
der Prozessverantwortung zwischen den Bereichen „Zentrale Services“ und „Cash
Management“ liegt zwischen den Prozessen „Dokumentenerfassung/-archivierung/-
vernichtung“ und „Rechnungsbuchung“.
Beispiel
Ein Beispiel für ablauforientierte Vorgaben (White Box-Vorgaben) kann im Zusammen
spiel von den Bereichen „Zentrale Services“ und „Schaden“ illustriert werden: Der Bereich
„Zentrale Services“ führt den Prozess „Aufnahme und Weiterleitung der Schaden
meldungen“ durch. Dabei werden die Schadeninformationen schon im entsprechenden
IT-System vorerfasst. Der Bereich „Zentrale Services“ muss sich bei der Durchführung
des Prozesses an die vom Bereich „Schaden“ definierten Vorgaben halten. Da nun in
diesem Fall die genauen und spezifischen Arbeitsschritte vom Bereich „Schaden“ an
den Bereich „Zentrale Services“ vorgegeben werden, hat der Bereich „Schaden“ die
Prozessverantwortung für die Aufnahme und Weiterleitung der Schadenmeldungen,
obwohl diese im Bereich „Zentrale Services“ durchgeführt werden.
Konkret hat das im Folgenden auch Auswirkungen auf die Modellierung, Ablage und
Aktualisierung der Prozesse: Die Darstellung von Aktivitäten, welche von anderen
Bereichen durchgeführt werden, jedoch in den eigenen Prozessverantwortungsbereich
fallen, erfolgt mittels der Modellierung der „ausgelagerten Aktivitäten“ in einem eigenen
Geschäftsprozessmodell (Subprozess).
Die Modellierung, Verwaltung und Einbindung in die Prozesslandkarte erfolgt in
jenem Bereich, in welchem die Prozessverantwortung liegt – im letzten Beispiel wäre das
beim Bereich „Schaden“. Eine Einbindung des Modells in die zugehörigen Prozesse des
Bereichs „Zentrale Services“ kann in Form eines Prozessaufrufs erfolgen.
Literatur
Bergsmann S (2012) End-to-End Geschäftsprozessmanagement: Organisationselement – Integrations

instrument – Managementansatz. Springer, Wien
Doran G-T (1981) There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives. Manag
Rev 70(11):35–36
Prozessmanagement Version 2.0. Dr. Götz Schmidt, Gießen
Kaplan R-S, Norton D-P (1992) The Balanced Scorecard – Measures that Drive Performance. Harv
Bus Rev 70(1):71–79
Stöger R (2009) Prozessmanagement – Qualität, Produktivität, Konkurrenzfähigkeit, 2. Aufl. Schäffer-
Poeschel, Stuttgart
Teil III
Prozessdokumentation
Gestaltungs-
und Modellierungsrichtlinien 5
Daniel Bouché, Manfred Lenhardt und Stefanie Schmidt
Zusammenfassung
Eine wichtige Grundlage für ein erfolgreiches Geschäftsprozessmanagement in
Unternehmen oder Organisationen ist die Kenntnis der eigenen Prozesse. Dies wird
unterstützt bzw. erreicht durch eine adäquate Prozessdokumentation, insbesondere
durch eine grafische Prozessmodellierung, die die Arbeitsgrundlage für die prozessbetei-
ligten Rollen bildet und die Basis für weitere Schritte im Geschäftsprozessmanagement
schafft. Der Fokus in diesem Kapitel liegt auf Gestaltungs- und Modellierungsrichtlinien
für die grafische Prozessmodellierung, die ein Rahmenwerk mit Vorgaben darstellen, um
die erstellten Modelle lesbar, verständlich, einheitlich und wiederverwendbar zu gestal-
ten. Diese Eigenschaften sind entscheidende Erfolgsfaktoren für die Prozessmodellierung.
Die wichtigsten Gestaltungs- und Modellierungsrichtlinien werden in diesem Kapitel
vorgestellt und mit praxisnahen Beispielen veranschaulicht.
5.1 Motivation und Begriffe
Während Kap. 3 auf die Prozessarchitektur sowie auf die Gestaltung von Prozessland
karten fokussiert, liegt der Schwerpunkt im vorliegenden Kapitel auf der Prozessmo
dellierung und deren Ausgestaltung.
D. Bouché · M. Lenhardt (*)

e-mail: manfred.lenhardt@boc-de.com
S. Schmidt
BOC Information Systems GmbH, Operngasse 20b, 1040 Wien, Österreich

74 D. Bouché et al.
Für die Dokumentation von Prozessen stehen unterschiedlichste Methoden und

Notationen zur Verfügung. Alle haben gemeinsam, dass sie einen bestimmten Rahmen zur
Modellierung vorgeben, der aus einem mehr oder weniger umfangreichen Satz von Model
lierungsobjekten, Konnektoren und deren Attributen zur Abbildung von Prozessabläufen
besteht. Das alleine ist jedoch nicht ausreichend, um einheitliche Prozesse, auch in Bezug
auf Qualität und Detaillierungsgrad, zu erhalten. Vor allem weil ein wesentlicher Faktor der
Modellierung nicht einkalkuliert werden kann – der Modellierer, der ohne weitere Vorgaben
eine subjektiv-intuitive Modellierung, basierend auf eigenen Erfahrungen, durchführt.
Wird die Modellierung von einem einzigen Modellierer durchgeführt, erhält man
möglicherweise vergleichbare Modelle, jedoch genügt die Qualität (Verständlichkeit,
Lesbarkeit etc.) zuerst nur den Ansprüchen des Modellierers selbst. Gibt es unterschied-
liche Modellierer, ist die Wahrscheinlichkeit hoch, dass sich die jeweils abgebildeten
Prozesse in Bezug auf Detailgrad, Qualität und Inhalte unterscheiden.
Beispiel
Ein IT-Mitarbeiter hat im Rahmen einer Vorstudie die Aufgabe, die im Unternehmen
bereits vorhandenen Prozesse bzgl. Optimierungsmöglichkeiten der IT zu analysie-
ren. Je nach Ausgestaltung der Prozesse kann der IT-Mitarbeiter jedoch nur mit hohem
Zeitaufwand die in anderen Bereichen und Projekten entstandenen Prozessdarstellungen
lesen, verstehen und hinsichtlich seiner Aufgabenstellung verwerten.
In diesem Zusammenhang greifen Gestaltungs- und Modellierungsrichtlinien, die in der

Regel in einem für alle Beteiligten zugänglichen Dokument zusammengefasst werden:
• Die Gestaltungsrichtlinien legen Rahmenbedingungen für die Prozessmodellierung

fest, z. B. für die Wiederverwendbarkeit von Modellen und deren Detaillierungsgrad.
• Die Modellierungsrichtlinien richten sich an die konkrete Modellerstellung und bein-
halten die Festlegung der Modellierungsnotation, Layout-Richtlinien sowie Namens
konventionen sowohl für ganze Modelle als auch für Objekte bzw. Klassen.
Demnach haben Gestaltungs- und Modellierungsrichtlinien eine unmittelbare Auswirkung

auf den Modellierer und dessen Modellierungsergebnisse sowie auf den Prüfer und
Freigeber der Modelle (vgl. Abschn. 5.7). Einer der wichtigsten Einflussfaktoren für die
Ausprägung und Formulierung der Modellierungsrichtlinien sind die spätere Verwendung
der Modelle sowie das formulierte Dokumentationsziel (vgl. ebenso Kap. 2). Es empfiehlt
sich, die Modellierungsrichtlinien regelmäßig mit Anwendungsfällen im Unternehmen und
Adressaten (engl. Stakeholder) der Modelle abzugleichen.
Zusätzlich gelten gesetzliche Vorgaben, Standards und Regularien als Einflussfaktoren
auf Gestaltungs- und Modellierungsrichtlinien, da diese bestimmte Inhalte, deren Detailgrad
und Berücksichtigung von Schnittstellen in der Dokumentation der Geschäftstätigkeit for-
dern. Beispiele hierfür sind Standards, wie ISO 9000:2005ff (International Organization
for Standardization (ISO) 2005), oder Verwaltungsvorschriften, wie Basel III (Bank for
5 Gestaltungs- und Modellierungsrichtlinien 75
International Settlements 2010) oder die Mindestanforderungen für das Risikomanagement

(MaRisk) (Deutsche Bundesbank 2010).
Gestaltungs- und Modellierungsrichtlinien sollen ein effizientes Modellieren ermögli-
chen und dabei folgende Eigenschaften für Prozessmodelle gewährleisten:
• Einheitlichkeit
• Lesbarkeit und
• Verständlichkeit.
Diese Punkte sind wesentlich für das Nutzen, Vergleichen und Wiederverwenden von
Prozessmodellen durch einen ggf. großen und heterogenen Anwenderkreis. Durch ein
lesbares und schnell verständliches Modell wird sowohl bei der Einarbeitungszeit für neue
Mitarbeiter als auch bei der Arbeitszeit aller Anwender für die Informationsbeschaffung
im Operativbetrieb gespart.
Das folgende plakative Beispiel soll dies veranschaulichen (vgl. Abb. 5.1). Der obere
Prozessablauf besitzt dieselben Informationen wie der Prozessablauf unten. Die „unge-
schickte“ Modellierung ohne Modellierungsrichtlinien erschwert die Lesbarkeit und die
(Wieder-)Verwendung des Prozessmodells.
Mit Modellierungsrichtlinien
Ohne Modellierungsrichtlinien
Abb. 5.1 Optische Modellierungsrichtlinien

Um das untere Modell in Abb. 5.1 zu verstehen und für seine tägliche Arbeit als
Arbeitsanleitung zu benutzen, benötigt ein Sachbearbeiter aufgrund der „ungeschick-
ten“ Modellierung deutlich länger als für das obere Modell. Diese Zeit geht von der pro-
duktiven Arbeitszeit ab und demotiviert den Mitarbeiter, sich mit Arbeitsanweisungen
auseinanderzusetzen. Die Konsequenz daraus ist, die in der Praxis sinkende Akzeptanz
und möglicherweise eine höhere Fehlerquote in der Sachbearbeitung, da die aktuelle
Dokumentation nicht bekannt ist oder nicht verstanden wird.
Die Entwicklung und konsequente Anwendung von geeigneten Gestaltungs- und
Modellierungsrichtlinien verringert den Zeitbedarf und steigert die Dokumentations
qualität der Prozessmodelle. Damit ist sie als ein Meilenstein auf dem Weg hin zu einem
erfolgreichen Prozessmanagement anzusehen.
Bei der Einführung von Richtlinien ist es ein wichtiger Aspekt, das Handbuch der
Richtlinien sowie deren Kommunikation auf eine höchstmögliche Akzeptanz der
Modellierer und Anwendbarkeit in der Modellierung auszurichten. Einerseits sollte
der Regelungsbedarf vollständig abgedeckt werden, andererseits muss die Dokumen
tation für die Leser auch handhabbar sein.
Definition
Ein Dokument mit bspw. 100 Seiten ist so umfangreich, dass nicht garantiert wer-
den kann, dass alle Vorgaben bei der Prozessmodellierung berücksichtigt werden.
Der Modellierer und der methodische Prüfer sollten mit vertretbarem Aufwand die
Inhalte der Richtlinien für die jeweiligen Aufgaben nachschlagen können. Es wird
ein übersichtliches und gut strukturiertes Handbuch oder webbasiertes Wiki-System
empfohlen, dessen Anwendung bereits in Modellierungsschulungen Bestandteil ist.
Idealerweise können die wichtigsten Aspekte auf einem doppelseitigen Faltblatt als
Tischunterlage oder Flyer veröffentlicht werden.
Im Folgenden beschreibt Abschn. 5.2 die Grundsätze ordnungsmäßiger Modellierung

(GoM) (Becker et al. 1995) im Kontext der Relevanz für die Modellierungspraxis. In
Abschn. 5.3 und 5.4 werden diese Grundsätze in Gestaltungs- und Modellierungsrichtlinien
anhand von Anwendungsbeispielen veranschaulicht. Abschn. 5.5 geht auf die Erfolgs
faktoren von Gestaltungs- und Modellierungsrichtlinien ein, während die Einhaltung die-
ser Richtlinien mittels Qualitätssicherungsmaßnahmen Inhalt von Abschn. 5.6 ist. Der
abschließende Abschn. 5.7 fasst das Vorgehen und die Verantwortlichkeiten zur Erstellung
von Gestaltungs- und Modellierungsrichtlinien zusammen.
5.2 Grundsätze ordnungsmäßiger Modellierung
Die Grundsätze ordnungsmäßiger Modellierung können als Metaebene der Modellierungs-

und Gestaltungsrichtlinien gesehen werden. Sie stellen sichten- und methodenneutrale
Anforderungen an die Prozessmodellierung dar (Becker et al. 1995).
Die sechs Grundsätze ordnungsmäßiger Modellierung sind (Becker et al. 1995):
1. Grundsatz der Richtigkeit

2. Grundsatz der Relevanz
3. Grundsatz der Wirtschaftlichkeit
4. Grundsatz der Klarheit
5. Grundsatz der Vergleichbarkeit
6. Grundsatz des systematischen Aufbaus
Modellierungstätigkeiten in Unternehmen oder Organisationen werden gegen die

konkret definierten Modellierungsrichtlinien geprüft, deren Basis die Grundsätze der
Modellierung bilden. Die Grundsätze sind auf der Metaebene sehr abstrakt formuliert
und werden nachfolgend anhand von Beispielen erläutert.
5.2.1 Grundsatz der Richtigkeit
Der Grundsatz der Richtigkeit gliedert sich in zwei Anforderungen: die syntaktische
Richtigkeit und die semantische Richtigkeit.
Als syntaktisch richtig (also formal korrekt) gelten Modelle, welche vollständig und korrekt
gegenüber dem zugrunde liegenden Metamodell sind (Becker et al. 1995). Das Metamodell gibt
hierbei die Informationsobjekte und Notationsregeln für die konkrete Modellerstellung vor.
Beispiel
Für die Modellierung einer Parallelbearbeitung werden die vordefinierten Objekte
und Konnektoren verwendet.
Die semantische Richtigkeit wird an der Struktur und Verhaltenstreue gegenüber dem
zugrunde liegenden Objektsystem gemessen (Becker et al. 1995), d. h. dass der im Modell
dargestellte Sachverhalt die Realität möglichst genau wiedergibt.
Bedeutung in der Praxis

Dieser Grundsatz wird mit dem Einsatz eines Prozessmodellierungs-Werkzeugs erfüllt,
das eine entsprechende Modellierungsmethode mit einer definierten Menge an Knoten
und Kanten vorgibt. Zusammen mit Gestaltungs- und Modellierungsrichtlinien sollte
sowohl die syntaktische als auch die semantische Richtigkeit sichergestellt sein.
Beispiel
Die BPMS-Methode (vgl. Abschn. 6.2) gibt pro Sicht/Ebene/Modelltyp bestimmte
Modellierungsobjekte vor (Knoten) und definiert, ob und mit welchen Konnektoren
(Kanten) diese verbunden werden (syntaktische Richtigkeit). Das kann durch
spezifische Gestaltungsrichtlinien unterstützt beziehungsweise verfeinert werden,

indem bspw. Modellierungsrichtlinien mit Namenskonventionen die semantische
Richtigkeit sicherstellen.
Im Gegensatz zu Prozessmodellierungs-Werkzeugen, wie z. B. ADONIS®, besit-
zen reine Präsentationswerkzeuge kein zugrunde liegendes Metamodell und keine
Notationsregeln, auf deren Grundlage die Richtigkeit einfach überprüft werden kann.
Prozessmodellierungs-Werkzeuge können zudem automatisch Notationsregeln überprü-
fen oder sie unterstützen/korrigieren den Modellierer direkt während der Modellierung.
5.2.2 Grundsatz der Relevanz
Der Grundsatz der Relevanz involviert einerseits die Eingrenzung des zu betrachten-
den Bereichs als auch die konkrete Ausprägung im Modell (Umfang). Beide Fälle sind
stark mit dem adressierten Kreis und dem verfolgten Ziel verbunden. Essentiell für die-
sen Grundsatz ist daher eine explizite Formulierung der Modellierungsziele bezogen auf
sämtliche Modellkomponenten (Becker et al. 1995).

Die Ausgestaltung der einzelnen Prozesse oder eines Prozessbereichs kann nur mit der
vorhergehenden Definition des Modellierungszwecks erfolgen und/oder der Priorisierung
der Prozesse im zu betrachtenden Bereich.
Prozessmodelle zur Verwendung als Arbeitsanweisung werden andere Detaillie
rungsgrade und Inhalte aufweisen als Prozessmodelle zur Einführung eines neuen IT-
Systems. Darüber hinaus können Prozessmodelle mit unterschiedlicher Bedeutung für
das Unternehmen/die Organisation im Detailgrad divergieren.
Zusätzlich werden unterschiedliche Gruppen im Unternehmen oder in der Organi
sation (z. B. Fachbereich, IT, Controlling) verschiedene Ansprüche an das Modell erhe-
ben und entsprechend weitere Informationen fordern, welche aus deren Sicht zum
Verständnis des Modells beitragen.
Definition
Um die Relevanz eines Prozesses zu identifizieren oder festzulegen, werden typischer-
weise Prozesslandkarten erstellt und hierarchisiert, bevor die Ablaufmodellierung in
Form von Geschäftsprozessmodellen erfolgt (vgl. ebenso Kap. 3 und Priorisierungsmatrix
in Abschn. 4.2.2).
5.2.3 Grundsatz der Wirtschaftlichkeit
Dieser Grundsatz relativiert den Absolutheitsanspruch der übrigen Grundsätze und

basiert grundsätzlich auf dem ökonomischen Prinzip. Im Sinne der Modellierung hängt
das wiederum sehr eng mit dem Modellierungszweck und somit mit dem Grundsatz der
Relevanz zusammen (Becker et al. 1995).

Diesem Grundsatz kann auf verschiedenen Ebenen Genüge getan werden. Einerseits
kann durch die Verwendung eines Werkzeugs mit ganzheitlichem Ansatz, welches
u. a. die Wiederverwendung einzelner Elemente und Abläufe unterstützt, der Aufwand
der Modellierung reduziert werden. Andererseits sollte dieser Grundsatz sozusagen als
Erinnerung hinter jedem einzelnen hier aufgeführten Grundsatz stehen, den Kosten-
Nutzen-Faktor nicht außer Acht zu lassen. Diese könnte auf den folgenden Satz reduziert
werden: So viel Informationen wie nötig und so wenig wie möglich.
Definition
Prozessmodellierungs-Werkzeuge, wie z. B. ADONIS®, unterstützen eine wirtschaft-
liche Modellierung mit einer intuitiven Benutzeroberfläche sowie durch Konzepte
für Wiederverwendung, wie Submodelle und sogenannte „Zentrale Modelle“ (vgl.
Abschn. 5.3.2).
5.2.4 Grundsatz der Klarheit
Dieser Grundsatz adressiert die Verständlichkeit der Modelle durch Dritte – die
Modellnutzer. Die Forderung nach einem strukturierten, intuitiv zugänglichen und les-
baren Prozessmodell steht in Wechselbeziehung mit dem Grundsatz der Richtigkeit und
kann diesen wiederum beeinflussen (Becker et al. 1995).

Die Verständlichkeit und Lesbarkeit der Modelle wird einerseits durch die Verwendung
eines Modellierungswerkzeugs, das eine definierte Methode vorgibt, und andererseits
durch entsprechende Gestaltungs- und Modellierungsrichtlinien, welche die gemein-
same Basis zu einer einheitlichen Modellierung darstellen, sichergestellt.
Definition
Der Grundsatz der Klarheit kann grundsätzlich durch eine leicht verständliche, intu-
itive Modellierungsnotation umgesetzt werden. Hierbei unterstützen bspw. auch
farbliche Markierungen und Piktogramme, die dem Leser der Modelle vorhan-
dene Detailinformationen symbolisieren, wie z. B. Input/Output oder verknüpfte
Dokumente. Weiterhin kann der Grundsatz der Klarheit durch rollenspezifische
Sichten auf die Prozesse oder durch unterschiedliche Einstiegsszenarien in bzw. Filter
auf die Prozesslandkarte (vgl. Kap. 3) unterstützt werden.
5.2.5 Grundsatz der Vergleichbarkeit
Dieser Grundsatz kann nur in Bezug auf andere Modelle beurteilt werden – ist also keine
modellautonome Eigenschaft – und hat ähnlich dem Grundsatz der Richtigkeit zwei
Dimensionen (Becker et al. 1995):
• Syntaktisch:
Inwieweit sind Modelle vergleichbar, welche mit unterschiedlichen Modellierungs
methoden erstellt wurden?
• Semantisch:
Die semantische Vergleichbarkeit wird auf inhaltlicher Ebene definiert. Sie wird z. B.
zum Vergleich von Ist- und Soll-Modellen, Soll- und Referenzmodellen oder Ist-
Modellen unterschiedlicher Tochtergesellschaften benötigt.

Die syntaktische Vergleichbarkeit ist davon abhängig, wie ähnlich sich die verwende-
ten Modellierungsmethoden sind. Werden zum Beispiel unterschiedliche Objekte zur
Modellierung mit der gleichen Bedeutung verwendet, ist ein Vergleich relativ einfach.
Zum Beispiel kann der Start eines Prozesses in Methode A durch ein Dreieck und in
Methode B durch ein Sechseck dargestellt werden. Die Aussage ist jedoch die gleiche.
Auf einer abstrakteren Ebene können auch Modellierungssprachen verglichen werden.
Hierfür ist es jedoch meist notwendig, dass die Modellierungssprachen für ähnliche/glei-
che Einsatzgebiete vorgesehen sind. Zum Beispiel besitzen die Modellierungssprachen
UML® und BPMN unterschiedliche Einsatzgebiete, sodass mit diesen Sprachen doku-
mentierte Modelle meist nur schwer vergleichbar sind.
Die semantische Vergleichbarkeit kann unterstützt werden, indem ähnliche oder
gemeinsam genutzte Patterns (Muster) und Abläufe als eine Art Vorlage, z. B. als
Referenzprozesse, zur Verfügung gestellt werden, die dann in einen speziellen Kontext ein-
gebunden und möglicherweise verfeinert werden. Als Beispiel lassen sich Rollen, welche
zentral definiert und nur im Prozesskontext eingebunden werden (Verantwortlichkeiten),
oder auch (Teil-)Abläufe, welche in unterschiedlichen Prozessen wiederverwendet werden
(wie Prüfschritte in unterschiedlichen Prozesskontexten), anführen.
Beispiel
Unternehmen oder Organisationen mit dezentraler Bearbeitung (z. B. die Filialen einer
Bank) streben in der Regel aus Kostengründen eine einheitliche Bearbeitung der Prozesse
an. Trotz allem können sich die erstellten Prozessmodelle bspw. durch die Prozessmen
gen, die Häufigkeit der verschiedenen Ablaufwege oder auch in Bearbeitungszeiten
unterscheiden.
Prozessmodellierungswerkzeuge können bei der Identifikation derartiger Unterschiede
mit Funktionalitäten, wie einem grafischen oder tabellarischen Modellvergleich und
Pfadanalysen, unterstützen.
5.2.6 Grundsatz des systematischen Aufbaus
Dieser Grundsatz verlangt, dass bei der Beschreibung in getrennten Sichten, das Metamodell
so konzipiert sein muss, dass Zusammenhänge zwischen den einzelnen Sichten klar sind
und diese bereits während der Modellierung adressiert werden können (Becker et al. 1995).

In der Prozessmodellierung dienen verschiedene Beschreibungssichten sowohl dem syste-
matischen Aufbau eines Modells als auch der Komplexitätsreduktion. Hierbei wird verhin-
dert, dass ein Prozessmodell mit Informationen überladen wird, wobei die Informationen
über die verschiedenen Sichten trotz allem zur Verfügung stehen. Die verschiedenen
Beschreibungssichten werden häufig als Modelltypen oder Diagrammarten bezeichnet und
über Referenzen (Verlinkungen) miteinander verknüpft. Neben dem Prozessmodell gibt es
häufig weitere Sichten für die Aufbauorganisation oder für die IT-Systeme.
Ein weiterer Vorteil des Auslagerns von prozessübergreifenden Informationen in
spezielle Sichten (z. B. Submodelle, Rollen, Anwendungen oder Dokumente) liegt in der
Möglichkeit, diese Informationen zentral für die Modellierer bereitzustellen und zu pfle-
gen (vgl. Abschn. 5.3.2).
Prozessmodellierungs-Werkzeuge bieten zudem in der Regel weiterführende Funktio
nalitäten, um Sichten zusammenzuführen oder deren Zusammenhänge darzustellen.
Beispiele hierfür sind Funktionalitäten, wie das Einblenden von Submodellen in ein
Hauptmodell, das Generieren von Sichten, bspw. von Prozesslandkarten, sowie tabellarische
Sichten für die Modellierung oder für die Zusammenhänge der Sichten (Referenzen-Sicht).
Beispiel
In Prozessmodellierungs-Werkzeugen werden die Anwendungen eines Unternehmens
oder einer Organisation in einer eigenen Sicht modelliert und gepflegt, bspw. in einem
Modell des Typs IT-Systemmodell. Artefakte aus einem solchen zentralen Modell
oder Repository werden z. B. den Aktivitäten über Referenzen (Verlinkungen) zuge-
ordnet. Im Vergleich zu reinen Präsentationswerkzeugen vereinfacht dies die Pflege
der Informationen. Ändert sich bspw. der Name einer Anwendung, kann dies im
Prozessmodellierungs-Werkzeug an einer Stelle erfolgen, während in Präsentationswerk
zeugen alle Zeichnungen/Dateien durchsucht und separat geändert werden müssen.
5.3 Gestaltungsrichtlinien für Geschäftsprozessmodelle
5.3.1 Detaillierungsgrad
Den richtigen Detaillierungsgrad für die Modellierung von Aufgaben/Tätigkeiten festzu-

legen, ist eine zentrale Aufgabe zu Beginn eines Modellierungsvorhabens. Die Richtlinie
lenkt die Prozessmodellierung zum erwarteten Ergebnis. Gemäß dem Grundsatz der
Wirtschaftlichkeit muss der Detaillierungsgrad der Aufgabenstellung entsprechen und

kann in der Regel aus dem Ziel des Projekts bzw. Modellierungsvorhabens oder aus
Erfahrungswerten aus vergangenen Modellierungsvorhaben abgeleitet werden.
Beispiel
Das Projektziel ist die Einführung einer neuen Anwendung für die Sachbearbeitung.
Die Prozessmodellierung soll hierbei Informationen liefern, welche fachlichen
Sachverhalte zu implementieren sind. Aus dem Projektziel kann abgeleitet werden,
dass eine sehr detaillierte Modellierung erforderlich ist. Jeder fachliche Sachverhalt
ist mit seinen Varianten und Schnittstellen abzubilden, den die neue Anwendung
zukünftig unterstützen soll. Die Dokumentation sollte zudem auf Datenfeldebene
erfolgen, um die Anforderungen an die Anwendung möglichst genau zu spezifizieren.
Der Detaillierungsgrad muss nicht für alle Prozesse gleich sein. Gemäß dem Grundsatz
der Wirtschaftlichkeit ist der Dokumentationsbedarf für Prozesse mit geringer
Häufigkeit und Kritikalität zu unterscheiden vom Dokumentationsbedarf der Kern-
oder Leistungsprozesse. Bei geringem Detaillierungsgrad kann im Bedarfsfall sogar auf
eine Ablaufmodellierung verzichtet und die Dokumentation auf Ebene der Prozess
landkarte mit einer prägnanten textuellen Prozessbeschreibung und Definition des
Prozessverantwortlichen vorgenommen werden.
Beim Detaillierungsgrad für die Modellierung von Aufgaben/Tätigkeiten können drei
Ebenen unterschieden werden (vgl. ebenso Kap. 2), wobei der Detaillierungsgrad und
Informationsgehalt der Prozessmodelle von Ebene zu Ebene zunimmt.
Detaillierungsebene 1: Verantwortlichkeiten (DEMI/RACI) und/oder Inputs/

Outputs (SIPOC)
Die Detaillierungsebene 1 ist die gröbste Beschreibungsebene für Aufgaben/Tätigkeiten.
Hierbei wird ein Prozess mit wenigen Aufgaben/Tätigkeiten beschrieben. Im Fokus
steht die grobe Ablaufbeschreibung im Sinne von „Was sind die Hauptschritte, die
zum Prozessziel führen?“, um eine schnelle End-to-End-Sicht (Prozessauslöser und
Prozessergebnisse) zu erhalten. Darauf basierend werden die Verantwortlichkeiten und
Inputs/Outputs der Aufgaben/Tätigkeiten beschrieben.
Die Dokumentation der Verantwortlichkeiten kann mit dem Schema DEMI (engl.
RACI) erfolgen, während die Inputs und Outputs mittels eines SIPOC-Diagramms
beschrieben werden können.
Die Bezeichnung DEMI steht hierbei für folgende Verantwortlichkeiten:
• Durchführungsverantwortung (Responsible)
• Ergebnisverantwortung (Accountable)
• Mitarbeit/Mitwirkung (Consulted)
• Informieren (Informed)
SIPOC
DEMI/RACI
Abb. 5.2 Detailgrad 1 in der Prozessmodellierung: Kombination Verantwortlichkeiten (DEMI/RACI)

und Inputs/Outputs (SIPOC)
Mit Hilfe eines SIPOC-Diagramms können die folgenden Fragen beantwortet werden:
• Supplier: Wer liefert zu? (intern/extern)

• Input: Was wird zugeliefert? (Ressourcen, Material, Dokumente etc.)
• Process: Um welchen Prozess(schritt) (also um welche Aufgabe/Tätigkeit) geht es?
• Output: Was ist das Ergebnis? (Ressourcen, Material, Dokumente etc.)
• Customer: Für wen werden die Ergebnisse erzeugt? (Kunde intern/extern)
Ein SIPOC-Diagramm bietet somit die Möglichkeit, neben den Aufgaben/Tätigkeiten auch
deren In- und Outputs zu dokumentieren. In Kombination mit den Verantwortlichkeiten
erhält man bereits auf Detaillierungsebene 1 eine umfassende Sicht zu den Verantwort
lichkeiten und eingesetzten Ressourcen (vgl. Abb. 5.2). Die Entscheidung, einen Prozess
auf der nächsten Detaillierungsstufe zu modellieren, hängt vom Modellierungsziel ab.
Typische Anwendungsgebiete für eine Prozessmodellierung auf Detaillierungsebene 1
finden sich im Qualitätsmanagement oder bei der organisatorischen Reorganisation (z. B.
Dokumentation von Aufgabenzuordnungen oder Optimierung von Ressourcenflüssen).
Detaillierungsebene 2: Bearbeiter-/Medienwechsel
Bei dieser Detaillierungsebene wird eine neue Aufgabe/Tätigkeit modelliert, wenn
ein Bearbeiterwechsel stattfindet. Dieses Prinzip kann auch auf den Wechsel des
Arbeitsmediums angewendet werden, z. B. bei einem Wechsel von Papierbearbeitung auf
eine elektronische Bearbeitung.
Durch den Wechsel des Bearbeiters oder des Mediums können Rückfragen und
Schleifen im Prozessablauf entstehen, Aufgaben/Tätigkeiten werden ggf. doppelt ausge-
führt oder es entstehen zeitliche Verzögerungen und Wartezeiten.
Typische Anwendungsgebiete für eine Prozessmodellierung auf Detaillierungsebene 2 sind:
• Prozessanalysen, Prozessoptimierungen und Organisationsuntersuchungen (vgl. Kap. 8

und 11),
• eine Personalbedarfsermittlung (vgl. Kap. 9) oder Prozesskostenrechnung (vgl. Kap. 10)

oder
• der prozessorientierte Aufbau eines Internen Kontrollsystems (IKS) (vgl. Kap. 17).
Detaillierungsebene 3: Unterbrechbarkeit
Bei dieser Detaillierung wird eine neue Aufgabe/Tätigkeit modelliert, solange sie vom
Bearbeiter noch „sinnvoll“ unterbrochen werden kann. Die neue Aufgabe/Tätigkeit erzeugt
auch ein neues Ergebnis. Ist dies nicht der Fall, ist es nicht sinnvoll, die Aufgabe/Tätigkeit
weiter zu detaillieren. Die Aktivität ist „ununterbrechbar“. Typische Anwendungsgebiete
für eine Prozessmodellierung auf Detaillierungsebene 3 sind Arbeitsanweisungen bzw.
Arbeitsanleitungen oder IT-Spezifikationen.
Zum Detailgrad der Ablaufbeschreibung gehört auch die Festlegung, welche Infor
mationen zu den Aktivitäten zu erheben und im Prozessmodell zu hinterlegen sind.
Abhängig vom Ziel der Prozessmodellierung können verschiedenste Informationen rele-
vant sein, z. B.:
• wie oft ein Prozess pro Woche/Monat/Jahr durchlaufen wird,

• wie die Durchlaufzeiten eines Prozesses sind,
• welche Kosten der Prozess verursacht,
• welche IT-Anwendungen verwendet werden,
• welche Dokumente durch den Prozess erzeugt/verändert werden,
• welche Rollen diesen Prozess bearbeiten oder
• welche Produkte durch diesen Prozess bearbeitet werden.
Darüber hinaus können weitere Anwendungsgebiete der Prozessmodellierung berücksichtigt

werden (z. B. Risikomanagement, Maßnahmenmanagement oder Kennzahlen-Controlling).
Ist das Ziel der Prozessmodellierung bspw. eine durchgängige Ist-Dokumentation
der vorhandenen Prozessschnittstellen, so ist die Aufnahme von Bearbeitungszeiten
und Kosten zunächst von untergeordneter Bedeutung. Wird jedoch das Ziel verfolgt,
Durchlaufzeiten eines Prozesses zu verbessern und verschiedene Soll-Varianten quanti-
tativ zu vergleichen, so ist die Aufnahme dieser Daten unabdingbar.
5.3.2 Wiederverwendung
Ein Ziel der Prozessmodellierung ist es, eine redundante Informationshaltung zu ver-
meiden und Geschäftsprozesse (Subprozesse), Prozessteile (Patterns), aber auch einzelne
Objekte (Objekte in zentralen Modellen) einmal zu modellieren und an anderer Stelle
wiederzuverwenden.
Die Wiederverwendbarkeit kann hierbei für das gesamte Unternehmen gelten oder
sich auf Unternehmensbereiche oder den jeweiligen Projektkontext beschränken.
Wiederverwendung von Prozessen (Subprozesse)

Ein (Sub-)Prozess ist ein in sich abgeschlossener Ablauf von Aktivitäten mit einer eindeuti-
gen Zielsetzung und mit einem definierten Umfang an Ergebnissen. Sowohl die Zielsetzung
als auch die Ergebnisse des Subprozesses müssen in den jeweiligen Kontext des übergeord-
neten Ablaufs integriert werden können. Ein Subprozess wird entweder modelliert, um ein
Prozessmodell übersichtlicher zu strukturieren oder um den Subprozess aufgrund seiner
Wiederverwendbarkeit übergreifend auch in anderen Prozessmodellen einzubinden.
Es werden synchrone und asynchrone Prozessaufrufe unterschieden. Wird das
Ergebnis des aufgerufenen Prozesses im aufrufenden Prozess weiterverwendet, so wird
von einem synchronen Prozessaufruf und von einem Subprozess gesprochen. Wird hin-
gegen der Prozess zwar aufgerufen, jedoch kein Ergebnis zurückerwartet, so handelt es
sich um einen asynchronen Prozessaufruf beziehungsweise um einen Nachfolgeprozess.
Beispiel
Asynchrone Prozessaufrufe werden häufig in prozesssteuernden Anwendungen
genutzt. Während bspw. ein Sachbearbeiter einen Prozess bearbeitet, wird – gesteu-
ert von einem Workflow-System – ein Nachfolgeprozess gestartet und zur späteren
Bearbeitung in die Arbeitsliste des Sachbearbeiters eingestellt.
Die Standardisierung eines (Sub-)Prozesses wird dann erreicht, wenn nicht nur die ein-
zelnen Schritte des Ablaufs, sondern insbesondere auch Rollen, Dokumente und IT-
Systeme gleichartig genutzt werden. Abweichungen müssen bspw. als Varianten in den
Prozessen dargestellt werden.
Wiederverwendung von Prozessteilen (Patterns)

Patterns sind Musterlösungen/Vorlagen, die einen Sachverhalt beschreiben, der ähnlich
aber nicht vollständig standardisiert in mehreren Prozessen vorkommt. Patterns werden
daher aus der Vorlage kopiert und als Teilablauf in andere Prozesse eingefügt und an die
unterschiedlichen Sachverhalte in den Prozessen angepasst.
Bei Patterns können drei Stufen der Wiederverwendbarkeit unterschieden werden:
• Wiederverwendung einer Folge von Aufgaben/Tätigkeiten,

• zusätzliche Wiederverwendung der Beschreibungen sowie
• zusätzliche Wiederverwendung der hinterlegten Rollen, Dokumente und/oder Anwen-
dungen.
Tabelle 5.1 skizziert die Vor- und Nachteile von Subprozessen und Patterns.
Verwaltung von Subprozessen oder Patterns: Ein Best Practice-Ansatz

Die Verwaltung und Integration von Subprozessen und Patterns muss in den Modellie
rungsrichtlinien festgehalten werden. Dies beinhaltet die Erstellung neuer Subprozesse
und Patterns bis hin zu Änderungen und der Übernahme in den Prozesskontext.
Tab. 5.1 Vor- und Nachteile von Subprozessen und Patterns

Art Vorteil Nachteil
Subprozess Änderungen in einem Subprozess Ein Subprozess muss ohne Änderungen am
müssen nur einmal, nämlich im Modell (beispielsweise Beschreibungen, IT-
Subprozess-Modell selbst, ange- Systeme, Rollen) übernommen werden und ist
passt werden. Damit reduziert sich damit relativ unflexibel. Wird ein Subprozess
der Nachbearbeitungsaufwand bei mehrmals verwendet, so muss jeweils eine
Änderungen im Prozess auf ein vollständige fachliche Übereinstimmung
Minimum. gegeben sein.
Pattern Patterns können flexibel an die Änderungen an Patterns ziehen sich nicht
modellierten Sachverhalte automatisch in den Prozessmodellen, in denen
angepasst werden. Beispielsweise sie verwendet werden, nach. Daher ist der
können Beschreibungen, Rollen Nachbearbeitungsaufwand bei Änderungen
oder Anwendungen an prozess in Patterns höher als der bei Subprozessen.
spezifische Kontexte angepasst Zudem muss die Verwendung der Patterns
werden. dokumentiert werden.
Vor jeder Modellierung von Standard-Sachverhalten sollte geprüft werden, ob bereits

ein Subprozess oder Pattern vorliegt. Dazu kann beispielsweise eine zentrale Prozess
landkarte bereitgestellt werden, die einen Überblick über alle modellierten Patterns und
Subprozesse liefert.
Erfahrungsgemäß ist es sinnvoll, dem Modellierer zu den Patterns und Subprozessen
Informationen zur Verfügung zu stellen, zum Beispiel:
• den Subprozess-/Pattern-Verantwortlichen, der bei eventuellen Änderungen am Sub

prozess/Pattern zu kontaktieren ist,
• Beispielprozesse, in denen die entsprechenden Patterns Verwendung finden,
• eine Begründung zur Bereitstellung oder Entwicklung des Subprozesses/Pattern,
• die Regeln zur Nutzung, z. B. „Welche Anpassungen sind am Pattern erlaubt?“ oder
„Auf welche Art und Weise kann der Subprozess verwendet werden?“
• der Status des Subprozesses/Pattern (z. B. freigegeben oder in Qualitätssicherung).
Wiederverwendung von Objekten in zentralen Modellen

Wiederverwendbare Objekte, wie Dokumente, Rollen, IT-Systeme, Risiken oder
Kontrollen, werden normalerweise in zentralen Modellen verwaltet. In vielen
Unternehmen/Organisationen ist eine spezielle Organisationseinheit für diese Modelle/
Objekte verantwortlich und erstellt und pflegt diese für das gesamte Unternehmen.
Es handelt sich um eine Bibliothek von Objekten, die einmal modelliert und vom
Prozessmodell aus beliebig oft verwendet (referenziert) werden kann.
Bei konsequenter Modellierung und Einbindung dieser Objekte und der entspre
chenden Unterstützung durch das Modellierungswerkzeug ergeben sich folgende
Vorteile:
• Auswertungsmöglichkeiten:
Ausgehend vom Objekt kann festgestellt werden, ob und wenn ja, wo bzw. wie oft
es verwendet wird, z. B. in welchen Prozessen ein bestimmtes Dokument verwendet
wird oder welche Prozessschritte ein bestimmtes IT-System benötigen.
• Einheitliche Bezeichnung und Detaillierungsgrad:
Durch die zentrale Vergabe der Namen und die Einbindung über Referenzen
wird eine einheitliche Bezeichnung sowie ein einheitlicher Detaillierungsgrad im
Unternehmen und/oder Projekt sichergestellt und etabliert.
• Effiziente Verwaltung:
Durch die zentrale Verwaltung der Objekte werden Änderungen an einer Stelle durch-
geführt und automatisch über die Referenzierung in allen Prozessen, in die das Objekt
eingebunden ist, nachgezogen. Im Gegensatz dazu muss bei einfachen Präsentations-
oder Zeichenwerkzeugen zunächst identifiziert werden, wo ein Element ggf. meh-
rere Male modelliert wurde, um es dann an jeder Stelle zu ändern. Wurde zudem der
Name nicht einheitlich verwendet, wird die Überarbeitung zusätzlich erschwert.
Beispiel
Bezüglich einheitlicher Bezeichnungen und Detaillierungsgrad kann der allgemeine
Begriff „CRM-Datenbank“ ausreichend sein oder der Projektkontext erfordert die
genaue Beschreibung, welcher Bereich der CRM-Datenbank angesprochen wird, wie
zum Beispiel „Beschwerdemanagement“, „Auftragsverwaltung“, „Kundenkontakte“
etc. Eine Detaillierung ist bspw. sinnvoll, wenn Teile der CRM-Datenbank in ein neues
System ausgelagert werden und die davon betroffenen Prozesse zu ermitteln sind.
5.4 Modellierungsrichtlinien für Geschäftsprozessmodelle
Die Modellierungsrichtlinien richten sich an die konkrete Modellerstellung und bein-

halten in der Regel:
• die Festlegung der Modellierungssprache und -notation,

• Layout-Richtlinien,
• Richtlinien zur Namensgebung (Namenskonventionen) sowie
• die Ablagestruktur der Modelle.
Die Modellierungssprache legt die Objekte und Konnektoren und deren Attribute für die
Prozessmodellierung fest. Die Notation gibt die Visualisierung der Sprache vor. Beispiele
für bekannte Sprachen zur Prozessmodellierung sind u. a.:
• Business Process Management Systems (BPMS) (vgl. Kap. 6 bzw. (Karagiannis 1995;
Junginger et al. 1998; Bayer et al. 1999)),
• Business Process Model and Notation (BPMN), ein Industriestandard der Object
Management Group (OMG) (2011) (vgl. Kap. 6),
• Ereignisgesteuerte Prozessketten (EPK), veröffentlicht von einer Arbeitsgruppe unter
Leitung von August-Wilhelm Scheer (Keller et al. 1992).
Für die Festlegung der Modellierungssprache ist ebenso das Ziel der Prozessdokumen
tation ausschlaggebend. Die Modellierungssprachen sind zum Teil sehr umfangreich
bzw. müssen ggf. an individuelle Bedürfnisse angepasst werden.
Die oben genannten Sprachen besitzen verschiedene Stärken. So eignet sich bspw. die
BPMS-Modellierungsmethode für fachliche Einsatzgebiete, wie die Prozessdokumentation
und die Prozessoptimierung. Die BPMN hingegen fokussiert auf die technische Umset
zung mittels prozesssteuernder Systeme.
Im Zusammenhang mit der Sprache sollten die Modellierungsrichtlinien zudem
Folgendes festlegen:
• Welche Klassen werden für welchen Modellierungszweck eingesetzt?

• Welche Attribute sollen/müssen genutzt werden (Pflichtfelder)?
Die Layout-Richtlinien legen vor allem optische Aspekte fest, z. B.
• einheitliche Modellierungsrichtung,
• stringente Vorwärtsmodellierung,
• rechtwinklige Verwendung von Konnektoren,
• Verwendung von Schwimmbahnen und
• Verwendung von Subprozessen.
Definition
Umfangreiche Prozesse mit vielen Tätigkeiten und Bearbeitungsalternativen (Pfaden)
sind unabhängig vom Medium ab einer bestimmten Komplexität nur sehr schwer
zu lesen. In diesem Fall können Richtlinien definiert werden, in welchen Fällen die
Auslagerung von Prozessteilen in Subprozesse die optische Darstellung vereinfachen.
Ein weiterer Aspekt der Modellierungsrichtlinien sind Namenskonventionen für

Modelle und Objekte. Diese unterstützen eine rasche Identifikation und Zuordnung der
Modelle/Objekte bspw. in umfangreichen Dokumentationen oder Auswertungen.
Beispiele für Namenskonventionen sind:
• bei Modellen z. B. Aufnahme des Konzern-/Organisationsbereichs in den Modellnamen,

• bei Objekten z. B. verrichtungsorientierte Benennung der Aktivitäten mit „Substantiv +
Verb“.
Ein weiterer Punkt in Modellierungsrichtlinien ist die Ablagestruktur der Modelle. Diese
sollte so gestaltet sein, dass die Modellierer/Benutzer die Prozesse oder Modelle, die sie
bearbeiten oder für die sie zuständig sind, rasch identifizieren und auffinden können.
Die Ablagestruktur/Verzeichnisstruktur ist daher häufig wie folgt aufgebaut:
• produktbezogen,
• prozessbezogen oder
• abteilungsbezogen.
Oftmals sind auch Mischformen sinnvoll, z. B. eine Ablagestruktur, die auf der höchsten
Ebene produktbezogen ist und sich dann prozessbezogen aufgliedert.
5.5 Erfolgsfaktoren von Gestaltungs- und

Modellierungsrichtlinien
Zu den Voraussetzungen für ein erfolgreiches Modellierungsvorhaben zählen Gestaltungs-

und Modellierungsrichtlinien, die sich konsequent an den Eigenschaften Einheitlichkeit,
leichte Lesbarkeit und Verständlichkeit ausrichten.
Die wichtigsten Erfolgsfaktoren hierfür sind:
• die Berücksichtigung der Projekt-/Modellierungsziele,

• die Berücksichtigung der Grundsätze ordnungsmäßiger Modellierung,
• ein verständlicher Inhalt der Richtlinien und handhabbarer Umfang sowie
• die Durchführung einer Qualitätssicherung gemäß den Richtlinien (vgl. Abschn. 5.6).
5.6 Qualitätssicherung von Geschäftsprozessmodellen
Die Prüfung der Gestaltungs- und Modellierungsrichtlinien ist in der Praxis häufig in
ein Freigabeverfahren für Prozessmodelle eingebettet.
Ein typisches Freigabeverfahren besteht neben einer fachlichen Qualitätssicherung aus
einer methodischen Qualitätssicherung. Die methodische Qualitätssicherung überprüft
die Einhaltung der organisationsspezifischen Gestaltungs- und Modellierungsrichtlinien
und die fachliche Qualitätssicherung die fachliche Vollständigkeit und Korrektheit
der erstellten Modelle. Darüber hinaus wird in einem Freigabeverfahren die Prozess
verantwortung dokumentiert.
Bei der methodischen Qualitätssicherung ist eine Werkzeugunterstützung durch ein
Prozessmanagement-Werkzeug sinnvoll, um z. B.
• die korrekte Verwendung der Objekte und Konnektoren zu prüfen,

• Auswertungen/Analysen zur Prüfung auf Vollständigkeit (z. B. Pflichtfelder), auf
Einhaltung von Namenskonventionen, auf Gültigkeit der Abhängigkeiten/Verknüp
fungen zwischen den Modellen etc. durchzuführen,
• eine mögliche Prozess-Checkliste, bspw. mittels vordefinierter Abfragen, effizient
durchgehen zu können,
• Modellvergleiche zur Identifikation von Änderungen durchzuführen,
Tab. 5.2 Vorgehensschritte und Verantwortlichkeiten

Nr. Vorgehensschritte Beteiligte Rollen
1. Erstellung und Weiterentwicklung Prozessberater sowie Freigabe durch Methoden-
der Gestaltungs- und Modellierungs experte
richtlinien
2. Anwendung der Gestaltungs- und Prozessexperte als Modellierer
Modellierungsrichtlinien
3. Methodische Qualitätssicherung Prozessberater
4. Fachliche Qualitätssicherung Prozessverantwortlicher bzw. Teilverantwortliche
im Fachbereich als Gestalter der Prozesse, z. B. der
Schnittstellen
• verschiedene Sichten/Varianten auf das Modell zu erhalten oder

• eine Qualitätssicherung und Freigabe von Modellen vornehmen zu können.
Eine Qualitätssicherung in einem größeren Rahmen wird Prozessaudit genannt. Hier steht
nicht die Prüfung gegenüber Gestaltungs- und Modellierungsrichtlinien im Vordergrund,
sondern ein Audit der Prozesse des Unternehmens bzw. eines Bereichs für ein bestimmtes
Einsatzgebiet.
Ein Beispiel hierfür ist eine Prüfung der modellierten Prozesse, ob Detaillierungsgrad
und modellierte Inhalte für ein Risikomanagement geeignet sind und die Identifikation
der ggf. noch zu erhebenden Inhalte. Ein weiteres Beispiel ist eine Prüfung der Prozesse
auf ihre Verwendung für eine Prozessoptimierung mittels Simulation.
Da für ein Prozessaudit ein umfangreiches, übergreifendes Wissen benötigt wird und
das Audit idealerweise von einer neutralen Instanz durchgeführt werden soll, werden
dazu häufig externe Experten eingebunden.
5.7 Vorgehensschritte und Verantwortlichkeiten
Basierend auf den bisherigen Ausführungen kann die Umsetzung der Gestaltungs- und
Modellierungsrichtlinien im Kontext der Prozessmodellierung in die in Tab. 5.2 darge-
stellten Vorgehensschritte und Verantwortlichkeiten gegliedert werden.
Literatur
Bank for International Settlements (2010) Basel III: International framework for liquidity risk mea-
surement, standards and monitoring, Arbeitsbericht, Basel. http://www.bis.org/publ/bcbs188.
pdf. Zugegriffen: 07. Jan 2013
Bayer F, Junginger S, Kühn H (1999) Concurrent Engineering of Service Products, Business
Processes and Organizational Structure. In: Proceedings of the 6th European Concurrent
Engineering Conference 1999 (ECEC’99), Society for Computer Simulation (SCS), Erlangen,
Nürnberg, S 157–162
Becker J, Rosemann M, Schütte R (1995) Grundsätze ordnungsmäßiger Modellierung. Wirtschafts

informatik 37(5):435–445
Deutsche Bundesbank (2010) Mindestanforderungen an das Risikomanagement – MaRisk,
Rundschreiben, 11/2010, Frankfurt. http://www.bundesbank.de/Redaktion/DE/Downloads/
Kerngeschaeftsfelder/Bankenaufsicht/Marisk/2010_12_15_rundschreiben_mindestanforderunge
n_risikomanagement.pdf?__blob=publicationFile. Zugegriffen: 07. Jan 2013
International Organization for Standardization (ISO) (2005) Quality management systems --
Fundamentals and vocabulary, Arbeitsbericht, ISO 9000:2005, Genf. http://www.iso.org/iso/home/
store/catalogue_ics/catalogue_detail_ics.htm?csnumber=42180. Zugegriffen: 13. Jan 2013
Junginger S, Kühn H, Bartl F, Herbst J (1998) Evaluation of Financial Service Organizations with
the ADONIS* Simulation Agents. In: Proceedings of the 10th European Simulation Symposium
(ESS’98). Society for Computer Simulation (SCS), Nottingham
Karagiannis D (1995) BPMS: Business Process Management Systems. ACM SIGOIS Bull
16(1):10–13
Keller G, Nüttgens M, Scheer A-W (1992) Semantische Prozeßmodellierung auf der Grundlage
„Ereignisgesteuerter Prozeßketten (EPK)”. In: Scheer A-W (Hrsg) Veröffentlichungen des
Instituts für Wirtschaftsinformatik (IWi), Universtität des Saarlandes, Heft 89, Saarbrücken.
http://www.wiso.uni-hamburg.de/fileadmin/wiso_fs_wi/Team/Mitarbeiter/Prof._Dr._
Markus_Nuettgens/Publikationen/heft089.pdf. Zugegriffen: 07. Jan 2013
Object Management Group (OMG) (2011) Business Process Model and Notation (BPMN) Version
2.0, Dokumentation, OMG Document Number: formal/2011-01-03. http://www.omg.org/spec/
BPMN/2.0/PDF. Zugegriffen: 13. Jan 2013
BPMN als Bestandteil der BPMS-
Modellierungsmethode 6
Marion Murzek, Tobias Rausch und Harald Kühn
Zusammenfassung
Die Business Process Model and Notation (BPMN) bietet Modellierungselemente für die
Abbildung vorwiegend technischer Prozessabläufe und Kollaborationen. Im Gegensatz
dazu unterstützt die BPMS-Modellierungsmethode die Abbildung von vorwiegend fach-
lichen Unternehmensinhalten in den vier Kernbereichen Geschäftsprozesse, Produkte,
Organisation und Informationstechnologie. Durch die zunehmende Verbreitung der
BPMN wurde die BPMN 2.0 mit ihren drei Diagrammtypen Geschäftsprozessdiagramm,
Choreographiediagramm sowie Konversationsdiagramm in die BPMS-Modellierungs
methode integriert. Durch diese Integration ergeben sich zwei Vorteile: Einerseits wird
die BPMS-Modellierungsmethode um Modelltypen für die Darstellung von Konver
sationen, Kollaborationen und Choreographien ergänzt. Dies ermöglicht bspw. die
Modellierung ausführungsrelevanter, technischer Aspekte. Andererseits wird durch
die fachlichen Elemente der BPMS-Modellierungsmethode die technisch orientierte
BPMN für die Nutzung in Fachbereichen/-abteilungen einsetzbar gemacht. Das Kapitel
gibt einen Überblick zur BPMS-Modellierungsmethode und beschreibt detailliert die
Integration der BPMN 2.0-Diagrammtypen in die BPMS-Modellierungsmethode. Ein
Best Practice-Beispiel veranschaulicht den Einsatz der so entstandenen integrierten
Modellierungsmethode.
M. Murzek
T. Rausch (*) · H. Kühn
e-mail: tobias.rausch@boc-group.com

94 M. Murzek et al.
6.1 Motivation
Die Erhebung und Beschreibung von Prozessen in Form von Modellen findet in der
PMLC-Phase Prozessdokumentation statt (vgl. Abschn. 2.4.2). Als Bestandteil des
BPMS-Rahmenwerks (Karagiannis 1995; Karagiannis et al. 1996) bietet die BPMS-
Modellierungsmethode Unterstützung zur Abbildung von Unternehmensinhalten in
den vier Kernbereichen Geschäftsprozesse, Produkte, Organisation und Informations
technologie (vgl. Abb. 6.1).
Die BPMS-Modellierungsmethode besteht aus verschiedenen Modelltypen (vgl.
Abb. 6.2). Die damit zur Verfügung gestellten Modellierungselemente helfen dabei, die
Unternehmensinhalte in den vier Kernbereichen integriert und grafisch darzustellen.
Der in Abschn. 6.3 beschriebene Modellierungsstandard Business Process Model
and Notation (BPMN) Version 2.0 (Object Management Group (OMG) 2011a) bietet
Modellierungselemente für die Abbildung vorwiegend technischer Prozessabläufe und
Kollaborationen. Er ist somit dem Kernbereich Geschäftsprozesse und teilweise dem
Bereich Informationstechnologie zuordenbar. Durch die Standardisierung und die zuneh-
mende Verbreitung der BPMN wurde die BPMN 2.0 mit ihren drei Diagrammtypen in die
BPMS-Modellierungsmethode integriert (vgl. Abschn. 6.4). Zu diesen drei Diagrammtypen
zählen das Geschäftsprozessdiagramm, das Choreographiediagramm sowie das Konver
sationsdiagramm. Das BPMN 2.0-Geschäftsprozessdiagramm kann alternativ zum BPMS-
Modelltyp Geschäftsprozessmodell verwendet werden.
Durch die Einbettung der BPMN 2.0-Diagrammtypen in die BPMS-Modellierungs
methode ergeben sich zwei Vorteile. Einerseits wird die BPMS-Modellierungsmethode im
Produkte
Geschäfts- Organisations-
prozesse einheiten
Informations-
technologie
Abb. 6.1 Übersicht über die vier Kernbereiche des BPMS-Rahmenwerks (Junginger et al. 1998;
Bayer et al. 1999)
6 BPMN als Bestandteil der BPMS-Modellierungsmethode 95
Kernbereich Geschäftsprozesse um Modelltypen für die Darstellung von Konversationen,

Kollaborationen und Choreographien ergänzt (vgl. Abschn. 6.4). Dies ermöglicht bspw.
die Modellierung ausführungsrelevanter, technischer Aspekte. Andererseits wird durch die
fachlichen Elemente der BPMS-Modellierungsmethode die technisch orientierte BPMN
für die Nutzung in Fachbereichen/-abteilungen einsetzbar gemacht. BPMN wird damit
auch für die folgenden typischen fachlichen Einsatzszenarien nutzbar:
• Organisationsanalyse,
• Arbeitsanweisungen,
• Aufbau und Pflege eines Internen Kontrollsystems (IKS)/Risikomanagements,
• Prozesskostenrechnung sowie Simulation,
• Personalbedarfsplanung und
• Testfall-Management.
Die folgenden Abschnitte erläutern detailliert die Integration der BPMN 2.0-Diagrammtypen
in die BPMS-Modellierungsmethode. Den Abschluss bildet die Beschreibung eines Best
Practice-Einsatzes der BPMS-Modellierungsmethode inkl. der eingebetteten BPMN 2.0. Der
Schwerpunkt liegt dabei auf der Verwendung der durch die BPMN 2.0 hinzugekommenen
Modelltypen.
6.2 Die BPMS-Modellierungsmethode
Das zentrale Element der Modellierung ist ein Modelltyp. Ein Modelltyp gruppiert eine
Menge von Klassen, die zur Abbildung eines bestimmten Sachverhalts/Bereichs verwen-
det werden. Jeder der vier Kernbereiche wird durch einen oder mehrere Modelltypen
unterstützt.
Abbildung 6.2 gibt eine Übersicht über die Modelltypen der BPMS-Modellierungs
methode. Im Zentrum steht dabei das Geschäftsprozessmodell, welches zur Abbildung
von unternehmensinternen als auch -übergreifenden Prozessen eingesetzt wird. Der
Kernbereich Geschäftsprozesse umfasst zusätzlich den Modelltyp Prozesslandkarte.
Der Modelltyp Arbeitsumgebungsmodell ist dem Kernbereich Organisationseinheiten
zuzurechnen. Der Kernbereich Informationstechnologie wird durch die Modelltypen IT-
Systemmodell und Datenmodell unterstützt. Die Modelltypen Dokumentenmodell und
Ressourcenmodell unterstützen die Modellierung sowohl im Bereich Organisation als
auch im Bereich Informationstechnologie. Den Bereich Produkte deckt der Modelltyp
Produktmodell ab.
Eine Erweiterung der vier Kernbereiche stellen die Modelltypen Risiko-Katalog und
der dazugehörige Kontrollen-Katalog dar, die den Aktivitäten in den Geschäftsprozessen
zugeordnet werden können.
Für welche Fragestellung welcher Modelltyp herangezogen werden kann bzw. wie
diese untereinander verknüpft sind, wird in den nächsten Abschnitten erläutert.
96 M. Murzek et al.
Prozesslandkarte Risiko-Katalog Kontrollen -Katalog Arbeitsumgebungsmodell
C C
C C
R R
Geschäftsprozessmodell
Ze
Ze
Ze
Ze
Produktmodell IT-Systemmodell Dokumentenmodell Datenmodell
Abb. 6.2 Übersicht über die Modelltypen der BPMS-Modellierungsmethode
6.2.1 Prozesslandkarte und Produktmodell
Die Prozesslandkarte dient zur Gruppierung und Hierarchisierung von Geschäftspro

zessen (vgl. ebenso Kap. 3). Werden die unterschiedlichen Hierarchieebenen untereinan-
der verknüpft, stellt die Prozesslandkarte eine Art Navigationsbaum dar. Die Fragen, die
der Modelltyp Prozesslandkarte zu beantworten hilft, sind demnach: „Welche Prozesse
können im Unternehmen identifiziert werden?“ und „Wie stehen diese Prozesse zuein-
ander in Beziehung?“.
Produktmodelle stellen eine Sammlung von Produkten und ihrer Komponenten
dar. Produkte haben in der Regel einen wesentlichen Einfluss auf die Strukturierung
der Prozesse (sowohl auf Ebene der Prozesslandkarte als auch auf Ebene der
Geschäftsprozessmodelle). Produkte werden über die Geschäftsprozesse durch die
Personalressourcen in den Organisationseinheiten und den Einsatz der Informations
technologie entwickelt. Die zentralen Fragen hierzu sind: „Welche Produkte gibt es im
Unternehmen?“, „Aus welchen Komponenten bestehen diese Produkte?“ bzw. „Wie ste-
hen die Produkte zueinander in Beziehung?“.
Durch die Verknüpfung von Produkten mit Prozessen wird darüber hinaus die Frage
„Welche Prozesse sind für die Erstellung welcher Produkte notwendig?“ beantwortet. Im
Detail kann zusätzlich unterschieden werden, welche Prozesse direkt an der Entstehung
eines Produkts beteiligt sind und welche Prozesse als Unterstützungsprozesse gesehen
werden können.
6.2.2 Ablauforganisation – Prozesse
Zur Modellierung der Ablauforganisation wird in der BPMS-Modellierungsmethode

der Modelltyp Geschäftsprozessmodell verwendet. Ein Geschäftsprozess setzt sich pri-
mär aus einer Folge von atomaren Aktivitäten zusammen. Neben den Ablaufelementen
Prozessstart und Prozessende ermöglichen weitere Ablaufelemente, wie z. B. Entscheidung
oder Parallelität, auch nicht-sequentielle Abläufe übersichtlich darzustellen. Die zentrale
Frage, die hiermit beantwortet werden kann, ist: „In welcher Reihenfolge müssen welche
Aktivitäten im Rahmen des Prozesses ausgeführt werden, um das Prozessziel zu erreichen?“.
Neben einer Bezeichnung und einer Beschreibung können einer Aktivität zusätzliche
Eigenschaften und Elemente – auch aus anderen Modelltypen – zugeordnet werden, wie z. B.
Input- und Output-Dokumente, verantwortliche Rollen, mögliche Risiken und Kontrollen,
benötigte IT-Systeme und Ressourcen, unterstützte Ziele oder zugeordnete Produkte.
Schwimmbahnen erlauben die Visualisierung des Prozesses durch verschiedene Einheiten,
z. B. die Abteilungen eines Unternehmens. Prozessaufrufe bieten die Möglichkeit, Prozesse
in Sub- oder Teilprozesse zu organisieren. Dies hat den Vorteil, dass Sub- oder Teilprozesse
von verschiedenen Geschäftsprozessmodellen referenziert werden können, aber nur einmal
modelliert werden müssen (vgl. ebenso Abschn. 5.3.2).
Zusätzlich zu den Schwimmbahnen und Ablaufobjekten bietet das Geschäftsprozess
modell die Klassen Variable und Variablenbelegung, um komplexe Übergangsbedingungen
im Modell zu definieren; die Klassen Kennzahl und Kennzahlenübersicht, um prozessbezo-
gene Kennzahlen abzubilden sowie die Klasse Ressource, welche dazu verwendet wird, um
Ressourcen, wie z. B. EDV-Systeme oder Kommunikationsmittel, darzustellen.
6.2.3 Aufbauorganisation
Ein weiteres Kernelement der BPMS-Modellierungsmethode ist das Arbeitsumgebungs

modell. Mittels Arbeitsumgebungsmodellen können zwei wesentliche Informationen
abgebildet werden:
• Modellierung von Organigrammen

Darstellung der Organisationsstrukturen in einem Unternehmen, ausgehend von der
ersten Ebene bis zu Sparten-, Bereichs- oder Abteilungsorganigrammen.
• Modellierung von Rollenmodellen
Modellierung und Dokumentation der notwendigen Rollen (Aufgabenträger), der
Zugehörigkeit von Bearbeitern und Anbindung an Organisationseinheiten.
98 M. Murzek et al.
Durch das Abbilden der Aufbauorganisation wird transparent, welche Organisations

einheiten/Rollen im Unternehmen existieren, welche Personen den jeweiligen Abteilungen
zugeordnet sind und welche Rollen sie bekleiden.
6.2.4 IT, Dokumente und Ressourcen
Der Modelltyp IT-Systemmodell bietet die Möglichkeit, Anwendungen, Services und

deren Schnittstellen zu dokumentieren. Sowohl Anwendungen als auch Services können
bei Bedarf hierarchisch aufgebaut werden. Auf der Ebene der Schnittstellen ist es zusätz-
lich möglich, auch die verwendeten technischen Operationen zu modellieren.
In erster Linie wird dadurch beantwortet, welche Anwendungen/Services im Unter
nehmen existieren, wie diese strukturiert sind und welche Schnittstellen sie anbie-
ten/verwenden. Auf der Detailebene einer Anwendung/eines Service ist es darüber
hinaus möglich zu erfassen, welcher Input/Output erwartet/produziert wird, welche
Organisationseinheiten, Personen oder Rollen die Anwendung/den Service verwenden
bzw. wer dafür verantwortlich ist.
Anwendungsfälle (engl. Use Cases) beschreiben das typische Nutzungs- und Inter
aktionsverhalten von Akteuren mit IT-Systemen. Dies kann über den Modelltyp Anwen
dungsfalldiagramm abgebildet werden.
Für das Modellieren von Informationsobjekten, wie z. B. Dokumenten, eignet sich der
Modelltyp Dokumentenmodell. Die Dokumente können hier ebenso aufgelistet, aber auch
hierarchisch abgebildet werden. Wiederum kann hier im Detail festgehalten werden, wel-
che Dokumente im Unternehmen existieren und wer für welches Dokument verantwort-
lich ist. Darüber hinaus können einem Dokument Daten aus dem Datenmodell zugeordnet
werden.
Zusätzlich können über den Modelltyp Ressourcenmodell u. a. die Elemente Betriebs
mittel, Prüf- und Messmittel, Know-how und Materialien abgebildet werden.
6.2.5 Risiken und Kontrollen
Durch die Beschreibung von Risiken und Kontrollen in Verbindung mit den anderen
Modelltypen wird die Modellierung auf den Gebieten Governance, Risk & Compliance
(GRC) ermöglicht. Die Modelltypen Risiko-Katalog und Kontrollen-Katalog unterstützen
die Dokumentation des Internen Kontrollsystems (IKS). Hier liegen die Schwerpunkte
vor allem auf der Erfassung, Analyse und Auswertung der Risiken und Kontrollen im
Unternehmen.
Risiken stellen Ereignisse oder Entwicklungen dar, die das Erreichen der gesetzten
Ziele negativ beeinflussen oder unmöglich machen. Die Charakterisierung eines Risikos
wird durch die Dimensionen Auswirkung und Fehlerhäufigkeit vorgenommen. Neben
der Bezeichnung und der Beschreibung ist es möglich, einem Risiko eine oder mehrere
Kontrollen zuzuordnen, welche das Eintreten des Risikos verhindern oder zumindest
minimieren sollen.
Kontrollen sind Regeln und Prozeduren, die sicherstellen, dass die Risikobewältigungs-
Maßnahmen durchgeführt werden, die im Rahmen des Risikomanagements definiert
wurden. Diese Kontrollen finden in allen Unternehmensbereichen und Funktionen
Anwendung. Darüber hinaus dienen diese Kontrollen der Überwachung der erwarteten
Entwicklung der Kennwerte eines Risikos (Auswirkung, Fehlerhäufigkeit) aufgrund der
getroffenen Maßnahmen. Kontrollen beinhalten eine Reihe verschiedener Aktivitäten, wie
z. B. Freigabe, Autorisierung, Verifikation, Abstimmung oder die Überprüfung der opera-
tiven Leistung.
6.3 BPMN 2.0
Die Business Process Model and Notation (BPMN) ist ein Industriestandard der Object
Management Group (OMG) (2011a; Freund und Rücker 2012). Die BPMN bietet Konzepte
und konkrete, grafische Notationen für die Modellierung von Prozessen, Kollaborationen
und Choreographien für Unternehmen, unabhängig von deren Branche.
6.3.1 Übersicht und Zielsetzung
Die Business Process Modelling Notation – heute Business Process Model and Notation –
wurde von Stephen A. White (IBM) erstmals spezifiziert und später (2006) von der Business
Process Management Initiative (BPMI) veröffentlicht. Im Juni 2005 wurde die BPMN von
der OMG übernommen und nach den BPMN-Versionen 1.0 und 1.2 ist die 2011 von der
OMG verabschiedete Version BPMN 2.0 die aktuell gültige Version.
Laut der OMG ist es das primäre Ziel, „eine Notation zur Verfügung zu stellen, die vom
Business Analysten (zuständig für die Erstellung des initialen Prozessdrafts) bis zum technischen
Entwickler (zuständig für die Umsetzung des Prozesses mittels Ausführungstechnologien) und bis
hin zu den Führungskräften/Prozessverantwortlichen, die die Prozesse managen und monitoren,
verstanden werden soll“ (aus dem Englischen, Object Management Group (OMG) 2011a, S. 1).
Das zweite wichtige Ziel der BPMN ist es, dass XML-basierte Ausführungssprachen, wie zum
Beispiel BPEL, visualisiert werden können (Object Management Group (OMG) 2011a, S. 1).
Diese Zielsetzungen spannen ein sehr weites Feld auf und lassen entsprechende
Spielräume für Interpretation. Tatsache ist in jedem Fall, dass die BPMN ein Ansatz zur
Standardisierung einer Notation zur Prozessabbildung ist und zudem Formate definiert,
über die ein Modellaustausch über Werkzeuggrenzen hinweg möglich sein soll. Zudem
bietet BPMN durch ihre starke Formalisierung und die definierten Möglichkeiten zur
XML-Serialisierung die Möglichkeit, Prozessmodelle leicht(er) in Umgebungen zur
Ausführung der Prozesse zu übernehmen.
100 M. Murzek et al.
6.3.2 Stärken und Schwächen
Neben der schon erwähnten Standardisierung und Formalisierung liegen die Stärken
der BPMN in der Modellierung vor allem darin, Prozesse über Unternehmensgrenzen
hinweg zusammen mit den wesentlichen Teilnehmern (Kollaborateuren) und der statt-
findenden Kollaboration/Interaktion abbilden zu können. Hierfür bietet BPMN explizite
Konzepte an, wie zum Beispiel die Abbildung unterschiedlicher Teilnehmer in soge-
nannten Pools und die Darstellung von Nachrichtenflüssen zwischen den Teilnehmern.
BPMN 2.0 bietet dahingehend neue, ergänzende bzw. teilweise auch alternative
Konzepte mit den neuen Konversations- und Choreographiediagrammen. Diese fokus-
sieren auf den Nachrichtenaustausch und die Haupt-Interaktionen zwischen den ver-
schiedenen Teilnehmern.
Zudem beinhaltet die BPMN eine stark formalisierte Menge an Modellierungselementen,
die es erlauben, für eine spätere technische Ausführung verschiedenste Arten von Ereignissen
(Nachricht, Eskalation etc.) sowie Ausnahmebehandlungen und Kompensationen zu
modellieren.
Gerade diese große Menge an Elementen ist auch einer der Hauptkritikpunkte an
der BPMN, neben ihrer noch immer sehr starken Fokussierung auf die technische
Ausführung von Prozessen.
Im Detail liegen die Hauptkritikpunkte und Schwächen der BPMN in den folgenden
Punkten:
• Der Fokus der BPMN als Modellierungssprache liegt nach wie vor auf der automatisier-
ten Ausführung von Prozessen. Die Elemente und Attribute, die die BPMN-Spezifikation
vorsieht, sind in erster Linie entworfen worden, um einen Prozess technisch ausführen
zu können (mittels Workflow-Systemen, Web Service-Orchestrierung etc.). Andererseits
fehlen in der Spezifikation die für fachliche Anwender und ihre Szenarien benötigten
Elemente und Attribute (Silver 2009; Object Management Group (OMG) 2011a; Lichka
et al. 2012; Rausch et al. 2012).
• Ein weiterer Kritikpunkt ist, dass die BPMN ihre eigene Zielsetzung, eine Sprache
und Notation für alle Bereiche im Unternehmen zu sein, nicht erfüllt („BPMN stands
for ‚Business People May Not…understand‘“ (Sinur 2010) oder auch „BPMN 2.0: no
longer for Business Professionals“ (Swenson 2010)). BPMN bietet wenige fachliche
Modellierungselemente. Beispielsweise fehlen Elemente für Organisationsstrukturen,
Risiken, Kontrollen oder Produkte.
• Darüber hinaus beinhaltet BPMN mehr als 60 Ereignistypen sowie weit über 150 ver-
schiedene Ausprägungen von Modellierungselementen. Zusätzlich enthält sie z. B.
unterschiedlichste Arten von logischen Konnektoren. Alles in allem ein Ausmaß, das
selbst geübte Anwender überfrachtet und die Sprache und Notation nicht gerade leicht
erlernbar macht. Für eine detaillierte Analyse wird auf (Genon et al. 2010) verwiesen.
• Die große Anzahl an Modellierungselementen wird zudem noch verschärft durch
die Tatsache, dass sich die Objektausprägungen auf den ersten Blick optisch nur
Kompensation
Terminierung
Bedingung
Eskalation
Nachricht
Mehrfach
Kein Typ
Abbruch
Parallel
Fehler
Signal
Link
Zeit
Top-Level
Startereignisse
Ereignis
Teilprozess
(unterbrechend)
Ereignis
Teilprozess (nicht
unterbrechend)
Sequenzfluss
(eintretend)
Zwischenereignisse
Sequenz-
fluss
(auslösend)
angeheftet
(unterbrechend)
angeheftet (nicht-
unterbrechend)
eignisse
End-
er-
Abb. 6.3 Übersicht der BPMN-Ereignisse (Object Management Group (OMG) 2011a, S. 261)
wenig voneinander unterscheiden. Dies ist zum Beispiel beim Element Ereignis der
Fall, welches prinzipiell durch einen Kreis symbolisiert wird. Die BPMN unterschei-
det dann jedoch weiter mittels einfachen, fetten und doppelten Linien zwischen
Startereignissen, Zwischenereignissen und Endereignissen sowie mittels durchgezoge-
nen bzw. unterbrochenen Linien zwischen unterbrechenden und nicht-unterbrechen-
den Ereignissen (vgl. Abb. 6.3).
6.4 Einbettung der BPMN 2.0 in die BPMS-

Modellierungsmethode
Dieser Abschnitt beschreibt unseren Ansatz, BPMN 2.0 in die BPMS-Modellierungsmethode

einzubetten. Im Wesentlichen lassen sich zwei verschiedene Arten unterscheiden, die ergän-
zend durchgeführt werden:
• Einerseits erfolgt die Aufnahme der BPMN-Klassen in die BPMS-Modellierungs

methode in Form von drei neuen Modelltypen: dem Geschäftsprozessdiagramm,
dem Choreographiediagramm und dem Konversationsdiagramm. Dies ermöglicht
die erweiterte Modellierung technischer Aspekte in der Prozessmodellierung und die
Abbildung von Kollaborationen in der BPMS-Modellierungsmethode.
• Andererseits werden die neuen BPMN-Klassen mit den relevanten BPMS-Attributen
angereichert, um die Referenzierung bestehender Klassen der BPMS-Modellierungs
methode (wie z. B. Produkte, Risiken oder Kontrollen) zu ermöglichen. Dies stellt
eine fachliche Erweiterung der BPMN 2.0 dar und macht diese somit für fachliche
Anwender umfangreicher nutzbar.
Abbildung 6.4 zeigt, wie die Diagrammtypen der BPMN 2.0 in die BPMS-Model
lierungsmethode und somit in die Modelltypen der vier Kernbereiche des Geschäfts
prozessmanagements integriert werden. Dadurch entsteht eine Umgebung für eine
vollumfängliche Geschäftsprozessmodellierung und -analyse (Zivkovic et al. 2007; Kühn
et al. 2010). Da in Abb. 6.4 die Einbettung der Elemente der BPMN 2.0 im Vordergrund
steht, wurden die Elemente des Modelltyps Geschäftsprozessmodell, die sich mit
den Ablaufelementen der BPMN 2.0 überschneiden, der Übersichtlichkeit halber,
weggelassen.
Darüber hinaus sind in der Abbildung die Zusammenhänge zwischen allen Elementen –
sowohl der BPMN-Klassen als auch der BPMS-Klassen – ersichtlich. Ohne im Detail auf
alle Zusammenhänge einzugehen, seien die folgenden hervorgehoben und kurz erläutert:
• Eine Prozesslandkarte ist ein wesentliches und unabdingbares Strukturierungsmedium
im Rahmen der Prozessdokumentation (vgl. Kap. 3). Durch sie wird das zu unter-
suchende Feld strukturiert, ein gemeinsames Verständnis geschaffen und eine
Priorisierung/ein Scoping vorgenommen. Zudem können bereits auf dieser Ebene
(Prozess-)Verantwortungen definiert, Schnittstellen und Service-Level abgestimmt
und nicht zuletzt ein klares Bild des End-to-End-Prozesses gezeichnet werden.
Durch die Integration besteht die Möglichkeit, in einer Prozesslandkarte BPMN-
Prozessabläufe zu referenzieren.
• Zur Abbildung der Produkte und als möglichen alternativen Einstieg in die Prozesswelt
kann zudem ein Produktkatalog erstellt und mit den Geschäftsprozessdiagrammen
in Bezug gesetzt werden. Damit entsteht ein klares Bild der Zusammenhänge und
Abhängigkeiten zwischen Produkten und Prozessen (Produkt-Prozess-Matrix).
• Auf der Ebene der Prozessabläufe selbst sind insbesondere die folgenden Erweiterungen
und Beziehungen hervorzuheben:
– Im Startereignis können Prozessverantwortliche, Produkte und IT-Applikationen hin-
terlegt werden, um zumindest die vier Kernbereiche des Geschäftsprozessmanagements
abzubilden (vgl. Abschn. 6.2). Darüber hinaus können kritische Erfolgsfaktoren und
Prozesskennzahlen referenziert werden, um die Beziehung zu Zielen und der Strategie
herzustellen und entsprechende Prozessreifegrade sowie das Prozess-Performance-
Management zu unterstützen.
6
Prozesslandkarte Produktmodell Dokumentenmodell Datenmodell Anwendungsfalldiagramm

Input Komponente Entität Anwendungsfall
Prozess Dokument
Output Produkt Attribut Akteur
BPMN 2.0-Modelltypen in der

BPMS-Modellierungsmethode Pool 3
Assoziation
Artefakt Bahn
1
Nachrichten- Konversations-
Textanmerkung Gruppierung Ablaufelement Nachricht
fluss link
Sequenz-
Kennzahlen- fluss Konversations-
Datenobjekt Ablaufknoten
übersicht Daten- knoten
assoziation
Choreographie- Teil-
Kennzahl Aktivität Gateway Ereignis Konversation
aktivität konversation
2
Variablen- Choreographie- Teil-

BPMN als Bestandteil der BPMS-Modellierungsmethode
Aufgabe Teilprozess 1 Geschäftsprozessdiagramm

belegung aufgabe choreographie
2 Choreographiediagramm
Variable
3 Konversationsdiagramm
: BPMN 2.0-Klasse
Rolle IT-Service Anwendung : BPMS-Klasse
Organisations- Risiko Kontrolle : Intra-Modellreferenz
Person Operation Schnittstelle
einheit : Inter-Modellreferenz
Arbeitsumgebungsmodell Risiko-Katalog Kontrollen-Katalog IT-Systemmodell
Abb. 6.4 Die BPMS-Modellierungsmethode mit BPMN 2.0 für die Prozessmodellierung
103
– Die Modellierungsklasse Aufgabe bietet die Möglichkeit, Verantwortlichkeiten, insbe-

sondere auch unter Nutzung des DEMI-/RACI-Konzepts, welches die verantwortlichen
Rollen für Durchführung, Ergebnis, Mitarbeit und zu Informieren definiert, zu refe-
renzieren (vgl. Abschn. 5.3.1). Neben Risiken und Kontrollen für die Dokumentation
und den Nachweis eines Internen Kontrollsystems können IT-Anwendungen, die zur
Durchführung einer Aufgabe benötigt werden, hinterlegt werden. Referenzen zu Anwen
dungsfällen, die weiteren Input für das Systemdesign liefern und es später ermöglichen,
die Anforderungen zum Geschäftsprozess zurückzuverfolgen, runden das Bild ab.
• Das Kernelement IT ist in verschiedene Modellierungskonzepte unterteilt worden. Im
IT-Systemmodell können ein IT-Servicekatalog und eine IT-Anwendungslandschaft
abgebildet werden, insbesondere auch im Hinblick auf eine weitere Entwicklung von
serviceorientierten Architekturen (SOA). Zudem können mit diesem Modelltyp Schnitt
stellen zwischen Anwendungen und Services sowie Infrastrukturelementen, z. B. als Basis
für das Unternehmensarchitektur-Management (vgl. Kap. 16), dokumentiert werden.
• Mit dem Dokumentenmodell kann ein Dokumentenkatalog/-repository aufgebaut
werden. Dokumente werden als Inputs und Outputs in Prozessen benutzt, sie können
Formulare bzw. Templates sein und ebenso Richtlinien und Anweisungen darstellen,
die während der Prozessdurchführung zu beachten sind.
• IT-Systeme und Dokumente können wiederum selbst mit dem Datenmodell verbun-
den werden, um so zu definieren, welche Entitäten von Anwendungen verarbeitet
bzw. welche Attribute auf Formularen benötigt werden.
• Zu guter Letzt bietet das Anwendungsfalldiagramm eine Möglichkeit, fachliche
Anforderungen für eine IT-technische Umsetzung weiter zu detaillieren und Input
für ein nachfolgendes Systemdesign zu liefern. Das Anwendungsfalldiagramm
wurde hierbei der Unified Modelling Language (UML) (Object Management Group
(OMG) 2011b), einem weiteren OMG-Standard, entlehnt. Je nach Zielsetzung ist
es selbstverständlich möglich, weitere UML-Stereotypen wie Klassen-, Sequenz-,
Zustandsdiagramme etc. für das Systemdesign einzubetten und heranzuziehen.
Nach der Integration der BPMN in die BPMS-Modellierungsmethode zeigen wir in

Abschn. 6.5 mögliche Einsatzszenarien dieser integrierten Sprache. Dabei wird insbe-
sondere auf die bisher wenig betrachteten neuen Diagrammtypen zur Darstellung von
Konversationen/Kommunikationen und Choreographien eingegangen.
6.5 Best Practice-Einsatz der BPMS-Modellierungsmethode

mit BPMN 2.0
Die in Abschn. 6.2 beschriebenen Modelltypen der BPMS-Modellierungsmethode bieten

die Möglichkeit, Prozesse und verwendete Ressourcen in Modellen mit unterschiedli-
chem Detailgrad abzubilden. Der Schwerpunkt liegt hierbei auf Prozessstrukturen und
Ressourcen. Im Gegensatz dazu liegt der Schwerpunkt der BPMN 2.0-Diagrammtypen
auf der Modellierung von Interaktionen zwischen Teilnehmern und/oder Prozessen auf
verschiedenen Detailebenen (Allweyer 2009).
Die Integration der BPMN 2.0 in die BPMS-Modellierungsmethode macht es mög-
lich, sowohl Interaktionen zwischen Partnern/Prozessen als auch die Verknüpfung mit
Ressourcen in Form von Dokumenten, Daten, IT-Systemen, Rollen, Organisationseinheiten,
Risiken und Kontrollen usw. abzubilden.
Nachfolgend ist der Einsatz der in die BPMS-Modellierungsmethode eingebetteten BPMN
2.0-Diagrammtypen anhand eines Beispiels aus dem Bereich Gesundheitswesen beschrieben.
In diesem Beispiel gibt es folgende Teilnehmende: den Patienten, die Krankenhausstation, die
Verwaltungsaufnahme und den Patientenservice/Empfang. Der hier betrachtete Kernprozess
ist die Patientenaufnahme, der sich aus den Teilprozessen Patienteneingang, Stammda
tenerhebung, Planen der Diagnostik und Stationsempfang zusammensetzt.
6.5.1 Darstellung von Kommunikationsflüssen (Konversationen)
Der erste Schritt, um Interaktionen zwischen Partnern abzubilden, ist die Erstellung
eines hierarchisierten Konversationsdiagramms. Konversationsdiagramme dienen zur
Modellierung von Teilnehmern und ihrer Interaktion untereinander. Sie helfen bei der
Klärung der Frage: „Welche Teilnehmer interagieren miteinander?“.
Abbildung 6.5 zeigt die Interaktion der vier Teilnehmer miteinander. Jeder Pool steht
für einen Teilnehmer. Die drei senkrechten Striche im Pool „Patient“ machen deut-
lich, dass es sich um mehrere Patienten handelt, wobei die anderen Beteiligten gleich
bleiben. Bei dem sechseckigen Objekt mit „+“ handelt es sich um ein Objekt der Klasse
Teilkonversation. Diese symbolisiert, dass es zwischen den mit Konversationslink ver-
bundenen Teilnehmern verschiedene Arten der Interaktion gibt.
Abbildung 6.6 zeigt eine verfeinerte Abbildung der Interaktionen. Die Kommuni
kation zwischen den einzelnen Teilnehmern wird jeweils mit einem Konversationsobjekt
abgebildet.
Abb. 6.5 Top-

Level-Konversation
„Patientenaufnahme“ mit vier
Teilnehmern
Abb. 6.6 Teil-Konversation

„Patientenaufnahme“
Eine andere Sicht auf die Interaktion zwischen den Teilnehmern bietet der Dia
grammtyp Choreographiediagramm, der in Abschn. 6.5.2 vorgestellt wird.
6.5.2 Darstellung von Choreographien
Das Choreographiediagramm bietet die Möglichkeit, die Pfade der Interaktion zwischen
zwei oder mehreren Teilnehmern abzubilden.
Zentrale Elemente in diesem Diagrammtyp sind die Choreographie-Aufgabe und die
Teilchoreographie. Mit Hilfe der weiteren Ablaufobjekte können hier neben sequentiellen
auch parallele oder Entscheidungsverläufe modelliert werden. Die Klasse Nachricht dient in
diesem Diagrammtyp dazu, auslösende und nicht-auslösende Nachrichten darzustellen und
zu untermauern, dass bei einer einzelnen Interaktion ein Nachrichtenaustausch stattfindet.
Die zentrale Frage, zu deren Beantwortung Choreographiediagramme herangezogen
werden sollten, ist: „Wer interagiert mit wem in welcher Reihenfolge?“. Abbildung 6.7
zeigt die Interaktionsreihenfolge der Teilnehmer aus dem Beispiel.
Abb. 6.7 Der Prozess

„Patientenaufnahme“ als
Choreographie
6.5.3 Darstellung von Prozessabläufen und Kollaborationen
Auch auf Prozessebene lassen sich mit Hilfe der BPMN 2.0-Diagrammtypen Interaktionen
abbilden. Das BPMN 2.0-Geschäftsprozessdiagramm bietet die Möglichkeit, Prozesse und
Kollaborationen abzubilden. Ähnlich wie im Modelltyp Geschäftsprozessmodell der
BPMS-Modellierungsmethode werden hier atomare Aufgaben und Ablaufobjekte verwen-
det, um die Prozessabläufe eines Unternehmens darzustellen. Zur expliziten Modellierung
von Zuständen, z. B. das Warten auf eine eingehende Nachricht, bietet BPMN 2.0 eine
eigene Klasse Ereignis an.
Die zentrale Frage, die bzgl. der Prozessmodellierung im integrierten BPMN 2.0-
Geschäftsprozessdiagramm beantwortet werden kann, ist: „Welche Aufgaben werden
von wem, in welcher Reihenfolge durchgeführt?“. Durch die Einbettung des BPMN 2.0-
Geschäftsprozessdiagramms in die BPMS-Modellierungsmethode ist es auch möglich,
diesen Diagrammtyp für die Beantwortung der Detailfragen einer Aufgabe (vgl. Aktivität
im Geschäftsprozessmodell) zu verwenden (vgl. Abschn. 6.2.2).
Darüber hinaus kann mit den zur Verfügung stehenden Poolobjekten und
Nachrichtenflüssen dargestellt werden, an welcher Stelle Aufgaben im Prozess mit ande-
ren Teilnehmern bzw. auch mit welchen Aufgaben andere Teilnehmer interagieren.
Abbildung 6.8 zeigt den Prozess „Patientenaufnahme“ als privaten Geschäftsprozess des
Teilnehmers „Verwaltungsaufnahme“ eingebettet in eine Kollaboration mit „Patientenservice/
Empfang“ und der „Station“. Einen privaten Prozess zeichnet aus, dass alle dem Prozess zuge-
hörigen Aufgaben dargestellt werden. Dem gegenüber steht der öffentliche Prozess. Dieser
enthält nur die Aufgaben, die mit den anderen Teilnehmern kommunizieren.
Darüber hinaus sind in einem eigenen Pool die dem Prozess zugehörigen Kennzahlen
abgebildet. Die Klasse Kennzahl steht hier durch die Einbettung von BPMN 2.0 in die
BPMS-Modellierungsmethode zur Verfügung.
Der Prozess beginnt mit der Aufnahme eines Patienten. Nachdem der Teilprozess
„Patienteneingang“ erfolgreich durchgeführt wurde, werden die Patientenunterlagen an
die Verwaltungsaufnahme weitergeleitet.
Das Ereignis „Neue Patientenunterlagen eingetroffen“ löst den Prozess in der
Verwaltungsaufnahme aus. Nach der Stammdatenerhebung, dem Anlegen einer
Patientenmappe oder der Überprüfung der Stammdaten wird noch überprüft, ob eine
Überweisung vorhanden ist. Danach erfolgt das Planen der Diagnostik, hier durch
einen Teilprozess dargestellt. Sind die Unterlagen des Patienten fertig, wird dieser an die
Station weitergeleitet.
In der Krankenhausstation wird der Stationsempfang durch das eintretende Ereignis
„Patient trifft ein“ ausgelöst. Nachdem der Teilprozess „Stationsempfang“ durchlaufen
wurde, endet der Prozess „Patientenaufnahme“.
Abbildung 6.9 zeigt den privaten Teilprozess „Planen der Diagnostik“ mit der
Interaktion mit dem Patienten, welcher in diesem Modell durch einen Black Box-Pool dar-
gestellt ist. Der private Prozess zeigt alle Aufgaben (abgerundete Rechtecke), die in diesem
Prozess enthalten sind, unabhängig davon, ob die Aufgabe mit Partnern kommuniziert
oder nicht. Die Kommunikation zwischen Partnern wird mit Nachrichtenfluss-Relationen
108
Abb. 6.8 Der private Prozess „Patientenaufnahme“ eingebettet in eine Kollaboration

M. Murzek et al.
6
BPMN als Bestandteil der BPMS-Modellierungsmethode
Abb. 6.9 Der private Teilprozess „Planen der Diagnostik“ als Geschäftsprozessdiagramm
109
Abb. 6.10 Der öffentliche Teilprozess „Planen der Diagnostik“ als Geschäftsprozessdiagramm
abgebildet. Die Inter-Prozesskommunikation, z. B. Daten-Inputs/-Outputs aus einzelnen

Aufgaben, wird mit Datenassoziationen und typisierbaren Datenobjekten dargestellt, siehe
„Diagnostikdatenbank“ (Typ: persistenter Speicher) und „Patiententermin“ (Typ: Daten-
Output) im Prozess in Abb. 6.9.
In Abb. 6.10 ist der gleiche Prozess, diesmal als öffentlicher Prozess, dargestellt. Einen
öffentlichen Prozess zeichnet aus, dass nur noch die Aufgaben visualisiert werden, die
an der Interaktion mit anderen Partnern beteiligt sind. Jegliche interne Kommunikation
wird ausgeblendet.
Mit dem in diesem Abschnitt vorgestellten Best Practice-Beispiel aus dem Bereich
Gesundheitswesen wird die Verwendung der BPMN 2.0-Modelltypen in der BPMS-
Modellierungsmethode mit dem Schwerpunkt auf der Interaktion zwischen den
Teilnehmenden demonstriert. Stehen jedoch die Prozesse und nicht die Interaktionen im
Fokus der Betrachtung, empfiehlt sich der Einstieg über den Modelltyp Prozesslandkarte.
Abbildung 6.11 zeigt hierzu die Hierarchie und Abfolge der Prozesse des Beispiels.
Abb. 6.11 Die Übersicht über die Prozesse in einer Prozesslandkarte
Als letztes Modell zeigt Abb. 6.12 das Arbeitsumgebungsmodell „Patientenad

ministration“ aus dem Beispiel Gesundheitswesen. Hier werden die Hierarchie der
Abteilungen „Patientenadministration“, „Patientenservice/Empfang“ und „Verwaltungs
aufnahme“, die mitarbeitenden Pfleger und die Rollen „Pfleger Patientenservice/
Empfang“ und „Pfleger Verwaltungsaufnahme“ dargestellt.
Dieses Modell dient einerseits zur Veranschaulichung der Aufbauorganisation des
Unternehmens. Andererseits wird es damit möglich, in den Prozessen den jeweiligen
Abb. 6.12 Arbeitsumgebungsmodell aus dem Gesundheitsbereich (Beispiel)

Aufgaben Rollen zuzuordnen, die für diese Aufgaben verantwortlich sind, diese durch-
führen oder dabei mitwirken.
Das in diesem Abschnitt beschriebene Best Practice-Beispiel zeigt zwei Verwendungs
möglichkeiten der BPMS-Modellierungsmethode: einmal „interaktionsorientiert“ mit
dem Fokus auf der Interaktion zwischen den Teilnehmenden und einmal „prozessorien-
tiert“ mit den Prozessen im Vordergrund. Damit werden noch einmal die zwei Vorteile
der BPMN 2.0-Einbettung in die BPMS-Modellierungsmethode illustriert. Einerseits wird
die erweiterte BPMS-Modellierungsmethode für die Abbildung von Kollaborationen und
Interaktionen verwendet. Andererseits erfolgt die Verwendung von BPMN 2.0 mit zusätz-
lichen Modelltypen für die Modellierung von Aufbauorganisation, IT-Systemen, Risiken
und Kontrollen, Dokumenten und Ressourcen.
Literatur
Allweyer T (2009) Kollaborationen, Choreographien und Konversationen in BPMN 2.0: Erweiterte

Konzepte zur Modellierung übergreifender Geschäftsprozesse, Arbeitsbericht, Fachhochschule
Kaiserslautern, Fachbereich Informatik und Mikrosystemtechnik, Zweibrücken. http://kurze-
prozesse.de/blog/wp-content/uploads/2009/06/kollaborationen-choreographien-und-konver-
sationen-in-bpmn-20.pdf. Zugegriffen: 07. Jan 2013
Freund J, Rücker B (2012) Praxishandbuch BPMN 2.0, 3. Aufl. Carl Hanser, München
Genon N, Heymans P, Moody D-L (2010) BPMN 2.0 Process Models: Analysis according to PoN,
Arbeitsbericht, PReCISE – University of Namur, Namur. http://www.info.fundp.ac.be/~nge/BP
MN/BPMN2_PoN_Analysis.pdf. Zugegriffen: 07. Jan 2013
Junginger S, Kühn H, Bartl F, Herbst J (1998) Evaluation of Financial Service Organizations
with the ADONIS* Simulation Agents. In: Proceedings of the 10th European Simulation
Symposium (ESS’98). Society for Computer Simulation (SCS), Nottingham
Berlin, S 81–106
Kühn H, Murzek M, Specht G, Zivkovic S (2010) Model-Driven Development of Interoperable,
Inter-Organisational Business Processes. In: Charalabidis Y (Hrsg) Interoperability in the Digital
Public Services and Administration: Bridging E-Government and E-Business. IGI Global,
Hershey, S 119–143
Lichka C, Boudinova D, Sommer J, Wittwer F (2012) BPMN Used by Business Professionals: An
In-depth Reflection on BPM with BPMN by the Swiss FOITT. In: Fischer L (Hrsg) BPMN 2.0
Handbook Second Edition, Future Strategies, Lighthouse Point, S 243–252
Object Management Group (OMG) (2011a) Business Process Model and Notation (BPMN)
Version 2.0, Dokumentation, OMG Document Number: formal/2011-01-03. http://www.omg.
org/spec/BPMN/2.0/PDF. Zugegriffen: 13. Jan 2013
Object Management Group (OMG) (2011b) OMG Unified Modeling Language™ (OMG UML),
Infrastructure – Version 2.4.1, Dokumentation, OMG Document Number: formal/2011-08-05
Rausch T, Kuehn H, Murzek M, Brennan T (2012) BPMN for Business Professionals: Making
BPMN 2.0 Fit for Full Business Use. In: Fischer L (Hrsg) BPMN 2.0 Handbook Second Edition,
Future Strategies, Lighthouse Point, S 189–202
Silver B (2009) BPMN Method and Style: A levels-based methodology for BPM process modeling
and improvement using BPMN 2.0. Cody-Cassidy Press, Aptos
Sinur J (2010) BPMN for Business Professionals: Burn Baby Burn. http://blogs.gartner.com/ji-
m_sinur/2010/08/30/bpmn-for-business-professionals-burn-baby-burn/. Zugegriffen: 13. Jan 2013
Swenson KD (2010) BPMN 2.0: no longer for Business Professionals. http://kswenson.wordpress.com/
2010/09/01/bpmn-2-0-no-longer-for-business-professionals/. Zugegriffen: 13. Jan 2013
Zivkovic S, Kühn H, Karagiannis D (2007) Facilitate Modelling using Method Integration – An
Approach using Mappings and Integration Rules. In: Österle H, Schelp J, Winter R (Hrsg)
Proceedings of the 15th European Conference on Information Systems (ECIS2007) – “Relevant
rigour – Rigorous relevance”, St. Gallen, S 2038–2050
Prozess-Compliance
7
Markus Schneider und Julia Auer
Zusammenfassung
Der Anspruch an eine Nachweiserbringung zur Einhaltung von Gesetzen oder Vorgaben
bzw. an einen detaillierten Einblick in die Prozessabläufe eines Unternehmens bean-
sprucht eine Vielzahl an Unternehmensressourcen. Da davon auszugehen ist, dass diese
Anforderungen in Zukunft tendenziell zunehmen werden, sollte sich jede Organisation
die Frage stellen, wie man mit diesen „Mehrleistungen“ umgeht. Dies betrifft sowohl die
einzelnen Unternehmensprozesse, die einen Erfüllungsgrad in Bezug auf Compliance-
Anforderungen nachweisen müssen, als auch den Compliance-Prozess an sich. In diesem
Kapitel wird der Compliance-Prozess näher betrachtet, d. h. es wird eine Vorgehensweise
zur Integration von Prozess- und Compliance-Organisation beschrieben, welche mit
neuen oder geänderten Anforderungen startet und mit der Lieferung der mit den
Stakeholdern abgestimmten Berichte endet. Die Zielsetzung ist, durch eine einheitliche
Herangehensweise die Aufwände, welche Organisationen bei der Nachweiserbringung
leisten müssen, zu minimieren und neue Anforderungen einfach in den Prozess-
Compliance-Ansatz integrieren zu können.
M. Schneider (*)
e-mail: markus.schneider@boc-group.com
J. Auer

116 M. Schneider und J. Auer
7.1 Herausforderung und Nutzen
Die Nachweiserbringung zur Einhaltung von Gesetzen, Richtlinien oder Vorgaben

beansprucht eine Vielzahl an Unternehmensressourcen. Die Einarbeitung in neue oder
geänderte Anforderungen, die Feststellung des Status-Quo in Bezug auf die Erfüllung
sowie die Erstellung von Berichten und die Kommunikation der Ergebnisse sind mitt-
lerweile ein nicht zu unterschätzender Aufwandstreiber, der – wie viele Prozesse im
Unternehmen – optimiert werden sollte.
Hinzu kommt, dass viele externe wie interne Compliance-Stakeholder (dt. Compliance-
Adressaten) immer häufiger detaillierten Einblick in die Prozessabläufe bekommen wollen.
Bei Bedarf werden bspw. Fragen gestellt, wie:
• An welcher Stelle in welchen Prozessen wird die Compliance-Anforderung X

berücksichtigt?
• Wie lautet die Einschätzung eines Prozessverantwortlichen in Bezug auf den
Erfüllungsgrad der Compliance-Anforderung Y?
• Wie ist der durchschnittliche Compliance-Grad für den Prozessbereich Z jetzt und
welcher Wert soll in Zukunft erreicht werden?
Eine weitere Herausforderung stellt die Mehrfachzuweisung von Compliance-Anforderungen

an Prozesse dar. Demnach werden in der Regel mehrere Compliance-Dimensionen
Anforderungen an einen Prozess haben.
Vor diesem Hintergrund bekommt der Begriff Prozessleistung eine weitere
Bedeutung: Er betrifft dann nicht mehr ausschließlich das Endergebnis eines Prozesses,
sondern auch die Berücksichtigung aller Vorgaben bzw. die Durchführung aller dafür
notwendigen Kontrollen.
Diese erweiterte Sicht des Begriffs Prozessleistung stellt auch einen zentralen Nutzenaspekt
dar: Durch die Einbindung von Compliance-Frameworks in die Prozessorganisation wird
einerseits zu einer risikoorientierten Steuerung der Unternehmensabläufe beigetragen und
andererseits auch Input für die kontinuierliche Prozessverbesserung geliefert.
Da davon auszugehen ist, dass die Anforderungen an die Durchführung und
Nachweiserbringung zur Einhaltung von Gesetzen und Vorgaben in Zukunft tendenziell
zunehmen werden, sollte sich jede Organisation die Frage stellen, wie man mit diesen
Mehrleistungen umgeht. Dies betrifft sowohl die einzelnen Unternehmensprozesse, die
einen Erfüllungsgrad in Bezug auf Compliance-Anforderungen nachweisen müssen, als
auch den Compliance-Prozess an sich.
Der Compliance-Prozess wird in den folgenden Abschnitten näher betrachtet, d. h. es
wird eine Vorgehensweise zur Integration von Prozess- und Compliance-Organisation
beschrieben, welche mit neuen oder geänderten Anforderungen startet und mit der
Lieferung der mit den Stakeholdern abgestimmten Berichte endet.
Auf Basis unserer bisherigen Erfahrungen und Good Practices in diesem Bereich wer-
den neben der Beschreibung der Vorgehensweise verschiedene Beispiele und vor allem
7 Prozess-Compliance 117
der Anwendungsfall EFQM® (European Foundation for Quality Management) eines

fiktiven Unternehmens (vgl. Abschn. 7.7) Inputs für eine praxisnahe Umsetzung von
Prozess-Compliance liefern können.
7.2 Vorgehensweise
Eine Vorgehensweise, um der Herausforderung „Prozess-Compliance“ zu begeg-

nen, stellt Abb. 7.1 dar. Diese Vorgehensweise beschreibt die groben Schritte, Auslöser
und Ergebnisse, welche typischerweise beim Setup, der Durchführung und der
Kommunikation von Prozess-Compliance betrachtet werden müssen.
Der in diesem Kapitel beschriebene Ansatz ist im Rahmen des Process Management Life
Cycle primär der Phase Prozessdokumentation zuzuordnen (vgl. ebenso Abschn. 2.4.2),
da gerade am Beginn des Compliance-Prozesses (Scoping) die Dokumentation der
Abhängigkeiten zwischen Compliance- und Prozessorganisation essentiell ist. Werden
auch die anschließenden Phasen Assessment und Reporting durchgeführt, werden sowohl
Inputs für die Prozessoptimierung als auch das Prozesscontrolling geliefert.
Am Beginn steht eine neue oder geänderte Compliance-Anforderung, bspw. eine
ISO®-Norm, für welche man eine Zertifizierung anstrebt, ein Sicherheitsstandard, ein
Gesetzestext oder sonstige externe oder interne Vorgaben, für die man einen bestimmten
Erfüllungsgrad nachweisen muss. Wichtig für die weitere Durchführung des Compliance-
Prozesses ist die Form, in welcher die Vorgaben verfügbar sein müssen. Damit eine
effiziente Vorgehensweise sichergestellt werden kann, müssen die Vorgaben in Form
konkreter Kontroll- und Steuerungsziele (engl. Control Objectives) vorhanden sein. Auf
Basis dieser einzelnen Zielsetzungen kann dann im nächsten Schritt die Zuordnung/
Verbindung zwischen Prozessorganisation und Compliance-Anforderungen erfolgen.
Das Compliance-Scoping verfolgt einerseits die Zielsetzung, einzelne Vorgaben mit den
Unternehmensprozessen zu verknüpfen, d. h. die operative Durchführung vorzuberei-
ten und die konkreten Erwartungshaltungen an die Prozessverantwortlichen klarzustellen.
Andererseits soll es auch Abhängigkeiten für das Management aufzeigen, insbeson-
dere dann, wenn mehrere Compliance-Frameworks berücksichtigt werden müssen. Aus
diesem Grund wird im Compliance-Scoping ein Mapping der Anforderungen mit der
Prozessorganisation auf zwei Ebenen durchgeführt: Auf Ebene 1 wird eine grobe Zuordnung
zwischen den Unternehmensprozessen bzw. Prozessbereichen einer Organisation und den
zu berücksichtigenden Compliance-Frameworks durchgeführt. Diese Zuordnung hilft, die
betroffenen Prozessbereiche zu identifizieren und zeigt High-Level-Abhängigkeiten auf,
bspw. für mehrfach betroffene Unternehmensprozesse. Die einzelnen Abhängigkeiten wer-
den dann mit Hilfe von verfeinerten Zuordnungen auf Ebene 2 detailliert. Auf dieser Ebene
werden einerseits die Prozessbereiche näher betrachtet (z. B. Hauptprozesse) und anderer-
seits werden die Control Objectives der entsprechenden Compliance-Frameworks zugeord-
net. Diese Mappings auf Ebene 1 und 2 werden in Form von Prozess-Compliance-Matrizen
dargestellt, welche im folgenden Abschnitt näher erläutert werden.
Abb. 7.1 Vorgehensweise

zur Umsetzung eines Prozess-
Compliance-Ansatzes
Vor der Assessment-Durchführung sollten noch zwei weitere Punkte geklärt werden:
die Normierung der Bewertungen und die Sicherstellung der Bewertungsqualität. Die
Normierung der Bewertungen ist insbesondere dann wichtig, wenn man Assessment-
Ergebnisse über verschiedene Prozesse und Compliance-Anforderungen vergleichen und
aggregieren möchte (vgl. Abschn. 7.4). Vor allem bei dezentralen Assessment-Ansätzen
(Stichwort: Self-Assessments) ist die Sicherstellung der Bewertungsqualität wichtig.
Eine häufige Fehlerquelle ist an dieser Stelle ein zu großer Interpretationsspielraum in
Bezug auf die Bewertung von Compliance-Anforderungen, welcher durch entsprechende
Hilfestellungen eingeengt werden kann (vgl. Abschn. 7.5).
Der nächste Schritt betrifft dann die operative Durchführung der Assessments, wel-
che in der Regel durch sogenannte Scorings erfolgen. Für das Scoring kann bspw. ein
Bewertungsbereich von 0 bis 5 verwendet werden. Nach Abschluss der Assessments
ist die Datenbasis für das Reporting vorhanden und die Berichte für die einzelnen
Compliance-Stakeholder können, im Optimum weitestgehend automatisiert, erstellt
werden (vgl. Abschn. 7.6).
7.3 Compliance-Scoping durchführen
Der Scope legt fest, welche Unternehmensprozesse, Compliance-Frameworks und

Control Objectives berücksichtigen müssen. Die Integration von Compliance-
Anforderungen mit dem Prozessmanagement zeigt nicht nur, welche Prozesse im
Einklang mit bestimmten Normen sein sollen, sondern unterstützt darüber hinaus eine
zeit- und kosteneffiziente Einführung und Umsetzung der Compliance-Anforderungen.
Die Verwendung von Prozesslandkarten leistet bei der Prozessabgrenzung einen hilf-
reichen Beitrag (vgl. Kap. 3). Wichtig bei der Realisierung von Prozess-Compliance
ist, die Anforderungen in eine allgemein prüfbare und adaptierbare Form zu über-
tragen. Einen entsprechenden Überblick der High-Level-Abhängigkeiten kann durch
Prozess-Compliance-Matrizen erzielt werden. Das Beispiel in Abb. 7.2 zeigt zum einen
eine Auflistung aller zu berücksichtigenden Compliance-Anforderungen (in Abb. 7.2
als Frameworks bezeichnet). Zum anderen werden auf der linken Seite alle betrof-
fenen Geschäftsprozesse (Management-, Kern- und Unterstützungsprozesse) eines
Unternehmens aufgegliedert und entsprechend durch ein Kreuz in der Matrix zugeordnet.
In einem nächsten Schritt werden Bewertungskriterien der einzelnen Compliance-
Rahmenwerke ausgewählt und den Geschäftsprozessen und/oder Aktivitäten zugeord-
net (vgl. Abb. 7.3). Die Tabelle kann darüber hinaus um Informationen zu den Control
Objectives bzw. um eine Priorisierung erweitert werden (Welche Prozesse weisen gro-
ßen Handlungsbedarf auf und müssen dementsprechend behandelt werden?). Die
Priorisierung kann zum Beispiel durch ein H (high priority, dt. hohe Priorität) und ein L
(low priority, dt. niedrige Priorität) anstelle des Kreuzes dargestellt werden. Darüber hin-
aus können auch die Prozesse in mehreren Ebenen aufgelistet werden (z. B. Haupt- und
Subprozesse).
Compliance-Frameworks
ISO® 9000 COBIT COSO II
Managementprozesse (MP)
MP1: Strategischer
x
MP2: Produktentwicklung x
MP3: Finanzmanagement x x
… x
Unternehmensprozesse
Kernprozesse (KP)
KP1: Marketing & Vertrieb x

KP2: Fertigung x x
KP3: Leistungs- und
x
Schadenbearbeitung
… x
Unterstützungsprozesse (UP)
UP1: Personalmanagement x
UP2: IT-Management x
UP3: Organisationsentwicklung x x x
… x
Abb. 7.2 Prozess-Compliance-Matrix – Level 1
Control Objectives werden als Richtlinien, Verfahren, Praktiken und Organisations

strukturen verstanden, die zum einen auf die Erreichung der Unternehmensziele
abzielen und zum anderen unerwünschte Ereignisse identifizieren, verhindern bzw.
korrigieren (IT Governance Institute 2005, S. 17). Controls können somit auch als
speziell für Compliance-Zwecke implementierte Aktivitäten/Prozesse, welche die
Geschäftsprozesse risikoorientiert steuern und unterstützen, definiert werden. Die
Risikoanalyse an sich, also das Identifizieren von Gefahren im Rahmen der wertschöp-
fenden Prozesse des Unternehmens, stellt beispielsweise eine Control dar.
Folgendes Beispiel einer Prozess-Compliance-Matrix auf detaillierter Ebene zeigt
nun, wo im Unternehmen Compliance-Anforderungen zu berücksichtigen sind, wo
die im Hinblick auf die Compliance kritischen Prozesse und Aktivitäten sind und wel-
che Control Objectives verwendet werden, um Problemen im Vorfeld zu begegnen (vgl.
Abb. 7.3).
Das Beispiel der Prozess-Compliance-Matrix auf Level 2 ist im Vergleich zu Level 1
somit um bestimmte Aspekte erweitert. Die Compliance-Frameworks sind aufgeglie-
dert in relevante Teilkriterien. Zusätzlich sind zu den Dimensionen der Rahmenwerke
einzelne und zu berücksichtigende Control Objectives angeführt und mit den
Geschäftsprozessen verknüpft.
7
Unternehmensprozesse
…
…
…
& Vertrieb
entwicklung
entwicklung
management
management
MP3: Finanz-
MP2: Produkt-
UP1: Personal-
KP2: Fertigung
KP1: Marketing
Prozess-Compliance
Kernprozesse (KP)
MP1: Strategischer
UP3: Organisations-
KP3: Leistungs- und
UP2: IT-Management
Schadenbearbeitung
Managementprozesse (MP )
Control Objectives Dimensionen
Unterstützungsprozesse (UP )
x
x
Kundenorientierung
QM-System
x
x
Prozessorientierter Ansatz
x
x x
Qualitätspolitik Verantwortung
x
®
Planung der Leitung
x x
Abb. 7.3 Prozess-Compliance-Matrix – Level 2

Personelle Ressourcen Management
x
x
x
x
ISO 9000
Infrastruktur v. Ressourcen
x
Kundenbezogene Prozesse Produkt-
x
x
Entwicklung realisierung
x
Manage IT-Investitionen
Plan and Organise
x x
Beurteile u. Manage IT-Risiken
x
x x
Manage Changes Acquire and
x
x x x x
Beschaffe IT-Ressourcen Implement
Schule und trainiere User Deliver and
COBIT
Manage Daten Support
x x x
x x
Monitore und evaluiere IT-Performance Monitor and
x
x
Sorge für IT-Governance Evaluate
x
Tätigkeit Überwachungsorgan
Kontrollumfeld
x
x
Compliance -Frameworks
Organisationsstruktur
x
Betriebliche Ziele Risikobe-
x
x x
Ziele Berichterstattung urteilung
x
Generelle IT-Kontrollen Kontroll-
COSO II
x x x x
Anwendungskontrollen aktivitäten
x
x x
Aufbauprüfung
Überwachung
x
x x
x x
x
Funktionsprüfung
121
7.4 Compliance-Bewertungen normieren
Viele Organisationen müssen den Erfüllungsgrad in Bezug auf Compliance-

Anforderungen oft nicht nur für ein, sondern in der Regel für mehrere Frameworks
nachweisen können. Vor diesem Hintergrund werden oft Anforderungen nach aggre-
gierten Sichten in Bezug auf den Status gewisser Compliance-Dimensionen gestellt,
bspw.:
• aggregierter Status aller Prozess-Compliance-Bewertungen für das Framework X,

• Statusübersicht aller Bewertungen für den Prozess Y oder
• Durchschnitt aller Bewertungen eines Prozessbereichs zum Zeitpunkt Z mit einem
bestimmten Merkmal.
Um solche Anforderungen einfacher umsetzen zu können, ist es hilfreich, die

Bewertungen zu vereinheitlichen. Demnach wird jede Bewertung eines Kontroll- und
Steuerungsziels unabhängig von der Prozess-Compliance-Zuordnung identisch durch-
geführt. Oftmals kommt als Bewertungsraster eine 5-stufige Skala zum Einsatz (vgl.
Tab. 7.1), da solche Skalen in diversen Standards und Reifegrademodellen, z. B. Business
Process Maturity Model (Object Management Group (OMG) 2008), Capability Maturity
Model Integration (CMMI Institute and Clearmodel 2013) oder Control Objectives
for Information and Related Technology (Information Systems Audit and Control
Association (ISACA) 2013, Bakshi 2004), verwendet werden.
Häufigster Kritikpunkt an dieser Vorgehensweise ist, dass Compliance-Frameworks
oftmals eigene Bewertungsskalen definiert haben und somit nicht zu einer generischen
Bewertungsskala passen. Dies ist grundsätzlich richtig, lässt sich aber in den meisten
Fällen mit einer einmaligen Übersetzungsarbeit bewerkstelligen, welche eine Zuordnung
der Bewertungen des spezifischen Compliance-Frameworks zur generischen Skala
durchführt. Wenn bspw. ein Kontroll- und Steuerungsziel nur mit Ja oder Nein beant-
wortet werden kann, entspricht Nein in diesem Fall dem Wert 1 und Ja dem Wert 5.
Werden Assessments mit einheitlichen Skalen durchgeführt, ist es im Anschluss sehr
einfach möglich, verschiedenste Aggregationen durchzuführen, da diese in der Regel nur
noch auf der Berechnung von arithmetischen Mitteln basieren und somit auch einfach
automatisierbar sind.
Tab. 7.1 5-stufige Skala Bewertungsraster

1 Keine Konformität
2 Wenig Konformität
3 Mittlere Konformität
4 Hohe Konformität
5 Volle Konformität
7.5 Scoring-Qualität sicherstellen
Die Vereinheitlichung der Bewertungen stellt einen wichtigen Schritt dar, um die
Umsetzung der Compliance-Anforderungen effizienter zu gestalten. Nichtsdestotrotz
kann davon ausgegangen werden, dass die Einschätzung in der Bewertungsskala meis-
tens nicht interpretationsfrei ist. Zielsetzung bei der Sicherstellung der Scoring-Qualität
ist daher, den Interpretationsspielraum der Bewertungsnormierungen so eng wie mög-
lich zu halten. Die Ergebnisse der Bewertung sollen also unabhängig von der bewerten-
den Person und auf Basis desselben Assessments am Ende so ähnlich wie möglich bzw.
identisch sein. Dies kann durch entsprechende Hilfetexte erreicht werden.
Die Hilfetexte der Bewertungsskalen sollen inhaltlich die Bedeutung der einzelnen
Intervalle beschreiben. Dies kann vor allem in Tabellenkalkulationsprogrammen (z. B.
Microsoft® Excel®) oder wie im folgenden Beispiel im Prozessmanagement-Werkzeug
ADONIS® erstellt und gepflegt werden (vgl. Abb. 7.4).
Im Beispiel wird die Bewertungsskala des Kontroll- und Steuerungsziels
„Imageverlust“ beschrieben. Die Range gibt an, in welchem Bereich/mit welchem
Intervall bewertet werden soll bzw. wann ein gewisser Wert zum Tragen kommt. Die
Scoring-Skala dient zum Mapping der Ist-Werte zu den normierten Scores (0-1-2-3-4
Abb. 7.4 Beispiel für einen Hilfetext einer Bewertungsskala

oder 1-2-3-4-5). Das Scoring gibt an, mit wie vielen Punkten die einzelnen Intervalle
gezählt werden sollen. So würde die Einschätzung von „0 = belanglos“ mit 1 Punkt
gerechnet werden, weil dies die beste Bewertungsmöglichkeit darstellt. Darüber hinaus
können Hilfetexte um Informationen zur Quelle der Intervallbeschreibungen bzw. um
Notizen erweitert werden.
7.6 Compliance-Assessment durchführen und Compliance-

Reporting aufbereiten
Sind die Zuordnungen zwischen Prozessorganisation und Compliance-Anforderungen

vorhanden (vgl. Abschn. 7.3), kann die operative Durchführung der Assessments erfol-
gen bzw. wird für jedes Kreuz in der Prozess-Compliance-Matrix zu einem definierten
Stichtag eine Bewertung durchgeführt. Auf die Organisation der Assessments wird an
dieser Stelle nicht im Detail eingegangen, generell können aber zentrale und dezentrale
Vorgehensweisen unterschieden werden. Eine zentrale Vorgehensweise wäre beispielsweise,
wenn ein Audit-Team die Bewertung aller Control Objectives durchführt bzw. die not-
wendigen Informationen von den Prozessverantwortlichen einholt. Ein dezentraler Ansatz
wäre u. a. die Durchführung von Self-Assessments, bei denen die Prozessverantwortlichen
die Einhaltung der Control Objectives selbst bewerten und die Bewertung stichprobenartig
von einer zentralen Stelle überprüft wird.
Nach Abschluss der Assessments sind die Bewertungen in einer zentralen Datenbank
verfügbar und es kann mit der Aufbereitung der Berichte für die einzelnen Compliance-
Stakeholder begonnen werden. Natürlich richtet sich die Struktur der einzelnen Berichte
an den Zielsetzungen der Anspruchsgruppen aus. Trotzdem werden gewisse Muster und
Templates sehr häufig verwendet und sollen an dieser Stelle vorgestellt werden.
7.6.1 Heat Maps
Im Bereich Prozess-Compliance helfen Heat Maps bei der Darstellung von aggregier-
ten Assessment-Ergebnissen pro Prozessbereich (vgl. Abb. 7.5). Sind einem Prozess
verschiedene Control Objectives zugewiesen und verwenden diese eine einheitliche
Bewertungsskala (vgl. auch Abschn. 7.4) reicht eine einfache Berechnung mit Hilfe des
arithmetischen Mittels aus, um einen aggregierten Assessment-Status zu ermitteln.
Dieser aggregierte Status wird in der Regel mit Hilfe einer Farbskala visualisiert (z. B.
wird ein Durchschnittswert zwischen 1 und 1,99 in Rot visualisiert, von 2 bis 2,99 wird
Gelb verwendet usw.). Es können aber auch Icons für die Repräsentation verwendet
werden.
Abb. 7.5 Beispiel für eine Heat-Map-Visualisierung auf Prozesslandkarten-Ebene
7.6.2 Process Passports
Process Passports bereiten die detaillierten Assessment-Ergebnisse eines Prozesses auf.

Je nach Zuordnung von Control Objectives bilden Passports auch die Möglichkeit unter-
schiedliche Compliance-Dimensionen eines Prozesses abzubilden, bspw. wenn für einen
Prozess neben Qualitätsmanagement-Zielen auch COBIT-Aspekte relevant sind. In der
Regel bestehen Process Passports aus zwei Teilen:
• einem Übersichtsblatt, welches alle Compliance-Dimensionen des Prozesses aggre-

giert darstellt (vgl. Abb. 7.6) und
Übersicht Process Passport „Fertigung von Prototypen“
ISO®
EFQM ® COBIT COSO II
14000
Fertigung von Prototypen 3,250 3,000 2,500 4,000
EFQM®
COSO II COBIT
ISO® 14000
Abb. 7.6 Übersichtsblatt Process Passport
EFQM® 5
Fertigung 3
von Prototypen
2
Soll-Wert
0
Wissen werden gemanagt
Pz werden systematisch
MA-Ressourcen werden
Pz werden bei Bedarf
Messergebnisse aus
Leistungsindikatoren
MA werden belohnt,
geplant, verbessert
Informationen und
Finanzen werden
Control Objective
Kundensicht
verbessert
gemanagt
anerkannt
gestaltet
Fertigung von Prototypen 4 4 3 3 2 2 4 4
Soll-Wert 4 5 5 3 3 3 4 5
Abb. 7.7 Detailblatt Process Passport

Übersicht Process Portfolio

ISO ®
EFQM® COBIT COSO II
14000
Produktentwicklung 3,000 2,000 2,000 3,000
Fertigung von Prototypen 3,250 3,000 2,500 4,000
Fertigung 4,000 3,500 3,000 3,000
EFQM ®
COSO II COBIT
Produktentwicklung
Fertigung von Prototypen
ISO® 14000 Fertigung
Abb. 7.8 Übersichtsblatt Process Portfolio
• einem Detailblatt pro Compliance-Dimension mit allen bewerteten Control

Objectives (vgl. Abb. 7.7).
7.6.3 Process Portfolios
Process Portfolios nutzen dasselbe Berichtstemplate wie die Process Passports mit dem
Unterschied, dass mehrere Prozesse zur besseren Vergleichbarkeit abgebildet werden
(vgl. Abb. 7.8).
7.7 Prozess-Compliance anhand eines Anwendungsbeispiels
Im Folgenden werden die Ausführungen dieses Kapitels anhand eines praktischen

Anwendungsbeispiels veranschaulicht.
7.7.1 Ausgangslage
Das Unternehmen Mustermann GmbH ist ein führendes europäisches Unternehmen

im Bereich Holzverarbeitung. Im Unternehmen sind rund 1.900 Mitarbeiter europaweit
tätig. Durch steigenden Wettbewerbsdruck und Kundenanforderungen sowie durch

das deklarierte Unternehmensziel der kontinuierlichen Qualitätsverbesserung strebt das
Unternehmen eine EFQM®-Zertifizierung an. Die EFQM®-Zertifizierung wird durch
externe Auditoren begleitet.
7.7.2 Exkurs: Prozessorientiertes Qualitätsmanagement und das

EFQM®-Modell
Prozessorientiertes Qualitätsmanagement ist ein Instrument zur Unternehmensführung,

welches neben der Steigerung der Effizienz und Prozessorientierung der Unterneh
mensabläufe auch eine erhöhte Kundenzufriedenheit sowie die Sicherstellung der
Compliance zum Ziel hat (Wagner und Käfer 2010, S. 37). Darüber hinaus kann über
einen Abgleich der Prozessziele sichergestellt werden, dass die Ergebnisse der Prozesse
mit der strategischen Ausrichtung des Unternehmens übereinstimmen (Wagner und
Käfer 2010, S. 25).
Die bekanntesten Qualitätsmanagement-Methoden sind die ISO® 9000 sowie
das EFQM®-Modell. Das EFQM®-Modell (oder das Modell für Excellence), entwi-
ckelt 1988 von der European Foundation for Quality Management, beschreibt ein
Qualitätsmanagement-System des Total Quality Management (TQM) (vgl. Abb. 7.9).
Das EFQM®-Excellence-Modell setzt sich aus neun Kriteriengruppen zusam-
men, die sich in fünf „Befähiger“- und vier „Ergebnis“-Kriterien unterteilen. Die
Befähiger-Kriterien beschäftigen sich damit, wie die Organisation ihre Hauptak
tivitäten abwickelt. Bei den Ergebnis-Kriterien geht es darum, welche Ergebnisse
vom Unternehmen erzielt wurden. Das Modell evaluiert zyklisch anhand eines
Befähiger Ergebnisse
Mitarbeiter-
Mitarbeiter bezogene
Ergebnisse
Ergebnisse
Prozesse
Führung
Politik und Kundenbezogene

Strategie Ergebnisse
Gesellschafts-
Ressourcen und bezogene
Partner Ergebnisse
Innovation und Lernen
Abb. 7.9 EFQM®-Excellence-Modell (EFQM 2013, aus dem Englischen übersetzt)

quantitativen Bewertungsschemas (Selbstbewertung der neun Kriterien mit objekti-

vierter Punktevergabe und anschließendem Benchmarking) Strukturen, Abläufe und
Ergebnisse im Unternehmen (Verlag PRO Sozial 2012). Die Anwendung des EFQM®-
Systems hilft das Verständnis für Schlüsselstärken und Schwachstellen in der Unterneh
mensleistung zu erlangen und unterstützt die Integration von existierenden und
geplanten Initiativen (EFQM 2013).
7.7.3 Compliance-Scoping bei der Mustermann GmbH

durchführen
Die Mustermann GmbH wählt in einem ersten Schritt aus ihrer Prozesslandkarte die
Prozesse aus, welche sie mit den EFQM®-Normen regelkonform gestalten bzw. einem
EFQM®-Assessment unterziehen will. Die festgelegten acht Unternehmensprozesse
(ausgewählte Management-, Kern- und Unterstützungsprozesse) sind mit einem dicken
Rahmen markiert worden (vgl. Abb. 7.10).
In einem nächsten Schritt bearbeitet die Mustermann GmbH ihre Prozess-Compliance-
Matrix. Sie betrachtet die EFQM®-Anforderungen, strukturiert sie mit entsprechenden
Control Objectives und ordnet sie der Prozess-Perspektive zu (vgl. Abb. 7.11).
7.7.4 Compliance-Assessment durchführen
Für das Anwendungsbeispiel werden im Folgenden die Definition, Bewertung und

Ergebnisse für das Compliance-Assessment anhand der EFQM®-Kontroll- und
Steuerungsziele mit den Unternehmensprozessen der Mustermann GmbH erläutert.
Als Grundlage für das Assessment dient die Prozess-Compliance-Matrix (vgl.
Abb. 7.11), die bereits aktualisiert und den Anforderungen des EFQM®-Rahmenwerks
zugeordnet worden ist. Durchgeführt wird die Bewertung dezentral, in Form von
Self-Assessments.
Das Unternehmen hat im Rahmen eines IT-Governance-Projekts seine IT-Prozesse
auf Basis des Rahmenwerks COBIT beurteilt. Dazu wurde vom Unternehmen die von
COBIT vorgeschlagene, einheitliche Bewertungsskala (Intervalle 1–5) angewendet, wel-
che jetzt auch für das anstehende EFQM®-Assessment wieder verwendet werden soll.
In einem ersten Schritt wurden die Wertebereiche der EFQM® Control Objectives
der 5-stufigen Intervallskala zugeordnet. Beispielsweise hat das Unternehmen für das
Control Objective „Prozesse werden systematisch gestaltet und gemanagt“ – welches
eine 4-stufige Bewertungsrange aufweist – ein Scoring von 1, 2, 4 und 5 zugeordnet und
in einem detaillierten Hilfetext beschrieben, um eindeutige und interpretationsfreie
Bewertungsergebnisse erzielen zu können (vgl. Abb. 7.12) In diesem Fall fällt folglich
Stufe 3 in der Compliance-Skala weg.
Abb. 7.10 Prozesslandkarte und Scope der Mustermann GmbH

7
Unternehmensprozesse Mustermann GmbH
UP1: IT
kontrolle
Prototypen
entwicklung
und Planung
management
KP1: Produkt-
UP2: Qualitäts-
KP4: Fertigung
Prozess-Compliance
KP3: Konzeption
MP2: Ressourcen-
Kernprozesse (KP)
KP2: Fertigung von

MP1: Qualitätspolitik
Managementprozesse (MP)
Control Objectives Dimensionen
Unterstützungsprozesse (UP)
F erarbeitet Vision/Mission
Führung (F)
x
F motiviert/unterstützt Mitarbeiter
x
x
x
P&S werden entwickelt, aktualisiert Politik und
P&S werden kommuniziert und eingeführt Strategie (P&S)
MA-Ressourcen werden geplant, verbessert
Mitarbeiter (MA)
MA werden belohnt, anerkannt
x
x
x
Finanzen werden gemanagt Ressourcen
x
x
x
Informations- u. Wissensmanagement und Partner
x
x
x
Pz werden systematisch gestaltet
Abb. 7.11 Prozess-Compliance-Matrix der Mustermann GmbH

Prozesse (Pz)
Pz werden bei Bedarf verbessert
EFQM®
x
Messergebnisse aus Kundensicht Kundenbezogene
x
Leistungsindikatoren Ergebnisse
x
Messergebnisse aus Mitarbeitersicht Mitarbeiter-
Compliance-Frameworks
x
Leistungsindikatoren bezogene Ergebnisse
Messergebnisse aus Sicht der Gesellschaft Gesellschafts-
Leistungsindikatoren bezogene Ergebnisse
Ergenisse der Schlüsselleistungen
Schlüsselergebnisse
x
Schlüsselleistungsindikatoren
131
EFQM®-Hilfetext
Name: Prozesse werden systematisch gestaltet und gemanagt.
Wie die Organisation ihre Prozesse gestaltet, managt und verbessert, um ihre
Politik und Strategie zu unterstützen und ihre Kunden und andere
Beschreibung:
Interessensgruppen voll zufriedenzustellen und die Wertschöpfung für diese zu
steigern.
1 = Die Prozesse sind kaum oder nicht dokumentiert.
2 = Prozesse sind vollständig dokumentiert.

Range:
3 = Prozesse sind erfolgreich implementiert und werden ggf. aktualisiert.
4 = Prozesse werden regelmäßig aktualisiert und optimiert.
Range des Control Objectives Einheitliche Compliance-Skala

1 1
Scoring: 2 2
3 4
4 5
Management, Prozess-
Source:
Reifegradmodelle
Notiz:
Abb. 7.12 Bewertungsskala für das EFQM®-Assessment anhand eines Beispiels
EFQM® 5
Produkt- 3
entwicklung
2
Soll-Wert
0
Pz werden systematisch
Wissensmanagement
F motiviert/unterstützt
entwickelt/aktualisiert
Messergebnisse aus
Informations- und
Control Objective
Finanzen werden
Mitarbeitersicht
P & S werden
Mitarbeiter
gemanagt
gestaltet
Produktentwicklung 3 2 3 3 2 3
Soll-Wert 4 4 5 3 4 3
Abb. 7.13 Detailblatt Process Passport für den Prozess „Produktentwicklung“

7.7.5 Compliance-Reporting durchführen
Nachdem die ausgewählten Personen der Mustermann GmbH das Assessment ihrer acht
Unternehmensprozesse nach den EFQM®-Anforderungen vorgenommen haben, wurden
die Ergebnisse pro Unternehmensprozess in einem Process Passport zusammengefasst
(vgl. Abb. 7.13 für den Prozess „Produktentwicklung“). Dazu wurden die konsolidierten
Werte des Assessments mit den Soll-Werten pro Prozess verglichen.
Demnach wurde festgestellt, dass die Kontrollziele „Informations- und Wissensma
nagement“ sowie „Messergebnisse aus Mitarbeitersicht“ den Zielvorstellungen entsprechen.
Handlungsbedarf wurde vor allem bei den Kontrollzielen „P & S werden entwickelt/aktua-
lisiert“, „Finanzen werden gemanagt“ sowie „Pz werden systematisch gestaltet“ identifiziert.
7.8 Zusammenfassung
Das vorliegende Kapitel beschreibt, wie den steigenden Anforderungen in Bezug auf die
Nachweiserbringung zur Einhaltung von Gesetzen, Richtlinien oder anderen Vorgaben
mit einer methodischen Vorgehensweise begegnet werden kann. Diese Vorgehensweise
zur Umsetzung eines Prozess-Compliance-Ansatzes beschreibt die Tätigkeiten und
Ergebnisse, welche beim Setup, der Durchführung und der Kommunikation beachtet wer-
den müssen. Die Zielsetzung ist, durch eine einheitliche Herangehensweise die Aufwände,
welche Organisationen bei der Nachweiserbringung leisten müssen, zu minimieren und
neue Anforderungen einfach in den Prozess-Compliance-Ansatz integrieren zu können.
Literatur
Bakshi S (2004) Control Self-assessment for Information and Related Technology. Inf Syst Control J 1
CMMI Institute and Clearmodel (2013) Capability Maturity Model Integration (CMMI). http://cm
miinstitute.com/. Zugegriffen: 13. Jan 2013
EFQM (2013) The EFQM Excellence Model, EFQM, Brüssel. http://www.efqm.org/en/tabid/132/D
efault.aspx. Zugegriffen: 07. Jan 2013
Information Systems Audit and Control Association (ISACA) (2013) COBIT 4.1: Framework for
ITGovernance and Control. http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx.
IT Governance Institute (2005) CobiT 4.0 – Deutsche Ausgabe, Dokumentation, Rolling
Meadows. http://www.risikomanagement-in-it-projekten.de/08Literatur/CObIT4_Deutsch.pdf.
Object Management Group (OMG) (2008) Business Process Maturity Model (BPMM) Version 1.0,
Dokumentation, OMG Document Number: formal/2008-06-01:4. http://www.omg.org/spec/BP
MM/1.0/PDF. Zugegriffen: 13. Jan 2013
Verlag PRO Sozial (2012) Qualitätsmanagement mit dem EFQM-Modell, Bonn. http://www.nonpr
ofit.de/artikel-lesen/artikel/efqm-kriterien/. Zugegriffen: 13. Jan 2013
Wagner K-W, Käfer R (2010) PQM Prozessorientiertes Qualitäts-Management: Leitfaden zur
Umsetzung der ISO 9001, 5. Aufl. Carl Hanser, München
Teil IV
Prozessoptimierung
Quantitative Analyse und Planung
von Prozessen 8
Zusammenfassung
Die quantitative Analyse von Prozessen ist ein wichtiges Hilfsmittel im Prozess
management, um qualitative Betrachtungen mittels Berechnungen und Simulationen
quantitativ zu ergänzen und zu plausibilisieren. Im vorliegenden Kapitel wird ein
Klassifikationsschema für Prozessanalysen basierend auf den Dimensionen „Zeitliche
Perspektive“, „Prozessstruktur“, „Analysetechnik“ und „Prozessumfeld“ eingeführt. Es
wird ein Phasenmodell für die quantitative Prozessanalyse vorgestellt, welches ausgehend
vom Ist-Zustand eines Prozesses Hilfestellung bietet, eine oder mehrere Soll-Alternativen
auszuarbeiten und diese quantitativ zu bewerten. Wichtige Betrachtungsobjekte in der
quantitativen Prozessanalyse werden anhand einer strukturellen Ebene (Analyseobjekte)
und einer inhaltlichen Ebene (quantitative Parameter) erläutert. Es wird eine Auswahl
wichtiger und in der Praxis eingesetzter Techniken der quantitativen Prozessanalyse vor-
gestellt. Diese reichen von statischen Verfahren der Prozessabfrage bis zu dynamischen
Verfahren, wie rechnerische Auswertung, Simulation und visuelle Animation.
8.1 Klassifikation von Verfahren zur Prozessanalyse
Das vorliegende Kapitel beschreibt ein Verfahren zur quantitativen Analyse und
Planung von Prozessen und gibt einen Überblick zu häufig in diesem Kontext eingesetz-
ten Techniken. Dabei schränkt sich das Kapitel auf ausgewählte Techniken ein, die eine
H. Kühn (*) · F. Bayer

e-mail: harald.kuehn@boc-eu.com

138 H. Kühn und F. Bayer
Abb. 8.1 Klassifikation von

Verfahren zur quantitativen Merkmal Ausprägung
Prozessanalyse
Zeitliche
ex-ante Echtzeit ex-post
Perspektive
Prozessstruktur bekannt unbekannt
Analysetechnik statisch dynamisch hybrid
Prozessumfeld betrachtet nicht betrachtet
Auswertung im „Ex-ante“-Fall unter Berücksichtigung der Prozessstruktur erlauben (vgl.

die grauen Markierungen in Abb. 8.1). Mit anderen Worten: Diese Techniken erlau-
ben ein Durchspielen von Prozessen vor der realen Ausführung und darauf basierende
„Was-wäre-wenn“-Analysen.
• Zeitliche Perspektive: Dieses Merkmal beschreibt, zu welchem Zeitpunkt die Prozess

analyse erfolgt. „Ex-post“-Analysen werden nach der Ausführung eines Prozesses
durchgeführt (Stichwort: Process Mining). Werden die quantitativen Parameter eines
Prozesses direkt während der Prozessausführung analysiert, so spricht man von einer
Echtzeit-Auswertung (Stichwort: Process Monitoring). Erfolgt zu Planungszwecken die
Analyse eines Prozessmodells vor dessen realer Umsetzung, dann spricht man von einer
„Ex-ante“-Betrachtung.
• Prozessstruktur: Die Prozessstruktur beschreibt den zeitlich-logischen Ablauf von
Elementen innerhalb eines Prozesses. Ist die Prozessstruktur bekannt, so kann
der konkrete Prozessablauf in Form von Prozessmodellen beschrieben werden.
Liegen keine Beschreibungen der strukturellen Logik des Prozesses vor, so ist die
Prozessstruktur unbekannt.
• Analysetechnik: Die Analysetechnik gibt an, auf welche Art und Weise die Auswertung
eines Prozesses erfolgt. Bei einer statischen Analyse werden für die Auswertung
nur diejenigen Informationen genutzt, die direkt im Prozessmodell und/oder dem
Prozessumfeld enthalten sind. Typische Vertreter dieser Analysetechnik sind Abfragen
auf die Prozessmodellinhalte. Bei einer dynamischen Analyse wird auch die logische
Prozessstruktur berücksichtigt, bspw. erlaubt dies die Ermittlung von Durchlaufzeiten.
Hybride Analysetechniken verbinden die Aspekte der statischen und dynamischen
Analyse. Beispielsweise können unter Nutzung von dynamischen Analysetechniken
Kennzahlen, wie Durchlaufzeiten und Auslastungen, ermittelt und anschließend mittels
Abfragen ausgewertet werden.
• Prozessumfeld: Das Prozessumfeld beschreibt den Kontext, in dem ein Prozess durchge-
führt wird. Der Prozesskontext ist bspw. das Unternehmen oder eine Organisationsstruktur,
in dem die Prozessausführung erfolgt. Bei organisationsübergreifenden Prozessen besteht
8 Quantitative Analyse und Planung von Prozessen 139
das Prozessumfeld aus allen beteiligten Akteuren. Wird kein Prozesskontext betrachtet, so
erfolgt die Prozessauswertung ausschließlich auf Basis der im Prozessmodell repräsentierten
Informationen.
8.2 Phasenmodell zur quantitativen Analyse und Planung von

Prozessen
Die quantitative Ex-ante-Analyse eines Prozesses ermöglicht die Auswertung des

Prozessverhaltens und der Bestimmung der Leistungsfähigkeit eines Prozesses vor des-
sen realer Umsetzung (Kühn und Karagiannis 2001). Ein Prozess wird durch ein kor-
respondierendes Prozessmodell repräsentiert bzw. formalisiert. Durch die Festlegung
von Kenngrößen und deren dynamische Wertermittlung können Besser-Schlechter-
Bewertungen im Vergleich zu einem oder mehreren quantitativen Zielwerten durchgeführt
werden. Die quantitative Prozessanalyse ist vorwiegend ein Instrument der PMLC-Phase
Prozessoptimierung (vgl. ebenso Abschn. 2.1.2 und 2.4.3) und wird hauptsächlich durch
die Rollen Prozessberater und Prozesscontroller durchgeführt (vgl. Abschn. 2.2.1).
Typischerweise werden dabei ausgehend von einer vorgegebenen Zielsetzung
der aktuelle Ist-Zustand eines Prozesses beschrieben und über iterative Schritte der
Modellvalidierung, Auswertung und Interpretation eine oder mehrere Soll-Alternativen
ausgearbeitet (vgl. Abb. 8.2). Die Planung umfasst dabei die Antizipation von möglichen
Soll-Situationen, das Vergleichen und Bewerten mit dem Ist-Zustand oder Benchmark-
Werten und davon ausgehend die proaktive Gestaltung des gewünschten Zielzustands.
Die folgenden Abschnitte skizzieren die einzelnen Phasen inkl. deren Rückkopplungsschleifen.
8.2.1 Zieldefinition
In der Zieldefinition werden die in der quantitativen Analyse zu ermittelnden Ergebnisgrößen

festgelegt (vgl. ebenso Kap. 4), wie bspw. die Durchlaufzeit eines Prozesses oder die im
Rahmen einer durchschnittlichen Prozessausführung erwartete Bearbeitungszeit. Weiterhin
wird der zu untersuchende Problembereich klar abgegrenzt, um eine Auswertbarkeit mit
ökonomisch sinnvollem Ressourcenaufwand durchführen zu können.
Abb. 8.2 Phasenmodell zur Feedback und Iterationen

quantitativen Prozessanalyse
Zieldefinition Modell- Validierung Auswertung Interpretation

erstellung
bzw.
-adaption
Beispiel
Eine Zieldefinition, wie „Wir müssen unsere Prozessdurchlaufzeiten um 20 % reduzie-
ren“, würde alle Prozesse eines Unternehmens betreffen und damit eine viel zu breite
Zieldefinition aufspannen. Vielmehr sollte die Zieldefinition für einen konkreten Pro-
zess mit einem sinnvoll eingegrenzten Prozessumfeld durchgeführt werden, wie etwa
„Wir müssen die Prozessdurchlaufzeit im Antragsprozess für Lebensversicherungen
um 20 % reduzieren“. In dieser Zielbeschreibung ist sowohl ein konkreter Prozess
benannt („Antragsprozess“) als auch das Prozessumfeld auf die Sparte „Lebensversi-
cherung“ eingeschränkt.
Weiterhin müssen die notwendigen Input-Parameter festgelegt werden, die zur Berechnung
der zu ermittelnden Ergebnisgrößen vorausgesetzt werden. Bei der Festlegung der Input-
Parameter sollte wie beim zu untersuchenden Problembereich ebenfalls auf die ökonomisch
sinnvolle Ermittelbarkeit geachtet werden. Überschreitet der erwartete Ermittlungsaufwand
für die quantitativen Input-Parameter die erwarteten Einsparungen der geplanten Prozess
verbesserung, so muss die Auswahl der Input-Parameter nochmals überdacht werden.
Ein weiterer wichtiger Bestandteil der Zieldefinition ist die Festlegung der Referenz
werte für die zu ermittelnden Ergebnisgrößen. Referenzwerte erlauben für die Entschei
dungsunterstützung im Rahmen einer Szenario-Analyse Besser-Schlechter-Aussagen.
Referenzwerte können bspw. der heutige Ist-Zustand oder auch Benchmark-Werte ver-
gleichbarer Unternehmen oder Branchen sein.
8.2.2 Modellerstellung/-adaption
Im Idealfall kann man in der quantitativen Prozessanalyse bei der Modellerstellung auf
bereits bestehende Prozessmodelle und Modelle zur Beschreibung des Prozessumfelds,
wie Organigramme, Rollenmodelle o. ä., aufsetzen und diese um die noch notwendigen
quantitativen Input-Parameter ergänzen. Sollen aufgrund der Zielvorgaben verschiedene
Alternativen betrachtet werden, so ist in der Modellerstellung darauf zu achten, dass die
alternativen Vergleichswerte für die spätere Validierung ebenfalls in die Modelle aufge-
nommen werden.
Sollten keine oder unvollständige Prozessmodelle vorliegen, so sind in dieser Phase
die notwendigen Modelle zu erstellen bzw. zu ergänzen. An dieser Stelle wird nicht
näher auf die Modellerstellung eingegangen, sondern es wird auf die in diesem Buch
beschriebenen Prinzipien und Richtlinien zur Architektur und Modellierung von
Prozessmodellen aus den PMLC-Phasen Prozessstrategie und Prozessdokumentation
verwiesen (vgl. Kap. 3, 5 und 6).
Eine Modelladaption kann durch einen Feedbackschritt nach der Modellvalidierung
oder nach der Ergebnisinterpretation notwendig werden. Dabei sind ebenfalls die verein-
barten Prinzipien und Richtlinien einzuhalten.
8.2.3 Validierung
Die Validierung von Prozessmodellen hat das Ziel, eine qualitative Absicherung der
erstellten Modelle und der erhobenen quantitativen Informationen durchzuführen (vgl.
ebenso Kap. 5). Schließlich sollen keine unzutreffenden Entscheidungen auf Basis unzu-
reichender oder falscher Informationen getroffen werden.
Im vorgestellten Verfahren wird die Modellvalidierung auf Basis zweier Schritte
durchgeführt. Im ersten Schritt erfolgt eine formale Prüfung der Modellinhalte und
im zweiten Schritt eine Überprüfung, ob die Modellinhalte und Analyseergebnisse den
Werten aus der Realität standhalten (Realitätscheck).
Bei der formalen Prüfung kommen Mechanismen, wie Syntaxchecks, Kardinalitäts- und
Vollständigkeitsprüfungen zum Einsatz. Dabei wird im Sinne eines grammatikalischen
Tests geprüft, ob das erstellte Prozessmodell konform zur gewählten Modellierungssprache
ist. Es wird geprüft, ob vereinbarte Modellierungsrichtlinien, wie bspw. „Jeder Prozess
benötigt einen eindeutigen Start.“ oder „Nach einem Prozessende dürfen keine weiteren
Aktivitäten folgen.“ konsistent eingehalten werden und ob alle für die Prozessanalyse not-
wendigen Input-Parameter, wie Zeiten, Kosten, Übergangswahrscheinlichkeiten oder
Prozessmengen, vollständig eingetragen wurden.
Der Realitätscheck kann aufgrund von Workshops, Interviews oder gemeinsamen Reviews
stattfinden, bei dem sowohl die Prozessmodelle als auch die Auswertungsergebnisse auf
Plausibilität gegenüber dem in der realen Umgebung auftretenden Verhalten validiert wer-
den. Beispielsweise stellt man die Auswertung des Ist-Modells den realen Daten gegenüber
oder führt Auswertungen mit verschiedenen Varianten der Input-Parameter durch und
prüft, ob dies zu plausiblen und nachvollziehbaren Ergebnissen führt. Führt beides zu posi-
tiven Ergebnissen, kann man von einem qualitativ guten Prozessmodell ausgehen. Falls nein,
dann sind eine entsprechende Modelladaption und eine erneute Validierung durchzuführen.
8.2.4 Auswertung
Die quantitative Auswertung liefert die Resultate zu den in der Zieldefinition festgeleg-
ten Ergebnisgrößen. Hierfür können sowohl rechnerische als auch simulationsbasierte
Techniken zum Einsatz kommen (vgl. Abschn. 8.4).
Ein wichtiger Aspekt ist, ob das Prozessumfeld in der Prozessanalyse berücksich-
tigt werden soll. Einfache Auswertungsverfahren konzentrieren sich ausschließlich
auf den Prozess ohne dessen Umgebung. Beispielhafte Ergebnisse sind Durchlauf- und
Bearbeitungszeiten, Liege- und Transportzeiten, aber auch der erwartete Personalbedarf
aufgrund der in der Bearbeitungszeit gebundenen Mitarbeiterressourcen und der
Prozessmenge. Außerdem kann die Analyse bis auf die Ebene einzelner Prozesspfade
erfolgen, was die Betrachtung kritischer Pfade, wie „kürzester Pfad“ (im Sinne der
Durchlaufzeit), „wahrscheinlichster Pfad“ oder „bearbeitungsstärkster Pfad“, ermöglicht.
Wird zusätzlich das Prozessumfeld in die Auswertung mit einbezogen, können außer-
dem Ergebnisse mit Bezug zur Aufbauorganisation ermittelt werden. Beispielhaft sei hier
der Anteil von Personalkosten an den Prozessgesamtkosten, der Personalbedarf auf Basis
der im Prozess beteiligten Rollen oder auch das Verhalten eines Prozesses in verschiede-
nen aufbauorganisatorischen Varianten genannt.
8.2.5 Interpretation
Die abschließende Phase ist die Interpretation der Ergebnisse. Es werden dabei Entschei
dungsgrößen und diagnostische Größen unterschieden. Die in der Zieldefinition festge-
legten Ergebnisgrößen inklusive etwaiger Referenzwerte bilden die Entscheidungsgrößen.
Auf Basis der Entscheidungsgrößen können Aussagen getroffen werden, welche der
in einer Szenario-Analyse betrachteten Soll-Alternativen jeweils die besseren und die
schlechteren Alternativen sind. Typische Entscheidungsgrößen in der quantitativen
Prozessanalyse sind Durchlauf- und Bearbeitungszeiten eines Prozesses oder der für eine
vorgegebene Prozessmenge notwendige Personalbedarf.
Diagnostische Größen sind Erklärungsvariablen, warum sich ein Prozessmodell bzw.
die in einer Prozessanalyse betrachteten quantitativen Parameter auf eine bestimmte Art
und Weise verhalten. Sie dienen der Ursachenforschung. Häufig genutzte diagnostische
Größen sind bspw. Transport- und Wartezeiten, um die Durchlaufzeit eines Prozesses zu
erklären, oder auch die im Prozess gebundene Bearbeitungszeit, um Rückschlüsse auf die
resultierenden Ressourcenbedarfe ziehen zu können.
Die Interpretation der Ergebnisse folgt dem Grundsatz, dass nicht interpretierbare
Ergebnisse wertlos sind. Dies kann zu einer erneuten Modelladaption, Validierung und
Auswertung führen.
8.3 Betrachtungsobjekte in der quantitativen Analyse von

Prozessen
Im Folgenden werden die Betrachtungsobjekte der quantitativen Prozessanalyse anhand

von zwei Betrachtungsebenen beschrieben: Auf einer strukturellen Ebene betrachtet man
die Elemente, aus denen ein Geschäftsprozess und sein Prozessumfeld zusammenge-
setzt sind (vgl. Abschn. 8.3.1). Auf einer inhaltlichen Ebene werden diese Analyseobjekte
um quantitative Parameter ergänzt bzw. diesen zugewiesen (vgl. Abschn. 8.3.2). Diese
Parameter beschreiben auf der einen Seite den statistischen Input, der notwendig ist,
um einen Geschäftsprozess quantitativ auszuwerten. Auf der anderen Seite beschrei-
ben sie die Ergebnisgrößen der quantitativen Analyse, die als Entscheidungsbasis für
Optimierungsmaßnahmen dienen.
8.3.1 Analyseobjekte
Die Beschreibung der Analyseobjekte erfolgt anhand der vier Kernbereiche des BPMS-
Rahmenwerks (vgl. Abschn. 6.2). Abbildung 8.3 gibt einen Überblick zu wichtigen
Analyseobjekten dieser Kernbereiche. Die quantitative Analyse von Prozessen im engeren
Sinne konzentriert sich ausschließlich auf die Elemente des Prozessbereichs. Die quantita-
tive Analyse im weiteren Sinne schließt auch das Prozessumfeld mit ein, welches durch den
Produktbereich, den Organisationsbereich und den Bereich der Informationstechnologie
abgedeckt wird. Häufig beeinflussen die Elemente aus dem Prozessumfeld den Prozessablauf.
Beispielsweise können bestimmte Produkteigenschaften (Preis, Menge etc.) oder Eigen
schaften im Organisationsbereich (Skills, Kompetenzen etc.) zu unterschiedlichen Entschei
dungspfaden im Prozess führen.
Wichtige Analyseobjekte im Prozessbereich sind die Ereignisse, die den Start und das Ende
eines Prozesses determinieren. Aktivitäten beschreiben die atomaren Bearbeitungsschritte
innerhalb eines Prozesses und Entscheidungen beeinflussen die relevanten Prozesspfade
innerhalb einer Prozessinstanz. Wiederkehrende Prozesssequenzen werden zu Teilprozessen
zusammengefasst, die selbst wieder Gegenstand einer Prozessanalyse sein können.
Produkt- Rechtlicher Materielles Immaterielles Dienst-

…
komponente Aspekt Produkt Produkt leistung
sind abhängig sind abhängig

Produkt
Ereignis Rolle
nutzt
Organisations-
Aktivität
einheit
Organisations- Skills &

Entscheidung Prozess
sind abhängig struktur Kompetenzen
Teilprozess Lokation
unterstützt unterstützt unterstützt
u. schränkt u. schränkt u. schränkt
ein ein ein
… …
Informations-
technologie
nutzt nutzt
Infrastruktur-
IT-Service Anwendung Komponente Server …
element
Abb. 8.3 Analyseobjekte in der Auswertung von Geschäftsprozessen (nach Junginger et al. 2004)
Wichtige Analyseobjekte aus dem Organisationsbereich sind Akteure, welche die

Aktivitäten und Teilprozesse durchführen. In vielen Fällen werden diese aufgrund auswer-
tungsrelevanter Vorschriften wie Betriebsvereinbarungen und Datenschutzbestimmungen
jedoch zu Rollen oder Stellen anonymisiert und bei Bedarf zu Organisationseinheiten aggre-
giert. Weitere analyserelevante Objekte sind Skills und Kompetenzen dieser Objekte oder
ortsgebundene Informationen wie die Lokationen, in denen ein Prozess durchgeführt wird.
Im Produktbereich werden die materiellen und immateriellen Produkte inklusive ihrer
Teilkomponenten beschrieben, die innerhalb der Prozesse erstellt und bearbeitet wer-
den. Einen wichtigen Aspekt bilden hier auch rechtliche Produktaspekte, wie Lizenzen
und Schutzrechte, da diese gerade in der quantitativen Betrachtung auch Einfluss auf die
Prozessauswertung nehmen können. Beispielsweise kann eine erhöhte Prozessmenge zur
Senkung von etwaigen mengenabhängigen Lizenzstückkosten führen.
Die Informationstechnologie bildet die Basis moderner Geschäftsprozesse. Typische
Einflussfaktoren für eine Prozessanalyse sind bspw. die angebotenen technischen Services,
Komponenten und Anwendungen. Außerdem spielen Verfügbarkeiten und Eigenschaften
der zugrunde liegenden Infrastruktur eine wichtige Rolle.
Die explizite und integrierte Repräsentation dieser Analyseobjekte unterstützt
bei der Formulierung der Zieldefinition und damit einhergehender quantitativer
Fragestellungen, die in einer Prozessanalyse verfolgt werden können. Die folgenden
Beispiele geben hierzu eine ausschnitthafte Übersicht, wobei in Klammern jeweils die
beteiligten Kernbereiche aufgeführt sind (Produkt, Prozess, Organisation, IT):
• Wie viele Aktivitäten haben eine Bearbeitungszeit größer x Minuten? (Prozess)

• Wie viele Aktivitäten sind manuell und wie viele automatisiert? (Prozess, IT)
• Wie viele Abteilungs- und/oder Rollenwechsel gibt es? (Prozess, Organisation)
• Wie viele Produkte werden innerhalb eines Prozesses bearbeitet? (Produkt, Prozess)
• Welche Prozesskosten verursacht die Erstellung eines bestimmten Produkts?
(Produkt, Prozess, Organisation, IT)
• Welche Menge des Prozesses x kann mit der bestehenden Besetzung von Rolle y abge-
arbeitet werden? (Prozess, Organisation)
• Welche Stellenauslastung herrscht im Prozess x? (Prozess, Organisation)
• Wie viele Ressourcen der Rolle x werden zusätzlich benötigt, wenn der Produktumsatz
von Produkt y um z Prozent erhöht wird? (Produkt, Prozess, Organisation)
• Bei der Erhöhung des zuvor genannten Produktumsatzes, wie stark erhöht sich die
Auslastung der involvierten IT-Ressourcen? (Produkt, Prozess, IT)
8.3.2 Quantitative Parameter
Um die Voraussetzungen zur Beantwortung solcher quantitativer Fragestellungen zu

schaffen, ist die Erfassung und Zuordnung von quantitativen Parametern zu den beteilig-
ten Analyseobjekten notwendig. Aufgrund ökonomischer Aspekte ist darauf zu achten,
Quantitative
Parameter
Sonstige
Zeiten Kosten Kapazitäten
Parameter
Aktivitäts- Prozess- Prozess-

Liegezeit
kosten menge kalender
Bearbeitungs- Akteurs- Ressourcen- Akteurs-

zeit kosten menge kalender
Prozess- Personal- Ressourcen-

Wartezeit
kosten bedarf kalender
Ressourcen- Wahrschein-
Transportzeit Belastungen
kosten lichkeiten
Transaktions- Statistische
Durchlaufzeit Auslastungen
kosten Verteilungen
Unternehmens-
… … Häufigkeiten
arbeitszeit
… …
Abb. 8.4 Quantitative Parameter in der Prozessanalyse (nach Kühn und Karagiannis 2001)
dass nur diejenigen Parameter erhoben werden, die tatsächlich auch für die Prozessanalyse
benötigt werden. Dies ist umso wichtiger, je größer der Anteil an manuell zu erhebenden
Parametern ist, da sonst die Kosten eines Prozessanalyse-Projekts die durch die Analyse
einzusparenden Kosten erreichen oder sogar übertreffen können. Im Idealfall können die
notwendigen Parameter automatisiert ermittelt werden (vgl. ebenso Abschn. 9.3). Gängige
Parameterkategorien hierfür sind Zeiten, Kosten, Kapazitäten und auch Parameter, wel-
che Verfügbarkeiten und statistische Informationen beschreiben. Abbildung 8.4 gibt einen
Überblick über typische Parameter aus den Kernbereichen Prozess und Organisation.
Im Folgenden werden einige wichtige quantitative Parameter näher erläutert. Die
Durchlaufzeit eines Prozesses ist die Zeitdauer vom Start eines Prozesses bis zu des-
sen Beendigung. Durchlaufzeiten werden in der Prozessanalyse sowohl für konkrete
Prozesspfade betrachtet als auch als gewichteter Durchschnittswert über alle möglichen
Prozesspfade hinweg. Ein Beispiel wäre die Bearbeitung eines Kreditantrags, bei dem
bestimmte Entscheidungen und davon abhängige Prozesspfade in Abhängigkeit der
Kreditantragshöhe getroffen werden. Über die Vergabe eines Kleinkredits kann bspw.
direkt durch einen Banksachbearbeiter entschieden werden, ein Immobilienkredit durch
den Bereichsleiter für Immobilienfinanzierungen in einer Filiale und ein Großkredit für
ein Unternehmen durch den verantwortlichen Bereichsvorstand. Diese Prozesspfade
haben jeweils individuelle und meist unterschiedliche Durchlaufzeiten. Werden diese

Durchlaufzeiten jeweils mit ihrer Pfadwahrscheinlichkeit gewichtet, erhält man den
Durchschnittswert für einen typischen Prozessdurchlauf.
Die Durchlaufzeit setzt sich nicht nur aus der Bearbeitungszeit der Aktivitäten, son-
dern auch aus der Summe der während der Prozessdurchführung auftretenden Warte-,
Liege- und Transportzeiten zusammen (BOC 2012, Abschnitt 4.1.3.2 „Aktivitätszeiten“,
S. 378 ff.). Die Wartezeit gibt die Zeit an, die durchschnittlich vor der Bearbeitung bzw.
bei der Unterbrechung einer Aktivität verstreicht. Die Liegezeit beschreibt die Zeit,
die ein Auftrag noch bei einem Akteur verweilt, bevor er zum nächsten Akteur zur
Bearbeitung weitergeleitet wird. Die Transportzeit ist die Zeit, die durchschnittlich für
den Transport zwischen den Aktivitäten benötigt wird.
Die Unternehmensarbeitszeit beschreibt die Zeit, die in einem Unternehmen für die
Ausführung von Geschäftsprozessen zur Verfügung steht. Bei vollständig automatisier-
ten Prozessen kann dies bis zu einem vollständigen Kalenderjahr betragen, d. h. 365 Tage
zu jeweils 24 Stunden. Berücksichtigt man allerdings auch Prozesse mit Beteiligung des
Menschen, so sind bei der Berechnung der zur Verfügung stehenden Unternehmensarbeitszeit
auch die relevanten Arbeitszeitmodelle zu berücksichtigen, d. h. ein Kalenderjahr abzüg-
lich der Wochenenden, gesetzlichen Feiertage sowie durchschnittlichen Urlaubs- und
Krankheitstage. Eine weiterführende Diskussion der Zeitbegriffe findet sich bspw. in
Abschn. 9.4.4 sowie (BOC 2012, Abschnitt 4.1.3.1 „Begriffsabgrenzung“, S. 377 f.).
Kosten können zu Elementen aus allen Kernbereichen zugewiesen werden. Diese reichen
von einer Aktivität, einem Akteur oder einer Ressource direkt zurechenbaren Kosten, über
mengenabhängige Transaktionskosten bis hin zu Prozesskosten für einen vollständigen Prozess.
Bei der Analyse von Prozessen inklusive ihres Prozessumfelds sind insbesondere
Kapazitätsbetrachtungen von Interesse. Wichtige Parameter sind dabei die Mengengerüste
für Prozesse, Parameter des Umfelds, wie vorhandene oder benötigte Ressourcenmengen
oder Personalbedarfe sowie Be- und Auslastungen bestimmter Ressourcenkategorien.
Ein weiterer wichtiger Bereich der quantitativen Parameter sind Informationen zum
zeitlichen Auftritt bzw. der Verfügbarkeit von Ressourcen, wie Prozess-, Akteurs- und
Ressourcenkalender. Solche Kalender geben an, wer an welchem Tag zu welcher Uhrzeit für
die Bearbeitung von Aktivitäten zur Verfügung steht. Statistische Verteilungen, darauf basie-
rende Übergangsbedingungen und Wahrscheinlichkeiten bei Entscheidungsknoten stellen die
notwendigen Informationen für die Quantifizierbarkeit eines Prozessablaufs zur Verfügung.
Manche der erläuterten Parameter können je nach eingesetzter Analysetechnik
sowohl Input-Parameter als auch Ergebnis-Parameter sein. Beispiele hierfür wären die
Prozessmenge und der Personalbedarf. Wählt man eine Analysetechnik zur Bestimmung
des notwendigen Personalbedarfs für eine gegebene Prozessmenge (vgl. Kap. 9), so ist
die Prozessmenge Input-Parameter und der Personalbedarf Ergebnis-Parameter. In
umgekehrter Richtung kann der Personalbedarf Input-Parameter sein, wenn man eine
Analysetechnik wählt, aus der aus einem gegebenen Personalstand die maximal damit
bearbeitbare Prozessmenge ermittelt wird und hieraus wiederum Betrachtungen zu den
Prozesskosten abgeleitet werden (vgl. Kap. 10).
8.4 Ausgewählte Techniken zur quantitativen Analyse von

Prozessen
Es wird im Folgenden ein Überblick zu Ex-ante-Techniken der Prozessanalyse gegeben.

Diese kommen für die Bewertung von Ist-Prozessen und vor der Umsetzung möglicher
Soll-Alternativen zum Einsatz. Dabei wird jeweils davon ausgegangen, dass die zugrunde
liegende Prozessstruktur bekannt ist.
Ex-post-Analysen (Process Mining) und Echtzeit-Analysen (Process Monitoring)
sind nicht Inhalt dieses Kapitels. Hierzu wird auf die einschlägige Literatur (Herbst und
Karagiannis 2000; van der Aalst 2011) verwiesen.
8.4.1 Statische Analyse
Eine statische Analyse kommt vorrangig zum Einsatz, wenn die Betrachtungsobjekte auf
einer strukturellen Ebene bereits beschrieben sind, aber noch keine quantitativen Parameter
hinzugefügt wurden oder (noch) nicht zur Verfügung stehen. Dadurch kann bereits in einer
frühen Phase der Prozesserhebung eine erste quantitative Analyse durchgeführt werden.
Bei der statischen Analyse handelt es sich um Abfragen auf Prozessmodelle (engl.
Queries), bei denen die Elemente und deren Abhängigkeiten sowohl innerhalb eines
Prozesses als auch in Verbindung mit dem Prozessumfeld betrachtet werden. Typische
Formen der statischen Analyse sind folgende:
• Die Ermittlung der Anzahl bestimmter Modelleigenschaften, wie die Anzahl

von Medienbrüchen, die Anzahl von Prozessschnittstellen oder die Anzahl von
Bearbeiter- und Rollenwechsel.
• Transitive Analysen, bei denen die Abhängigkeiten der Elemente untereinander ermittelt
werden. Ein Beispiel hierfür ist die Ermittlung der Anzahl der Produktverantwortlichen
innerhalb eines Prozesses, die sich aus der Anzahl der Rollen ergibt, die den Produkten
zugeordnet sind, die selbst wiederum den Aktivitäten im Prozess zugeordnet sind, in
denen die Produkte bearbeitet werden.
• Impact-Analysen sind eine spezielle Form von transitiven Analysen. Dabei wer-
den jeweils Art und Anzahl von Elementen ermittelt, die miteinander über einen
bestimmten Sachverhalt verbunden sind, und dann anhand der Abhängigkeiten in
Ebenen angeordnet. Ein Beispiel hierzu ist die Ermittlung aller Prozesse, die eine spe-
zielle Anwendung benutzen, die wiederum einen bestimmten IT-Dienst nutzt, der nur
von einem konkreten Service-Provider erbracht werden kann. Für weitere Beispiele
vgl. ebenso Abschn. 16.3.2.
• Matrizen ermöglichen die kompakte Auswertung von bilateralen Abhängigkeiten.
Beispiele hierfür sind die Risiko-Prozess-Matrix oder die Rollen-Prozess-Matrix
zur Ermittlung der auftretenden Risiken und Rollen in einem Prozess. Für weitere
Beispiele vgl. ebenso Abschn. 16.3.2.
8.4.2 Dynamische Analyse
In der dynamischen Analyse erfolgt eine Auswertung des Prozessflusses unter Berück
sichtigung der quantitativen Parameter. Im Folgenden werden einige dynamische
Techniken vorgestellt, die in der praktischen Anwendung zur Prozessanalyse Verbreitung
gefunden haben. Es wird sowohl auf die rechnerische Auswertung eingegangen als auch
auf Verfahren basierend auf Simulation. All diesen Techniken liegt zugrunde, dass
Entscheidungsalternativen im Prozessablauf als Übergangsbedingungen der Nachfolger
beziehung von Entscheidungsobjekten abgebildet werden. Die Übergangs bedingung
kann dabei unter Zuhilfenahme von Wahrscheinlichkeiten oder Variablen basierend auf
statistischen Verteilungen formuliert werden. Die genannten Techniken sind im Prozess
management-Werkzeug ADONIS® umgesetzt.
Es gibt eine Vielzahl weiterer Verfahren für dynamische Analysen, wie bspw. die
Monte-Carlo-Simulation, System Dynamics (Sterman 2000; Senge 2011) oder Petri-
Netze (Petri 1962; Reisig 2010). Aus Platzgründen werden diese Verfahren im vorliegen-
den Kapitel nicht weiter ausgeführt und stattdessen auf die relevante Literatur verwiesen.
8.4.2.1 Rechnerische Auswertung
Die rechnerische Auswertung berechnet das Ergebnis eines Prozesses. Es wird keine
Prozesssimulation durchgeführt (Junginger 1998; BOC 2012, Abschnitt 3.4 „Rechnerische
Auswertung“, S. 366 ff.). Bei jeder Entscheidung werden an den ausgehenden Nachfolger
beziehungen Wahrscheinlichkeiten hinterlegt (vgl. Abb. 8.5). Die Summe der einzelnen
Wahrscheinlichkeiten muss dabei eins ergeben. Ist keine Wahrscheinlichkeit angegeben,
so wird dieser Pfad immer ausgeführt (= 100 %). Es werden alle möglichen Pfade des
Prozessmodells analysiert und die Wahrscheinlichkeiten des jeweiligen Prozesspfads ermit-
telt. Dabei werden zwei Fälle unterschieden: (1) Prozessmodelle ohne Schleifen und (2)
Prozessmodelle mit Schleifen.
(1) Prozessmodelle ohne Schleifen

Die Häufigkeit einer Aktivität für einen Prozessdurchlauf ergibt sich aus dem Produkt
der Wahrscheinlichkeiten der Nachfolgerbeziehungen auf dem Pfad bzw. den Pfaden
vom Prozessstart bis zu dieser Aktivität.

Aktivität
HäufigkeitAktivität = Wahrscheinlichkeit an Nachfolgerbeziehung
Pro Pfad zur Aktivität Prozessstart
(8.1)
Die durchschnittliche Bearbeitungszeit pro Aktivität erhält man durch die Gewichtung
der Bearbeitungszeit (BZ) der Aktivität mit ihrer Häufigkeit.
Durchschnittliche BZAktivität = HäufigkeitAktivität × BZAktivität (8.2)
Zur Berechnung der durchschnittlichen Bearbeitungszeit des gesamten Prozesses bildet man
die Summe über alle mit ihrer Häufigkeit gewichteten Bearbeitungszeiten der Aktivitäten.
Abb. 8.5 Prozessmodell ohne Schleifen

Durchschnittliche BZProzess = Durchschnittliche BZAktivität (8.3)
Alle Aktivitäten
Für den Prozess aus Abb. 8.5 ergeben sich anhand der vorgegebenen Bearbeitungszeiten
der Aktivitäten die in Tab. 8.1 angeführten durchschnittlichen Prozessbearbeitungszeiten.
(2) Prozessmodelle mit Schleifen

Bei Prozessmodellen mit Schleifen (vgl. Abb. 8.6) kann das zuvor genannte Verfahren
nicht angewendet werden. Entweder berechnet man dann pro Schleife eine bestimmte
Anzahl von Durchläufen, um das Ergebnis möglichst genau anzunähern. Oder man
benutzt Berechnungsansätze wie bspw. geometrische Reihen, um pro Schleife den exak-
ten (mathematischen) Wert zu berechnen. Das Gesamtergebnis setzt sich dann aus den
Ergebnissen der einzelnen geometrischen Reihen zusammen. Diese Technik wird im
Folgenden skizziert und basierend auf den Werten aus Abb. 8.6 und Tab. 8.2 beispielhaft
angewendet.
Eine geometrische Reihe kann, wie nachstehend angeführt, berechnet werden.

∞
1
pi = (8.4)
1−p
i=0
Die Schleife 1 setzt sich wie folgt zusammen:

Schleife 1 = AktivitätAntrag prüfen + 0,1 × AktivitätUnterlagen nachfordern
+ AktivitätAntrag prüfen + 0,1 × (AktivitätUnterlagen nachfordern
+ AktivitätAntrag prüfen + 0,1 × (. . .))) (8.5)
Schleife 1 Schleife 2
Abb. 8.6 Prozessmodell mit Schleifen
Tab. 8.1 Bearbeitungszeiten im Prozess „Adressänderung“

Aktivität Bearbeitungszeit Häufigkeit Durchschnittliche
(mm:ss) der Aktivität Bearbeitungszeit
(mm:ss)
Partner im System suchen 01:00 1,0 01:00
Adresse prüfen 00:30 1,0 00:30
(Inland/Ausland)
Neue Adresse eintragen 01:30 1,0 = 0,9 + (0,1 × 01:30
0,7) + (0,1 × 0,3)
Land aus Risikotabelle 01:30 0,1 00:09
entnehmen
Beim Kunden rückfragen 15:00 0,03 = 0,1 × 0,3 00:27
Prozess – – 03:36
Tab. 8.2 Bearbeitungszeiten Bearbeitungszeit

im Prozess „Antragsprüfung“ Aktivität (mm:ss)
Antrag prüfen 02:00
Unterlagen nachfordern 05:00
Antragsdaten eingeben 01:00
Plausibilitätsprüfung durchführen 00:30
Schleife 1 besitzt eine Besonderheit: Nicht alle Aktivitäten, die zur Schleife gehören,
werden vor dem Eintritt in die Schleife vollständig durchlaufen, d. h. die AktivitätUnterlagen
nachfordern wird vor dem Schleifeneintritt noch nicht ausgeführt. Um jedoch die Formel
der geometrischen Reihe anwenden zu können, müssen die einzelnen Terme jeweils voll-
ständig in die Reihe eingehen, d. h. alle Prozessschritte der Schleife beinhalten. Um dies
zu erreichen, wird beim ersten Term die „fehlende“ AktivitätUnterlagen nachfordern ergänzt.
Damit das Ergebnis aber korrekt bleibt, wird die Ergänzung auch gleich wieder neutrali-
siert, indem die ergänzte Aktivität subtrahiert wird und die Änderung dadurch insgesamt
null ist. Die nachstehende Formel zeigt Schleife 1 unter Anwendung der Formel der geo-
metrischen Reihe, wobei die Terme schrittweise zusammengefasst werden.
Schleife 1 = (AktivitätAntrag prüfen + AktivitätUnterlagen nachfordern − AktivitätUnterlagen nachfordern )
+ 0,1 × (AktivitätUnterlagen nachfordern + AktivitätAntrag prüfen
+ 0,1 × (. . .)))
Schleife 1 = −AktivitätUnterlagen nachfordern

+ (AktivitätUnterlagen nachfordern + AktivitätAntrag prüfen )
+ 0,1 × (. . .)))
Schleife 1 = −AktivitätUnterlagen nachfordern

∞

+ 0,1i × AktivitätUnterlagen nachfordern
i=0
(8.6)
+ AktivitätAntrag prüfen
Somit ergibt sich für die durchschnittlich in Schleife 1 gebundene Bearbeitungszeit eine
Dauer von 2 Min. 47 Sek.
Durchschnittliche BZSchleife 1 = − BZUnterlagen nachfordern

1
+ × BZUnterlagen nachfordern + BZAntrag prüfen
1 − 0,1
1
Durchschnittliche BZSchleife 1 = − 5 Min + × 7 Min ∼ 2 Min 47 Sek (8.7)
1 − 0,1
Da in Schleife 2 bereits alle Aktivitäten vor dem Eintritt in die Schleife vollständig
durchlaufen werden, kann man direkt in die Formel einsetzen. Die durchschnittliche
Bearbeitungszeit von Schleife 2 ergibt sich damit wie folgt:
1
Durchschnittliche BZSchleife 2 = × (1 Min + 30 Sek) ∼ 2 Min 8 Sek
1 − 0,3
Durchschnittliche BZÄnderungsantrag ∼ 4 Min 55 Sek (8.8)
Die durchschnittliche Bearbeitungszeit der Antragsprüfung des Änderungsantrags aus

Abb. 8.6 ist somit in der Größenordnung von 4 Min. 55 Sek.
Gelten bestimmte Rahmenbedingungen, so besitzt die rechnerische Auswertung aller-

dings einige Einsatzgrenzen. Sind bspw. unterschiedliche Ablaufpfade vom gleichen
Sachverhalt abhängig, d. h. verschiedene Entscheidungen im Prozess basieren auf den
gleichen Übergangsbedingungen, so kann dies alleine durch Wahrscheinlichkeiten nicht
korrekt abgebildet werden („abhängige Wahrscheinlichkeiten“). Ein weiteres Problem bei
komplexen Prozessstrukturen mit vielen verzweigenden Ablaufpfaden kann die Laufzeit der
Berechnung sein. Wie zuvor geschildert, wird für die Berechnung der Aktivitätshäufigkeit
der Pfad vom Beginn des Prozesses bis zur Aktivität benötigt. Nimmt man bspw. binäre
Entscheidungen in einem Prozess an, d. h. Entscheidungen mit jeweils zwei ausgehenden
Möglichkeiten, und nimmt man weiter an, dass die Pfade nach den Entscheidungen nicht
mehr zusammenführen, dann gibt es 2n mögliche Prozesspfade. Dies kann verständlicher-
weise bei einer größeren Anzahl von Entscheidungen zu sehr langen Berechnungslaufzeiten
führen, die für einen praktischen Einsatz nicht mehr akzeptabel sind.
8.4.2.2 Simulation
Stoßen rechnerische Verfahren an ihre Grenzen, so bieten bspw. simulationsba-
sierte Techniken (Rabe und Knothe 2010) alternative Auswertungsmöglichkeiten.
Das Grundprinzip dabei ist, das Prozessmodell hinreichend oft „durchzuspielen“ und
die Ergebnisse pro Prozesspfad zu protokolieren. Im Folgenden werden einige in der
Prozessanalyse-Praxis eingesetzte Simulationstechniken skizziert (Herbst et al. 1997;
Kühn und Karagiannis 2001; BOC 2012, Abschnitt 4 „Simulation“, S. 374 ff.). Sie basie-
ren alle auf diskreten, ereignisgesteuerten Simulationsverfahren.
Pfadanalyse
In der Pfadanalyse erfolgt eine reine Pfadbetrachtung eines Geschäftsprozesses, d. h. das
Prozessumfeld wird nicht berücksichtigt (BOC 2012, Abschnitt 4.2 „Pfadanalyse“, S. 386 ff.).
Ausgehend von einer vor der Pfadanalyse festgelegten Anzahl von Simulationsläufen
n wird das Prozessmodell n-mal von Anfang bis Ende durchgeführt. Die Anzahl der
Simulationsläufe gibt nicht an, wie oft der Prozess in der Realität durchgeführt, son-
dern nur wie oft der Prozess in der Simulation ausgeführt wird. Je höher die Anzahl der
Simulationsläufe, desto genauer werden die Simulationsergebnisse.
Bei der Durchführung werden an den festgelegten Stellen jeweils Zufallsgeneratoren
ausgeführt, die anhand einer vorgegebenen statistischen Verteilung Zufallszahlen erzeugen
und diese ihren assoziierten Variablen zuweisen. An den Entscheidungen im Prozessablauf
werden die Variablen in Form von Übergangsbedingungen abgefragt und steuern damit die
Ablaufpfade (vgl. Abb. 8.7). Werden in einer Übergangsbedingung mehrere Variablen über
logische Operatoren wie UND, ODER und NICHT miteinander verknüpft, so können damit
auch komplexe Geschäftsregeln (engl. Business Rules) formuliert und ausgewertet werden.
Durch die Simulationsläufe wird nach und nach eine Pfadtabelle aufgebaut, in der
alle aufgetretenen Ablaufpfade inkl. ihrer jeweiligen Pfadwahrscheinlichkeit fest-
gehalten werden. Am Ende der Simulation können dann die ausgewerteten quan-
titativen Parameter (vgl. Abschn. 8.3.2) pro Prozesspfad betrachtet oder auch
Abb. 8.7 Prozessmodell mit Variablenbelegungen und Übergangsbedingungen
Durchschnittswerte für den gesamten Prozess gebildet werden. Durchschnittswerte

ergeben sich als Summe der Ergebnisse pro einzelnen Pfad, jeweils gewichtet mit der
Wahrscheinlichkeit des Pfads.
Soll zusätzlich zur Pfadbetrachtung auch noch eine Auswertung auf Ebene der
Aktivitäten durchgeführt werden, so müssen darüber hinaus noch die erwarteten
Aktivitätshäufigkeiten ermittelt werden. Im Gegensatz zur rechnerischen Auswertung
ergibt sich in der Pfadanalyse die erwartete Häufigkeit einer Aktivität aus der Anzahl,
wie oft diese Aktivität in allen Simulationsläufen durchgeführt wurde, gewichtet mit der
Gesamtzahl der Simulationsläufe n (Junginger 1998, S. 14).
n
Anzahl der Aktivitätsdurchführung in Durchlauf i
HäufigkeitAktivität = i=1 (8.9)
n
Belastungsanalyse (Kapazitätsanalyse)
Die Belastungsanalyse ergänzt die Pfadanalyse um die Betrachtung des Prozessumfelds,
d. h. sie verknüpft sie mit den Elementen der Aufbauorganisation (BOC 2012, Abschnitt
4.3 „Belastungsanalyse“, S. 398 ff.). Die Verknüpfung erfolgt durch Zuweisung
von ausführenden Rollen, Stellen, Organisationseinheiten oder Ressourcen mittels
Zuweisungsregeln. Die Definition der Zuweisungsregeln erfolgt analog der Definition
von Übergangsbedingungen im Prozessablauf zur Steuerung des Prozessflusses.
Beispiel
Zur Illustration einer solchen Zuordnungsregel ein Beispiel aus dem Bankbereich:
In einem Kreditprozess wird die Kontrollaktivität von verschiedenen Bearbei-
tern in Abhängigkeit von der Kredithöhe durchgeführt. Bei einer Kredithöhe grö-
ßer 500.000 EUR erfolgt die Kontrolle durch den Leiter der Organisationseinheit
„Kreditabteilung“, bei einer Kredithöhe kleiner oder gleich 500.000 EUR von Bearbei-
tern der Rolle „Sachbearbeiter“. In ADONIS® würde eine solche Zuordnungsregel bei
einer Aktivität wie folgt formuliert werden:
(({“Sachbearbeiter”:“Rolle”} < −“hatRolle”) [!“Kredithöhe” ≤ 500000]) ODER

(({“Kreditabteilung”:“Organisationseinheit”} < − “ist Leiter”)
[!“Kredithöhe” > 500000]) (8.10)
Außerdem werden Mengengerüste des Prozesses hinterlegt, die beschreiben, in welcher

Periode ein Geschäftsprozess mit welcher Menge auftritt. Auf Basis der Aktivitätshäufigkeiten,
der Prozessmengen und der Stundensätze der Aufbauorganisation können auch mengenab-
hängige Bearbeitungskosten ermittelt werden.
Die Belastungsanalyse erlaubt eine kapazitätsorientierte Auswertung und schafft die
Basis für die Beantwortung der Frage: „Wie viele Personal- und Sachressourcen eines
bestimmten Typs werden für die Bearbeitung einer gegebenen Prozessmenge benö-
tigt?“. Die Belastungsanalyse liefert damit die Basis zur Implementierung von weiter-
führenden Verfahren, wie bspw. die Personalbedarfsermittlung (vgl. Kap. 9) oder die
Prozesskostenrechnung (vgl. Kap. 10).
Auslastungsanalyse (Leistungsanalyse)
Die Auslastungsanalyse verknüpft die Pfadanalyse ebenso wie die Belastungsanalyse mit
der Betrachtung des Prozessumfelds (BOC 2012, Abschnitt 4.4 „Auslastungsanalyse“,
S. 411 ff.). Im Gegensatz zur Belastungsanalyse geht die Auslastungsanalyse allerdings
von einem vorgegebenen Stand an Personal- und Sachressourcen aus. Die Verfügbarkeit
Abb. 8.8 Definition von Auftrittsintervallen in einem Prozesskalender

dieser Ressourcen wird über Kalender beschrieben. Ebenso über einen Kalender wird
das Auftrittsverhalten eines Prozesses beschrieben, d. h. in welchen Tagesabschnitten ein
Prozess mit welchen Ankunftsraten angestoßen wird (vgl. Abb. 8.8). Im Gegensatz zur
Pfad- und Belastungsanalyse simuliert die Auslastungsanalyse auf der Zeitachse und ist
somit eine zeitablaufbezogene Betrachtung.
Eines der Hauptergebnisse der Auslastungsanalyse ist die Ermittlung von dynami-
schen Wartezeiten im Prozessablauf. Die Personal- und Sachressourcen stehen nur
anhand ihrer definierten Menge und in der in den Kalendern spezifizierten Zeit zur
Verfügung. Wird aufgrund der Prozesskalender eine Arbeitslast erzeugt (Menge von
Aktivitäten), die durch die vorgegebenen Ressourcen nicht zeitgerecht abgearbeitet wer-
den kann, so entstehen bei den Aktivitäten überhöhte Wartezeiten, die sich wiederum in
einer verlängerten Durchlaufzeit des Prozesses niederschlagen.
Die Auslastungsanalyse unterstützt bei der Beantwortung der Frage „Welche Prozess
menge kann eine Organisation mit gegebener Ressourcenzahl unter Einhaltung eines vor-
gegebenen Service-Level bearbeiten?“ bzw. „An welchen Stellen in einer Organisation treten
Engpässe auf, die sich in unnötig langen Warte- und Prozessdurchlaufzeiten niederschla-
gen?“. Die Stellen mit überhöhter Auslastung sind anschließend die Anknüpfungspunkte,
um durch Verbesserungen zu einer adäquaten Auslastung und damit zu verbesserten
Prozessdurchlaufzeiten zu kommen.
8.4.2.3 Animation
Die quantitative Prozessanalyse kann um Mittel der Animation ergänzt werden, um
zusätzlich auch eine visuelle Analyse zu unterstützen. Es werden dabei zwei Arten der
Animation unterschieden.
Bei der geschlossenen Animation werden während der Auswertung kein Benutzereingriff
und keine Veränderung der zugrunde liegenden quantitativen Parameter vorgenommen.
Die Animation visualisiert den Ergebnisverlauf oder das Verhalten eines Prozesses oder
auch des Prozessumfelds während der Durchführung einer Auswertung. In Abb. 8.9 (links)
sieht man bspw. die Entwicklung der Prozessdurchlaufzeit während eines Simulationslaufs.
Man kann im Bild deutlich erkennen, dass die Durchlaufzeit zu Beginn der Simulation
stark oszilliert und sich dann mit steigender Anzahl von Simulationsläufen sukzessive
dem erwarteten Wert annähert („einschwingt“). Dies kann u. a. dazu genutzt werden,
um zu identifizieren, wie viele Simulationsläufe benötigt werden, um zu einer validen
Ergebnisaussage zu kommen.
Auf der rechten Seite in Abb. 8.9 sieht man ein Beispiel zur Animation von Stellen
in einer Organisation, denen Prozessaktivitäten zur Ausführung zugeteilt sind. Die
Schreibtische symbolisieren die Stellen, die kleinen Vierecke neben und auf den
Schreibtischen die Aktivitäten, die noch vor der Ausführung im Wartestapel der Stelle
liegen bzw. bereits von der Stelle bearbeitet werden.
Bei der interaktiven (offenen) Animation kann während der Auswertung vom Benutzer
Einfluss genommen werden. Dies reicht von einfachen Fällen, in denen der Benutzer aus
einer vorgegebenen Anzahl von Alternativen während der Animation eine auswählen
00:000:00:35:00
00:000:00:32:30
00:000:00:30:00
Abb. 8.9 Beispiele visueller Animationen: Durchlaufzeitentwicklung und Arbeitslast von Stellen
Abb. 8.10 Interaktive Prozessanimation
kann, bis hin zu Änderungen von Input-Parametern während der Auswertung, die dann
zu einer Veränderung im Ergebnisverlauf führen können und damit dem Benutzer hel-
fen, wichtige diagnostische Größen zu erkennen. Abbildung 8.10 zeigt ein Beispiel einer
interaktiven Prozessanimation, bei der ein konkreter Prozessverlauf durch schrittwei-
ses Markieren des Prozesspfads animiert wird. Bei Entscheidungsalternativen wird der
Benutzer gefragt, welche der möglichen Alternativen gewählt werden soll, um damit
Einfluss auf den Prozessablauf zu nehmen. Zusätzlich zum Bereich der Prozessanalyse
werden solche Prozessanimationen auch im Bereich des Prozesstrainings eingesetzt, um
Mitarbeiter auf bevorstehende Prozessänderungen vorzubereiten.
8.4.2.4 Hybride Analyse
In der hybriden Analyse werden Techniken der dynamischen und statischen Analyse
kombiniert eingesetzt. Das typische Vorgehen ist dabei der Einsatz der dynamischen
Analyse, um gewünschte quantitative Ergebnisgrößen zu ermitteln. Auf den Ergebnissen
der dynamischen Analyse werden dann mit zielgerichteten Abfragen der statischen
Analyse bestimmte Sachverhalte extrahiert.
Ein typisches Beispiel einer hybriden Analyse ist die Ermittlung von Durchlaufzeiten
und Personalauslastungen für eine Menge von Prozessalternativen auf Basis der
Prozesssimulation, aus denen dann anschließend mit Abfragen diejenigen ermittelt werden,
die die geringste Durchlaufzeit bei gleichzeitig geringstem Personalaufwand aufweisen.
Literatur
BOC (2012) ADONIS Version 5.1. Band II: Benutzerhandbuch, Benutzerhandbuch. BOC
Information Technologies Consulting AG, Wien
Herbst J, Junginger S, Kühn H (1997) Simulation in Financial Services with the Business Process
Management System ADONIS. In: Society for Computer Simulation (SCS) (Hrsg) Proceedings
of the 1997 European Simulation Symposium (ESS’97), S 491–495
Herbst J, Karagiannis D (2000) Integrating Machine Learning and Workflow Management to
Support Acquisition and Adaptation of Workflow Models. Intell Syst Account Finance Manag
9(2):67–92
Junginger S (1998) Quantitative Bewertung von Geschäftsprozeßmodellen: Eine Gegenüberstellung
von Rechnerischer Auswertung und Simulation. BPMS-Bericht, Abteilung Knowledge Engineering,
Universität Wien, Wien
Junginger S, Kühn H, Bayer F, Karagiannis D (2004) Workflow-based Business Monitoring. In:
Fischer L (Hrsg) Workflow Handbook 2004. Future Strategies, S 65–80
Kühn H, Karagiannis D (2001) Modellierung und Simulation von Geschäftsprozessen. WISU 30
(8–9/01):1161–1170
Petri C-A (1962) Kommunikation mit Automaten. Dissertation, Institut für instrumentelle
Mathematik, Universität Bonn, Bonn
Rabe M, Knothe T (2010) Geschäftsprozess-Simulation. In: Jochem R, Mertins K, Knothe T (Hrsg)
Prozessmanagement, Symposion, Düsseldorf, S 473–490
Reisig W (2010) Petrinetze: Modellierungstechnik, Analysemethoden, Fallstudien. Vieweg + Teubner,
Berlin
Senge P-M (2011) Die fünfte Disziplin, 11. Aufl. Schäffer-Poeschel, Stuttgart
Sterman J-D (2000) Business Dynamics: Systems Thinking and Modeling for a Complex World.
McGraw-Hill Higher Education, Kingsport
van der Aalst W-M-P (2011) Process Mining: Discovery, Conformance and Enhancement of
Business Processes. Springer, Berlin
Prozessbasierte
Personalbedarfsermittlung 9
Marcus Landgraf und Manfred Lenhardt
Zusammenfassung
Die Personalbedarfsermittlung als Grundlage für alle Planungs- und Umsetzungsschritte
im Rahmen des betrieblichen Personalmanagements ist der Ausgangspunkt für die
Verfügbarkeit der Ressource „Mitarbeiter“ im notwendigen Umfang und in der ent-
sprechenden Qualifikation in den Arbeitsprozessen einer Organisation. Im vorlie-
genden Kapitel werden ausgehend von einem Grundmodell erweiterte Parameter der
Aufbau- und Ablauforganisation betrachtet. Mithilfe dieser Parameter wird Schritt für
Schritt eine prozessbasierte Personalbedarfsermittlung etabliert. Auf Basis der entwi-
ckelten Berechnungsmodelle werden neben funktionalen und prozessualen Auswer
tungsmöglichkeiten die Ermittlung und Gestaltung der verschiedenen Modellparameter
erläutert. Ausgewählte Fragestellungen, die im Rahmen einer Personalbedarfsermittlung
behandelt werden müssen, bilden den Abschluss dieses Kapitels.
9.1 Einleitung
9.1.1 Überblick
Im vorliegenden Kapitel wird eine prozessbasierte Personalbedarfsermittlung (P-PBE)

betrachtet. Bei einer P-PBE wird konsequent auf Geschäftsprozesse als Basis für die
Ermittlung der notwendigen Parameter zur Berechnung von Personalkapazitäten
M. Landgraf (*)
e-mail: marcus.landgraf@boc-eu.com
M. Lenhardt

160 M. Landgraf und M. Lenhardt
abgestellt. Daraus resultiert, dass die ermittelten Ergebnisse immer einen strikten Bezug
zu den Prozessen der Organisation besitzen.
Im Kontext des Prozessmanagements ist die P-PBE ein weiterführendes Thema, das
entsprechend fortgeschrittenes Wissen über das Managen von Prozessen bedingt. Das
aktuelle Kapitel befasst sich mit grundsätzlichen Fragestellungen, die im Kontext einer
P-PBE durch eine Organisation betrachtet werden müssen.
Für die erstmalige Durchführung einer P-PBE in einer Organisation bietet dieses
Kapitel Hilfestellung bei der Projektvorbereitung. Für Organisationen, in welchen eine
Personalbedarfsermittlung bereits etabliert ist, kann das Kapitel als Grundlage für eine
Reflektion der bestehenden Ablauf- und Aufbauorganisation zur Durchführung einer
Personalbedarfsermittlung genutzt werden.
Eingeleitet wird das Kapitel durch die Motivation für den Einsatz und Umsetzung
einer P-PBE (vgl. Abschn. 9.1.2). Ergänzt wird die Einleitung durch Abgrenzungen
und Definitionen zur P-PBE (vgl. Abschn. 9.1.3). Auf Ergebnisarten sowie auf die
notwendigen Parameter für die Berechnung der Personalbedarfe wird in den
anschließenden Abschnitten eingegangen (vgl. Abschn. 9.2 und 9.3). Im Anschluss
wird die Erhebung der Berechnungsparameter näher erläutert (vgl. Abschn. 9.4). Die
Betrachtung von Fragestellungen, welche bei der Umsetzung einer P-PBE berück-
sichtigt werden müssen, bildet den Schwerpunkt des abschließenden Abschnitts
(vgl. Abschn. 9.5).
9.1.2 Motivation der prozessbasierten Personalbedarfsermittlung
In einem globalen, vor allem auf Kosten basierenden wirtschaftlichen Wettbewerb ist
der kosteneffiziente Einsatz der Produktionsfaktoren ein wesentlicher Erfolgsfaktor.
Der Faktor „Personal“ als einer der kostenintensivsten Produktionsfaktoren ist dabei
von besonderer Bedeutung. Dabei ist nicht ausschließlich die reine Arbeitskapazität
von Interesse. Im Besonderen muss neben der Arbeitskapazität auch die entsprechende
Qualifikation, welche für die Erledigung der geplanten Arbeit notwendig ist, im entspre-
chenden Umfang zur Verfügung stehen. Ein Stillstand der Personalkapazitäten muss im
Rahmen einer kosteneffizienten Produktion und Dienstleistungserbringung möglichst
vermieden werden.
Das Konzept „Just in time“, welches auf einem kontinuierlichen prozessorientier-
ten Bearbeitungsverfahren mit möglichst geringem Stillstand der Produktionsfaktoren
und des Produktionsgegenstands abzielt, ist in der Industrie seit langer Zeit Praxis.
Dienstleistungsbereiche, in welchen just in time ebenfalls seit vielen Jahren als
Grundlage für die Personalbedarfsplanung zum Einsatz kommt, sind bspw. Callcenter
und der Konsumgütervertrieb in Form von großen (Super-)Märkten. Beobachtet wer-
den kann, dass just in time auch in hochqualifizierten Dienstleistungssektoren immer
häufiger zum Einsatz kommt (vgl. bspw. die Entwicklung der Arbeitsorganisation im
Finanzsektor oder in der Softwareentwicklung).
9 Prozessbasierte Personalbedarfsermittlung 161
Eine effektive Ermittlung und Planung des notwendigen Personalbedarfs im Kontext

der Qualifikation und des Kapazitätsumfangs muss auf den Grundlagen des operativen
Produktions- und Dienstleistungsverfahrens aufsetzen. Damit motivieren die obigen
Ausführungen die weitere Betrachtung der prozessbasierten Personalbedarfsermittlung
in diesem Kapitel.
9.1.3 Abgrenzungen und Definitionen
Die Einordnung der Personalbedarfsermittlung als ein Instrument im betriebswirtschaft-

lichen Personalmanagement ist Gegenstand dieses Kapitels.
Definition
Personalmanagement umfasst alle Aktivitäten, die in einer Organisation im Zusam
menhang mit der betriebswirtschaftlichen Planung und Umsetzung von personalrele-
vanten Fragestellungen auftreten.
Die Personalbedarfsplanung ist ein Bestandteil des Personalmanagements. Im Besonderen

lassen sich für die Personalplanung im Rahmen des Personalmanagements die folgenden
Phasen identifizieren (Gabler Verlag 2013b):
• Ermittlung des geplanten Personalbedarfs

• Planung der Personalbeschaffung
• Planung der Personalentwicklung
• Planung des Personaleinsatzes
• Planung der Personalfreisetzung
Der Ermittlung des Personalbedarfs als Grundlage für alle weiteren Personalplanungs-
Phasen sowie der anschließenden operativen Umsetzung durch die verantwortlichen
Führungskräfte kommt eine Schlüsselfunktion im gesamten Personalmanagement zu.
Die eben vorgenommene Einordnung und Abgrenzung im Rahmen des Personalma
nagements führt uns zu weiteren Definitionen im Kontext der Personalbedarfsermittlung.
Definition
Unter einer Personalbedarfsermittlung wird die „Festlegung des Arbeitskräftepotenzials
[verstanden], das ein Unternehmen momentan bzw. zu einem zukünftigen Zeitpunkt in
quantitativer und qualitativer Hinsicht benötigt, um die geplanten Aktivitäten durch-
führen zu können“ (Gabler Verlag 2013a).
Definition
Unter einem Prozess (synonym: Geschäftsprozess) wird eine Abfolge von Aktivitäten
verstanden, die von Akteuren durchgeführt und zur Erstellung eines definierten
Ergebnisses benötigt werden. Innerhalb der Aktivitäten werden Artefakte, wie z. B.

Formulare oder Informationen, unter Zuhilfenahme von Ressourcen bearbeitet (vgl.
ebenso Abschn. 2.1.1 sowie (Junginger 2000; Kühn und Karagiannis 2001)).
Aus diesen Definitionen wird eine Definition für die prozessbasierte Personalbedarfs
ermittlung abgeleitet.
Definition
Die prozessbasierte Personalbedarfsermittlung umfasst die Festlegung des Arbeits
kräftepotenzials, welches zur Erstellung eines definierten Ergebnisses als Abfolge
geplanter Aktivitäten in einem Prozess unter Zuhilfenahme quantitativer und qualitati-
ver Ressourcen benötigt wird.
Wie bereits zu Beginn dieses Kapitels ausgeführt, steht der (vollständige) Prozess im
Mittelpunkt der Personalbedarfsermittlung. Daraus resultiert, dass alle Parameter, wie
bspw. Mengen oder Zeiten, welche in die Berechnung des Personalbedarfs einbezogen
werden sollen, auf Basis eines Prozesses erhoben werden müssen. Die Konsequenz für
die größtmögliche Granularität von Ergebnissen in der P-PBE ist, dass diese immer den
Personalbedarf eines einzelnen Prozesses reflektieren.
Andere Formen der Personalbedarfsermittlung, bspw. eine aktivitäts- oder produkt-
basierte, erzwingen die Ermittlung der Berechnungsparameter auf entsprechend unter-
schiedlichen Basen. Die Ergebnisse können als größtmögliche Granularität immer nur
die gewählte Grundbasis reflektieren.
9.2 Berechnungsmodelle in der prozessbasierten

Personalbedarfsermittlung
In der Personalbedarfsermittlung werden mathematische Modelle eingesetzt, um

die Ergebnisse in Form von Kapazitätsinformationen für die Beantwortung von
Fragestellungen im Kontext von zu erwartenden Personalbedarfen zu analysieren,
zu bewerten und zu planen. Eine Entscheidung durch das Management bildet den
Abschluss der Phase zur Personalbedarfsermittlung. Diese Entscheidung muss die Frage
beantworten, welche der ermittelten Personalbedarfskapazitäten soll die Grundlage für
die weiteren Personalplanungsphasen sein.
Beginnend mit einem Grundmodell zur Ermittlung des Personalbedarfs wird
anschließend auf mögliche Erweiterungen des Grundmodells eingegangen.
9.2.1 Grundmodell der Personalbedarfsermittlung
Das Grundmodell der Personalbedarfsermittlung kann durch nachstehende Formel

repräsentiert werden:
GAZ = M × t oder Gesamtarbeitszeit = Menge × Zeit (9.1)
Damit wird der rechnerische Personalbedarf in Form einer Gesamtarbeitszeit (GAZ),

in Minuten, ermittelt. Die erforderlichen Berechnungsparameter sind eine Menge als
Anzahl sowie die Zeit in Minuten, die für die Bearbeitung der angegebenen Menge erfor-
derlich ist.
Im Rahmen der hier betrachteten P-PBE ist die Basis für den Mengenwert ein Prozess.
Der Parameter Menge ist also eine Prozessmenge (PM). Da die Gesamtarbeitszeit im
Kontext der Personalbedarfsermittlung üblicherweise für ein Jahr ermittelt wird, muss
die Prozessmenge einen Jahreswert repräsentieren. Irrelevant ist, ob die Prozessmenge
aufgrund einer Schätzung, einer Hochrechnung oder als ein automatisch ermittelter
Wert, bspw. aus einem Workflow-System, zur Verfügung gestellt wird. Zu berücksich-
tigen ist, dass das Ermittlungsverfahren über die qualitative „Härte“ der Prozessmenge
unmittelbar die qualitative Aussagekraft der berechneten Gesamtarbeitszeit beeinflusst.
Die in der Berechnung verwendete Zeit bezieht sich auf die Zeitdauer, die für die
Bearbeitung eines Prozessdurchlaufs (ein einzelner Prozess) benötigt wird. Diese Zeit
wird als Bearbeitungszeit (BZ) bezeichnet und definiert sich als die Zeitdauer, welche
notwendig ist, das Produkt oder die Dienstleistung durch den Prozess „vom Anfang bis
zum Ende“ zu bearbeiten.
Der Anfang eines Prozesses ist jener (Umwelt-)Zustand, der als Auslöser für den Start
eines Prozessdurchlaufs definiert ist.
Beispiel
Im Fall eines Callcenters kann ein Auslöser bspw. die Entgegennahme eines Telefon-
anrufs durch einen Agenten sein. Im Zusammenhang mit der Entwicklung von Soft-
ware stellt bspw. die Anforderung eines Hotfixes einen Prozessauslöser dar. Mit einem
Hotfix wird üblicherweise die Behebung eines technischen Fehlers bezeichnet, der die
laufende Produktion gefährdet. Fast immer müssen diese Fehlerklassen just in time
einer Lösung zugeführt werden.
Das Bearbeitungsende ist durch die Verfügbarkeit des definierten Prozessergebnisses

gekennzeichnet.
Beispiel
Im Fall des Callcenters wäre dies der Zeitpunkt des Auflegens oder des Gesprächsen-
des, ggf. inkl. der notwendigen Dokumentationsarbeiten durch den Agenten. Im Fall
des Hotfixes können die technische Verfügbarkeit, der erfolgreiche Test oder sogar der
produktive Rollout des Hotfixes mögliche Endzeitpunkte darstellen.
Wesentlich für die hier notwendige Bearbeitungszeit ist die Unterbrechungsfreiheit.

Gemeint ist, dass Zeiten, die aufgrund von Unterbrechungen auftreten (bspw. durch ein
kurzes Gespräch mit einem Kollegen), nicht in die Bearbeitungszeit eingehen dürfen.
Wir sprechen im Kontext der P-PBE daher auch von der Netto-Bearbeitungszeit (net-
toBZ) eines Prozesses.
Die bisherigen Erläuterungen führen zu einer Präzisierung des ursprünglichen
Grundmodells, in welchem eine Jahres-Gesamtarbeitszeit (JGAZ) berechnet wird:
Jahres-Gesamtarbeitszeit = Prozessmenge × Netto-Bearbeitungszeit
oder
JGAZ = PM × nettoBZ (9.2)
Das hier vorgestellte Grundmodell kann in zunehmend komplexer werdenden
Organisationen nur für einen begrenzten, lokalen Prozess Gültigkeit besitzen. Im
Kontext der Jahres-Gesamtarbeitszeit ergibt sich u. a. die Frage: Wie viele Arbeitstage
umfasst ein Arbeitsjahr? Beispielsweise müssen Unternehmen, die in Deutschland bun-
desweit agieren mit einer Schwankungsbreite von mehreren Arbeitstagen umgehen, die
sich aufgrund regional unterschiedlicher Feiertage ergibt.
Bei der Durchführung einer P-PBE muss das Grundmodell auf die jeweiligen organisa-
torischen Gegebenheiten angepasst werden. Dies führt im hier betrachteten Kontext zu ver-
schiedenen Erweiterungen des Grundmodells, die Gegenstand des folgenden Abschnitts sind.
9.2.2 Erweiterte Modelle in der Personalbedarfsermittlung
In der Realität stößt das Grundmodell sehr rasch an seine Grenzen, um die komplexen
Fragestellungen einer P-PBE adäquat zu unterstützen. Im Folgenden werden grund-
legende Modellparameter vorgestellt, die helfen, die Komplexität der Realität für die
P-PBE im Berechnungsmodell beherrschbar zu machen.
Die folgenden Modellparameter werden vorgestellt und das Grundmodell anschlie-
ßend um den jeweiligen Parameter erweitert:
• Anzahl der Prozesse,

• Qualifikation,
• Jahresarbeitszeit und
• Kapazitäten der Leitungs- und Führungsanteile.
Zu beachten ist, dass die Liste der möglichen Modellparameter nicht abschließend ist.
Vielmehr muss für jede Organisation entschieden werden, welche und in welcher Form
relevante Modellparameter berücksichtigt werden sollen (vgl. ebenso Abschn. 8.3.2).
Eine Organisation ist im prozessualen Kontext niemals eindimensional. In der
Realität besteht eine Organisation immer aus einer Vielzahl an operativen Prozessen,
die in der P-PBE berücksichtigt werden müssen. Diese prozessuale Mehrdimensionalität
kann durch die Erweiterung des Grundmodells berücksichtigt werden:

n
JGAZ = (PMi × nettoBZi ) (9.3)
i=1
Es ist selbstredend, dass mit einer steigenden Anzahl von Prozessen das Rechenverfahren
langwieriger wird. Problematisch ist allerdings weniger die Dauer des Rechenverfahrens,
als die Vielzahl an validen Prozessmengen, die von der Organisation erhoben und
zur Verfügung gestellt werden müssen. Fragestellungen, die sich im Rahmen der
Datenerhebung zu den einzelnen Parametern ergeben, werden in Abschn. 9.4 behandelt.
Die Anzahl der notwendigen Mengenwerte ist ein weiterer Grund für die Empfehlung
einer P-PBE. Würde die Personalbedarfsermittlung auf der Ebene von Aktivitäten eines
Prozesses erfolgen, wäre der Umfang an notwendigen, validen Mengenwerten noch ein-
mal um ein Vielfaches größer als auf der Prozessebene.
Ein weiteres Thema im operativen Tagesgeschäft ist der Umstand, dass Prozesse
nicht immer von der gleichen Person durchgeführt werden. Es handelt sich immer um
Individuen, die mit unterschiedlichen Attributen, bspw. in Bezug auf Qualifikation,
Erfahrung oder Bearbeitungsgeschwindigkeit, ausgestattet sind. Erschwerend kommt
hinzu, dass auch das einzelne Individuum kein konstantes Verhalten in Bezug auf die ange-
führten Attribute aufweist. In Abhängigkeit der jeweiligen Tageszeit, der aktuellen beruf-
lichen und außerberuflichen sowie individuellen Stresssituation(en) und vielen weiteren
möglichen Einflussgrößen mehr wirken diese Attribute laufend auf die individuelle Netto-
Bearbeitungszeit pro Prozessdurchlauf ein. Als Vereinfachung wird im weiteren Verlauf
nur mehr von der unterschiedlichen Qualifikation gesprochen. Der Begriff „Qualifikation“
subsumiert die verschiedenen, hier beispielhaft angeführten, Einflussgrößen.
Die Folge ist eine große Bandbreite der Netto-Bearbeitungszeiten, die im Rahmen der
Prozessbearbeitung auftreten und beobachtet werden können. Der damit entstehende
Komplexitätsgrad ist kein zielführendes Vorgehen bei der Abbildung der Realität mit
Hilfe eines Modells. Ein Modell wird bewusst zur Reduktion der realen Komplexität auf
ein gewolltes Minimum gewählt. Aufgrund der Komplexitätsreduktion können sehr effi-
zient Entscheidungspotenziale für mögliche reale Szenarien identifiziert und kommuni-
ziert werden.
Eine Lösung für dieses Problem ist der Einsatz von durchschnittlichen Bear
beitungszeiten (øBZ). Mit der durchschnittlichen Bearbeitungszeit können die unter-
schiedlichen Qualifikationen im Berechnungsmodell adäquat berücksichtigt werden.
Ein weiterer Parameter, der in unserem Berechnungsmodell berücksichtigt werden
soll, ist die Anzahl der unterschiedlichen Prozesspfade und die pro Pfad zugeordnete
Prozessmenge (PfM, für die Prozesspfadmenge), die über den jeweiligen Prozesspfad
„läuft“. Mit diesem Parameter kann dem Umstand Rechnung getragen werden, dass
neben der Qualifikation auch der jeweilige Prozesspfad wesentlichen Einfluss auf die
durchschnittliche Bearbeitungszeit nimmt.
Beispiel
Ein Antragsprozess tritt 1.000 Mal pro Monat auf, d. h. die Prozessmenge (PM) ist 1.000
pro Monat. Innerhalb des Prozesses gibt es zwei mögliche Pfade, d. h. die Anzahl der
unterschiedlichen Prozesspfade ist 2. Pfad 1 betrifft den Fall, dass der Antrag angenommen
wird und hat eine Wahrscheinlichkeit von 80 %. Pfad 2 betrifft den Fall, dass der Antrag
abgelehnt wird und hat eine Wahrscheinlichkeit von 20 %. Damit ist die Prozesspfad-
menge (PfM) von Pfad 1 800 pro Monat und die PfM von Pfad 2 200 pro Monat.
Wir erweitern das Berechnungsmodell um die Parameter der durchschnittlichen

Bearbeitungszeit und der Prozesspfadmenge. Dabei gilt, dass die Laufvariable i einen
konkreten Prozess repräsentiert und die Laufvariable j für einen Prozesspfad und die
korrespondierende durchschnittliche Bearbeitungszeit des Prozesspfads steht:
n
m

JGAZ = PfMij × øBZij (9.4)
i=1 j=1
Die Jahresarbeitszeit (JAZ), die als ein weiterer Parameter auf die Gestaltung des
Berechnungsmodells einwirkt, ermöglicht die Interpretation der rechnerisch ermittel-
ten Jahres-Gesamtarbeitszeit als Jahreskapazität. Nur aufgrund der Jahreskapazität kann
die beispielhafte Aussage „… 10,5 Personalkapazitäten pro Jahr werden benötigt …“
getroffen werden. Die Definition der Jahresarbeitszeit als zweistufiger Parameter ist im
Rahmen des gewählten Berechnungsmodells von großer Bedeutung.
Definition
Die Jahresarbeitszeit ist jene Zeitsp§anne, die eine Personalkapazität in Vollzeit durch-
schnittlich pro Kalenderjahr einer Organisation produktiv zur Verfügung stehen kann.
Die maximale Jahresarbeitszeit wird begrenzt durch die Unternehmensarbeitszeit.
Auf eine formale Darstellung (Formel) der Jahresarbeitszeit wird an dieser Stelle verzich-
tet. In der Realität wird der konkrete Wert der Jahresarbeitszeit durch die Organisation
festgelegt und nivelliert damit mögliche Ausprägungen der Jahresarbeitszeit, die sich auf-
grund unterschiedlicher Dienstverträge ergeben können. Die Jahresarbeitszeit ist in der
Personalbedarfsermittlung eine Rechengröße, die in den Phasen Personalbeschaffung
und Personaleinsatz auf die realen Gegebenheiten, den individuellen Dienstvertrag,
Rücksicht nehmen muss.
Definition
Die Unternehmensarbeitszeit ist jener zeitliche Umfang von max. einem Kalenderjahr,
den eine Organisation gewillt ist, Produkte herzustellen und Dienstleistungen zur
Verfügung zu stellen.
Die Unternehmensarbeitszeit (UAZ) kann maximal 525.600 Arbeitsminuten pro

Kalenderjahr betragen. Das entspricht 365 Arbeitstagen bei einer Dauerproduktion von
24 Arbeitsstunden zu jeweils 60 Arbeitsminuten (vgl. ebenso Abschn. 9.4.4).
Die Berechnung der Jahres-Gesamtarbeitszeit erfolgt meistens in der Maßeinheit
„Minuten“. Der Personalbedarf wird allerdings fast immer in der Maßeinheit „Kapazitäten“
auf Jahresbasis ermittelt. Dies erleichtert die Ergebnisinterpretation und die weiterführende
Nutzung der Personalbedarfsermittlungs-Ergebnisse, bspw. als Grundlage für die weiteren
Phasen in der Personalplanung.
Wir erweitern das Berechnungsmodell und stellen den Fokus von einer Jahres-
Gesamtarbeitszeit auf eine berechnete Kapazität auf Basis der gewollten Unternehmensar
beitszeit um und berechnen mithilfe der folgenden Formel die Jahres-Unternehmenskapazität
(JUKAP).
n m
PfMij × øBZij
JGAZ i=1 j=1
(9.5)
JUKAP = oder JUKAP =
UAZ UAZ
Die Berechnung der Jahres-Unternehmenskapazität (JUKAP) ermöglicht den Einsatz des

Berechnungsmodells auch als Planungswerkzeug. Eine Änderung der Prozessmenge (PM)
auf einen erwarteten oder geplanten Wert ermöglicht eine Aussage über die rechnerisch
notwendige Kapazität in Bezug auf das vorhandene (Referenz-)Unternehmen. Die errech-
nete Jahres-Unternehmenskapazität gibt an, wie häufig die korrespondierenden eingesetzten
Ressourcen zur Verfügung gestellt werden, um die angegebenen (Plan-)Mengen bei der ange-
führten durchschnittlichen Bearbeitungszeit (øBZ) nach einem Jahr produziert zu haben.
Auf (Teil-)Unternehmensebene werden diese Arten von Planungswerkzeugen vor allem
im Bereich der Investitions- und Grenzkostenrechnung (Poggensee 2009, S. 107 ff.) eingesetzt.
Im Kontext des Prozessmanagements bewegen wir uns damit im Bereich der Prozessoptimie
rung. Sehr häufig ist ein Parameter in der Prozessoptimierung die Vorgabe von monetä-
ren oder zeitlichen Grenzwerten, die im Rahmen eines Optimierungszyklus unterschritten
werden sollen. Gelingt dies, erhöht sich der effiziente Einsatz der Produktionsfaktoren bei
gleichzeitiger Steigerung der Produktivität unter Vermeidung von hohen Investitionskosten.
Weiterführende Erläuterungen zur Prozessoptimierung sind in Kap. 8, 10 und 11 zu finden.
Für den Produktionsfaktor „Personal“ begrenzt die Unternehmensarbeitszeit die
maximal mögliche Jahresarbeitszeit. Mehr als die Unternehmensarbeitszeit kann von
einer einzelnen Personalkapazität nominell nicht geleistet werden. Nach unten wird die
Jahresarbeitszeit durch den frei gestaltbaren Dienstvertrag begrenzt. Wie groß der frei
gestaltbare Handlungsspielraum bei Dienstverträgen ist, hängt vom jeweiligen Sektor,
internationalen und nationalen Gesetzen sowie den regionalen Gepflogenheiten ab.
Die Erweiterung des Berechnungsmodells um den Parameter „Jahresarbeitszeit“
(JAZ) ermöglicht eine Aussage über die notwendigen Personalbedarfskapazitäten pro
(Arbeits-)Jahr. Diese errechneten Kapazitäten für eine Jahresproduktion auf Basis von
Vollzeitkapazitäten erhöhen die Aussagekraft unseres Modells zur Personalbedarfs
ermittlung entscheidend. Wir erweitern das Berechnungsmodell und ermitteln die
Jahres-Personalbedarfskapazität (JPBKAP):
m
n
PfMij × øBZij
i=1 j=1
JUKAP UAZ
JPBKAP = oder JPBKAP = (9.6)
JAZ JAZ
Mit Hilfe des bisher entwickelten Berechnungsmodells können beliebige Planszenarien

für die Personalbedarfskapazitäten (JPBKAP) auf Vollzeitbasis ermittelt werden. Als
Grundlage für die weiteren Planungsphasen Personalbeschaffung, Personalentwicklung,
Personaleinsatz und Personalfreisetzung stellt die P-PBE strategische Informationen für
die laufende Organisationsgestaltung und -steuerung zur Verfügung. Diese Phasen sind
jedoch nicht weiter Inhalt des vorliegenden Kapitels.
Eine (vorerst) letzte hier vorgestellte Erweiterung betrifft die Kapazitäten der
Leitungs- und Führungsanteile (im Folgenden kurz: Führungsaufgaben). In den bis-
herigen Ausführungen wurde keine Abgrenzung zwischen den operativen und füh-
rungsspezifischen Prozessinhalten gemacht. Bei der Durchführung einer P-PBE stehen
die operativen Jahreskapazitäten in der Regel im Mittelpunkt des Interesses. Dies ist
für die Führungskapazitäten nicht immer der Fall. Oft genug ist dies aber lediglich
dem Umstand geschuldet, dass es in der Realität als zu schwierig angesehen wird,
valide Werte vor allem für die Bearbeitungszeiten bei Führungskräften zu erheben.
Über das Einbringen von Konstanten in das Berechnungsmodell werden wir dieser
Problemstellung begegnen. Die fachlichen Grundlagen hierfür können dem Verfahren
„Arbeitsplatzmethode“ (Bundesministerium des Innern in Zusammenarbeit mit dem
Bundesverwaltungsamt 2013, S. 141 f.) entnommen werden.
Vereinfacht dargestellt, werden bei der Arbeitsplatzmethode keine Mengen
und Bearbeitungszeiten berücksichtigt. Es wird davon ausgegangen, dass die per
Arbeitsplatzmethode berücksichtigten Kapazitäten auf jeden Fall notwendig sind und
daher „gesetzt“ werden können. Das finale Berechnungsmodell wird auf Basis der folgen-
den Annahmen erstellt:
• Eine Führungskraft wird „reduziert“ auf die expliziten Führungsprozesse bzw.

Prozessteile, die ausschließlich von der Führungskraft erbracht werden können, bspw.
Mitarbeitergespräche oder Personaladministration etc.
• Arbeitsinhalte, die von einer Führungskraft auf Basis der Qualifikation eines
Sachbearbeiters oder Produktionsmitarbeiters im laufenden, operativen Tagesgeschäft
erbracht werden, werden nicht berücksichtigt. Diese Prozessmengen und -zeiten wer-
den im Berechnungsmodell bei den entsprechenden Qualifikationen berücksichtigt,
bspw. die Kundenberatung in der Qualifikation „Sachbearbeiter“ oder die Erstellung
von Programmcode in der Qualifikation „Programmierer“.
• Für die verschiedenen Führungsebenen, bspw. Teamleitung, Abteilungsleitung oder
Bereichsleitung, werden die führungsrelevanten Arbeitsanteile (FA) als Faktor einer
Vollzeitkapazität zwischen 0 und 1 festgelegt.
• Ebenfalls festgelegt werden die Führungsspannen (FSP) für die verschiede-
nen Führungsebenen. Die Führungsspanne beschreibt die maximale Anzahl der
Mitarbeiter, die von einer Führungskraft geführt werden soll.
Damit definiert sich das (vorläufig) finale, erweiterte Berechnungsmodell für die hier
vorgestellte P-PBE als Gesamt-Jahres-Personalbedarfskapazität (Gesamt-JPBKAP), die
sich aus der operativen Jahres-Personalbedarfskapazität (JPBKAP) zuzüglich der dafür

benötigten Führungskapazität pro Führungsebene i zusammensetzt:

n
JPBKAP × FAi
Gesamt-JPBKAP = JPBKAP + (9.7)
FSPi
i=1
Zu beachten ist, dass die hier vorgestellte Berücksichtigung der Führungskapazitäten

ein relativ einfaches Modell darstellt. Zu Gunsten der Verständlichkeit und Lesbarkeit
wurde auf die Berücksichtigung der Führungskapazitäten als weitere Eingangsgröße in
der jeweils nächsthöheren Führungshierarchie verzichtet.
Die Ausführungen zu den Berechnungsmodellen werden mit dem Hinweis abge-
schlossen, dass es sich bei den vorgestellten Modellparametern um grundlegende
Parameter handelt. Damit ist gemeint, dass zumindest für diese Parameter eine konzep-
tionelle Auseinandersetzung im Rahmen einer P-PBE vorgenommen werden muss. Eine
szenariospezifische Erweiterung der Parameter ist möglich.
9.3 Ergebnisdarstellung in der prozessbasierten

Im Mittelpunkt der bisherigen Ausführungen zur P-PBE standen die Berechnungs

modelle. Nun ändert sich der Fokus und wir wenden uns der Darstellung der
Ergebnisse unter verschiedenen Gesichtspunkten zu. Beginnend mit der prozessualen
Ergebnisdarstellung werden auch funktionale und gemischte Ergebnisrepräsentationen
erläutert.
9.3.1 Prozessbasiertes Ergebnis
Im Mittelpunkt der prozessbasierten Ergebnisse steht die Ablauforganisation, die

über verschiedene Aggregationsstufen die berechneten Personalbedarfe für Prozess
landkarten, Teil-Prozesslandkarten, Prozessgruppen und Prozesse darstellt (vgl. ebenso
Kap. 3).
Neben den verschiedenen prozessualen Aggregationsstufen muss eine prozess-
basierte Ergebnisdarstellung zumindest die operativen Personalbedarfskapazitäten
(JPBKAP) wiedergeben. Da die ermittelten Personalbedarfe als Grundlage für stra-
tegische Entscheidungen sowie als Unterlagen für die nachfolgenden Phasen in der
Personalplanung dienen, wird empfohlen, die Ergebnisdarstellung mit Hilfe der in
Tab. 9.1 dargestellten Modellparameter umzusetzen.
In Tab. 9.2 wird ein Beispiel für eine reale Ergebnisausprägung aus dem Bankenbereich
gegeben.
Tab. 9.1 Parameter der prozessbasierten Ergebnisdarstellung der P-PBE

PM Prozessmenge als Anzahl
øBZ durchschnittliche Bearbeitungszeit in Minuten
JGAZ Jahresgesamtarbeitszeit in Minuten
JPBKAP Jahres-Personalbedarfskapazität in Personalkapazitäten pro Arbeitsjahr
Tab. 9.2 Beispiel einer prozessbasierten Ergebnisdarstellung

PM øBZ JGAZ JPBKAP
1. GP Vertrieb 1.486.350 16,02
1.1 GP Allgemein 301.467 3,25
1.1.1 GP Backoffice durchführen 18.529 16,27 301.467 3,25
1.1.2 …
1.2 GP Privatkredite 853.645 9,20
1.2.1 GP Immobilienkredite 541.994 5,84
1.2.1.1 GP Immobilienkauf beraten 264 770,24 203.343 2,19
1.2.1.2 GP Bauspardarlehen beraten 823 215,41 177.282 1,91
1.2.1.3 GP Sanierung beraten 1.373 117,53 161.369 1,74
1.2.2 GP Konsumkredite 311.650 3,36
1.2.2.1 GP Kontorahmen beraten 3.728 9,23 34.409 0,37
1.2.2.2 GP Sonstige Kredite beraten 8.541 32,46 277.241 2,99
1.2.n … … … … …
1.3 Gewerbliche Kreditprozesse 331.239 3,57
1.3.n … … … … …
Beispiel
In Tab. 9.2 wird die Beratung eines Bauspardarlehens (vgl. „1.2.1.2 GP Bauspardarle-
hen beraten“) 823 Mal pro Jahr durchgeführt. Die durchschnittliche Beratungsdauer
von ca. 3,5 Stunden (215,41 min/60 min) führt zu einem Arbeitsaufwand von ca. 369
Arbeitstagen bei 8 Arbeitsstunden pro Tag (177.282 min/(8 × 60 min)). Unter der
Annahme, dass die durchschnittliche Nettoarbeitszeit eines Bankmitarbeiters pro Jahr
193,30 Tagen entspricht, ergibt sich sodann ein Personalbedarf von ca. 1,91 Mitarbei-
terkapazitäten pro Jahr (369 Jahresarbeitsaufwand in Tagen/193,30 Nettoarbeitstage
pro Jahr).
Die hierarchische Aggregation der Ergebnisse beginnt auf der Ebene von Einzelprozessen
(bottom-up) und steht für die Ergebnisanalyse sowohl top-down als auch bottom-up
zur Verfügung. Die prozessbasierte Ergebnisdarstellung inklusive der Prozessmengen
und durchschnittlichen Bearbeitungszeiten wird häufig als Ausgangspunkt einer

Prozessoptimierung genutzt.
Leicht nachvollziehbar ist, dass die Ergebnisdarstellung der P-PBE in der hier vorge-
stellten Art und Weise die Entscheidungsprozesse auf allen Führungsebenen (operativ,
taktisch und strategisch) mit entsprechenden Informationen unterstützen kann.
Neben der prozessorientierten Ergebnisdarstellung sind Informationen über die rech-
nerisch ermittelten Kapazitäten im Kontext der erwarteten Qualifikationen ein weiterer
Schwerpunkt in der P-PBE. Die entsprechende Ergebnisdarstellung ist Inhalt des folgen-
den Abschnitts.
9.3.2 Funktionales Ergebnis
Neben den Ergebnissen für die Ablauforganisation ist die Sicht auf die Aufbau
organisation von besonderem Interesse. Funktionale Ergebnisse repräsentieren die
erwarteten Kapazitäten einer dezidierten Qualifikation. Die Bedarfe zu den verschie-
denen Qualifikationen sind eine grundlegende Eingangsgröße für die nachfolgen-
den Phasen in der Personalplanung. In diesen Phasen stehen die Beschaffung, die
Entwicklung sowie der operative Einsatz von entsprechend qualifiziertem Personal im
notwendigen Umfang im Mittelpunkt. In der Freisetzungsphase ist darauf zu achten,
dass benötigte Qualifikationen ggf. länger in der Organisation verbleiben.
Um funktionale Ergebnisse in der P-PBE nutzen zu können, muss im Berech
nungsmodell ein Parameter für die Verteilung der Prozessmenge auf die möglichen pro-
zessbearbeitenden Qualifikationen berücksichtigt werden. Wird dieser Parameter im
Berechnungsmodell nicht berücksichtigt, dann kann die funktionale Ergebnisdarstellung
nur für jene Prozesse eingesetzt werden, in welchen eine 1:1-Beziehung zwischen
Prozess und Qualifikation gegeben ist. Auf die Ergebnisdarstellung dieser einfachen
Konstellation wird bewusst verzichtet.
In der Realität sind meistens komplexere Varianten im Zusammenwirken von
Prozessen und Qualifikationen anzutreffen. Diese komplexeren Varianten entsprechen
einer der folgenden Konstellationen:
• Prozesse 1:n Qualifikationen,

• Prozesse m:1 Qualifikationen und
• Prozesse m:n Qualifikationen.
Im Gegensatz zu den prozessbasierten Ergebnissen sind ausschließlich die errech-

neten Kapazitäten pro Qualifikation als Jahreskapazität (JPBKAP) von Interesse.
Prozessmengen (PM) und durchschnittliche Bearbeitungszeiten stellen in der funktiona-
len Ergebnisrepräsentation keinen Mehrwert dar.
Tab. 9.3 Beispiel einer funktionalen Ergebnisdarstellung

JPBKAP
1. Vertriebsabteilung 16,02
1.1 Bereich Vertriebsunterstützung 4,21
1.1.1 Sachbearbeiter Vertriebsunterstützung 1,99
1.1.2 Bearbeiter Vertriebsunterstützung 2,21
1.2 Bereich Privatkunden 11,81
1.2.1 Team Immobilien 9,61
1.2.1.1 Sachbearbeitung Immobilien 6,36
1.2.1.2 Bearbeitung Immobilien 3,25
1.2.2 Team Privatkunden allg. 2,20
1.2.2.1 Sachbearbeitung Privatkunden allg. 1,27
1.2.2.2 Bearbeiter Privatkunden allg. 0,93
Beispiel
Tabelle 9.3 zeigt eine reale Ergebnisausprägung. In dem angeführten Beispiel werden
von der Qualifikation „1.2.1.2 Bearbeitung Immobilien“ 3,25 Mitarbeiterkapazitäten
pro Jahr benötigt. Eine Aussage über den Arbeitsinhalt dieser Qualifikation ist in der
gewählten Ergebnisrepräsentation nicht möglich, auch nicht gewollt.
Gut erkennbar ist, dass sowohl eine Aggregation als auch ein Drill down der Personalbedarfe
über die verschiedenen Organisationsebenen, bspw. Qualifikation, Gruppe, Team, Abtei
lung, Bereich etc., möglich ist. Auf diese Art und Weise können Grundlagen wieder für alle
Entscheidungsebenen (strategisch, taktisch und operativ) zur Verfügung gestellt werden.
Ein wichtiges Kriterium für die Qualität des Berechnungsverfahrens ist, dass egal aus
welchem Blickwinkel die Ergebnisse der P-PBE betrachtet werden, funktional oder pro-
zessbasiert, das Gesamtergebnis immer identisch sein muss. In dem hier vorgestellten
Beispiel ist das jeweils eine Jahres-Personalbedarfskapazität (JPBKAP) von 16,02.
Bereits erwähnt wurde, dass die bisher vorgestellten Ergebnisrepräsentationen unter-
schiedliche Vor- und Nachteile aufweisen. Die Vorstellung einer Mischform für die
Ergebnisrepräsentation vereint die jeweiligen Vorteile.
9.3.3 Ergebnisse als Mischformen
Die bisher vorgestellten Ergebnisrepräsentationen legen den jeweiligen Darstellungs

schwerpunkt entweder auf die Ablauforganisation oder auf die Aufbauorganisation. Mit
der Kombination der beiden Sichten steht eine gemischte Ergebnisrepräsentation zur
Verfügung, in welcher das Ergebnis der P-PBE aus beiden Blickwinkeln in einer gemein-
samen Ergebnisdarstellung betrachtet werden kann.
In Tab. 9.4 findet sich eine beispielhafte Darstellung für eine reale Ergebnis
ausprägung zur P-PBE als Mischform. Wie bereits in Abschn. 9.3.2 ausgeführt, finden
wir in der Realität meistens komplexe Kombinationen von Prozessen und den durch-
führenden Qualifikationen. Um die Ergebnisse entsprechend der hier vorgestellten
Mischform repräsentieren zu können, muss das zugrunde liegende Berechnungsmodell
speziellen Anforderungen genügen.
Berechnungsmodell bei Mischformen

Tabelle 9.4 gliedert sich in die Bereiche:
• Ablauforganisation (Prozesse),
• Verteilung der Qualifikation sowie
• Aufbauorganisation.
Die Bereiche Ablauf- und Aufbauorganisation beinhalten Informationen und Daten, die
bereits bei der Entwicklung von Berechnungsmodellen in Abschn. 9.2.2 erläutert wurden.
Der Bereich „Verteilung der Qualifikation“ führt zur Etablierung eines weiteren
Parameters für das zugrunde liegende Berechnungsmodell. Dieser Parameter wird als
„Qualifikationsverteilung pro Prozess“ (QVP) bezeichnet. Wie aus Tab. 9.4 ersichtlich
ist, ist der QVP ein Faktor, der die ermittelten Prozesskapazitäten auf die vorhandenen
Qualifikationen verteilt.
Die errechnete Jahres-Personalbedarfskapazität (JPBKAP) von 2,19 für den Prozess
„1.2.1.1 GP Immobilienkauf beraten“ verteilt sich mit 1,64 Vollzeitkapazitäten auf
die Qualifikation „1.2.1.1 Sachbearbeitung Immobilien“ bei einem QVP von 75 %.
Die verbleibenden 0,55 Vollzeitkapazitäten werden aufgrund des QVP von 25 % der
Qualifikation „1.2.1.2 Bearbeitung Immobilien“ zugerechnet.
Da die in der P-PBE zugrunde gelegte Prozessmenge (Arbeitsmenge pro Jahr) inner-
halb der Unternehmensarbeitszeit (Arbeitsjahr) vollständig abgearbeitet werden muss,
ergeben sich für das Berechnungsmodell zwei Qualitätsparameter, mit deren Hilfe die
rechnerische Validität des ermittelten Ergebnisses sehr einfach überprüft werden kann:
• Für den Parameter QVP gilt, dass die Summe aller QVP zu einem Prozess gleich
100 % sein muss.
• Die ermittelte Jahres-Personalbedarfskapazität (JPBKAP) aus dem Blickwinkel der
Prozesssicht (Ablauforganisation) muss ident sein mit dem Ergebnis aus Sicht der
Qualifikationen (Aufbauorganisation). In Tab. 9.4 entspricht dies einer Vollzeitkapazität
von 16,02.
So einfach der rechnerische Zusammenhang zwischen den berechneten Kapazitäten und

den verfügbaren Qualifikationen ist, umso spannender kann sich die Erhebung der ein-
zelnen QVP in der Realität gestalten.
Tab. 9.4 Beispiel der Ergebnisse einer P-PBE als Mischformen

Ablauforganisation
PM øBZ JGAZ JUKAP JPBKAP
1. GP Vertrieb 1.486.350 16,02 100 %

1.1 GP Allgemein 301.467 3,25
1.1.1 GP Backoffice durchführen 18.529 16,27 301.467 301.466,83 3,25 0%
1.1.2 GP … … … … …
1.2 GP Privatkredite 853.645 9,20
1.2.1 GP Immobilienkredite 541.994 5,84
1.2.1.1 GP Immobilienkauf beraten 264 770,24 203.343 203.343,36 2,19 0%
1.2.1.2 GP Bauspardarlehen beraten 823 215,41 177.282 177.282,43 1,91 0%
1.2.1.3 GP Sanierung beraten 1.373 117,53 161.369 161.368,69 1,74 0%
1.2.2 GP Konsumkredite 311.650 3,36
1.2.2.1 GP Kontorahmen beraten 3.728 9,23 34.409 34.409,44 0,37 0%
1.2.2.2 GP Sonstige Kredite beraten 8.541 32,46 277.241 277.240,86 2,99 0%
1.2.n … … … … …
1.3 Gewerbliche Krediteprozesse 331.239 331.238,88 3,57 0%
1.3.n … … … … …
Ergebnisrepräsentation bei Mischformen

Die Ergebnisrepräsentation einer P-PBE in Mischform muss zumindest die
Ablauforganisation und die Aufbauorganisation darstellen und wäre damit im Vergleich
zu der gewählten Darstellungsform in Tab. 9.4 kompakter. Die in Tab. 9.4 gewählte
Darstellungsform, inklusive dem Bereich „Verteilung der Qualifikation“, ist eine erwei-
terte Ergebnisrepräsentation gegenüber der Mindestdarstellung und deckt aus unserer
Sicht den „idealen“ Informationsgehalt einer P-PBE ab.
Verteilung der Qualifikation Aufbauorganisation

1.1.1 Sachbearbeiter Vertriebsunterstützung
1.1.1 Sachbearbeiter Vertriebsunterstützung

1.2.2.1 Sachbearbeitung Privatkunden allg.
1.2.2.1 Sachbearbeitung Privatkunden allg.

1.1.2 Bearbeiter Vertriebsunterstützung
1.1.2 Bearbeiter Vertriebsunterstützung

1.2.2.2 Bearbeiter Privatkunden allg.
1.2.1.1 Sachbearbeitung Immobilien
1.2.1.1 Sachbearbeitung Immobilien

1.1 Bereich Vertriebsunterstützung
1.2.2.2 Barbeiter Privatkunden allg.

1.2.1.2 Bearbeitung Immobilien
1.2.1.2 Bearbeitung Immobilien
1.2.2 Team Privatkunden allg.

1.2 Bereich Privatkunden
1.2.1 Team Immobilien

1. Vertriebsabteilung
16,02 4,21 1,99 2,21 11,81 9,61 6,36 3,25 2,20 1,27 0,93
3,25 3,25 1,07 2,18 0,00 0,00 0,00 0,00 0,00 0,00 0,00
33 % 67 % 0% 0% 0% 0% 3,25 3,25 1,07 2,18 0,00 0,00 0,00 0,00 0,00 0,00 0,00
… … … … … … … … … … … … … … … … …
9,20 0,96 0,92 0,04 8,24 6,04 3,68 2,36 2,20 1,27 0,93
5,84 0,55 0,55 0,00 5,29 5,29 3,38 1,91 0,00 0,00 0,00
0% 0 % 75 % 25 % 0% 0% 2,19 0,00 0,00 0,00 2,19 2,19 1,64 0,55 0,00 0,00 0,00
15 % 0 % 50 % 35 % 0% 0% 1,91 0,29 0,29 0,00 1,62 1,62 0,96 0,67 0,00 0,00 0,00
15 % 0 % 45 % 40 % 0% 0% 1,74 0,26 0,26 0,00 1,48 1,48 0,78 0,70 0,00 0,00 0,00
3,36 0,41 0,37 0,04 2,95 0,75 0,30 0,45 2,20 1,27 0,93
20 % 10 % 0% 0 % 20 % 50 % 0,37 0,11 0,07 0,04 0,26 0,00 0,00 0,00 0,26 0,07 0,19
10 % 0 % 10 % 15 % 40 % 25 % 2,99 0,30 0,30 0,00 2,69 0,75 0,30 0,45 1,94 1,20 0,75
… … … … … … … … … … … … … … … … …
3,57 0,00 0,00 0,00 3,57 3,57 2,68 0,89 0,00 0,00 0,00
… … … … … … … … … … … … … … … … …
Mit den hier vorgestellten Darstellungsbereichen können die nachgelagerten Phasen

der Personalplanung mit den relevanten Informationen unterstützt werden. Vor allem die
Informationen zur Qualifikationsverteilung können in den folgenden Einsatzszenarien
eine wichtige Grundlage für die weitere Entscheidungsfindung darstellen:
• Im Prozessmanagement können diese Informationen als Input für fachliche, organi-

satorische und technische Prozessoptimierungen dienen.
• Die Untersuchung und Begleitung der Frage, ob die spezifische Ausprägung der
Generalisierung und Spezialisierung in einem einzelnen Prozess oder in der gesam-
ten Prozessarchitektur gewollt ist, kann untersucht und begleitet werden. Dieses
Einsatzszenario ist häufig von strategischer Bedeutung und nimmt Einfluss auf alle
Phasen der Personalplanung.
9.4 Erhebung der Berechnungsparameter
In den vorangegangenen Abschnitten wurden die möglichen Berechnungsmodelle sowie

die Repräsentation von Ergebnissen im Rahmen der P-PBE erläutert. Dieses Kapitel wid-
met sich der Fragestellung der Erhebungsverfahren ausgewählter Parameter, die von
grundsätzlicher Bedeutung für die Berechnung einer P-PBE sind. Explizit hingewiesen
wird darauf, dass die Erhebung weiterer Parameter in Analogie zu den hier vorgestellten
Erhebungsverfahren möglich ist.
In Abhängigkeit der gewollten oder notwendigen Ergebnisgranularität der P-PBE
müssen mehr oder weniger Parameter erhoben und periodisch aktualisiert werden.
Beispielsweise sind die Anzahl der notwendigen Unternehmens- und Jahresarbeitszeiten,
aber auch der Umfang an zu betrachtenden Prozessen und Qualifikationen unmittelbare
Treiber für die Anzahl von zu erhebenden Prozessmengen und Bearbeitungszeiten.
Der Erhebungsaufwand für eine Vielzahl von Parametern in der P-PBE ist umso gerin-
ger, je umfangreicher prozessbasierte Anwendungen eingesetzt werden, bspw. in Form
von Workflow-Systemen oder prozessbasierten Management-Informationssystemen. Im
Umkehrschluss gilt, dass der zu leistende Aufwand für die Ermittlung und Festlegung der
entsprechenden Parameterwerte umso höher ausfällt, je geringer der Einsatz von prozess-
basierten Systemen in der täglichen Arbeit der jeweiligen Organisation ist.
In der Realität zeigt sich, dass im Rahmen einer P-PBE eine Kombination von
unterschiedlichen Erhebungsverfahren und -quellen zum Einsatz kommen muss.
Welche Verfahren und Quellen zur Verfügung stehen, ist situationsbedingt zu ent-
scheiden. Unterschiedlich valide Verfahren und Quellen sind meist für geschlossene
Teilorganisationen in Bezug auf das eingesetzte operative IT-System zu beobachten.
9.4.1 Geschäftsprozesse
Eine P-PBE ist ohne die Identifikation der Prozesse, für welche die Kapazitäten der
Personalbedarfe ermittelt werden sollen, nicht möglich (vgl. ebenso Abschn. 9.1.3).
Da die Prozesse bildlich betrachtet das Fundament der P-PBE darstellen, wird auf die
Erhebung dieses Parameters kurz eingegangen.
Grund für die knappe Erläuterung ist die Tatsache, dass den Themen der
Prozessidentifikation und Prozesserhebung eigenständige Kapitel im Rahmen des vorlie-
genden Buchs gewidmet sind (vgl. Abschn. 3.4, Kap. 5, 6 sowie Abschn. 11.4).
Da im Rahmen der P-PBE kein unmittelbares Interesse an der Ablaufdarstellung

von Prozessinhalten besteht, ist die Verfügbarkeit der Prozesslandkarte in Form
einer Aufzählung der Einzelprozesse ausreichend (vgl. hierzu die Strukturierung der
Tab. 9.2). Auch die hierarchische Gliederung der Einzelprozesse über verschiedene
Aggregationsstufen hinweg ist keine zwingende Voraussetzung für die P-PBE (vgl.
ebenso Tab. 9.2). Unbestrittener Weise unterstützt die hierarchische Gliederung die
Interpretation und Aussagekraft der Ergebnisse und wird daher empfohlen.
9.4.2 Bearbeitungszeiten
Die Bearbeitungszeit ist einer von lediglich zwei Parametern, welcher ein zwingender
Bestandteil in Berechnungsmodellen für jede Art von Personalbedarfsermittlungen ist
(vgl. ebenso Abschn. 9.2.1).
Prinzipiell stehen die folgenden Verfahren zur Erhebung von Bearbeitungszeiten zur
Verfügung:
• Schätzungen,
• automatisierte Messungen,
• teilautomatisierte Messungen oder
• manuelle Messungen.
Aus Sicht der Autoren sind Schätzungen kein valides Verfahren, um eine aussagekräf-
tige P-PBE zu etablieren. Die P-PBE hat im Rahmen der gesamten Personalplanung
eine Schlüsselfunktion (vgl. ebenso Abschn. 9.1.3). Schätzungen als Basis einer
Schlüsselfunktion sind unbedingt zu vermeiden.
Messungen verbleiben als einzige Verfahren, welche valide Grundlagen für die
Ermittlung von durchschnittlichen Bearbeitungszeiten zur Verfügung stellen können.
Die Validität der erhobenen Messwerte steht in unmittelbarem Zusammenhang mit dem
eingesetzten Messverfahren.
Automatisierte Messungen basieren auf Zeitwerten, die vollautomatisiert von einem
technischen System erfasst wurden, bspw. durch ein Workflow-System. Eine gesonderte
Interaktion durch den Anwender ist nicht erforderlich. Im Rahmen der P-PBE wer-
den diese Daten maximal einer Analyse zur Eliminierung von technisch nicht korrek-
ten Messungen unterzogen, welche bspw. durch einen Systemabsturz oder technische
Verarbeitungsfehler, entstehen können. Nachteile hat dieses Messverfahren bei den fol-
genden Konstellationen:
• Sind die technischen Messpunkte nicht sauber im Vergleich zu den Prozessen der
Prozesslandkarte abgegrenzt, dann kann eine Zuordnung der einzelnen Messwerte zu
den relevanten Prozessen, und damit die Gestaltung einer validen durchschnittlichen
Bearbeitungszeit pro Prozess, schwierig werden.
• Liegen die technischen Messpunkte zu „weit“ voneinander entfernt, dann können unter
Umständen gewollte Unterbrechungen nicht als solche erkannt werden. Bspw. ist beim
Start eines weiteren Prozesses die Messung des ursprünglichen Prozesses zu unterbre-
chen und erst wieder fortzusetzen, wenn die Bearbeitung wieder aufgenommen wird.
• Unterbrechungen der Bearbeitung durch äußere Einflüsse, vor allem durch persönli-
che Verteilzeiten (vgl. ebenso Abschn. 9.4.4), sind kaum erkennbar.
Den Nachteilen bei der automatisierten Messung kann über den Einsatz von teilautoma-
tisierten Messungen begegnet werden. Im Rahmen von teilautomatisierten Messungen
der durchschnittlichen Bearbeitungszeit startet und stoppt der Mitarbeiter die jeweilige
Messung selbstständig. Unterstützt wird der Mitarbeiter dabei durch eine „intelligente“
IT- bzw. datenbankgestützte Stoppuhr. Unter der hier gemeinten Intelligenz wird bspw.
verstanden,
• dass dem Mitarbeiter nur jene Prozesse zur Verfügung stehen, die er in der Realität
auch bearbeiten kann.
• dass Prozesse beliebig oft unterbrochen und zur weiteren Bearbeitung wieder gestartet
werden können.
• dass Bearbeitungszeiten von Prozessen, die vom Mitarbeiter nicht eindeutig als been-
det markiert wurden, nicht als gültige Messung interpretiert werden.
• dass durchschnittliche Bearbeitungszeiten pro Prozess, ggf. auch pro Qualifikation,
automatisch berechnet werden.
Ein wesentlicher Nachteil der teilautomatisierten Verfahren sind mögliche Fehler, deren
Ursache im Verhalten des Mitarbeiters liegt oder durch einen Dritten bereits im Vorfeld
der Messung hervorgerufen wurde. Beispiele hierfür sind eine falsche Auswahl des
Messprozesses durch den Mitarbeiter oder eine zu grob geschnittene Prozesslandkarte.
Das letzte Messverfahren, die manuelle Messung, unterscheidet sich von der teilauto-
matisierten Messung vor allem durch die unterstützenden Messinstrumente. Diese sind
eine Stoppuhr und „Papier“. Papier in dem hier gemeinten Kontext kann auch jede Art
von Datei sein, die für eine manuelle Aufzeichnung der Messdaten eingesetzt wird. Die
„intelligente“ Nutzung der unterstützenden Messinstrumente obliegt ausschließlich dem
Mitarbeiter. Die Nachteile dieses Systems sind evident:
• Beispielsweise muss die gesamte Administration der verschiedenen Messvorgänge

inklusive Unterbrechungen und erneutem Start bei der Weiterbearbeitung von
Prozessen durch den Mitarbeiter manuell und selbstständig durchgeführt werden.
• Die Bearbeitungszeit eines einmalig oder mehrmalig unterbrochenen Prozesses ist
nach dem endgültigen Prozessabschluss aus den einzelnen Teilmessungen manuell zu
berechnen.
• Die Verdichtung von durchschnittlichen Bearbeitungszeiten, gemessen durch verschie-
dene Mitarbeiter, muss manuell über das Zusammenführen von „Papier“ erfolgen.
Als Abschluss zu diesem Abschnitt wird angeführt, dass in der Realität die Festlegung
von durchschnittlichen Bearbeitungszeiten in sinnvoller Art und Weise nur mit Hilfe
von automatisierten oder teilautomatisierten Messungen erfolgen kann. Die Bildung von
durchschnittlichen Bearbeitungszeiten auf Basis einer manuellen Messung ist nur für
eine geringe Anzahl von Prozessen oder in einer Pilotphase zielführend.
9.4.3 Mengen
Auf den ersten Blick erscheint die Verfügbarkeit und Nutzung von Mengeninformationen
eine relativ triviale Aufgabe zu sein. Diese Trivialität verliert sich häufig bei einer genau-
eren Betrachtung der verfügbaren Quellen über Mengeninformationen. In den meis-
ten Fällen ist die eindeutige Zuordnungsmöglichkeit zwischen mengenspezifischen
Informationsquellen und den Prozessen in der P-PBE schwach ausgeprägt.
Am ehesten ist die eindeutige Beziehung zwischen mengenspezifischen Informations
quellen und den Prozessen beim Einsatz eines Workflow-Systems zu beobachten. Hier
wird die Anzahl der Startvorgänge pro Prozess protokolliert. Diese Protokolle können,
ggf. auch für mehrere Jahre, als Basis für die Bildung von prozessbasierten, durchschnitt-
lichen oder erwarteten Jahresmengen herangezogen werden.
Die eindeutige Korrelation zwischen mengenspezifischen Informationsquellen und
den Prozessen in der P-PBE ist auch bei entsprechenden IT-Anwendungen nicht immer
vollständig gegeben. Je geringer die fachliche und technische Beziehung zwischen den
eingesetzten IT-Systemen und den realen Prozessen ausgeprägt ist, umso geringer ist die
eindeutige Zuordenbarkeit von Mengen aus den Informationsquellen zu den Prozessen.
In den bisherigen Ausführungen wurden zwei Aspekte angesprochen, die bei der
Ermittlung von Mengen eine wesentliche Rolle spielen und näher betrachtet werden
müssen. Diese Aspekte sind die fachliche und die technische Prozesszuordnung von men-
genspezifischen Informationsquellen.
Fachliche Aspekte
Die erste Frage, die sich im Rahmen der P-PBE stellt, ist „Für welche Prozesse müssen
Mengen erhoben werden?“. Einen ersten Anhaltspunkt zur Klärung dieser Frage bietet
die Prozesslandkarte als maximale Ausprägung der fachlichen Prozesse. Prozesse, die
nicht Bestandteil der Prozesslandkarte sind, sind in der P-PBE nicht zu berücksichtigen.
Eine weitere Einschränkungsmöglichkeit der Prozesse, die für die P-PBE
von Bedeutung sind, kann die Gliederung der Prozesslandkarte, bspw. nach der
Kategorisierung von Kern-, Unterstützungs- und Managementprozessen, darstellen (vgl.
ebenso Abschn. 2.1.1). Zumindest die Kernprozesse sollten Bestandteil der P-PBE sein.
Ist die Frage nach den Prozessen geklärt, führt das konsequenterweise zur Frage
„Was soll gezählt werden?“. Klar ist, dass die Zählung von Prozessmengen in einem
eindeutigen Zusammenhang mit dem zu zählenden Prozess stehen muss. Der ein-
fachste Zählpunkt ist das Ende eines Prozesses. Hier bietet sich aufgrund der Definition
eines Prozesses (vgl. ebenso Abschn. 9.1.3) mit Hilfe der Prozessergebnisse ein idea-
ler Zählpunkt an. Können Prozessergebnisse nicht eindeutig einem Prozess zugeordnet
werden, dann handelt es sich um eine Fragestellung der korrekten Verteilung auf die
Prozesse (vgl. hierzu die Ausführungen zu den technischen Aspekten). Ggf. kann das
Schneiden der Prozesslandkarte bspw. über die Definition eines Teilprozesses entspre-
chend überarbeitet werden.
In Prozessen, die mehr als nur ein Ergebnis zur Verfügung stellen können, erfolgt
die Zählung der verschiedenen Endergebnisse analog zu einem Einzelergebnis. In die-
sen Konstellationen muss allerdings auf die korrekte Berechnung der durchschnittli-
chen Bearbeitungszeit geachtet werden. Dieses Szenario kann über die Berücksichtigung
der Entscheidungen, an welchen über das abschließende Prozessergebnis entschieden
wird, abgebildet werden (vgl. hierzu auch den Parameter Prozesspfadmenge (PfM) im
Abschn. 9.2.2).
Ein weiterer Zählpunkt, der die Aussagekraft der P-PBE erhöhen kann, ist der
Prozessstart. Eine Zählung des Prozessstarts ist häufig durch einen oder mehrere
Auslöser möglich. Die Ausführungen zur Zählung von Prozessergebnissen gelten analog.
Sind die fachlichen Aspekte geklärt, können die technischen Aspekte zur Erhebung
von Mengeninformationen betrachtet werden.
Technische Aspekte
Typischerweise wird der Personalbedarf als jährliche Vollzeitkapazität auf Basis
der Jahresmenge eines Prozesses berechnet. Die Prozessmengen müssen daher als
Jahreswerte zur Verfügung stehen.
Eine grundsätzliche technische Zielsetzung muss es sein, dass die Mengen automa-
tisch aus IT-Systemen abgefragt oder berechnet werden können. Keine Organisation
kann es sich aus Kosten- und Zeitgründen leisten, eine laufende, manuelle Zählung über
einen längeren Zeitraum oder auf Dauer zu etablieren. Eine manuelle Zählung kann
maximal im Rahmen einer fachlichen Evaluierung von Mengeninformationen durchge-
führt werden.
Über die fachlichen Aspekte wurden die Zählpunkte „Prozessende“ und „Prozessstart“
zur Ermittlung von Prozessmengen identifiziert. Aus welchen IT-Systemen können aber in
massenverarbeitenden Organisationen entsprechende Prozessmengen abgefragt werden?
Für produzierende Organisationen ist dies (meistens) relativ einfach zu bewerkstel-
ligen. Über ERP- oder Lagerhaltungs-Systeme stehen sehr gute Informationen über die
ein- und ausgehenden Vor-, Teil- und Endprodukte zur Verfügung. Über den Input der
Vor- und Teilprodukte als Auslöser eines Prozesses sowie die Prozessergebnisse als Teil-
oder Endprodukte werden diese häufig hoch automatisiert bspw. per Barcode erfasst.
Für service- oder dienstleistungsorientierte Organisationen ist ein analoges Vorgehen
nur dann möglich, wenn ein workflowbasiertes IT-System eingesetzt wird. Ist dies
nicht der Fall, müssen im Rahmen der P-PBE Alternativen identifiziert werden, die
einen möglichst hohen Grad an automatisierten prozessualen Mengenermittlungen
gewährleisten.
Alternative IT-Systeme, die bei der automatisierten Ermittlung von Prozessmengen

berücksichtigt werden können, sind bspw.:
• Scansysteme, die physische Post in elektronische Akten transformieren,

• datenbankbasierte Bestandssysteme,
• Rechnungslegungs-Systeme,
• elektronische Verarbeitungsdaten von oder an Dritte(n), wie z. B.
– Web-Applikationen,
– EDI-basierte Systeme (Electronic Data Interchange-basierte Systeme),
– Batchläufe oder
– Bank-Zahlbänder,
• Druckdaten und -ströme,
• E-Mail- und Fax-Server oder
• ACD-Anlagen (Automatic Call Distribution-Anlagen).
Die Aufzählung erhebt keinen Anspruch auf Vollständigkeit. Allen Quellen ist gemein,
dass eine Ermittlung der Prozessmengen meist nur über verschiedene Transformations-
und Aggregationsschritte möglich ist.
Die Ausführungen zu den Mengenerhebungen werden mit einem Hinweis auf die
Messung der Bearbeitungszeiten als Quelle für Prozessmengen abgeschlossen. Dies ist
vor allem dann möglich, wenn flächendeckende Zeitmessungen über einen adäquaten
Zeitraum stattfinden.
9.4.4 Jahresarbeitszeit
In Abschn. 9.2.2 wurden im Kontext der Arbeitszeit die Parameter Unternehmensarbeitszeit

und Jahresarbeitszeit eingeführt. Der aktuelle Abschnitt erläutert die Berechnung sowie die
Festlegung der beiden Rechenparameter.
Die Unternehmensarbeitszeit kann maximal 525.600 Arbeitsminuten pro Kalenderjahr
betragen (vgl. Abschn. 9.2.2). Beispielsweise werden Unternehmensarbeitszeiten,
die in der Industrie mit einem durchgängigen Jahresschichtmodell möglich sind, im
Finanzdienstleistungssektor kaum anzutreffen sein. Weitere Determinanten bei der
Gestaltung der Unternehmensarbeitszeit sind internationale und nationale Gesetze,
wie bspw. die Fahrverbotszeiten im Transportwesen. Nicht zuletzt nehmen auch
regionale Gegebenheiten, wie z. B. Feiertage, erheblichen Einfluss auf die mögliche
Unternehmensarbeitszeit. Unter Berücksichtigung der hier angeführten Determinanten
ist ein Wert für die Unternehmensarbeitszeit zu definieren.
Am Beispiel der deutschen Bankarbeitstage (Deutsche Bundesbank 2012, S. 4) werden
Auswirkungen auf die Unternehmensarbeitszeit in ausgewählten Städten dargestellt (vgl.
Tab. 9.5).
Die Festlegung der Jahresarbeitszeit unterliegt zumindest den gleichen Determi
nanten, die bereits im Kontext der Unternehmensarbeitszeit erläutert wurden.
Tab. 9.5 Ausgewählte regionale Bankarbeitstage in Deutschland

Berlin Köln München
Kalendertage 365 365 365
Ø Wochenendtage –104 –104 –104
Gesetzliche Feiertage –9 –9 –9
Geschäftsfreie Tage („Bankfeiertage“) –2 –2 –2
Heiligabend und Silvester
Regionale Feiertage 0 –2 –4
bspw. Heiligedreikönigstag
Brauchtumstage 0 –1 0
bspw. Rosenmontag
(Innenministerium des Landes Nordrhein-West-
falen 2007, S. 100 f.)
Bankarbeitstage 250 247 246
Besondere Aufmerksamkeit muss dem Umstand der durchschnittlichen Verfügbarkeit

einer Personalkapazität beigemessen werden. An dieser Stelle werden ein mögliches
Berechnungsverfahren und die zugehörigen Parameter vorgestellt.
Das in Tab. 9.6 vorgestellte Rechenverfahren orientiert sich am Berechnungsverfahren
zur Jahresarbeitszeit einer Normalarbeitskraft (Bundesministerium des Innern in
Zusammenarbeit mit dem Bundesverwaltungsamt 2013, S. 160 ff.) und ist ein mögliches
Berechnungsverfahren zur Ermittlung der Jahresarbeitszeit.
Allen Berechnungsverfahren gemeinsam ist, dass die Ausgangsbasis ein Kalenderjahr
(365 Tage) ist. Verschiedene Sonderkonstellationen, die sich bspw. aufgrund eines
Schaltjahres ergeben, werden hier nicht berücksichtigt. Damit ist die Anzahl der
Wochenendtage mit 104 ebenfalls als Konstante zu betrachten.
Tab. 9.6 Berechnungsverfahren zur Ermittlung der Jahresarbeitszeit

Tage pro Kalenderjahr
− abzüglich Wochenendtage
− abzüglich Feiertage
− abzüglich Krankheitstage
− abzüglich Urlaubstage
1. Bruttoarbeitszeit pro Jahr
− abzüglich Fortbildungstage
2. Bruttoarbeitszeit pro Jahr
− abzüglich Verteilzeiten
Nettoarbeitszeit pro Jahr
Diffiziler wird es im Hinblick auf die Feiertage, die durchschnittlich pro Jahr anfallen.
Die beispielhaften Ausführungen im Kontext der Bankarbeitstage (vgl. Tab. 9.5) sind ein
Einflussfaktor, der zu berücksichtigen ist. Ein weiterer Faktor ist das „Wandern“ von Fei
ertagen im Ablauf eines Kalenderjahrs. Damit gemeint ist, dass nicht alle Feiertage jährlich auf
einen Arbeitstag fallen, sondern im Ablauf der Jahre auch auf Wochenenden fallen können.
Welche Möglichkeiten stehen zur Verfügung, um die durchschnittlichen Feiertage
pro Kalenderjahr zu berücksichtigen?
• Explizite Berechnung der Feiertage für jene Periode, für die eine P-PBE durchgeführt
werden soll
• Ermittlung der durchschnittlichen Feiertage in den letzten Jahren
• Nutzung von offiziellen Referenzwerten, welche durch Branchenvertretungen oder
öffentliche Behörden bekannt gegeben werden
Für die Parameter „Krankheitstage“ und „Urlaubstage“ gelten analog die Ausführungen
zum Parameter „Feiertage“. Quellen, die sich für die beiden angeführten Parameter
häufig zusätzlich nutzen lassen, sind entsprechende Statistiken, welche in der
Personalabteilung der Organisation geführt werden.
Die bisher betrachteten Parameter werden von den 365 ursprünglichen Kalendertagen
abgezogen. Das errechnete Teilergebnis ist eine erste Bruttoarbeitszeit, die für viele
Branchen und Regionen eine ähnliche Ausprägung erfahren kann.
Der Parameter „Fortbildungstage“ führt meistens zu einer Individualisierung der
Jahresarbeitszeit im Vergleich zu ähnlichen Organisationen. Grund hierfür ist die oft
unterschiedliche strategische Ausrichtung im Hinblick auf wissensintensive oder weni-
ger wissensintensive Arbeitsprozesse in Organisationen,
• die in der gleichen oder einer ähnlichen Branche aktiv sind,

• in der gleichen Region angesiedelt sind oder
• gleichartige Kundengruppen und Märkte bedienen.
Nach Abzug der Fortbildungstage erhält man ein weiteres Bruttoergebnis, welches
ggf. noch um den Faktor Verteilzeiten reduziert wird, um die Nettoarbeitszeit einer
Personalkapazität auf Vollzeitbasis zu erhalten.
Lediglich erwähnt wird an dieser Stelle, dass sich die Verteilzeit aus den sachlichen
und persönlichen Verteilzeiten zusammensetzt. Während die sachlichen Verteilzeiten
immer Bestandteil der gemessenen Bearbeitungszeiten sind, ist die Festlegung der per-
sönlichen Verteilzeiten fast immer eine Herausforderung im Rahmen der P-PBE.
Die Festlegung einer organisationsweit gültigen persönlichen Verteilzeit kann sinn-
voller Weise nur über die explizite Messung und die Bildung eines entsprechenden
Durchschnittswerts oder über den Einsatz von pauschalen Verteilzeitfaktoren, die bspw.
von öffentlichen Organisationen evaluiert wurden, erfolgen.
Um die Bedeutung des konkreten Werts für den Parameter „Jahresarbeitszeit“
zu illustrieren, werden in Tab. 9.7 exemplarisch erhobene Werte von öffentlichen
Tab. 9.7 Jahresarbeitszeit – ausgewählte Parameter

ø Feiertage ø Krankentage Summe
Stadt Malchin (Zemke 2009) 9,00 20,00 29,00
gBG 12,75 15,00 27,75
Organisationen in Deutschland gegenübergestellt. Die öffentlichen Organisationen sind

die Stadt Malchin in Mecklenburg-Vorpommern (Zemke 2009) und eine gewerbliche
Berufsgenossenschaft (gBG), die bundesweit Dienststellen betreibt.
Der Parameter „Feiertage“ ist ein regionaler, nicht beinflussbarer, realer Faktor,
der einerseits für eine ausschließlich lokal und andererseits für eine bundesweit agie-
rende Organisation berechnet wurde. Der Faktor „Krankentage“ wurde in beiden
Organisationen erhoben.
Abgeschlossen wird der Abschnitt mit der Bemerkung, dass die unterschiedli-
chen Ausprägungen von Arbeitsverträgen, bspw. Vollzeit- oder Teilzeitverträgen,
keine Auswirkung auf die Jahresarbeitszeit haben. Im Rahmen der P-PBE wer-
den die Kapazitäten immer als Vollzeitkapazitäten ausgewiesen. Fragestellungen der
konkreten, persönlichen Jahresarbeitszeit sind Gegenstand in den Planungsphasen
„Personalbeschaffung“ und „Personaleinsatz“.
9.5 Ausgewählte Fragestellungen im Kontext der

Im abschließenden Abschnitt zur P-PBE werden ausgewählte Fragestellungen ange-

sprochen, die im Zusammenhang mit der Etablierung einer Personalbedarfsermittlung
betrachtet werden sollten. Dieser Abschnitt will verschiedene Denkanstöße dazu
geben.
Wer ist von der P-PBE betroffen?

Dies ist eine der ersten Fragen, die sich im Rahmen der Ankündigung einer geplan-
ten Personalbedarfsermittlung jeder Mitarbeiter in der Organisation stellen wird – vor
allem im Kontext der Angst vor einem möglichen Verlust des Arbeitsplatzes oder der
Veränderung der aktuellen Stellung in der Organisation.
Spätestens zum Zeitpunkt der Ankündigung der Personalbedarfsermittlung muss
diese Frage vorweg beantwortet werden. Die Antwort darauf kann nur lauten: Jeder
Mitarbeiter wird betroffen sein.
Gemeinsam mit der Ankündigung der Personalbedarfsplanung muss die Zielsetzung
und die Liste der möglichen Maßnahmen offen und klar kommuniziert werden. Eine
Personalbedarfsplanung wird im seltensten Fall das Freisetzen von Mitarbeitern zur
alleinigen Zielsetzung haben. Restrukturierungen, Umschulungen, Arbeitslastverteilungen

etc. sind weitere beispielhafte Zielsetzungen und Maßnahmen, die häufig im Fokus stehen.
Sollte doch die Freisetzung von Mitarbeitern im Fokus stehen, dann sprechen wir nicht
von einem klassischen P-PBE Ansatz, wie er hier vorgestellt wurde.
Falls nicht glaubhaft vermittelt werden kann, dass von der geplanten P-PBE alle
Mitarbeiter, vom Empfang bis in die Führungsetage, betroffen sind, dann wird es sehr
schwierig werden, die notwendige Akzeptanz für eine erfolgreiche Umsetzung der P-PBE
in der Organisation zu gewinnen (zum Thema Akzeptanz vgl. auch die Ausführungen
weiter unten in diesem Abschnitt).
Die Ermittlung von validen Bearbeitungszeiten und Prozessmengen ohne die
konstruktive Mitarbeit durch die Belegschaft ist kaum vorstellbar (vgl. bspw. die
Ausführungen zur Schätzung und Messung von Bearbeitungszeiten in Abschn. 9.4.2).
Eine Möglichkeit, die Beteiligung aller Mitarbeiter sicherzustellen, ist, die P-PBE ohne
Ausnahme in allen Organisationseinheiten durchzuführen. Im Idealfall wird die P-PBE
sogar als laufende Aufgabe in der Linienorganisation etabliert. Eine andere Möglichkeit
stellt ein laufendes Projekt dar, bei dem über eine Roadmap ersichtlich ist, wann und in
welcher Organisationseinheit eine P-PBE geplant ist.
Wie transparent ist die Ermittlung von Bearbeitungszeiten?

Eine meist begleitende Fragestellung in diesem Kontext ist jene nach den richtigen
Mitarbeitern, die für die Ermittlung der durchschnittlichen Bearbeitungszeiten herange-
zogen werden sollen.
Aus Sicht der Autoren kann es darauf nur eine Antwort geben: Alle Mitarbeiter müs-
sen an der Ermittlung der „korrekten“ durchschnittlichen Bearbeitungszeit beteiligt werden.
Die „korrekte“ durchschnittliche Bearbeitungszeit muss die unterschiedlichen
Qualifikationen und Fertigkeiten der Mitarbeiter vollständig berücksichtigen. Diese kann
nur über eine flächendeckende Beteiligung aller Mitarbeiter gewährleistet werden.
So provokant diese Aussage klingen mag, diese Aussage kann durch positive
Erfahrungen der Autoren bei Messungen zur Bearbeitungszeit mit Mitarbeiterbeteiligungen
von mehr als 85 % über mehrere Wochen in verschiedenen Projekten untermauert werden.
Als Conclusio ergibt sich: Ohne Akzeptanz geht gar nichts!
Vermutlich unbestritten ist, dass die Etablierung einer Personalbedarfsermittlung
häufig erst einmal Ängste um den eigenen Arbeitsplatz, zumindest aber um die persön-
liche Position in der Organisation, auslöst. Diese Angst geht meistens vom Empfang
bis in die obersten Führungsetagen durch die gesamte Organisation. Die einzige
Person, die von dieser Angst vermutlich nicht betroffen ist, ist jene Person, die eine
Personalbedarfsermittlung beauftragen kann.
Um diesem Handicap zuvorzukommen, sollte eine P-PBE nicht erst zum Zeitpunkt
einer drohenden oder bereits vorhandenen wirtschaftlichen Schieflage aufgesetzt wer-
den. Vielmehr sollte die Schlüsselfunktion der Personalbedarfsermittlung als Grundlage
für die laufende Planung der Unternehmensentwicklung im Vordergrund stehen.
Literatur
Bundesministerium des Innern in Zusammenarbeit mit dem Bundesverwaltungsamt (2013)

Handbuch für Organisationsuntersuchungen und Personalbedarfsermittlung, Handbuch, Berlin.
http://www.orghandbuch.de/cln_321/nn_414290/OrganisationsHandbuch/DE/ohb__pdf,templat
eId=raw,property=publicationFile.pdf/ohb_pdf.pdf. Zugegriffen: 13. Mär 2013
Deutsche Bundesbank (2012) Hinweise zur Abwicklung des unbaren Zahlungsverkehrs bei der
Deutschen Bundesbank im Zusammenhang mit bundeseinheitlichen und regionalen Feiertagen,
Merkblatt. http://www.bundesbank.de/Redaktion/DE/Downloads/Kerngeschaeftsfelder/Unbarer_
Zahlungsverkehr/zv_merkblatt_feiertage.pdf.pdf?__blob=publicationFile. Zugegriffen: 13. Jan 2013
Gabler Verlag (2013a) Gabler Wirtschaftslexikon, Stichwort: Personalbedarf. http://wirtschaftslexikon.
gabler.de/Archiv/54931/personalbedarf-v8.html. Zugegriffen: 07. Jan 2013
Gabler Verlag (2013b) Gabler Wirtschaftslexikon, Stichwort: Personalplanung. http://wirtschaftslexikon.
gabler.de/Archiv/56484/personalplanung-v7.html. Zugegriffen: 13. Jan 2013
Innenministerium des Landes Nordrhein-Westfalen (2007) Gefahrenabwehr in Nordrhein-
Westfalen: Jahresbericht 2007, Bericht, Düsseldorf. www.mik.nrw.de/publikationen/produktau
swahl.html?eID=pub&f=25&s=632143. Zugegriffen: 16. Jan 2013
30(8–9/01):1161–1170
Poggensee K (2009) Investitionsrechnung: Grundlagen – Aufgaben – Lösungen. Gabler, Wiesbaden
Zemke T (2009) Personalbedarfsplanung im Rahmen des Personal- und Organisationsent
wicklungskonzeptes einer Stadtverwaltung erläutert am Beispiel der Stadt Malchin. Europäischer
Hochschulverlag, Bremen
Prozesskostenrechnung
10
Christoph Prackwieser und Kai-Helmut Eckert
Zusammenfassung
Die Kostenstruktur der eigenen Produkte und Services zu kennen und die damit
einhergehende Identifikation von kostenverursachenden Einflussgrößen sind Voraus
setzung für die erfolgreiche Durchführung von Optimierungsprojekten und die
Grundlage vieler betriebswirtschaftlicher Entscheidungsprozesse. Die Anwender des
Instruments Prozesskostenrechnung erzielen durch die konsequente Fokussierung
auf die Unternehmensprozesse und deren Ressourcenverbrauch transparente, nach-
vollziehbare und verständliche Ergebnisse. Das Kapitel soll zum Einsatz dieses mächti-
gen Analyseinstruments motivieren und ein Grundverständnis für die Anwendung der
Prozesskostenrechnung schaffen. Anhand des Process Management Life Cycle wird die
Methode positioniert und die notwendige Einbindung beteiligter Unternehmensbereiche
erläutert. Eine in Praxisprojekten bewährte methodische Vorgehensweise und Berech
nungslogik wird vorgestellt und deren Anwendung anhand eines intuitiven Beispiels
beschrieben. Den Abschluss bildet eine kritische Diskussion der Methode.
10.1 Motivation für den Einsatz der Prozesskostenrechnung
Die übergeordnete Zielsetzung sehr vieler sogenannter Prozessoptimierungsprojekte ist

es, die Kosten zu senken. Als externer Betrachter mag es überraschen, dass hierfür in
der Praxis relativ selten das Instrument der Prozesskostenrechnung herangezogen wird.
C. Prackwieser (*)
e-mail: christoph.prackwieser@boc-group.com
K.-H. Eckert

188 C. Prackwieser und K.-H. Eckert
Stattdessen wird versucht, die Kosten über indirekte Einflussfaktoren, wie z. B. benötigte
Bearbeitungszeit oder Kompetenz der durchführenden Bearbeiter zu beeinflussen.
Mit dem folgenden Kapitel wollen wir Interesse an und ein Grundverständnis
für die Anwendung der Prozesskostenrechnung schaffen und dabei motivieren, die
Prozesskostenrechnung in den Werkzeugbaukasten mit aufzunehmen. Wir zeigen, wel-
che praxisrelevanten Zielsetzungen erreicht werden können und stellen eine, in unseren
eigenen Kundenprojekten bewährte, Methode detailliert vor und veranschaulichen deren
Anwendung anhand eines intuitiven Beispiels.
Wenngleich die Prozesskostenrechnung keinen revolutionär anderen Ansatz im
Vergleich zu traditionellen Kostenrechnungsmethoden darstellt, so bietet sie doch ihren
Anwendern, durch die konsequente Fokussierung auf die Unternehmensprozesse, einen
neuen Blickwinkel auf die Orte und Situationen der Kostenentstehung. Sie sorgt damit für
mehr Transparenz und stellt wertvolle Informationen zur Entscheidungsunterstützung
zur Verfügung.
Die Einsatzbreite der Prozesskostenrechnung ist je nach betrachteter Branche sehr
unterschiedlich. Während sie im produzierenden Bereich bereits zum Standardrepertoire
jedes Controllers und Kostenrechners gehört, wird sie bspw. im Dienstleistungsbereich
nur vereinzelt angewendet und ist dort noch seltener integraler Bestandteil des
Kostenrechnungssystems. Während ähnliche Ansätze, wie z. B. das Activity-based Costing,
im Produktions- oder Logistikbereich schon länger bekannt sind und verwendet werden,
rücken durch verstärkte Industrialisierungsbemühungen vieler Dienstleistungsunternehmen
auch die internen Kosten der eigenen Dienstleistungen stärker in den Fokus und müssen
sich mit denen von externen Anbietern messen lassen.
Typischerweise wird die Prozesskostenrechnung als Ergänzung zu bestehenden, im
Unternehmen bewährten Kostenrechnungsverfahren eingesetzt. Während in klassischen
Systemen die Kosten auf Kostenträger, wie Produkte oder Services, und Kostenstellen
geschlüsselt werden, betrachtet die Prozesskostenrechnung den gesamten Ablauf der
Produktion eines Produkts oder der Erbringung einer Dienstleistung. Diese Ausrichtung
auf die innerbetriebliche Entstehung der Leistung, also den Wertschöpfungsprozess,
trägt stark zu einer transparenteren Sicht auf die Kostenentstehung bei und ermöglicht
unter Betrachtung des Prozesses auch für Nicht-Controller eine verständliche und verur-
sachungsgerechte Zuordnung verschiedener Kostenarten.
10.2 Einsatzgebiete und Ziele der Prozesskostenrechnung
Je nachdem, ob die Prozesskostenrechnung die traditionelle Kostenträgerrechnung erset-

zen oder ergänzen soll, ergeben sich unterschiedliche Anforderungen. Prinzipiell kann die
Prozesskostenrechnung sowohl als Teilkostenrechnung als auch als Vollkostenrechnung
durchgeführt werden. Während sich die Teilkostenrechnung auf die Kosten und Kostenarten
beschränkt, welche direkt den zu erstellenden Produkten bzw. Dienstleistungen zuzurechnen
sind (variable Kosten, Einzelkosten), berücksichtigt die Vollkostenrechnung alle Kosten.
10 Prozesskostenrechnung 189
Wird eine Prozesskostenrechnung mit der Zielsetzung Geschäftsprozessverbesserung

bzw. der Verringerung des Ressourceneinsatzes durchgeführt, so ist erfahrungsgemäß
eine Teilkostenrechnung ausreichend. Typische Zielsetzungen einer solchen Maßnahme
sind hierbei:
• Schaffung von Kosten- und Prozesstransparenz in den indirekten Leistungsbereichen

• Ermittlung von Einflussgrößen (Kostentreibern) auf Kosten und Ressourcenverbrauch
• Aufzeigen der Auswirkungen von Veränderungen an den Prozessabläufen, von der
Einsparung unnötiger Prozesse oder von der veränderten Anzahl der Prozessdurch
führungen (Simulation und Ergebnisvergleich unterschiedlicher Szenarien)
• Optimierung der Geschäftsprozesse aus Kostengesichtspunkten
• Beurteilung von Wirtschaftlichkeit und Leerkosten bestimmter Bereiche
• Benchmarking (z. B. Vergleich von Kostenstellen und Standorten)
• Bewirken von Verhaltensänderungen
Beim Einsatz der Prozesskostenrechnung als Vollkostenrechnung werden alle Kosten

verteilt, insbesondere auch die Gemeinkosten. Typisches Einsatzgebiet ist hierbei die
Preiskalkulation oder der Vergleich von eigenen Kosten mit denen externer Dienstleister.
Weitere Zielsetzungen können sein:
• Schaffung von Grundlagen für die Kalkulation von Preisen und Kundengeschäften
• Angemessene Bewertung und Verrechnung von innerbetrieblichen Leistungen
• Verbesserung der Produkt- und Kundenergebnisrechnung (durch Zurechnung der
Prozesskosten auf Produkte, Kunden, Marktsegmente)
• Unterstützung von strategischen Entscheidungen (z. B. Make or Buy, Outsourcing)
Die Durchführung von Prozesskostenrechnungs-Projekten oder der Aufbau eines sol-

chen Systems ist ein anspruchsvolles Projekt, bei dessen Initiierung Klarheit über die
mittel- und langfristigen Ziele bestehen muss. Aus diesen Vorgaben lassen sich wichtige
Entscheidungen über die einzubindenden Unternehmensbereiche bzw. die zu verwen-
denden Softwarewerkzeuge ableiten.
10.3 Einordnung der Prozesskostenrechnung in den Process

Management Life Cycle
Gerade wenn die Prozesskostenrechnung als zusätzliches Instrument eines permanenten

Prozessmanagements eingeführt werden soll, eignet sich der Process Management Life
Cycle (PMLC, vgl. ebenso Kap. 2) sehr gut dazu, um diese Methode zu positionieren.
Dem Management und den Unternehmensbereichen kann anhand des PMLC transpa-
rent gemacht werden, welche Prozessmanagement-Aufgaben unterstützt werden und in
welchen Phasen die Zuarbeit der betroffenen Bereiche erforderlich ist.
Soll die Prozesskostenrechnung nur einmalig im Rahmen eines Projekts angewendet

werden, fördert die Einordnung in den PMLC das Verständnis für Wechselwirkungen
mit bestehenden Prozessmanagement-Verfahren und sorgt für Klarheit über erforderli-
che Zuarbeit und voraussichtliche Ergebnisse.
Aus den zuvor angeführten vielfältigen Einsatzmöglichkeiten der Prozesskostenrech
nung lässt sich schon erahnen, dass dieses Instrument auch in einigen Phasen des PMLC
seine Anwendung finden kann oder auch auf deren Ergebnisse angewiesen ist.
Wie alle Prozessoptimierungs-Methoden ergeben sich auch für die Prozesskos
tenrechnung wesentliche Rahmenbedingungen aus der Phase Prozessstrategie. Wird das
Instrument permanent angewendet, so ergeben sich aus den operationalisierten Zielen
der Strategie die für die weitere Optimierung vorgesehenen Kenngrößen (vgl. ebenso
Kap. 4). Um die Umsetzungsalternativen einzelner strategischer Vorhaben zu bewerten,
kann diese Methode bspw. die Prozesskosten als Input für einen Business Case liefern. Des
Weiteren könnten aus der Strategie Hinweise zum Projekt-Scope, der Bandbreite möglicher
Handlungsalternativen, die Optimierungstiefe oder die Betrachtungsdauer abgeleitet werden.
In der Phase Prozessdokumentation wird in Form von Prozessmodellen ein wichtiger
Input für die Prozesskostenrechnung geschaffen. Die Modelle dienen der Transparenz
über die mit Produkten oder Services verbundenen Tätigkeiten und deren Bearbeiter. Sie
bilden das Grundgerüst um die in Prozessen ausgeführten Aktivitäten mit Ressourcen,
deren Kostenstellen, den Bearbeitungszeiten und Kosten in Beziehung zu setzen. Zu
beachten ist, dass die Prozesskostenrechnung gewisse Anforderungen an die Struktur
und Modellierungstiefe der Prozesse stellt.
Ist es das Ziel eines Prozesskostenrechnungs-Projekts, eine kostenfokussierte Bewertung
der Ist-Situation durchzuführen, so kann die eigentliche Kalkulation der Prozesskosten
noch in der Phase Prozessdokumentation erfolgen.
Soll aber eine Verbesserung der Kostensituation erreicht werden, so müssen neben
der Betrachtung der Ist-Situation ein Design und eine Bewertung von Soll-Prozessen
erfolgen. Dies geschieht in der Phase Prozessoptimierung. Idealerweise haben sich
aus der Aufnahme und dem Studium der Ist-Prozesse in der vorhergehenden Phase
bereits einige Ideen für Prozessverbesserungen ergeben. Nun können diese Ideen in
Prozessmodellen ausformuliert und damit verbundene Einsparungs-Hypothesen mittels
der Prozesskostenrechnung bewertet werden.
Ein häufig in der Praxis anzutreffendes Problem ist die Ermittlung der konkreten
Prozessmengen und Bearbeitungszeiten. Zu diesen Daten kann man einerseits durch
Befragungen oder Datenauswertungen in der Phase Prozessdokumentation kommen.
Soll die Prozesskostenrechnung zu einem ständigen Werkzeug werden, liegt aber eine
automatisierte Ermittlung der relevanten quantitativen Input-Parameter in der Phase
Prozessdurchführung nahe. Dies kann durch die Anpassung von IT-Systemen oder
aber – hoffentlich nur temporär – durch das Ausfüllen von Strichlisten erreicht werden.
Näheres zur Erhebung quantitativer Parameter wird in Abschn. 9.4 erläutert.
Wird die Prozesskostenrechnung nicht nur projektbasiert, sondern permanent durchge-
führt, so wird sie unweigerlich zu einem zentralen Instrument der Phase Prozesscontrolling.
Dabei stehen die Beobachtung von Veränderungen der Prozesskosten und deren
Zusammensetzung im Vordergrund. Durch eine analytische Durchdringung der berechne-
ten Daten können Potenziale zur kostenrelevanten Prozessverbesserung erzielt, aber auch
Hinweise für strategische Änderungsmöglichkeiten herausgearbeitet werden.
10.4 Beteiligte Rollen
Es liegt auf der Hand, dass ein so breites Instrument wie die Prozesskostenrechnung eine
Vielzahl von Zuarbeitern verschiedener Rollen benötigt.
Da gerade für Kostenstellenverantwortliche und deren Vorgesetzte die gestei-
gerte Transparenz in ihrem Bereich zu einer gewissen Abneigung gegenüber dieser
Methode führen kann, ist ein einflussreicher, von der Methode überzeugter Sponsor
sehr wichtig, um diese zentralen Personen zur Mitwirkung zu motivieren. Neben
Prozessverantwortlichen, Prozessexperten, Prozessberatern und Prozesscontrollern
(vgl. Abschn. 2.2) sind vor allem Kenner der Kostenstruktur des Unternehmens, also
Kostenrechner oder Controller mit einzubeziehen. Es hat sich auch als vorteilhaft her-
ausgestellt, wenn das Projekt unmittelbaren Zugriff auf Mitarbeiter hat, die aus dem
Kostenrechnungssystem bzw. dem Data Warehouse Auswertungen erstellen können.
10.5 Grundlagen Kostenarten und Prozesskostenrechnung
Generelles Ziel einer Prozesskostenrechnung ist die Beherrschung und in weiterer Folge
die Senkung der stetig steigenden Gemeinkosten einer Organisation. Dies wird versucht,
durch eine erhöhte Transparenz der Gemeinkostenbereiche herbeizuführen. Eine solche
Transparenz kann unter anderem dadurch erreicht werden, dass die in den Kostenstellen
anfallenden Tätigkeiten sowie die durch sie anfallenden Kosten dokumentiert wer-
den. Weiterhin liefert eine Aufschlüsselung der Tätigkeiten und Prozesse nach ihrer
Beanspruchung der betrieblichen Ressourcen wertvolle Informationen über mögliche
Rationalisierungspotenziale und Ansatzpunkte zur Geschäftsprozessoptimierung.
10.5.1 Grundlagen der Kostenrechnung
Um die Funktionsweise einer Prozesskostenrechnung zu verstehen, ist es wichtig, einige

wesentliche Grundlagen der Kostenrechnung zu betrachten.
Oberstes Ziel einer Kostenrechnung ist es, die in einer Organisation entstehenden
Kosten zu verteilen. Die Verteilung sollte dabei möglichst verursachungsgerecht erfol-
gen, d. h. die Bereiche oder Produkte, die die größten Kosten verursachen, sollen diese
Kosten auch tragen. In der Kostenrechnung gibt es verschiedene Arten der Kalkulation,
jede für sich mit Vor- und Nachteilen. An dieser Stelle soll lediglich ein vereinfachter
Abriss der Kostenrechnung gegeben werden.
Bei einer Kostenrechnung werden zunächst verschiedene Kostenarten unterschieden.

Ziel dieser Unterscheidung ist es, zu verstehen, wofür in einer Organisation Kosten anfal-
len. Beispiele für Kostenarten sind Werbekosten, Personalkosten oder Maschinenkosten.
Eine weiteres wichtiges Unterscheidungskriterium von Kostenarten – und im weite-
ren Verlauf für die Prozesskostenrechnung – sind die Einzelkosten und Gemeinkosten.
Einzelkosten (direkte Kosten) bezeichnen die Kosten, die unmittelbar abhängig zu
einem Bezugsobjekt sind. Abhängig vom gewählten Bezugsobjekt können Einzelkosten
z. B. Materialkosten sein, die für ein zu erstellendes Produkt anfallen, aber bspw. auch
Kosten, die bei jeder Durchführung eines Prozesses entstehen.
Den Einzelkosten gegenüber stehen die Gemeinkosten (indirekte Kosten). Gemeinkosten
können nicht verursachungsgerecht einem Bezugsobjekt zugeordnet werden. Daher müs-
sen zur Verteilung von Gemeinkosten spezifische Umlageverfahren angewendet werden.
Typische Beispiele für Gemeinkosten sind Miete oder das Gehalt eines Abteilungsleiters
(Wöhe 2005, S. 1082).
Sowohl Einzelkosten als auch Gemeinkosten sollen über die Kostenrechnung auf
die in der Organisation existierenden Kostenträger umgelegt werden (vgl. Abb. 10.1).
Klassische Kostenrechnungssysteme unterscheiden hierbei zwei grundsätzliche Arten:
die Vollkostenrechnung sowie die Teilkostenrechnung (Wöhe 2005, S. 1080).
In der Vollkostenrechnung werden alle Kosten auf die Kostenträger verteilt. Einzel-
und Gemeinkosten werden dabei im Rahmen einer Kostenartenrechnung erfasst,
auf verschiedene Kostenstellen verteilt und schlussendlich auf die verschiedenen
Kostenträger verteilt. Bei dieser Kalkulation werden Kostenträgern auch Kosten zuge-
ordnet, für die sie ursächlich gar nicht verantwortlich sind.
Die Teilkostenrechnung versucht dieses Problem dahingehend zu lösen, dass den
Kostenträgern nur ein Teil der Gesamtkosten zugeordnet wird. Dabei verzichtet die
Teilkostenrechnung auf die Zuordnung der fixen Kostenbestandteile und konzentriert
sich auf die Verteilung der variablen Anteile. Damit ist die Teilkostenrechnung wesent-
lich verursachungsgerechter. Jedoch liefert die Teilkostenrechnung keine Antwort auf
die Frage, wie eine verursachungsgerechte Verteilung der Gemeinkosten erfolgen kann.
Abb. 10.1 Umlage von Kosten

auf Kostenträger (Horváth
Einzelkosten Gemeinkosten
2009, S. 424)
Kostenstelle
Kostenträger
Da die Gemeinkosten aber einen wesentlichen Anteil an den Gesamtkosten einer

Organisation haben, ist es wichtig, sich mit diesen zu befassen und Methoden anzuwen-
den, die sich mit der Verteilung derselben beschäftigen.
10.5.2 Activity-based Costing und Prozesskostenrechnung
Als Antwort auf das Problem der steigenden Gemeinkosten wurden in den USA Mitte
der 80er-Jahre des vergangenen Jahrhunderts sogenannte Activity-based Costing-
Systeme (ABC-Systeme) entwickelt, die die fixen Gemeinkosten nicht mehr über die
Lohnstunden, sondern über in Anspruch genommene Aktivitäten den Produkten
zurechnen sollten. Ziel des ABC war somit eine verursachungsgerechtere Umlage der
direkten und indirekten Gemeinkosten auf die Produkte. Das Activity-based Costing
wird hauptsächlich für die Kostenanalyse in direkten Unternehmensbereichen, also z. B.
der Produktion, angewendet.
Den Startschuss für das Thema Prozesskostenrechnung im deutschsprachigen Raum
gab der von Horváth und Mayer (1989) veröffentlichte Aufsatz „Prozeßkostenrechnung –
Der neue Weg zu mehr Kostentransparenz und wirkungsvolleren Unternehmensstrategien“.
Die Kernphilosophie der Prozesskostenrechnung ist es, die betrieblichen Gemeinkosten
entsprechend der tatsächlichen Inanspruchnahme betrieblicher Aktivitäten oder Tätigkeiten
den Kalkulationsobjekten – in dem Fall den Prozessen – zuzurechnen. Im Unterschied zum
Activity-based Costing werden in der Prozesskostenrechnung Prozesshierarchien, also z. B.
Haupt- und Teilprozesse, eingeführt und die Kosten danach unterschieden, ob sie mit der
Output-Menge in einem linearen Zusammenhang stehen oder nicht. Diese Neuerungen
erleichtern den Einsatz der Prozesskostenrechnung in indirekten Unternehmensbereichen,
wie bspw. Personal oder Finanzen, und in Dienstleistungsunternehmen. Als oberstes Gebot
steht demnach das Verursachungsprinzip im Vordergrund.
Da in der Prozesskostenrechnung neben den Gemeinkosten auch die direkt zuorden-
baren Einzelkosten den Kostenträgern zugeordnet werden, entspricht die Prozesskosten
rechnung in ihrem Wesen einer Vollkostenrechnung.
Im Zentrum der Prozesskostenrechnung stehen die unternehmensinternen Abläufe.
Die in einer Organisation durchgeführten Aktivitäten können dabei zu kostenstellen-
übergreifenden Prozessen aggregiert werden.
Abteilungsübergreifende Prozesse werden in der Prozesskostenrechnung als Hauptpro
zesse, ihre abteilungsspezifischen Komponenten als Teilprozesse bezeichnet (vgl. Abb. 10.2).
Die Idee der Prozesskostenrechnung ist es nun, die durchgeführten Tätigkeiten
in Teilprozessen zusammenzufassen und diesen Teilprozessen Kosten zuzuordnen.
Dabei werden die Prozesse in leistungsmengeninduzierte (lmi) und leistungsmen-
genneutrale (lmn) Prozesse unterschieden. Ist die Anzahl der Durchführungen eines
Prozesses von der Ausbringungsmenge der Kostenstelle variabel, so handelt es sich um
einen leistungsmengeninduzierten Prozess. Wird der Prozess jedoch unabhängig vom
Leistungsvolumen der Kostenstelle durchgeführt, so ist er leistungsmengenneutral.
Indirekte Kostenstelle
Beschaffung Lagerwirtschaft Fertigungssteuerung
Fertigungsaufträge abwickeln
prozesse
Haupt-
Teilenummern verwalten
prozesse
Teil-
TP1 TP2 TP3 TP4 TP5 TP6
Tätigkeitsanalyse
Abb. 10.2 Haupt- und Teilprozesse (Mayer 1998, S. 86)
Die Kosten der leistungsmengenneutralen Teilprozesse werden typischerweise im

Verhältnis zu den in Anspruch genommenen Personalkapazitäten auf die leistungsmen-
geninduzierten Prozesse umgelegt.
Wesentlicher Unterschied zwischen dem im amerikanischen Raum verbreiteten Activity-
based Costing und der im deutschsprachigen Raum verbreiteten Prozesskostenrechnung ist
die zusätzliche Betrachtung indirekter Leistungsbereiche in der Prozesskostenrechnung, wie
z. B. dem Einkauf oder der Logistik.
10.6 Vorgehensmodell für die Prozesskostenrechnung
10.6.1 Allgemeines Vorgehensmodell
Eine Prozesskostenrechnung erfolgt grundsätzlich in mehreren aufeinanderfolgenden

Schritten (Horváth und Mayer 1989):
1. Prozessanalyse
Zu Beginn der Prozesskostenrechnung erfolgt eine Prozessanalyse mit dem Ziel der
Ermittlung der zu den zu untersuchenden Geschäftsbereichen gehörenden Prozesse.
Hierbei werden schwerpunktmäßig die wertschöpfenden Geschäfts- und Subprozesse
analysiert.
Ausgangspunkt der Prozessanalyse ist vielfach eine Tätigkeitsanalyse zur Ermittlung der
einzelnen Aktivitäten. Dabei wird für alle Aktivitäten ermittelt, wer diese durchführt
oder wo diese durchgeführt werden sowie welche Zeiten für die Durchführung der
Aktivitäten benötigt werden.
2. Bestimmung der Kostentreiber

Kostentreiber sind Bezugsgrößen zur Quantifizierung der Geschäfts- und Subprozesse. Sie
stellen eine Beziehung zwischen den Kosten, den Prozessen und den Kalkulationsobjekten
her. Dabei müssen Kostentreiber mengenmäßig erfassbar sein.
Bei der Zusammenstellung eines Pakets im Online-Versandhaus ist die Bestellmenge
eines bestimmten Artikels kein geeigneter Kostentreiber. Die Prozesskosten sind iden-
tisch, egal ob die Bestellmenge eines Artikels 1 oder 10 Stück beträgt. Beeinflusst werden
die Prozesskosten vielmehr durch die Häufigkeit des Prozesses – sprich durch die Anzahl
der Paketzusammenstellungen sowie durch die Anzahl der Bestellpositionen.
3. Bestimmung der Kostentreibermengen und Prozesskosten

Für die jeweiligen Kostentreiber ist die tatsächliche Anzahl zu ermitteln. Dies können
abhängig vom jeweiligen Kostentreiber einmal die Fertigungsaufträge/Prozessmengen
oder auch wie am Beispiel unter Schritt 2 die Anzahl der Bestellpositionen sein.
Daraufhin können die Kosten pro Prozessmengeneinheit bestimmt werden.
4. Prozesskostenkalkulation
Den Abschluss der Prozesskostenrechnung bildet die Prozesskostenkalkulation. Hierfür
werden zunächst Prozesskostensätze ermittelt. Der Prozesskostensatz als Quotient aus
ermittelten Prozesskosten und Kostentreibermengen gibt an, welche direkten Kosten mit
der einmaligen Durchführung des Prozesses entstehen.
Prozesskosten
Prozesskostensatz = (10.1)
Kostentreibermenge
Als nächstes müssen die leistungsmengenneutralen Kosten auf die Prozesse umge-
legt werden. Hierbei können verschiedene Umlageverfahren angewendet werden. Am
Ende ergibt sich ein Gesamtprozesskostensatz als Summe aus Prozesskostensatz und
Umlagesatz.
Gesamtprozesskostensatz = Prozesskostensatz + Umlagesatz (10.2)
10.6.2 Umlageverfahren
Zur Berechnung des Umlagesatzes der leistungsmengenneutralen Kosten können ver-

schiedene Umlageverfahren angewendet werden. Dabei ist es auch nicht notwendig,
für alle leistungsmengenneutralen Kosten das gleiche Umlageverfahren zu wählen.
Abhängig vom jeweiligen leistungsmengenneutralen Kostenblock kann mal das eine
oder mal das andere Umlageverfahren geeignet sein. Die wichtigsten Umlagearten sollen
hier vorgestellt werden.
• Gleichverteilung
Alle Prozesse erhalten den gleichen Anteil der leistungsmengenneutralen Kosten.

lmn-Kosten
Umlagesatz = (10.3)
Anzahl der Prozesse
• Mengenverteilung
Die Prozesse mit der größten Prozessmenge erhalten anteilig den größten Anteil der
leistungsmengenneutralen Kosten.
Anzahl Prozessmenge Einzelprozess

Umlagesatz = × lmn-Kosten (10.4)
Anzahl Prozessmenge aller Prozesse
• Prozentverteilung
Die Prozesse mit dem größten Prozesskostensatz erhalten den größten Anteil der
leistungsmengenneutralen Kosten.

lmn-Kosten
Umlagesatz = × Prozesskostensatz (10.5)
lmi-Kosten
10.6.3 Praxisbeispiel
Einleitung
Das Hotel Bärlina ist ein renommiertes Viersternehotel im Herzen Berlins, exklusiv gele-
gen am Gendarmenmarkt. Die zentrale Lage und die sehr gute Anbindung machen es
zum perfekten Ausgangspunkt für Berlin-Besucher sowie Geschäftsreisende.
Das klare Design im puristischen Stil der Hotelzimmer spiegelt urbane Trends wider
und verleiht den Zimmern eine angenehme Atmosphäre zum Wohlfühlen. Viele der
Zimmer sind mit einem privaten oder französischen Balkon ausgestattet und bieten
traumhafte Ausblicke auf die Hauptstadt.
Das Hotel verfügt insgesamt über 100 identische Hotelzimmer zu je 59 EUR pro
Nacht.
Ausgangssituation und Motivation

Aufgrund von starken Veränderungen im Berliner Hotelmarkt hat die Geschäftsleitung
von Bärlina beschlossen, ihre Zimmerpreise an die veränderte Nachfrage und an die
gegebene Variantenvielfalt anzupassen. Es wird kritisiert, dass kaum Kostentransparenz
in der Preispolitik des Hotels herrsche. Preise wurden bisher aus dem „Bauch heraus“
definiert und scheinen irgendwie nicht zu stimmen.
Nach Prüfung der Zimmerpreise stellte die Geschäftsführung fest, dass die Zimmer
reinigung einen enormen Kostenblock einnimmt. Insbesondere durch die schwankende
Auslastung (durchschnittlich 50 %) müssen enorm viele Arbeitskräfte vorgehalten werden
(konstante Kosten trotz schwankender Auslastung!). Vor diesem Hintergrund kommt die
Geschäftsführung zu der strategischen Überlegung, die Zimmerreinigung an einen exter-
nen Dienstleister auszulagern (Outsourcing). Für diesen Fall stellt sich die Frage, welcher
Preis maximal pro Zimmerreinigung zu akzeptieren wäre.
Aktuell liegt ein Angebot der externen Reinigungsfirma CleanTeam GmbH vor.
Diese würde die Zimmerreinigung (inkl. Reinigung der anfallenden Schmutzwäsche) für
6 EUR pro Zimmer anbieten.
Um diese Do or Buy-Entscheidung (Selbst reinigen oder reinigen lassen?) auf ver-
ursachungsgerechten Informationen basierend richtig treffen zu können, sollen für die
Kalkulation alle Kosten funktionsübergreifend ermittelt und prozessorientiert aufgeteilt
werden. Die Prozesskostenrechnung soll für die nötige interne Kostentransparenz sorgen
und folglich den Ausgangspunkt für die Marktanalyse liefern.
Zimmerreinigung im Bärlina
Die Zimmerreinigung im Bärlina erfolgt mit Hilfe des leistungsmengeninduzierten
Prozesses „Zimmereinigung Abreise-/Bleibezimmer“. Sämtliche Aktivitäten, die für die
Zimmerreinigung anfallen, werden durch die internen Reinigungskräfte erbracht. Bei dem
Reinigungsprozess wird unterschieden zwischen Abreise- und Bleibezimmer. In einem
Bleibezimmer (d. h. der Gast bleibt noch eine weitere Nacht) wird die tägliche Standardrei
nigung durchgeführt. Im Abreisezimmer (d. h. der Gast reist ab) wird zusätzlicher
Reinigungsaufwand betrieben, um das Zimmer an einen neuen Gast übergeben zu können.
Für die Zimmerreinigung der Abreise-/Bleibezimmer konnten die in Abb. 10.3 dar-
gestellten Aktivitäten und Zeiten im Rahmen des ersten Schritts „Prozessanalyse“ (vgl.
Abschn. 10.6.1) identifiziert werden.
Bei der „Bestimmung der Kostentreiber“ gemäß Schritt 2 (vgl. Abschn. 10.6.1) konnte
die Anzahl der durchgeführten Zimmerreinigungen als Kostentreiber identifiziert werden.
• Lohnkosten „Reinigung“
Die gesamte Zimmerreinigung wird auf die Kostenstelle 1200 gebucht. Dieser
Kostenstelle werden die Reinigungskräfte zugeordnet (vgl. Tab. 10.1).
• Ermittlung der leistungsmengeninduzierten (lmi) Kosten
Für eine verursachungsgerechte Verrechnung der Zimmerreinigung im Bärlina
sind gemäß Schritt 3 „Bestimmung der Kostentreibermengen und Prozesskosten“
(vgl. Abschn. 10.6.1) die Zeiten und Mengen der Durchführung sowie der
Stundenlohn der Reinigungskräfte relevant. Die lmi-Kosten können dann direkt über
Prozesskostensätze zugerechnet werden.
• Tabelle 10.2 zeigt die Mengen, Zeiten und Kosten, die für die Zimmerreinigung ermit-
telt werden können.
Abb. 10.3 Ausschnitt des leistungsmengeninduzierten Prozesses „Zimmerreinigung Abreise-/

Bleibezimmer“
Tab. 10.1 Lohnkosten Reinigung

Rolle Stundenlohn in EUR Mitarbeiteranzahl Arbeitszeit in h/Tag
Reinigungskraft 12 6 6
Werte kleiner eins in der Spalte „Menge: Pro Durchführung“ weisen auf Tätigkeiten
hin, die nicht bei jeder Zimmerreinigung durchgeführt werden. So wird bspw. die
Minibar nur bei jeder vierten Zimmerreinigung aufgefüllt.
Die Kostentreibermenge je Aktivität ist in der Spalte „Menge: Gesamt“ aufge-
führt. Die Menge 12,5 für die Aktivität „Minibar auffüllen“ ergibt sich beispielsweise
aus der Multiplikation der Faktoren 50 %-ige Auslastung der 100 Zimmer und einer
Durchführungsrate von 0,25.
Für die Zimmerreinigung ergibt sich somit ein Prozesskostensatz in Höhe von
4,18 EUR.
Weitere Kosten „Schmutzwäsche“

Das Bärlina reinigt die anfallende Schmutzwäsche (benutzte Bettwäsche und
Handtücher) selbst. Hierfür stehen im Kellergeschoss des Hotelgebäudes Gerätschaften
für das Waschen, Trocknen und Bügeln der Wäsche zur Verfügung. Diese werden von
einem externen Dienstleister geleast.
Tab. 10.2 Ermittlung der leistungsmengeninduzierten Kosten

Menge Zeit Prozesskostensatz
Pro Ø Zeitver- in EUR
Pro Durchfüh- brauch in Ø Gesamt
Durchführung Gesamt rung in min min in min
Zimmer lüften 1 50 3 3 150 0,60
Staubsaugen 1 50 5 5 250 1
Betten richten 0,25 12,5 2 0,5 25 0,10
Betten neu 0,75 37,5 5 3,75 187,5 0,75
beziehen
Minibar 0,25 12,5 0,5 0,125 6,25 0,025
auffüllen
Bad putzen 1 50 7 7 350 1,4
Handtücher 1 50 1 1 50 0,20
wechseln
Mülleimer 1 50 0,5 0,5 25 0,1
leeren
Summe 4,18
Aus dem Controlling liegt die Information vor, dass jährlich eine Betriebskosten
pauschale von insgesamt 40.000 EUR anfällt. Die Leasinggebühr der Geräte sowie der
Strom- und Wasserverbrauch sind in der Pauschale enthalten.
Ergebnis
Die Prozesskostenrechnung sorgt für die interne Kostentransparenz, die hinsichtlich der
strategischen Entscheidung „Selbst reinigen oder reinigen lassen?“ erforderlich ist. Durch die
prozessorientierte Aufteilung der Kosten wird ersichtlich, welche einzelnen Kostenblöcke
in der heutigen Situation (Selbstreinigung) bestehen und demzufolge, welchen Preis das
Bärlina im Falle einer externen Auslagerung der Reinigung bereit ist zu zahlen.
In Schritt 4 „Prozesskostenkalkulation“ (vgl. Abschn. 10.6.1) können bzgl. der Frage
„Selbst reinigen oder reinigen lassen?“ folgende Ergebnisse berechnet werden.
Für die Selbstreinigung der Zimmer entstehen dem Bärlina folgende Kosten (vgl.
ebenso Tab. 10.3):
• 365 [Tage im Jahr] × 100 [Anzahl Zimmer] × 0,5 [Ø Auslastung] × 4,18 EUR [lmi-
Kosten Reinigung]
Tab. 10.3 Kosten für Selbstreinigung der Zimmer durch Hotel Bärlina
lmi-Kosten Zimmereinigung 76.285 EUR
Kosten Reinigung Schmutzwäsche +40.000 EUR
Gesamtkosten Selbstreinigung 116.285 EUR
Tab. 10.4 Kosten für Fremdreinigung der Zimmer durch CleanTeam GmbH
Gesamtkosten Fremdreinigung 109.500 EUR
Für die Fremdreinigung bei der CleanTeam GmbH würden hingegen folgende Kosten
entstehen (vgl. ebenso Tab. 10.4):
• 365 [Tage im Jahr] × 100 [Anzahl Zimmer] × 0,5 [Ø Auslastung] × 6 EUR [Preis pro
Zimmerreinigung durch CleanTeam]
Fazit: Kosten für Selbstreinigung > Kosten für Fremdreinigung

Vor diesem Hintergrund und aus Kostengesichtspunkten sollte die strategische
Entscheidung dahingehend getroffen werden, das vorliegende Angebot der CleanTeam
GmbH anzunehmen und dementsprechend die Zimmerreinigung auszulagern.
Zu berücksichtigen ist jedoch, dass bei einer solchen strategischen Entscheidung nicht
alleine die Kosten ausschlaggebend sind. Gleichzeitig spielen auch die Risiken, die mit
Outsourcing einhergehen können, eine entscheidende Rolle.
10.6.4 Bewertung der Prozesskostenrechnung
Das oben angeführte Beispiel zeigt deutlich, dass die Prozesskostenrechnung eine objek-
tive und nachvollziehbare Entscheidungsgrundlage für kosten- und preisinduzierte
Fragestellungen bieten kann. Dennoch muss sich der Anwender bewusst sein, dass die
in der Methode der Prozesskostenrechnung geforderte leistungsmengeninduzierte
Variabilität der Einzelkosten in der Realität selten gegeben ist. Beispielsweise können die
Mitarbeiterressourcen, gerade wenn es sich um angestelltes Personal handelt, nicht kurz-
fristig auf den jeweils benötigten Stand angepasst werden. Diese Annäherung der vor-
gehaltenen Kapazität mit der tatsächlich benötigten kann in der Praxis nur auf längere
Sicht erreicht werden, weshalb die Prozesskostenrechnung oft als taktisch oder strate-
gisch ausgerichtetes Entscheidungsinstrument verstanden wird.
Nicht von ungefähr wird in der Literatur, wenn es um die Optimierung von Prozessen
geht, meistens die zeitliche Straffung des Geschäftsvorgangs verfolgt. Es ist vielfach einfa-
cher, einem Teilprozess oder einer Aktivität eine durchschnittliche Dauer zuzuweisen als aus
den traditionellen Kostenrechnungssystemen die Kosten zu extrahieren, die in Abgrenzung
und Granularität den bei der Prozesskostenrechnung benötigten entsprechen. Oftmals hat ja
auch eine Verkürzung der Bearbeitungszeit eines Prozesses direkte Auswirkung auf dessen
verursachte Kosten, da die kalkulatorischen Personalkosten des Prozesses sinken.
Dieser Zusammenhang dürfte jedem Mitarbeiter, der sich mit Prozessen beschäftigt
klar sein. Die Prozesskostenrechnung geht aber noch einen Schritt weiter, indem sie wei-
tere Kostenarten betrachtet und den Prozessen zuordnet. Erfahrungsgemäß stehen diese
weiteren Kostenarten nicht immer im Blickfeld der Prozessverantwortlichen, können
aber für eine gesamtheitliche Optimierung sehr wesentlich sein.
Literatur
Horváth P (2009) Controlling, 11. Aufl. Vahlen, München

Horváth P, Mayer R (1989) Prozeßkostenrechnung – Der neue Weg zu mehr Kostentranzparenz
und wirkungsvolleren Unternehmensstrategien. Controlling (4):214–219
Mayer R (1998) Prozeßkostenrechnung und Prozeßkostenmanagement. In: Horváth & Partner
(Hrsg) Prozesskostenmanagement: Methodik und Anwendungsfelder, 2. Aufl. Vahlen, München,
S 73–100
Wöhe G (2005) Einführung in die Allgemeine Betriebswirtschaftslehre, 22. Aufl. Vahlen, München
Organisatorische
Prozessoptimierung 11
Eva Wolf, Lea Appelhans und Robert Klose
Zusammenfassung
Die organisatorische Prozessoptimierung beinhaltet die Analyse von Schwachstellen in
einem oder mehreren Ist-Prozessen, um darauf aufbauend Verbesserungsmaßnahmen
zu erarbeiten und neue Soll-Prozesse zu entwickeln. Im folgenden Kapitel werden
schwerpunktmäßig Veränderungen in der Aufbau- und Ablauforganisation sowie der
IT-Unterstützung betrachtet. Hierfür eignen sich unterschiedliche qualitative Methoden,
um vom Ist-Zustand zum gewünschten Soll-Zustand zu gelangen. Das Kapitel stellt
Techniken zur Bewertung und Analyse des erhobenen Ist-Zustands vor, wie z. B.
Checklisten, Interviews, Prozess-Assessments, Reifegradmodelle oder die Verwendung
von Referenzprozessen. Des Weiteren wird dargestellt, wie sich aus dem erhobenen Ist-
Zustand Verbesserungsvorschläge ableiten, priorisieren und darauf basierend konkrete
Maßnahmen zur Umsetzung identifizieren lassen. Ebenfalls wird ein Überblick über
die jeweiligen Vor- und Nachteile der unterschiedlichen Techniken sowie Hinweise zur
Anwendung unter Berücksichtigung verschiedenartiger Rahmenbedingungen gegeben.
11.1 Einleitung
Häufig wird die Prozessoptimierung mit einer Kosten- oder Personalreduktion gleichge-
setzt. Dies ist zu kurz gedacht, denn das vornehmliche Ziel einer Prozessoptimierung ist
die Verbesserung der Leistungen und Produkte des Unternehmens. Der Zusammenhang
zwischen Prozessen und Produkten sollte nie aus den Augen verloren werden, denn
eine Verbesserung der Prozesse führt direkt oder indirekt zu einer Verbesserung
der Produktqualität, des Preis-Leistungs-Verhältnisses und damit letztendlich der
Kundenzufriedenheit.
E. Wolf (*) · L. Appelhans · R. Klose

e-mail: eva.wolf@boc-de.com

204 E. Wolf et al.
Die organisatorische Prozessoptimierung beinhaltet die Analyse von Schwachstellen

in einem oder mehreren Ist-Prozessen, um darauf aufbauend Verbesserungsmaßnahmen
zu erarbeiten und einen neuen Soll-Prozess zu entwickeln. Prozessbetrachtung sowie
Potenzialanalyse erfolgen anhand ablauf-, aufbau- sowie IT-gestützter Aspekte. Hierzu
können verschiedene Methoden und Techniken eingesetzt werden, die im Folgenden
erläutert werden.
11.2 Betrachtungsgegenstand der organisatorischen

Prozessoptimierung
Für ein Prozessoptimierungs-Projekt ist es hilfreich, wenn für den zu untersuchenden

Bereich eine aktuelle Prozessdokumentation vorhanden ist (vgl. ebenso Abschn. 2.1.3
und 2.4.3). Diese ist jedoch keine zwingende Voraussetzung für die Durchführung, da
im Bedarfsfall die in Abschn. 11.4 vorgestellten Prozess-Erhebungsmethoden für die
Dokumentation der für die Optimierung ausgewählten Prozesse verwendet werden können.
Auf der Grundlage dokumentierter Prozesse kann die Prozessanalyse durchgeführt
werden (vgl. Abschn. 11.5). Sie umfasst die Bewertung und Analyse des Ist-Zustands von
Ist-Prozess Soll-Prozess
Ablauforganisation • Geschäftsprozess • Geschäftsprozess

(Prozessmodell & (Prozessmodell &
Prozessdokumentation) Prozessdokumentation)
• Erforderliche Rollen • Erforderliche Rollen

• Anforderungsprofil • Anforderungsprofil
(erforderliche (erforderliche
Aufbauorganisation Qualifikationen) Qualifikationen)
IT-Unterstützung
• IT-Unterstützung • IT-Unterstützung
• Automatisierung • Automatisierung
Abb. 11.1 Betrachtungsgegenstand der Prozessoptimierung

11 Organisatorische Prozessoptimierung 205
Geschäftsprozessen im Hinblick auf die zukünftige Zielsetzung, welche sich dann in der
Soll-Konzeption widerspiegelt.
Die Soll-Konzeption (vgl. Abschn. 11.6) beinhaltet schließlich die Beseitigung der mit-
tels der Prozessanalyse identifizierten Schwachstellen in den Ist-Prozessen. Hierfür werden
eine oder mehrere Soll-Prozess-Alternativen erarbeitet. Abbildung 11.1 fasst den Betrach
tungsgegenstand der organisatorischen Prozessoptimierung noch einmal zusammen.
Die Prozessanalyse und -optimierung stehen in Beziehung zueinander: Auf Grundlage
der in der Prozessanalyse identifizierten Schwachstellen und Optimierungspotenziale
können Prozesse optimiert und in einen gewünschten Soll-Zustand gebracht werden.
Abbildung 11.2 veranschaulicht diesen Zusammenhang.
Die organisatorische Prozessoptimierung versucht, Prozesse nicht nur aufgrund auf-
wendiger empirischer Analysen von Prozesszeiten und Prozesskosten, sondern vorran-
gig aufgrund des bei den Prozessexperten und Kunden vorhandenen Wissens über die
Prozesse – und damit auch über Schwachstellen und Verbesserungspotenziale – mittels
qualitativer Techniken zu optimieren.
Wie in der Einleitung erwähnt, können sich Verbesserungspotenziale innerhalb eines
Geschäftsprozesses sowohl auf ablauf-, aufbau- sowie IT-gestützte Aspekte beziehen.
Typische Fragestellungen der organisatorischen Prozessoptimierung sind:
• innerhalb der Ablauforganisation:

– Bestehen Möglichkeiten, Prozessschritte zu standardisieren?
– Können Prozessschritte eliminiert, parallelisiert bzw. zusammengefasst werden?
– Kann die Anzahl der im Prozess genutzten Formulare und Dokumente reduziert
werden?
Prozessanalyse Prozessoptimierung
Ermittlung von Schwachstellen

und Optimierungspotenzialen
hinsichtlich der Ist-Prozesse • Beseitigung von Schwachstellen
• Ausschöpfen von Optimierungs-
potenzialen
• Annäherung der Ist-Prozesse an
gewünschten Soll-Zustand
Abb. 11.2 Zusammenhang zwischen Prozessanalyse und Prozessoptimierung

206 E. Wolf et al.
– Wie können Informationsübergaben effizient gestaltet bzw. Rückfragen vermieden

werden?
– Gibt es Tätigkeiten, die sehr aufwendig oder umständlich sind? Was sind die
Ursachen dafür?
• innerhalb der Aufbauorganisation:
– Inwiefern können Prozessteile auf einzelne Aufgabenträger übertragen werden, um
Schnittstellen zu reduzieren?
– Bestehen Möglichkeiten, eine Prozessverantwortung zu etablieren?
• innerhalb der IT-Unterstützung:
– Gibt es Medienbrüche (z. B. Ausdrucken und erneutes Abtippen von Informationen),
die sich vermeiden lassen?
– Welche Prozessteile können durch Verbesserung der IT-Unterstützung optimiert
werden?
– Werden Daten redundant, also z. B. in mehreren Anwendungen, erfasst?
11.3 Vorgehensweise zur Prozessoptimierung
Die Prozessverbesserungen können, abhängig von den definierten Zielen, welche eine
Organisation verfolgt (vgl. ebenso Abschn. 2.4.3), und den Strategien, die sie zur Erreichung
dieser Ziele einsetzt, unterschiedliche Bereiche tangieren. Die häufigsten Optimierungs
maßnahmen betreffen die Umgestaltung der Aufbau- und Ablauforganisation, also die
organisatorische Ebene, oder aber die technische Verbesserung, welche auf die Auto
matisierung von Prozessen oder Prozessschritten abzielt.
In der Regel wird zur Prozessoptimierung ein mehrstufiges Vorgehen gewählt (vgl.
Abb. 11.3).
Ausgehend von der Zieldefinition für das Optimierungsprojekt ist es im Anschluss
daran zu empfehlen, das Optimierungsprojekt aufzusetzen bzw. zu planen. Hierzu
müssen insbesondere das verantwortliche Projektteam zusammengestellt und die
notwendigen personellen Ressourcen eingeplant werden (zum Thema „Aufsetzen
des Optimierungsprojekts“ vgl. ebenso Abschn. 2.4.3). Sofern noch nicht vorhan-
den, erfolgt anschließend die Erhebung der Ist-Prozesse oder die Vervollständigung
der vorhandenen Prozessdokumentation. Auf dieser Grundlage kann sodann die
Bewertung und Analyse der ausgewählten Prozesse stattfinden. Schließlich erfol-
gen die Erstellung des Soll-Konzepts und die Umsetzung der Maßnahmen. Details zu
Bewertung & Soll-

Ist-Erhebung Umsetzung
Analyse Konzeption
Abb. 11.3 Vorgehen bei der Prozessoptimierung

den einzelnen Ablaufphasen werden in den nachfolgenden Abschnitten des Kapitels

beschrieben.
11.4 Ist-Erhebung von Prozessmodellen
Sollten die Ist-Prozesse in einem Unternehmen noch nicht erhoben worden sein, so muss
die Erhebung an dieser Stelle erfolgen. Sind sie bereits vorhanden, so wird die Bewertung
und Analyse auf Basis der bestehenden Ist-Prozessdokumentation durchgeführt. Weisen
die Ist-Prozesse einen für eine fundierte Prozessanalyse zu geringen Informationsgehalt
auf, so müssen sie ggf. um zusätzliche Informationen angereichert werden.
Falls die Prozesse zunächst erhoben werden müssen, so eignen sich dafür, je nach-
dem, wie viel Zeit ein Unternehmen in die Erhebung der Ist-Prozesse investieren möchte
und kann, unterschiedliche Erhebungsmethoden.
Eine große Rolle spielt in diesem Kontext der Detaillierungsgrad, mit dem die
Prozesse erhoben werden (vgl. ebenso Abschn. 5.3.1). Sollten die zeitlichen Ressourcen
begrenzt sein, genügt es in einem ersten Schritt, einen niedrigen Detailgrad zu wählen
und nur den groben Ablauf der Prozesse aufzunehmen. Eine detaillierte Aufnahme kann
auch zu einem späteren Zeitpunkt erfolgen. Insbesondere hängt der Detailgrad auch von
der Zielsetzung des Unternehmens ab: Reicht ein grober Überblick über die Prozesse zur
Analyse bereits aus oder sollen diese auf Detailebene analysiert werden, um beispiels-
weise Medienbrüche oder Prozesskosten und -zeiten zu betrachten?
Zur Erhebung der Ist-Prozesse eignen sich im Kontext von Prozessoptimierungs-
Projekten aus unserer Erfahrung drei Modellierungstechniken, welche unterschiedliche
Zielsetzungen verfolgen:
• Produkt-Prozess-Übersicht,
• Kooperations- bzw. Kommunikationsbilder,
• Prozessablaufsicht.
Produkt-Prozess-Übersichten können angewendet werden, wenn für die Ressourcenver

teilung Produkte und Leistungen verbunden mit entsprechenden Produktkennzahlen genutzt
werden sollen. Eine entscheidende Rolle spielt hierbei die Verknüpfung der Produkte mit den
Prozessen, welche zur Erstellung der Produkte notwendig sind. Die Produkte bilden hierbei
den Ordnungsrahmen für die Prozesse der Organisation.
Kooperations- bzw. Kommunikationsbilder eignen sich in besonderer Form zur
Analyse von Kommunikationsflüssen oder zur Darstellung des Zusammenwirkens
unterschiedlicher am Prozess beteiligter Akteure. Es besteht die Möglichkeit, sowohl
interne Schnittstellen zwischen Abteilungen/Bearbeitern als auch Schnittstellen zu exter-
nen involvierten Akteuren darzustellen.
Bei der letztgenannten Methode, der Prozessablaufsicht, wird das Augenmerk auf die pro-
zessuale Abfolge von Arbeitsschritten gelegt, wohingegen bei der Produkt-Prozess-Übersicht
die angebotenen Produkte mit den Prozessen eines Unternehmens verknüpft werden.
208 E. Wolf et al.
Nachfolgend sollen die Vor- und Nachteile der drei vorgestellten Techniken erörtert
werden.
11.4.1 Produkt-Prozess-Übersicht
Die Produkt-Prozess-Übersicht verknüpft die Produkte einer Organisation mit den

Prozessen, die für die Erstellung der Produkte notwendig sind. Sie kommt z. B. häufig
in der öffentlichen Verwaltung zum Einsatz mit dem Ziel, die Geschäftsprozesse in den
Produktplan einer Behörde einzuordnen.
Vorteil der Methode ist, dass der Produktplan einer Organisation als Ordnungs
rahmen zur Identifikation ihrer Geschäftsprozesse dienen kann und die Organisation
dadurch auch den für die Durchführung der Geschäftsprozesse benötigten Ressour
ceneinsatz den erstellten Produkten zuordnen kann. Zusätzlich von Vorteil ist es, wenn
für die einzelnen Produkte in der Finanzbuchhaltung Kostenstellen eingerichtet werden.
Auf Grund der Tatsache, dass Produkte, Leistungen, Geschäftsprozesse und ggf. Kosten/
Erlöse und personelle Ressourcen miteinander in Beziehung gesetzt werden, erhält man
einen guten Überblick über das Zusammenwirken dieser Elemente sowie über mögliche
Optimierungspotenziale.
Will man sowohl Produkte, Leistungen als auch Geschäftsprozesse in Verbindung
zueinander setzen, muss auf Grund des Erhebungsaufwands, insbesondere für die
Prozesse, ein längerer Zeitrahmen festgesetzt werden.
Beschränkt man sich zunächst auf die Zuordnung der Prozesse zu den Produkten, so
ist eine relativ zügige Erhebung möglich. Abbildung 11.4 zeigt einen Ausschnitt aus einer
Produkt-Prozess-Übersicht (zum Thema „Produkt-Prozess-Matrix“ vgl. ebenso Kap. 3).
Verkehrs- und Kfz-
Angelegenheiten
Abb. 11.4 Ausschnitt einer Produkt-Prozess-Übersicht mit der Zuordnung von Leistungen
11.4.2 Kooperations- bzw. Kommunikationsbilder
Kooperations- bzw. Kommunikationsbilder haben zum Vorteil, dass sie zügig erho-
ben werden können und leicht verständlich sind. Sie stellen damit eine gemeinsame
Kommunikationsbasis für alle beteiligten Personen dar. Darüber hinaus ermöglichen sie
die komprimierte Darstellung der wesentlichen Prozessinhalte und stellen in übersicht-
licher Form die Schnittstellen zwischen den einzelnen beteiligten Akteuren dar.
Als nachteilig kann sich erweisen, dass Schwächen aus dem Detailablauf nicht erkennbar
werden, da Kooperations- bzw. Kommunikationsbilder ein sehr hohes Abstraktionsniveau
aufweisen.
In Abb. 11.5 ist ein Beispiel für ein Kooperationsbild abgebildet.
11.4.3 Detaillierte Prozessablaufmodelle
Die Vorteile dieser Erhebungsmethode bestehen in der Möglichkeit, die einzelnen

Arbeitsabläufe detailliert einzusehen und damit die Schnittstellen zwischen Abteilungen
bzw. Bearbeiterwechsel im Prozess leichter zu identifizieren. Auch die zeitliche
Reihenfolge der Prozessschritte wird dabei betrachtet. Im Rahmen der Prozessanalyse
Abb. 11.5 Kooperationsbild „Stellungnahme zu Dokument erstellen“

210 E. Wolf et al.
ist es von Vorteil, zusätzlich zur Erhebung der einzelnen Prozessschritte auch fachliche
Aspekte mit zu betrachten.
Im Rahmen einer solchen Detailerhebung werden insbesondere Informationen zu fol-
genden Aspekten erhoben:
• die im Prozess genutzten Dokumente,

• die unterstützenden IT-Systeme bzw. IT-Services, ggf. unter Berücksichtigung von
Datenflüssen,
• die durchführenden Bearbeiter/Rollen je Aktivität, ggf. unter Nutzung des DEMI-
Konzepts (DEMI = Durchführungsverantwortung, Ergebnisverantwortung, Mitwirkung,
zu Informieren),
• die für den Prozess benötigten Inputs und die im Prozess erstellten Outputs.
Auf diese Weise ist ein leichteres und umfassenderes Analysieren, z. B. im Hinblick auf
Medienbrüche, Prozessverbesserungen durch IT-Unterstützung, häufige Bearbeiterwechsel
oder Vereinheitlichung von Dokumenten, möglich (zum Thema „Dokumentation von
Prozessablaufmodellen“ vgl. ebenso Kap. 5).
Der Nachteil der Methode besteht in dem relativ hohen Zeitaufwand zur Erhebung
der Prozesse. Falls noch keine Prozessablaufmodelle im Unternehmen vorhanden
sind, empfiehlt es sich zunächst, beispielsweise anhand einer Prozesslandkarte oder
Produkt-Prozess-Übersicht, eine grobe Einschätzung der Prozesse hinsichtlich ihres
Optimierungspotenzials durchzuführen. Nachfolgend ist ein Beispiel für einen detailliert
erhobenen Prozessablauf abgebildet (vgl. Abb. 11.6).
Abb. 11.6 Beispiel für den Prozess „Überweisung annehmen“

11.5 Bewertung und Analyse
Auf der Grundlage der vorhandenen bzw. erstellten Prozessdokumentation kann die
Bewertung und Analyse der gewählten Prozesse durchgeführt werden. In diesem Schritt
werden die Prozesse auf ihre Optimierungspotenziale hin untersucht. Der Ist-Zustand
der Prozesse wird demnach einer tiefergehenden Analyse unterzogen. Auf dieser Basis
werden Schwachstellen und Verbesserungspotenziale ermittelt.
Insbesondere sind in diesem Schritt die Ursachen für unerwünschte Abweichungen vom
Zielzustand zu identifizieren. Es genügt also nicht, nur die Symptome für Schwachpunkte
zu beseitigen, sondern es müssen auch deren Ursachen und Wirkungen analysiert werden.
Beispiel
Im Rahmen der Prozessanalyse stellt sich heraus, dass die vom Mitarbeiter eingereichte
Reisekostenabrechnung zunächst durch das Sekretariat und anschließend nochmals
durch die Buchhaltung geprüft wird. Es kommt also zu einer Doppelarbeit und ggf.
sogar zu einem doppelten Korrekturvorgang beim einreichenden Mitarbeiter. Hier
ist zu analysieren, warum eine einmalige Kontrolle nicht ausreicht. Folgende Gründe
kommen in Betracht:
• ie Buchhaltung weiß nicht, dass im Sekretariat bereits eine Prüfung der

D
Abrechnung erfolgt.
• Die Buchhaltung vertraut der Prüfung durch das Sekretariat nicht, da die Prüfung
dort nicht in der erforderlichen Qualität erfolgt.
Diese Gründe sind in der Folge sehr wichtig für die Erarbeitung von Verbesserungsvor-
schlägen (vgl. Abschn. 11.6). Diese könnten bei Vorliegen des letzteren Grundes bspw.
eine Einweisung der Sekretariatsmitarbeiter durch die Buchhaltung beinhalten oder
auch die Erstellung einer Checkliste über die Prüfungskriterien.
Zur Analyse der Prozesse eignet sich eine Reihe von Instrumenten, um Schwachstellen
effizient identifizieren zu können und Verbesserungspotenziale daraus abzuleiten.
Geläufig im Rahmen der Analyse ist die Verwendung von Checklisten, in denen über
typische Fragen eine Identifikation von Schwachstellen erfolgt. Aber auch andere
Methoden sind probat, um Prozessverbesserungspotenziale zu erkennen. Diese sowie die
genannten Checklisten werden in den folgenden Unterabschnitten erläutert.
Im Rahmen der Identifikation der Schwachstellen ist ebenfalls eine Priorisierung der
Schwachstellen notwendig, d. h. welches Problem ist für das Unternehmen besonders
kritisch, welches eher weniger kritisch.
Hier kann mit einem Punktesystem verfahren werden, indem die einzelnen Probleme
in Workshops bewertet werden. Die Wichtigkeit eines Problems ist insbesondere abhän-
gig von der Beziehung zum Prozessziel und dem Einfluss auf das Prozessergebnis, z. B.
Kundenzufriedenheit, Umsatz oder Image.
212 E. Wolf et al.
Ein weiterer Einflussfaktor in der Bewertung liegt in der Dringlichkeit der Beseitigung
eines Problems. Hier wird also der zeitliche Faktor betrachtet. Beide Aspekte sind dem-
nach zu berücksichtigen.
Nachdem die Schwachstellen identifiziert und bewertet wurden, müssen diese einer
tiefergehenden Analyse unterzogen werden. Auch hierfür stehen Techniken bzw.
Ansätze zur Verfügung, die es erlauben, den Ursachen der identifizierten Probleme auf
den Grund zu gehen (vgl. Abschn. 11.5.6 und 11.5.7).
11.5.1 Checklisten
Der Vorteil bei der Verwendung von Checklisten liegt in der strukturierten Abfrage
wichtiger Prozess-Fragestellungen. Diese ermöglichen eine schnelle Identifikation von
Schwachstellen in den Prozessen.
Klassischerweise sind solche Checklisten in drei Kategorien untergliedert. Tabelle 11.1
listet diese Kategorien auf und führt beispielhafte Fragestellungen an.
11.5.2 Interviews mit Fachexperten für die einzelnen Prozesse
Die Ermittlung von Optimierungspotenzialen erfolgt idealerweise gemeinsam mit den

Mitarbeitern, welche die zu untersuchenden Prozesse ausführen. Einerseits kann es nur
Tab. 11.1 Checklisten

Checklisten-Kategorie Beispiel-Fragen
Verbesserung/Veränderung • Welche Prozessaktivitäten können durch den Einsatz von
des IT-Verfahrens Informationstechnologie optimiert werden?
• Wo existieren Medienbrüche?
• Wo kann die Anzahl von unterschiedlichen Formularen und
Dokumenten reduziert werden?
Verbesserung des Zusammen- • Wie gestalten sich die Input- und Output-Beziehungen („Wer
spiels der Akteure liefert an wen?“) und wie können diese optimiert werden
(Informationsübergaben, Reduktion von Rückfragen etc.)?
• An welchen Stellen wechselt der Prozess den Bearbeiter bzw.
kann ein häufiger Bearbeiterwechsel durch Änderung des
Bearbeitungsablaufs reduziert werden?
Steigerung der Effizienz • Wo tritt unnötige Mehrarbeit auf (Doppeleingaben, Schleifen,
unnötige Kontrollaktivitäten) und wie kann diese vermieden
werden?
• Kann die Durchlaufzeit des Prozesses durch Parallelisierung
verringert werden?
• Wo und warum treten Wartezeiten im Prozess auf?
so gelingen, die Realität abzubilden. Andererseits ist der mitarbeiterorientierte Ansatz

Grundbedingung für eine spätere erfolgreiche Implementierung der Soll-Konzeption.
Erst wenn die Mitarbeiter glaubhaft einbezogen werden und ihre Arbeit selbst mitgestal-
ten, entsteht die Motivation, sich an der Entwicklung zu beteiligen.
Interviews mit den jeweiligen Fachexperten sind daher ein wichtiges Mittel,
um Optimierungspotenziale zu identifizieren. Der Vorteil besteht darin, dass sol-
che Mitarbeiter über eine sehr detaillierte Fachkenntnis der Prozesse verfü-
gen und somit ein hohes Potenzial für die Identifikation von Schwachstellen und
Verbesserungsmöglichkeiten bestehen kann. Für die Interviews sollten Mitarbeiter aus-
gewählt werden, die Leistungsträger im Unternehmen sind und sich mit dem betrachte-
ten Prozess sehr gut auskennen.
Ein Nachteil an dieser Methode der Prozessanalyse ist, dass ggf. eine zu einge-
schränkte Sicht auf die Prozesse besteht und der Blick „von außen“ fehlt. In diesem Fall
kann es durchaus sinnvoll sein, auch Prozessexperten aus anderen Bereichen, welche
mit dem analysierten Bereich zusammenarbeiten, in die Schwachstellenanalyse einzu-
beziehen, um eventuell neue Ansatzpunkte für Verbesserungen zu erhalten. Ein gewis-
ser Zeitaufwand für die Durchführung der Befragung muss bei dieser Technik jedoch
berücksichtigt werden.
11.5.3 Kundenumfragen
Etwas aufwendiger, aber durchaus sehr aufschlussreich ist der Einbezug der Kundensicht
in die Prozessanalyse. Hierzu muss zunächst ein Fragebogen entwickelt werden, der
den Kunden durch offene Fragen die Möglichkeit bietet, Schwachstellen und Verbesse
rungspotenziale zu benennen. Dieser Fragebogen kann bspw. bei Abholung des bestell-
ten Produkts ausgehändigt werden. Möglich ist auch die IT-gestützte Beantwortung der
Fragen über einen Aufruflink im Newsletter oder einem Online-Mailing. Erfahrungsgemäß
ist allerdings die Rücklauf- bzw. Teilnahmequote bei Kundenumfragen sehr gering.
11.5.4 Benchmarking und Nutzung von Referenzprozessen
Das Prozess-Benchmarking ist die vergleichende Analyse von Prozessen mit einem fest-
gelegten Bezugswert. Dabei sind folgende Ausprägungen möglich:
• Vergleich von Prozessen innerhalb des Unternehmens (interner Wettbewerb),

• Vergleich mit Prozessen anderer Unternehmen der gleichen Branche (direkter
Wettbewerb),
• Vergleich mit Prozessen anderer Unternehmen ähnlicher Branchen (indirekter
Wettbewerb),
• Vergleich mit Prozessen anderer Unternehmen anderer Branchen.
214 E. Wolf et al.
Üblich und besonders praktikabel ist der Vergleich zwischen mehreren Standorten oder
Einheiten eines Unternehmens, in denen identische Prozesse ablaufen. Häufig stellt sich
dabei heraus, dass einzelne Standorte oder sogar einzelne Mitarbeiter bereits bestimmte
Prozessverbesserungen für sich umgesetzt haben. Diese lokal vorhandenen Best Practices
können dann meist auf andere Standorte übertragen werden.
Beispiel
Zwei Teams bearbeiten die Abrechnung von staatlich geförderten Projekten. Team A
erhält die Rechnungskopien und erstellt daraus eine eigene Nachweis-Liste für den Förder-
mittelgeber. Team B lässt sich neben den Rechnungskopien auch die Projektcontrolling-
Liste zusenden, in der alle Rechnungen bereits eingetragen sind, und erweitert diese um
einige wenige fördertechnisch relevante Spalten. Dadurch vermeidet Team B einen Groß-
teil des Aufwands für die erneute Erfassung der Rechnungen.
Schwieriger, aber bei standardisierten Prozessen ebenfalls denkbar, ist ein Vergleich
mit anderen Organisationen zur Identifizierung von Verbesserungspotenzialen. Im
Zuge des Lernprozesses von anderen Unternehmen können eigene Schwachstellen
aufgedeckt werden. Meist scheitert ein Austausch von Prozessmodellen jedoch an
den Barrieren der Datenvertraulichkeit und Informationszurückhaltung einzel-
ner Organisationen. Ein positives Beispiel stellt diesbezüglich u. a. die Kommunale
Gemeinschaftsstelle für Verwaltungsmanagement (KGSt®) in Deutschland dar, welche
den Austausch von Prozessen in der öffentlichen Verwaltung durch den Aufbau einer
kommunalen Prozessbibliothek fördern möchte (Kommunale Gemeinschaftsstelle für
Verwaltungsmanagement (KGSt) 2013).
Neben den vorgenannten Varianten des Prozess-Benchmarking kann ebenso die
Orientierung an Referenzmodellen erfolgen, die oftmals leichter zu beschaffen sind.
Referenzmodelle sind Best Practices, die als Vorlage zur Erarbeitung der Soll-Prozesse
dienen können und damit sowohl zu einer Aufwandsreduktion als auch zu einer höhe-
ren Qualität der Ergebnisse führen können. Referenzmodelle sind sowohl branchenspe-
zifisch (z. B. Versicherung, Kommunaler Master) oder aber themenbezogen erhältlich.
Im Bereich der themenbezogenen Referenzprozesse können die IT-Servicemanagement-
Prozesse gemäß der IT Infrastructure Library (ITIL®) (IT Service Management Forum
(itSMF) 2007) als Beispiel genannt werden. Hierbei erfolgt ausgehend von definierten
Prozessen die organisationsspezifische Adaption des vorgegebenen Prozesses.
11.5.5 Verbesserungsmanagement
Eine weitere Möglichkeit, Prozessschwachstellen zu identifizieren, besteht in der

Betrachtung des Verbesserungs- oder Beschwerdemanagements einer Organisation,
soweit ein solches etabliert ist. Auch dabei können durch Kunden und Mitarbeiter
Abb. 11.7 Beispiel eines Ursache Wirkung

Ishikawa-Diagramms (Capi
2008) Umfeld Maschine Mensch
Problem
… Methode Prozess
Impulse für Prozessverbesserungen gegeben werden. Insbesondere ist bei dieser Form
der Analyse der Blick aus der Kundenperspektive wertvoll.
Eine Schwierigkeit besteht allerdings darin, die für die zu untersuchenden Prozesse
relevanten Beschwerden bzw. Verbesserungsvorschläge herauszufiltern.
11.5.6 Ermittlung von Optimierungspotenzialen mit Hilfe von

Ishikawa-Diagrammen
Nachdem mit Hilfe der bisher vorgestellten Instrumente mögliche Schwachstellen iden-
tifiziert wurden, kann nun die Analyse dieser Schwachstellen erfolgen. Eine Technik
für die Analyse ist das Ishikawa-Diagramm oder auch Fischgräten- oder Ursache-
Wirkungs-Diagramm. Mit dieser Technik sollen Problemursachen identifiziert und ihre
Abhängigkeiten in einem Diagramm anschaulich dargestellt werden. Abbildung 11.7
zeigt ein Beispiel eines Ishikawa-Diagramms.
Um alle möglichen Ursachen zu berücksichtigen, werden verschiedene Dimensionen
betrachtet, z. B. Mensch, Maschine, Methode, Prozess, Management, Umfeld. Diese
bilden die Basisgräten des Fischs. Bei der Fischgrätenanalyse wird – in der Regel im
Rahmen eines Brainstormings – generell drei Mal nach dem „Warum?“ gefragt, da
man sich nicht mit „vorgeschobenen“ Aspekten zufrieden gibt, sondern den tatsäch-
lichen Ursachen sowie Nebenursachen auf den Grund gehen will. Diese mehrstufige
Ursachenforschung wird durch die verschiedenen Pfeile in der Abbildung repräsentiert.
11.5.7 Ermittlung von Optimierungspotenzialen anhand von

Reifegradmodellen
Für ein erfolgreiches Geschäftsprozessmanagement und die stetige Verbesserung von

Geschäftsprozessen stellt die permanente Überprüfung der Leistung ein wesentliches
Instrument dar. Diese Überprüfung wird üblicherweise in sogenannten Reifegradbewertungen
216 E. Wolf et al.
bzw. Prozess-Assessments vollzogen. Reifegradmodelle sind geeignet, um den aktuellen Status

eines Prozesses, dessen Schwachstellen und Schritte zur Optimierung zu bestimmen.
Eine konzeptionelle Grundlage zur Reifegradermittlung bietet beispielsweise
das GPM-Reifegradmodell (Schmelzer und Sesselmann 2008, S. 316). Das GPM-
Reifegradmodell kann je nach Betrachtungsgegenstand in das PAG-Modell (Prozess-
Assessment für Geschäftsprozesse) sowie das PAU-Modell (Prozess-Assessment für
Unternehmen) unterschieden werden (Schmelzer und Sesselmann 2008, S. 316). Wir
haben in Anlehnung an das PAG-Modell ein Vorgehensmodell entwickelt, das auf die
Bewertung konkreter Geschäftsprozesse fokussiert.
In unserem Reifegradmodell werden die folgenden Dimensionen betrachtet (vgl.
ebenso Abb. 11.8):
• Ziele und Kennzahlen,

• Prozesse und Vorgehensweisen,
• Rollen und Verantwortlichkeiten,
• Fähigkeiten und Kompetenzen,
• Prozess- und Risikobewusstsein und Kommunikation sowie
• Tools und Automatisierung.
Ziele und
Kennzahlen
Prozesse und
Tools und
Vorgehens-
Automatisierung
weisen
Geschäftsprozess
Prozess- und
Rollen und
Risiko-
Verantwortlich-
bewusstsein und
keiten
Kommunikation
Fähigkeiten und
Kompetenzen
Abb. 11.8 Dimensionen zur Bewertung eines Geschäftsprozesses

Mit dieser Vorgehensweise wird der gesamt-organisatorische Aspekt des Geschäftsprozesses

angemessen berücksichtigt.
Innerhalb des Prozess-Assessments erfolgt anschließend eine Bewertung der einzel-
nen Dimensionen des Geschäftsprozesses, wobei die Reifegradstufen 0 („Nicht existent“)
bis 5 („Optimiert“) verwendet werden können (vgl. Abb. 11.9).
Mit Hilfe eines Fragen- und Bewertungskatalogs kann der Reifegrad einer
Dimension anhand des Erfüllungsgrads von definierten Kriterien gemessen werden. Im
REIFEGRAD
5
Optimiert
REIFEGRAD
4 Prozesse sind
Gesteuert und bis zur Stufe
messbar von „Good
REIFEGRAD
Practices“
3 Das verfeinert. Dies
Management basiert auf den
Definierter
überwacht und Resultaten der
REIFEGRAD Prozess
misst die kontinuier-
2 Die Vorgehens- Einhaltung der lichen
Wiederholbar weisen sind Verfahren und Verbesserung
aber intuitiv standardisiert, führt und dem
REIFEGRAD
dokumentiert Maßnahmen Reifegrad-
1 Wiederholbare, und wurden durch, wenn vergleich mit
aber intuitive durch Prozesse anderen Orga-
REIFEGRAD Initial/Ad -hoc Prozesse Schulungen nicht effizient nisationen. IT
wurden vermittelt. zu sein
0 Die entwickelt
wird in einer
Es ist ver- scheinen. Auto- integrierenden
Organisation in dem bindlich, dass matisierung Art und Weise
Nicht existent hat erkannt, Ausmaß, dass dem vor- und Tools verwendet, um
dass die ähnliche geschriebenen werden in
Erkennbare Arbeitsabläufe
Fragestellung Vorgehens- Prozessablauf begrenztem
Prozesse zu
existiert und weisen von gefolgt wird. Maße genutzt. automatisieren,
fehlen beantwortet verschiedenen Die Vorgehens-
komplett. Die bietet
werden muss. Bearbeitern der weisen sind
Organisation Werkzeuge zur
Es gibt Ad-hoc- gleichen nicht verfeinert,
hat nicht Verbesserung
Ansätze, die Aufgabe aber aus exis -
einmal erkannt, auf der Qualität
durchgeführt tierenden und Effizienz
dass die individueller werden. Es gibt Verfahren
Fragestellung und schafft
oder Fall-zu- eine hohe formalisiert.
überhaupt eine hohe
Fall-Basis Abhängigkeit
existiert. Wandlungs-
angewendet von indivi- fähigkeit der
werden. Der duellen Organisation.
übergreifende Bearbeitern.
Ansatz ist ohne Das Auftreten
formale von Fehlern ist
Organisation. wahrscheinlich.
Abb. 11.9 Reifegradstufen von Prozessen (in Anlehnung an das PAG-Modell (Schmelzer und
Sesselmann 2008))
218 E. Wolf et al.
Fragen- und Bewertungskatalog werden dezidiert Kriterien abgefragt, anhand derer die
Reifegradbestimmung des Prozesses erfolgt. Nicht erreichte Kriterien – diese orientieren
sich in der Reifestufe 5 am optimalen Zustand – zeigen gleichzeitig Verbesserungspotenziale
sowie den Weg auf, um zum nächsten Reifegrad-Level zu gelangen.
Auf Basis des ermittelten Zustands des Prozesses erfolgt die Definition des Soll-
Reifegrads (vgl. Abb. 11.10). Diese Einschätzung ist insbesondere von den zu erfüllen-
den Kriterien bzw. Bedingungen abhängig, die erforderlich sind, um die nächsthöhere
Reifegradstufen
6. Tools und
Zielsetzung und Definition 1. Ziele und Kennzahlen
Automatisierung
von Kennzahlen
Prozesse zur Messung
Kontroll- und Prüfaktivitäten
und Überwachung
Kontinuierliche
Prozessautomatisierung
Verbesserung
Nutzung von
Prozessstruktur
Anwendungen
und Tools 2. Prozesse und
Vorgehensweisen
Internes
Kontrollsystem Prozessablauf und
-dokumentation
Reporting und Weiterführende

Kommunikation Dokumentation
Regelmäßige Treffen Rollenmodell
5. Prozess- und
Risiko- Wissens- Akzeptanz der Rollen
bewusstsein austausch und Empowerment
und Kommunikation Schulungen und Kompetenzen
Mitarbeiter- und Qualifikationsniveau
entwicklung
3. Rollen und
4. Fähigkeiten und Kompetenzen Verantwortlichkeiten
Aktueller Reifegrad Zielreifegrad
Abb. 11.10 Ist- und Soll-Reifegradermittlung

Reifegradstufe zu erreichen. Hierbei spielen beispielsweise wirtschaftliche Aspekte eine

Rolle.
Idealerweise schließt die Phase der Bewertung und Analyse bereits mit ersten
Maßnahmenvorschlägen ab, die erforderlich sind, um einen höheren Reifegrad zu
erreichen.
11.6 Soll-Konzeption
Nach der Identifikation und Analyse von Schwachstellen sollen darauf aufbauend
Verbesserungsvorschläge für die Beseitigung der Schwachpunkte und Umsetzung der
Optimierungspotenziale entwickelt werden.
Zu empfehlen sind in diesem Kontext Listen, in denen die Schwachstellen aufge-
führt, priorisiert und mit Verbesserungsvorschlägen versehen werden können. Für die
Erarbeitung von Verbesserungsvorschlägen werden häufig Brainstorming-Methoden
verwendet, wie z. B.:
• das klassische Brainstorming,

• die „Methode 635“ (Rohrbach 1969) zur strukturierten Entwicklung von Ideen oder
• Scamper (Eberle 1996) oder die Osborn-Checkliste (Osborn 1957) als systematisches
Vorgehen für die Modifizierung existierender Prozesse.
Nach der initialen Auflistung von Vorschlägen ist die Bewertung der einzelnen Verbes
serungsvorschläge von großer Bedeutung. Nutzen und Aufwand für die Umsetzung
müssen in Relation gesetzt werden. Umfangreiche Verbesserungsvorschläge werden häu-
fig in einer separaten Machbarkeitsstudie im Hinblick auf ihre Umsetzbarkeit bewertet.
Es ist also zu evaluieren, welche erforderlichen Aufwände mit der Umsetzung verbunden
sind und welcher Nutzen für das Unternehmen durch eine Umsetzung realisiert werden
kann.
Kommen mehrere Vorschläge für Prozessänderungen in Betracht, so ist es sinnvoll,
Soll-Prozessvarianten zu erstellen und diese miteinander zu vergleichen, um anschlie-
ßend die geeignetste zur Umsetzung heranzuziehen. Sind zum Beispiel bereits Kosten
und/oder Zeiten für die Ist-Prozesse erhoben worden, können diese für die verschiede-
nen Soll-Varianten prognostiziert und die Ergebnisse separat bewertet werden.
Bewegt man sich noch auf einem niedrigeren Detailgrad und hat noch keine
Berechnungsdaten erhoben, kann auch das Hervorheben von Verbesserungsvorschlägen
im Prozess sinnvoll sein: Modellierungswerkzeuge bieten die Möglichkeit, sowohl
Änderungen im Modell durch Kennzeichnungen sichtbar zu machen als auch die
Verbesserungsvorschläge textuell zu beschreiben, wie anhand von Abb. 11.11 beispiel-
haft gezeigt wird.
Auch auf dieser Basis ist eine Bewertung von Prozessvarianten möglich. Nach der
Bewertung der Varianten soll eine Entscheidung darüber gefällt werden, welche der
220 E. Wolf et al.
Abb. 11.11 Kennzeichnung von Änderungen in Prozessen
Tab. 11.2 Ausschnitt aus einer Maßnahmenliste

Prozess Maßnahme Nutzen Aufwand Verantwortlich Termin
Anlagenbuch- Standardisierung Vermeidung Kosten für Leitung 31.12.2013
haltung der Durchführung manuellen Anschaffung Buchhaltung
der Inventur Erfassungsaufwands Handscanner
Mahnwesen Verlagerung der Zeitersparnis – Leitung 31.03.2014
Kuvertiertätigkeiten durch Nutzung Poststelle
nach Mahnläufen in der vorhandenen
die Poststelle Kuvertiermaschine
Zahlungs- Erweiterung Verringerung Kosten für Leitung 30.06.2013

verkehr Zahlungsmöglich Arbeitsaufwand im Anschaffung EC- Verkauf
keiten um Bereich Kasse, Gerät, Bankgebühren
EC-Gerät Steigerung der für Abwicklung
Kundenzufriedenheit
Verbesserungsvorschläge in konkrete, umzusetzende Maßnahmen münden sollen. Die

Liste der Verbesserungsvorschläge wird also zu einer konkreten Maßnahmenliste. Diese
Maßnahmen werden anschließend zeitlich priorisiert und es muss festgelegt werden, wer
für die Umsetzung der jeweiligen Maßnahmen verantwortlich ist. In Tab. 11.2 findet sich
ein beispielhafter Ausschnitt aus einer Maßnahmenliste.
Sogenannte Quick Wins sind prädestiniert für eine umgehende Umsetzung, denn sie
sind charakterisiert durch folgende Merkmale:
• Es sind jene Ideen, mit deren Umsetzung ein schneller Erfolg realisiert werden kann.
• Sie erzielen mit geringem Aufwand ein sichtbares und verbessertes Ergebnis.
• Die dadurch erzielten Resultate tragen dazu bei, Akzeptanz für Neuerungen (durch
mentale Einbindung der Beteiligten) und umfassendere Prozessverbesserungen zu
schaffen.
• Sie können mittels Sofortmaßnahmen direkt umgesetzt werden. Nur selten ist hierfür
ein Projekt notwendig.
Das Augenmerk sollte also bei der geplanten Umsetzung auf der Realisierung dieser
Quick Wins liegen.
11.7 Umsetzung der Maßnahmen und Dokumentation

der Soll-Prozesse
Im letzten Schritt eines Prozessoptimierungs-Projekts erfolgen die Umsetzung der defi-

nierten Maßnahmen und die Dokumentation der Soll-Prozesse.
In den Soll-Prozessen werden die umzusetzenden Maßnahmen eingearbeitet. Typische
Prozessänderungen betreffen die Automatisierung, Auslagerung, Parallelisierung,
Eliminierung oder die Standardisierung von Prozessteilen.
Des Weiteren müssen in diesem Schritt die Planung und die Umsetzung inklusive
der zeitlichen Vorgaben und Bereitstellung von Ressourcen vorgenommen werden.
Detailliertere Informationen zur Maßnahmenumsetzung werden in Kap. 12 und 13
beschrieben, wobei in Kap. 12 insbesondere die Begleitung der Maßnahmenumsetzung
durch ein Veränderungsmanagement behandelt wird.
Literatur
Capi (2008) Ursache-Wirkungs-Diagramm, oder Ishikawa Diagramm als Fischgräten-Diagramm.

http://commons.wikimedia.org/wiki/File:Ursache_Wirkung_Diagramm_allgemein.svg.
Eberle B (1996) Scamper on: Let your imagination run wild! Prufrock Press, Waco
IT Service Management Forum (itSMF) (2007) An Introductory Overview of ITIL® V3,
Dokumentation, Wokingham. http://www.best-management-practice.com/gempdf/itsmf_an_i
ntroductory_overview_of_itil_v3.pdf. Zugegriffen: 07. Jan 2013
Kommunale Gemeinschaftsstelle für Verwaltungsmanagement (KGSt) (2013) Prozessbibliothek,
Köln. http://www.kgst.de/produkteUndLeistungen/prozessbibliothek/. Zugegriffen: 07. Jan 2013
Osborn A-F (1957) Applied imagination. Scribner, New York
Rohrbach B (1969) Kreativ nach Regeln – Methode 635, eine neue Technik zum Lösen von
Problemen. Absatzwirtschaft 12(19):73–76
Teil V
Prozessumsetzung
Organisatorische Umsetzung
12
Eckart Hagenloch, Stefan Müller und Mario Scherber
Zusammenfassung
Die organisatorische Umsetzung von Soll-Prozessen stellt für die direkt und indi-
rekt beteiligten Menschen eine große Herausforderung dar. Aufbauend auf den
vorangegangenen Kapiteln in diesem Buch werden methodische und praktische
Grundlagen für die Umsetzung von Soll-Prozessen gegeben. Innerhalb des Kapitels
wird auf wichtige Rahmenbedingungen eingegangen, die zu den angestrebten
Veränderungen geführt haben und/oder bei der Umsetzung berücksichtigt wer-
den müssen. Mit den Ausführungen zur Umsetzungsplanung werden praktische
Hinweise und Empfehlungen gegeben, die über ein Projektmanagement hinaus für
die Planung der anstehenden Veränderungen relevant sind. Neben der Vorstellung
wichtiger Erfolgsfaktoren, wie der Identifikation der Adressaten sowie der zeitlichen
und personellen Planung, wird umfänglich auf Aspekte der geeigneten Einbindung
von Beteiligten und Betroffenen eingegangen. Es werden Techniken für ein effizientes
Veränderungsmanagement, unterstützt durch Elemente des Prozessmarketings, ver-
mittelt. Das Kapitel verschafft einen Überblick von der formalen Umsetzungsplanung
bis hin zu den weichen Faktoren (engl. Soft Facts), wie z. B. den Umgang mit
Widerständen für eine erfolgreiche Einführung von Soll-Prozessen mit dem wichtigen
Erfolgsfaktor „Mensch“.
E. Hagenloch (*) · S. Müller · M. Scherber

e-mail: eckart.hagenloch@boc-de.com

226 E. Hagenloch et al.
12.1 Prozessumsetzung als Teil des Process Management

Life Cycle
Ein wichtiger Faktor für den Erfolg von Prozessoptimierungs-Projekten ist die struktu-
rierte und gut geplante Prozessumsetzung. Nicht selten scheitern Prozessverbesserungs-
Projekte trotz hervorragend ausgearbeiteter Soll-Konzepte an einer mangelnden
Vorbereitung und Strukturierung der Prozessimplementierung und somit an den orga-
nisatorischen und sozialen Gegebenheiten einer Organisation.
Die Phase der Prozessumsetzung ist ein zentrales Element des Process Management
Life Cycle (PMLC, vgl. Abschn. 2.4.4). In der Praxis erfolgt die Prozessumsetzung
entweder im Rahmen der Prozessoptimierungs-Projekte oder im Anschluss an ein
Verbesserungsprojekt. Die Basis bilden letztlich aber immer die freigegebenen Soll-
Prozesse bzw. abhängig vom Grad der Änderungen das freigegebene Soll-Konzept. Nur
so können dem Prozessimplementierungs-Team eine Orientierungshilfe und Grundlage
gegeben werden.
Da Prozessverbesserungen häufig Einfluss auf die Aufbauorganisation haben, Menschen
neue oder geänderte Aufgaben gestellt bekommen bzw. andere Kommunikations- und IT-
Kanäle nutzen müssen, spielt das Thema Veränderungsmanagement ebenso eine wichtige
Rolle im Rahmen der Prozessumsetzung.
Die Begrifflichkeiten Prozessumsetzung, -einführung bzw. -implementierung wer-
den häufig synonym verwendet. Letztlich versteckt sich hinter allen Begriffen die prak-
tische Umsetzung und Überführung der Soll-Prozesse in den Regelbetrieb, d. h. die
Verankerung in organisatorischer und technischer Hinsicht. Die Prozessumsetzung
ist daher eine systematische, meist projektartige Vorgehensweise, die alle unmittel-
bar und mittelbar Beteiligten mit den jeweils notwendigen Informationen versorgt,
Rückkopplungen aus Umsetzungsschritten berücksichtigt und die Soll-Prozesse prak-
tisch ausführbar gestaltet.
Bestandteile der Prozessumsetzung sind somit der Umsetzungsplan (vgl.
Abschn. 12.3), die Umsetzung selbst (vgl. Abschn. 12.4) sowie das begleitende Verände
rungsmanagement (vgl. Abschn. 12.5) und ggf. ein Prozessmarketing (vgl. Abschn. 12.6).
Der Zusammenhang der Begrifflichkeiten untereinander wird durch Abb. 12.1
veranschaulicht.
Das Veränderungsmanagement umfasst die aktive Beeinflussung von organisatori-
schen Veränderungen mit verschiedenen Formen der Information, Kommunikation
und Beteiligung. Im Mittelpunkt des Veränderungsmanagements steht hierbei der
Mensch als Erfolgsfaktor einer Prozessimplementierung. Beim Prozessmarketing steht
vor allem die Vermarktung von Prozessoptimierungs-Projekten und Veränderungen im
Mittelpunkt, um einen frühzeitigen Austausch mit allen Adressaten zu gewährleisten.
Häufig wird dieser Teil der Prozessimplementierung auch als Akzeptanzmanagement
bezeichnet.
12 Organisatorische Umsetzung 227
• Überführung des Soll-Konzepts

in einen Umsetzungsplan (Meilensteine)
Prozessumsetzung • Definition von Verantwortlichkeiten im
Rahmen der Prozesseinführung
• Implementierung der Prozessveränderung
• Zielgerichtetes Planen,
• Steuern und
Veränderungsmanagement • Umsetzen von komplexen
Veränderungen in Organisationen
• Regelmäßige Informationen
Prozessmarketing • Kontinuierliche Feedback-Verarbeitung
Abb. 12.1 Veränderungsmanagement und Prozessmarketing als Bestandteile der Prozessumsetzung
12.2 Rahmenbedingungen und Herausforderungen der

Prozessumsetzung
Prozessumsetzung ist eine Managementaufgabe, die nur auf Basis hoher Akzeptanz bei
allen Beteiligten erfolgreich und im zeitlichen und finanziellen Rahmen erfüllt werden
kann. Allerdings stehen genau diese Projekte häufig unter enormem Zeitdruck. Um
erfolgreich zu sein, müssen fünf wichtige Rahmenbedingungen berücksichtigt werden:
1. Wirtschaftliche Rahmenbedingungen
Prozessumsetzungen stehen einerseits unter dem Einfluss des wirtschaftlichen Drucks
der Prozessveränderung und andererseits selbst unter der Vorgabe eines Projektbudgets.
2. Organisatorische Rahmenbedingungen
Prozessverbesserungen haben üblicherweise einen Einfluss auf die Aufbauorganisation.
Neue Rollen oder Aufgabenverlagerungen müssen mit der vorhandenen Ressourcen
ausstattung abgeglichen werden. Besondere Berücksichtigung muss vorhandenen
Betriebsvereinbarungen geschenkt werden, die letztlich einen wesentlichen Einfluss auf
den Grad einer Prozessumsetzung haben können.
3. Technische Rahmenbedingungen
Einführung oder Veränderung von neuen bzw. bestehenden IT-Anwendungen sind
wesentliche Erfolgsfaktoren von Prozessverbesserungen (vgl. ebenso Kap. 13). Im
Rahmen der Prozessumsetzung sind allerdings technische Begrenzungen zu berück-
sichtigen. Die vorhandene IT-Infrastruktur oder auch mangelnde IT-Kapazitäten
können wesentlichen Einfluss auf die Prozessumsetzung nehmen.
4. Soziologische/kulturelle Rahmenbedingungen
Die Unternehmenskultur und -flexibilität sind wichtige zu berücksichtigende
Faktoren im Rahmen einer Prozessimplementierung. Ist die Unternehmenskultur
nur bedingt veränderungsbereit, muss auch das Projektteam während der Prozess
umsetzung darauf reagieren.
5. Persönliche Rahmenbedingungen
Persönliche Erfahrungen der Adressaten im Umgang mit Veränderungen sind wich-
tig für eine proaktive Mitwirkung im Rahmen der Veränderung oder Ursache für auf-
tretenden Widerstand.
Die Umsetzungsplanung und -durchführung, vor allem aber das begleitende Verän
derungsmanagement, müssen genau diese Rahmenbedingungen berücksichtigen, um
Soll-Prozesse erfolgreich in der Organisation zu verankern.
Beispiel
Die Mustermann GmbH ist gewillt, das vorgelegte Soll-Konzept für den Dienstrei-
seantrag erfolgreich umzusetzen. Die Umsetzung ist enorm durch wirtschaftliche
Vorgaben getrieben, da die Reisekosten in den letzten Jahren um 20 % gestiegen sind
und nun gesenkt werden sollen. Technische Rahmenbedingungen sind insbeson-
dere durch das vorgeschlagene neue IT-System gegeben, welches webbasiert einen
Workflow zur Verfügung stellt. Das Umsetzungsteam ist zudem aufgrund der orga-
nisatorischen Umstrukturierung der Reisestelle und der telefonischen Auskunft mit
organisatorischen Rahmenbedingungen konfrontiert.
12.3 Umsetzungsplanung und Umsetzungsformen
Grundlage für die Planung und Festlegung der Ziele der Prozessumsetzung bietet in
der Regel das Soll-Konzept. Hier sind die Soll-Prozesse beschrieben und aus den Soll-
Konzept-Schwerpunkten lassen sich die Meilensteine für den Umsetzungsplan ableiten.
Dabei ist es wichtig, zu beachten, dass die Ziele der Prozessumsetzung auch vom Soll-
Konzept abweichen können.
Beispiel
Nach Vorlage des Soll-Konzepts beim Betriebsrat wurden klare Bedenken vor-
gebracht. Einerseits müssen dadurch Änderungen im Soll-Konzept hinsichtlich
der Umstrukturierung der Aufbauorganisation berücksichtigt werden und ande-
rerseits wurden Kriterien bei der Auswahl der neuen Software im Rahmen des
Beteiligungsrechts durch den Betriebsrat nicht bestätigt. Deshalb muss auch hier
eine erneute Anpassung erfolgen.
Im Rahmen der Umsetzungsplanung/-durchführung wird die Umsetzungsform festgelegt

sowie darauf aufbauend die personelle Projektbesetzung und zeitliche Planung bestimmt.
Ein weiterer Schwerpunkt besteht darin, alle an der Umsetzung Beteiligten zu identifizie-
ren und diese, entsprechend der Art ihrer Beteiligung und mit dem gezielten Einsatz der
jeweils sinnvollen Medien, einzubinden.
Da es sich bei der Durchführung der Prozessumsetzung letztlich häufig um ein
Projekt bzw. die Fortführung eines Prozessoptimierungsprojekts handelt, bildet das
Projektmanagement die entsprechende Basis dafür. Abweichend von der Durchführung
im Rahmen eines Projekts gibt es noch die Variante der Prozessumsetzung im Rahmen
des PMLC bzw. Kontinuierlichen Verbesserungsprozesses (KVP) (Witt und Witt 2007),
bei welchen dies als laufende Tätigkeit betrachtet wird.
Im vorliegenden Kapitel soll nicht vertiefend auf die Grundlagen des Projektmanage
ments eingegangen werden. Vielfach ist die zu wählende Projektmanagement-Methode
in Unternehmen auch bereits vorgegeben. Es wird dabei auf bewährte Methoden, wie
PRINCE2® (Office of Government Commerce (OGC) 2009) oder PMBOK® (Project
Management Institute (PMI) 2010) aufgebaut, welche die Projektplanung, Projektorgani
sation usw. grundlegend beschreiben und vorgeben.
Da die Prozessumsetzung in Projektform durchgeführt wird, liegt der Schwerpunkt an
dieser Stelle darauf, wie bestimmte Aspekte des Projektmanagements auf die Prozessum
setzung angewendet werden sollen und welche Besonderheiten dabei zu beachten sind.
Zu Beginn der Prozessumsetzung muss die Umsetzungsform festgelegt werden, da
sich aus dieser bestimmte Erfolgsfaktoren für die Umsetzungsdurchführung ableiten las-
sen. Hierzu zählen u. a. die personelle und zeitliche Gestaltung des Umsetzungsprojekts
sowie die verwendeten Kommunikationsmittel.
Es können folgende Vorgehensweisen der Prozessumsetzung unterschieden werden
(Fischermanns 2010, S. 354):
• Schlagartig
Die kompletten Prozesse (oder Anwendungen) werden bei allen Betroffenen
gleichzeitig eingeführt und vorhandene Abläufe werden sofort verworfen. Ein
Parallelbetrieb ist demnach nicht möglich.
• Stufenweise
Teile der Prozesse (oder Anwendungen) werden nacheinander eingeführt. Häufig
wird hierfür eine Pilotierung durchgeführt, auf welche andere Organisationseinheiten
aufsetzen.
• Parallel laufend
Der neue Prozess (oder die neue Anwendung) wird eingeführt und die bisheri-
gen werden als Back-up vorgehalten oder es werden beide Lösungen nebeneinander
genutzt (seltenerer Fall).
Maßgeblich für die Entscheidung, welche Variante gewählt wird, sind die bereits
beschriebenen fünf Rahmenbedingungen der Prozessumsetzung (vgl. Abschn. 12.2). Die
Wahl der Umsetzungsform wird bspw. dadurch beeinflusst, wie hoch der wirtschaft-
liche Druck der Prozessumsetzung ist oder ob im Rahmen der Umsetzung auch die
Einführung einer neuen IT-Anwendung ansteht (vgl. Kap. 13).
Weitere Einflussfaktoren zur Bestimmung der jeweiligen Umsetzungsform kön-
nen bestimmte individuelle Gegebenheiten sein, wie z. B. der entstehende Aufwand,
das Thema Sicherheit (d. h. eher stufenweise oder parallel laufende Einführung anstatt
schlagartige Einführung) aber auch die personelle Ressourcenverfügbarkeit.
Beispiel
Die Mustermann GmbH hat sich bei der Einführung des Soll-Konzepts für eine
schlagartige Umsetzung entschieden. Organisatorisch hat die neue Struktur maß-
gebliche Änderungen zur Folge, sodass das parallele Vorhalten der alten Struktur
nicht sinnvoll erscheint. Das neue IT-System soll zu einem festen Stichtag für alle
Mitarbeiter zur Verfügung stehen.
12.4 Erfolgsfaktoren bei der Umsetzungsplanung/

-durchführung
Für die Planung der Prozesseinführung wurden folgende Erfolgsfaktoren identifiziert,

die in jedem Einführungsprojekt berücksichtigt werden sollten:
1. Identifikation der Adressaten

2. Zeitliche Gestaltung
3. Personelle Gestaltung (Ressourcen)
4. Formen der Einbindung (I-K-B-Modell (Scherber et al. 2011))
5. Festgelegte Medien
6. Interaktion
Diese Erfolgsfaktoren werden in den folgenden Abschnitten näher beschrieben.
12.4.1 Identifikation der Adressaten
Ein Hauptaugenmerk liegt auf der Identifikation der Adressaten, also wer über die
Prozesseinführung informiert oder in diese involviert werden sollte. Alle Adressaten
benötigen einen unterschiedlichen Grad an Informationen. Einige müssen konkret
wissen, wie zukünftig der Prozess detailliert zu durchlaufen ist. Anderen reicht die
Information, was sich grundsätzlich im Prozess ändert.
Es werden folgende Adressaten unterschieden (in Anlehnung an European

Association of Business Process Management EABPM 2009, S. 187):
• Direkt betroffene Aufgabenträger

Diese sind direkt von der Prozesseinführung betroffen und werden daher stark an der
Umsetzung beteiligt. Hier sind vielfach Schulungs- oder Umschulungsmaßnahmen
notwendig.
• Nicht direkt betroffene Aufgabenträger
Unter bestimmten Umständen ist es notwendig, nicht direkt von der Prozesseinführung
betroffene Personen ebenfalls einzubeziehen. Dazu können bspw. der Betriebsrat,
bestimmte Gremien oder Beauftragte in Unternehmen, aber auch Führungskräfte nicht
betroffener Bereiche zählen.
• Entlastete
Zu dieser Gruppe gehören alle Personen und Organisationseinheiten, die nicht mehr
oder in angepasster Form am Soll-Prozess beteiligt sind. Diese dürfen nicht außer Acht
gelassen werden und sollten im Business Case des Soll-Konzepts berücksichtigt sein.
• Lieferanten und Kunden
Diese Adressaten stehen außerhalb des Unternehmens. Je nachdem, wie stark die
Prozesseinführung diese betrifft, werden sie nur informiert oder stärker involviert.
Beispiel
Auch für die Mustermann GmbH ist die Identifikation sämtlicher Adressaten ein wich-
tiger Erfolgsfaktor. Das Projektteam konnte die Sachbearbeiter der Reisestelle und der
internen Abrechnung als direkt betroffene Aufgabenträger identifizieren. Für diese
Rollen wird sich die zukünftige Arbeit grundlegend ändern. Als indirekt betroffene
Aufgabenträger wurden die IT-Abteilung und der Betriebsrat identifiziert. Die zentrale
Telefonauskunft wird vom neuen Prozess entlastet. Zukünftig werden diese Mitarbei-
ter nicht mehr beim Dienstreiseantrag involviert sein. Da der Reisevorschuss entfällt,
wird der Sachbearbeiter „Reisekasse“ anderweitig eingesetzt werden müssen.
12.4.2 Zeitliche Gestaltung
Ein weiterer Erfolgsfaktor für ein gelungenes Prozessumsetzungs-Projekt ist die solide
zeitliche Planung. Abhängig von der gewählten Umsetzungsform kann die Zeitplanung
stark in ihren einzelnen Phasen variieren.
Sobald der zeitliche Rahmen (Start- und Endtermin) für das Umsetzungsprojekt
bestimmt wurde, kann die tatsächliche Planung beginnen. Das ganze Projekt wird in
einzelne Arbeitspakete aufgeteilt und Meilensteine zur Überprüfung der Zwischenergeb
nisse definiert. Weiterhin sollte im Zeitplan für jedes Arbeitspaket vor Beendigung ein
Qualitätssicherungsschritt vorhanden sein sowie festgelegt werden, wann die

Berichterstattung und Ergebnispräsentation dazu erfolgt.
In Abhängigkeit der aktuellen Gegebenheiten im Projekt sollte die Zeitplanung laufend
überprüft, auf Basis der einzelnen Meilensteinergebnisse und der Ressourcenverfügbarkeit
hinterfragt und ggf. angepasst werden.
12.4.3 Personelle Gestaltung (Ressourcen)
Das Projekt setzt sich klassischerweise aus einem Projektleiter und Projektmitarbeitern
zusammen. Der Projektleiter überwacht und steuert dabei die Veränderungen im Rahmen
des Umsetzungsprojekts. Optimal wird diese Rolle durch den Prozessverantwortlichen des
Soll-Prozesses besetzt, da er später die dauerhafte Verantwortung für den Erfolg bzw. die
Zielerreichung des Prozesses übernimmt.
Die Projektmitarbeiter zeichnen sich durch ihre jeweilige Sachkompetenz aus
und bestehen dabei aus Fachexperten, IT-Mitarbeitern, Mitarbeitern mit Schulungs
kompetenzen, aber idealerweise auch aus Führungskräften der Betroffenen, um eine
höhere Akzeptanz bei der Einführung zu schaffen. Ein guter Weg, das Know-how des
Optimierungsprojekts in die Umsetzungsphase zu integrieren, besteht darin, Mitarbeiter
zu involvieren, die bereits während der Optimierung und der Erstellung der Soll-Prozesse
beteiligt waren. Des Weiteren kann es hilfreich sein, einen Veränderungsmanager ins
Projektteam zu holen, der in Fragen der Organisationsentwicklung berät, aber der auch
auf menschlicher Ebene mit den Betroffenen agiert.
Neben der Sicherstellung der qualitativen Kompetenzen der Projektmitarbeiter sollte
das Vorhandensein der personellen Ressourcen geprüft werden. Dabei ist zu ermitteln,
welche Projektmitarbeiter in welchem Umfang in den verschiedenen Arbeitspaketen
benötigt werden und ob eine Unterstützung durch externe Ressourcen zur Erfüllung des
Zeitplans notwendig ist.
12.4.4 Formen der Einbindung (I-K-B-Modell)
Sobald die vier genannten Adressaten für den Prozess identifiziert wurden (vgl.
Abschn. 12.4.1), bleibt zu entscheiden, in welchem Ausmaß diese nun in die Umsetzung
eingebunden werden. Für die differenzierte Einbindung der Adressaten haben wir ein
Modell entwickelt, welches insbesondere für Planungs- und Entscheidungsphasen eine
Auswahl der Formen der Einbindung vereinfachen soll. Dieses „I-K-B-Modell“ unter-
scheidet drei Formen der Einbindung (Scherber et al. 2011):
• Information
Ziel ist es, die Adressaten ausreichend über die Umsetzung sowie über die Notwen
digkeit zur Veränderung zu informieren, um Bewusstsein und Verständnis zu schaffen.
Die reine Information der Mitarbeiter schließt dabei die Kommunikation und direkte
Beteiligung aus.
• Kommunikation
Ziel ist es, die Umsetzung und Veränderung ausreichend zu kommunizieren, um
Transparenz und Verständnis zu schaffen. Bei der Kommunikation handelt es sich
um den Austausch von Informationen und nicht um eine unidirektionale Weitergabe
von Informationen.
• Beteiligung
Ziel ist es, alle Betroffenen mit ins Boot zu holen und entsprechend am Verände
rungsprozess zu beteiligen, um Ängsten und Widerständen zu begegnen. Damit
werden Betroffene zu Beteiligten gemacht und können sich später besser mit den
Veränderungen identifizieren.
Wenn im Rahmen der Umsetzungsplanung feststeht, welche Adressaten in welcher

Form eingebunden werden, kann auch der Projektplan parallel zu den Arbeitspaketen
und Meilensteinen um die Termine erweitert werden, an denen planbarer Informations-,
Kommunikations- oder Beteiligungsbedarf der Adressaten besteht. Dies wird in
Abb. 12.2 visualisiert. Darüber hinaus ist das Modell geeignet, eine ungeplante
Einbindung von Adressaten hinsichtlich der geeigneten Form vorzubereiten. Dies wird
durch die in Abb. 12.3 dargestellte Zuordnung von Medien unterstützt.
Offen bleiben jedoch die Fragen „Wie genau werden die Mitarbeiter informiert?“ und
„Wie wird mit den Mitarbeitern kommuniziert und der Austausch gefördert?“. Um diese
Fragen zu beantworten, werden Medien benötigt, die eine zielgerichtete Interaktion mit
den Adressaten ermöglichen (vgl. Abschn. 12.4.5).
AP5: Projektkoordination, Berichtswesen, Dokumentation u. Querschnittsaufgaben
AP4
Start Implementierung
AP3
und Optimierung GPM
AP2
AP1
KW01 KW02 KW03 KW04 KW05 KW06 KW07 KW08 KW09 KW10 KW11 KW12
Ereignis AP1 Legende:
Arbeitspaket
QS AP1
Berichterstattung
Ereignis AP2 Qualitätssicherung
Informationsbedarf I
QS AP2
Kommunikationsbedarf K
Beteiligungsbedarf B
I K K I I I I I
B B B K B K B
Abb. 12.2 Beispiel für eine Projektplanung unter Berücksichtigung der Formen zur Einbindung
von Projektadressaten
Reichweite
Engagement
E-Mail- Diskussions - Opinion
hoch des
Groupware Newsletter forum Board Vorstands
Intranet
Mitarbeiter - Interne Vorstands-

Mailing befragung „Change besuche
Vorstands- Agents“
rede Anreiz-
systeme
Informations - Change
mittel
veranstaltung Controlling
Schwarzes
Brett Projekt-
Kick-off-Meeting
Schulung erfahrungs - Erfolge feiern
austausch
Präsentation
Workshops, Projektarbeit
in Leitungs- Einzel-
gering Klausuren im Team
meetings gespräche
deutliche Signale Anstoß zum Umdenken Verhaltensänderung

Wirkungstiefe
Legende: I K B
Abb. 12.3 Übersicht über Reichweite und Wirkungstiefe von Medien für die Formen der Einbindung
Beispiel
Aufgrund der Vielzahl an Adressaten und der enormen organisatorischen Veränderun-
gen sollen die identifizierten Adressaten unterschiedlich eingebunden werden. Geplant
ist es, frühzeitig sämtliche Mitarbeiter über die geplanten Änderungen zu informieren
und auch Kommunikationsmittel zur Verfügung zu stellen. Die Reisestelle soll früh-
zeitig im Umsetzungsprojekt eingebunden werden, da sich deren Abläufe verändern
werden. Auch die interne Abrechnung bekommt neue Aufgaben und soll daher direkt
eingebunden werden. Der Betriebsrat muss für die Softwareauswahl eingebunden
werden, soll aber auch während des Projekts fortlaufend informiert werden. Mit der
Adressatengruppe der Entlasteten soll frühzeitig in eine Kommunikation eingestiegen
werden. Insbesondere muss für den Sachbearbeiter der Reisekasse eine neue Perspek-
tive diskutiert werden.
12.4.5 Festgelegte Medien
Der gezielte Einsatz der richtigen Medien ist ein wichtiges Werkzeug bei der Einbindung
der Adressaten in die Prozesseinführung. Dabei ist jeweils das Medium auszuwählen, das
für die Adressaten zum gewählten Zeitpunkt sinnvoll ist.
Abbildung 12.3 beschreibt die Reichweite im Verhältnis zur Wirkungstiefe von

Medien, die im Zusammenspiel mit dem I-K-B-Modell (vgl. Abschn. 12.4.4) verwendet
werden können. Die Medien, die für eine bestimmte Form der Einbindung genutzt wer-
den, werden durch die dargestellten Farben/Schraffuren repräsentiert. Abbildung 12.3
erhebt keinen Anspruch auf Vollständigkeit und die Zuordnung der Medien zu den
Formen der Einbindung kann darüber hinaus auch variieren.
• Information
Um die Mitarbeiter über Prozessveränderungen zu informieren, kann bspw. ein
Mailing oder ein Newsletter genutzt werden. Die Reichweite dieser Medien ist hoch,
führt aber zu keiner merklichen Verhaltensänderung der Mitarbeiter. Folglich ist die
reine Information nicht zwangsläufig für alle Adressaten von Vorteil. Daher müssen
von Beginn an diejenigen identifiziert werden, die in die Kommunikation eingebun-
den oder sogar beteiligt werden müssen.
• Kommunikation
Als Medium zur Kommunikation über eine Prozesseinführung kann ein Diskus
sionsforum im Intranet genutzt werden. Hier können sich alle Mitarbeiter über
das Projekt und die daraus resultierenden Veränderungen austauschen. Dies
sollte idealerweise unter Moderation des Projektleiters erfolgen. Die Reichweite
eines Diskussionsforums ist hoch, da alle Mitarbeiter Zugriff zum Intranet haben,
und kann dazu beitragen, Anstöße zum Umdenken im Rahmen der zukünftigen
Prozessveränderungen zu geben.
• Beteiligung
Um die Mitarbeiter an der Prozesseinführung zu beteiligen, können Schulungen
durchgeführt werden. Dabei kann es sich bspw. um die Schulung einer später im
Prozess verwendeten IT-Anwendung handeln. Es ist aber auch möglich, die Aufgaben
der einzelnen Prozessmitarbeiter in Rollenspielen oder Prozess-Walk-Throughs zu
schulen, um dabei erste Erfahrungen zu sammeln und um die spätere Akzeptanz
gegenüber den Veränderungen zu erhöhen. Diese Medien versprechen eine gute
Wirkungstiefe, haben jedoch eine eher geringe Reichweite, da nur wenige Beteiligte
involviert werden können.
Beispiel
Um den Projektplan und die vorgesehenen Einbindungsformen zu detaillieren, hat sich
das Projektteam der Mustermann GmbH entschieden, konkrete Medien im Rahmen
des Umsetzungsprojekts festzulegen. Mit den entlasteten Mitarbeitern sollen zu Beginn
Einzelgespräche geführt werden. Anschließend sollen sämtliche Mitarbeiter im Rahmen
der Betriebsversammlung über die geplanten Strukturreformen und die Einführung des
neuen Systems informiert werden. In Workshops sollen anschließend die direkt betrof-
fenen Aufgabenträger eingebunden werden, während die IT-Abteilung laufend im Rah-
men der IT-Systemauswahl und -Einführung direkt eingebunden ist. Parallel werden die
Gespräche mit dem Betriebsrat geführt. Während der IT-Systemeinführung sollen die
Sachbearbeiter der Reisestelle und internen Abrechnung über Prozess-Walk-Throughs
und IT-Schulungen ausgebildet und in die neuen Abläufe eingeführt werden. Für die
Mitarbeiter, die später das neue System im Rahmen der Beantragung und Abrechnung
von Reisen nutzen werden, soll eine E-Learning-Plattform freigeschaltet werden.
12.4.6 Interaktion
Im Rahmen der Prozesseinführung ist es wichtig, die verschiedenen Adressaten je nach

Projektzeitpunkt und -fortschritt in dem für sie richtigen Ausmaß zu integrieren.
Die direkt Betroffenen sind im Projektverlauf intensiv zu beteiligen, da sie durch
organisatorische Änderungen, (Um-)Schulungsmaßnahmen und neue Aufgaben die
intensivsten Veränderungen erfahren. Sie sind es auch, die mit stetigem Feedback oder
Verbesserungsvorschlägen zum Erfolg der Prozessumsetzung beitragen können. Nicht
vergessen werden dürfen dabei auch die Entlasteten. Sie sind nicht mehr oder in ange-
passter Form in den Soll-Prozess eingebunden, erleben aber dennoch einen starken
Wandel. Mit ihnen muss frühzeitig im Einführungsprozess besprochen werden, welche
Rolle sie zukünftig einnehmen und welche weiteren Aussichten sich ihnen bieten. Nicht
direkt Betroffene, wie der Betriebsrat, sollten über den kompletten Projektverlauf hinweg
informiert werden. Phasenweise kann auch eine stärkere Einbindung notwendig sein,
gerade wenn die Zustimmung des Betriebsrats erforderlich ist.
Die Einbindung der Lieferanten und Kunden hängt stark vom einzuführenden
Prozess ab. Ist der Lieferant/Kunde von den Veränderungen nur indirekt betroffen,
reicht eine Information bzw. Abstimmung (Kommunikation) aus. Ist der Lieferant/
Kunde aber direkt von dem veränderten Prozess betroffen und muss ggf. auch seine
Prozesse anpassen, dann ist auch eine Beteiligung im Rahmen des Projekts notwendig.
12.5 Veränderungsmanagement
12.5.1 Veränderungsmanagement im Kontext des

Prozessmanagements
Maßgeblich für eine erfolgreiche Implementierung der Geschäftsprozesse wird die

Einbindung aller Beteiligten (Adressaten) entsprechend der jeweiligen Auswirkungen
von Veränderungen auf ihre tägliche Arbeit sein. Nachdem eine konzeptionelle und
planerische Vorbereitung weitgehend vollzogen ist, wird es nun im Rahmen des
Veränderungsmanagements um die tatsächliche und lebendige Veränderung gehen. Da
diese in ganz individuelle Bereiche jedes einzelnen Beteiligten wirkt, können allgemein
gültige Methoden auch nur grundsätzlich vorgestellt werden. Ihre optimale Wirkung
können sie erst in der Kombination im individuellen Anwendungsfall entfalten.
Veränderungsmanagement geht oft mit dem Wandel von Organisationsstrukturen ein-

her und dient als Schnittstelle und Ansprechpartner für die Beschäftigten. Gegenstand
des Veränderungsmanagements ist dabei die zielgerichtete Planung, Steuerung und
Umsetzung von komplexen Veränderungen in Organisationen. Deshalb hat das
Veränderungsmanagement vorrangig eine strukturierte und an Vorgaben orientierte
Beeinflussung der Wandlungsbereitschaft und Wandlungsfähigkeit zur Zielsetzung. Der
Erfolgsfaktor im Veränderungsmanagement ist die Arbeit mit den Menschen (vgl. Abb. 12.4).
Im Rahmen notwendiger Veränderungen sind den Beteiligten neben ihren ganz
individuellen Bedürfnissen und Befürchtungen ganz allgemein häufig folgende Aspekte
wichtig (Management School St. Gallen 2011):
• klare, glaubhafte Botschaften senden, offene Kommunikation fördern,

• den Wandel nachvollziehbar und begreifbar machen,
• Betroffene zu Beteiligten machen,
• komplexe Veränderungen in einer Organisation aktiv steuern oder
• Veränderungen systematisch und nachhaltig begleiten.
Im Rahmen des Veränderungsmanagements ist es daher wichtig, ein hohes Maß an allge-
meiner Information in sinnvoller Kombination mit individueller Kommunikation und
Beteiligung zu erreichen. Dabei umfasst das Veränderungsmanagement selbst eben diese
aktive Beeinflussung von organisatorischen Veränderungen mit verschiedenen Formen der
Information, Kommunikation und Beteiligung. Das Veränderungsmanagement beinhaltet
die Integration aller Adressaten (unmittelbar und mittelbar Beteiligte) in der jeweils geeig-
neten Form und stellt dabei eine systematische Vorgehensweise zur Unterstützung der fach-
lichen Aufgabenstellung durch methodisch untersetzte Interaktionen dar.
Im Ergebnis sind alle Adressaten mit den jeweils notwendigen Informationen ver-
sorgt und deren Rückkopplungen aus Umsetzungsschritten hinreichend berücksichtigt.
Das Veränderungsmanagement fungiert so als Vertretung der Adressaten (im Sinne
einer Interessenvertretung). Für eine Projektorganisation zur Prozessimplementierung
Abb. 12.4 Veränderungsmanagement

Veränderungsmanagement
im Kontext zu weiteren Elementen der

Prozessumsetzung
Mensch
Zeit
Technik Budget
empfiehlt sich eine Trennung zwischen Projektleitung und der Leitung des
Veränderungsmanagements (z. B. als Stabsfunktion), da nicht selten in diesen Rollen
Interessenkonflikte entstehen können.
„Wenn der Wind des Wandels weht, bauen die einen Mauern und die anderen Wind
mühlen!“ (Chinesisches Sprichwort)
Veränderungsmanagement soll im Rahmen der Prozessimplementierung das
Schaffen einer gemeinsamen Orientierung aller Beteiligten und die Identifikation
mit dem Veränderungsprozess unterstützen. Als Drehscheibe für transparente
und zielgerichtete Information und Kommunikation mit den Beteiligten beinhal-
tet es auch die Entwicklung geeigneter Beteiligungsformen für die Beschäftigten (ggf.
Initiierung übergreifender Personalentwicklung und Qualifikation; ggf. Begleitung bei
Rahmenvereinbarungen zu Personalveränderungen).
Das Veränderungsmanagement soll am Projektplan zur Prozessimplementierung
ausgerichtet werden. Dies kann mit einem Informations-, Kommunikations- und
Beteiligungskonzept (ggf. inkl. Schulungskonzept) unterstützt werden. Darin sollen fol-
gende Themen ausgeführt werden:
• regelmäßige und sachgerechte Information,

• kontinuierliche Informationsflüsse zwischen Beteiligten,
• regelmäßige Befragungen der Beschäftigten zur zielgruppengerechten Entwicklung
von zukünftigen Maßnahmen,
• Entwicklung und Umsetzung geeigneter Beteiligungsformen,
• Ausarbeitung von Gestaltungsgrundsätzen und
• Ausarbeitung von Szenarien zur Aufgabenverteilung.
Beispiel
Auch die Mustermann GmbH hat sich für die Erweiterung der Projektorganisation um
einen Veränderungsmanager entschieden. Dieser soll als Mittler zwischen Projektlei-
tung und Adressaten wirken. Konkret obliegt ihm die regelmäßige und sachgerechte
Verbreitung der Informationen des Projekts an alle Mitarbeiter und die stetige Beteili-
gung der Sachbearbeiter der Reisestelle. Darüber hinaus ist er Ansprechpartner für die
Adressaten zu Komplikationen bei der Umsetzung der Projektschritte.
Durch das Veränderungsmanagement werden während einer Projektphase die

Grundvoraussetzungen zur Förderung der organisationsübergreifenden Zusammen
arbeit für die Zeit nach dem Abschluss des Veränderungsprozesses gelegt. Der tat-
sächliche Nutzen eines guten Veränderungsmanagements tritt demnach erst nach
einem Projekt zur Prozessimplementierung ein. Anders sieht dies beim kontinu-
ierlichen Geschäfts
prozessmanagement im Sinne des PMLC aus. Im PMLC sollte
das Veränderungsmanagement ebenso als fester und kontinuierlicher Bestandteil

Berücksichtigung finden. Dies ist nicht nur für anstehende Veränderungen im
Unternehmen hilfreich, sondern auch für die Ausprägung einer offenen und integrieren-
den Unternehmenskultur nützlich.
12.5.2 Möglichkeit der Vereinfachung wiederkehrender Phasen
Während des Fortschreitens der Prozessimplementierung werden einerseits Informationen

immer detaillierter und andererseits verstärkt sich die Individualität des Informations-
und Kommunikationsbedarfs bei den Adressaten. Zielgruppen und Beteiligungsformen
(I-K-B-Modell, vgl. Abschn. 12.4.4) divergieren und die Komplexität des Veränderungsma
nagements erhöht sich kontinuierlich.
Um in diesem Kontext das Veränderungsmanagement dennoch konsequent und ziel-
orientiert umsetzen zu können, liegt die Überlegung nach einer sinnvollen Vereinfachung
nahe. Wir haben einige Implementierungsprojekte nach Gemeinsamkeiten untersucht,
auf deren Basis sich eine solche Vereinfachung methodisch ableiten lässt. Im Ergebnis
wurde ein Regelkreis entwickelt, der sich aus der immer wiederkehrenden Abfolge von
Kommunikation – Entscheidung – Information – Kontrolle zusammensetzt. Diese
Methode wurde kurz KEIK genannt (Scherber et al. 2011).
Demnach sollen bevorstehende Entscheidungen vorab hinreichend kommuni-
ziert werden, um ggf. noch Input für die Entscheidung selbst zu erhalten und vor allem
eine Beteiligung an der Entscheidung mit später zu erwartender höherer Akzeptanz zu
erreichen. Diese Kommunikationsphase darf nicht zu lange anhalten und sollte auch
nicht unbedingt mehrstufig sein. Dadurch können der Eindruck einer basisdemokrati-
schen Entscheidungsfindung und Frustration über eine ggf. abweichende Entscheidung
eingegrenzt werden. In jedem Falle sollte die Kommunikationsphase durch die zeit-
nahe Entscheidung abgeschlossen werden. Eine Entscheidung ist wichtig und gibt für
die nächsten Schritte im Rahmen der Prozessimplementierung allen Adressaten eine
Orientierung.
Nach der Entscheidung ist eine zeitnahe und umfassende Information über diese
Entscheidung und deren Hintergründe besonders wichtig. Wird über die Entscheidung
nicht umfänglich informiert, so entstehen Intransparenz und Akzeptanzverlust bis hin
zur Orientierungslosigkeit. Dies wird auch in späteren Phasen der Implementierung
zu spüren sein und nährt den Boden für Widerstände. Bei der Information über
Entscheidungen ist wiederum die Klarheit und Verständlichkeit, mit der über eine
Entscheidung informiert wird, von höchster Bedeutung. Werden Entscheidungen nicht
verstanden, eröffnet sich bei den Adressaten ein Interpretationsbedarf, der seitens der
Entscheider nicht mehr gesteuert werden kann und deshalb häufig für die Umsetzung
der Entscheidung zu Hemmnissen führt.
Nachdem über die Entscheidung hinreichend informiert wurde, sollte keine erneute
Diskussion der Entscheidung angestoßen werden! Damit würde die Entscheidung selbst
in Frage gestellt und Unsicherheit signalisiert werden. Darüber hinaus würde dies die
Aussicht eröffnen, dass die Entscheidung revidiert werden könnte. Im Anschluss an
die Information über die Entscheidung soll auch deren Umsetzung kontrolliert wer-
den. Dies wiederum ist eine grundsätzliche Voraussetzung für den Start in die nächste
Kommunikationsphase. Denn zumindest die Umsetzung der Entscheidung in Ansätzen
sollte dabei Gegenstand der Kommunikation sein, um für weitere Entscheidungen mit
vertieftem Detaillierungsgrad nun kommunikativ darauf aufsetzen zu können. Sofern
Anpassungen oder Korrekturen an bereits gefällten Entscheidungen notwendig werden,
sollte dies zu diesem Zeitpunkt mit berücksichtigt werden. Aus dem voran beschriebe-
nen Vorgehen ergibt sich ein wiederkehrender Kreislauf, wie er in Abb. 12.5 grafisch
dargestellt ist.
Der Einsatz dieser Methodik soll die zunehmende Komplexität im Veränderungs
management während eines Projekts etwas senken und den Verantwortlichen rela-
tiv einfache Orientierungshilfen liefern. Die Methodik kann auch einfach in die
Umsetzungsplanung aufgenommen und somit deren konsequente Einhaltung gesichert
werden.
Kommunizieren
Projektmanagement-
Soll-Konzept
Aufgaben
Projekt- Detail-
management konzept
Kontrollieren Entscheiden
Umsetzungs-
Medium
schritte
Informationsziele
(Reichweite, Umsetzung
Wirkungstiefe) Informieren
Abb. 12.5 Methode KEIK zur Vereinfachung der Abfolge von der Entscheidungsfindung bis zur
-umsetzung
12.5.3 Veränderungsverläufe und Reaktion der Beteiligten
Innerhalb eines Projekts zur Prozessimplementierung oder auch bei Veränderungs

prozessen allgemein treten typische Veränderungsverläufe auf. Das Modell nach Lewin
(1947) verdeutlicht die drei Phasen, die bei Veränderungen üblicherweise durchlaufen
werden (vgl. ebenso Abb. 12.6):
• Auftauen: Gegenwärtigen Zustand auftauen

– Ziel: Bereitschaft zum Wandel erzeugen
– Überzeugung der Mitarbeiter von der Notwendigkeit zur Veränderung
– Widerstände gegen den Wandel beseitigen
• Bewegen: Bewegung zum neuen Gleichgewicht
– Veränderungen vornehmen
– Neue Verhaltensweisen einüben
• Einfrieren: Einfrieren des neuen Gleichgewichts
– Ziel: Langfristige Stabilisierung der erreichten Veränderung
– Rückfall in alte Verhaltensweisen vermeiden
– Konsequente Überwachung des Ist-Zustands
Diesen Phasen können typische Reaktionen zugeordnet werden, die für die Verantwort
lichen für die Veränderungen den Umgang mit den Reaktionen vereinfachen. Die
Methoden und Medien für den Umgang mit den Reaktionen wurden in den vorherigen
Abschnitten erläutert. Zu deren Einsatz gibt es keine „Standard-Rezeptur“, er wird durch
Abb. 12.6 Modell

NEUE STRUKTUR
nach Lewin (1947)
– Phasen der
Veränderung ALTE STRUKTUR
Einfrieren Auftauen
Bewegen
Tab. 12.1 Beispiele zum Umgang mit den Phasen der Veränderung
Phasen Auftauen Bewegen Einfrieren
Was ist zu tun? • E rwartungen und • V eränderungsziele • Realisierung
Befürchtungen festlegen vereinbarter
transparent machen • Soll-Zustand erarbeiten Maßnahmen
• Überwindung von • Erarbeitung der • Kontrolle
Widerständen Soll-Prozesse durch • Nachjustierung
• Verstärkung der Prozessmodellierung • Stabilisierung des
fördernden Kräfte • Erhebung der neuen Verhaltens
• Analyse der Situation Anforderungen auf
und Definition von Basis der Prozesse
Ansatzpunkten für • Erarbeitung der
Veränderungen zukünftigen IT-
Infrastruktur
• Wissensvermittlung
• Stetige Information
über den aktuellen Stand
Methoden • Klärungsworkshops • Prozessmodellierungs- • Umsetzungsteams
• Befragung Workshops • Übergabe in
• Diagnoseworkshops • Arbeitsteams Linienverantwortung
• Feedbackrunden • Führungskreise • Training und Feedback
• Soll-Ist-Vergleiche • Soll-Ist-Vergleiche
eine gute Vorbereitung und Planung des Veränderungsmanagements erleichtert. Hierzu

gibt Tab. 12.1 einige Beispiele.
Eine weitere Darstellungsform der Phasen der Veränderung wurde durch die
Management School St. Gallen (2011) entwickelt. Dabei erfolgt eine Unterteilung der
Veränderung in fünf Phasen (vgl. Abb. 12.7). Auch in dieser Sichtweise spielen vor allem
der Umgang mit Widerständen und der Ansatz bei der Wandlung der Position von
Betroffenen zu Beteiligten eine wichtige Rolle. Aus umfangreichen Projekterfahrungen
mit Prozessimplementierungen und anderen organisatorischen Veränderungen kann fast
schon einhellig dieser Schwerpunkt als der kritische Erfolgsfaktor bezeichnet werden.
Der Umgang mit den Reaktionen der Adressaten kann dabei wieder gemäß der
Vorbereitung und Planung des Veränderungsmanagements mit den aufgeführten
Methoden und Medien erfolgen und verspricht bei kontinuierlichem und gut an die
Zielgruppen angepasstem Einsatz eine zunehmende Akzeptanz.
12.5.4 Eisbergmodell
Besonders im Kontext psychologischer oder psychosozialer Themenkomplexe ist

häufig das Eisbergmodell bekannt. Es geht auf die Erkenntnisse des Begründers der
Psychoanalyse, Sigmund Freud, zurück und beschreibt bildlich den Aufbau des persön-
lichen Bewusstseins. Demnach werden nur ca. 10–20 % unseres Verhaltens in täglichen
1 • Fehlende Information
• Nicht wahrhaben wollen
• Schock und kurzzeitige Euphorie
• Gerüchte
Betroffene
Beteiligte 2 • Schlechtes Klima, Ausklinken
• Konflikte, Kritik,
„Geht nicht“-Haltung
• „Sabotage“
• Unterstellungen, negative
Verleugnungsphase Emotionen
(1)
Stabilisierung 3 • Moment maximaler Instabilität:
(5) Das Alte loslassen,
Widerstand das Neue noch nicht da.
(2) • Einbruch der Leistung
Versuch, Irrtum und • Frustration, Depression, Mutlosigkeit
Ausprobieren • Verunsicherung, Angst
(4)
4 • Ungeordnete Aktion, Probehandeln
• Experimentieren
Tal, Krise, • Chaos, Reibungsverluste, …
Instabilität
(3) 5 • Nach vorne schauen
• Neuorientierung
• Sich wiederfinden, ordnen
• Neue Rituale und Traditionen
• Blick auf die nächste
Herausforderung
Abb. 12.7 Veränderungsverläufe und typische Reaktionen der Beteiligten verstehen (Manage-
ment School St. Gallen 2011, S. 31)
Situationen bewusst durch uns gesteuert. Freud zog mit dieser bis heute in zahlreichen
Studien bestätigten und untersetzten Erkenntnis sozusagen einen Schlussstrich unter
die bis dahin geltenden Auffassungen, die menschliches Verhalten allein auf bewusstes
Denken und rationales Handeln zurückführen wollten.
Einleitend wurde bereits auf die Bedeutung der Menschen im Rahmen des
Veränderungsmanagements verwiesen. So ist auch das Wissen um das Eisbergmodell
wichtig, um insbesondere Reaktionen auf Veränderungen (inkl. der entsprechenden
Vorgehensweise) positiv im Sinne der Gesamtzielsetzung zu verarbeiten. Bei aller Planung
und Vorbereitung der Prozessimplementierung bleibt ein wesentlicher Anteil an nicht
direkt oder bewusst zu steuernden Reaktionen auf anstehende Veränderungen bestehen.
Hier ist es oft sehr hilfreich, sich mit vorherigen Veränderungen und den daraus resultie-
renden Erfahrungen zu befassen. Sind z. B. frühere organisatorische Veränderungen posi-
tiv umgesetzt worden, so kann darauf sicherlich gut aufgebaut werden. Bei gegenteiligen
Erfahrungen kann insbesondere in einer Start-Phase der Prozessimplementierung eine
intensive Kommunikation helfen, Erfahrungen, Bedürfnisse und Befürchtungen zu erfas-
sen, die spätere unterbewusste Reaktionen auslösen können. Abbildung 12.8 verschafft
Beobachtbares
Träume Fehlleistungen
Verhalten
Bewusstes
Gedanken,
Testantworten Gefühle, Assoziationen
Wünsche
Abwehrmechanismen Auslösender
Umweltreiz
Vorbewusstes
Angst
Verdrängte Konflikte
Persönlichkeitsmerkmale
Unbewusstes
Psychosexuelle Entwicklung,
traumatische Erlebnisse
Erbanlagen,
Instinkte
Abb. 12.8 Eisbergmodell (nach Ruch und Zimbardo 1974, S. 366–367)
einen Überblick über die theoretischen Hintergründe des Eisbergmodells, wie es nach
dem Freud’schen Ur-Modell durch andere Personen weiter verfeinert wurde. (Ruch und
Zimbardo 1974)
12.5.5 Umgang mit Widerständen
Grundsätzlich kann zwischen drei Arten von Widerständen unterschieden werden:
• Rationaler Widerstand
– Bezieht sich auf logische Argumente gegen den Wandel
– Form des Widerstands, der am Einfachsten durch eine Begründung des Wandels
zu handhaben ist (Sensibilisierung!)
• Politischer Widerstand
– Entsteht durch die Angst von Mitarbeitern, aufgrund von Veränderungen im
Unternehmen an Einfluss und Macht zu verlieren
– Diese Angst entsteht z. B. beim Abbau von Hierarchieebenen im Unternehmen
• Emotionaler Widerstand
– Entwickelt sich aus mehr oder weniger konkreten Befürchtungen und Ängsten der
Mitarbeiter vor dem Wandel
– Lässt sich nicht mit logischen Argumenten erklären
– Subjektive, nicht rational erklärbare Gefühle spielen die größte Rolle
– Angst, mit den Veränderungen nicht zurechtzukommen
Nach einer Studie von Capgemini Consulting (Capgemini Deutschland 2010, S. 48 ff.)
können die Hauptgründe für mangelnde Veränderungsbereitschaft mit mangelnder
Einsicht für die Notwendigkeit, der Angst vor Entscheidungen und dem Verlust an
Einfluss zusammengefasst werden (vgl. Abb. 12.9). An eben diesen Widerständen soll-
ten deshalb die Beteiligungsformen angesetzt werden und in geeigneter Intensität und
Kontinuität dazu führen, dass eine passgenaue Einbindung der Beteiligten erreicht wird.
Für diesen Ansatz, Beteiligte mit ins Boot zu holen, gibt es einige Tipps, die nachfol-
gend aufgelistet werden:
• Eine Veränderung kann nur dann erfolgreich umgesetzt werden, wenn alle Beteiligten
„mitziehen“.
• Folgende Gruppen sollten bereits zu Beginn des Veränderungsprozesses involviert
werden:
– Personalrat,
– Betriebsrat,
– Gleichstellungsbeauftragte.
Was sind die Hauptgründe

für die mangelnde Veränderungsbereitschaft von Führungskräften?1
Antworten Häufigkeit
Mangelnde Einsicht für notwendige Veränderungen 47 %
Angst vor schwierigen Entscheidungen 45 % Primär
Verlust an Einfluss 44 %
Angst vor Statusverlust 33 %
Mangelnde eigene Flexibilität 32 % Sekundär
Fehlende eigene Kompetenzen 30 %
Frustration aus vergangenen Veränderungen 22 %
Ausgeprägter Egoismus 15 % Tertiär
Sonstiges 9%
1 Bis zu drei Nennungen
Abb. 12.9 Hauptgründe mangelnder Veränderungsbereitschaft (in Anlehnung an Capgemini

Deutschland 2010, S. 49)
• In den bilateralen Gesprächen kommt es auf eine gute Vorbereitung an:

– klare, direkte Antworten auf Fragen.
– offene Kommunikation zur Verhinderung von Unsicherheit und Ablehnung!
12.6 Prozessmarketing
Das Prozessmarketing ermöglicht es, im Rahmen der Implementierung von Prozessen

sämtliche Adressaten zu informieren und stellt insofern eine Untermenge des Veränder
ungsmanagements dar. Umgangssprachlich werden so Prozessoptimierungsprojekte
„vermarktet“. Wichtig ist: Die Einführung von veränderten Prozessen und ganzheitlich
von Prozessmanagement darf nicht „im Hinterzimmer“ geschehen.
Das Prozessmarketing ist ein wichtiger Bestandteil des Veränderungsmanagements
und beschreibt alle von außen wahrnehmbaren Aktivitäten. Dabei werden mit „außen“
alle jene Adressaten angesprochen, die nicht oder weniger an den direkten Veränderungen
beteiligt sind. Allerdings sind eben auch für diese der Fortschritt und das Verständnis von
Veränderungen wichtig, um spätestens nach Abschluss der Veränderungen mit den dann
implementierten Prozessen arbeiten zu können.
Alle Beteiligten müssen frühzeitig und fortlaufend über die Ziele, den Status und die
Erfolge informiert werden. Von den Beteiligten können gleichzeitig zahlreiche Ideen
für Informations- und Kommunikationsmittel eingeholt werden. Eine kreative Ader ist
gefragt!
Auch für das Prozessmarketing können einige der in den vorherigen Abschnitten auf-
gezeigten Medien eingesetzt werden. Medien im Rahmen des Prozessmarketings können
z. B. sein:
• E-Mail-Newsletter,
• Informationsveranstaltung,
• Vorstandsrede,
• Kreative Instrumente (Prozessmanagement-Karten, -Würfel, -Mousepads usw.),
• Schwarzes Brett,
• Mailings,
• Kick-off-Meeting,
• Ergebnispräsentation im Leitungsmeeting,
• Diskussionsforen,
• Erfolge feiern.
Für die Nutzung der Medien sind jeweils drei Fragestellungen von großer Bedeutung:
• Wer soll mit dem Medium erreicht werden? Aus dieser Fragestellung kann eine
sinnvolle Auswahl geeigneter Medien vorgenommen werden. Wichtige Kriterien
sind dabei wieder die Reichweite und die Wirkungstiefe, die bei der identifizierten
Zielgruppe erzielt werden sollen.
• Was soll mit dem Medium erreicht werden? Mit dieser Fragestellung werden
die bereits ausgewählten Medien weiter gefiltert. Dabei spielen dann stärker die
Formen der Einbindung (I-K-B-Modell, vgl. Abschn. 12.4.4) eine Rolle. Mit ihrer
Unterstützung werden Informationen, Kommunikation oder Beteiligung an oder mit
den Zielgruppen ermöglicht. Diese Formen der Einbindung sind auch für die letzte
Fragestellung relevant.
• Wie soll mit dem Medium informiert, kommuniziert oder beteiligt werden? Nach
der Auswahl stehen dann die entsprechenden Vorbereitungen für den Einsatz des
Mediums an.
Die Dokumentation des Auswahlverfahrens nach diesen drei Fragestellungen ist für die
Vorbereitung des Medieneinsatzes oft sehr hilfreich. Sie liefert bereits den Rahmen für
die vorbereitende Konzeption, z. B. von Veranstaltungen, und sichert von Anfang an den
Erfolg der Aktivitäten.
Literatur
Capgemini Deutschland (2010), Change Management Studie 2010. http://www.egovernment.ch/ffO-

Workshop_2010/Change_Management_Studie_2010.pdf. Zugegriffen: 29. Mär 2013
Fischermanns G (2010) Praxishandbuch Prozessmanagement, 9. Aufl. Dr. Götz Schmidt, Gießen
Lewin K (1947) Frontiers in Group Dynamics : Concept, Method and Reality in Social Science;
Social Equilibria and Social Change. Hum Relat 1(5):5–41.
Management School St. Gallen (2011) Strategie-, Change- & Prozessmanagement, Seminarunterlagen
(unveröffentlicht). Management School St. Gallen, St. Gallen
Office of Government Commerce (OGC) (2009) Erfolgreiche Projekte managen mit PRINCE2.
The Stationery Office Books, Norwich
Project Management Institute (PMI) (2010) A guide to the Project Management Body of
Knowledge PMBOK, 4. Aufl. Project Management Institute (PMI), Newtown Square
Ruch F-L, Zimbardo P-G (1974) Lehrbuch der Psychologie. Einführung für Studenten der
Psychologie, Medizin und Pädagogik. Springer, Berlin
Scherber M, Hirschmann C, Hagenloch E (2011) GPM-Spezialist, Seminarunterlagen (unveröf-
fentlicht). BOC Information Technologies Consulting GmbH, Berlin
Witt J, Witt T (2007) Werkzeuge des Qualitätsmanagements in der KVP-Praxis. Symposion
Publishing, Düsseldorf
Technische Umsetzung
13
Tobias Rausch, Michael Puncochar, Kai-Helmut Eckert
und Christoph Moser
Zusammenfassung
Dieses Kapitel fokussiert auf die technische Umsetzung von Prozessen durch
Informationstechnologie als Teil der Phase Prozessumsetzung des PMLC. Die
Ergebnisse der Geschäftsprozessmodellierung und -analyse bilden hierfür die Basis.
Dafür werden die Rolle und Tätigkeiten des Business- und IT-Analysten näher
betrachtet. Das Kapitel beantwortet die Frage: Wie kann es erfolgreich gelingen, die
fachlichen Anforderungen zu „übersetzen“ und den Transformationsprozess für das
Design zur technischen Umsetzung zu gestalten? Basierend auf einer Klassifikation von
IT-Anwendungen, praktischen Erfahrungen und Best Practices wird die technische
Umsetzung von Prozessen durch Einführung von Standardsoftware/ERP-Systemen,
mittels Workflow-Systemen sowie durch Entwicklung von Individualsoftware vor-
gestellt. Der Fokus liegt dabei auf den Möglichkeiten und Herausforderungen,
die bei der technischen Umsetzung bestehen sowie auf konkreten Methoden und
Vorgehensmodellen. Abschließend werden ein Vorgehen sowie Erfahrungen als Best
Practice-Fallbeispiel aus einem der größten individuellen Softwareentwicklungs-
Projekte der letzten zehn Jahre in Europa präsentiert.
T. Rausch (*) · C. Moser

e-mail: tobias.rausch@boc-group.com
M. Puncochar
BOC Unternehmensberatung GmbH, Rabensteig, 2, 1010 Wien, Österreich
K.-H. Eckert

250 T. Rausch et al.
13.1 Überblick und Zielsetzung
Dieses Kapitel fokussiert auf die technische Umsetzung von Prozessen durch
Informationstechnologie als Teil der Phase Prozessumsetzung des Process Management
Life Cycle (PMLC, vgl. Abschn. 2.4.4). Wie in Abb. 13.1 dargestellt, bilden die Ergebnisse
der Geschäftsprozessmodellierung und -analyse der PMLC-Phasen Prozessdokumentation
sowie Prozessoptimierung hierfür die Basis.
Genauso wie die Geschäftsprozesse selbst, unterliegen auch die für die Ausführung
der Prozesse erforderlichen IT-Anwendungen (Softwarelösungen) einem Lebenszyklus
(Application Management Life Cycle (van der Pols 2005; Meijer et al. 2008)). Im
Optimalfall wird der Takt für diesen Lebenszyklus vom PMLC vorgegeben, sodass
Anpassungen der zugrunde liegenden IT-Anwendungen immer durch fachliche
Erfordernisse gesteuert werden.
Geschäftsprozessanalyse
PMLC
und -modellierung
An-
forderungen
Optimierung Design
Application Management
Life Cycle
Implemen-
Betrieb tierung und
Test
Produktiv-
setzung
Abb. 13.1 Einordnung in den PMLC sowie Application Management Life Cycle (in Anlehnung
an van der Pols 2005; Meijer et al. 2008)
13 Technische Umsetzung 251
Das Kapitel richtet sich vorrangig an Prozessexperten oder Prozessverantwortliche,

Business- und IT-Analysten, IT-Programm-/Projektleiter sowie fachlich orientierte
Mitarbeiter von Prozessumsetzungs- und Anwendungsentwicklungsprojekten.
Die vorgestellten Inhalte beschreiben:
• wie Geschäftsprozesse bestmöglich mit IT (Software, Anwendungen) unterstützt wer-

den können,
• welche Möglichkeiten und Herausforderungen es bei der technischen Umsetzung gibt
und
• wie konkrete Methoden und Vorgehensmodelle dafür aussehen können.
In diesem Sinne kann dieses Kapitel auch für Programmierer/Entwickler interessant

sein, wenngleich die Inhalte und Konzepte, der gewählte Abstraktionsgrad und die
Sprache vor allem auf oben erwähnte Rollen und Zielgruppen abzielen. Abbildung 13.2
zeigt die Hauptakteure und den Fokus des Kapitels.
Während viele Kapitel in diesem Buch auf die Geschäftsprozessmodellierung und -ana-
lyse mit den Rollen des Prozessexperten und des Prozessverantwortlichen fokussieren,
Geschäftsprozessanalyse und -modellierung

Prozessexperte
Anwendungen
Business Analyst
Anforderungen
Vorgehensmodelle
Rollen
Methode C Design, IT-Spezifikation

Methode A (Best
Methode B
IT-Analyst
(z. B. Practice,
(z. B. UML)
BPMN) kunden-
spezifisch)
Programmierer
Implementierung und Test
Abb. 13.2 Motivation und Fokus des Kapitels inkl. involvierter Rollen
konzentriert sich das vorliegende Kapitel auf die Rollen und Tätigkeiten in Bezug auf die
Definition von Anforderungen sowie die weitergehende Spezifikation für das Design zur
technischen Umsetzung (vgl. Mitte der Abb. 13.2).
Folglich stehen die Rolle und die Aufgaben des Business-Analysten (European
Association of Business Process Management EABPM 2009) als „Übersetzer“ und
„Transformator“ der fachlichen Anforderungen im Mittelpunkt. Der Business-Analyst
besitzt sehr gute analytische und konzeptionelle Fähigkeiten und hat neben einem brei-
ten fachlichen Verständnis ebenso gute Kenntnisse der Anwendungslandschaft und
-logik. Somit ist er das zentrale Bindeglied zwischen den Prozessexperten im Fachbereich
und der IT/Entwicklung. Er kann mit beiden Seiten gleich gut kommunizieren und stellt
das viel zitierte Business IT Alignment sicher.
Der Begriff des Business-Analysten kommt traditionell aus dem anglo-amerikanischen
Raum. Im deutschsprachigen Raum werden diese Aufgaben oft durch Absolventen der
Wirtschaftsinformatik wahrgenommen oder auch durch Mitarbeiter des Fachbereichs,
die sich über mehrere Jahre Erfahrung und Know-how in der IT-Umsetzung erarbei-
ten konnten (z. B. durch die Mitarbeit in IT-Projekten in ihrem Bereich, durch fachli-
che Anwendungsbetreuung etc.). Je nach Projekt und Personen/Team kann die Rolle des
Business-Analysten ggf. auch personell mit der des IT-Analysten zusammenfallen oder
auch von mehreren Personen wahrgenommen werden.
Neben der zentralen Rolle des Business-Analysten spielen im Rahmen der techni-
schen Umsetzung weitere Akteure eine wichtige Rolle. Tabelle 13.1 fasst die maßgeblich
involvierten Rollen und deren Tätigkeiten zusammen.
Tab. 13.1 Rollen und deren Tätigkeiten im Rahmen der technischen Umsetzung
Rolle Tätigkeiten
Prozessexperte (Fachbereich) • Definiert fachliche Anforderungen und beauftragt deren
Spezifikation und Umsetzung
• Nimmt die realisierten Anforderungen am Ende der
Umsetzung ab
Business-Analyst („Übersetzer“) • Versteht die fachlichen Anforderungen und erstellt die
detaillierte Spezifikation
• Steht für Detailfragen zur Spezifikation im gesamten
Prozess zur Verfügung
IT-Analyst • Nimmt Anforderungen entgegen, gibt Feedback aus
technischer/IT-Sicht
• Erstellt das Software-Design
• Schätzt Umsetzungsmöglichkeiten (Machbarkeit),
Abhängigkeiten zu anderen Anwendungen/Bereichen
sowie Aufwände
Programmierer/Entwickler • Technisches Design der Software
• Implementiert die Anforderungen
13.2 Einführung/Implementierung von (neuen)

IT-Anwendungen
Die Implementierung und Einführung neuer IT-Anwendungen ist in der Regel eine
große Herausforderung für Unternehmen, wobei diese Herausforderung mit zuneh-
mender Unternehmensgröße und Anzahl der Einsatzgebiete der Anwendung steigt
– im Extremfall bis zur kompletten Neuentwicklung und dem Austausch der gesamten
System- und Anwendungslandschaft. Damit derartige Vorhaben gelingen können und
nicht von vornherein zum Scheitern verurteilt sind, müssen nicht nur die fachlichen
Abläufe und Anforderungen dokumentiert und bekannt sein, sondern auch in detail-
lierte Vorgaben für das Design und die Implementierung überführt werden.
Bevor die (Neu-)Implementierung bzw. Einführung von IT-Anwendungen näher
beschrieben wird, nehmen wir im folgenden Unterabschnitt eine Klassifikation von IT-
Anwendungen vor, um dann in Folge auf Vorgehensmodelle und Methoden einzugehen,
wie IT-Anwendungen auf Basis von fachlichen Analysen und Prozessen technisch umge-
setzt werden können.
13.2.1 Klassifikation von IT-Anwendungen
Software erlaubt es Anwendern, mit Computern (bzw. allgemeiner Hardware) zu inter-

agieren und diese für ihre Zwecke nutzbar zu machen. Software kann nach verschiedenen
Kriterien unterschieden werden (vgl. Abb. 13.3). In Bezug zu ihrer Nähe zum Anwender
Standardsoftware/
Systemsoftware
ERP-Systeme
Software
WF-Systeme/-Engines,
Anwendungssoftware modifizierte
Standardsoftware
Individualsoftware
Abb. 13.3 Klassifikation von Software bzw. IT-Anwendungen (in Anlehnung an Diehl 2000;
zitiert aus Vaher 2003/2004)
wird sie oft in Systemsoftware und Anwendungssoftware unterschieden (Hansen und

Neumann 2009, S. 34 ff.). Es ist anzumerken, dass diese Grenze nicht immer scharf
gezogen werden kann, zum Beispiel bei Programmbibliotheken, einigen Middleware-
Komponenten oder auch Web-Browsern.
Dieses Kapitel hat die Gruppe der Anwendungssoftware (IT-Anwendung oder oft auch
einfach nur Anwendung oder Applikation genannt) im Fokus, d. h. jene Software, die mit
dem Ziel entwickelt wurde, Anwender bei der Bearbeitung und Lösung von Aufgaben und
Problemstellungen zu unterstützen, um dadurch direkten Nutzen zu schaffen. Hierfür
gibt es mannigfaltige Einsatzmöglichkeiten, wie zum Beispiel Marketing, Sales, Logistik,
Buchhaltung und Controlling, Personalmanagement etc.
IT-Anwendungen können zudem weiter unterteilt werden. Eine gängige Klassifizierung
unterscheidet zwischen Standard- und Individualsoftware (Hansen und Neumann 2009,
S. 259 f.). Standardsoftware – oft als Enterprise Ressource Planning- oder auch ERP-System
bezeichnet – kann zudem noch weiter unterschieden werden, je nachdem, ob es sich um
Branchenlösungen, Anwendungen für bestimmte (Unternehmens-)Bereiche oder funkti-
onsübergreifende Lösungen handelt. In der Praxis hat sich gezeigt, dass zwischen den bei-
den Extremen Standard- und Individualsoftware oft ein dritter Weg gegangen wird, in dem
Sinne, dass Standardsoftware stark modifiziert wird und/oder Workflow-Systeme sowie
Prozess-Engines zur Integration und Bereitstellung von Anwendungen und Systemen ver-
wendet werden.
Im Folgenden werden Methoden und Vorgehensmodelle für die technische Umsetzung
bei der Neuentwicklung von Anwendungen vorgestellt. Im Detail erfolgt dies anhand eines
konkreten Projektbeispiels zum Thema Individualsoftware (vgl. Abschn. 13.2.4) und der
Erläuterung von praxiserprobten Best Practice-Vorgehensmodellen für deren Spezifikation
und Entwicklung (vgl. Abschn. 13.3).
Nichtsdestoweniger sei erwähnt, dass insbesondere die in Abschn. 13.3 vorgestellte
Methode auch analog für die beiden anderen Kategorien anwendbar ist. Dahingegen
sind Vorgehensmodelle für die Spezifikation, Umsetzung und Einführung bei der
Neuentwicklung von Anwendungen oft projektspezifisch bzw. abhängig von den gewähl-
ten Zielen, der gewählten Anwendungs- und Softwarearchitektur und dem unterneh-
mensintern vorhandenen Know-how.
Da im Vergleich zum Thema Individualsoftware die Themen Standardsoftware sowie
Workflow-Systeme/Prozess-Engines in der einschlägigen Literatur weitreichend behan-
delt werden, gehen wir in den folgenden beiden Abschnitten für diese beiden nur im
Überblick auf wichtige, zu beachtende Punkte ein.
13.2.2 Einführung von Standardsoftware/ERP-Systemen
Bei der Einführung von Standardsoftware ist es ein entscheidendes Kriterium, inwieweit
der Umfang und Inhalt der Software des gewählten Anbieters als gegeben hingenommen
und akzeptiert wird bzw. wie groß die Notwendigkeit und der Wille zu Modifikationen
der Standardsoftware sind. Dies geschieht in der Regel durch sogenanntes Customizing
der Standardsoftware, was bei größeren Modifikationen einer Neuprogrammierung der
betroffenen Teile entspricht und entsprechende Aufwands- und vor allem Pflegepro
blematiken nach sich zieht.
Bei der Einführung von Standardsoftware, insbesondere wenn es sich um Unter
nehmenssysteme wie SAP®, Oracle® etc. handelt, ist zu beachten, dass die fachli-
che Modellierung im Hinblick auf die Granularität in der Regel nicht direkt auf
die Transaktionen/Funktionen des gewählten Systems abgebildet werden kann.
Standardsoftware wird heutzutage als prozessbasierte Software platziert, für die Hersteller
(bzw. Berater) Prozess-Templates zur Einführung anbieten. Diese sind jedoch in der
Regel eine Ansammlung von eher technischen Transaktionen/Funktionen und haben so
nur indirekten Bezug zum fachlichen Prozess. Zudem kennt der fachliche Prozess auch
rein manuelle Aktivitäten, die im System keine Entsprechung finden.
Zwischen fachlichen Geschäftsprozessen und ERP-Systemen treten somit folgende
Beziehungen auf:
• Eine fachliche Aktivität entspricht genau einem ERP-Prozessschritt oder

• eine fachliche Aktivität wird durch mehrere ERP-Prozessschritte abgebildet oder
Analyse und Design Prozessumsetzung

(z. B. im Prozessmanagement-Werkzeug (z. B. im SAP ® Solution Manager)
ADONIS®)
Bidirektionaler
Austausch
© Copyright 2013. SAP AG.

Alle Rechte vorbehalten.
Geschäftsprozesse
Fachliche Sicht „Integrationssicht“
Entscheidungen, Technische Prozesse ERP-Szenarien
Schleifen, Aktivitäten ERP-Transaktionen
ohne ERP-Support
Abb. 13.4 Zusammenführung von Geschäftsprozessen und ERP-Szenarien

• mehrere fachliche Aktivitäten werden durch einen ERP-Prozessschritt abgebildet oder

• eine fachliche Aktivität hat keine Entsprechung im ERP-System, da z. B. die Aktivität
manuell ist oder ggf. nicht durch das ERP-System unterstützt wird.
Um diese vielfältigen Beziehungen mit all ihren Konsequenzen berücksichtigen zu kön-

nen, ist es notwendig, die Geschäftsprozesse als fachliche Sicht mit der technischen Sicht
des ERP-Systems zu integrieren. Abbildung 13.4 veranschaulicht diese Verknüpfung der
Geschäftsprozesse mit den ERP-Szenarien über die technischen Prozesse, die als soge-
nannte Integrationssicht betrachtet werden können.
Fachliche Geschäftsprozesse lassen sich normalerweise nicht 1:1 auf Prozesse in
(ERP-)Systemen abbilden. Daher muss es in der Modellierung eine Trennung zwi-
schen der Geschäftsprozesssicht und einer (ERP-)Systemprozesssicht geben, wie auch
Abb. 13.4 zeigt. Diese Erkenntnis (Trennung fachliche und technische Prozesssicht)
lässt sich ebenso auf die anderen Softwaretypen anwenden (vgl. Abb. 13.5 für Workflow-
Systeme/Prozess-Engines sowie Abb. 13.6 für Individualsoftware).
13.2.3 Technische Umsetzung von Prozessen mittels Workflow-

Systemen und Prozess-Engines
Neben Standard- und Individualsoftware steht am Markt ein vielfältiges Angebot

an Prozessausführungs-Umgebungen zur Verfügung. Diese werden oft auch als
Workflow-Systeme, Prozess-Engines oder BPM-Suites bezeichnet und beinhalten
Workflow-Steuerung, Prozessmonitoring, Prozesscontrolling, Eskalationsmanagement,
Regelsysteme etc. Beispiele hierfür sind sowohl Systeme großer Hersteller (z. B. IBM®,
Oracle® und Tibco®) als auch Open Source BPM-Suites (z. B. activeBPEL™, Activiti™,
Bonita Open Solution, JBoss®).
Um Prozesse möglichst optimal durch IT zu unterstützen, sollten die eingesetz-
ten Anwendungen eine Prozesslogik beinhalten oder über eine externe Prozesslogik-
Einheit, d. h. ein Workflow-System bzw. eine BPM-Suite, angesteuert werden. Dies ist
wichtig, da in der Regel mehrere Anwendungen zur Unterstützung eines Prozesses im
Einsatz sind und Mitarbeiter für gewöhnlich auch in mehr als einem Prozess invol-
viert sind. Eine Integration der Anwendungen und Verteilung der Aufgaben an die
zuständigen Mitarbeiter kann somit durch das Workflow-System bzw. die BPM-Suite
erfolgen.
Zur Gestaltung der technisch ausführbaren Prozesse (Workflows) unterscheidet man
typischerweise drei Ebenen (Karagiannis 1995; Junginger et al. 2000; Truyen 2006; BOC
2007; Petzmann et al. 2007), wie in Abb. 13.5 dargestellt:
1. den Business Graphen (Computation Independent Model = CIM nach MDA®),

2. den Workflow Graphen (Platform Independent Model = PIM) und
3. den Execution Graphen (Platform Specific Model = PSM).
Business Graph = CIM

(Geschäftsprozess-
Modellierungssprache,
z.B. BPMS, EPK)
Workflow Graph = PIM

(erweiterte Geschäftsprozess-
Modellierungssprache, + +
z. B. BPMN)
Ausführungs-
modell
Execution Graph = PSM
(Sprache des BPMS, ggf.
herstellerspezifisches BPEL)
Legacy-System, Referenzmodelle
UML-Modelle
keine Modellierung (Standardsoftware)
Abb. 13.5 Trennung von Business, Workflow und Execution Graph (Junginger et al. 2000, S. 199)
Die Einbindung von Anwendungen oder Anwendungsfunktionen in den Prozess

erfolgt heutzutage in der Regel durch den Aufruf von Services. Das Konzept der service-
orientierten Architekturen (SOA) unterstützt die Workflow-Modellierung hierbei gut
(BOC 2006). Im Rahmen der Erstellung des Workflow-Graphen kann überlegt werden,
welche zusätzliche IT-Unterstützung (in Form weiterer Services) benötigt wird und wo
ggf. bereits existierende Services im Workflow genutzt werden können.
Neben dem Aspekt des Workflow sind im Bereich von Prozessausführungs-Umgebungen
die Business Rules-Systeme von großer Bedeutung, da Geschäftsregeln maßgeblich den
Workflow-Ablauf beeinflussen. Je größer der Anteil an Geschäftsregeln, desto kleiner ist
die Notwendigkeit, Regeln im Code zu implementieren, was den Aufwand bei Änderungen
massiv verkleinern kann und generell eine größere Flexibilität verleiht.
Im Umfeld der Prozessausführung durch sogenannte Prozess-Engines haben sich im
Laufe der letzten zehn bis 15 Jahre einige Standards entwickelt. Diese Standards wurden in der
Regel bottom-up durch Hersteller verschiedener Systeme vorangetrieben und fokussieren pri-
mär auf die Prozessausführung und die dafür notwendigen technischen Informationen, wie
Systemumgebung, Daten-Mapping, Details zum Aufruf des Webservice/der Applikation etc.
Die heutzutage aktuell bekanntesten Standards sind XPDL (XML Process Definition
Language) (Workflow Management Coalition (WfMC) 2013), BPEL (Business Process
Execution Language) (Organization for the Advancement of Structured Information
Standards (OASIS) 2007) sowie BPMN DI (BPMN Diagram Interchange) (Object
Management Group (OMG) 2011a, S. 367 ff.). BPMN DI ist hierbei die Serialisierung
von BPMN 2.0 und wird durch die Object Management Group (OMG) gewartet. Zu
beachten ist, dass all diese Formate jeweils einen standardisierten Kern definieren, der in
der Regel durch die Anbieter von Ausführungsumgebungen durch sogenannte „vendor-
specific enhancements“ erweitert werden kann.
Abschließend kann festgehalten werden, dass durch die Vielfalt an Technologien,

deren Einsatzmöglichkeiten sowie stark variierenden Integrationsnotwendigkeiten
eine allgemein gültige Vorgehensweise im Sinne eines „Kochrezepts“ bei der Nutzung,
Implementierung und Einführung von Workflow-Systemen und Prozess-Engines kaum
möglich ist.
13.2.4 Technische Umsetzung von Prozessen mit

Individualsoftware
Wie der Name bereits nahelegt, wird hierbei Software individuell entwickelt und auf
die individuellen Bedürfnisse des Anwenders/Unternehmens im Detail eingegan-
gen, d. h. das Ergebnis ist im Alltag durchaus vergleichbar mit einer Maßanfertigung.
Maßanfertigungen von Produkten, wie zum Beispiel Schuhen oder Anzügen, sind
in Bezug auf ihre Individualität durchaus vergleichbar. Allerdings ist dabei in der
Regel das Zielprodukt bereits deutlich definiert (bekannt), wodurch die Möglichkeit
Maß zu nehmen (also die Spezifikation zu erstellen), erheblich besser gegeben ist. Bei
Individualsoftware hingegen ist das Zielbild oft nur teilweise vorhanden, Architektur-
Entscheidungen sind noch zu treffen und das Vorgehen zur Erstellung der Spezifikation
ist nicht vorgegeben. Einzelne Parameter können sich sogar noch im Laufe des Projekts
ändern.
Oft handelt es sich hierbei um Lösungen, die nur von einem Unternehmen eingesetzt
werden. Andererseits besteht auch die Möglichkeit, eine Software, die ursprünglich als
Individualsoftware entwickelt worden ist, in weiterer Folge zu einer Branchenlösung und
damit de-facto zu einer Standardsoftware weiter zu entwickeln.
Zur Erstellung einer maßgeschneiderten Software ist es essenziell, die fachlichen
Anforderungen detailliert zu kennen, wie auch die Rahmenbedingungen und nicht-
funktionalen Anforderungen (wie z. B. Antwortzeiten, Offline-Nutzung) in einem
Pflichtenheft vorab zu spezifizieren.
Hierbei ist zu beachten, dass das Zielbild und die entsprechenden Zielvorgaben (tech-
nisch wie inhaltlich) in frühen Stadien oft nicht ausreichend bekannt sind bzw. sich
im Laufe der Zeit ändern können. Zudem kann im Unterschied zu Standardsoftware
kein vorhandenes Zielsystem als Referenzpunkt genommen werden, sondern die
Anforderungen sind als Soll-System von Grund auf zu beschreiben. Inwieweit eine
Ist-Analyse (und Ist-Prozessaufnahme) hierfür hilfreich ist, ist im Einzelfall zu ent-
scheiden. Dies hängt v. a. auch von der Zielsetzung der Neuentwicklung ab: Je revolu-
tionärer die geplanten Änderungen in Bezug auf die Arbeitsabläufe, Organisation und
IT-Anwendungen sind, umso weniger Relevanz und Vorteile hat eine Ist-Analyse.
Im Folgenden werden Methoden zur Erfassung der fachlichen Anforderungen im
Rahmen einer prozessbasierten IT-Spezifikation dargestellt, wobei die Autoren hier-
bei auf ihre Erfahrungen aus großen Softwareentwicklungsprojekten zurückgrei-
fen. Anforderungen an IT-Systeme werden aus geschäftlichen Zielen, Prozessen und
Erwartungen abgeleitet, analysiert und sukzessive verfeinert. Bei großen Systemen entsteht
dabei eine Komplexität, die nur methodisch und werkzeuggestützt zu beherrschen ist.
Stellt man die Anforderungen in den Mittelpunkt, werden diese, wie in Abb. 13.6
dargestellt, aus den fachlichen Prozessmodellen, Anwendungsfallbeschreibungen und
GUI-Entwürfen (engl. Graphical User Interface; dt. grafische Benutzeroberfläche) im
Rahmen des Anforderungsmanagements abgeleitet und dokumentiert (vgl. Nr. 1 in
Abb. 13.6).
Hierzu zählen auch die Vorgaben, die sich aus der Softwarearchitektur selbst ergeben
(BOC 2007). Auf Basis der Anforderungen werden dann:
• die technischen Geschäftsprozessmodelle abgeleitet (vgl. Nr. 2 in Abb. 13.6),

• die Testfälle abgeleitet (vgl. Nr. 3 in Abb. 13.6) und
• das Design der Anwendungskomponenten erstellt (vgl. Nr. 4 in Abb. 13.6).
Diese Artefakte bilden auch das Gerüst für eine Methode zur Entwicklung von Individual
software, die im nächsten Abschnitt anhand eines Best Practice-Projektbeispiels im Detail
vorgestellt wird.
Facharchitektur Softwarearchitektur
Fachliche Technische
Prozessmodelle Anforderungen
1
Anwendungsfall- Anforderungen 1
beschreibungen 1
4 Entwurf der Komponenten

1
und technischen Services
GUI-Entwürfe
2
3
Technische
Geschäftsprozessmodelle
Workflow- und
Testfälle
Datenmodelle
Abb. 13.6 Wesentliche Artefakte der Anforderungsspezifikation

13.3 Entwicklung von Individualsoftware anhand eines Best

Practice-Projekts
Im Folgenden werden Konzepte, Vorgehen und Erfahrungen aus einem der größ-
ten individuellen Softwareentwicklungsprojekte der letzten zehn Jahre in Europa als
Best Practice-Fallbeispiel präsentiert. Für das ausgewählte Projekt haben sich Ende der
1990er-Jahre neun unabhängige Sozialversicherungsträger mit dem Ziel einer komplet-
ten Neuentwicklung ihrer gesamten IT-Anwendungen zusammengeschlossen. Diese
sollten auf Basis vereinheitlichter Prozessabläufe und basierend auf der damals noch
recht neuen Java- und der noch jungen, aber schon den Kinderschuhen entwachsenen
Workflow-Technologie entstehen.
Hierbei entstand eine Best Practice-Spezifikationsmethode, die im Folgenden näher
beschrieben wird. Grundsätzliche Überlegungen zum Vorgehen und insbesondere zur
Identifikation von Anwendungsfällen für die Workflow-Steuerung finden sich auch in
Herzog (1998).
13.3.1 Spezifikationsmethode und Vorgehensmodell
Die Spezifikationsmethode im dargestellten Projekt unterscheidet grundsätzlich zwei

Phasen im methodischen Vorgehen:
1. Die Phase Geschäftsprozessmodellierung dient den Mitarbeitern der Sozialversiche

rungsträger dazu, die zukünftige gemeinsame Arbeitsweise aus fachlicher Sicht
festzulegen. Sie endet damit, dass die fachliche Beschreibung der zukünftig verein-
heitlichten Geschäftsprozesse von einem an der Geschäftsprozessmodellierung nicht
beteiligten Fachmitarbeiter nachvollzogen und verstanden werden kann.
2. An die Geschäftsprozessmodellierung schließt sich die Phase der Anforderungsanalyse
an. Während der Anforderungsanalyse wird festgelegt, wie die zu entwickelnde Software
den zuvor fachlich abgestimmten Geschäftsprozess unterstützen soll. Im Ergebnis der
Phase ist definiert, wie der Bearbeiter mit der neu zu erstellenden oder weiter zu ent-
wickelnden Software arbeitet, um die im Geschäftsprozess definierten Aufgaben zu
erledigen. Die Phase ist abgeschlossen, wenn die Anforderungen an die Software als
Spezifikation für die nachfolgende Entwicklung sowie den Test und die Abnahme ein-
deutig, widerspruchsfrei, vollständig, umsetzbar und testfähig beschrieben sind.
13.3.1.1 Geschäftsprozessmodellierung
In der Geschäftsprozessmodellierung werden ausgehend von den in der Prozesslandkarte
identifizierten Prozessen die fachlichen Abläufe beschrieben. Ein besonderes Merkmal
in der gewählten (EPK-nahen) Methodik liegt in der konsequenten Modellierung von
Ereignissen, die nicht nur als Ausgangs- und Endzustände der Prozesse dienen, sondern
auch die fachlichen Zustände im Laufe des Prozesses beschreiben und somit für die
zweite Phase der Anforderungsdefinition Input für Transaktionsgrenzen liefern. Hierbei
hat sich gezeigt, dass es zielführend ist, die Aktivitäten und Ereignisse für das gemein-
same Verständnis der zukünftigen Arbeitsweise und als Input für die nachfolgende Phase
sehr detailliert zu beschreiben (vgl. Detaillierungsebene 3 in Abschn. 5.3.1).
Zu beachten gilt es jedoch, dass durch die Geschäftsprozessmodelle keine Details der
Informationsverarbeitung oder konkrete Anforderungen (z. B. die Interaktion zwischen
Benutzer und System oder die Gestaltung der Benutzeroberfläche) beschrieben werden
(Phase der Prozessdokumentation). Sie definieren und dokumentieren somit noch nicht
die funktionalen Anforderungen an das System, sondern bilden vielmehr die Grundlage
für deren Erarbeitung in der nachfolgenden Anforderungsspezifikation.
Als erster Schritt zur Anforderungsspezifikation werden zentrale Objekte („Dinge“),
die der Prozess benötigt bzw. verarbeitet, durch Benennung und Formalisierung in Form
von Domänenobjektmodellen (DOM) abgebildet.
Das DOM kann als fachliches Klassenmodell gesehen werden und ist eine wich-
tige Verbindung zum Geschäftsobjektmodell (GOM), das von der Entwicklung erstellt
und gepflegt wird. Die im Domänenobjektmodell modellierten Zusammenhänge
sind Kandidaten für Klassen und Beziehungen im GOM und damit Grundlage für das
Datenmodell der zugrunde liegenden Datenbank.
Der Übergang zur Phase der Anforderungsanalyse ist dabei durchaus fließend bzw. die
Erstellung des DOM kann auch der erste Schritt darin sein. Im vorgestellten Projekt wurde
mit dem DOM im Laufe der Geschäftsprozessmodellierung begonnen. Jedoch ist es wichtig
zu erwähnen, dass dieses im Laufe der Projektzeit immer weiter verfeinert und mit zuneh-
mender Implementierungstätigkeit mehr und mehr durch die Technik geprägt wurde.
13.3.1.2 Anforderungsanalyse
In der Anforderungsanalyse und -spezifikation entstehen die detaillierten Vorgaben für
die Entwicklung der Individualsoftware. Im Vordergrund stehen hierbei insbesondere
Informationen und Vorgaben zu:
• der grafischen Benutzeroberfläche,

• den Möglichkeiten des Benutzers zur Interaktion mit der Software,
• Geschäftsregeln: Berechnungen wie auch ablaufsteuernde Regeln (z. B. für Berechti
gungen etc.),
• Prüfungen (Plausibilisierungen), die das System vornimmt,
• automatischen Systemschritten oder gar vollautomatischen Prozessen (Batch-
Prozesse),
• Transaktionsgrenzen (Speicherpunkte bzw. Punkte zum Wiederaufsetzen) und
• der Workflow-Steuerung (Ablauflogik sowie zu steuernde Programmteile).
Abbildung 13.7 zeigt die beiden Phasen und die darin maßgeblichen Artefakte für die
Spezifikation.
Prozesslandkarte
1 Geschäftsprozessmodell
Anwendungsfall
Vorgang 1 Vorgang 2
ENDE
2 Interaktionsmodell 4 Weitere Elemente der

Systemspezifikation
Verteilregeln
Kompetenzen
Plausibilitäten/Regeln
Meldungen
Grunddaten
Formularelemente/
Dokumententypen
Klassendefinition
Domänenobjektmodell
5 Vorgangsfenster - 3 Vorgangsfenster - Verweise möglich auf:

Folge Modell
• Plausibilitäten/Regeln
• Meldungen
• Grunddaten
• Eigenschaften von
Klassen
• Methoden von
Klassen
Abb. 13.7 Überblick über die Methode zur prozessbasierten Anwendungsspezifikation

Wie man erkennt, ist das Geschäftsprozessmodell (vgl. Nr. 1 in Abb. 13.7) hier-
bei das Bindeglied zur detaillierten Anforderungsanalyse. Insbesondere dient es als
direkter Ausgangspunkt für die Spezifikation der Transaktionsgrenzen und Workflow-
Steuerungseinheiten auf Basis des folgenden Vorgehens:
• Aus dem vorliegenden Geschäftsprozess werden zuerst die Transaktionsgrenzen

bestimmt und so der Prozess in mehrere Teile geschnitten. Dies geschieht durch grafi-
sches Gruppieren, wie auch in Abb. 13.7 schematisch dargestellt. Die fachlich identifi-
zierten Zustände (Ereignisse) bieten hierbei Hilfestellung.
• Die so entstehenden Teile werden in der Ziel-Architektur als Vorgänge bezeichnet
und stellen somit die Transaktionssicht dar. In einem nachfolgenden Schritt werden
die Vorgänge zu Anwendungsfällen (Sicht der Vorgangssteuerung) zusammengefasst
(ebenfalls noch im Geschäftsprozess, vgl. Nr. 1 in Abb. 13.7).
• Für das Schneiden der Anwendungsfälle ist insbesondere auf Rollenwechsel bei der
Durchführung der einzelnen Aktivitäten zu achten: Wechselt die Rolle, so liegt auch
ein neuer Anwendungsfall vor (Herzog 1998). Ein Vorgang muss immer genau einem
Anwendungsfall zugeordnet sein, d. h. ein Vorgang darf nicht über die Grenzen eines
Anwendungsfalls hinausgehen.
Die Vorgangsgrenzen markieren somit die Bereiche eines Geschäftsprozesses, innerhalb

derer das System folgendes Verhalten garantiert:
• Bei einem Abbruch des Vorgangs vor dessen regulärer Beendigung werden alle bis
dahin eingegebenen Daten nicht in die Datenbank geschrieben. Das System hat genau
den Zustand wie vor dem Start des Vorgangs.
• Bei regulärer Beendigung des Vorgangs werden alle eingegebenen Daten unwiderruf-
lich in die Datenbank geschrieben.
Die beiden wesentlichen weiteren Elemente der Spezifikation sind die detaillierte
Beschreibung der Benutzer- und Systeminteraktion (vgl. Nr. 2 in Abb. 13.7) sowie die
Definition der grafischen Benutzeroberfläche (vgl. Nr. 3 in Abb. 13.7).
Die detaillierte Beschreibung der Benutzer- und Systeminteraktion wird in sogenann-
ten Interaktionsmodellen vorgenommen (vgl. in Analogie auch die Interaktionsdiagramme
der UML 2.0 (Object Management Group (OMG) 2011b)). Hierbei gilt es, für
jede im Prozess identifizierte fachliche und nicht zu 100 % manuelle Aktivität, ein
Interaktionsmodell zu erstellen und darin Schritt für Schritt zu erläutern, welche Aktionen
das System bzw. der Benutzer durchführt. Rein manuelle Aktivitäten werden ausschließ-
lich im Geschäftsprozessmodell beschrieben. Somit wird einerseits sichtbar, wie das
System auf Benutzerinteraktionen reagieren soll, und andererseits erkennt man, welche
Möglichkeiten der Benutzer zur Interaktion vorfindet. Die grafische Modellierung ähnelt
hierbei der Logik eines Prozessablaufs, wodurch nicht nur mögliche Entscheidungen
(z. B. nach Systemprüfschritten) sowie Schleifen explizit dargestellt werden können,
sondern auch auf Elemente zurückgegriffen wird, die Modellierern und Lesern aus der
Geschäftsprozessmodellierung vertraut sind.
Abbildung 13.8 zeigt ein Beispiel für eine Interaktionssequenz für die fachliche
Aktivität „Partner anlegen“.
Ein weiterer Vorteil dieser Methode liegt darin, dass sie ebenso für vollautomatische
Prozesse bzw. Teilprozesse eingesetzt werden kann.
Wichtige Bestandteile der so beschriebenen Interaktionsschritte sind insbesondere auf
Systemseite sogenannte Regeln und Plausibilitäten. Regeln, welche in der Literatur oft auch
als Geschäftsregeln (Business Rules) bezeichnet werden, beschreiben hierbei die Art der
Partner anlegen
Maske initialisieren und

Informationen aus
Partnersuche übernehmen
Partnerstammdaten
eingeben
Meldungen:
Partnerstammdaten LW MF AL 10061 Fehlgeschlagene
überprüfen Pflichtfelder Prüfungen ausgeben
nicht erfüllt 1.00
LW PL AL 10094
Partnerstammdaten
Systemprüfungen 0.01
XOR
Partnerstammdatenüberprüfung
fehlgeschlagen
Partnerstammdaten OK
Maske für Verifikation

Partnerdaten aufbereiten
Abb. 13.8 Beispiel für eine Interaktionsbeschreibung (grafischer Interaktionsablauf)

Verarbeitung nach dem Schema „Wenn-Dann-Sonst“, wohingegen Plausibilitäten zur

Sicherstellung fachlich konsistenter Daten dienen und nicht unbedingt dem Schema einer
Regel entsprechen müssen.
Beispiele für Regeln und Plausibilitäten:
• Regel
– Berechnungsregeln für Zinsfüße
– Ablaufregel zur GUI-Steuerung: „Wenn Option <Optionsname> aktiviert, dann
werden folgende Buttons deaktiviert: <Buttonaufzählung>“
– Regeln zur Identifikation potenzieller postalischer Adressdubletten
• Plausibilität
– Ein Datum muss größer als das Tagesdatum sein (Datum > Tagesdatum), ansons-
ten erscheint eine Fehlermeldung.
– Wird das Betragsfeld <Feldname> befüllt, darf das Datum <Feldname> nicht ein-
getragen werden. Wird das Betragsfeld nach dem Datum befüllt, erfolgt die Info-
Meldung „Datum <Feldname> wird entfernt“.
Eine Plausibilität führt zudem immer zur Ausgabe von Meldungen an den Benutzer.
Solche Systemmeldungen stellen einen weiteren Bestandteil der Spezifikationsmethodik
dar.
Regeln, Plausibilitäten und Systemmeldungen sind Elemente, die sich auch direkt
in der Systemarchitektur wiederfinden und insbesondere auch in verschiedensten
Geschäftsprozessen bzw. Interaktionen wiederverwendet werden können (vgl. Nr. 4 in
Abb. 13.7).
Weitere Elemente mit analogen methodischen Eigenschaften, die ebenso Teil der
Spezifikation der Anwendung bilden, sind:
• Grunddaten
Diese werden zentral verwaltet (zum Beispiel Mehrwertsteuersätze) und können so
bei Bedarf leicht geändert werden (Systemparameter).
• Formularelemente/Dokumenttypen
Sie dienen der Beschreibung von benötigten Formularen und Dokumenten (für Scan
und Druck).
• Verteilregeln
Diese beschreiben Regeln für die Verteilung der Aufgaben (engl. Work Items) im
Workflow.
• Kompetenzen
Sie definieren Kompetenzen zur Durchführung.
Für die Definition der grafischen Benutzeroberfläche ist es empfehlenswert, mit einer
Übersicht der Abfolge der Vorgangsfenster eines Anwendungsfalls bzw. Prozesses zu
beginnen (vgl. Nr. 5 in Abb. 13.7). Hier kann im ersten Schritt der grobe Ablauf der
einzelnen Vorgänge modelliert werden, der bereits aus der fachlichen Modellierung
bekannt sein sollte. In der technischen Beschreibung der Vorgangsfensterfolge wird
die Funktionsweise der grafischen Oberfläche beschrieben, welche Voraussetzungen
(Plausibilitäten, Regeln etc.) erfüllt sein müssen und wie der technische Ablauf aussieht.
Welche Fenster schlussendlich im konkreten Fall aufgerufen werden, hängt von den
Entscheidungen des Benutzers im Kontext der jeweiligen fachlichen Fallbearbeitung ab.
Nun ist für jedes Vorgangsfenster (Maske) die grafische Benutzeroberfläche im
Detail zu beschreiben. Für die Spezifikation dieser GUI-Details stehen gängige Konzepte
für Oberflächenelemente, wie Formulare, Dialoge, Gruppen, Panels, Registerkarten
(-sets), Split Panels, Menüs, Kontextmenüs, Treelist-Bäume etc. zur Verfügung. Auf
den Oberflächenelementen können nun Felder unterschiedlichen Typs sowie zur Ein-
oder Ausgabe von Daten oder Schaltflächen definiert werden. Zudem wird auch bei
der Definition der Oberfläche wiederum auf Regeln, Plausibilitäten, Grunddaten sowie
Meldungen zurückgegriffen, zum Beispiel um Wertebereiche für Drop Down-Felder
oder Prüfungen bei der Eingabe von Daten zu definieren. Auch Verweise auf Attribute
von DOM-Klassen sind hier sinnvoll und möglich, um so die Felder und deren Typen
näher zu definieren.
Beispiel
Im Rahmen des Projekts wurde die beschriebene Methode in vollem Umfang mit dem
Geschäftsprozessmanagement-Werkzeug ADONIS® umgesetzt. Dies gilt ebenso für
die Definition der grafischen Benutzeroberflächen, die zu 100 % modelliert werden
können. Dazu wurde auf technischer Ebene eine weitgehende Integration mit einem
Open Source-GUI-Builder (ohne Verfasser 2013) vorgenommen, um die modellierten
Benutzeroberflächen als Java-Swing-Oberflächen anzuzeigen.
13.3.2 Vorgehen zum Anforderungsmanagement im Rahmen der

kontinuierlichen Weiterentwicklung
Die Anwendung, die im Rahmen des beschriebenen Projekts umgesetzt wurde, ist
mittlerweile seit mehreren Jahren produktiv im Einsatz. Dadurch liegt der Fokus
auf der Pflege und Weiterentwicklung des Systems. Hierfür wurde in Ergänzung der
Spezifikationsmethode ein System zur Verwaltung von Anforderungen und zur kon-
trollierten Spezifikation (Change Request (CR), vgl. die Schritte 1–6 in Abb. 13.9)
sowie zur Begleitung der Umsetzung geschaffen (Auftragsmanagement, vgl. die
Schritte 7–8 in Abb. 13.9).
Entscheidend dabei ist, entsprechende Quality Gates im Rahmen der Freigabe vor-
zusehen und hierfür methodische und inhaltliche Standards zu definieren. Zudem sind
neben einer technischen Tool-Unterstützung vor allem die organisatorischen Aspekte im
Zuge des Anforderungsmanagement-Prozesses nicht zu unterschätzen.
Spezifikationen für Change Requests werden erstellt, Change Requests werden

gereviewed, befundet, geschätzt und beauftragt (freigegeben) umgesetzt und ausgeliefert
5
3
In Abnahme- Freigegebene Aktuelles

In In externem CR in
review und Fach- Produktions-
Bearbeitung Review Umsetzung
2 4 Schätzung 6 spezifikation 7 8 release
Abb. 13.9 Prozess für den Umgang mit Change Requests und das Auftragsmanagement
Tab. 13.2 Rollen und deren Tätigkeiten im Anforderungsmanagement

Rolle Tätigkeiten
Business-/IT-Analyst (Fachmodellierer) • Detailliert die Spezifikation von Change
Requests
• Steht für Detailfragen zur Spezifikation im
gesamten Prozess zur Verfügung
• „Übersetzer“ und „Vermittler“ zwischen
Fachbereich und IT/Umsetzung
Vertreter des Kunden/Auftraggebers • Nimmt fachliche Anforderungen auf und
(Prozessexperten des Fachbereichs) priorisiert diese
• Führt externes Review durch und beauftragt
spezifizierte und geschätzte Change Requests
• Nimmt umgesetzte Change Requests vor
Produktivsetzung von neuen Releases ab
Produktmanager • Nimmt fachliche Anforderungen entgegen,
diskutiert diese mit Vertretern des Kunden
und stimmt die Priorität ab
• Übernimmt Teile der Übersetzer-Rolle und
begleitet den gesamten Prozess
• Verantwortet die Release-Planung
Auftragsmanagement • Begleitet/moderiert den Prozess, insbesondere
die Kommunikation zwischen den involvier-
ten Rollen
Entwickler • Führt das Annahmereview und die Schätzung
von neuen Change Requests durch
• Implementiert die Change Requests
Tester • Begleitet bereits das Annahme-Review
• Führt fachliche Tests gegen die Spezifikation
und daraus erstellten Testfälle durch
Tab. 13.3 Softwarekategorien und deren Bewertung bezüglich Methode, Vorgehen und Einführung
268
Softwarekategorie Methode Vorgehen (Top-down/Bottom-up) Einführung

Standardsoftware • „Beliebige“ Methode für fach- • Beide Vorgehen sind möglich. • Big Bang: Vollständige Umstellung
liches Prozess-Blue-Printing • In der Regel kommt jedoch zu einem definierten Zeitpunkt.
(Prozesslandkarte und fachliche aufgrund des Projektumfangs • Iterativ: In mehreren kleineren
Prozessabläufe inkl. Ressourcen). das Top-down-Vorgehen zum Schritten (eher unüblich).
• Die Methode muss zumindest Einsatz (beginnend mit • Bei geschäftskritischer Software
erlauben, den Einsatz der Prozess-Blue-Printing, oft Phase paralleler Nutzung von
Standardsoftware im Prozessab- Abgleich mit Umfang der altem und neuem System.
lauf, die zum Einsatz kommenden Standardsoftware, Design von
Funktionen/Transaktionen Soll-Prozessen, Definition,
sowie den Anpassungsbedarf zu Customizing/Entwicklung,
definieren. Festlegung Testfälle, Rollout-
• Im Fall prozessbasierter Stan Vorbereitung etc.).
dardsoftware kommen oft tech-
nische Design-Modelle für die
Definition der Transaktionsab-
folge zum Einsatz.
Workflow-Systeme/Prozess- • Methoden, die die Konzepte • Beide Vorgehen sind möglich • In der Regel projektspezifisch,
Engines, Modifizierte der MDA® unterstützen. und in der Realität anzutreffen. oft iterativ bzw. in kleineren
Standardsoftware • Für das Design werden oft • Oft prototypisches Vorgehen Tranchen.
objektorientierte Methoden bzw. eine Mischung aus
verwendet. Top-down- und Bottom-up-
• Die in Abschn. 13.2.4 vorgestellte Vorgehen.
Methode kann als Rahmenwerk
dienen.
Individualsoftware • Für eine Best Practice-Methode vgl. • Top-down-Vorgehen. • Bei geschäftskritischer Software oft
Abschn. 13.2.4. • Bottom-up-Vorgehen praktisch Parallelbetrieb nach Umstellung.
nicht sinnvoll, ggf. für einzelne • Jedoch aufgrund der Problematik
Studien/Prototypen. der Datenmigration oft Big Bang-
Ansatz.
T. Rausch et al.
Dies umfasst die frühzeitige Priorisierung der Erweiterungen/Änderungen (daraus

ergeben sich zielgerichtete Spezifikationen) und das Einbinden entsprechender Fachleute
in allen Stufen des Prozesses. Diese Fachleute sind anhand ihrer Rollen in Tab. 13.2 im
Überblick nochmals dargestellt.
13.4 Zusammenfassung zur technischen Umsetzung von

Prozessen
Eine iterative Vorgehensweise bei der Entwicklung hat sich, unabhängig von der
Softwarekategorie, in nahezu allen Fällen als sinnvoll erwiesen, insbesondere wenn es
sich um größere Neuentwicklungen bzw. die Einführung von unternehmensweiter
Standardsoftware handelt.
Tabelle 13.3 bietet abschließend eine Zusammenfassung für die drei identifi-
zierten Softwarekategorien im Hinblick auf mögliche Methoden, Vorgehen und
Einführungsansätze.
Literatur
BOC (2006) Wege zu einer serviceorientierten Architektur (SOA). Whitepaper, BOC Information
Technologies Consulting AG, Wien
BOC (2007) Prozessorientierte Anwendungsentwicklung mit ADONIS. Whitepaper, BOC
Information Technologies Consulting AG, Wien
Diehl H-J (2000) Marketing für betriebswirtschaftliche Standardanwendungssoftware. Bewältigung
von Unsicherheit und Spezifität im Systemgeschäft. Deutscher Universitätsverlag, Wiesbaden
Hansen H-R, Neumann G (2009) Wirtschaftsinformatik 1: Grundlagen und Anwendungen, 10.
Aufl. Lucius und Lucius, Stuttgart
Herzog J (1998) Easy Use Cases – Bestimmung von Use Cases aus Geschäftsprozessmodellen.
OPP, München
Junginger S, Kühn H, Heidenfeld M, Karagiannis D (2000) Building Complex Workflow
Applications: How to Overcome the Limitations of the Waterfall Model. In: Fischer L (Hrsg)
Workflow Management Coalition: Workflow Handbook 2001, Future Strategies, Lighthouse
Point, S 191–206
Meijer M, Smalley M, Taylor S (2008) ITIL V3 and ASL – Sound Guidance for Application
Management and Application Development, Whitepaper, Norwich. http://www.best-manage-
ment-practice.com/gempdf/itilv3_asl_sound_guidance_white_paper_jan08.pdf. Zugegriffen:
07. Jan 2013
Object Management Group (OMG) (2011a) Business Process Model and Notation (BPMN)
Version 2.0. Dokumentation, OMG Document Number: formal/2011-01-03. http://www.omg.
org/spec/BPMN/2.0/PDF. Zugegriffen: 13. Jan 2013
Object Management Group (OMG) (2011b) OMG Unified Modeling Language™ (OMG UML),
Infrastructure – Version 2.4.1. Dokumentation, OMG Document Number: formal/2011-08-05
ohne Verfasser (2013) Java GuiBuilder Homepage. www.guibuilder.de. Zugegriffen: 07. Jan 2013
Organization for the Advancement of Structured Information Standards (OASIS) (2007) Web
Services Business Process Execution Language Version 2.0: OASIS Standard. Dokumentation.
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.pdf. Zugegriffen: 07. Jan 2013
Petzmann A, Puncochar M, Kuplich C, Orensanz D (2007) Applying MDA Concepts to Business
Process Management. In: Fischer L (Hrsg) 2007 BPM and Workflow Handbook. Future
Strategies, Lighthouse Point, S 103–116
Truyen F (2006) The Fast Guide to Model Driven Architecture: The Basics of Model Driven
Architecture, Whitepaper. Cephas Consulting Corp. http://www.omg.org/mda/mda_files/Cep
has_MDA_Fast_Guide.pdf. Zugegriffen: 13. Jan 2013
Vaher L (2003/2004) Potenziale und Risiken von Standard- und Individualsoftware. Universität
Hannover, Hannover
van der Pols R (2005) Application Services Library (ASL): A Framework for Application Management.
Van Haren, Amersfoort
Workflow Management Coalition (WfMC) (2013) XPDL Support and Resources.
http://www.wfmc.org/xpdl.html. Zugegriffen: 07. Jan 2013
Teil VI
Prozessdurchführung und Prozesscontrolling
Umsetzung des Prozesscontrollings
14
Erik Guschlbauer und Christian Lichka
Zusammenfassung
Das Prozesscontrolling erlaubt es Unternehmen, sich adäquat, zeitnah und mit effizientem
Einsatz der Ressourcen der sich kontinuierlich wandelnden Umwelt anzupassen. Konträr
zu klassischen Controlling-Ansätzen (basierend auf der Aufbauorganisation, funktional)
werden die Ressourcen kundenorientiert anhand der Wertschöpfungskette flexibel ver-
teilt, um stetigen Erfolg zu gewährleisten. Die Zielsetzung des Prozesscontrollings besteht
darin, über Prozesse benutzergruppenspezifisch zu informieren, Transparenz hinsicht-
lich der Prozessleistung und möglicher Optimierungspotenziale zu schaffen und zur
Implementierung der Unternehmensstrategie beizutragen. Das folgende Kapitel beleuch-
tet die Aufgaben und Ziele des Prozesscontrollings und beschreibt die Komponenten eines
Kennzahlensystems. Die Bestandteile, d. h. Ziele, Kennzahlen und Maßnahmen, werden
erläutert und in Zusammenhang gesetzt, um eine ausführliche Entscheidungsgrundlage
zu etablieren. Die Definition ausgewählter Regelkreise sichert die Verankerung und
Kontinuität des Prozesscontrollings in der Unternehmung. Auszüge zu technischen und
organisatorischen Implementierungsansätzen sowie ein exemplarischer, phasenbasierter
Vorgehensvorschlag schließen das Prozesscontrolling im Rahmen des Kapitels ab.
E. Guschlbauer (*)
e-mail: erik.guschlbauer@boc-group.com
C. Lichka
BOC Information Technologies Consulting GmbH, Zürcherstrasse 21, 8400 Winterthur, Schweiz

274 E. Guschlbauer und C. Lichka
14.1 Motivation und Zielsetzung des Prozesscontrollings
Unternehmen unterliegen aufgrund ihrer Umwelt einem kontinuierlichen Wandel;

doch ist es meist nicht die Veränderung an sich, die für eine Organisation problema-
tisch ist. Entscheidend ist die Geschwindigkeit, in der sich die Einflussfaktoren (bei-
spielsweise das Marktvolumen oder gesetzliche Regularien) verändern und in welchem
Tempo eine Organisation sich daran anpassen kann (Hutzler 2004). Um der Forderung
nach Flexibilität und zeitnaher Reaktion gerecht zu werden, ist es erforderlich, dass
Organisationen ihren Controlling-Ansatz hinterfragen. Bisherige Ansätze bauen ver-
mehrt auf der Steuerung von Aufbauorganisationen (funktional) auf. Die Verteilung von
Ressourcen erfolgt meist anhand einer Kostenstellenrechnung. Prozessverantwortungen
sowie -schnittstellen werden jedoch durch diesen Ansatz vernachlässigt (nicht gesteuert),
wodurch Effizienzeinbußen verursacht werden. Unternehmen sind daher zu motivieren,
eine vollständig prozessorientierte Organisation zu etablieren, die die Integration der
Strategie in das Zentrum stellt (Knuppertz 2008).
Die unterschiedlichen Aufgaben einer solchen prozessorientierten Organisation wer-
den durch spezifische Rollen im Unternehmen wahrgenommen (vgl. Abschn. 2.2). Im
Umfeld des Prozesscontrollings sind für nachfolgend beschriebene Aufgaben vorrangig
der Prozessverantwortliche und der Prozesscontroller zuständig.
Die Zielsetzung des Prozesscontrollings besteht darin, über Prozesse benutzergruppen-
spezifisch zu informieren und Transparenz hinsichtlich der Prozessleistung und mög-
licher Optimierungspotenziale zu schaffen. Von zentraler Bedeutung sind dabei die in
Abb. 14.1 angeführten Aufgabenbereiche (Fiedler 2013).
Die Prozessbewertung erfolgt im Rahmen der Phase Prozessstrategie des Process
Management Life Cycle (PMLC, vgl. Abschn. 2.4.1) und dient zur Planung der
Umsetzung der Prozessmanagement- und Unternehmensstrategie. Die Analyse erfolgt
anhand von Prozesslandkarten und stellt sicher, dass die richtigen Prozessstrukturen eta-
bliert werden. Für ausgewählte Geschäftsprozesse erfolgt die Ableitung von Zielen und
Kennzahlen.
Abb. 14.1 Aufgabenbereiche

des Prozesscontrollings (Fiedler
2013)
Prozess- Prozess- Prozess-
bewertung überwachung optimierung
Prozessinformation
14 Umsetzung des Prozesscontrollings 275
Die Prozessüberwachung erfolgt innerhalb der PMLC-Phase Prozesscontrolling (vgl.

Abschn. 2.4.6) und umfasst das periodische Reporting des Status hinsichtlich der gemes-
senen Kennzahlen und mit konkreten Vorgaben versehenen Zielen. Die Ergebnisse
sind laufend mit der Unternehmens- und Prozessstrategie abzugleichen, um frühzei-
tig Potenziale (positiv wie negativ) wahrzunehmen und entsprechende Maßnahmen
zu setzen. Die Überwachung der Prozesse stellt sicher, dass die Unternehmens- und
Prozessstrategie richtig umgesetzt wird.
Die Prozessoptimierung erfolgt im Zuge der gleichnamigen PMLC-Phase (vgl.
Abschn. 2.4.3) und gliedert sich in zwei Abschnitte. Die etablierten Ist-Prozesse sind hin-
sichtlich der Eignung zur Umsetzung der Unternehmens- und Prozessstrategie zu evalu-
ieren und zu bewerten. Der daraus abgeleitete Handlungsbedarf an der Prozesslandschaft
ist zu strukturieren und zu priorisieren. Die Adaption der einzelnen Prozesse erfolgt
durch gesonderte Maßnahmen. Auf Basis der angepassten Prozesse sind Vision, Mission
und zugeordnete Messinstrumente einem Review zu unterziehen und bei Bedarf an die
Unternehmensziele anzugleichen. Die veränderten Rahmenbedingungen (Strategie und
Prozesslandschaft) sowie die Ergebnisse aus dem Controlling bedingen die Anpassung
von Zielen und Kennzahlen. Der Fokus der Prozessoptimierung ist es, die Effizienz und
Effektivität der Prozesse sowie deren Controlling zu steigern.
Die Prozessinformation beschreibt die Verteilung und Kommunikation der Prozesse und
Prozessschritte, die über alle Aufgaben des Prozesscontrollings übergreifend erfolgen muss.
Tabelle 14.1 fasst mögliche Zielsetzungen für das Prozesscontrolling eines Unter
nehmens anhand der beschriebenen Aufgaben zusammen.
Tab. 14.1 Zielsetzungen des Prozesscontrollings

Aufgabenbereiche Zielsetzung
Prozessbewertung • Umsetzung der Unternehmensstrategie gewährleisten
• Langfristigen Unternehmenserfolg sicherstellen
• Belegbarkeit von Bauchgefühl und Erfahrung erzielen
Prozessüberwachung • Operationalisierung der Prozessdokumentation erreichen
• Zielerreichungsgrad messen
• Potenziale, Chancen und Risiken erkennen und beurteilen
• Transparente Steuerungsinformation erheben
• Kommunikation fördern
• Prozessmanagement in der Unternehmenskultur verankern
Prozessoptimierung • Entscheidungsgrundlagen etablieren
• Effizienz und Effektivität steigern
• Grundlage für Benchmarking (intern wie extern) schaffen
Prozessinformation • Transparente Kommunikation der Prozesslandschaft und deren
Bestandteile durchführen
• Zielsetzung und Vorgehen publizieren
14.2 Einbettung des Prozesscontrollings in eine

prozessorientierte Organisation
Die Einbettung des Prozesscontrollings in eine vollständig prozessorientierte

Organisation ist ein wesentlicher Erfolgsfaktor. Bezogen auf die Unternehmung ist
zu beachten, dass die Prozesse gemäß der Strategie aufzubauen sind (Schmelzer und
Sesselmann 2010, S. 255) und die Aufbauorganisationsstruktur den Prozessen zu folgen
hat (Schmelzer und Sesselmann 2010, S. 546).
Bezugnehmend auf das Prozessmanagement werden auf Basis der Strategie geeignete
Ziele erarbeitet. Diese Ziele bilden die Grundlage zur Gestaltung der Prozesslandschaft
des Unternehmens (vgl. Kap. 3). Die Umsetzung und Leistungserbringung obliegt der
Aufbauorganisation, deren Ergebnisse anhand definierter Messwerte zu evaluieren sind.
Die Kernaufgabe des Prozesscontrollings besteht somit im Abgleich von Zielen und der
erbrachten Leistung. Davon ist abzuleiten, dass das Prozesscontrolling sowohl im stra-
tegischen als auch im operativen Umfeld eines Unternehmens zu etablieren ist. Die
Aufgaben des strategischen als auch des operativen Prozesscontrollings können zusam-
mengefasst Tab. 14.2 entnommen werden.
Als Schnittmenge zwischen strategischem und operativem Prozesscontrolling ist die
Bereitstellung geeigneter Ziele und Kennzahlen anzusehen, die sowohl die Historie eines
Unternehmens, den aktuellen Status sowie mögliche Zukunftsszenarien umfassen. Zu
diesem Zweck ist eine geeignete Methodik anzuwenden, die diese Informationen in ihrer
Gesamtheit erfasst und anwendungsspezifische Auswertungen erlaubt. Die folgenden
Abschnitte greifen dies auf und beschreiben die Grundlagen eines kennzahlenorientier-
ten Prozesscontrollings.
Tab. 14.2 Aufgaben des strategischen und des operativen Prozesscontrollings

Strategisches Prozesscontrolling Operatives Prozesscontrolling
Definition strategischer, prozessbezogener Ableitung operativer Prozessziele,
Ziele basierend auf den strategischen
Prozesszielen
Ableiten kritischer Erfolgsfaktoren von Bestimmen der Kennzahlen und Ziele
Prozessen
Identifikation und Bewertung strategischer Laufende Performance-Evaluation
Leistungslücken
Sicherstellung der prozessorientierten Periodische Reviews der Prozesslandschaft,
Ausrichtung des Unternehmenscontrol- Kennzahlen und Vorgaben
lings
Periodische Evaluation hinsichtlich der −
Unternehmensstrategie
14.3 Die Kennzahl – eingebettet in ein System
14.3.1 Die strategische Variable „Ziel“
Ziele sind auf unterschiedlichen Ebenen einer prozessorientierten Unternehmung zu definie-

ren und sollten sich an den bekannten SMART-Grundlagen orientieren (vgl. Abschn. 4.2.4).
Die Erarbeitung von Prozesszielen beginnt im Kontext eines längerfristigen, kon-
tinuierlichen Strategieprozesses. Ausgehend von der Strategie, dem Leitbild und der
Vision des Unternehmens werden kritische Erfolgsfaktoren erarbeitet. Diese bilden die
Grundlage für die Definition von Zielen auf strategischer Unternehmensebene. Es gilt
zu beschreiben, was eine Organisation erreichen muss, um die langfristige Orientierung
umzusetzen und den Unternehmenserfolg zu sichern.
Die strategischen Ziele werden auf Ebene des Prozessmanagements einem Abgleich
unterzogen. Es wird definiert, welche Prozesse oder Prozesseinheiten Einfluss auf ein
strategisches Ziel nehmen. Für die jeweiligen Ergebnismengen gilt es erneut, kritische
Erfolgsfaktoren zu erheben und daraus strategische Prozessziele abzuleiten.
Prozesseinheiten und -gruppierungen sind hinsichtlich ihrer Elemente und deren
Zielsetzungen (operative Prozessziele) zu untersuchen. Eine Zielvereinbarung sollte pro
Prozess erfolgen, doch in Ermangelung ausreichender Ressourcen seitens des Managements
und Controllings kann dies auf die relevanten Hauptprozesse eingeschränkt werden.
Basierend auf der dreistufigen Hierarchie (Ziele aus der Strategie, strategische
Prozessziele, operative Prozessziele) sind Zielsetzungen für das Prozesscontrolling fest-
zulegen. Es gilt zu erarbeiten, welche Informationen zur Zielerreichung und -steuerung
erhoben werden müssen. Darüber hinaus ist zu definieren, welche Leistungen (inkl.
Ressourcenaufwand) dafür zu erbringen sind.
14.3.2 Die strategische Variable „Kennzahl“
Zur Erfolgskontrolle der definierten Ziele sowie als Indikator für Potenziale werden
innerhalb des Prozesscontrollings Kennzahlen genutzt. Es wird zwischen Kennzahlen
der Unternehmung und Prozesskennzahlen unterschieden. Key Performance Indicators
(KPeI) stellen aus Sicht des Managements erfolgskritische Messfaktoren dar, beispiels-
weise die Rentabilität der Unternehmung. Key Process Indicators (KPrI) hingegen wer-
den durch die Prozessverantwortlichen definiert und beschreiben Kennzahlen, die
zur Beurteilung eines Prozesses oder einer Prozessgruppe herangezogen werden, zum
Beispiel die prozentuale Erfolgsquote eines Produktionsprozesses.
Definition
Kennzahlen sind Messgrößen, die den Leistungsstand eines Unternehmens nach Inhalt,
Zeit und Ausmaß genau bestimmen. Im Gegensatz dazu sind Prozesskennzahlen
Messgrößen, die den Leistungsstand von Prozesszielen nach Inhalt, Zeit und Ausmaß
genau bestimmen.
Bei der Definition einer Kennzahl gilt es festzulegen, welche Erwartungshaltung diese zu
erfüllen hat. Die Aussagekraft einer Kennzahl hat sich direkt auf das zugewiesene Ziel zu
beziehen, beschreibt dieses und erlaubt Rückschlüsse auf die Historie, den gegenwärtigen
Status und die mögliche künftige Entwicklung. Beispielsweise beschreibt die Erfolgsquote
eines Produktionsprozesses fortwährend dessen Verlauf. Anhand der Historie sowie
möglicher Hochrechnungen kann die weitere Entwicklung und die Wirksamkeit von
Opti mierungsmaßnahmen eingeschätzt werden. Ein konträres Beispiel beschreibt
die alleinige Betrachtung der Kosten pro Prozessdurchlauf. Aufgrund sich wandeln-
der Gegebenheiten (wie bspw. Verfügbarkeit der Ressourcen, Marktlage oder einmalige
Investitionen) kann die Entwicklung der Prozesskennzahl nicht eindeutig eingeschätzt
und beurteilt werden.
Des Weiteren gilt es bei der Erarbeitung von Kennzahlen die Anforderungen des
Unternehmens und des Prozessmanagements zu berücksichtigen. Eine generelle Prämisse
umfasst beispielsweise die ökonomische Auswertung und Erhebung einer Kennzahl.
Es gilt den Aufwand zur Pflege einer Kennzahl dem Nutzen gegenüberzustellen. In vie-
len Fällen empfiehlt es sich, bereits vorhandene Daten (beispielsweise aus einem Data
Warehouse) zu nutzen und anhand der Erfordernisse aufzubereiten/zu aggregieren.
Kennzahlen sollen der aktiven Steuerung der Prozesse und des Unternehmens dienen. Aus
diesem Grund ist es erforderlich, dass die etablierten Werte zeitnah erhoben und ausge-
wertet werden können. Das bedingt, dass die Aussagekraft einer periodischen Bewertung
für die nächste Bezugsperiode (und gegebenenfalls die fortfolgenden) weiterhin gültig ist.
Bei der Definition einer Kennzahl ist darüber hinaus der Bezug zu den als SMART defi-
nierten Zielen zu wahren und ebenso einzuhalten (vgl. Abschn. 4.2.4). Die Werte der KPeI
und KPrI sind periodisch und fortwährend zu erheben. Von besonderer Bedeutung sind
dabei die Stabilität der Datengrundlage und die Kontinuität der Entwicklung. Zu beachten
ist jedoch, dass Unternehmen zukunftsorientiert zu agieren haben; dementsprechend ist
bei der Definition jene Ausprägung zu berücksichtigen, die den geringsten Einfluss durch
vergangene Faktoren aufweist (Hamel 2009). Um die Auswertung auf unterschiedlichen
(Management-)Ebenen zu ermöglichen, sind die Periodenwerte von Kennzahlen in defi-
nierten Skalen zu gestalten (bspw. alle Finanzkennzahlen im Format Millionen Euro). Die
Daten zur Kennzahlenerhebung sollten direkt aus dem zu beurteilenden Prozess stammen
und müssen diesen direkt beeinflussen. Beide Faktoren unterstützen die Akzeptanz des
Prozesscontrollings auf der Ebene der Prozesse.
Definition
rozesskennzahlen sind stets gemäß dem Ziel, das durch den Prozess realisiert wird,
P
zu gestalten und sollen Information betreffend Effizienz, Effektivität und Steuerung
für den Verantwortlichen repräsentieren. Die visualisierten Werte sollen Aufschluss
darüber geben, in welcher Form der Prozess zur Zielumsetzung beiträgt.
Bei der Erarbeitung von Kennzahlen gilt es jedoch, den Umfang des Unternehmens und
seiner Prozesse zu erfassen. Daher ist es von Bedeutung, dass man von einer rein wer-
tegetriebenen Betrachtungsweise abkehrt. Sogenannte harte Kennzahlen (zum Beispiel
finanzielle Auswertungen oder prozentuelle Verteilungen) stellen weiterhin einen essen-
tiellen Bestandteil der Unternehmenssteuerung dar. Jedoch sind diese im Rahmen des
Prozesscontrollings um sogenannte weiche Faktoren (unter anderem Prozessumfelder,
Prozesskultur, Konflikt- und Ressourcenmanagement) zu ergänzen. Externe Faktoren
(beispielsweise die Marktentwicklung und die Kundenstruktur) können im Rahmen des
Prozesscontrollings angeführt und bei der Entscheidungsfindung berücksichtigt werden,
sind jedoch gesondert anzuführen oder zu kennzeichnen, da sie nicht direkt durch die
Prozessgruppe oder den Prozess zu beeinflussen sind. Darüber hinaus sollten Kennzahlen
markiert werden, die ein Unternehmen pflegen muss, beispielsweise aufgrund von
Zertifizierungen (z. B. ISO 9001 (International Organization for Standardization (ISO)
2005)) oder rechtlichen Ansprüchen (z. B. BASEL III (Bank for International Settlements
2010)). Zuletzt sollte im Rahmen des Prozesscontrollings angeführt werden, ob eine
Kennzahl aktiv oder reaktiv ausgeführt ist. Aktive Kennzahlen können durch den Prozess
präventiv gestaltet werden (bspw. die Prüfung der Qualifikation und Liquidität vor der
Beauftragung). Reaktive Kennzahlen bedürfen adaptiver Vorgänge im Anschluss an
deren Erhebung (bspw. die Aufzeichnung eingesetzter Ressourcen).
14.3.3 Das Kennzahlensystem
Die Elemente Strategie, Prozess, Ziel sowie Kennzahl befinden sich in einer Unternehmung
in einem gegenseitigen Spannungsfeld. Entscheidungen und Änderungen beeinflussen
diese Elemente wechselseitig auf den unterschiedlichsten Ebenen. Im Rahmen des
Prozesscontrollings ergibt sich auf unterster Ebene die Wechselwirkung aus den in
Abb. 14.2 beschriebenen Elementen.
Abb. 14.2 Wechselwirkung

der Elemente Prozess, Ziel und
Kennzahl Ziel
Kenn- Prozess
zahl beeinflusst
Prozess Strategisches Ziel Controlling-Kennzahl

hat hat
Entwicklungsprozess Höhere Ertragskraft Betriebsergebnis
erzielen
Hauptprozess
Marketing und Vertrieb
Unterstützungsprozess Unterstützungsprozess
Organisationsentwicklung Prozessziel: Markt- Personalmanagement
führerschaft erlangen
Prozessziel: Prozess- Prozessziel:
qualität erhöhen Marktanteil Produktivität steigern
Durchlaufzeit
Umsatz je Mitarbeiter
Anzahl Reklamationen
Abb. 14.3 Beispiel zur Abhängigkeit von Prozesscontrolling-Inhalten
Die anhand der Unternehmensstrategie definierten Ziele sind durch die Leistungen
des Unternehmens zu realisieren. Prozesse definieren die Leistungserbringung inner-
halb einer Organisation und sind somit für die Umsetzung der Ziele maßgeblich. Die im
Rahmen der Prozessdurchläufe erzielten Ergebnisse werden mit Hilfe von Kennzahlen
gemessen und bewertet. Durch den Abgleich von Zielen und Kennzahlen kann der
Erfolg des Unternehmens beurteilt werden und in weiterer Folge eine Potenzialanalyse
sowie eine darauf basierende Umgestaltung der Prozesslandschaft erfolgen.
Die Wechselwirkung der Elemente wird jedoch um weitere Ausprägungen unter-
schiedlicher Art ergänzt. Ziele, Prozesse und Kennzahlen wirken auf unterschiedlichen
Ebenen aufeinander ein und beeinflussen somit die jeweiligen Ergebnisse. Am verein-
fachten Beispiel in Abb. 14.3 ist zu erkennen, dass ein auf strategischer Ebene definiertes
Ziel (höhere Ertragskraft erzielen) sowohl durch Kernprozesse (Marketing & Vertrieb)
als auch Unterstützungsprozesse (Organisationsentwicklung und Personalmanagement)
beeinflusst wird.
Die Wechselwirkung zwischen Elementen wird durch ein geeignetes Kennzahlensystem
visualisiert und aufbereitet. Es muss das Ziel der Unternehmung sein, den jeweiligen
Anwendergruppen die benötigte Information adäquat und entscheidungsrelevant aufbe-
reitet zur Verfügung zu stellen.
Das Prozesscontrolling eines Unternehmens ist entsprechend aufzubauen und sollte
darüber hinaus die Vernetzung der Anforderungen, die definierten Leitlinien sowie die
Strukturen von Kennzahlen, Zielen und Prozessen berücksichtigen. Entscheidend ist,
dass Abhängigkeiten und Aggregationen visualisiert werden und den Nutzern die benö-
tigte Information zur Verfügung steht. Dies umfasst sowohl den Datenumfang, deren
zielgruppenspezifische Aufbereitung (so viel wie nötig, so wenig wie möglich) sowie
die Möglichkeit, tiefer in die Strukturen blicken zu können (engl. Drill Down). Beim
Aufbau des Prozesscontrollings ist darüber hinaus zu beachten, dass ebenso ausgewählte
Information aus dem Unternehmenscontrolling integriert wird und für weitere Analysen
zur Verfügung steht. Nur eine vollständige Betrachtung der Unternehmung (Strategie
und Prozesse) gewährt eine adäquate Entscheidungsgrundlage.
14.4 Einbettung von Kennzahlensystemen in Management-

Szenarien am Beispiel des Prozessmanagements
14.4.1 Definition von Anforderungen und der Erwartungshaltung
Eine prozessorientierte Unternehmung unterliegt der Prämisse sich kontinuier-

lich zu verbessern. Dieses Streben nach Verbesserung umfasst unter anderem die
Prozessoptimierung gemäß der gleichnamigen PMLC-Phase (vgl. Abschn. 2.4.3) als
auch die Messung im Rahmen des Prozesscontrollings, die Aufschluss darüber gibt, ob
die Änderungen eine positive oder negative Auswirkung hatten. Unter Verbesserung ist
darüber hinaus die Anpassung an Gegebenheiten und die Umwelt zu verstehen. Dies
betrifft beispielsweise den bewussten Umgang mit Know-how (Aufbau und Wegfall),
die Ausrichtung auf die Bedürfnisse des Kunden (Wünsche, Anforderungen und
Erwartungshaltung) als auch die Anpassung der Unternehmens- und Prozessstruktur
hinsichtlich neuer/adaptierter Produkte und Technologien (Allweyer 2005).
Prozesscontrolling spricht vor allem Entscheidungsträger innerhalb eines
Unternehmens an. Diese benötigen für ihre Arbeiten eine adäquate Informationsbasis,
die zur weiteren Steuerung des Unternehmens genutzt werden kann und innerhalb der
Organisation als Bewertungsgrundlage dient. Das Steuerungsinstrument ist jedoch nicht
auf Reengineering beschränkt, sondern sollte zur laufenden Kontrolle und Evaluation
genutzt werden. Nur eine flexible und reaktionsschnelle Organisation kann ihre Strategie
dauerhaft umsetzen und den Unternehmenserfolg gewährleisten.
Definition
rozesscontrolling stellt die notwendige Information zur erfolgreichen, zukunftsorien-
P
tierten Fortführung des Unternehmens zur Verfügung. Es bietet den Verantwortlichen
eine adäquate Entscheidungs- und Argumentationsgrundlage.
Der Prozesscontrolling-Regelkreis setzt sich aus drei Bestandteilen zusammen, die in

Abb. 14.4 angeführt sind.
Die initiale Einführung des Prozesscontrollings innerhalb einer Unternehmung erfolgt
gemäß den oben genannten Prämissen und Anforderungen. Im Zuge dessen werden die not-
wendigen Grundlagen erhoben, bestehende Inputs validiert und ein Zielszenario festgelegt.
Abgeschlossen wird diese einmalige Phase mit dem Übergang in den Betrieb. Ein Controlling-
Zyklus etabliert die Rahmenbedingungen für Entscheidungs- und Bewertungsgrundlagen
und die daraus abgeleiteten Projekte und Maßnahmen. Ein gesonderter Review-Zyklus dient
zur kontinuierlichen Verbesserung des Prozesscontrollings und dessen Adaption an die
Unternehmens- und Umwelterfordernisse.
Abb. 14.4 Übersicht über den Review

Prozesscontrolling-Regelkreis
Initiale Controlling
Einführung &
Betrieb
14.4.2 Initiale Einführung des Prozesscontrollings
Im Zuge der initialen Einführung des Prozesscontrollings werden die notwendigen

Grundlagen innerhalb des Unternehmens und dessen Strategie- und Prozesskultur etabliert.
Die Phasen der Einführung sind in Abb. 14.5 gelistet.
Die Erhebung der Grundlagen beinhaltet, eine organisatorische Struktur im Unterneh
men zu etablieren. Dies umfasst die Definition eines Kernteams mit Mitgliedern der
unterschiedlichen Managementebenen (Unternehmensführung, Prozessmanagement,
Bereichsmanager). Das Kernteam begleitet die initiale Einführung bis zum Übergang in den
Betrieb. Es ist sicherzustellen, dass die Teammitglieder über entsprechende Kompetenzen
verfügen und ein repräsentatives Bild der Organisation widerspiegeln. Vergleichbar zur
PMLC-Phase Prozessdokumentation (vgl. Abschn. 2.4.2) wird im Rahmen von Steuerungs
runden die Prozess- und Geschäftsumgebung erhoben. Das Ergebnis daraus ist ein reiner
Dokumentationsbestand (beispielsweise bestehend aus Prozesslandkarten, Prozessen und
Verantwortungen), der in ein zyklisches Controlling-Szenario zu migrieren ist. Die in Form
der Dokumentation vorliegenden Inputs sind gemäß strategierelevanter Umfelder zu vali-
dieren, zu denen unter anderem Vision, Mission und Strategie der Unternehmung gehö-
ren. Basierend auf der Ergebnismenge ist ein Zielszenario festzulegen, das darüber hinaus
die Zielgruppen (unter anderem Stakeholder und künftige Anwender) umfasst. Ausgehend
vom Zielszenario sind Eingangs- und Ausgangskriterien (zum Beispiel Finanzkennzahlen
oder Ressourcenplanungen) zu definieren, die aufschlüsseln, welche Information bereits in
Abb. 14.5 Phasen der Initiale Einführung

initialen Einführung des
Prozesscontrollings
Grundlagen Inputs Zielszenario

erheben validieren festlegen
der Unternehmung vorhanden ist und welche noch erarbeitet werden muss. Mittels der zur
Verfügung stehenden Information wird eine Machbarkeitsstudie anhand einer repräsenta-
tiven Prozessgruppe durchgeführt. Das Ergebnis umfasst einen Erstentwurf der Kennzahlen
und Ziele, der ebenso eine Revision der bisherigen Arbeiten enthält. Durch die Definition
von Abhängigkeitsbeziehungen und zielgruppenspezifischen Auswertungen wird ein ers-
tes Kennzahlensystem realisiert und an der repräsentativen Prozessgruppe erprobt. Die
Ergebnisse des Testbetriebs fließen in das finale Konzept zum Prozesscontrolling ein, bevor
dieses in den Betrieb wechselt. Der Übergang in den Betrieb ist pro Prozessbereich durch-
zuführen, wobei zu beachten ist, dass Organisationseinheiten nach Möglichkeit nicht in
einem Mischbetrieb zu führen sind.
14.4.3 Controlling und Betrieb
Der laufende, zyklische Betrieb eines Prozesscontrollings besteht aus vier Kernschritten,
die in Abb. 14.6 angeführt sind.
Periodisch sind die benötigten Daten der definierten Ziele und Kennzahlen zu erheben
und aufzubereiten, wie dies bspw. auch in der PMLC-Phase Prozessdurchführung geschieht
(vgl. Abschn. 2.4.5). Als Datenquellen stehen die manuelle Erhebung, die Nutzung operativer
Informationssysteme (z. B. ERP-Systeme) als auch Workflow-Instrumente zur Verfügung.
Manuelle Erhebungen sind auf ein Minimum zu reduzieren, da sie erheblichen Aufwand
bedeuten und die höchste Fehlerwahrscheinlichkeit aufweisen. Der Einsatz empfiehlt sich
im Rahmen der initialen Einführung, da somit flexibel mit vorhandener Information gear-
beitet werden kann. Die operativen Informationssysteme einer Unternehmung bieten meist
eine Vielzahl an Information, jedoch ohne Bezug zu Prozessen, Zielen und Kennzahlen.
Bei der Nutzung dieser Informationsquelle ist es von Bedeutung, dass die Verknüpfung zur
Prozesslandschaft sämtlichen involvierten Unternehmensbereichen bewusst ist und strin-
gent gepflegt wird. Workflow-Systeme dienen der Ablaufsteuerung und bieten oftmals bereits
Abb. 14.6 Zyklus von Daten-

Controlling und Betrieb erhebung
Controlling Daten-
Controlling & auswertung
Betrieb
Maßnahmen-
definition
einen Prozesskontext. In vielen Fällen kann die Information direkt weiter verarbeitet werden.
In der Praxis ergibt sich meist ein Mischbetrieb aus den drei genannten Datenquellen. Zu
beachten ist, dass die gewonnenen Rohdaten anhand der Zielgruppen, Konventionen und
Erfordernisse aufzubereiten sind. Dies umfasst unter anderem die Umrechnung auf nor-
mierte Skalen, die Aggregation von der Abteilungs- hin zur Unternehmensebene sowie eine
Plausibilitätsprüfung.
Die Ergebnisdaten sind innerhalb des Kennzahlensystems zu hinterlegen und den
verantwortlichen Personen zur Auswertung zur Verfügung zu stellen. Als geeignetes
Instrument haben sich Management-Cockpits etabliert, die sowohl eine übersichtliche
Darstellung der Gesamtsituation gewähren als auch detaillierte Information (engl. Drill
Down) für die weitere Analyse zur Verfügung stellen.
Im Rahmen der Auswertung steht die Umsetzung der Prozessziele im Vordergrund.
Zu diesem Zweck ist durch den Prozesscontroller speziell die Entwicklung des Prozesses
unter Einbezug von Umweltkriterien und der Historie zu beurteilen. Das etablierte
Kennzahlensystem erlaubt den Verantwortlichen die Auswertung hinsichtlich definierter
Schwellwerte und prognostizierter Hochrechnungen.
Die Verantwortung für die Ziele und Kennzahlen der Prozesse trägt typischerweise der
Prozessverantwortliche. Daher sind in Absprache mit ihm geeignete Maßnahmen und
Projekte aufzusetzen, die eine optimale Nutzung der vorhandenen Ressourcen hinsicht-
lich der Zielerreichung sicherstellen. Maßnahmen sind mit den entsprechenden Prozessen,
Zielen und Kennzahlen zu verknüpfen und in weiterer Folge in den Controlling-Zyklus zu
integrieren. Die Definition umfasst sowohl den Auslöser einer Maßnahme, deren Zielsetzung
als auch eine Beschreibung und Argumentation der geplanten Tätigkeiten. Darüber hinaus
werden die geplanten Ressourcen hinterlegt und eine zeitliche Meilensteinplanung definiert.
Die Planung einer Maßnahme oder eines Projekts erlaubt dessen Integration in den
Controlling-Zyklus. Es ist sicherzustellen, dass die Maßnahme für sich entsprechend
der Unternehmensstandards durchgeführt wird und eine positive Auswirkung auf
die gesamte Zielerreichung hat. Bei der Beurteilung einer Maßnahme gilt es sämtliche
Einflussfaktoren innerhalb der prozessorientierten Unternehmung zu berücksichtigen,
da positive wie negative Korrelationen innerhalb des Prozessszenarios zu erwarten sind.
Durch die kontinuierliche Evaluation und Steuerung der Prozesse hinsichtlich deren
Ziele sowie durch die ergriffenen Maßnahmen wird innerhalb der Unternehmung eine
vollständige Realisierung der Unternehmensstrategie ermöglicht.
14.4.4 Periodische Reviews
Um der Prämisse der stetigen Verbesserung und Strategierealisierung eines Unternehmens

gerecht zu werden, ist es erforderlich, die Elemente des Prozesscontrollings regelmäßig
zu beurteilen und gegebenenfalls anzupassen. Abbildung 14.7 beschreibt die Kernschritte
eines zyklischen Review-Prozesses.
Im Rahmen der Einführung des Prozesscontrollings wurden für die Elemente des
Kennzahlensystems (Ziele, Kennzahlen, Maßnahmen, Projekte und Prozesse) Kriterien
Abb. 14.7 Zyklus des Review- Evaluation

(operativ)
Prozesses
Evaluation
Controlling Review (strategisch)
Maßnahmen-
definition
für eine erneute Evaluation hinterlegt. Diese kann sowohl periodisch ausgelöst werden
(beispielsweise jährlich) als auch ereignisbezogen (zum Beispiel beim Abschluss einer
Maßnahme oder dem Vorliegen eines Quartalsberichts) sein.
Die operative Evaluation behandelt die einzelnen Elemente eines Kennzahlensystems
hinsichtlich ihrer Eigenschaften. Auf Basis des Datenbestands aus dem Betrieb
(vgl. Abschn. 14.4.3) gilt es zu bewerten, ob Information erhoben, gepflegt und
zum Controlling der Entwicklung genutzt wurde. In weiterer Folge ist durch die
Kompetenzträger zu evaluieren, ob das Element seinen Zweck gemäß der definierten
Richtlinien erfüllt und das Controlling eine adäquate Steuerung erlaubt. Die Resultate
sind, gekennzeichnet als operative Lücken, in die Maßnahmendefinition zu überführen.
Die strategische Evaluation behandelt das Gesamtbild des Prozesscontrollings (abge-
bildet durch ein Kennzahlensystem, vgl. Abschn. 14.3.3) bezogen auf die Leistung
zur Steuerung des Unternehmens, der Zielerreichung und Realisierung der Strategie.
Für die Steuerung der Unternehmung ist es erforderlich zu prüfen, ob Information
termingerecht zur Verfügung stand, verarbeitet und als Entscheidungsinstrument
genutzt wurde. Die Zielerreichung des Prozesscontrollings ist am Umsetzungsgrad
der Unternehmensstrategie zu messen. Da diese durch die Prozessziele umzusetzen
ist, gelten diese wiederum als zu aggregierende Leistungsindikatoren. Aufgrund der
Entwicklung einer Organisation und ihrer Strategie sind das Prozesscontrolling sowie
das Kennzahlensystem hinsichtlich der Strategieumsetzung zu evaluieren. Es gilt fest-
zustellen, ob mit der etablierten Methodik eine adäquate Umsetzung der Strategie und
deren Steuerung gewährleistet werden kann. Die Resultate der Analysen sind als strategi-
sche Lücken in die Maßnahmendefinition zu überführen.
Die Maßnahmendefinition wird genutzt, um Entwicklungspotenziale des
Prozesscontrollings in einer Unternehmung zu nutzen. Basierend auf den strategischen und
operativen Lücken gilt es zu entscheiden, welche Aktionen durch die Organisation auszu-
lösen sind. Projekte und Maßnahmen eignen sich zur partiellen Adaption von Prozessen
und Prozessgruppen sowie von Elementen des Kennzahlensystems. Sie sind definiert
durch Auslöser, Zielsetzung, Beschreibung und Argumentation der Tätigkeiten. Darüber
hinaus sind sowohl Ressourcen als auch zeitliche Meilensteine zu planen. Sofern erheb-
licher Handlungsbedarf identifiziert wurde (dies umfasst bspw. die Einführung neuer
Prozessgruppen oder die Restrukturierung der bestehenden Organisation) ist dies in Form
eines Reengineering-Programms (als Summe einer Mehrzahl an Projekten) durchzuführen.
Die Planung einer Maßnahme oder eines Projekts erlaubt dessen Integration in den
Controlling-Zyklus. Es ist sicherzustellen, dass die Maßnahme für sich entsprechend der
Unternehmensstandards durchgeführt wird und sich positiv auf die Implementierung der
Unternehmensstrategie auswirkt. Bei der Beurteilung gilt es sämtliche Einflussfaktoren
innerhalb der prozessorientierten Unternehmung zu berücksichtigen, da positive wie
negative Korrelationen innerhalb des Prozessszenarios zu erwarten sind.
Durch die kontinuierliche Evaluation und Steuerung des Prozesscontrollings hin-
sichtlich der Strategieumsetzung sowie durch die ergriffenen Maßnahmen wird inner-
halb der Unternehmung eine vollständige Realisierung derselben gewährleistet.
14.5 Technische und organisatorische Lösungen zur

Integration
14.5.1 IT-gestütztes Prozesscontrolling
Die zentrale Aufgabe des Controllings besteht darin, Daten übersichtlich und struktu-
riert aufzubereiten, um Entscheidungsträgern ein verständliches Bild zur wirtschaft-
lichen Lage und Entwicklung des Unternehmens liefern zu können. Aus Sicht des
Prozesscontrollings ergeben sich daraus die in Abb. 14.8 angeführten Teilschritte.
Prozessintegration
Auswertung
Aggregation Datenbestand
operative Workflow-
Erhebung manuell
Systeme Instrumente
Abb. 14.8 Teilschritte des IT-gestützten Prozesscontrollings

Ausgehend vom Datenbestand der Unternehmung und dem definierten Bedarf des
Prozesscontrollings sind die benötigten Daten zu erheben. Als Datenquellen können
beispielsweise manuelle Informationen, operative Systeme oder Workflow-Instrumente
dienen. Um eine prozessorientierte Verarbeitung gemäß dem Kennzahlensystem zu
ermöglichen, ist der erarbeitete Datenbestand zu aggregieren. Die aggregierten Daten
können entsprechend definierter Controlling-Prämissen ausgewertet werden. Mögliche
Auswertungen stellen Reports, tabellarische Sichten sowie Grafiken dar. Der letzte
Schritt besteht in der Verknüpfung der erzielten Auswertungen mit den zugewiesenen
Geschäftsprozessen (Allweyer 2005).
Der Einsatz technischer Lösungen erlaubt die automatisierte Verarbeitung der
beschriebenen Teilschritte. Controlling-/Management-Cockpits stellen einen etablier-
ten Lösungsansatz dar, da sie es erlauben, die Datenverarbeitung und -auswertung zu
automatisieren. Darüber hinaus ermöglichen es Cockpits, Zusammenhänge aufzuzei-
gen und ein vernetztes System (bestehend aus Controlling, Prozessmanagement und
Organisation) zu etablieren (Konnopka 2008).
Das Beispiel in Abb. 14.9 zeigt ein Management-Cockpit und verdeutlicht die
Möglichkeiten, die sich durch den Einsatz technischer Komponenten ergeben.
Abb. 14.9 IT-gestütztes Prozesscontrolling mittels des ADOscore® Controlling-Cockpits

In tabellarischer Form wird es den Entscheidungsträgern ermöglicht, den aktuel-

len Prozessstatus zu erfassen. Die Gliederung erlaubt eine eindeutige Identifikation der
Zusammenhänge und Einflusskriterien. In Kapiteln gegliederte Detailansichten bieten
weiterführende sowie vertiefende Information und erlauben das Aufrufen und Erstellen
dynamischer, grafischer Auswertungen.
14.5.2 Techniken zur Prozessanalyse basierend auf Kennzahlen
Durch den vermehrten Einsatz von IT in Unternehmen aller Branchen ergibt sich, dass
Daten unterschiedlichster Art gesammelt und archiviert werden. In den meisten Fällen
werden diese Daten im Zuge spezifischer Prozesse erhoben und genutzt. Der Ansatz des
Process Mining betrachtet den Datenbestand einer Organisation als globales Ganzes auf
dessen Basis neue Information zur Unternehmung und einzelnen Prozessen gewonnen
werden soll. Analog dem Data Mining möchte man Potenziale erkennen und zur unter-
nehmerischen Weiterentwicklung nutzen (Remberg 2008).
Anhand standardisierter Kennzahlen und Zielwerte (beispielsweise betreffend des
Ressourceneinsatzes) können mit Hilfe der ABC-Analyse Schwerpunkte innerhalb der
Unternehmung definiert werden. Es gilt eine Priorisierung der Ziele und Prozesse zu
erarbeiten, die zur Strategieumsetzung erforderlich sind. Die Klassifikation erfolgt dabei
in drei Kriterien: A – erfolgskritisch; B – wichtig; C – geringe Bedeutung. Aufgrund
der Einstufung können seitens des Managements Vorgaben zur Bereitstellung von
Ressourcen und hinsichtlich des Controllings getroffen werden (Schneider et al. 2008).
Demnach sind erfolgskritische Ziele unter anderem einer häufigeren Prüfung zu unter-
ziehen als jene von geringer Bedeutung und deren Grenzwerte enger anzusetzen.
Dem weiteren Ausbau der Marktposition eines Unternehmens widmet sich der
Ansatz zur Analyse gemäß Process Intelligence, welcher auf der Kombination des
Wissens der Bereiche Business Intelligence und Prozessmanagement beruht. Im
Rahmen der Business Intelligence verwaltet und pflegt ein Unternehmen markt- und
wirtschaftsorientierte Kennzahlen sowie das Wissen über den Markt selbst. Das
Prozessmanagement einer Unternehmung kapselt die Leistungserbringung und somit
die Kernkompetenz (das Know-how) einer Unternehmung. Durch die gezielte Fusion
beider Management-Disziplinen können Potenziale frühzeitig erkannt und genutzt
werden. Beispielsweise verringert sich durch diese Kombination die Reaktionszeit auf
Marktveränderungen sowie die Produkteinführungszeit (time to market), wodurch die
Position des Unternehmens nachhaltig gestärkt werden kann.
14.5.3 Vorgehensmodell zur Prozesscontrolling-Einführung
Die Einführung eines ganzheitlichen Prozesscontrollings in einer Unternehmung erfor-

dert ein stringentes Vorgehen, dessen Ablauf bereits im Vorfeld definiert und terminiert
wird. Die Gliederung in Phasen erlaubt einen sequenziellen Aufbau sowie den spezifi-
schen Einsatz von Know-how und Kompetenzen. Abbildung 14.10 beschreibt ein exem-
plarisches Vorgehen, dessen Phasen nachstehend umrissen werden.
In Folge des Entscheids zur Einführung eines Prozesscontrollings gilt es, die benö-
tigten technischen Komponenten zu erheben. Oftmals wird zu Beginn auf vorhandene
technische Ressourcen, bspw. das Microsoft® Office®-Paket o. ä., zurückgegriffen, die
jedoch erhöhten Personaleinsatz und Qualitätssicherung erfordern. In einem ersten
Kick-off-Meeting, dem alle Stakeholder beiwohnen sollten, gilt es, die weiteren Phasen
zu definieren und erste Eckdaten zu erheben. Die Ergebnisse des Meetings sind im
Nachgang aufzubereiten und dienen als Grundlage für das weitere Vorgehen.
Im Folgenden müssen die Vision, Mission und Strategie auf Aktualität und Akzeptanz
geprüft werden, ebenso unter Berücksichtigung aktueller wirtschaftlicher Faktoren.
Basierend auf den Ergebnissen werden die kritischen Erfolgsfaktoren zur Umsetzung
Abb. 14.10 Vorgehensmodell

zur Prozesscontrolling- Phasen Arbeitspakete
Einführung
- Abstimmung mit IT -Dienstleistung
- Ausrollen der Komponenten
Vorbereitung
- Kick-off-Meeting und Vorgehensplanung
& Kick-off
- Aufbereitung der Inputs
- Involvieren aller Stakeholder
- Validierung von Vision, Mission & Strategie

Strategische - Ableiten kritischer Erfolgsfaktoren
Grundlagen - Abgleich mit derzeitiger Prozesslandschaft
- Erstellung der Strategiedokumentation
- Definition von Sichten & Perspektiven

Erstellung - Ableiten der Ziele
Kennzahlen - - Bestimmung der Abhängigkeiten
system - Definition der Kennzahlen
- Definition von Maßnahmen
- Prüfen der Datenverfügbarkeit

Kennzahlen - - Abbildung der Berechnungslogik
anbindung - Anbindung operativer Systeme
- Testlauf der Erhebung
- Anforderungsdefinition des Reportings &

Publikation
der Zielgruppen
& Verteilung
- Integration entsprechender Komponenten
Vorbereitung - Testbetrieb und Freigabe

operativer - Konzeption des Go -Live
Einsatz - Schulung
Abschluss - Abschlussbericht erstellen

& Go-Live - Abschlusspräsentation
erhoben und mit der aktuellen Prozesslandschaft abgeglichen. Sofern sich Abweichungen
ergeben, sind Korrekturen anzusetzen und die Phase zu wiederholen. Die Ergebnisse
sind in einer Strategiedokumentation festzuhalten und ein Zeitpunkt für ein neuerliches
Review ist festzulegen.
In Abstimmung mit den Stakeholdern werden Perspektiven und Sichten für das zu
definierende Kennzahlensystem erhoben, die die jeweiligen Rollen und Funktionen
abdecken. Dadurch soll den Involvierten ausschließlich die entscheidungsrelevante
Information zur Verfügung gestellt werden – so wenig wie möglich, so viel wie nötig.
Die zuvor erarbeiteten kritischen Erfolgsfaktoren werden gruppiert, zu Zielen aggregiert
und priorisiert. Anschließend sind die Abhängigkeiten der Ziele herauszuarbeiten unter
Berücksichtigung, dass diese Kette von Beginn bis zum Ende der Wertschöpfungskette
des Unternehmens zu gestalten ist. Pro Ziel sind im Anschluss Kennzahlen und erste
Maßnahmen zur Umsetzung festzusetzen.
Für die definierten Kennzahlen wird im Folgenden die Datenanbindung erhoben. Zu
diesem Zweck werden die Verfügbarkeit geprüft, etwaige Rechenlogik abgebildet und die
Quellsysteme direkt oder per Export angebunden. Sofern die Erhebung abgeschlossen
werden konnte, kann eine erste Aktualisierung erfolgen.
Die Auswertung der Ergebnisse bildet die Entscheidungsgrundlage des Prozess
controllings. Aus diesem Grunde ist eine adäquate Publikationsform zu definieren.
Oftmals orientiert sich diese an der jeweiligen Zielgruppe und umfasst Druckdokumente,
tabellarische Auswertungen, dynamische Cockpits oder Grafiken.
Nachdem die Komponenten in die Umgebung integriert wurden, ist das System in den
Testbetrieb zu überführen. Ziel der Testphase ist es, in einem definierten Prozessbereich
erste Erfahrungen und Rückmeldungen zu sammeln sowie nach Möglichkeit umzu-
setzen. Darüber hinaus wird versucht die Historie des Systems anzureichern, um den
Entscheidungsträgern von Beginn an eine adäquate Grundlage zur Verfügung zu stellen.
Nach Abschluss der ersten Tests wird der Übergang zum produktiven Betrieb abgestimmt.
Dies umfasst die Schulung sämtlicher involvierten Personen sowie erneute Kommunikation
der Zielsetzung und des Vorgehens aller Unternehmensbeteiligten. Zu diesem Zeitpunkt
sollte das System als stabil angesehen werden, da bei Änderungen (bspw. dem Austausch
einer Kennzahl) die Historie und somit die Entscheidungsgrundlage verloren geht.
Nachdem das System sämtlichen relevanten Bereichen der Unternehmung zur Verfügung
gestellt wurde, gilt es die Ergebnisse zu dokumentieren und den Auftraggebern zu präsen-
tieren. Im Speziellen sind darin die nächsten Schritte sowie die zu erwartenden Ergebnisse
anzuführen.
14.6 Erfolgsfaktoren des Prozesscontrollings
Um fortwährenden Erfolg sicherzustellen, ist es essenziell, dass sich eine Unternehmung

ihrer Umwelt und der dortigen Positionierung bewusst ist. Gemäß diesem Verständnis gilt
es ein aktives und präventives Prozesscontrolling aufzubauen, das zeitnahe Auswertungen
und Reaktionen auf Basis adäquater Grundlagen erlaubt. Um eine fundierte

Entscheidungsgrundlage aufzubauen und zu erhalten, bedarf es Kontinuität und Stabilität,
da ausschließlich dadurch Vergleichswerte, Historien und in weiterer Folge Prognosen
erstellt werden können. Im Rahmen des Prozesscontrollings gilt es zu beachten, dass
das Unternehmen in seiner Gesamtheit betrachtet wird. Als idealer Ausgangspunkt
hat sich die oberste Prozesslandkarte etabliert, da sie die Wertschöpfungskette des
Unternehmens repräsentiert und anhand der Strategie zu gestalten ist (vgl. Kap. 3).
Unternehmensstrategie, Prozesslandschaft und -controlling gilt es aufeinander abzu-
stimmen, sodass kongruente Ziele verfolgt und Synergien in der Unternehmung genutzt
werden können. Um die Akzeptanz und Unterstützung aller Organisationseinheiten
sicherzustellen, gilt es Prozesse, das Controlling sowie das gewünschte Vorgehensmodell
transparent und offen zugänglich zu kommunizieren. Controlling beschreibt die aktive
Steuerung anhand interner Information. Dementsprechend ist es essenziell, dass Ziele und
Kennzahlen mess- und vergleichbar gestaltet werden, um den Abgleich von Zielsetzung,
erbrachter Leistung und eingesetzter Ressourcen zu ermöglichen. Abschließend ist anzu-
führen, dass Ressourcen effektiv in der Unternehmung einzusetzen sind, weshalb abzu-
schätzen ist, in welchem Verhältnis der Aufwand zur Abbildung eines Kennzahlensystems
(oder ausgewählter Bestandteile) zur Informationsgewinnung steht.
Literatur
Allweyer T (2005) Geschäftsprozessmanagement: Strategie, Entwurf, Implementierung, Controlling,

W3L. Herdecke, Bochum
Bank for International Settlements (2010) Basel III: International framework for liquidity risk
measurement, standards and monitoring, Arbeitsbericht, Basel. http://www.bis.org/publ/bcb-
s188.pdf. Zugegriffen: 07. Jan 2013
Fiedler R (2013) Prozess-Controlling, Arbeitsbericht, Fachhochschule Würzburg-Schweinfurt. http://
www.projektcontroller.de/material/material/Prozess_Controlling.pdf. Zugegriffen: 07. Jan 2013
Hamel G (2009) Mission: Management 2.0. Harvard Business Manager, April 2009
Hutzler U (2004) Prozessorientierte Unternehmensorganisation zur Verbesserung der Performance.
Control Mag 29(5):405–411
International Organization for Standardization (ISO) (2005) Quality management systems --
Fundamentals and vocabulary, Arbeitsbericht, ISO 9000:2005, Genf. http://www.iso.org/iso/
home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=42180. Zugegriffen: 13. Jan 2013
Knuppertz T (2008) Herausforderung Prozesscontrolling - Prozessorientierung im Unternehmen
unterstützen. Control Mag 33(1):7–11
Konnopka A (2008) Management Cockpit: Digitaler Steuerknüppel. Control Mag 33(1):45–48
Remberg J (2008) Grundlagen des Process Mining. GRIN, Norderstedt
Schneider G, Geiger K-I, Scheuring J (2008) Prozess- und Qualitätsmanagement: Grundlagen der
Prozessgestaltung und Qualitätsverbesserung mit zahlreichen Beispielen, Repetitionsfragen
und Antworten, Compendio Bildungsmedien, Zürich
Teil VII
Integrierte Managementsysteme
Integration strategisches Management
und Prozessmanagement 15
Christian Lichka und Erik Guschlbauer
Zusammenfassung
Das strategische Management fokussiert vorrangig auf die Sicherung der langfris-
tigen Existenz sowie auf die Erfüllung von Wachstumszielen eines Unternehmens.
Das operative Management unterstützt dabei maßgeblich unter Zuhilfenahme
betriebswirtschaftlicher Steuerungsmechanismen. Über das Business Process
Management Systems-Rahmenwerk kann nun ein Bezug zum Prozessmanagement
hergestellt werden, wobei es konkreter Ansätze für die Integration dieser beiden
Managementansätze bedarf. Um eine Integration zu erreichen, gilt es, ein Zielsystem
zu erstellen, welches einen Bezug zwischen dem strategischen Management und dem
Prozessmanagement herstellt. Das Kapitel reißt hierfür zum einen den Ansatz des
zielorientierten Prozessmanagements an, der auf eigene, prozessuale Zielsysteme
fokussiert. Zum anderen wird der Schwerpunkt des Kapitels insbesondere auf die
Methode der Balanced Scorecard gelegt, welche als strategische Steuerungsmethode
auch als Steuerungselement des Prozessmanagements gelten kann – vor allem aus
einer integrativen Sicht. Ein detailliertes Beispiel rundet die Erläuterungen ab.
C. Lichka (*)
BOC Information Technologies Consulting GmbH, Zürcherstrasse 21, 8400 Winterthur, Schweiz
e-mail: christian.lichka@boc-group.com
E. Guschlbauer

296 C. Lichka und E. Guschlbauer
15.1 Strategisches Management
15.1.1 Definition und Abgrenzung
Um eine Integration des strategischen Managements und des Prozessmanagements näher

beleuchten zu können, ist eingangs eine Positionierung und Abgrenzung der Begriffe erfor-
derlich. Eine generelle Klassifizierung des Begriffs Management wurde auf sehr abstrak-
ter Ebene bspw. im 20. Jahrhundert von M. P. Follet erläutert und geprägt: „Management
ist die Kunst, mit anderen Leuten Dinge zu erledigen“ (übersetzt aus Crainer 2000). Eine
eingehendere Beleuchtung des Begriffs findet allerdings immer erst in den jeweiligen
Teildomänen, wie bspw. im Qualitätsmanagement oder Financial Management, statt.
Das strategische Management ist daher im ersten Schritt vom operativen Management
abzugrenzen. Als gute Grundlage zur Definition eignen sich Staudt et al. (1985) und
Steinmann und Schreyögg (1984). Nach ihnen ist das strategische Management eine
übergreifende Führungsaufgabe mit dem Ziel, den langfristigen Erfolg des Unternehmens
zu sichern. Es handelt sich ferner um ein Grundverständnis, das auf einer dynami-
schen Umwelt mit permanenten Veränderungen bzw. Diskontinuitäten aufbaut. Das
Kunstwort „dynax“ – eine Kombination aus „dynamisch“ und „komplex“ – beschreibt
diesen Umstand recht treffend. Somit stehen im strategischen Management die Sicherung
der langfristigen Existenz sowie die Erfüllung von Wachstumszielen im Vordergrund
(Macharzina 1995; Welge und Al-Laham 2001). Das operative Management hingegen
beschäftigt sich primär mit der Erfolgserzielung und Liquiditätssicherung aus betriebs-
wirtschaftlicher Sicht anhand selektiver Steuerungsgrößen (Gälweiler 1990).
Um nun weiter anhand einer Definition bzw. Abgrenzung voranzukommen, benötigt
es ein „Modell“, mit dessen Hilfe die beiden Ansätze des strategischen Managements und
des Prozessmanagements gut positioniert werden können. Klassische betriebswirtschaft-
liche Verfahren sind hierzu weniger geeignet, da – wie eingangs erwähnt – sehr stark auf
Teildisziplinen heruntergebrochen wird. Strategische Kreisläufe positionieren wiederum
den Bereich des Prozessmanagements selten konkret. Beispielhaft sei hier Venzin et al.
(2010) in Abb. 15.1 angeführt.
Einen weitaus pragmatischeren Ansatz stellt dazu das Business Process Management
Systems-Rahmenwerk (BPMS-Rahmenwerk) dar (vgl. (Karagiannis 1995; Junginger
et al. 1998; Bayer et al. 1999) sowie Abb. 15.2). In diesem Ansatz wird nicht nur das stra-
tegische Management positioniert (Strategic Decision Process), sondern auch ein Bezug
zum Prozessmanagement – insbesondere über die Phasen Re-Engineering Process und
Ressource Allocation Process – hergestellt.
Sowohl klassische strategische Kreisläufe, deren Steuerungsmechanismen entweder in
das Management von operativen Aufgaben (Strategieumsetzung und Leistungskontrolle
bei Venzin et al. (2010)) oder in die Reflexion oder Adaption der strategischen Vorgaben
münden, als auch operative Managementvorgänge werden hier durch zwei Kreisläufe
(vgl. zwei Rückläufe aus dem Performance Evaluation Process in Abb. 15.2) in Einklang
gebracht.
15 Integration strategisches Management und Prozessmanagement 297
Entwicklung
einer Gesamt-
unternehmens-
strategie
Analyse des
Marktes Entwicklung Entwicklung
Initiierung des einer Vision einer
Strategie-
Strategie- und von Geschäfts-
umsetzung
prozesses Langfrist- bereichs-
Analyse der zielen strategie
Firma
Entwicklung
von
funktionalen
Strategien
Leistungs-
kontrolle
Abb. 15.1 Strategischer Management-Kreislauf (in Anlehnung an Venzin et al. 2010)
Abb. 15.2 Regelkreissystem

Strategic Decision
des BPMS-Rahmenwerks
Process
(vgl. dazu Karagiannis 1995;
Junginger et al. 1998; Bayer
et al. 1999)
Re-Engineering
Process
Performance
Evaluation Process
Ressource Allocation
Process
Workflow
Process
Kurz zusammengefasst beinhaltet der Strategic Decision Process alle jene Vorgaben
und Rahmenbedingungen, die für den langfristigen, strategischen Betrieb eines
Unternehmens notwendig sind. Der Re-Engineering Process deckt die Gestaltung
der Vorgehensweisen zur Umsetzung dieser Ziele ab. Insbesondere in diesem Bereich
kann das Prozessmanagement gut positioniert werden. Ressource Allocation ist mit
der vorhergehenden Phase eng verknüpft, da dabei die notwendigen Ressourcen (IT,
Personal etc.) zur Umsetzung der Vorgehensweisen bereitgestellt werden müssen. Die
nachfolgende Ausführung (Workflow Process) sowie die Evaluation der Ergebnisse
(Performance Evaluation) schließen den Kreislauf ab. Vergleichbar ist dies mit dem
PDCA-Zyklus (vgl. Abschn. 2.3), wobei in BPMS spezifischer auf Unternehmens
kreisläufe eingegangen wird.
15.1.2 „Uniqueness“ ist der Schlüssel
Auf eine sehr einfache und anschauliche Art und Weise kann mithilfe von Mintzberg
(1978) und Porter (1996) abgeleitet werden, dass ein „Pattern in a stream of decisions“
die strategische Führung ausmacht. Porter detailliert weiter, indem er auf ein „unique
set of factors“ abstellt, welches die nachhaltige Wettbewerbsfähigkeit sicherstellt. Die
Aufgabe von Managementmethoden ist es nun, dieses „Pattern“ – also ein transparentes
Entscheidungsrahmenwerk – aufzuzeigen und allen verständlich zu machen (und somit
zu einem „intended set“ (of factors) zu konvertieren). Die operative Umsetzung muss
sicherstellen, dass die Festigkeit und Länge der Wertschöpfungskette eine möglichst
hohe kompetitive Wettbewerbsfähigkeit ermöglicht.
Für die Integration des strategischen Managements und des Prozessmanagements
lässt sich dementsprechend ableiten, dass
1. das Prozessmanagement eine Methode zur Sicherstellung der Ausgestaltung und

Umsetzung der strategischen Vorgaben eines Unternehmens ist. Dies kann dadurch
erreicht werden, dass die Prozesse zur Erbringung der Unternehmensleistung direkt
auf die strategischen Vorgaben abgestellt werden. Hierbei positioniert sich das
Prozessmanagement mit einem eher operativen Aspekt. Beispiele wären strategische
Compliance-Anforderungen, die direkt auf die relevanten Prozesse projiziert werden
und von der Prozessorganisation umgesetzt werden müssen.
2. das Prozessmanagement selbst strategische Vorgaben (aus dem strategischen Kreislauf
„Performance Evaluation“ - „Strategic Decision“ im BPMS-Rahmenwerk, vgl. Abb. 15.2)
an die Prozessorganisation macht. Dies können bspw. Rahmenbedingungen für die
Ausprägung von Rollen, die Änderung und Freigabe von Prozessabläufen oder Pro
zessaudits sein. Zumeist handelt es sich hierbei um methodische Vorgaben.
Die Balanced Scorecard (Kaplan und Norton 1992, 1996) kann als ein Vertreter eines strate-
gischen Managements sehr gut zum Erzeugen dieses „Pattern“ (Entscheidungsrahmenwerks)
eingesetzt werden, wohingegen das Prozessmanagement (bspw. in der Ausprägung von ISO-
Qualitätsmanagement) für die Nachhaltung und Kommunikation der Wertschöpfungskette
zuständig ist (vgl. „unique set of factors“, das durch Aufzeigen und Kommunikation bzw.
Erläuterung zu einem „intended set“ (of factors) wird).
15.2 Prozessmanagement: Das Fundament des strategischen

Managements
Entsprechend der gerade vorgestellten Platzierung kann das Prozessmanagement als

„Umsetzungsarm“ zur Steuerung von taktischen und operativen Vorgaben gesehen werden.
Junginger et al. (2004) liefern hier eine gute Übersicht, um dies besser erläutern zu können
(vgl. Abb. 15.3).
P1 P3
Strategic Level
(Process Scorecard) P2 Pn …
1:n Aggregation
…
Tactical Level
(Process Types)
Aggregation of Aggregation of Aggregation of
Instances of Instances of Instances of
Process Type 1 Process Type 2 Process Type n
1:n Aggregation
… … …
Operational Level …
(Process Instances)
…
Instances of Instances of Instances of

Process Type 1 Process Type 2 Process Type n
1:1 Mapping
Runtime Environment
(Execution Data) Data Data Data Data
Source 1 Source 2 Source 3 Source n
Abb. 15.3 Ebenen der Prozesssteuerung (Junginger et al. 2004)

Abbildung 15.3 veranschaulicht, wie einzelne Prozessvorgaben (bspw. qualitative

oder quantitative Ziele) – hier im Rahmen einer Prozess-Scorecard aufgebaut – in die
Prozessorganisation heruntergebrochen werden. Dies erfolgt im ersten Schritt auf tak-
tischer Ebene für die einzelnen Prozesse. Es handelt sich dabei allerdings nicht um die
Prozessinstanzen (d. h. nicht um den speziellen Einkaufsprozess des Herrn Müller), son-
dern nur um den dazugehörigen Prozesstyp (den „allgemeinen“ Einkaufsprozess). Auf
dieser Ebene ist das klassische Prozessmanagement aus europäischer Sicht angesiedelt,
d. h. hier sind Themen, wie Prozessabbildung, Definition von Arbeitsanweisungen etc.,
einzuordnen.
Prozessmanagement im amerikanischen oder anglo-amerikanischen Verständnis zielt
zumeist auf die Automatisierung von Prozessen, d. h. im Wesentlichen auf die Steuerung
von Instanzen ab (Stähler et al. 2009). Dies wird in Abb. 15.3 auf operationeller Ebene
durch die Prozessinstanzen verdeutlicht.
Unterstellt man nun, dass auf operationeller Ebene alle Methoden- und
Steuerungsthemen des klassischen Workflow-Managements sowie auf taktischer Ebene
das klassische Prozessmanagement, wie Prozessdokumentation, -optimierung sowie
-umsetzung und -controlling, angesiedelt sind, so werden (nur) auf oberster – strategi-
scher – Ebene Berührungspunkte zwischen dem strategischen Management und dem
Prozessmanagement ersichtlich (Lichka 2005).
Daraus ergibt sich unmittelbar die Frage, nach welcher Methode diese Schnittmenge
strukturiert werden kann. Im Wesentlichen handelt es sich hier um das Herunterbrechen
von Zielvorgaben in die Prozessorganisation.
Das klassische Prozessmanagement kennt vor allem das Controlling und die
Optimierung der Prozesse aus „eigenem Antrieb“ heraus, wie bspw. das Prozess-
Performance-Management, welches auf die Verbesserung der aktuellen Leistungszahlen
von Prozessen abstellt (zur Mühlen 2004). Aus technischer Sicht stellen sich hierzu auf
einen Schlag diverse Fragen, die gelöst werden müssen (bspw. wie die Datenerhebung
von Prozesskennzahlen erfolgen soll oder welche Audit-Trails angebunden wer-
den können). Diese Herausforderungen verschlingen oft signifikante Ressourcen in
der Umsetzung und bergen somit die Gefahr, den Bewegungsspielraum für andere
Steuerungsverfahren aufgrund von Ressourcenverknappung einzuschränken oder sogar
zu verhindern. Aus diesem Grund ist es ratsam, vorab die betriebswirtschaftlichen
Voraussetzungen zur Steuerung von Prozessen zu beleuchten.
Ein gewisses Gegengewicht zu dieser Steuerung nach reinen Performance-Indikatoren
stellt in den letzten Jahren die Steuerung von Maturity Levels im Prozessmanagement
dar. Als Beispiele gelten Capability Maturity Model Integration (CMMI) (CMMI
Institute and Clearmodel 2013) oder das Maturity Model nach COBIT (Pederiva 2003).
Aufgrund der Möglichkeit, in den Maturity Levels auch weiche Faktoren zu inkludie-
ren, eröffnen sich schneller und kostengünstiger umsetzbare Performance-Management-
Szenarien, die den aktuellen Bedarf an Prozessoptimierung besser adressieren als rein
workflowbasierte Verfahren.
Beispiele hierzu sind nicht nur die Messung von Prozessen nach Durchlaufzeiten,
Prozesskosten, Personalkapazitäten o. ä., sondern auch die Definition einzelner
Maturity-Dimensionen, wie Dokumentation, Kommunikation oder Management. In
jeder dieser Dimensionen werden den Prozessen oder Prozessgruppen unterschiedliche
Maturity-Vorgaben gesetzt.
Allen bisher genannten Verfahren ist jedoch weiterhin eigen, dass die Steuerung
bzw. die Zielvorgaben zumeist aus dem Kontext der Prozessorganisation, d. h. aus
dem eigenen Kontext, heraus erfolgen und nur sehr selten sauber aus dem strategi-
schen Management übergeleitet werden. Integration würde in diesem Zusammenhang
bedeuten, sowohl eigene (prozessgetriebene) als auch unternehmensweite (strategische)
Vorgaben zu integrieren und zu harmonisieren.
15.3 Methoden zur Integration
Grundsätzlich bedarf es zur Integration des strategischen Managements und des

Prozessmanagements keiner eigenen Methode, um eine saubere Integration herzustellen,
sondern lediglich der Erstellung eines Zielsystems, das die Vorgaben zwischen strategi-
schem Management und Prozessmanagement koppelt. Dies kann aus dem Kontext des
Prozessmanagements heraus erfolgen und bspw. mittels „Management by Objectives“
gekoppelt sein oder auf Basis eigener, prozessualer Zielsysteme erfolgen (Stichwort: ziel-
orientiertes Prozessmanagement, vgl. Kap. 4). Alternativ dazu, jedoch in vielen Fällen
umfassender, kann eine strategische Steuerungsmethode ausgewählt werden, die auch als
Steuerungselement des Prozessmanagements dienen kann. Hierzu eignet sich bspw. die
Balanced Scorecard (Kaplan und Norton 1992, 1996).
15.3.1 Balanced Scorecard
Die Balanced Scorecard (BSC) stellt einen modernen Vertreter des Performance-
Managements dar, wobei sie im Vergleich zu anderen Verfahren erstaunlich viel Gewicht
in methodische und weniger datenlastige Umsetzungsverfahren legt.
Die BSC geht von einer ausgeglichenen Betrachtung von Zielen, Kennzahlen und
Maßnahmen in unterschiedlichen Unternehmensperspektiven aus. Diese Perspektiven
sowie deren Inhalte sind direkt aus der Strategie abgeleitet und stellen das zentrale,
strategische Steuerungsinstrument dar. Die klassischen Perspektiven sind Finanzen,
Kunden, Prozesse sowie Lernen & Entwicklung (vgl. Abb. 15.4). Um eine Übersicht zu
gewährleisten, schafft die BSC Komplexitätsreduktion durch die Vorgabe, nicht mehr als
10–15 Ziele und 20–25 Kennzahlen zu verwenden. Zwischen den Perspektiven werden
zeitliche Abhängigkeiten dargestellt. So hat eine Steuerung in der Perspektive Lernen &
1
Finanzen
Maßnahmen
Kennzahlen
Vorgaben
Wie treten wir
ggü. Teilhabern
Ziele
auf, um
finanziellen
Erfolg zu
haben?
2 3
Kunden Interne GPs
Maßnahmen
Maßnahmen
Kennzahlen
Kennzahlen
Vorgaben
Vorgaben
Wie treten wir In welchen GPs
ggü. unseren Vision, müssen wir die
Ziele
Ziele
Kunden auf, Besten sein,
Strategie
um unsere um Teilhaber
Vision zu und Kunden zu
verwirklichen? befriedigen?
4
Lernen & Entw.
Maßnahmen
Kennzahlen
Vorgaben
Wie fördern wir

Veränderungs-
Ziele
u. Wachstums-
potenziale, um
die Vision zu
verwirklichen? GP… Geschäftsprozess
Abb. 15.4 Balanced Scorecard: Perspektiven (in Anlehnung an Gabler Verlag 2013)
Entwicklung zukunftsorientierten Charakter, dessen Auswirkungen sich im Folgenden

auf Prozesse, Kunden und schlussendlich Finanzen niederschlagen können. Es wird
somit versucht, von einer vergangenheitsbezogenen Betrachtung auf eine zukunfts-
orientierte Steuerung umzustellen und Stellgrößen zu finden, um den zukünftigen
Unternehmenserfolg frühzeitig beeinflussen zu können.
Die BSC nur als reines Steuerungsmedium zu sehen, fasst hingegen zu kurz. Kaplan
et al. (1992) streichen fünf Kernaufgaben des Verfahrens heraus:
• Operationalisierungsfunktion (Strategic Alignment)

Die BSC ermöglicht es, einen langfristigen, strategischen Horizont auf operative
Tätigkeiten und Steuerungsaspekte herunterzubrechen. Sie transformiert die Strategie
in eine Menge aus Zielen, Kennzahlen und Maßnahmen.
• Fokussierungsfunktion
Die Steuerungstätigkeit der Führungskräfte wird auf eine wesentliche Menge an
Zielen fokussiert. Insofern werden die Steuerung harmonisiert und Reibungsverluste
durch unterschiedliche Steuerungsauffassungen reduziert.
• Kommunikationsfunktion
Durch eine sehr plakative Umsetzung der BSC im Rahmen von Ursache-Wirkungs-
Beziehungen kann das strategische Konzept leicht transportiert und im Unternehmen
kommuniziert werden. Dies fördert die Identifikation mit dem Unternehmen sowie
mit den relevanten Zielen.
• Integrationsfunktion
Durch die Betrachtung aller wesentlichen Bereiche eines Unternehmens wird eine
Steuerungsintegration geschaffen. Darüber hinaus werden hierarchisierte Einheiten
durch ein Herunterbrechen der BSC in den Steuerungsprozess stringent inkludiert.
• Reduktionsfunktion
„Von Daten zu Informationen“: Unter dieser Parole kann der Gedanke der BSC, durch
Fokussierung auf eine begrenzte Menge an Steuerungsgrößen Komplexitätsreduktion
zu erzielen, zusammengefasst werden.
Da die Prozesse in der Balanced Scorecard-Methode bereits unmittelbar als Perspektive

vorgesehen sind, ist die Integration von strategischem Management und Prozess
management ohne großen Aufwand möglich. Schwerpunktmäßig werden in der
Perspektive der Prozesse (ggf. auch in anderen Perspektiven wie bspw. „Finanzen“) die
Ziele für das Prozessmanagement definiert und in die Prozessorganisation herunterge-
brochen. Im Gegenzug ergeben sich die Zielerreichungsgrade mittels Key Performance
Indicators (KPI oder wesentliche Kennzahlen) oder aggregierter Erfüllungsgrade aus
den Prozessen bzw. der Prozessorganisation. Abbildung 15.5 gibt hierzu einen näheren
Eindruck.
Verbindet man nun die Erkenntnisse aus Abschn. 15.2 mit denjenigen der Balanced
Scorecard, ergeben sich im Sinne eines durchgehenden Performance-Managements fol-
gende Aspekte:
• Das Zielsystem der BSC wird direkt in die Prozessorganisation heruntergebrochen.

• Alternativ oder zusätzlich erfolgt eine Detaillierung der Ziele der BSC durch die
Prozessverantwortlichen für die ihnen jeweils zugewiesenen Prozesse.
• Das Prozessmanagement stellt den fachlichen und organisationsbezogenen Unterbau
zu den formulierten Zielen dar.
• Die Kennzahlen können zwar, müssen aber nicht, aus dem Prozessmanagement
bereitgestellt werden.
Abbildung 15.5 zeigt den Mehrwert eines solchen Szenarios anschaulich. Aus BSC-Sicht
wurde (als Ausschnitt) ein Ziel der Kundenzufriedenheit mit mehreren Kennzahlen
definiert. Der KPI „avg. number of complaints“ berechnet sich aus der Anzahl der
Bestellungen sowie der Anzahl der Beschwerden. Die Datenquellen der beiden
Kennzahlen sind jeweils die operativen Systeme. Parallel dazu existiert eine Verbindung
Achieving Customer Satisfaction

(strategic goal)
Strategic
# complaints …
(avg)
div
Tactical
# complaints
# orders
Business
Business -driven
Operational
Working Instruction
Data-driven
Drill Down
Drill Down
Transformation Order Processing
Accounting
Workflow Principles
Abb. 15.5 Zielsystem-Integration Prozessmanagement und BSC (in Anlehnung an Junginger

et al. 2004, S. 78)
von Kennzahlen (in diesem Beispiel die „Orders“) oder Zielen mit den dahinterliegenden
Prozessen (in Abb. 15.5 schematisch die Prozessdokumentation).
Somit wird Mehrwert in mehreren Dimensionen erzielt:
• Aus Sicht des Prozesses sind die aus der BSC zugewiesenen Kennzahlen (und Ziele)
maßgeblich. Der direkte Zusammenhang ist klar ersichtlich.
• Aus Sicht der Interpretation der Kennzahlen (aus der BSC) stehen dem Anwender
nicht nur die datentechnische Drill down-Sicht (klassischerweise ein OLAP oder
Daten-Drill) zur Verfügung, sondern auch ein fachlich-orientierter Drill down (vgl.
die Verbindung mit den Working Instructions und den Accounting Principles).
Hierdurch können bspw. Prozessveränderungen hinterfragt und Zusammenhänge zu
Kennzahlenentwicklungen aufgezeigt werden.
15.3.2 Zielorientiertes Prozessmanagement
Eine weitere Vorgehensweise zur Integration des strategischen Managements und des
Prozessmanagements stellt das zielorientierte Prozessmanagement dar. In Kap. 4 fin-
det sich bereits eine ausführliche Auseinandersetzung mit dem Thema. Zum einen
handelt es sich dabei um die Erweiterung des klassischen Prozessmanagements um die
Definition eines Zielsystems für das Prozessmanagement. Zum anderen beinhaltet es
die Integration des Zielsystems (d. h. folglich die laufende Messung und Steuerung) in
die Prozessorganisation.
Im Vergleich zur BSC handelt es sich dabei um die Definition eines Zielsystems, das
sowohl auf das Herunterbrechen von Zielen aus einem übergeordneten – strategischen –
Kontext als auch auf eigene Prozessziele spezialisiert ist. Im Unterschied zur BSC, die
klare Vorgaben hinsichtlich Struktur und Vorgehensweise der Methode vorsieht, han-
delt es sich dabei eher um die Erweiterung des Prozessmanagements um klassische
Management by Objectives-Überlegungen.
Abbildung 15.6 stellt den Kreislauf der Methode dar, der im Wesentlichen aus der
Definition, der Ausführung sowie der Kontrolle der Vorgaben besteht. Darüber hin-
aus wird in ablauforganisationsbezogene sowie aufbauorganisationsbezogene Ziele
Strategie Aufbauorganisations-
bezogene Ziele
Reporting und Controlling Management
Ablauforganisations-
Unternehmenssteuerung bezogene Ziele
Definition
Kontrolle
Ausführung
Prozessindividuelle
Ziele und Maßnahmen
Unternehmensbezogene,
prozessrelevante
Unternehmensbezogene,
aufbauorganisationsbezogene
Abb. 15.6 Aufbau eines Zielsystems nach dem Ansatz des zielorientierten Prozessmanagements
unterschieden. Aus dem Kontext der BSC wurde – neben der Steuerung von Zielen und
Kennzahlen – die Fokussierung auf Maßnahmen einbezogen.
15.4 „Perfect World“: Wie die Integration aussehen könnte
Eine Integration, wie sie aus methodischer oder theoretischer Sicht machbar wäre, ist
im Realeinsatz die absolute Seltenheit. Hierzu tragen einige Faktoren bei. Einerseits
würde eine solche Integration einen hohen Reifegrad der Organisation in methodi-
scher Umsetzung und Steuerung prozessualer und strategischer Themen voraussetzen.
Darüber hinaus müsste das Management den Mehrwert der Integration sowie der damit
einhergehenden organisatorischen Matrixstruktur die notwendige Relevanz einräumen
und mit der daraus resultierenden Komplexität umgehen (wollen).
Im Rahmen dieses Kapitels sei jedoch ein Szenario dargestellt, das den Mehrwert
der Methodenintegration anhand eines Beispiels aufzeigen soll. Zu diesem Zweck dient
eine exemplarische Umsetzung mit den Softwareprodukten ADOscore® zur Balanced
Scorecard-Steuerung sowie ADONIS® zur Prozessdokumentation.
Anhand sechs einzelner Schritte wird die Integration aus Sicht der Interpretation einer
negativen Abweichung einer Kennzahl detailliert. Startpunkt (vgl. Abb. 15.7) ist eine im
Kontext der BSC-Steuerung identifizierte Abweichung der Kennzahl „Durchlaufzeit beleg-
gebundene Überweisung“.
Balanced Scorecard
Die Kennzahl „Durchlaufzeit (DLZ) beleggebundene Überweisung“ ist rot.
Abb. 15.7 Schritt 1 des Integrationsbeispiels: Negative Abweichung einer Kennzahl wird erkannt
BSC-Controlling
Starker Anstieg der Kennzahl „Durchlaufzeit (DLZ) beleggebundene Überweisung“ wird
festgestellt.
2
Abb. 15.8 Schritt 2 des Integrationsbeispiels: Allgemeiner Grund für die Abweichung wird festgestellt
Prozessanalyse
Durchlaufzeit ist abhängig von der Kennzahl „Anzahl der Unterschriften, die nicht in Ordnung
gewesen sind“.
3
Identifikation des IT-Services

„Risk Rating“ als mögliche Ursache
für den Anstieg.
Abb. 15.9 Schritt 3 des Integrationsbeispiels: Mögliche Ursache für Anstieg der Durchlaufzeit
wird identifiziert
Prozesscontrolling
Die Ursache für den Anstieg der Durchlaufzeit liegt möglicherweise im Anstieg dieser Kennzahl.
Abb. 15.10 Schritt 4 des Integrationsbeispiels: Anstieg der Durchlaufzeit ist im Cockpit ersichtlich
IT-Serviceanalyse
Identifikation von Kennzahlen, die dem IT-Service „Risk Rating“ zugeordnet sind.
Abb. 15.11 Schritt 5 des Integrationsbeispiels: Zuordnung der identifizierten Kennzahl ist nach-
vollziehbar
IT-Servicecontrolling
Verzögerung liegt auch an der schlechten Performance des IT-Services „Risk Rating“. Es sind
entsprechende Maßnahmen zur operativen Ursachenabklärung und Behebung zu treffen.
6
Abb. 15.12 Schritt 6 des Integrationsbeispiels: Eine weitere mögliche Ursache für die Verzöge-
rung ist im Cockpit ersichtlich
Schritt 2 (vgl. Abb. 15.8) zeigt im Rahmen des BSC-Controllings den plötzlichen
Anstieg der Kennzahl in den roten Bereich.
Aufgrund der Verbindung der Kennzahlen zu den zugewiesenen Prozessen können
die direkt involvierten Prozesse sofort identifiziert und betrachtet werden. Dies betrifft
sowohl die fachliche Ablaufdarstellung (vgl. Abb. 15.9) als auch die zum jeweiligen
Prozess gehörigen Detail-Cockpits (vgl. Abb. 15.10). Der Zusammenhang möglicher
fachlicher Prozessänderungen (anhand der Prozessdokumentation ersichtlich) kann im
Kontext der Kennzahlenentwicklungen des Prozess-Cockpits evaluiert werden. In die-
sem Beispiel wird als negativer Treiber eine operative Prozesskennzahl gefunden.
Die identifizierte Kennzahl ist aus dem Bereich des IT Risk-Ratings, welche in der
Prozess- und Servicedokumentation (vgl. Abb. 15.11) des IT-Bereichs zu finden ist.
Die Identifikation der Fehlerquelle (vgl. Abb. 15.12) ist die Basis für eine geeignete
Maßnahmendefinition. Sinnvollerweise erfolgt deren Controlling im Einklang mit den
hier aufgeführten Steuerungsebenen. Dies kann bspw. IT-technisch unterstützt werden,
indem die Steuerungs-Cockpits der einzelnen Ebenen (vgl. die Schritte 2, 4 und 6) nicht
nur die aktuellen Ziele und Kennzahlen, sondern auch Maßnahmen beinhalten.
Anhand des aufgezeigten Szenarios wird ersichtlich, dass die Integration des strate-
gischen Managements und des Prozessmanagements eine sehr starke Vernetzung der
einzelnen Themen voraussetzt. IT-gestützt und auch fachlich hat es sich erfahrungsge-
mäß als vorteilhafter erwiesen, dabei mit sauberen Schnittstellen – bspw. zwischen BSC,
Prozessmanagement und Unternehmensarchitektur-Management – zu arbeiten, als

eine weitreichende methodische und technische Integration zu forcieren. Aufgrund der
dadurch entstehenden Größe und Vernetzung des Szenarios könnte ansonsten keinerlei
Flexibilität aufrechterhalten werden.
15.5 Fazit
Zusammenfassend sei weniger auf die Methodenintegration, deren Herausforderungen und

Chancen verwiesen, sondern eher auf die organisatorisch-kulturelle Sicht. Sowohl fachlich
als auch methodisch und technisch existieren ausreichend Möglichkeiten, um eine sinnvolle
Integration des strategischen Managements und des Prozessmanagements herzustellen.
Ein Schiff erreicht sein (langfristiges) Ziel viel eher, wenn dieses dem Kapitän nicht
nur bekannt ist, sondern die Kommunikation zur Brücke auch gut funktioniert und der
Ablauf der Steuerung des Maschinenraums auch darauf abgestimmt ist. Somit bedeutet
eine Integration des strategischen Managements und des Prozessmanagements aus orga-
nisatorischer Sicht auch eine Integration der Steuerungsverfahren und damit einherge-
hend die Schaffung von erhöhter Transparenz. Sowohl das Prozessmanagement als auch
die BSC als ein wesentlicher Vertreter strategischer Steuerungsverfahren leben von einer
aktiven und offenen Unternehmens- und Steuerungskultur. Zusammenhänge zu verste-
hen und zu verbessern ist eben nur umsetzbar, wenn die Zusammenhänge auch allen
bekannt sind.
Um dies zu schaffen, ist ein Big Bang-Vorgehen nur selten sinnvoll – vielmehr soll-
ten die Schaffung von Management-Awareness sowie das Vorantreiben der Integration
auf Basis selektiver, nach Optimierungspotenzialen priorisierter Bereiche im Fokus ste-
hen. Auf diese Weise können einerseits Quick Wins erzielt werden. Andererseits hat die
Organisation ausreichend Zeit, sich an die Änderungen anzupassen. Eine parallel ablau-
fende, saubere IT-Umsetzung fördert dazu die Nutzbarkeit und sukzessive die Nutzung
der Steuerungselemente (Ziele, KPI, Maßnahmen) auf allen Ebenen.
Literatur

Crainer S (2000) The Management Century: A Critical Review of 20th Century Thought and
Practice. Jossey-Bass, San Francisco
Gabler Verlag (2013) Gabler Wirtschaftslexikon, Stichwort: Balanced Scorecard. http://
wirtschaftslexikon.gabler.de/Archiv/1856/balanced-scorecard-v7.html. Zugegriffen: 07. Jan 2013
Gälweiler A (1990) Strategische Unternehmensführung, 2. Aufl. Campus, Frankfurt, New York

Junginger S, Kühn H, Bartl F, Herbst J (1998) Evaluation of Financial Service Organizations
with the ADONIS* Simulation Agents. In: Proceedings of the 10th European Simulation
Symposium (ESS’98), Society for Computer Simulation (SCS), Nottingham
Junginger S, Kühn H, Bayer F, Karagiannis D (2004) Workflow-based Business Monitoring. In:
Fischer L (Hrsg) Workflow Handbook 2004. Future Strategies, S 65–80
Kaplan R-S, Norton D-P (1992) The Balanced Scorecard – Measures that Drive Performance. Harv
Bus Rev 70(1):71–79
Kaplan R-S, Norton D-P (1996) The Balanced Scorecard: Translating Strategy into Action.
Harvard Business Review Press, Boston
Lichka C (2005) Strategic Monitoring and Alignment to Achieve Business Process Best Practices.
In: Proceedings of the 16th International Conference and Workshop on Database and Expert
Systems Applications (DEXA 2005). IEEE Computer Society, Copenhagen, S 914–918
Macharzina K (1995) Unternehmensführung: Das internationale Managementwissen, 2. Aufl.
Gabler, Wiesbaden
Mintzberg H (1978) Patterns in Strategy Formation. Manag Sci 24(9):934–948
Pederiva A (2003) The COBIT Maturity Model in a Vendor Evaluation Case. Info Syst Control J 3
Porter M-E (1996) Crafting Strategy. Harv Bus Rev (Nov–Dec)
Stähler D, Meier I, Scheuch R, Schmülling C, Somssich D (2009) Enterprise Architecture, BPM
und SOA für Business-Analysten: Leitfaden für die Praxis. Hanser, München
Staudt E, Groeters U, Hafkesbrink J, Treichel H-R (1985) Kennzahlen und Kennzahlensysteme.
Erich Schmidt, Berlin
Steinmann H, Schreyögg G (1984) Strategische Kontrolle: Empirische Ergebnisse und theoretische
Konzeption, Arbeitsbericht, 25, Universität Erlangen-Nürnberg; Betriebswirtschaftslehre und
Unternehmensführung, Nürnberg
Venzin M, Rasner C, Mahnke V (2010) Der Strategieprozess: Praxishandbuch zur Umsetzung im
Unternehmen, 2. Aufl. Campus, Frankfurt, New York
Welge M-K, Al-Laham A (2001) Strategisches Management: Grundlagen, Prozess, Implementierung,
3. Aufl. Gabler, Wiesbaden
zur Mühlen M (2004) Workflow-based Process Controlling: Foundation, Design, and Application
of Workflow-driven Process Information Systems. Logos, Berlin
Integration von Prozessmanagement und
Unternehmensarchitektur-Management – 16
Konzepte und Vorgehensweisen zum
Business IT Alignment
Christoph Moser und Lutz Kirchner
Zusammenfassung
Unternehmensarchitektur-Management (engl. Enterprise Architecture Management,
EAM) befasst sich mit dem ganzheitlichen Management aller relevanten Elemente
einer Unternehmensarchitektur sowohl auf Seiten des Business als auch der IT. Durch
die integrative Betrachtung von Prozessmanagement und Unternehmensarchitektur-
Management entsteht eine solide Basis für das Business IT Alignment. Die im
Prozessmanagement konzipierten Prozesse werden als Teil der Geschäftsarchitektur in die
Unternehmensarchitektur eingebettet und mit der IT-Landschaft verknüpft. Die dadurch
gewonnene Transparenz bietet eine gemeinsame Planungsbasis für die Fachbereiche und
IT-Abteilungen. Anstehende Änderungen der Architektur werden nicht isoliert betrach-
tet, sondern gemeinsam geplant und umgesetzt. Das vorliegende Kapitel gibt einen ein-
führenden Überblick über das Unternehmensarchitektur-Management. Im Vordergrund
stehen jene Konzepte und Verfahren, die eine möglichst nahtlose Integration der
Geschäftsarchitektur – repräsentiert durch die Geschäftsprozesse – und der IT-Landschaft
ermöglichen. Den konzeptuellen Rahmen bildet dabei mit TOGAF® ein international
anerkannter Standard für das Unternehmensarchitektur-Management. Die theoretischen
Konzepte werden anhand eines praktischen Beispiels aus der Luftfahrtbranche erläutert.
C. Moser (*)
e-mail: christoph.moser@boc-eu.com
L. Kirchner

314 C. Moser und L. Kirchner
16.1 Motivation und Grundlagen
Die effektive und effiziente Umsetzung geschäftlicher Anforderungen durch

Informationstechnologie (IT) stellt die zentrale Herausforderung im Rahmen des IT-
Managements dar. Durch die integrierte Anwendung von Methoden des Prozessma
nagements und des Unternehmensarchitektur-Managements (engl. Enterprise Architecture
Management, EAM) kann diese Herausforderung gemeistert und somit die Unterneh
mensziele erfolgreich umgesetzt werden. Die Ausgangsbasis ist die Geschäftsstrategie des
Unternehmens. Geschäftliche Anforderungen werden in Abhängigkeit der Unterneh
mensstrategie bewertet und konsequent auf allen Ebenen der Unternehmens architektur
definiert und implementiert. Dadurch wird sichergestellt, dass die oftmals herrschende
Kommunikationslücke zwischen den Geschäftsbereichen eines Unternehmens und den IT-
Abteilungen geschlossen wird. Es gilt, eine gemeinsame und konsistente Planungsbasis zu
schaffen, abzustimmen und permanent weiterzuentwickeln: die Unternehmensarchitektur
(Keller 2012).
Definition
Im Kern beschreibt die Unternehmensarchitektur das Zusammenspiel von Elementen
der geschäftlichen Tätigkeit des Unternehmens und der Informationstechnologie.
Unternehmensarchitektur-Management liefert Entscheidungsgrundlagen zur Weiterent
wicklung des Unternehmens; oftmals in Form von sogenannten Bebauungsplänen.
Ein typischer Bebauungsplan beinhaltet und visualisiert beispielsweise Anwendungen im

Kontext von Geschäftsprozessen und Organisationseinheiten, sodass daraus abgeleitet werden
kann, welche Anwendungen welche Prozesse in welchen Organisationseinheiten unterstützen.
Die Stärken des Unternehmensarchitektur-Managements zeigen sich dabei im inhä-
rent ganzheitlichen Ansatz. Durch die integrative Betrachtung des Prozessmanagements
und des IT-Architekturmanagements entsteht eine solide Basis für das Business
IT Alignment (Moser et al. 2010). Von Beginn an ist sicherzustellen, dass die im
Rahmen des Prozessmanagements konzipierten und dokumentierten Prozesse effek-
tiv und effizient durch Informationstechnologie umgesetzt werden und in der Folge die
Unternehmensstrategie optimale Unterstützung erfährt. Dazu ist es zielführend, ausgehend
von der Unternehmensstrategie das Unternehmen in Form von Geschäftsfähigkeiten zu
beschreiben. Diese stellen Fähigkeiten des Unternehmens dar, die durch Geschäftsprozesse
(Ablauforganisation), Mitarbeiter (Aufbauorganisation) und IT umgesetzt werden. Um
innerhalb der einzelnen Geschäftsfähigkeiten den Fokus auf das Business IT Alignment
legen zu können, wird die erforderliche IT-Unterstützung in Form von Geschäftsfunktionen
beschrieben. Diese werden mit den Geschäftsprozessen verknüpft und bilden somit das zen-
trale und fachliche Bindeglied zwischen Geschäfts- und IT-Architektur.
Die Einsatzbereiche des Unternehmensarchitektur-Managements sind vielfältig. Szenarien
wie Bebauungsplanung, Anwendungsportfolio-Management, Stammdaten-Management und
16 Integration von Prozessmanagement und Unternehmensarchitektur-Management 315
Technologieharmonisierung sind nur einige Beispiele. Im Zusammenhang mit dem Business

IT Alignment fokussiert das Unternehmensarchitektur-Management auf die Planung,
Optimierung und Umsetzung von IT-Architekturen im Einklang mit den Anforderungen
der Fachbereiche. Das Unternehmensarchitektur-Management benötigt hierbei aber min-
destens Input, wenn nicht gar (mit-)steuernde Kompetenzen aus dem Prozessmanagement,
da die Anforderungen der Fachbereiche hier originär entstehen. Das gleiche gilt für das
Strategiemanagement. Zielsetzungen für das Unternehmensarchitektur-Management werden
aus der Unternehmensstrategie abgeleitet und in Form von Architekturprinzipien operatio-
nalisiert (Eckert et al. 2012, S. 93). Diese beeinflussen und steuern in weiterer Folge alle ande-
ren Aktivitäten im Unternehmensarchitektur-Management. Das Risikomanagement in der
speziellen Ausprägung des IT-Risikomanagements hat als orthogonale Managementdomäne
Einfluss auf die Gestaltung aller Ebenen der Unternehmensarchitektur.
Als Basis für das Unternehmensarchitektur-Management dient eine konsis-
tente und modellhafte Beschreibung der Architektur. Diese wird i. d. R. in dezidierten
Unternehmensarchitektur-Management-Werkzeugen wie bspw. ADOit® erstellt und ana-
lysiert. Dabei kommen bestimmte Werkzeuge und Modellierungssprachen bzw. -metho-
den zum Einsatz, wie z. B. die praxisorientierten Architekturmanagement-Frameworks
TOGAF® (The Open Group 2009, 2011) und DoDAF (U.S. Department of Defense 2010)
oder die der Wissenschaft entstammende Unternehmensmodellierungsmethode MEMO
(Frank 2002; Kirchner 2008), um nur eine kleine Auswahl zu nennen. Die Architektur
wird in unterschiedliche Ebenen separiert, welche dann im Unternehmensmodell mitei
nander in Beziehung gesetzt werden. Abb. 16.1 zeigt eine typische Strukturierung eines
Unternehmensmodells. Zuoberst befinden sich die Strategien bzw. strategischen Ziele sowie
die daraus abgeleiteten Architekturprinzipien. Darunter definiert die Geschäftsarchitektur
die Geschäftsfähigkeiten, Geschäftsprozesse und Produkte des Unternehmens. Als zen-
trales Integrationskonzept zur darunterliegenden Informationssystemarchitektur dient
die Geschäftsfunktion. Diese wird meist als funktionale Beschreibung der Anwendungen
(Softwareprodukte) genutzt, welche die Geschäftsprozesse unterstützen. Geschäftsfunktionen
dienen somit als gemeinsame terminologische Basis für die Abstimmung zwischen IT
und Business. Weiterhin werden in der Datenarchitektur jene Daten in der Form von
Geschäftsobjekten beschrieben, die für die Ausführung der Geschäftsprozesse erfor-
derlich sind bzw. durch die Geschäftsprozesse manipuliert werden. Die darunterlie-
gende Architekturebene repräsentiert die Technologiearchitektur. Diese beschreibt die
Technologien, die erforderlich sind, um Anwendungen entwickeln, integrieren und betrei-
ben zu können. Orthogonal zu den vorgenannten Ebenen wird noch die Aufbauorganisation
(diese wird teils auch als Bestandteil der Geschäftsarchitektur gesehen) und die
Projektorganisation dargestellt.
Die folgenden Abschnitte orientieren sich an den oben beschriebenen Konzepten
innerhalb der Unternehmensarchitektur hinsichtlich der Zielsetzung des Kapitels, dem
Aufzeigen der Potenziale und des Vorgehens zum Business IT Alignment, und werden in
diesem Kontext teilweise vertieft diskutiert. Insbesondere die Rolle der Geschäftsfunktionen
als Integrationskonzept zwischen Business und IT wird hierbei hervorgehoben behandelt.
Strategie und Governance
Ziel Control Objective Architekturprinzip Kennzahl
Organisation Geschäftsarchitektur Trans-

formation
Domäne Geschäfts- Produkt IT-Service

fähigkeit
Standort
Geschäftsfunktion Geschäfts- Vertrag Projekt

prozess
Applikations- und Daten-

Servicearchitektur architektur
Organisations-
einheit
Anwendungs- Service
gruppe
Anwendung Geschäfts- Anforderung

objekt
Akteur
Anwendungs- Schnittstelle
komponente
Technologiearchitektur
Rolle Technologiepaket Infrastrukturbaustein
Datenbank Technologie Netzwerk-

element
Risikoarchitektur
Risiko Schutzobjekt
Abb. 16.1 Beispiel für Ebenen und Elemente einer Unternehmensarchitektur

16.2 Eine stabile Grundlage für das Business IT Alignment
Eine der wesentlichen Herausforderungen bei der Umsetzung eines nachhaltigen

Business IT Alignment ist die Etablierung einer gemeinsamen Struktur und stabilen
Planungsgrundlage für alle Bereiche einer Organisation. Hierzu wird die Schaffung eines
zentralen Bilds, welches über den Zeitablauf möglichst stabil bleibt, empfohlen. Dabei
kann es sich etwa um die Prozesslandkarte auf oberster Ebene (vgl. ebenso Kap. 3) oder –
wie in einigen Unternehmensarchitektur-Management-Frameworks (vgl. z. B. TOGAF®)
empfohlen – um Business Capability Maps (dt. Geschäftsfähigkeits-Karten) handeln.
Business Capabilities (dt. Geschäftsfähigkeiten) beschreiben dabei die Fähigkeiten des
Unternehmens, die einen Mehrwert für das Unternehmen schaffen. Sie bilden stabile,
abgeschlossene und voneinander unabhängige Einheiten, die zunächst abstrahierend
von der technischen Realisierung bzw. von der organisatorischen Einbettung als eine
Menge von Geschäftsfunktionen dokumentiert werden können. Realisiert werden die
Geschäftsfähigkeiten durch die Ausführung von Geschäftsprozessen unter Einbeziehung
der IT. Geschäftsfähigkeiten umfassen somit neben den Geschäftsprozessen auch
die zugrunde liegenden IT-Ressourcen sowie die beteiligte Aufbauorganisation (vgl.
Abb. 16.2).
Auf einem hohen Abstraktionsgrad können Geschäftsfähigkeiten und Geschäftsprozesse
in der Regel synonym betrachtet werden. Sollte eine Prozesslandkarte des Unternehmens
bzw. des im Fokus stehenden Ausschnitts des Unternehmens bereits existieren, kann diese
folglich für die weitere Architekturplanung wiederverwendet werden. Wichtig ist aller-
dings, dass für diese eher strategische Betrachtung und Analyse der Fokus auf einer stabi-
len und abstrakten Geschäftslogik liegt. Es muss sich um logische, abstrahierte Fähigkeiten
handeln, die implementierungsunabhängig – dies gilt sowohl aus technischer als auch aus
organisatorischer Sicht – formuliert sind. Es sollte somit keine unnötige Differenzierung
der Geschäftsfähigkeiten aufgrund organisatorischer Gegebenheiten (z. B. unterschied-
licher Standorte) erfolgen, soweit diese nicht durch fachliche Anforderungen (etwa
Abb. 16.2 Business Capabilities

als „Durchstich“ durch die Geschäftsfähigkeit
Architekturebenen
Geschäftsprozesse und
Organisationseinheiten
Geschäftsfunktionen
Anwendungen und
Technologien
unterschiedliche rechtliche Anforderungen an unterschiedlichen Standorten) begründet

werden kann. Schnittstellen zwischen Geschäftsprozess- und Unternehmensarchitektur-
Management-Werkzeugen (bspw. zwischen ADONIS® und ADOit®) ermöglichen dabei, die
Prozesslandkarte synchron zu halten.
Erst auf der Detailebene wird die veränderliche Geschäftslogik in Form von detaillierten
Prozessablaufdiagrammen dokumentiert. Diese Ebene spielt aber für das Unternehmens
architektur-Management im ersten Schritt eine untergeordnete Rolle bzw. wird nur bei
Bedarf (üblicherweise in späteren Umsetzungsphasen, vgl. bspw. Abschn. 16.3.2.3) betrach-
tet. Geschäftsfähigkeiten oder Top Level-Prozesslandkarten bilden somit den fachlichen
Blueprint des Unternehmens. Sie dienen u. a. der Einordnung von strategischen und takti-
schen Anforderungen. Durch die Trennung von Geschäftsfähigkeiten und der tatsächlichen
Realisierung in Form von Geschäftsprozessen und zugrunde liegenden Applikationen und
Technologien können strategische Anforderungen konsequent und übersichtlich zugeordnet
werden.
Die einer Business Capability zugeordneten Geschäftsprozesse sollten sich Geschäfts
funktionen bedienen und sind idealerweise nicht direkt mit IT-Lösungen (z. B. Anwen
dungen) zu verknüpfen. Grundlegender Vorteil dieser Entkopplung der Geschäftsprozesse
von der IT im Unternehmensmodell durch die integrative Schicht der Geschäftsfunktionen
ist die Stabilität letzterer im Zeitverlauf. Geschäftsprozessabläufe unterliegen tendenziell
einer höheren Änderungsfrequenz als Geschäftsfunktionen, da durch die Optimierung
der Abläufe im Prozess immer wieder Verbesserungen (z. B. bei Kosten oder Zeiten)
erzielt werden sollen und können. Die verwendeten Funktionen bleiben aber in der
Regel dieselben oder ändern sich lediglich im Detail, was auf der Betrachtungsebene der
Funktionslandkarte nicht augenfällig wird. Auch sind seitens der Fachabteilungen, wie
oben schon angedeutet, keine detaillierten Kenntnisse der IT-Architektur notwendig.
Seitens der IT können in der Regel die Prozesse, insbesondere Prozessabläufe, ausge-
blendet werden, was die Kommunikation mit den Fachbereichen für die Rollen in der
IT grundlegend vereinfacht. Die Ebene der Geschäftsfunktionen bildet somit eine stabile
Planungsgrundlage – sowohl für die Fachbereiche als auch für die IT.
Ein verbreiteter, branchenneutraler Ordnungsrahmen, der als Ausgangsbasis für die
Erstellung einer Business Capability Map dienen kann, ist beispielsweise die Porter’sche
Wertschöpfungskette (Porter 1985). Aktivitäten wie Eingangslogistik, Produktion und
Ausgangslogistik – die auch als Geschäftsfähigkeiten interpretiert werden können – bilden
beispielsweise die Ausgangsbasis für die Definition der unternehmensspezifischen Business
Capability Map (vgl. Abb. 16.3). Porter (1985, S. 37) unterschied bereits im Jahre 1985 zwi-
schen Primäraktivitäten und Sekundäraktivitäten (auch Unterstützungsaktivitäten) – eine
Trennung, die auch für die Geschäftsfähigkeiten hilfreich ist, sodass der Fokus für alle wei-
teren Business IT Alignment-Maßnahmen schwerpunktmäßig auf die wertschöpfenden
Geschäftsfähigkeiten gelegt werden kann.
Wettbewerbsstrategie - Wertschöpfungskette
Unternehmensinfrastruktur
Unterstützungs -
aktivitäten
Human Resource Management
Technologieentwicklung
Beschaffung
Marge
Interne Externe Marketing
Produktion Service
Logistik Logistik und Verkauf
Primäraktivitäten
Abb. 16.3 Porter’sche Wertschöpfungskette (Gabler Verlag 2013)
Beispiel
Abbildung 16.4 zeigt ein Beispiel für eine Business Capability Map mit mehreren Ebenen
für einen Flughafen. Das Beispiel orientiert sich an der Porter’schen Wertschöpfungskette.
Unternehmensinfrastruktur
Human Resource Management
Technologieentwicklung
Beschaffung
Marketing
Aviation Non-Aviation Service
und Verkauf
Boden- Retail
abfertigung Mgmt.
Sicher- Gebäude
heitsdienst und Park…
Terminal-
betrieb
Abb. 16.4 Beispiel einer Business Capability Map eines Flughafens

Die „Primär-Geschäftsfähigkeiten“ werden nochmals in zwei wesentliche Blöcke unter-

schieden: „Aviation“ und „Non-Aviation“. Beide Geschäftsfähigkeiten werden hierarchisch
zerlegt. Während Aviation alle unmittelbar mit dem Flugbetrieb zusammenhängenden
Geschäftsfähigkeiten, wie „Bodenabfertigung“ und „Terminalbetrieb“, beinhaltet, fokus-
siert der Bereich Non-Aviation auf Geschäftsfähigkeiten, wie „Retail Management“ sowie
„Gebäude- und Parkraumvermietung“.
Eine weitere Hilfestellung für die Erstellung von Business Capability Maps bieten oftmals
auch branchenspezifische Referenzmodelle. Beispiele sind u. a.:
• das ACORD-Framework (ACORD Corporation 2013), ein Referenzmodell für die

Versicherungswirtschaft, welches u. a. auch Capability Maps beinhaltet,
• eTOM (TeleManagement Forum 2013), die enhanced Telecom Operations
Map, ein Rahmenwerk für Geschäftsprozesse von Unternehmen im Bereich der
Telekommunikation und IT-Dienstleistung oder
• FEA, die Federal Enterprise Architecture (U.S. Office of Management and Budget
2013), ein Referenzmodell für den öffentlichen Sektor aus den USA.
16.3 Vorgehensmodell für das Business IT Alignment
Die Durchführung des Unternehmensarchitektur-Managements im Allgemeinen und des

Business IT Alignment im Speziellen in einem Unternehmen orientiert sich idealerweise
an einem Vorgehensmodell, das die erforderlichen Tätigkeiten inkl. der beteiligten Rollen
angemessen detailliert beschreibt. Architekturmanagement-Frameworks aus und für die
Praxis als auch eher wissenschaftlich motivierte Methoden der Unternehmensmodellierung
beinhalten jeweils ein mehr oder weniger ausgearbeitetes Vorgehensmodell dieser Art.
Stellvertretend soll an dieser Stelle anhand der Architecture Development Method (ADM)
aus TOGAF® (The Open Group 2009, S. 49 ff.) – ein in der Praxis weltweit anerkanntes
Framework – skizziert werden, wie ein solches Vorgehensmodell konzipiert ist und wie
in welchen Phasen die Integration von Geschäftsprozess- und Unternehmensarchitektur-
Management im Sinne eines Business IT Alignment zum Tragen kommt.
Die TOGAF® Architecture Development Method beschreibt, wie eine Unterneh
mensarchitektur unter Berücksichtigung der Anforderungen aus Business und IT
zu konzipieren ist. Abbildung 16.5 zeigt einen Überblick über die Phasen der ADM.
Innerhalb der einzelnen Phasen existiert jeweils noch ein Mikroprozess, der die dort
durchzuführenden Aktivitäten strukturiert.
16.3.1 Phasen der Architecture Development Method
Die Phasen der ADM werden im Folgenden kurz beschrieben, wobei etwaige Schnittstellen
zum Prozessmanagement, z. B. die Verwendung von Geschäftsprozessen als Input oder
Output, jeweils explizit erwähnt werden.
Preliminary:
Framework
& Principles
A:
Architecture
Vision
H:
B:
Architecture
Business
Change
Architecture
Management
C:
G:
Requirements Information
Implementation
Management Systems
Governance
Architectures
F: D:
Migration Technology
Planning Architecture
E:
Opportunities
& Solutions
Abb. 16.5 TOGAF® ADM (The Open Group 2011, S. 48)
Preliminary
In dieser frühen Phase wird u. a. festgelegt, welche Bereiche der Organisation zu berück-
sichtigen sind (Scope), welche Stakeholder zu beachten sind, wie die Schlüsseltreiber
aussehen, welche Architekturprinzipien einzuhalten sind und wie das zu nutzende
Architekturmanagement-Framework auszusehen hat. Unternehmensarchitektur-

Management-Werkzeuge werden in Hinblick auf die erforderlichen Sichten (Viewpoints),
das Metamodell etc. an dem Framework ausgerichtet. Obwohl in TOGAF® nicht explizit
beschrieben, ist es ratsam, Geschäftsprozessmodelle – insbesondere Prozesslandkarten
oder wenn vorhanden Business Capability Maps – als Input für diese Phase zu verwenden,
um diese zur Beschreibung des organisatorischen Kontexts sowie in späteren Phasen als
Grundlage für die Definition der Anforderungen aus dem Fachbereich nutzen zu können.
Requirements Management
Die parallel zu allen anderen Phasen der ADM durchzuführenden Aktivitäten
des Anforderungsmanagements sollen gewährleisten, dass jederzeit auf geänderte
Anforderungen reagiert werden kann. Diese werden zentral verwaltet und stehen in
den einzelnen Phasen als Input für die durchzuführenden Aktivitäten zur Verfügung.
Insbesondere Anforderungen, die zu Änderungen der Geschäftsarchitektur führen,
sollten auf Geschäftsfähigkeiten verweisen und in weiterer Folge auch in Form von
Geschäftsprozessen detailliert werden.
A. Architecture Vision
Die Architekturvision beschreibt den gewünschten Zustand der Organisation für die kom-
menden Jahre. Sie enthält die Beschreibung der Strategien und Ziele. Sie beschreibt, wie
die neu zu schaffenden bzw. zu optimierenden Fähigkeiten die Strategien und Ziele der
Organisation unterstützen. Dabei steht vor allem die Definition der Anforderungen (engl.
Business Requirements) an die zu entwickelnde Architektur im Vordergrund. Business
Capability Maps oder Prozesslandkarten dienen hier als Hilfsmittel zur Ableitung der
geschäftlichen Anforderungen und helfen beim Verständnis auf Geschäftsseite insgesamt.
B. Business Architecture
Die Beschreibung der Unternehmensarchitektur in Form von Strategien,
Geschäftsprozessen, Aufbauorganisation und Funktionen auf der Basis der Festlegungen
der Architecture Vision ist Gegenstand dieser Phase. Geschäftsprozesse werden
genutzt, um die zukünftige Struktur der Ablauforganisation zu beschreiben. Im Zuge
des Prozessmanagements werden Gap-Analysen durchgeführt, um entwickelte Soll-
Prozesse mit den Ist-Prozessen zu vergleichen. Zur Strukturierung und Einordnung der
Geschäftsprozessmodelle wird idealerweise die Business Capability Map genutzt.
C. Information Systems Architectures

Diese Phase wird noch einmal in Data und Application Architecture unterschieden.
Die Data Architecture beinhaltet die Identifikation und Dokumentation von Daten
und Datenquellen, die benötigt werden, um die Geschäftsprozesse zu unterstützen. Die
Application Architecture dient u. a. der Identifikation von Anwendungen, die geeig-
net sind, um die hinsichtlich der Unterstützung der Geschäftsprozesse relevanten
Daten angemessen zu verarbeiten. Anwendungen werden funktional – in Form von
Geschäftsfunktionen – beschrieben, wodurch gewährleistet ist, dass die Dokumentation

weitgehend unabhängig von konkreten Technologien ist.
D. Technology Architecture
Ausgehend von den Anforderungen an die Architektur wird die notwendige Unterstützung
durch die technische Infrastruktur spezifiziert. Die konkrete Ausprägung der Technologie
architektur hat in der Regel keinen direkten Bezug auf die Geschäftsprozesse, wobei neue
Technologien oftmals Enabler für neue Geschäftsmodelle sein können.
E. Opportunities and Solutions

Die Architekturbeschreibungen der vorangegangenen Phasen werden hinsicht-
lich eventuell existierender Alternativen überprüft. Alternativen können sich hier-
bei sowohl auf die Geschäftsarchitektur als auch auf die IT-Architektur beziehen.
Als Bewertungskriterien werden u. a. die in der Phase Architecture Vision definierten
Architekturprinzipien herangezogen.
F. Migration Planning
In dieser Phase wird ein konkreter Zeitplan für die Realisierung der Zielarchitektur
entwickelt. Die erforderlichen Veränderungen an der Architektur werden unter
Berücksichtigung von Abhängigkeiten, Risiken und Ressourcen erarbeitet.
G. Implementation Governance
Die Implementierung der neuen Architektur wird begleitend überwacht, wodurch sicher-
gestellt wird, dass die Konformität der in den einzelnen Projekten erstellten Produkte zu
den zuvor erstellten Architekturbeschreibungen und Vorgaben jederzeit gegeben ist.
H. Architecture Change Management

In dieser Phase erfolgen die Bewertung der erreichten Ziele und der aufgetretenen Risiken
sowie die Ermittlung interner und externer Einflussfaktoren. Auf Basis dieser Bewertung
sowie neuer und geänderter Anforderungen wird ggf. ein neuer Entwicklungszyklus initiiert.
16.3.2 Ausgewählte Phasen und Ergebnistypen
Anhand der drei Phasen Business Architecture, Information Systems Architectures und
Opportunities and Solutions wird skizziert, an welcher Stelle eine besonders enge Integration
des Prozessmanagements mit dem Unternehmensarchitektur-Management zielführend ist.
16.3.2.1 Phase „Business Architecture“

Die Business Capability Map bildet einen idealen Startpunkt für die Standortbestimmung
des Business IT Alignment. Business Capabilities werden bspw. nach deren strategischer
Bedeutung und der Qualität der IT-Unterstützung bewertet. Somit kann, ohne auf die
Ebene der Informationssystemarchitektur zu vertiefen, bereits auf dieser Ebene evaluiert
werden, welche Bereiche des Unternehmens bspw. durch Investitionen in die IT besser
unterstützt werden sollten. Hierzu empfiehlt es sich, klare Kriterien – etwa in Form
eines standardisierten Fragenkatalogs – zu erstellen. Bewertet werden u. a. der funkti-
onale Abdeckungsgrad, nicht-funktionale Anforderungen (wie Verfügbarkeiten und
Performance) und die Betriebskosten.
Die Maßnahmen zur Optimierung können dann vielfältiger Natur sein. Die Bandbreite
zur Optimierung des Business IT Alignment reicht von der Optimierung der (IT-)
Supportprozesse über Anpassungen/Optimierung bestehender Anwendungen bis hin zur
Einführung neuer Anwendungen. Der Fokus dieser Standortbestimmung sollte aber nicht
ausschließlich auf die Qualität der IT-Unterstützung – die IT-Fitness der zugrunde liegen-
den IT-Architektur – gelegt werden. Selbstverständlich können Optimierungspotenziale
auch innerhalb der Geschäftsarchitektur an sich identifiziert werden. Ein Beispiel wären
hohe Fehlerraten in Prozessen einer Business Capability, die nicht auf die zugrunde lie-
gende IT zurückzuführen sind, oder heterogene, nicht-standardisierte Geschäftsprozesse
bei verschiedenen Unternehmensstandorten. Dies kann dazu führen, dass für die identi-
fizierten Bereiche die Geschäftsprozesse im Detail modelliert und analysiert werden müs-
sen. Hohe Fehlerraten können dann ggf. durch Training der Mitarbeiter, Bereitstellung von
(prozessbasierten) Arbeitsanweisungen oder Reorganisation der Prozesse reduziert werden.
Auf Basis der Business Capability Map kann somit aus strategischer Sicht entschieden
werden, in welche der identifizierten Geschäftsfähigkeiten investiert werden muss, um eine
erforderliche Differenzierung am Markt zu erreichen und den langfristigen Geschäftserfolg
des Unternehmens sicherzustellen. Fehlinvestitionen, wie etwa Projekte in Bereichen, die
strategisch von geringer Bedeutung sind, werden aufgedeckt bzw. vermieden.
Für die identifizierten Bereiche erfolgt dann eine hierarchische Zerlegung der
Geschäftsfähigkeiten, sodass auch taktische Anforderungen auf einer entsprechend tie-
feren Ebene der Capability Map zugeordnet werden können. In TOGAF® werden die
Geschäftsfähigkeiten – im Sinne funktionaler Bausteine – als Architekturbausteine
(Architecture Building Blocks) bezeichnet. Mit dieser Vorgehensweise wird sichergestellt,
dass der mögliche Lösungsraum nicht bereits in frühen Phasen von IT-Projekten – ohne
Detailkenntnis über die fachlichen Anforderungen – durch Festlegung von Technologien
bzw. durch unreflektierte Annahmen zu bestehenden Organisationsstrukturen bzw.
Geschäftsprozessen eingeschränkt wird.
Für die konkrete Ausgestaltung der Business Capability Map, insbesondere für deren
Detaillierung in tiefere Ebenen, empfiehlt es sich, die wesentlichen Kriterien, die das
Geschäft beeinflussen, vorab zu definieren. Kriterien, die eine einheitliche Zerlegung
ermöglichen, können beispielsweise folgende sein:
• Kundentyp
Ein Flughafen unterscheidet beispielsweise zwischen Airlines, Retail-Kunden (Shops)
und Passagieren.
• Produkte/Dienstleistungen
Auf oberster Ebene unterscheidet ein Flughafen zwischen Aviation- und
Non-Aviation-Dienstleistungen.
• Vertriebskanäle
Shops des Flughafens werden beispielsweise via Direktvertrieb und/oder via Inter
netvertrieb angeboten.
• Fertigungstiefe
Hierbei ist zu klären, welche Fähigkeiten durch den Flughafen direkt abgedeckt wer-
den bzw. welche durch mögliche Partner erbracht werden. Beispielsweise könnte die
Gepäckförderanlage direkt durch Mitarbeiter des Flughafens oder aber auch durch
einen Sourcing-Partner betrieben und gewartet werden.
Ähnliche Kriterien werden auch in Kap. 3 zur Zerlegung und Strukturierung von
Prozesslandkarten empfohlen. Grundregel für die hierarchische Zerlegung im Rahmen
des Unternehmensarchitektur-Managements ist jedoch, dass die Geschäftsfähigkeiten
nur dann detailliert und aufgespalten werden, wenn aus funktionaler Sicht auf der jewei-
ligen Abstraktionsebene tatsächlich Unterschiede berücksichtigt werden müssen. So ist
eine Aufspaltung einer Geschäftsfähigkeit im Hinblick auf unterschiedliche ausführende
Organisationseinheiten oder unterschiedliche Standorte (soweit dies aufgrund unter-
schiedlicher regulatorischer oder rechtlicher Anforderungen nicht zwingend erforderlich
ist) in der Regel nicht zielführend.
Fokussiert man nun auf eine konkrete Geschäftsfähigkeit, lassen sich die Geschäfts
funktionen im Sinne erforderlicher IT-Unterstützung zuordnen. Diese dienen zunächst
der funktionalen Beschreibung benötigter Informationssysteme. Eine Menge von
Geschäftsfunktionen bildet somit die funktionale Detailebene einer Geschäftsfähigkeit aus.
Beispiel
Abbildung 16.6 bezieht sich erneut auf das Flughafenszenario. Am Beispiel der
Geschäftsfähigkeit „Aviation > Terminalbetrieb“ wird aufgezeigt, wie eine hierarchische
Zerlegung erfolgen kann. Diese Geschäftsfähigkeit wird auf dritter Ebene etwa in fol-
gende Geschäftsfähigkeiten detailliert: „Check-in“, „Sicherheitskontrolle“, „Boarding“
etc. Weiterhin erfordert die Geschäftsfähigkeit „Boarding“ eine Reihe von Geschäftspro-
zessen (von der Aufbauorganisation wird in der Abbildung abstrahiert) sowie IT-Unter-
stützung, repräsentiert durch die von der IT angebotenen Geschäftsfunktionen. Wird
der Geschäftsprozess „Pier-Boarding durchführen“ im Detail betrachtet, wird schnell
klar, dass eine Reihe an Geschäftsfunktionen zur Realisierung des Prozesses erforderlich
ist. Exemplarisch zu nennen sind an dieser Stelle „Fluginformationen bereitstellen“ und
„Dynamische Hinweisschilder bespielen“. Abbildung 16.6 zeigt die hier beschriebene
Geschäftsarchitektur in Form eines Abhängigkeitsdiagramms.
Es wird deutlich, dass die Geschäftsfunktionen als zentrales Bindeglied zwischen den
Geschäftsprozessen auf der einen Seite und der IT auf der anderen Seite als integra-
tive Schicht dienen können. So kann in der Form von Geschäftsfunktionen seitens der
Fachabteilung formuliert werden, welche Anforderungen an die IT existieren, ohne
Geschäftsarchitektur
Geschäftsfähigkeiten
Aviation
Terminalbetrieb …
Check-In Sicherheitskontrolle Boarding De-Boarding Grenzkontrolle Zollabwicklung …
Geschäftsprozesse
Bus-Boarding Pier-Boarding …
durchführen durchführen
Geschäftsfunktionen
Boarding Zutritts- Flug- Durchsage Dynamische Fluggast -

durch- kontrolle information durch- Hinweisschilder brücken …
führen durchführen bereitstellen führen bespielen aktivieren
Abb. 16.6 Abhängigkeitsdiagramm (Geschäftsarchitektur)
dass die Struktur der Anwendungsarchitektur zwingend bekannt sein muss. Seitens der
IT kann mittels Funktionslandkarten dargestellt werden, welche Funktionen angeboten
werden, wodurch eine Grundlage für die Erstellung einer Gap-Analyse geschaffen wird.
Die identifizierten Geschäftsfunktionen müssen in weiterer Folge von konkreten
Anwendungen realisiert werden. Die Konzeption hierfür erfolgt in der Phase „Information
Systems Architectures“.
16.3.2.2 Phase „Information Systems Architectures“

Auf Ebene der Information Systems Architectures erfolgen analog zur Business Architecture
die Beschreibung der Ist-Architektur sowie die Entwicklung der Zielarchitektur.
Mittels Gap-Analysen – sowohl bezogen auf die Datenarchitektur als auch auf die
Anwendungsarchitektur – werden erforderliche Anpassungen der Unternehmensarchitektur
erkannt.
In der Applications Architecture (Teil der Information Systems Architectures) wer-
den u. a. konkrete Softwarelösungen evaluiert und bewertet. TOGAF® bezeichnet diese
auch als Solution Building Blocks. Insbesondere für das Business IT Alignment sind die
bestehenden Anwendungen mit den in der Phase Business Architecture definierten
Geschäftsfunktionen zu verknüpfen.
ACS BA FIDS SUS
Boarding
durchführen
Buseinsatz
steuern
Durchsage
durchführen
Dynamische Hinweis-
schilder bespielen
Fluggastbrücken
aktivieren
Zutrittskontrolle
durchführen
Abb. 16.7 Matrix mit Anwendungen und angebotenen Geschäftsfunktionen
Beispiel
Wird wiederum das Beispiel des Flughafens aufgegriffen, könnten die identifizierten
Geschäftsfunktionen aktuell durch Anwendungen wie „FIDS“ (Flight Information Dis-
play System), „BA“ (Beschallungsanlage) und „ACS“ (Aviation Core System) realisiert
sein. Abbildung 16.7 zeigt die Zusammenhänge in Form einer Matrixdarstellung.
Jede der Anwendungen ist im Kontext der von ihr bereitgestellten Geschäftsfunktionen zu
bewerten. Zentrale Kriterien hierzu sind beispielsweise Business-Fitness, IT-Fitness und
Kosten-Fitness. Diese oder vergleichbare Bewertungsansätze sind ein zentrales Instrument
im Rahmen des Anwendungsportfolio-Managements. Zur Bewertung der Business-
Fitness werden beispielsweise der funktionale Abdeckungsgrad (Grad der Erfüllung der
Anforderungen der Nutzer), aber auch nicht-funktionale Anforderungen (wie Sicherheit,
Performance, Usability) ermittelt. Die Bewertung wird in der Regel gemeinsam mit
den jeweiligen Prozessverantwortlichen durchgeführt. Zur IT-Fitness werden sowohl
die technologische Architektur der Anwendungen als auch die zugrunde liegenden,
betriebsrelevanten IT-Verfahren (bspw. ein funktionierendes Störungs-, Change- oder
Release-Management) bewertet. Die Verknüpfung der Anwendung mit den verwendeten
Technologien ist hier von Vorteil. Werden diese Technologien etwa in einer Technologie-
Roadmap (diese wird in der Phase Technology Architecture definiert) regelmäßig bewer-
tet, so können wertvolle Schlüsse in Hinblick auf die IT-Fitness gezogen werden.
Abbildung 16.8 zeigt ein Beispiel anhand von Technologie-Lebenszyklen. Die Anwendung
FIDS verwendet Technologien, für die ein Ablösedatum (engl. End-of-Life) gesetzt wurde.
Für die Ermittlung der Kosten-Fitness werden schließlich u. a. Investitionskosten und
Betriebskosten bewertet. Die Gesamtheit der Parameter dient zur Entscheidungsfindung,
wie in Zukunft mit bestehenden oder geplanten Anwendungen zu verfahren ist. Hier
steht in aller Regel vor allem die Entscheidung Make or Buy, also kaufen oder selbst
1998 2004 2010 2016

Name
1995 2001 2007 2013 2019
ACS
IIS 7.5
Internet Explorer 9.x
Java SE v6
Oracle Version 11g R2 25.02.2010 -26.02.2016
BA
Java SE v6
Oracle Version 11g R2 25.02.2010 -26.02.2016
FIDS
Cobol 2002 01.01.2002 -26.02.2014
DB2 for Mainframe z/OSx 01.01.2002 -25.02.2014
z/OS v1.1 01.01.2002 -26.02.2014
Abb. 16.8 Anwendungen und zugrunde liegende Technologien (Technologie-Roadmap-Sicht)
entwickeln, im Vordergrund. Es wird auf diese Weise eine Investitionsstrategie für jede
der Anwendungen definiert.
Beispiel
Abbildung 16.9 zeigt eine Darstellung eines Anwendungsportfolios, wiederum am Bei-
spiel des Flughafens. Betrachtet man in diesem Beispiel die Anwendung FIDS, so ist
unmittelbar ersichtlich, dass die Anwendung zwar strategisch wichtig ist, jedoch weder
bezüglich IT-Fitness noch Business-Fitness zufriedenstellende Bewertungsergebnisse
liefert. Die Anwendung ist somit ein Ablösekandidat. Die Investitionsstrategie wird auf
„Desinvestieren“ gesetzt.
Um die Auswirkungen der auf diese Weise definierten Investitionsstrategien auf

den betrachteten Unternehmensbereich insbesondere im Zusammenspiel mit den
Geschäftsprozessen zu visualisieren, empfiehlt es sich, einen Bebauungsplan zu erstellen.
Dieser wird typischerweise in Form einer Matrix repräsentiert.
Beispiel
Im nachfolgenden Beispiel (vgl. Abb. 16.10) werden die Geschäftsprozesse auf der
horizontalen und die Organisationseinheiten auf der vertikalen Achse dargestellt. In
den Zellen der Matrix werden die Anwendungen inklusive ihrer Investitionsstrategie
abgebildet. Für Anwendungen mit Investitionsstrategie Desinvestieren (Pfeil nach
unten, vgl. Abb. 16.10) sind alternative Anwendungen einzuplanen. Geplante, d. h.
zum Betrachtungszeitpunkt noch nicht produktive, Anwendungen werden in der Mat-
rix mit gestricheltem Rahmen visualisiert.
IT-Fitness
Exzellent
Gut
Ausreichend
Mangelhaft
Ungenügend
Nicht
anwendbar
Kein Eintrag
Nicht anwendbar Mangelhaft Gut
Kein Eintrag Ungenügend Ausreichend Exzellent
Business-Fitness
Strategische Bedeutung ACS BA FIDS SUS
Abb. 16.9 Anwendungslandschaft – Portfoliodarstellung
In den nachfolgenden Phasen, insbesondere in der Phase Opportunities and Solutions, wer-
den nun unterschiedliche Lösungsvarianten im Detail erarbeitet. Auf die Phase Technology
Architecture wird hier aufgrund ihres geringen Bezugs zum Prozessmanagement nicht näher
eingegangen.
Pier-Boarding Bus-Boarding Boarding …

durchführen durchführen überwachen
Airline BA BA
Sicherheitsdienst SUS
Terminalbetrieb ACS ACS ACS
FIDS FIDS
FIDS NP FIDS NP
Abb. 16.10 IT-Bebauungsplan

16.3.2.3 Phase „Opportunities and Solutions“

Auf der Ebene der Geschäftsarchitektur werden ggf. unterschiedliche Varianten von
Geschäftsprozessen (bspw. auch mit unterschiedlichen Bearbeitern bzw. Organi
sationseinheiten) im Detail erarbeitet und bewertet. Die erforderliche Beschreibung
und -analyse der Geschäftsprozesse erfolgt im Rahmen des Prozessmanagements durch
Prozessverantwortliche bzw. Prozessexperten (vgl. Abschn. 2.2.1). Ebenfalls muss entschie-
den werden, welche Teile der IT-Architektur selbst entwickelt und welche zugekauft wer-
den sollten (Make or Buy). Es empfiehlt sich, die verschiedenen Alternativen, auf die sich
eine Anforderung bezieht, in Form eines Abhängigkeitsdiagramms darzustellen.
Beispiel
Abbildung 16.11 zeigt ein Beispiel, welches die betroffenen Artefakte auf den Ebenen der
Unternehmensarchitektur darstellt und entsprechend ihres Planungsstatus hervorhebt.
Diejenigen Elemente der Architektur, die im Zuge der Umsetzung der Anforderung abge-
löst werden sollen, werden durchgestrichen markiert. Elemente, die angepasst werden müs-
sen (etwa ein zu adaptierender Geschäftsprozess), werden mit einem Stern gekennzeichnet.
Neu zu implementierende Architekturobjekte werden mit einem Schild gekennzeichnet.
Geschäftsarchitektur
Pier-Boarding
durchführen
Dynamische Hinweis - Fluginformationen …

schilder bespielen bereitstellen
Informations-
system-
architektur
FIDS FIDS NP
Flugplandaten ACS Gate-Infos SUS
Abb. 16.11 Lösungsszenario als Abhängigkeitsdiagramm

Für die Bewertung der Alternativen erscheinen auch Methoden des Prozessmanagements
hilfreich. Verfahren, wie die Simulation der Geschäftsprozesse, tragen dazu wesentlich
bei. So erlauben diese die Bewertung der alternativen Lösungsszenarien im Hinblick auf
Prozesskosten, Personalbedarf etc. (vgl. Kap. 8, 9, und 10).
Beispiel
In unserem Flughafenbeispiel wird eine mögliche Prozessänderung bei der Geschäfts-
funktion „Boarding durchführen“ identifiziert. Auf vielen Flughäfen kann diese Akti-
vität mittlerweile durch Bereitstellung eines Self-Service-Scanners durch die Passagiere
selbst durchgeführt werden. Somit ergibt sich eine Prozessänderung, wobei die Aktivität
„Registrierung des Passagiers“ nicht wie bisher durch Boardingpersonal durchgeführt
werden muss. Langfristig kann der Personaleinsatz dadurch reduziert werden.
In weiterer Folge werden die Phasen Migration Planning, Architecture Governance

und Change Management der ADM durchlaufen. Bei Bedarf wird ein weiterer
Architekturzyklus beginnend mit der Phase Architecture Vision initiiert. Da diese Phasen
keiner engen Verzahnung mit dem Prozessmanagement bedürfen, werden sie an dieser
Stelle nicht im Detail diskutiert.
16.4 Zusammenfassung
Prozessmanagement und Unternehmensarchitektur-Management werden in Organisationen

oftmals nahezu unabhängig voneinander implementiert. Mögliche Synergieeffekte können in
diesen Fällen nicht identifiziert werden und gehen somit verloren. Im vorliegenden Kapitel
werden die Synergieeffekte einer integrativen Nutzung der beiden Managementansätze auf-
gezeigt. Das Konzept der Business Capabilities wird eingeführt, um einen gemeinsamen
Rahmen zur Einordnung von Geschäftsprozessen und zugrunde liegenden IT-Architekturen
bereitzustellen.
Als Bindeglied zwischen den Geschäftsprozessen als wesentlichem Teil der Geschäfts
architektur und der IT-Architektur werden Geschäftsfunktionen etabliert. Diese bilden als
stabile und planungssichere Schnittstelle zwischen Geschäftsbereich und IT den Dreh- und
Angelpunkt für ein Business IT Alignment. Aus der Sicht des Geschäftsbereichs können auf
diese Weise Anforderungen an die IT losgelöst von einer technischen Betrachtung beschrie-
ben werden. Aus IT-Sicht werden die Geschäftsfunktionen zur Beschreibung und Bewertung
der Anwendungen und IT-Systeme genutzt, ohne bereits im ersten Schritt auf organisatori-
sche Rahmenbedingungen eingehen zu müssen. Die Geschäftsfunktionen bilden somit eine
solide Basis für die Planung und Weiterentwicklung sowohl der Geschäftsprozesse als auch
der Anwendungslandschaft.
Literatur
ACORD Corporation (2013) ACORD Framework, Pearl River. http://www.acord.org/resources/fr

amework/Pages/default.aspx. Zugegriffen: 07. Jan 2013
Eckert K-H, Frenzel M, Kirchner L (2012) Strategiekonformes Management von IT-Architekturen:
Von der Strategie zum Architekturprinzip. In: Meinhardt S, Reich S (Hrsg) HMD – Praxis der
Wirtschaftsinformatik, Bd 286. dpunkt, Heidelberg, S 93-103
Frank U (2002) Multi-Perspective Enterprise Modelling (MEMO) - Conceptual Framework and
Modelling Languages. In: Proceedings of the 35th Annual Hawaii International Conference on
System Sciences (HICSS-35). Computer Society Press, Honolulu
Gabler Verlag (2013) Gabler Wirtschaftslexikon, Stichwort: Wertschöpfungskette.
http://wirtschaftslexikon.gabler.de/Archiv/145581/wertschoepfungskette-v6.html. Zugegriffen:
07. Jan 2013
Keller W (2012) IT-Unternehmensarchitektur – Von der Geschäftsstrategie zur optimalen IT-
Unterstützung, 2. Aufl. dpunkt, Heidelberg
Kirchner L (2008) Eine Methode zur Unterstützung des IT-Managements im Rahmen der
Unternehmensmodellierung. Logos, Berlin
Moser C, Fürstenau D, Junginger S (2010) A Method for Integrating EAM and BPM. In:
Proceedings of the 2nd European Workshop on Patterns for Enterprise Architecture
Management (PEAM2010), Paderborn, S 231–242
Porter M-E (1985) Competitive Advantage: Creating and Sustaining Superior Performance. The
Free Press A Division of Simon & Schuster Inc., New York
TeleManagement Forum (2013) Business Process Framework (eTOM). http://www.tmforum.org/
BusinessProcessFramework/1647/home.html. Zugegriffen: 07. Jan 2013
The Open Group (2009) TOGAF® Version 9: The Open Group Architecture Framework
(TOGAF)®, Dokumentation, Document Number: G091
The Open Group (2011) TOGAF® Version 9.1, Dokumentation, Document Number: G116. http://
pubs.opengroup.org/architecture/togaf9-doc/arch/. Zugegriffen: 07. Jan 2013
U.S. Department of Defense (2010) The DoDAF Architecture Framework Version 2.02,
Department of Defense, United States of America, Washington. http://dodcio.defense.gov/dod
af20.aspx. Zugegriffen: 07. Jan 2013
U.S. Office of Management and Budget (2013) Federal Enterprise Architecture (FEA), Washington.
http://www.whitehouse.gov/omb/e-gov/fea. Zugegriffen: 07. Jan 2013
Integration von Prozess- und
Risikomanagement durch das 17
Interne Kontrollsystem
Thomas Müllner, Tim Farcher und Robert Strobl
Zusammenfassung
Innerhalb des Prozessmanagements werden durch die Prozessanalyse operationelle
Risiken identifiziert und bewertet, die das Erreichen der Prozessziele sowie im Weiteren
das Erreichen der Unternehmensziele erschweren oder sogar verhindern. Diesen ope-
rationellen Risiken zu begegnen, ist die Aufgabe des Internen Kontrollsystems (IKS),
das Sorge dafür zu tragen hat, die Prozessziele zu erreichen, Vermögenswerte zu sichern
und gesetzliche Vorgaben einzuhalten. Das Verhindern und Vermeiden von opera-
tionellen Risiken durch das IKS sollte auf effektive und effiziente Weise erfolgen. Um
dies zu gewährleisten, ist es essentiell, die Managementsysteme Risikomanagement
und Prozessmanagement integriert zu betrachten. Dieses Kapitel zeigt die wesentli-
chen Anknüpfungspunkte der Integration dieser Managementsysteme mittels unseres
Vorgehensmodells für das Interne Kontrollsystem – des „IKS-Life Cycle“ – auf. Anhand
dieses Vorgehensmodells, welches sich in die Phasen „IKS-Strategie“, „Risikoanalyse“,
„Kontrolldefinition und Risikooptimierung“, „Implementierung der Kontrollen“,
„Ausführung der Kontrollen“ und „Evaluierung der Risiken und Kontrollen“ glie-
dert, wird die Integration im Detail erläutert. Abschließend stellt dieses Kapitel das
IKS als Erfolgsfaktor für das Prozessmanagement dar und zeigt auf, wie es mithilfe von
Methoden des unternehmensweiten Risikomanagements laufend verbessert werden kann.
T. Müllner (*) · T. Farcher · R. Strobl

e-mail: thomas.muellner@boc-at.com

334 T. Müllner et al.
17.1 Überblick über die Gestaltung der Integration
„Risiko“ stellt einen Begriff dar, über den nicht nur heute viel gesprochen, geschrieben
und diskutiert wird. Der Begriff fand mit dem italienischen Wort „risico“ bereits im 16.
Jahrhundert Einzug in die kaufmännische Sprache. Damals wie heute versteht man dar-
unter die Gefahr, das angestrebte Ziel nicht zu erreichen (Eisele 2004).
Alle Tätigkeiten, die ausgeführt werden, um eine Organisation hinsichtlich Risiken
zu steuern, zu verbessern und zu kontrollieren werden im Risikomanagement bzw. im
Risikomanagement-System zusammengefasst (Austrian Standards 2010a). Zu diesem Zweck
bildet das Risikomanagement eine Querschnittsfunktion und weist Schnittstellen sowohl zum
strategischen Management, zum Prozessmanagement, zum IT-/Unternehmensarchitektur-
Management als auch zum Wissensmanagement auf (vgl. ebenso Abschn. 1.3).
Das vorliegende Kapitel betrachtet im Detail die Integration von Risikomanagement
und Prozessmanagement. Die Basis dieser Integration stellt das Interne Kontrollsystem
(IKS) dar, welches damit ein wesentlicher Teil des Prozessmanagements und auch des
Risikomanagements wird.
Definition
Unter dem Internen Kontrollsystem (IKS) werden Grundsätze, Maßnahmen und Ver
fahren verstanden, die
• der Sicherung der Wirksamkeit und Wirtschaftlichkeit der Geschäftsprozesse,

• der Ordnungsmäßigkeit und Verlässlichkeit der Rechnungslegung und
• der Einhaltung relevanter rechtlicher Vorschriften
dienen (Bungartz 2011).
Hierzu wirkt das Interne Kontrollsystem gegen Risiken, die infolge von Unangemes
senheit oder Versagen von internen Prozessen, Personen oder Systemen oder aufgrund
von externen Ereignissen eintreten können. Diese Risiken werden unter dem Begriff
„operationelle Risiken“ zusammengefasst (Oesterreichische Nationalbank (OeNB) und
Finanzmarktaufsicht (FMA) 2005).
Das Interne Kontrollsystem ist somit, wie eingangs beschrieben, integraler Bestandteil
sowohl des unternehmensweiten Risikomanagements wie auch des Prozessmanagements
und stellt das wesentliche Bindeglied dieser beiden Managementbereiche dar. Das IKS ist
auf Seiten des Prozessmanagements ein Erfolgsfaktor, der die Effektivität und Effizienz
der Geschäftsprozesse positiv beeinflusst, indem die operationellen Gefahren/Risiken
vermindert oder sogar vermieden werden können. Diese Gefahren/Risiken stellen ihrer-
seits wiederum einen wesentlichen Bestandteil des unternehmensweiten Risikoportfolios
dar, das im Managementbereich des unternehmensweiten Risikomanagements liegt.
Aus diesen Zusammenhängen heraus lässt sich das Argument ableiten, dass das IKS
einen wesentlichen Erfolgsfaktor des Prozessmanagements darstellt und im Sinne der
Prozessoptimierung eine wichtige Rolle spielt.
17 Integration von Prozess- und Risikomanagement 335
Auf die Integration von Risikomanagement und Prozessmanagement mithilfe des

Internen Kontrollsystems, die wesentlichen Erfolgsfaktoren und auf die daraus resultie-
renden Vorteile wird in diesem Kapitel detailliert eingegangen.
Der nachfolgende Abschnitt erläutert in einem kurzen Überblick den Aufbau
eines Internen Kontrollsystems und den IKS-Life Cycle. Der IKS-Life Cycle ist ein
Vorgehensmodell, welches nach unserer Erfahrung sehr gut geeignet ist, ein IKS zu imple-
mentieren, zu betreiben und kontinuierlich zu optimieren. Anhand dieses Vorgehensmodells
wird in weiterer Folge dargestellt, wie das IKS als Erfolgsfaktor für das Prozessmanagement
eingesetzt werden kann und wie das IKS selbst durch das Risikomanagement des Unter
nehmens einem kontinuierlichen Verbesserungsprozess unterliegt.
17.2 Aufbau und Vorgehensmodell des Internen

Kontrollsystems
17.2.1 Aufbau des Internen Kontrollsystems
Nach Bungartz (2011) gliedert sich das IKS in aufbau- und ablauforganisatorische
Kontrollen sowie in Überwachungssysteme.
Die aufbauorganisatorischen Kontrollen spiegeln sich in der Struktur der Aufbauorga
nisation bzw. in der Infrastruktur wider. Beispiele hierfür sind Funktionstrennung,
Kompetenzregelungen oder Zugriffsbeschränkungen im IT-Bereich. Des Weiteren fordern
diese Kontrollen die Definition von Rollen, deren Verantwortungen und Qualifikationen.
Kontrollen in der Ablauf- bzw. Prozessorganisation sollen die effektive und effizi-
ente Durchführung der Geschäftsprozesse sicherstellen. Dies erfolgt durch die teilweise
Implementierung von Kontrollen in den verwendeten IT-Systemen, aber auch durch
Arbeitsanweisungen und Richtlinien, die von den Prozessmitarbeitern einzuhalten
sind.
Die Überwachung dieser aufbau- und ablauforganisatorischen Kontrollen obliegt
in erster Linie der internen Revision, der Geschäftsführung, dem Aufsichtsrat und den
Wirtschaftsprüfern, welche im Zuge der Überwachung den ordnungsgemäßen Aufbau
und Betrieb des IKS sicherstellen sollen. (Bungartz 2011)
Die Implementierung, der Betrieb und die laufende Weiterentwicklung dieses
Systems kann durch Anwendung unseres IKS-Vorgehensmodells, des IKS-Life Cycle,
sichergestellt werden, welches nachfolgend vorgestellt wird.
17.2.2 Vorgehensmodell des Internen Kontrollsystems – Der IKS-

Life Cycle
Der IKS-Life Cycle stellt – wie der Process Management Life Cycle (PMLC, vgl. Kap. 2) –
einen Managementkreislauf dar, der in regelmäßigen Abständen durchlaufen wird und
die kontinuierliche Verbesserung des Prozessmanagement-Systems zum Ziel hat.
Abb. 17.1 Der IKS-Life Cycle
IKS-Strategie
Evaluierung
der Risiken Risikoanalyse
und Kontrollen
Kontrolldefinition
Ausführung der
und
Kontrollen
Risikooptimierung
Implementierung
der Kontrollen
Der IKS-Life Cycle besteht aus den folgenden sechs Phasen, die im Anschluss näher
erläutert werden (vgl. Abb. 17.1):
• IKS-Strategie,
• Risikoanalyse,
• Kontrolldefinition und Risikooptimierung,
• Implementierung der Kontrollen,
• Ausführung der Kontrollen und
• Evaluierung der Risiken und Kontrollen.
17.2.2.1 IKS-Strategie
In der Phase IKS-Strategie wird der Bezug des IKS zum strategischen Managementsystem
hergestellt und das organisatorische Rahmenwerk des IKS auf Basis der strategischen
Zielsetzungen erstellt. „Welche Ziele verfolgt das IKS?“ bzw. „Welche strategischen
Zielsetzungen sollen durch das Interne Kontrollsystem unterstützt werden?“ sind die zentralen
Fragen in dieser Phase. Auf Basis dieser Zielsetzung wird das organisatorische Rahmenwerk
des Internen Kontrollsystems definiert, welches u. a. aus folgenden Elementen besteht:
• Definition der relevanten Rollen,

• Definition des Scope,
• Festlegung der zu verwendenden Methoden im Zuge des IKS-Life Cycle,
• Definition der IT-Unterstützung des IKS und
• Abstimmung des Reporting über das IKS.
17.2.2.2 Risikoanalyse
In der darauffolgenden Phase des IKS-Life Cycle werden die im Scope liegenden Prozesse
einer Risikoanalyse unterzogen. Hierbei werden mögliche Ereignisse oder Entwicklungen
identifiziert, die das Erreichen der definierten Ziele erschweren bzw. unmöglich machen.
Als Grundlagen für die Identifikation von Risiken können, meist in Kombination, ver-
schiedene Methoden angewendet werden, um eine möglichst vollständige Darstellung
des Risikoportfolios des einzelnen Prozesses zu erreichen. Beispiele solcher Methoden
sind die „Prozess-Fehlermöglichkeits- und Einflussanalyse“ (P-FMEA, Process Failure
Mode and Effects Analysis) (Verband der Automobilindustrie (VDA) 2009) oder kreative
Methoden wie Brainstorming. Die Anwendung dieser Methoden führt zu Risiken, die die
Zielerreichung des jeweiligen Prozesses erschweren bzw. unmöglich machen. Mit welcher
Wahrscheinlichkeit diese Risiken eintreten und welche Auswirkung sie beim Eintritt haben,
ist ebenso im Zuge der Risikoanalyse festzulegen. Hierzu stehen qualitative und quantita-
tive Skalenmodelle zur Verfügung, wobei im Bereich der operationellen Risiken meist die
qualitative Bewertung herangezogen wird. Durch die Bewertung der identifizierten Risiken
ergibt sich ein qualifiziertes Risikoportfolio des einzelnen Geschäftsprozesses, welches in
der nächsten Phase einer Optimierung in Form von Kontrolldefinitionen unterzogen wird.
17.2.2.3 Kontrolldefinition und Risikooptimierung

Jedes Risiko, das in der vorangegangenen Phase analysiert wurde, wird nun anhand
der Risikotoleranzgrenzen des Unternehmens bewertet und ggf. mit einer oder mehre-
ren Kontrollen versehen, die das einzelne Risiko vermeiden, vermindern oder abwälzen
sollen. Die Risikotoleranzgrenze des Unternehmens wird durch das Risikomanagement
definiert und gliedert das Risikoportfolio des Unternehmens entlang der Achsen
„Wahrscheinlichkeit“ und „Auswirkung“ in die folgenden drei Kategorien:
• kein Handlungsbedarf,
• Handlungsbedarf und
• akuter Handlungsbedarf.
Die drei genannten Kategorien dienen der Priorisierung der Risikobewältigung. Risiken der
Kategorie „kein Handlungsbedarf“ werden keine Kontrollen gegenübergestellt und daher
bewusst akzeptiert, da sich deren Verminderung oder Vermeidung auf Basis einer Kosten-
Nutzen-Analyse nicht als sinnvoll erweist. Risiken, die der Kategorie „Handlungsbedarf“ zuge-
ordnet werden, sollten mittelfristig durch eine oder mehrere Kontrollen optimiert werden,
da sie einen beträchtlichen Schaden anrichten können. Risiken mit akutem Handlungsbedarf
stellen für die Organisation existenzbedrohende Risiken dar und müssen umgehend durch
geeignete Kontrollmaßnahmen vermieden, vermindert oder abgewälzt werden.
17.2.2.4 Implementierung der Kontrollen

Die zuvor definierten Kontrollen werden im Zuge dieser Phase in der Organisation
nachhaltig verankert. Dies erfolgt im Allgemeinen durch die Implementierung der
Kontrollen:
• als IT-Kontrollen in der bzw. in den betroffenen Applikationen,

• als Arbeitsanweisung für die Mitarbeiter,
• als Kontrollen im Ablauf des betroffenen Prozesses,
• als Kontrolle in der Aufbauorganisation, die z. B. zur Funktionstrennung dient, oder

• als Kontrolle in der Infrastruktur, die IT-Berechtigungen oder Zutrittsbeschränkungen
reguliert.
Nach der Implementierung und der notwendigen Befähigung der betroffenen Mitarbeiter
soll die Durchführung dieser Kontrollen den betroffenen Risiken entsprechend vermin-
dernd oder vermeidend begegnen.
17.2.2.5 Ausführung der Kontrollen

Die in den Vorphasen definierten und implementierten Kontrollen werden in die-
ser Phase gemäß den Vorgaben von den Mitarbeitern bzw. von den betroffenen IT-
Systemen ausgeführt und deren Ausführung wird dokumentiert. Diese Dokumentation
der Kontrolldurchführung, ob positiv erfolgt oder nicht, dient in der nachfolgenden
Phase dazu, das IKS als Ganzes und jede einzelne Kontrolle im Speziellen hinsichtlich
ihrer risikominimierenden Wirkung zu bewerten.
17.2.2.6 Evaluierung der Risiken und Kontrollen

Die Evaluierungsphase stellt das „Controlling“ des IKS dar. In dieser Phase werden alle
operationellen Risiken erneut hinsichtlich ihrer Wahrscheinlichkeit und Auswirkung
bewertet. Dies erfolgt im Zuge einer regelmäßigen Aktualisierung des Risikoportfolios
des Unternehmens, um eine aktuelle Informationsbasis der Risikosituation des
Unternehmens sicherstellen zu können. Die Neubewertung der Risiken lässt auch erste
Rückschlüsse auf die Wirksamkeit der gesetzten Kontrollen zu, da die definierten und
implementierten Kontrollen die Risikowerte positiv beeinflussen sollen. Demnach
sollten sich die betroffenen Risiken hinsichtlich ihrer Wahrscheinlichkeit und/oder
Auswirkung vermindern. Diese Entwicklung der Risiken gibt also Auskunft über die
Wirkungen der Kontrollen, welche im Zuge der Funktionsprüfung durchgeführt wer-
den. In diesem Zusammenhang spricht man auch von der Design Effectiveness. Es
wird demnach geprüft, ob die Kontrolle in der Lage ist, das Risiko positiv hinsichtlich
Eintrittswahrscheinlichkeit und Auswirkung zu beeinflussen. Ist dies nicht der Fall,
verändern sich die Risikowerte nicht, oder entwickeln sie sich sogar negativ, so gilt es
zu analysieren, ob die Kontrolle nicht wirkt oder ob sich das Risiko trotz der gesetz-
ten Maßnahmen erhöht hat. Diese weiterführende Analyse wird als Überprüfung der
Operating Effectiveness bezeichnet. Es wird hierbei überprüft, ob die Kontrolle von den
Mitarbeitern bzw. den IT-Systemen gemäß den Vorgaben durchgeführt wurde.
17.2.2.7 Verankerung des Internen Kontrollsystems

Um dem Anspruch einer kontinuierlichen Verbesserung des IKS zu genügen, führt eine
wiederholte Durchführung des IKS-Life Cycle dazu, das Interne Kontrollsystem nachhal-
tig im Unternehmen zu verankern und laufend zu evaluieren und zu verbessern.
Die Projekterfahrung zeigt, dass in den meisten Fällen ein dreimaliger Durchlauf des
IKS-Life Cycle das IKS in der Organisation nachhaltig verankert, da sich dadurch der
Nachhaltiges
Iteration 3
Internes
Kontrollsystem
Iteration 2
Einführung des
Internen Iteration 1
Kontrollsystems
• Nach der Einführung Nachweis des Nutzens der IKS-Einführung anhand von
Risikobewertungen, Kontrollbewertungen oder Reifegradmodellen
• Weitere Verbesserungen durch wiederholtes Durchlaufen des IKS-Life Cycle
• Kontinuierliche Verbesserung und nachhaltige Verankerung des IKS mit jeder weiteren „Runde“
Abb. 17.2 Verankerung des Internen Kontrollsystems
Lerneffekt der Mitarbeiter einstellt und das IKS als etwas Selbstverständliches angesehen
wird (vgl. Abb. 17.2). Wesentlich hierfür ist es, den Nutzen des IKS für das Prozess- wie
auch für das Risikomanagement laufend ins Bewusstsein der Mitarbeiter zu rufen, die
wesentliche Inputgeber für mögliche Verbesserungen des IKS darstellen.
17.2.3 Integration von Prozess- und Risikomanagement durch den

IKS-Life Cycle
Der IKS-Life Cycle stellt neben einem Vorgehensmodell für das Interne Kontrollsystem
auch die Basis der Integration des Prozessmanagements und Risikomanagements
dar. Abbildung 17.3 zeigt beispielhaft die vielfältige Interaktion von Prozess- und
Risikomanagement im Zuge des Internen Kontrollsystems.
Diese Übersicht stellt deutlich die vielfältigen Schnittstellen zwischen dem Prozessma
nagement und dem Risikomanagement durch das IKS dar. Die Pfeilrichtungen in den
einzelnen Phasen des IKS-Life Cycle stellen den In- bzw. Output dar, welcher vom IKS in
Richtung des Prozessmanagements bzw. des Risikomanagements empfangen bzw. geliefert
wird. Daraus kann z. B. in der Phase der Risikoanalyse (vgl. Abschn. 17.2.2.2) entnommen
werden, dass der Input für die Risikoanalyse durch das Prozessmanagement geliefert wird,
der Output der Risikoanalyse in das unternehmensweite Risikoportfolio Einzug findet und
hier das IKS als „Lieferant“ für das Unternehmens-Risikomanagement fungiert.
Im Zuge der näheren Betrachtung der Schnittstellen des IKS zum Prozessma
nagement wie auch zum Risikomanagement soll in den nachfolgenden Abschnitten im
Detail auf das IKS als Erfolgsfaktor des Prozessmanagements und auf die Optimierung
des IKS im Zuge des Risikomanagements eingegangen werden.
Prozessmanagement IKS-Life Cycle Risikomanagement

Ziel: Minimierung
Ziel: Sicherstellung von des Risikoportfolios
Effektivität und Effizienz von IKS-Strategie
Geschäftsprozessen Risikomanagement-
Rahmenwerk/Risikopolitik
Geschäftsprozesse Risikoportfolio
Risikoanalyse
werden analysiert der operationellen Risiken
Kontrolldefinition
Optimieren der Geschäfts- Optimierung des Risikoportfolios
und
prozesse durch Kontrollen der operationellen Risiken
Risikooptimierung
Aktualisierung der Implementierung

Prozessdokumentation der Kontrollen
Ausführung der
Kontrollen
Evaluierung
Sicherstellung Effektivität und Sicherstellung der gewünschten
der Risiken
Effizienz der Geschäftsprozesse Entwicklung des Risikoportfolios
und Kontrollen
Abb. 17.3 Integration des Prozess- und Risikomanagements durch den IKS-Life Cycle
17.3 Das Interne Kontrollsystem als Erfolgsfaktor des

Prozessmanagements
Die Integration von Prozessmanagement und IKS kann z. B. anhand der beiden Vorgehens
modelle vorgenommen werden. So zeigt Abb. 17.4 anhand des Process Management Life
Cycle (PMLC) und des IKS-Life Cycle, welche wesentlichen Informationen in den einzel-
nen Phasen zwischen diesen Systemen ausgetauscht werden und jeweils wichtige Inputdaten
darstellen.
Wie das Interne Kontrollsystem einen Erfolgsfaktor des Prozessmanagements im
Rahmen des PMLC darstellen kann, wird in den nachfolgenden Abschnitten anhand der
PMLC-Phasen detailliert diskutiert.
17.3.1 Prozessstrategie: Das Interne Kontrollsystem unterstützt den

Prozessverantwortlichen bei der Erreichung der Prozessziele
Gemäß der einleitenden Definition dient das IKS der Erreichung von Zielen in den
Bereichen der Finanzberichterstattung, der Einhaltung von geltenden Gesetzen,
Richtlinien oder unternehmensinternen Vereinbarungen (z. B. Corporate Governance)
PMLC Prozessmanagement IKS-Life Cycle
Prozessstrategie Ziel: Sicherstellung von

Effektivität und Effizienz von IKS-Strategie
Geschäftsprozessen
Prozessdokumentation Geschäftsprozesse
Risikoanalyse
werden analysiert
Prozessoptimierung Kontrolldefinition
Optimieren der Geschäfts-
und
prozesse durch Kontrollen
Risikooptimierung
Prozessumsetzung Aktualisierung der Implementierung

Prozessdokumentation der Kontrollen
Prozessdurchführung Ausführung der

Kontrollen
Prozesscontrolling Evaluierung
Sicherstellung Effektivität und
der Risiken
Effizienz der Geschäftsprozesse
und Kontrollen
Abb. 17.4 Integration von Prozessmanagement und IKS
sowie der Erreichung von betrieblichen Zielen (The Committee of Sponsoring

Organization of the Treadway Commission (COSO) 2004/2006; Bungartz 2011).
Beispiele solcher betrieblicher Ziele sind:
• die Steigerung der Effektivität und Effizienz von Organisationseinheiten und

Geschäftsprozessen,
• die Erhöhung der Kundenzufriedenheit,
• die Verkürzung der Durchlaufzeiten (Bungartz 2011),
• die Verkürzung von Produktlebenszyklen sowie
• die Erhöhung des Automatisierungsgrads der Geschäftsprozesse (Horváth und
Partners 2007).
Diese betrieblichen Ziele sind es, die, wie in Abschn. 2.4.1 Prozessstrategie darge-
stellt, als Prozessziele von übergeordneten Unternehmenszielen abgeleitet wurden (vgl.
ebenso Kap. 4). Im Zuge dieser Phase wurden den einzelnen Prozessen ein oder meh-
rere Prozessziele zugewiesen, die der Prozessverantwortliche mit seinen Mitarbeitern
versucht zu erreichen. Geht der Prozessverantwortliche mit den vorhandenen, limitier-
ten Ressourcen bewusst um, so zählt es auch zu seinen Aufgaben abzuwägen, welche
Probleme, Gefahren oder negative Entwicklungen die Erreichung dieser Prozessziele
erschweren bzw. unmöglich machen. Gegen diese operationellen Risiken wirkt das IKS,
um diese Risiken zu minimieren bzw. sogar zu vermeiden und um im Umkehrschluss

die Erreichung der Prozessziele zu unterstützen. Somit dient das IKS dem einzelnen
Prozessverantwortlichen dazu, seine Ziele zu erreichen sowie dem Prozessmanagement
als System, den geforderten Beitrag zur Erreichung der strategischen Ziele zu leisten.
Das IKS, z. B. in Form des IKS-Life Cycle, dient dem Prozessverantwortlichen als
methodisches Rahmenwerk, um diese möglichen Gefahren oder negativen Entwicklungen
systematisch zu identifizieren und zu bewerten. Daraus können in weiterer Folge
Handlungsmaßnahmen dagegen abgeleitet werden.
17.3.2 Prozessdokumentation: Analyse der operationellen Risiken

im Geschäftsprozess
Die Risikoanalyse dient zur Identifikation und Bewertung möglicher negativer

Entwicklungen oder Gefahren, die die Erreichung der Prozessziele erschweren oder
unmöglich machen oder die die Prozessdurchführung in effektiver und effizienter
Weise behindern. Daher stellt die Prozessdokumentation (vgl. ebenso Abschn. 2.4.2) die
wesentliche Basis für die Risikoanalyse wie auch für die Dokumentation dar.
Der Risikoanalyse geht gemäß der ONR 49000 (Austrian Standards 2010a) die
Festlegung der Rahmenbedingungen für ebendiese Risikoanalyse voraus (Abb. 17.5).
Diese Rahmenbedingungen umfassen folgende Punkte:
• den Betrachtungsgegenstand der Risikoanalyse,

• die involvierte Rollen,
• die angewendeten Methoden sowie
• den Gültigkeitszeitraum.
Der Betrachtungsgegenstand der Risikoanalyse beschreibt die Elemente des Geschäfts

prozesses, welche untersucht werden. Meist sind dies die Prozessziele an sich, die ein- und
ausgehenden Schnittstellen, die einzelnen Aktivitäten, die verwendeten IT-Systeme sowie
Dokumente, wie Arbeitsanweisungen oder Formulare. Die weiteren Rahmenbedingungen
werden in den folgenden Abschnitten detaillierter erläutert.
17.3.2.1 Involvierte Rollen
Bevor die einzelnen Betrachtungsgegenstände des Geschäftsprozesses untersucht werden
können, ist zu klären, welche Personen an der Risikoanalyse teilnehmen sollten, um eine
möglichst hohe Quote bei der Entdeckung von Risiken des Geschäftsprozesses zu erzie-
len. Je nach definiertem Betrachtungsgegenstand sind dies:
• der Prozessverantwortliche,
• der Prozessexperte bzw. Prozessmitarbeiter,
• der Prozess- bzw. IKS-Berater und/oder
• der Prozesscontroller.
Geschäftsprozess
Definition/Zuordnung von Kontrollen auf Aktivitätsebene
Risiken Kontrollen
Abb. 17.5 Dokumentierter Geschäftsprozess inkl. Risiken und Kontrollen
Im Zuge der Risikoanalyse ist es oft hilfreich, auch eine fachbereichsfremde Person hin-
zuzuziehen, um die „Betriebsblindheit“ der genannten Rollen zu kompensieren.
17.3.2.2 Angewendete Methoden
Wie in Abschn. 17.2.2.2 beschrieben, kann eine Reihe verschiedener Methoden verwen-
det werden, um operationelle Risiken zu identifizieren und zu bewerten. Abbildung 17.6
zeigt häufig angewendete Methoden gemäß ihrer Eignung zur Identifikation und
Bewertung von Risiken.
Abb. 17.6 Methoden der

Risikoanalyse (Austrian Auswahl Methoden der Risikoanalyse
Standards 2010b)
Methode Identifikation Bewertung
Brainstorming +++ +
FMEA +++ ++
Szenarioanalysen +++ +++
CIRS +++ +
Brainstorming
Im Zuge von Brainstorming-Workshops identifizieren die involvierten Personen die mög-
lichen Problemfelder des Geschäftsprozesses und dessen Betrachtungsobjekte (Brühwiler
2007). Hierzu werden neben anderen Hilfsmitteln sogenannte Key Questions verwendet,
wie z. B.:
• Was hindert die Prozessmitarbeiter daran, die Prozessziele zu erreichen?

• Welche Erfolgsfaktoren beeinflussen das Prozessergebnis und wie können diese nega-
tiv beeinflusst werden?
• Was hindert die Prozessmitarbeiter daran, den Prozess in einem angepassten zeitli-
chen und finanziellen Rahmen und unter Einhaltung der Vorgaben durchzuführen?
• Welche Probleme können seitens der IT auftreten?
Sehr gerne werden diese Fragen mit vorgefertigten Gefahrenlisten kombiniert, um

Risiken aus allen relevanten Themengebieten zu berücksichtigen, so z. B.:
• Prozessrisiken (fehlerhafte Dateneingabe, mangelhafte Kundenberatung, unzulässige

Geschäftspraktiken etc.),
• Systemrisiken (Hardwarefehler, Softwarefehler, Versorgungsstörung etc.),
• Personenrisiken (unbefugte Handlung, Betrug, Diebstahl etc.) sowie
• externe Risiken (Betrug, Angriffe auf Systemsicherheit, Diebstahl etc.).
Da Brainstorming zu den Kreativitätstechniken zählt, eignet es sich sehr gut zur Identifikation
von möglichen Risiken, jedoch weniger zur Bewertung derselben (Brühwiler 2007).
FMEA
Die Fehlermöglichkeits- und Einflussanalyse (FMEA oder Funktionsanalysen bzw. engl.
Failure Mode and Effects Analysis) ist eine weit verbreitete Methode im Bereich des
Risikomanagements (Werdich 2011). Dabei werden technische wie auch organisatorische
Systeme und Produkte in ihre Komponenten aufgeteilt. Diese wiederum werden in

Funktionen zerlegt und jede Funktion wird in Bezug auf Fehler, Gefährdungen und
Abweichungen hin untersucht. Für gefundene Gefährdungen werden Ursachen analy-
siert, gegen welche Maßnahmen ergriffen werden. Beispiele sind die „System-FMEA“, die
„Design-FMEA“ und die „Prozess-FMEA“.
Bei der Prozess-FMEA (oder P-FMEA), welche für die Analyse von operationellen
Risiken in Geschäftsprozessen dient, geht man entsprechend nachfolgender Schritte vor:
1. Dokumentation des Prozesses und seiner Teilprozesse und Aktivitäten

2. Festlegung der Funktionen der einzelnen Teilprozesse und Aktivitäten (Transformation
Input zu Output)
3. Identifikation von Fehlern bzw. von Fehlfunktionen
4. Analyse der Ursachen der Fehler bzw. der Fehlfunktionen
5. Treffen von Maßnahmen zur Verhinderung, Verminderung etc.
Die Bewertung der Risiken findet in jeder FMEA durch Anwendung der Risikoprioritätszahl
statt. Die Risikoprioritätszahl (RPZ) ist das Produkt der Wahrscheinlichkeit des Auftretens,
der Auswirkung und der Wahrscheinlichkeit des Entdeckens des Risikos, wobei für jede die-
ser drei Dimensionen eine gewisse maximale Punktzahl vergeben werden kann. Die daraus
resultierende RPZ kann in weiterer Folge gut mit der Risikotoleranz des Unternehmens ver-
glichen werden, um entsprechende Maßnahmen abzuleiten (Brühwiler 2007).
Szenarioanalysen
Szenarioanalysen sind sowohl für die Identifikation als auch die Bewertung von operati-
onellen Risiken sehr gut geeignet. Eine oft angewendete Methode dieser Kategorie stellt
die „Fehlerbaum- und Ablaufanalyse“ dar, welche nachfolgend beschrieben wird.
Die Fehlerbaum- und Ablaufanalyse oder Analyse von „Top Events“ definiert ein
unerwünschtes, fiktives, negatives Ereignis und bestimmt alle Möglichkeiten, wie ein sol-
ches eintreten könnte. Diese Ursachen werden optisch in einer Baumdarstellung logisch
verknüpft und wenn möglich mit Wahrscheinlichkeiten belegt. Basierend darauf kann
die Eintrittswahrscheinlichkeit des Top Events näherungsweise sehr gut bestimmt wer-
den. Ausgehend von diesem Top Event werden im Zuge der Ablaufanalyse die mögli-
chen Ablaufszenarien des Ereignisses dargestellt (vgl. Abb. 17.7).
Die Fehlerbaum- und Ablaufanalyse findet meist auf aggregierter Ebene (Bereich
Prozesslandkarte) Anwendung, wobei mehrere Prozesse in Betracht gezogen werden, um ein
übergeordnetes, meist strategisches Ziel einer Risikoanalyse zu unterziehen. Die Ursachen
dieses negativen Ereignisses werden den betroffenen Geschäftsprozessen zugeordnet und
gemäß ihrer Wahrscheinlichkeit bewertet. Die Eintrittswahrscheinlichkeit des Top Event
kann nun auf Basis der Einzelwahrscheinlichkeiten ermittelt werden (Brühwiler 2007).
CIRS
Ein Critical Incidents Reporting System (CIRS) ist ein weit verzweigtes Meldesystem in
einer Organisation, bei dem sogenannte Vorkommnisse gesammelt und ausgewertet
Fehlerbaum Ereignisbaum
Folgeereignis
W1 Ursache 1
1
W2 Ursache 2
Folgeereignis
2
W3 Ursache 3 Top
Event
Folgeereignis
n
Wn Ursache n Wtop
Einzelwahrscheinlichkeiten Wahrscheinlichkeit Top Event
Logische UND-Verknüpfung Logische ODER-Verknüpfung Verzweigung
Abb. 17.7 Fehlerbaum- und Ablaufanalyse (Brühwiler 2007, S. 132)
werden, die beinahe zu einem Schaden hätten führen können. Je mehr eine Organisation
über kritische Vorkommnisse weiß, desto besser kennt sie ihre Risiken, deren Häufigkeit
und Fehlerquellen in den betrieblichen Abläufen. Dabei ist CIRS nicht zu verwechseln
mit einem Schadenmeldesystem, wo eingetretene Schadensfälle gesammelt und ausge-
wertet werden. Gängige Anwendungsgebiete des CIRS sind die Luftfahrt, der öffentliche
Verkehr und die klinischen Pfade im Gesundheitsbereich (Brühwiler 2007).
17.3.2.3 Definition des Gültigkeitszeitraums der Risikoanalyse

Natürlich ist die initiale Risikoanalyse nicht ausreichend für ein nachhaltiges Risikoma
nagement, welches den Anspruch verfolgt, das Risikoportfolio des Unternehmens laufend
zu aktualisieren. Demnach sind selbstverständlich auch die Risikoanalysen der Geschäfts
prozesse in regelmäßigen Abständen zu wiederholen, um festzustellen ob:
• sich Eintrittswahrscheinlichkeiten oder Auswirkungen von bereits identifizierten

Risiken geändert haben oder
• neue Risiken hinzugekommen sind.
17.3.3 Prozessoptimierung: Optimierung der Geschäftsprozesse

durch den IKS-Life Cycle
Gemäß Abschn. 2.4.3 Prozessoptimierung sollen die Prozesse im Sinne der definierten
Prozessziele hinsichtlich Effektivität und Effizienz optimiert werden. Dem PMLC folgend
fließen die analysierten Risiken in die Priorisierung der möglichen Optimierungsprojekte
ein und legen neben den weiteren Kriterien, wie z. B. der strategischen Relevanz, dem
Handlungsbedarf akuter Handlungsbedarf

Wahrscheinlichkeit
Risikoportfolio
kein Handlungsbedarf Handlungsbedarf
Auswirkung
Abb. 17.8 Risikoportfolio
Ergebnis der Kosten-Nutzen-Analyse, der Anzahl der Prozessdurchläufe oder der Größe des
jeweiligen Handlungsbedarfs, jene Optimierungsprojekte fest, welche durchzuführen sind.
Den Handlungsbedarf der analysierten Risiken kann man z. B. anhand einer Risikoport
folio-Darstellung ableiten (vgl. Abb. 17.8), welche die Risiken den drei Kategorien:
• kein Handlungsbedarf,
• Handlungsbedarf und
• akuter Handlungsbedarf
zuordnet (vgl. ebenso Abschn. 17.2.2.3).

Risiken, die in den Bereichen „Handlungsbedarf“ und „akuter Handlungsbedarf“
liegen, sind im Zuge der Optimierung des Risikoportfolios derart zu behandeln, dass
sie sich entsprechend ihrer Wahrscheinlichkeit und Auswirkung verringern oder sie
sogar vermieden werden können. Dies erfolgt für operationelle Risiken in Form von
Kontrollen, die aufbau- oder ablauforganisatorisch festgelegt werden und den gewünsch-
ten Effekt bei den Risiken erzielen sollen.
Die so definierten Kontrollen können verschiedenen Kategorien zugeordnet werden,
wie z. B.:
• Automatische Kontrollen
• Benutzerberechtigungen, automatische Benachrichtigungen, Alarming (Hinweis-
oder Fehlermeldungen), automatische Problembehandlung, Plausibilitätsprüfungen,
Summenprüfungen etc.
• Semiautomatische Kontrollen
• Authentifizierung, erforderliche Benutzerbestätigung, Log-Dateien, Alarming etc.
• Manuelle Kontrollen
• 4-Augen-Prinzip, manuelle Validierung, Sichtkontrolle, Überprüfung etc.
Nach der Art der Einbindung in den Geschäftsprozess kann man die Kontrollen nach
folgenden Arten gruppieren:
• Parallele Kontrollen
Hierbei erfolgen die Bearbeitungsschritte gleichzeitig und die Ergebnisse werden mit-
einander verglichen.
• Serielle Kontrollen
Bei dieser Kontrollart werden Arbeitsergebnisse verglichen, die zu unterschiedlichen
Zeitpunkten entstehen.
• Redundante Kontrollen
Zu Kontrollzwecken ist es hierbei erforderlich, Bearbeitungen zu wiederholen, um
sicherzustellen, dass zuvor das richtige Ergebnis erzielt wurde.
• Plausibilitätskontrollen
Das Arbeitsergebnis wird nach vorgegebenen Regeln, auch zeitlich versetzt, auf
Stimmigkeit und Korrektheit überprüft.
Vielfach wird eine Kombination der verschiedenen Kontrolltypen eingesetzt, um einen

entsprechenden Effekt bei der Verminderung oder Vermeidung von Risiken zu erzielen.
Generell sind Kontrollen anzustreben, die vorgelagert und vollautomatisch durchgeführt
werden (Bungartz 2011).
Vorgelagerte Kontrollen werden vor dem Teilprozess oder der Aktivität durchgeführt,
welche das bzw. die Risiken beinhalten und wirken so präventiv gegen das Risiko. Zu
dieser Art von Kontrollen zählen z. B. Zugangskontrollen, Authentifizierungskontrollen
sowie Freigabekontrollen. Automatische Kontrollen werden vom unterstützenden IT-
System selbstständig, ohne Benutzerinteraktion durchgeführt. Somit kann gewährleistet
werden, dass die Kontrolle an der festgelegten Stelle in der definierten Art durchgeführt
wird.
Diese Kontrollen fließen im Zuge der Prozessoptimierung in die Erarbeitung von
Soll-Prozessvarianten ein, wobei nicht jede Kontrolle unbedingt einen neuen Aktivitäts
schritt bedeuten muss. An der Ausprägung der zugrunde liegenden Risikowerte und
dem daraus resultierenden Handlungsbedarf (siehe Risikoportfolio) orientiert sich die
Frequenz der Kontrollausführung, welche von „pro Prozessdurchlauf“ bis „einmal jähr-
lich“ reichen kann. In welcher Form die jeweilige Kontrolle schlussendlich in die Soll-
Prozessvariante einfließt, entscheidet der Prozessverantwortliche in Abstimmung mit
dem IKS-Verantwortlichen. Der Prozessverantwortliche muss einerseits die positive
Auswirkung der Kontrolle den daraus resultierenden Erhöhungen von Durchlaufzeiten
und Kosten gegenüberstellen. Darüber hinaus wird im Zuge der Umsetzungs- und
Machbarkeitsstudie (vgl. ebenso Abschn. 2.4.3) das Design der Kontrolle abgeleitet und
festgelegt.
17.3.4 Prozessumsetzung: Überwachung der Prozessumsetzung

durch das Interne Kontrollsystem
Wie in Abschn. 2.4.4 Prozessumsetzung beschrieben, wird im Zuge dieser Phase des
PMLC der Soll-Prozess „zum Leben erweckt“ und die Prozessmitarbeiter führen diesen
Prozess innerhalb eines bestimmten Zeitraums (teilweise zu Testzwecken) durch. In die-
ser Anfangsphase des neuen Prozesses ist es wichtig, dem Prozessverantwortlichen ein
Instrument zur Überwachung und ggf. Steuerung der Prozessumsetzung zur Verfügung
zu stellen. Vermehrte Stichproben oder definierte Kontrollpunkte sind Beispiele für tem-
poräre Kontrollen, die als Teil des IKS die Einführung von Soll-Prozessen und deren
Einhaltung unterstützen sollen. Im Sinne ihrer Aufgabe dienen Kontrollen dazu, die neu
gestalteten Prozesse einzuhalten und durchzuführen. Sobald diese Anfangsphase been-
det wurde und der Prozess in das „daily business“ übergeht, können diese anfänglichen
Kontrollen teilweise reduziert werden.
17.3.5 Prozessdurchführung: Sicherstellung der

ordnungsgemäßen, effektiven und effizienten
Prozessdurchführung durch das Interne Kontrollsystem
Neben der Erhebung von Messdaten für Prozesskennzahlen sowie kurzfristigen Problem
lösungen steht vor allem die Durchführung der Prozesse im Tagesgeschäft im Fokus der
PMLC-Phase Prozessdurchführung (vgl. ebenso Abschn. 2.4.5).
Die implementierten Kontrollen des IKS sollen im Zuge dieser Phase die Erreichung
der Prozessziele sicherstellen, wie sie in Abschn. 2.4.1 Prozessstrategie definiert wurden.
Hierzu wurden verschiedenste Kontrollen gemäß deren Definition in den nachfolgenden
Bereichen implementiert:
• Infrastruktur,
• Personal,
• Organisation/Prozesse,
• Hardware/Software,
• Kommunikation und
• Notfall- und Krisenmanagement.
Im Rahmen der Prozessdurchführung werden auch die Kontrollen des Internen Kontroll
systems ausgeführt, teilweise automatisch, teilweise halbautomatisch oder manuell durch
die Mitarbeiter des Unternehmens. Bei Kontrollen, die nicht automatisch durch ein IT-
System ausgeführt werden, muss sichergestellt werden, dass diese Anwendung finden und
durch die Mitarbeiter nicht bewusst oder unbewusst außer Acht gelassen werden. Daraus
ergibt sich der Bedarf der Überwachung und Sicherstellung der Kontrolldurchführung.
Zu diesem Zweck werden Monitoring-Kontrollen verwendet, die die Durchführung der
operativen Kontrollen im Prozessablauf sicherstellen sollen. Diese Monitoring-Kontrollen

werden meist als Stichprobenkontrollen durchgeführt, aber auch als „Walk-through“,
durch Sichtung von Arbeitsunterlagen oder IT-Log-Dateien.
Nicht jede operative Kontrolle muss mit einer Monitoring-Kontrolle versehen wer-
den. Jedoch wird empfohlen, für die folgenden operativen Kontrollen ein Monitoring
vorzusehen:
• Kontrollen der Vorbereitung, Initiierung und Genehmigung von Transaktionen,

• Kontrollen im Zuge der Finanzberichterstattung,
• Kontrollen der Vermeidung von betrügerischen Handlungen,
• Kontrollen für nicht-routinemäßige Prozesse bzw. für Schätzungen sowie
• Kontrollen auf Ebene der Unternehmensführung (Bungartz 2011).
17.3.6 Prozesscontrolling: Bewertung der Zielerreichung durch das

Interne Kontrollsystem
Wie in Abschn. 2.4.6 beschrieben, werden im Rahmen des Prozesscontrollings die

Prozessziele hinsichtlich ihrer Erreichung analysiert. Hierzu werden Messdaten auf-
bereitet, welche während der Prozessdurchführung gesammelt wurden. Neben diesen
definierten Messdaten, meist für Qualität, Zeit und Kosten, stehen auch die Daten der
Kontrollen dieser Prozesse für die Analyse zur Verfügung.
Die Kontrollen bzw. deren Durchführungsdokumentationen geben Aufschluss darü-
ber, unter welchen Bedingungen diese Prozessziele erreicht wurden. In der Dokumentation
der Durchführung der jeweiligen Kontrolle wird festgehalten, ob die Kontrolle erfolgreich
durchgeführt wurde oder ob dies nicht möglich war. Sollte die Kontrolldurchführung nicht
möglich gewesen sein, sind die Kontrollverantwortlichen angehalten, den Sachverhalt zu
dokumentieren, warum eine erfolgreiche Durchführung nicht möglich war. Dieser Input
kann natürlich neben vielen anderen Erfahrungen als „Lessons Learned“ verwendet wer-
den. Diese Lessons Learned sind es wiederum, die Verbesserungspotenziale darstellen und
in der Phase der Prozessoptimierung des PMLC strukturiert realisiert werden können.
Das IKS kann somit innerhalb des Prozesscontrollings zur Reflexion der Erreichung
der Prozessziele genutzt werden und im weiteren Verlauf so zur kontinuierlichen
Verbesserung der Geschäftsprozesse beitragen.
17.4 Optimierung des Internen Kontrollsystems durch das

Risikomanagement
Wie in Abschn. 17.2.2.6 „Evaluierung der Risiken und Kontrollen“ beschrieben wurde,
wird auch an das IKS der Anspruch der laufenden Optimierung gestellt, welcher im
Kontext des unternehmensweiten Risikomanagements umgesetzt werden kann.
Neben der Identifikation und Bewertung von Risiken ist die laufende Optimierung
des Risikoportfolios des Unternehmens eines der grundlegenden Ziele des unter-
nehmensweiten Risikomanagements. So fordern Risikomanagement-Standards, wie
z. B. das COSO II-Rahmenwerk, die laufende Überwachung und Verbesserung des
Risikomanagements (The Committee of Sponsoring Organization of the Treadway
Commission (COSO) 2004/2006). Während dieser laufenden Überwachung und
Optimierung werden natürlich auch die Instrumentarien hinterfragt, welche die Risiken
der Organisation vermeiden oder vermindern sollen. Demzufolge ist auch das IKS im
Fokus dieser Optimierungsbestrebungen, weil es gegen einen wesentlichen Teil des
Risikoportfolios des Unternehmens wirkt – den Teil der operativen Risiken.
Im Zuge der IKS-Life Cycle-Phase Evaluierung der Risiken und Kontrollen wird diesen
Optimierungsbestrebungen des Risikomanagements Rechnung getragen, indem die einzelnen
Kontrollen auf ihre Funktion hin untersucht werden und das IKS als System evaluiert wird.
17.4.1 Funktion der Kontrolle prüfen
Im Detail werden die einzelnen Kontrollen in einer Prüfung hinsichtlich ihrer Effektivität
und Effizienz evaluiert. Durch die laufende Überprüfung der Kontrollen soll die dauer-
hafte Wirksamkeit des IKS unter Berücksichtigung des Ressourceneinsatzes und damit die
Effektivität und Effizienz des Internen Kontrollsystems gewährleistet werden.
Zu diesem Zweck wird für jede Kontrolle definiert, in welchen Abständen diese
Funktionsprüfung durchzuführen ist, jedoch mindestens einmal im Jahr. Die Frequenz der
Bewertung der Kontrollen richtet sich nach verschiedenen Gesichtspunkten, wie z. B.:
• Häufigkeit der Kontrolldurchführung

Je öfter die Durchführung, desto kürzer das Bewertungsintervall.
• Art der Kontrolle
Manuell oder automatisch, präventiv oder detektiv (Manuell-detektive Kontrollen
sind in kürzeren Abständen zu bewerten).
• Priorität der Kontrolle
Wird die Kontrolle als Abschlusskontrolle bei Prozessen mit Schnittstellen zu
Kunden oder anderen Interessensgruppen verwendet, sollte auch hier eine kürzere
Bewertungsfrist angesetzt werden.
Bei jeder Bewertung einer Kontrolle wird eine Überprüfung auf die Design Effectiveness
durchgeführt und die operative Effektivität (engl. Operating Effectiveness) überprüft. Dabei
wird die Design Effectiveness der Kontrolle insofern überprüft, ob sie in der Lage ist, dem
adressierten Risiko zu begegnen. Bei der Überprüfung der operativen Effektivität (engl.
Operating Effectiveness) wird festgestellt, ob die Kontrolle in der Art durchgeführt wird, wie
es die Definition erfordert, und ob die Personen, die die Kontrolle durchführen, über die not-
wendige Qualifikation und Kompetenz verfügen (Bungartz 2011). Für die Funktionsprüfung
Abb. 17.9 Reifegrad der Reifegrad der Kontrolle

Kontrolle (in Anlehnung an
Optimiert
Bungartz 2011)
Überwacht
(5)
Definiert
(4)
Wieder-
holbar
(3)
Initial
(2)
(1)
• Nicht verlässliche Kontrolle
1
• Die Kontrolle wird nur fallweise ausgeführt
• Fehlende Nachvollziehbarkeit der Kontrolle

2 • Personenbezogene Kontrolle
• Keine Dokumentation der Kontrolldurchführung
• Integrierte Kontrolle (im Geschäftsprozess)

3 • Nachvollziehbarkeit der Kontrolle ist gegeben
• Dokumentation der Kontrolldurchführung
• Regelmäßige Bewertung der Kontrolle

4
• Laufende Aktualisierung der Kontrolle
• Automatisierung der Kontrolle

5
• Kontrolle ist präventiv
der Kontrollen wird meist die Dokumentation der Kontrolldurchführung aus der vorange-
gangenen Phase oder das Ergebnis der Monitoring-Kontrollen herangezogen und z. B. durch
Stichprobenkontrollen überprüft. Die Überprüfungen der Design Effectiveness und der
Operating Effectiveness führen zu einer umfassenden Bewertung der Kontrolle, die zu einer
Beibehaltung der Kontrolle, zu einer Verbesserung der bestehenden Kontrolle oder zu einem
Ablösen der derzeitigen Kontrolle durch eine neue Kontrolle führen kann.
Die durch die Funktionsprüfung gesammelten Ergebnisse für die Wirksamkeit und
Funktion der Kontrolle können anhand eines Reifegradmodells Aufschluss über die
Qualität der einzelnen Kontrolle geben. Das in Abb. 17.9 dargestellte Reifegradmodell,
welches sich am CMMI-Reifegradmodell (Capability Maturity Model Integration) (CMMI
Institute and Clearmodel 2013) orientiert, soll dies beispielhaft veranschaulichen.
17.4.2 Evaluierung der Organisation des Internen Kontrollsystems
Die vorangegangenen Bewertungen sind ein wesentlicher Bestandteil der Evaluierung

des IKS. Neben den einzelnen Funktionsprüfungen der Kontrollen kann auch die
Organisation des Internen Kontrollsystems evaluiert werden. Dazu können einerseits
IKS-Kennzahlen verwendet werden, die Aufschluss über die Qualität des IKS geben.
Andererseits können ebenso Evaluierungsfragen, die auf das IKS angewendet werden
können, eingesetzt werden.
Als Beispiele für Kennzahlen des IKS können folgende verwendet werden:
• Verhältnis vorgelagerte/nachgelagerte Kontrollen,

• Verhältnis automatische/manuelle Kontrollen,
• Anzahl der Kontrollen auf Unternehmensführungsebene und Prozessebene,
• Anteil von Kontrollen mit wesentlichen Kontrollschwächen/ungelösten Schwächen sowie
• Grad der Abdeckung der Kontrollziele pro Prozess durch Kontrollen. (Bungartz 2011)
Mithilfe folgender beispielhafter Evaluierungsfragen kann das IKS speziell hinsichtlich

seines Aufbaus und Umfangs evaluiert werden:
• Ist der Fokus des IKS (Organisationseinheiten, Prozesse, Ziele) angemessen?

• Ist die technische Unterstützung des IKS ausreichend?
• Haben die Mitarbeiter Kenntnis über ihre Rollen und führen sie diese aus?
• Liegen Beanstandungen seitens des Wirtschaftsprüfers oder der internen Revision vor?
• Liegen den zuständigen Personen Berichte der Revision oder Aufsichtsbehörden vor?
Wie die einzelnen Kontrollen kann das IKS als System ebenfalls anhand des bereits ver-
wendeten Reifegradmodells bewertet werden (vgl. Abb. 17.10).
Durch die Bewertung des IKS anhand der Reifegradskala können Handlungs
maßnahmen zur Verbesserung des IKS, wie auch zur Verbesserung von einzelnen
Abb. 17.10 Reifegrad des IKS Reifegrad des IKS

(in Anlehnung an Bungartz
2011) Optimiert
Überwacht
(5)
Definiert
(4)
Wieder-
holbar
(3)
Initial
(2)
(1)
• Kontrollen sind kaum oder nicht vorhanden

1 • Vorhandene Kontrollen sind nicht verlässlich
• Das IKS ist nicht als System oder Organisation definiert
• Kontrollen vorhanden, nicht als IKS wahrgenommen

2 • Nachvollziehbarkeit der Kontrollen nicht gegeben
• Keine Kommunikation der Kontrollen
• Dokumentation des IKS

3 • Kontrollen sind Teil der Geschäftsprozesse
• Regelmäßige IKS-Schulungen finden statt
• Regelmäßige Bewertung der Kontrollen

4 • Monitoring-Kontrollen sind etabliert
• Regelmäßiges Reporting des IKS
• IKS und Risikobewusstsein stark im Untern. ausgeprägt

5 • IKS wird umfassend durch die IT unterstützt
• IKS ist Teil eines integrierten Managementsystems
Kontrollen, abgeleitet werden. Diese Handlungsmaßnahmen zur laufenden Optimierung

werden im Zuge des nächsten Durchlaufs des IKS-Life Cycle herangezogen, um das IKS
und dessen Elemente zu verbessern.
Damit erfüllt das IKS einerseits den Anspruch des Risikomanagements der kon-
tinuierlichen Verbesserung und andererseits stellt das IKS somit einen langfristigen
Erfolgsfaktor für das Prozessmanagement dar.
Literatur
Austrian Standards (2010a) Risikomanagement für Organisationen und Systeme – Begriffe und
Grundlagen – Umsetzung von ISO 31000 in die Praxis, Arbeitsbericht, ONR 49000, Wien. https:/
/www.astandis.at/shopV5/search/Details.action?dokkey=347213. Zugegriffen: 13. Jan 2013
Austrian Standards (2010b) Risikomanagement für Organisationen und Systeme, Teil 2: Leitfaden
für die Methoden der Risikobeurteilung, Arbeitsbericht, ONR 49002-2, Wien. https://www.asta
ndis.at/shopV5/search/Details.action?dokkey=347216. Zugegriffen: 13. Jan 2013
Brühwiler B (2007) Risikomanagement als Führungsaufgabe: Unter Berücksichtigung der neuesten
Internationalen Standardisierung, 2. Aufl. Haupt, Bern
Bungartz O (2011) Handbuch Interne Kontrollsysteme (IKS): Steuerung und Überwachung von
Unternehmen, 2. Aufl. Erich Schmidt, Berlin
Eisele B (2004) Value-at-Risk-basiertes Risikomanagement in Banken: Portefeuilleentscheidungen,
Risikokapitalallokation und Risikolimitierung unter Berücksichtung des Bankenaufsichtsrechts,
Deutscher Universitätsverlag, Wiesbaden
Horváth & Partners (Hrsg) (2007) Balanced Scorecard umsetzen, 4. Aufl. Schäffer-Poeschel, Stuttgart
Oesterreichische Nationalbank (OeNB), Finanzmarktaufsicht (FMA) (2005) Leitfaden:
Management des operationellen Risikos, Leitfaden, Wien. http://www.oenb.at/de/img/lf_opera
tionelles_risiko_tcm14-36314.pdf. Zugegriffen: 08. Jan 2013
The Committee of Sponsoring Organization of the Treadway Commission (COSO) (2004/2006)
Unternehmensweites Risikomanagement – Übergreifendes Rahmenwerk: Zusammenfassung
(übersetzt 2006 durch Deutsches Institut für Interne Revision e.V., Frankfurt/Main),
Arbeitsbericht, The Committee of Sponsoring Organization, Jersey City. http://www.coso.org/
documents/COSO_ERM_ExecutiveSummary_German.pdf. Zugegriffen: 13. Jan 2013
Verband der Automobilindustrie (VDA) (2009) Produkt-und Prozess FMEA, Dokumentation,
Kapitel 4. http://www.en-standard.eu/vda-4-kapitel-produkt-und-prozess-fmea/. Zugegriffen: 08.
Jan 2013
Werdich M (Hrsg) (2011) FMEA – Einführung und Moderation: durch systematische Entwicklung
zur übersichtlichen Risikominimierung (inkl. Methoden im Umfeld). Vieweg + Teubner,
Wiesbaden
Integration von Prozess-
und Wissensmanagement 18
Robert Woitsch, Wilfrid Utz und Vedran Hrgovcic
Zusammenfassung
Der Produktionsfaktor „Wissen“ gewinnt immer mehr an Bedeutung und entschei-
det zunehmend über den Unternehmenserfolg. Trotzdem ist für viele Organisationen
das systematische Anwenden des Führungsinstruments „Wissensmanagement“ eine
Herausforderung. Dieses Kapitel stellt das Wissensprodukt als Bindeglied zwischen
Prozess- und Wissensmanagement vor. Wissensprodukte definieren Wissen in kon-
sumierbarer Form und ermöglichen somit das Steuern von Wissen. Dabei werden
drei Arten von prozessorientiertem Wissensmanagement unterschieden: (1) Der
Prozess als Inhalt stellt normative organisatorische Abläufe dar, (2) der Prozess als
Know-how- und Integrationsplattform integriert Prozess- und Wissensmanagement
durch Wissensprodukte, und (3) der Prozess als Managementinstrument ermög-
licht die prozessorientierte Erstellung von Wissensprodukten. Das vorgestellte
Wissensmanagement-Rahmenwerk unterstützt bei der Integration von Prozess- und
Wissensmanagement durch das Wissensmanagement-Modell und durch ein Wissens
management-Projektportfolio. Die Wissensbilanz ermöglicht die Beobachtung und das
zielgerichtete Steuern von Organisationswissen. Neben dem theoretischen Fundament
beschreibt das Kapitel auch Erfahrungen aus Praxisprojekten mit der Ableitung von
Wissensprodukten, der Darstellung von Wissensmanagement-Prozessen und der
Verwendung von Wissensbilanzen.
R. Woitsch (*) · W. Utz · V. Hrgovcic

BOC Asset Management GmbH, Operngasse 20b, 1040 Wien, Österreich
e-mail: robert.woitsch@boc-eu.com

356 R. Woitsch et al.
18.1 Motivation
Nichts ist so praktisch wie eine gute Theorie, ist ein treffendes Zitat von Lewin und
Feynman, das den Wert eines methodischen Vorgehens für praktische Lösungen unter-
streicht. Das Wissensmanagement stellt sich der Herausforderung, eine Balance zwischen
Zeit, Geld und Qualität der Wissensbereitstellung zum Erreichen der Unternehmensziele
zu ermöglichen.
Der Begriff „Wissensmanagement“ entstand aus der Informationstechnologie und der
Wissensverarbeitung um 1940, wird seit ca. 1995 (Despres und Chauvel 1999) als eigenstän-
diges betriebswirtschaftliches Instrument gesehen und hatte um das Jahr 2000 einen Hype.
Wie die Schlagwörter „Wissensgesellschaft“, „Komplexitätsgesellschaft“, „Lifelong
Learning“ oder „Social Media“ zeigen, ist Wissensmanagement heutzutage – teilweise unter
anderen Namen – noch immer eine Herausforderung für Organisationen, die sich mit
der Kernfrage „Wie kann das Wissen zum Nutzen der Organisation verwendet werden?“
beschäftigen.
Dabei befindet sich das Fachwissen in den Köpfen der Mitarbeiter, in der gelebten nor-
mativen Praxis sowie in den verwendeten technischen Infrastrukturen. Die organisato-
rische Wissensbasis ist daher die Summe der Mitarbeiter, der organisatorischen Abläufe
(Prozesse) sowie der technischen Infrastruktur, in denen die Inhalte gespeichert sind.
Das Wissen und die Fähigkeiten von Mitarbeitern und der Einsatz von Informations
technologie stellen wesentliche Ressourcen dar, um mit den massiven Datenmengen,
der Abhängigkeit von Schlüsselmitarbeitern und der Kommunikationsflut umgehen zu
können. Obwohl die Wurzeln des Wissensmanagements mit der Katalogisierung der
Bibliothek von Alexandria – als Vorläufer semantischer Taxonomien – tausende Jahre
zurückreicht und Organisationen aktuell mit Themen, wie sozialen Netzwerken, Web 2.0,
Semantik oder Visual Analytics, konfrontiert sind, stellt das methodische Verwenden des
betriebswirtschaftlichen Führungsinstruments „Wissensmanagement“ immer noch eine
Herausforderung dar, um das Wissen für die Organisation zielgerichtet in betrieblichen
Nutzen umzusetzen.
Dieses Kapitel zeigt in zwei Abschnitten, wie Wissensmanagement als betriebli-
ches Führungsinstrument in das Prozessmanagement integriert werden kann. Im ersten
Abschnitt wird ein Wissensmanagement-Rahmenwerk vorgestellt, anhand dessen das
Wissen transparent dokumentiert und somit verbessert werden kann. Anwendungsfälle sind
die Wahrung der betrieblichen Haftung, die Risikoeinschätzung, das Qualitätsmanagement,
das Archivieren impliziter Entscheidungsfindungen von Führungskräften, die Kollaboration
von Schlüsselarbeitskräften, das Lernen der Mitarbeiter und die Realisierung von techno-
logischen Lösungen gemäß organisatorischen Vorgaben. Im zweiten Abschnitt wird ein
Evaluations-Rahmenwerk vorgestellt, anhand dessen das Wissen zielgerichtet gesteuert wer-
den kann. Anwendungsfälle sind das betriebliche Verbesserungs- und Innovationswesen,
die Effizienzsteigerung, die Aus-, Fort- und Weiterbildung, Technologietransfer sowie der
organisatorische Wandel.
18 Integration von Prozess- und Wissensmanagement 357
Dieses Kapitel stellt ein Vorgehen vor, mit dem die beiden oben genannten
Abschnitte je nach Zielsetzung mit Hilfe von Projekten umgesetzt werden können.
Zuvor werden empfohlene Grundlagen beschrieben.
18.2 Empfohlene Grundlagen und Begriffsabstimmung
Um heterogene unternehmensrelevante Inhalte in einer Organisation nutzbar zu machen,

sind Tätigkeiten notwendig, die in Summe als Wissensmanagement verstanden werden
(Woitsch et al. 2010, S. 59 ff.).
Ergänzend zu dem in Kap. 15 eingeführten Begriff „Management“ verstehen wir unter
„Wissensmanagement“ das Lenken und Leiten von Wissensarbeit, wie das Umwandeln,
Speichern, Austauschen oder Verteilen von Wissen. Diese pragmatische Begriffsabstimmung
basiert auf der ÖNORM (Austrian Standards 2007), berücksichtigt aber auch den
Managementaspekt, der in einer Reihe von Wissensmanagement-Definitionen (Beckman
1999) hervorgehoben wird.
Der systemische Ansatz versteht Organisationseinheiten als Satz von Wechselbeziehungen
oder Wechselwirkungen (International Organization for Standardization (ISO) 2008). Im
Wissensmanagement verstehen wir daher sozio-technische Systeme als Zusammenspiel von
Experten, Wissensarbeitern und Entscheidungsträgern mit IT-Anwendungen, dem Web
oder mobilen Endgeräten.
Implizites Wissen ist an den Menschen gebunden, wogegen explizites Wissen in einer
für andere Menschen oder IT-Anwendungen verwendbaren Form aufbereitet ist (Nonaka
und Takeuchi 1995). Welche Form verwendet wird, richtet sich nach dem Anwender. Ein
Benutzer möchte das Wissen in einer anderen Form präsentiert bekommen als ein „intel-
ligentes“ Computerprogramm.
Die Beschreibung von Wissen variiert zwischen streng formalen und nicht for-
malen Wissensrepräsentationen (Woitsch und Hrgovcic 2011). Streng formale
Wissensrepräsentationen werden vorwiegend von Computerprogrammen benötigt, bei-
spielweise in Form von mathematischen Graphen, semantischen Netzen, Ontologien oder
Aussagenlogik. Nicht formale Wissensrepräsentationen sind hingegen für menschliche
Interpretation gedacht, wie beispielsweise Mind Maps, Chart-Darstellungen, Texte oder
Videos.
Wir verstehen die Wissensrepräsentationen als Modelle und unterscheiden daher zwi-
schen streng formalen Modellen und nicht formalen Modellen, wobei die streng formalen
Modelle für die Konfiguration der IT-Infrastruktur verwendet werden und die nicht for-
malen Modelle für die Darstellung der fachlichen Ebenen benötigt werden (Karagiannis
und Woitsch 2010).
Die Bausteine (Probst et al. 1997) oder Tätigkeiten des Wissensmanagements kön-
nen mit Wissenstransparenz, Wissenserwerb, Wissensentwicklung, Wissensverteilung,
Wissensbewahrung und Wissensnutzung beschrieben werden, wobei diese Tätigkeitsfamilien
in der Praxis unterschiedlich ausgeprägt sein können und sich teilweise auch überlappen. Wir
verstehen diese Bausteine oder Tätigkeiten als Wissensmanagement-Prozesse (Karagiannis
und Telesko 2000).
In der Informationstechnologie werden Daten, Informationen und Wissen folgender-
maßen abgegrenzt: Daten sind kontextfrei, Informationen beziehen sich auf einen Kontext,
jedoch ist Wissen die intelligente Interpretation und daraus abgeleitete Handlungsfähigkeit
(Karagiannis und Telesko 2001).
In der betrieblichen Praxis ist es notwendig, die sogenannten Wissensprodukte, die
in (Mak und Woitsch 2005) und (Göllner et al. 2008) entwickelt worden sind, zu identi-
fizieren, um das für die Geschäftsprozesse verwendbare – und damit „konsumierbare“ –
Wissen zu kennen und dieses in weiterer Folge zu bearbeiten und zu steuern. Diese Sicht
auf Wissensprodukte hat sich in der Praxis auch in hochkomplexen und sicherheitskriti-
schen Anwendungen bewährt und ist als Führungsinstrument zu empfehlen.
18.3 Wissensmanagement als Rahmenwerk
18.3.1 Überblick über das Wissensmanagement-Rahmenwerk
Das Wissensmanagement-Rahmenwerk beschreibt die Integration von Prozessmanagement

und Wissensmanagement, stellt eine Vorgehensweise vor und erläutert einen Modellie
rungsrahmen für das Unternehmenswissens.
Prozessorientiertes Wissensmanagement kennt drei Ausbaustufen (Woitsch 2004):
• der Prozess als inhaltliche Darstellung normativer Organisationsabläufe,

• der Prozess als Integrations- und Wissensplattform sowie
• der Prozess als Managementinstrument, um Wissensmanagement prozessorientiert
zu gestalten.
Die vorangegangenen Kapitel des Buchs behandeln ausführlich den Prozess als inhaltliche
Darstellung normativer Organisationsabläufe, indem die organisatorischen Abläufe beob-
achtet, erhoben und in einer für den Menschen ansprechende Repräsentationsform, in Form
von grafischen Diagrammen, dokumentiert werden sowie durchsuchbar gemacht werden.
Der Prozess als Integrations- und Wissensplattform beschreibt die Integration von
Prozess- und Wissensmanagement. Die größte Herausforderung dabei ist die Identifikation
des notwendigen Wissens, wobei das Wissen oft für das Ableiten betriebswirtschaftlicher
Führungstätigkeiten zu ungenau definiert ist. Das Wissensprodukt hingegen stellt einen
Ankerpunkt für die Integration von Prozessmanagement und Wissensmanagement dar und
ermöglicht das gezielte Steuern von Wissensmanagement-Tätigkeiten.
Der Prozess als Managementinstrument stellt Prozessmanagement-Instrumente für
die Produktionsprozesse und Nutzungsprozesse von Wissensprodukten zur Verfügung,
um das zielgerichtete Wissensmanagement zu unterstützen.
Abb. 18.1 Das

Ziel Evaluation
Wissensprodukt als Anker- und
Bindeglied
Geschäftsprozess
„Das Wissensprodukt als Bindeglied

für die Integration zwischen
Prozess- und Wissensmanagement.“
Wissensprodukt
Wissens-
Wissens-
management-
umgebung
Prozesse
Wissensstrukturen
Wissens- Wissens-
werkzeuge ressourcen
Abbildung 18.1 zeigt schematisch, wie mittels Wissensprodukten eine Integration

zwischen Prozess- und Wissensmanagement ermöglicht wird. Dabei wird das Wissen
in Geschäftsprozessen in Form von konsumierbaren Wissensprodukten identifi-
ziert – in Abb. 18.1 als kleine Rechtecke symbolisiert. Empfehlenswert ist es daher, die
Wissensarbeiter aus dem Geschäftsprozess nach jenem Wissen zu fragen, welches sie zur
Bearbeitung des Geschäftsprozesses „konsumieren“.
In der Regel wird eine Mischung aus implizitem Kollegenwissen, IT-Lösungen, div.
Dokumenten und Vorlagen sowie Web-Referenzen aufgelistet. Die Sichtweise mit-
tels Wissensprodukt übersetzt diese Mischung aus Quellen und Anwendungen in
sogenannte Produkte und Dienstleistungen, die vom Mitarbeiter konsumiert wer-
den können. Beispielsweise wird das implizite Wissen von Kollegen in Form von
Beratungsdienstleistungen oder kollegialer Hilfe konsumiert. IT-Lösungen werden in
Form des strukturierten Inhalts konsumiert.
Dieser „Brückenschlag“ zwischen Prozess- und Wissensmanagement ermöglicht
es, die Wissensprodukte vom Geschäftsprozess aus als Informationsquellen zu sehen.
Diese Wissensprodukte können allerdings mit einem eigenständigen Managementansatz
gesteuert werden.
Der Modellierungsrahmen PROMOTE® (BOC 2013a) ermöglicht die Beschreibung
der Wissensprodukte und der Wissensmanagement-Prozesse zur prozessorientierten
Gestaltung der Wissenstätigkeiten.
Das Wissensmanagement-Vorgehen von PROMOTE® basiert auf dem BPMS-
Rahmenwerk (Karagiannis 1995). Genau wie im BPMS-Rahmenwerk werden fünf
Phasen für ein modellunterstütztes Wissensmanagement definiert (Telesko et al. 2001).
Abbildung 18.2 beschreibt die fünf Phasen des Wissensmanagement-Vorgehens von
PROMOTE®. Die erste Phase reflektiert die strategische Positionierung der Organisation
Abb. 18.2 Die 1

Wissensmanagement- Zieldefinition
Vorgehensweise PROMOTE®
2
Wissensmanagement
5 Wissens-
Performance
3 Monitoring
Operationalisieren
von Wissen
4
Wissensarbeit
und -verwendung
bezüglich Wissen und Kompetenzen. Die zweite Phase modelliert die Wissensprodukte
und deren Zusammenhang mit den Geschäftsprozessen und ermöglicht, je nach
Reifegrad des Wissensmanagements in der Organisation, die Umsetzung von:
• wissensbasierter Steuerung mittels Wissensbilanz,

• Wissenslogistik mittels Wissensmanagement-Prozessen,
• Skill-Management mittels Skill-Profilen oder
• wissensbasierter IT-Infrastruktur.
Die dritte Phase unterstützt die Transformation der Wissensmodelle in konkrete betrieb-
liche Lösungsansätze mittels Projektportfolio zu den Themen:
• personalbezogenes Wissensmanagement,
• organisatorisches Wissensmanagement,
• IT-bezogenes Wissensmanagement,
• inhaltliche Arbeiten und
• Dokumentationsarbeit.
Diese Phase dient der Vorbereitung und dem Aufbau des Wissensmanagement-Systems.
Die vierte Phase ist das operative Arbeiten im Wissensmanagement-System.
Hier werden konkrete Wissenswerkzeuge in den Bereichen Komposition, Content,
Kollaboration und Kompetenzen für den Wissensarbeiter zur Verfügung gestellt, um die
konkreten Geschäftsprozesse abarbeiten zu können (Woitsch et al. 2010).
Die fünfte Phase beschäftigt sich mit der Evaluation des Wissensmanagement-
Systems. Dabei werden die Kennzahlen der Wissensprodukte gemäß eines Beurtei
lungs-Rahmenwerks erhoben, mit Soll-Werten verglichen und entsprechende
Wissensmanagement-Maßnahmen zur Steuerung abgeleitet. Somit stellt die letzte Phase
das Steuerungsrahmenwerk für Wissensmanagement auf Basis der Wissensbilanz von
Göllner et al. (2008, 2010) dar.
18.3.2 Definition der Ziele und Systemgrenzen
Bevor Wissensmanagement-Initiativen eingeführt werden, ist es wie in jedem Projekt

notwendig, die Systemgrenzen und die Ziele der Initiativen zu formulieren. Sind die
Zielvorgaben zu abstrakt formuliert, wie „Mache das ganze Wissen allen Mitarbeitern
nutzbar.“, leidet die Wissensmanagement-Initiative am Fehlen einer klaren Abgrenzung
und wird wahrscheinlich die ungenauen Ziele nicht erfüllen können. Im Folgenden wer-
den einige Beispiele aus erfolgreichen Praxisprojekten vorgestellt.
Beispiel
An eine Dokumentationsabteilung des öffentlichen Dienstes wurden ständig neue Aufga-
ben herangetragen und weniger Ressourcen zur Verfügung gestellt. Daraufhin entschloss
sich der Leiter dieser Abteilung, die Wissensmanagement-Prozesse zu erheben. Ziel war es,
alle Produktionsprozesse der bestehenden Informationsprodukte, Dienstleistungen und
Anwendungen zu untersuchen, um Zeit, Ressourcen und benötigte Finanzmittel transpa-
rent darzustellen. Der Abteilungsleiter konnte somit die unterschätzten Aufwände für Infor-
mationsprodukte darlegen und erhielt eine Aufstockung der Ressourcen.
Beispiel
Der Organisationsleiter einer ca. 120 Mitarbeiter zählenden Einheit ging in Pension
und wollte seinem Nachfolger seine auf Erfahrung beruhenden, kritischen und wis-
sensintensiven Entscheidungsfindungen mittels einer Wissensbilanz dokumentieren.
Ziel war es daher, die Entscheidungsfindung der langjährigen Führungsperson für den
Nachfolger nachvollziehbar zu dokumentieren.
Beispiel
In einer Abteilung einer internationalen Organisation gibt es Aufklärungsmissionen, die
von hochspezialisierten Fachkräften durchgeführt werden. Obwohl die rechtlichen und
organisationsinternen Vorgaben mittels eines Geschäftsprozesses für alle Spezialisten
gleich sind, entwickelte jedoch jeder Mitarbeiter ein eigenes Vorgehen. Ziel des Projekts
war es, alle Informationsquellen, die im Laufe der Zeit von den Experten gefunden und
als hilfreich erachtet worden waren, mit dem offiziellen Geschäftsprozess abzugleichen,
Verbesserungspotenziale aufzuzeigen und Vorschläge zu Verbesserungen zu erarbeiten.
18.3.3 Modellieren der Wissensprodukte
Die Wissensprodukte sind der Einstiegspunkt für das Wissensmanagement. Tabelle 18.1
zeigt das vorgeschlagene Wissensmanagement-Modell von PROMOTE® anhand sei-
ner Komponenten. Die einzelnen Komponenten werden in den folgenden Abschnitten
jeweils weiterführend erläutert.
Tab. 18.1 Das Wissensmanagement-Modell (Woitsch 2004)

Wissensprodukte
Die Wissensprodukte beschreiben die Wirkung für den Kunden.
Wissensmanagement-Prozesse Wissensumgebung
Die Prozesse beschreiben die Erzeugung von Die Wissensumgebung beschreibt die Kom-
Wissensprodukten und geben somit Auskunft petenz der Mitarbeiter und die Fähigkeit der
über deren Qualität. Organisation.
Wissensstruktur
Die Wissensstruktur bildet die Themenfelder der Organisation ab.
Wissenswerkzeuge Wissensressourcen
Die Wissenswerkzeuge geben Auskunft über Die Wissensressourcen beschreiben die Informa-
die vorhandene Technologie der Wissensarbeit. tionsquellen und Verarbeitungsmöglichkeiten.
18.3.3.1 Das Wissensprodukt
Die Wissensprodukte ermöglichen die „Konsumation“ von Wissen innerhalb eines
Wissensmanagement-Systems. Sie werden in Informationsprodukte, Beratungsprodukte
und Anwendungen unterteilt und werden aus dem Geschäftsprozess heraus konsumiert.
Abbildung 18.3 zeigt einen anonymisierten Ausschnitt einer Produktlandkarte. Die
gesamte Produktlandkarte spezifiziert alle Wissensprodukte für einen Geschäftsprozess.
Der hier angeführte Ausschnitt listet Wissensprodukte für nur einen Prozessschritt, die
„Gefahreneinschätzung“, auf. Für diesen Prozessschritt stehen fünf Wissensprodukte zur
Verfügung.
Wissensprodukte für
Gefahreneinschätzung
Anwendungen Informationsprodukte Beratungsprodukte
Risikomatrix Liste von Experten- Stakeholder Meeting

Statements
Expertenliste für
Kontaktaufnahme
Gefahrenanalyse-
Bericht
Abb. 18.3 Beispiele für Wissensprodukte aus einem Projekt

Die Risikomatrix ist ein Microsoft® Excel® Template, das mit einer Reihe von
Funktionalitäten die Erstellung einer individuellen Risikomatrix unterstützt. Die Liste von
Experten-Statements ist eine von Fachexperten gewartete Wiki-Seite. Die Kontaktliste für
Experten zur Gefahreneinschätzung ist eine Adressdatenbank für ausgewählte Kontakte. Der
Bericht zur Gefahrenanalyse ist als PDF-Dokument in einem Dokumentenmanagement-
System gespeichert. Das Beratungsprodukt „Stakeholder Meeting“ ist eine physische
Veranstaltung, die regelmäßig abgehalten wird und mittels einer Webseite angekündigt wird.
Die Aufteilung in Informationsprodukte, Beratungsprodukte und Anwendungen
wurde im Rahmen eines Praxisprojekts entwickelt (Mak und Woitsch 2005).
Informationsprodukte bieten dabei explizite Informationen an, die von einem Mitarbeiter
interpretiert werden können, wie Handlungsanleitungen, Dokumente, Bücher, Richtlinien,
Protokolle, schriftliche Regeln, Präsentationen, Filme, Datenbankabfragen oder ähnliches.
Beratungsprodukte hingegen bieten implizite Informationen an, die von einem
Mitarbeiter zu einem anderen Mitarbeiter übermittelt werden, wie Auskünfte, Beratungen,
Moderationen, das Abhalten von Kursen, periodische Besprechungen oder ähnliches.
Anwendungen wiederum stellen explizite Informationen zur Verfügung, die nicht
von Mitarbeitern, sondern von einem Computerprogramm verarbeitet werden, wie
Entscheidungsunterstützungs-Systeme, Workflow-Systeme, automatische Textanalysen
oder ähnliches.
Die weiteren Komponenten des Wissensmanagement-Modells werden in den folgen-
den Abschnitten jeweils weiterführend erläutert.
18.3.3.2 Der Wissensmanagement-Prozess
Die Wissensmanagement-Prozesse verstehen alle Tätigkeiten des Wissensmanagements als
Prozess und können daher als themenspezifische Sammlung von Prozessen gesehen wer-
den. Ursprünglich wurden die Wissensmanagement-Prozesse als Unterstützungsprozesse
gesehen. Jedoch hat die betriebliche Praxis gezeigt, dass sie als Managementprozesse
anzuerkennen sind, da die Herausforderungen des Wissensmanagements in Form von
Mitarbeiterkommunikation, dem Veränderungsmanagement und dem Abschätzen von
Risiken auftreten und daher den Managementprozessen zugeordnet werden.
Der prozessorientierte Ansatz PROMOTE® beschreibt die vorhin erläuterten Wissens
bausteine in Form von Prozessen. Daher werden folgende Wissensmanagement-Prozesse
unterschieden:
• das Identifizieren oder Scannen von Wissen,

• die Aufbereitung oder Speicherung von Wissen,
• das Zugreifen auf Wissen und das Verwenden von Wissen,
• die Analyse von Wissen sowie
• die Verteilung von Wissen.
Diese Prozesse ergeben Teil-Wissensprodukte, die direkt oder indirekt an der Erstellung
oder Verwendung eines Wissensprodukts beteiligt sind. Die Entscheidung, welche
Wissensmanagement-Prozesse in höherer und welche in geringerer Qualität ausgeführt

werden, ist ein wesentlicher Bestandteil des Wissensmanagements.
18.3.3.3 Die Wissensumgebung
Die Wissensumgebung beschreibt die Mitarbeiter, ihre Fähigkeiten sowie deren Aufgaben
gebiete. Die Hauptgruppen sind die (1) Wissensmanager, welche für die Führung und
Steuerung der Wissensmanagement-Prozesse und die Bereitstellung von Wissensprodukten
verantwortlich sind; die (2) Wissensarbeiter oder Wissensnutzer, die für die Verwendung
und Erzeugung von Wissen verantwortlich sind, sowie die (3) Wissensadministratoren, die
für die Konfiguration des Systems zuständig sind.
Jeder Mitarbeiter hat ein Fähigkeitenprofil, das mit dem Soll-Profil seiner Wissensrolle
verglichen werden kann. Somit ergibt sich ein Fähigkeitenradar, der die Fähigkeiten auf
Mitarbeiterebene, auf Abteilungsebene und letztendlich auf Organisationsebene nach vor-
her bestimmten Kriterien je nach Ausprägung auflistet.
18.3.3.4 Die Wissensstruktur
Die Wissensstruktur beschreibt den Inhalt – die Domain – eines Unternehmens. Diese
unterteilt sich sowohl in die fachliche Wissensstruktur als auch in die systemische
Wissensstruktur. Die systemische Wissensstruktur wird durch Prozesse, Organisa
tionsabteilungen, Rollen o. ä. definiert. Die fachliche Struktur beschreibt die Fachgebiete, in
denen das Unternehmen tätig ist.
Die Detaillierung beginnt mit der Terminologie, einer Auflistung von meist alpha-
betisch sortierten relevanten Begriffen, und kennzeichnet somit organisationsrelevante
Terme. Eine weiterführende Detaillierung ist das Glossar, der Thesaurus sowie die der-
zeit höchste Ausprägung einer formalen Begriffsdefinition, die Ontologie.
18.3.3.5 Die Wissensressourcen
Die Wissensressourcen sind jene Wissensquellen, aus denen die Organisation ihr
Wissen bezieht. Zentraler Informationsträger ist das Dokument. Die Abgrenzung eines
Dokuments ist durch eine eindeutige Identifizierung eines Dokuments, bspw. über eine
URL, gegeben.
Wissensquellen beinhalten oder erzeugen eine Menge von Dokumenten, und brin-
gen aufgrund derselben Abfrage auf dieselbe Informationsquelle wiederholbar dieselbe
Menge an Dokumenten hervor. Beispiele sind Dokumentenmanagement-Systeme,
Datenbanken, Data Warehouses oder Content Management-Systeme.
Wissensressourcen beinhalten oder erzeugen ebenfalls eine Menge an Dokumenten;
allerdings bringen diese auf dieselbe Abfrage nicht notwendigerweise dieselben
Dokumente hervor. Die Wissensressource ist ein informeller Wissensraum, wie persönli-
che Netzwerke, Experten oder assoziative Beobachtungen.
Die Summe der explizit genannten Dokumente, der aufgelisteten Wissensquellen und
der Wissensressourcen werden oft vereinfacht als Wissensressourcen der Organisation
gesehen.
18.3.3.6 Die Wissenswerkzeuge
Wissenswerkzeuge sind in IT-Werkzeuge und Human-Werkzeuge untergliedert. Unter
IT-Werkzeugen versteht man technische Infrastrukturen und IT-Anwendungen, die
Funktionalität für die Wissensarbeit anbieten. Traditionelle IT-Systeme sind Such
maschinen, Datenbanken, E-Mail-Systeme, Archive und dergleichen. Human-Werkzeuge
sind organisatorische und intrinsische Methoden und Verfahren, um Gruppen und
Einzelpersonen als Wissensträger zu gewinnen. Somit sind bspw. Kollaborationen, Space-
Management, Zeitmanagement, Kaffeeküche und Teambuilding-Veranstaltungen typi-
sche Human-Werkzeuge.
Die unterschiedlichen Werkzeuge arbeiten auf unterschiedlichen Formaten. Daher
müssen die jeweiligen Formate der Wissenswerkzeuge erkannt werden.
18.3.4 Projektorientierte Vorbereitung und Aufbau
Dieser Abschnitt beschreibt, wie Wissensmodelle in den lauffähigen Betrieb überführt wer-
den. Die Modelle ermöglichen daher eine geordnete Realisierung von Wissensmanagement-
Projekten.
Bei einer schrittweisen Umsetzung oder Verbesserung des Wissensmanagement-Systems
werden zuerst die Wissensprodukte analysiert und notwendige Verbesserungsmaßnahmen
aufgelistet. Diese Maßnahmen werden in Form von Projekten formuliert und mittels üblicher
Projektmanagement-Verfahren umgesetzt. Als Hilfsmittel hat sich ein Wissensmanagement-
Portfolio mit folgenden Projektkategorien bewährt (Woitsch et al. 2010):
• Kategorie Mensch/Mitarbeiter:
Diese Kategorie umfasst Aus-/Weiter- und Fortbildung von Mitarbeitern. Somit wird
der Ausbildungsgrad der Organisation verbessert, beispielsweise unter Nutzung eines
Ausbildungskonzepts oder eines Leitfadens für Lessons Learned.
• Kategorie Technologie:
Diese Kategorie umfasst die Implementierung, Anschaffung, Konfiguration und Adaption
von Systemen und Technologien, wie die Einführung eines Kollaborationswerkzeugs oder
die Integration zweier Systeme.
• Kategorie Organisation:
Diese Kategorie umfasst organisatorische Notwendigkeiten für das Wissensmanagement,
wie die Einführung von Wissensbilanzierung oder des Qualitätsmanagements.
• Kategorie Inhalt:
Diese Kategorie umfasst die inhaltliche Qualität, Aktualität und Verarbeitung relevan-
ter Informationen, wie ein Rechercheprojekt für ein Thema oder die Einführung von
Bewertungsheuristiken von Inhalten.
• Kategorie Dokumentation:
Diese Kategorie umfasst die Sicherstellung unternehmensrelevanter Dokumente sowie
die semantische Interoperabilität des Wissens. Somit wird die semantische Qualität
der Metadaten für die langfristige Sicherstellung und Nutzbarmachung des Wissens
ermöglicht. Beispiele sind die Erstellung eines unternehmensweiten Terminologie-
Frameworks oder eine Langzeitarchivierung.
Das Wissensmanagement-Projektportfolio kennt neben den Kategorien auch ein

Reifegradmodell, in dem die verschiedenen Aggregatzustände der Projekte beschrieben
werden können.
Je nach Organisation wird zwischen unterschiedlichen Studien, Show Cases, Demons
tratoren und Prototypen sowie der Produktion und Live-Schaltung unterschieden.
18.3.5 Operativer Betrieb
Da das Wissensmanagement ein sozio-technisches System ist, ist der operative Betrieb
die Summe aller kommunikations- und informationsbezogenen Aktivitäten von
Mitarbeitern und IT-Systemen. Grundsätzlich hat also jede Organisation ein im operati-
ven Betrieb befindliches Wissensmanagement-System.
Die vorher beschriebenen Wissensmanagement-Initiativen beeinflussen:
• die Verhaltensweise der Mitarbeiter bei organisatorischen Initiativen,

• den Ausbildungsstand der Mitarbeiter bei mitarbeiterorientierten Initiativen,
• die Verwendung von neuen IT-Systemen bei technischen Initiativen,
• den Kenntnisstand der Organisation bei inhaltlichen Initiativen oder
• den Reifegrad der Informationen durch dokumentationsorientierte Initiativen.
Ein Wissensmanagement-System besteht daher in der Regel nicht nur aus einer Wissens
management-Initiative oder einem konkreten IT-System, sondern aus einer Fülle von
ständig neuen Wissensmanagement-Initiativen, die sich schrittweise in ein geordnetes
Wissensmanagement-System integrieren und je nach Notwendigkeit ständig verändern.
Trotz der Selbstverständlichkeit der ständigen Veränderung im Informationszeitalter
ist es schwierig, den korrekten Zeitpunkt für eine konkrete Maßnahme zu finden.
Eine Entscheidungshilfe kann das Steuerungsinstrument „Wissensbilanz“ sein. Die
Wissensbilanz beurteilt die Nutzung und Erstellung der Wissensprodukte mittels zwölf
Feldern und zeigt Verbesserungspotenziale auf.
18.4 Wissensbilanz als Steuerungsinstrument
18.4.1 Überblick über die Wissensbilanz
Ausgangspunkt hierbei sind die Wissensprodukte der jeweiligen Organisationseinheit, die

erhoben und auf der Wissensprodukt-Landkarte abgebildet werden. Diese Wissensprodukte
werden (1) produziert, (2) müssen an den Nutzerkreis kommuniziert und vermarktet wer-
den und (3) sind einem ständigen Wandel ausgesetzt (Göllner et al. 2009).
Auf Basis von bekannten Ansätzen der Wissensbilanzen wurden in einem Pilotprojekt
im österreichischen Bundesheer vier Sichtweisen auf die genannten drei Wissensprodukt-
Säulen erarbeitet (Göllner et al. 2008). Je nach Organisation gibt es unterschiedliche
Vorgehensweisen, um die zwölf Themenfelder – die sich aus drei Säulen und je vier
Sichtweisen zusammensetzen – zu entwickeln.
Abbildung 18.4 stellt sowohl die drei Säulen als auch die vier Sichtweisen vor.
WISSENSBILANZ
ZUR PERFORMANCE-STEIGERUNG
Ansicht Aussagekraft
Anlassfall und Produkt

- Wahrgenommenes
Ergebnis „Wirkung am Markt“
- Anlassfall
Produktion zur Leistungserbringung
Kommunikation für die Außenwirkung
- Produkte
Transformation für die Innenwirkung
Prozesse und Struktur

- Kernprozesse
- Qualitätsrelevante Prozesse „Wissensmanagement“
- Führungs- und steuerungs-
relevante Prozesse
Humankapital, Beziehungen
und Fähigkeiten
- Personen „Verwertbares Wissen“
- Fähigkeiten
- Beziehungen
Ressourcen und
Unterstützung
- Budget
- Infrastruktur „Verfügbarer Input“
- Material und Gerät
- Information und
Kommunikation
Abb. 18.4 Das 3-Säulen-Referenzmodell

Die drei Säulen:
• Produktion der Wissensprodukte,

• Kommunikation und Marketing der Wissensprodukte und
• ständige Innovation der Wissensprodukte
sind die Grundphilosophie der Wissensbilanz mit PROMOTE®.

Die vier Sichtweisen sind:
• Produktsicht,
• Prozess- und Struktursicht,
• Humankapital-, Beziehungskapital- und Fähigkeitensicht sowie
• Ressourcen- und Unterstützungssicht.
Die Steuerung von Wissensprodukten kann daher durch insgesamt zwölf Kennzahlenfelder
erfolgen, die sich aus den drei Säulen und vier Sichtweisen ergeben:
• Produktion und Benutzernutzen von Wissensprodukten,

• Bekanntheit von Wissensprodukten,
• Produkte zur Veränderung von Wissensprodukten,
• Produktionsprozesse für Wissensprodukte,
• Kommunikationsprozesse für Wissensprodukte,
• ständige Verbesserungsprozesse für Wissensprodukte,
• notwendige Kompetenz und Mitarbeiterressourcen zur Produktion von Wissens-
produkten,
• Netzwerke innerhalb und außerhalb der Organisation zur Bereitstellung von Kompe
tenzen und Ressourcen für Wissensprodukte,
• ständige Netzwerkpflege und interne Ausbildung,
• Ressourcen, wie Material, Geräte, Informationen und Geld, zur Produktion von
Wissensprodukten,
• Ressourcen zur Kommunikation und dem Betreiben von Netzwerken sowie
• Ressourcen zur ständigen Verbesserung, Ausbildung, Netzwerkpflege und für neue
Wissensmanagement-Initiativen.
Die weiteren Abschnitte geben einen Überblick, wie eine Wissensbilanz erstellt wird.
18.4.2 Beschreibung der Ausgangslage
Das vorhin beschriebene Rahmenwerk für Wissensmanagement ist die notwendige

Grundlage, um das Steuern mit einer Wissensbilanz zu ermöglichen. Im ersten Schritt
wird daher das vorhin beschriebene PROMOTE®-Wissensmanagement-Modell verwen-
det, um die konkrete Ausgangslage zu modellieren.
Zunächst werden die Systemgrenzen der Organisationseinheiten, der Input in Form von
Wissensressourcen und Wissenswerkzeugen, der Output in Form von Wissensprodukten,
die Ressourcenbereitstellung, die Transformation in Form von Wissensmanagement-
Prozessen und der Wissensumgebung sowie die Zielvorgaben festgehalten.
Aus diesem Wissensmanagement-Modell lassen sich dann alle vorher genannten
zwölf Kennzahlenfelder für eine Wissensbilanz ableiten.
18.4.3 Spezifikation der Ziele und Erkennen von

Wirkungszusammenhängen
Nachdem die Ausgangslage festgehalten ist, werden zunächst die kritischen Erfolgsfaktoren
und danach die Ziele des zu steuernden Systems für jedes der zwölf Themenfelder
abgeleitet.
Ziele werden je nach organisatorischer Praxis zu Sub- oder Hauptzielen zusammenge-
fasst und konkrete Kennzahlen, die die Erreichung der Ziele messen können, werden als
eine Art organisatorische Sensoren definiert.
Bereits bestehende Kennzahlen werden aus den relevanten Betriebsführungs-
Systemen übernommen und um gängige Wissenskennzahlen aus Kennzahlenkatalogen
(Göllner et al. 2010, S. 64 ff.) ergänzt. Abschließend werden fehlende Kennzahlen
bedarfsgerecht hinzugefügt.
Beispiel
Als Beispiel werden Kennzahlen der Forschungsbilanz ÖBH (Mak et al. 2010, S. 36) zur
Steuerung der Wissensgenerierung kurz vorgestellt. Insgesamt wurden 93 Kennzahlen
zur Wissenssteuerung definiert. Konkrete Kennzahlen sind bspw. die Ergebnisbeurtei-
lung, die Verwertbarkeit der Ergebnisse, die Umsetzungsquote, die Abnahmequote oder
der Befüllungsgrad des Organisationsplans.
18.4.4 Operative Datenanbindung und Steuerung durch die

Wissensbilanz
Ziele, Kennzahlen und deren Wirkungszusammenhänge spezifizieren die Kennzahlenlogik.

Für die konkrete Nutzung werden operative Daten und Berichtssysteme verwendet.
Das Ergebnis sind Kennzahlen-Cockpits, die konkrete Kennzahlenwerte zur Wissens
bereitstellung, der Effizienz des Wissensmanagement-Systems, der organisatorischen
Fähigkeiten und Beziehungsnetzwerke sowie der notwendigen und derzeitigen Ressour
cenbereitstellung anzeigen.
Je nach vorher definierten Systemgrenzen können unterschiedliche Kennzahlen-
Cockpits erzeugt werden und unterschiedliche Entscheidungsträger in der Einschätzung
über die Wissensbereitstellung unterstützt werden.
Der vorgestellte Wissensbilanz-Ansatz hat gegenüber gängigen Wissensbilanzen

zwei Vorteile: (1) Der Ausgangspunkt ist ein speziell für die Organisation angepasstes
Wissensmanagement-Modell und ermöglicht daher das kontinuierliche Verbessern und
Steuern der Wissensnutzung. (2) Der flexible Ansatz ermöglicht eine ständige Anpassung
der Wissensbilanz an das sich ständig verändernde Wissensmanagement.
18.5 Zusammenfassung
In diesem Kapitel wird die Integration von Prozess- und Wissensmanagement basie-
rend auf einem theoretischen Rahmenwerk, das in Forschungsprojekten (BOC 2013b)
entwickelt worden ist, sowie auf Erfahrungen, die in Praxisprojekten mit ADONIS®,
PROMOTE® und ADOscore® gesammelt worden sind, beschrieben.
Neben einer allgemeinen Motivation und Begriffsabstimmung wird das PROMOTE®-
Wissensmanagement-Modell, insbesondere das Wissensprodukt, vorgestellt, das eine
Integration von Prozess- und Wissensmanagement ermöglicht. Das Wissensmanagement-
Modell bildet die Grundlage für das Erstellen, Betreiben und ständige Verbessern eines
Wissensmanagement-Projektportfolios. Die Wissensbilanz wird als individuelles und flexi
bles Steuerungsinstrument für Wissensmanagement vorgestellt.
Die Integration von Prozess- und Wissensmanagement ermöglicht die Erweiterung
des Geschäftsprozesses zu einer integrativen Wissensplattform. In Folge werden einige
Erfahrungen aus Praxisprojekten vorgestellt.
Die Sichtweise auf Wissensprodukte wird als vorteilhaft angesehen, da Wissen in
einer konkreten, anwendbaren und messbaren Form dargestellt wird. Oft ist es eine
erstmalige detaillierte Darstellung von Aufgaben, Tätigkeiten, notwendigen Fähigkeiten
und Infrastruktur für notwendiges Wissen in der Organisation. Wie in den beschriebe-
nen Praxisprojekten erwähnt, hilft die Darstellung von Wissensprodukten zur besseren
Darstellung der Wissensarbeit, zur besseren Koordination von Wissensmanagement-
Initiativen und zur besseren Strukturierung von Web-Plattformen.
Das Steuerungsinstrument Wissensbilanz ermöglicht dem Management, Wissens
lücken, die zu Risiken führen können, in Form von nicht erreichten Kennzahlen dar-
zustellen und auf frühzeitiges Erkennen des Wissensbedarfs mit zielgerichteten und
transparenten Maßnahmen zu reagieren. Wie in den angeführten Praxisprojekten erwähnt,
können Erfahrungen von Managemententscheidungen dargestellt und Wissensflüsse aus
Projektergebnissen besser gesteuert werden.
Abschließend kann zusammengefasst werden, dass das Erzeugen, Verteilen und
Verwenden von Wissen in Organisationen in unterschiedlichen Formen stattfin-
det. Das zielgerichtete Steuern des Wissens, durch die Verwendung des Instruments
„Wissensmanagement“, zur Steigerung des Nutzens, zur Minimierung des Risikos und zur
Entwicklung von Fähigkeiten ist in vielen Organisationen eine Herausforderung, die mit
dem vorgestellten Ansatz unterstützt werden kann.
Literatur
Austrian Standards (2007) ÖNORM ISO 10014, Ausgabe: 2007-10-01, Arbeitsbericht, Wien. https
://www.astandis.at/shopV5/Preview.action;jsessionid=1DAC01AD83CB36039D2437135C2CB
9D3?preview=&dokkey=273618&selectedLocale=de. Zugegriffen: 12. Jan 2013
Beckman T-J (1999) The Current State of Knowledge Management. In: Liebowitz V-J (Hrsg)
Management Handbook, Boca Raton, S 1.1–1.22
BOC (2013a) PROMOTE: Process-oriented methods and tools for knowledge management.
http://www.boc-group.com/promote/. Zugegriffen: 28. Mar 2013
BOC (2013b) Forschungsprojekte der BOC Gruppe. http://www.boc-group.com/partner/wissen-
schaft-forschung/. Zugegriffen: 28. Mar 2013
Despres C, Chauvel D (1999) A Thematic Analysis of the Thinking in Knowledge Management.
Whitepaper, Graduate School of Business and The Theseus Institute, Marseille-Provence,
Sophia Antipolis. http://www.academia.edu/336437/A_Thematic_Analysis_of_the_Thinking_
in_Knowledge_Management. Zugegriffen: 12. Jan 2013
Göllner J, Mak K, Trattnig G, Woitsch R (2008) Wissensmanagement und Wissensbilanz im ÖBH
am Beispiel der ABCAbwS & ABCAbw. Projektbericht, Sonderpublikation, Schriftenreihe der
Landesverteidigungsakademie in Zusammenarbeit mit der ABC-Abwehrschule und Fa. BOC
Göllner J, Mak K, Woitsch R (2009) Wissensbilanzierung beim Österreichischen Bundesheer.
Wissensmanag Mag Führungskräfte (04)
Göllner J, Mak K, Woitsch R (2010) Grundlagen zum Wissensmanagement im ÖBH, Teil 2:
Wissensbilanz als Steuerungsinstrument im ÖBH: Ein Evaluierungs-Rahmenwerk aus der Sicht
praktischer Anwendungen. Schriftenreihe der Landesverteidigungsakademie, Wien
International Organization for Standardization (ISO) (2008) Quality management systems
-- Requirements, Arbeitsbericht, ISO 9001:2008, Genf. http://www.iso.org/iso/home/
store/catalogue_tc/catalogue_detail.htm?csnumber=46486. Zugegriffen: 17. Jan 2013
Karagiannis D, Telesko R (2000) The EU-Project PROMOTE: A Process-Oriented Approach
for Knowledge Management. In: Proceeding of Third International Conference on Practical
Aspects of Knowledge Management, Basel
Karagiannis D, Telesko R (2001) Wissensmanagement: Konzepte der Künstlichen Intelligenz und
des Softcomputing, Lehrbücher Wirtschaftsinformatik. Oldenbourg, München
Karagiannis D, Woitsch R (2010) Knowledge Engineering in Business Process Management. In:
vom Brocke J, Rosemann M (Hrsg) Handbook on Business Process Management 2. Springer,
Heidelberg
Mak K, Woitsch R (2005) Der Einsatz des prozessorientierten Wissensmanagementwerkzeuges
PROMOTE® in der Zentraldokumentation der Landesverteidigungsakademie. Schriftenreihe
der Landesverteidigungsakademie, Wien
Mak K, Hofmeister K, Göllner J, Woitsch R (2010) WM-Projekt Forsschungsmanagementsystem
(FMS) – ÖBH Modell: „Die Forschungsbilanz ÖBH“, Sonderpublikation, Schriftenreihe der
Landesverteidigungsakademie in Zusammenarbeit mit BMLVS/WFE und der Fa. BOC, Wien
Nonaka I, Takeuchi H (1995) The knowledge creating company. How Japanese companies create
the dynamics of innovation, Oxford UP, New York
Probst G, Raub S, Romhard K (1997) Wissen managen: Wie Unternehmen ihre wertvollste
Ressource optimal nutzen. Gabler, Wiesbaden
Telesko R, Karagiannis D, Woitsch R (2001) Knowledge Management, Concepts and Tools:
The PROMOTE project. In: Gronau N (Hrsg) Forum Wissensmanagement, Systeme –
Anwendungen – Technologien. Shaker, Aachen
Woitsch R (2004) Process-Oriented Knowledge Management: A Service-Based Approach. Dissertation,

Universität Wien, Wien
Woitsch R, Hrgovcic V (2011) Modelling Knowledge: An Open Models Approach. In:
Proceedings of the 11th International Conference on Knowledge Management and Knowledge
Technologies (i-KNOW ‘11), Article No. 20, Graz
Woitsch R, Mak K, Göllner J (2010) Grundlagen zum Wissensmanagement, Teil 1: Ein
WM-Rahmenwerk aus der Sicht praktischer Anwendungen. Schriftenreihe der Landesvertei
digungsakademie, Wien
Teil VIII
Abschluss
Zusammenfassung und Ausblick auf
wichtige Trends 19
Zusammenfassung
Im vorliegenden Abschlusskapitel wird eine kurze Zusammenfassung des Buchs gege-
ben. Weiterhin werden wichtige Prozessmanagement-Trends für die kommenden
Jahre skizziert.
Das Prozessmanagement mit seinen vielfältigen Aspekten ist mittlerweile in vielen

Unternehmen ein fester Bestandteil des Methodenbaukastens. Das Prozessmanagement
ist damit „Commodity“, d. h. es gehört zum Standardrepertoire praxiserprobter
Vorgehensweisen und Techniken. Das vorliegende Buch liefert mit den Kap. 2–14 nicht
nur eine Erläuterung, „was“ in den vorgestellten Facetten des Prozessmanagements getan
werden soll, sondern auch konkrete Schritte, Empfehlungen und Beispiele, „wie“ es effek-
tiv und effizient gemacht werden kann. Es soll zur Gestaltung und Umsetzung im eigenen
Unternehmen anregen.
Darüber hinaus hat sich das Prozessmanagement vom reinen Organisations- und
Optimierungsinstrument hin zu einem Führungsinstrument entwickelt und ist heute in
den Führungsebenen der Unternehmen als Managementansatz angekommen. Auch in
diesem Umfeld liefert das Buch mit den Kap. 15–18 einen hilfreichen Beitrag, wie sich
das Prozessmanagement mit anderen etablierten Managementansätzen zu einem sinn-
vollen Ganzen integrieren kann (Stichwort: Integrierte Managementsysteme).
Es lassen sich für die kommenden Jahre diverse Tendenzen im Prozessmanagement
absehen, wovon wir drei aus unserer Sicht wichtige Trends im Folgenden kurz skizzieren:
1. Prozessmanagement als Bestandteil eines integrierten Managementsystems

Das strategische Prozessmanagement ist Aufgabe der Unternehmensführung und des
Senior Managements. Es kann nicht delegiert werden. Um die Durchgängigkeit einer
H. Kühn (*) · F. Bayer

e-mail: harald.kuehn@boc-eu.com

Topmanagement-Entscheidung in die operative Umsetzung sicherzustellen, ist vom

Prozessmanagement gefordert, ein noch klareres Rollen- und Aufgabenverständnis zu
entwickeln. Weitere methodische Arbeiten und deren Aufbereitung zu Best Practice-
Ansätzen sind notwendig, um bspw. ausgehend von den Unternehmenszielen die
Gestaltungsprinzipien für eine Prozessarchitektur noch transparenter ableiten und hier-
aus konkrete Vorgaben für das Prozessdesign machen zu können.
Eine weitere Tendenz ist, dass das Prozessmanagement mehr und mehr mit den
„benachbarten“ Managementansätzen integriert wird (vgl. Kap. 15–18). Auch hier
erwarten wir künftig sowohl auf der methodischen als auf der Werkzeugseite einen noch
intensiveren Austausch und Nutzung sich daraus ergebender Synergien in der Praxis.
Ein wichtiger Aspekt ist dabei die unmittelbare Messbarkeit von prozessrelevanten
Entscheidungen über die Grenzen der Managementansätze hinweg.
2. Agilität mittels Prozessmanagement

Die zeitliche Distanz von einer Produkt- oder Dienstleistungsidee bis zu deren
Realisierung in ein marktreifes Angebot wird immer kürzer. Vom Prozessmanagement
wird dabei gefordert, die relevanten Teile des damit verbundenen Wegs möglichst effi-
zient zu gestalten. Alleinstellungsmerkmale zu Mitbewerbern können nicht nur über
das Angebotsportfolio selbst, sondern insbesondere auch über die zugrunde liegenden
Prozesse gewonnen werden.
Die Auswirkungen von Änderungen im Produkt- oder Dienstleistungsportfolio auf
die relevanten Unternehmensprozesse, Organisationsstrukturen und IT-Systeme müs-
sen bereits vor der Realisierung nachvollziehbar sein. Dies wird umso wichtiger, je mehr
die eigenen Prozesse zur Erreichung von agilen Strukturen durch Lieferanten- und
Partnerprozesse zu Wertschöpfungsketten horizontal und vertikal integriert werden.
Seitens der Informationstechnologie wird dies ergänzt durch Ansätze, wie eine zuneh-
mende Standardisierung von Prozesstechnologien oder durch „As-a-Service“-Ansätze
basierend auf Cloud Computing. Das Prozessmanagement spielt dabei mehr und mehr
die zentrale Rolle, um agile Vorgehensweisen in der Unternehmenssteuerung und -ent-
wicklung zu ermöglichen.
3. Partizipation im Prozessmanagement
Community-Systeme, wie Facebook® und Google+® vorrangig im privaten Bereich
sowie XING® und LinkedIn® mit dem Schwerpunkt im geschäftlichen Umfeld, haben
neue Möglichkeiten geschaffen, den Informationsaustausch von Personengruppen
zu unterstützen. Es ist damit zu rechnen, dass Unternehmens-Community-Systeme,
wie bspw. JIVE™ oder blueKiwi™, in den nächsten Jahren ebenfalls verstärkt Einzug
in die Unternehmensinfrastruktur halten und damit als ergänzende Hilfsmittel im
Prozessmanagement zur Verfügung stehen werden.
Die zentralen Rollen bei der Ist-Erhebung und Soll-Konzeption von Prozessen sind
der Prozessverantwortliche, der Prozessexperte und der Prozessberater. Die ande-
ren Rollen werden jeweils nach Bedarf involviert. Heute interagieren diese Rollen typi-
scherweise mit Hilfe von Feedback-Interviews, organisatorischen Freigabeprozessen,
19 Zusammenfassung und Ausblick auf wichtige Trends 377
methodischen und fachlichen Reviews o. ä. miteinander. Moderne Prozessmanagement-

Software mit Prozessportal-Funktionen, Feedback-Möglichkeiten, Community Features,
Instant Messaging etc. ermöglichen zusätzlich eine unmittelbarere und weiterführende
Partizipation im Prozessmanagement von nahezu allen Mitarbeitern in einer Organisation.
Dies unterstützt sowohl die operativen Verfahren im Prozessmanagement, aber vor allem
auch die Etablierung des Prozessmanagements als Führungs- und Steuerungssystem in der
Organisation.
Das vorliegende Buch liefert Impulse für das Prozessmanagement und deckt dabei
sowohl aktuelle als auch wiederkehrende Themen ab, die immer wieder in Projekten nach-
gefragt werden. Wie die Zukunft im Bereich Prozessmanagement im Detail aussehen wird,
können wir leider nicht prognostizieren. Allerdings sind wir überzeugt, dass der beste
Weg, die Zukunft „vorherzusagen“, ist, sie aktiv zu gestalten. In diesem Sinne wünschen
wir Ihnen ein erfolgreiches Gestalten und Gelingen Ihrer Prozessmanagement-Aktivitäten.
Anhang 1: ADONIS:Community Edition
Die im Buch dargestellten Prozessmodelle wurden mit dem Geschäftsprozessmanagement-

Werkzeug ADONIS® erstellt. Die kostenfreie ADONIS:Community Edition kann unter
folgender Web-Adresse heruntergeladen werden: www.adonis-community.com.

DOI: 10.1007/978-3-642-36995-7, © Springer-Verlag Berlin Heidelberg 2013
Anhang 2: ADOit:Community Edition
Die im Buch dargestellten Unternehmensarchitektur-Modelle wurden mit dem EAM-

Werkzeug ADOit® erstellt. Die kostenfreie ADOit:Community Edition kann unter fol-
gender Web-Adresse heruntergeladen werden: www.adoit-community.com.

Sachverzeichnis
A Business IT Alignment, 314, 317

ABC. Siehe Activity-based Costing Vorgehen, 320
Activity-based Costing (ABC), 193 Business Process Management Systems
Anforderungsmanagement, 266 (BPMS), 20, 94, 296, 359
Animation, 155 Business Process Model and Notation
Application Management Life Cycle, 250 (BPMN), 99
Choreographiediagramm, 106
Geschäftsprozessdiagramm, 107
B Konversationsdiagramm, 105
Balanced Scorecard (BSC), 301 Stärken und Schwächen, 100
Bearbeitungszeit (BZ), 146, 163 BZ. Siehe Bearbeitungszeit
Bebauungsplan, 314
Benchmarking, 213
BPMN. Siehe Business Process Model and C
Notation Checkliste, 212
BPMS. Siehe Business Process Management Compliance, 116
Systems Anwendungsbeispiel, 127
BPMS-Modellierungsmethode, 95 Assessment, 124
Anwendungsfalldiagramm, 98 Bewertung, 122
Arbeitsumgebungsmodell, 97 Scoping, 119
Choreographiediagramm, 106 Scoring, 123
Datenmodell, 98 Vorgehen, 117
Dokumentenmodell, 98
Geschäftsprozessdiagramm, 107
D
Geschäftsprozessmodell, 97
Design Effectiveness, 338, 351
IT-Systemmodell, 98
Durchlaufzeit, 145
Kontrollen-Katalog, 99
Konversationsdiagramm, 105
Produktmodell, 96 E
Prozesslandkarte, 96 EAM. Siehe Enterprise Architecture
Ressourcenmodell, 98 Management
Risiko-Katalog, 98 EFQM. Siehe European Foundation for Quality
Brainstorming, 219, 344 Management
BSC. Siehe Balanced Scorecard Enterprise Architecture Management (EAM),
Business Capability, 317 314

384 Sachverzeichnis
ERP-System, 255 Internes Kontrollsystem (IKS), 334

European Foundation for Quality Management Definition, 334
(EFQM), 128 Design Effectiveness, 351
Operating Effectiveness, 352
Optimierung, 350
F Vorgehen, 335
Fehlermöglichkeits- und Einflussanalyse Interview, 213
(FMEA), 344 Ishikawa-Diagramm, 215
FMEA. Siehe Fehlermöglichkeits- und
Einflussanalyse
J
Jahresarbeitszeit (JAZ), 166
G JAZ. Siehe Jahresarbeitszeit
GAZ. Siehe Gesamtarbeitszeit
Gesamtarbeitszeit (GAZ), 163, 164
Geschäftsfähigkeit, 317 K
Geschäftsregel, 264 Kennzahl, 277, 301
Gestaltungsprinzip, 38 Kennzahlensystem, 279
Gestaltungsrichtlinie, 74 Klassifikation
Detaillierungsgrad, 81 IT-Anwendung, 253
Qualitätssicherung, 89 Verfahren zur Prozessanalyse, 137
Verantwortung, 90 Kooperationsbild, 209
Vorgehen, 90 Kostenrechnung, 191
Wiederverwendung, 84 Einzelkosten, 192
Grundsätze ordnungsmäßiger Modellierung Gemeinkosten, 192
(GoM), 76 Teilkostenrechnung, 192
Klarheit, 79 Vollkostenrechnung, 192
Relevanz, 78
Richtigkeit, 77
Systematischer Aufbau, 81 M
Vergleichbarkeit, 80 MDA. Siehe Model Driven Architecture
Wirtschaftlichkeit, 78 Model Driven Architecture (MDA), 256
Modellierungsrichtlinie, 74, 87
Qualitätssicherung, 89
H Verantwortung, 90
Heat Map, 125 Vorgehen, 90
Modelltyp, 95
I
IKS. Siehe Internes Kontrollsystem O
IKS-Life Cycle, 335 Operating Effectiveness, 338, 352
Individualsoftware, 258
Integration
mit Risikomanagement, 339 P
mit strategischem Management, 298 Personalbedarfsermittlung, 159
mit Unternehmensarchitektur- Definition, 161
Management, 314 Ergebnisdarstellung, 169
mit Wissensmanagement, 358 erweitertes Modell, 164
Sachverzeichnis 385
Grundmodell, 162 leistungsmengeninduziert, 193

Parametererhebung, 176 leistungsmengenneutral, 193
prozessbasiert (P-PBE), 162 Praxisbeispiel, 196
Personalbedarfskapazität, 167, 168 Umlageverfahren, 195
Personalbedarfsplanung, 161 Verantwortung, 50
Personalmanagement, 161 Vorgehen, 194
PfM. Siehe Prozesspfadmenge Zielsetzung, 189
PM. Siehe Prozessmenge Prozesslandkarte, 38
PMLC. Siehe Process Management Life Cycle Bewertung, 47
P-PBE. Siehe Personalbedarfsermittlung, Determinante, 42
prozessbasiert Nutzen, 40
Process Management Life Cycle (PMLC), Prozessmerkmal, 42
5, 12 Vorgehen zur Gestaltung, 42
Anwendung, 14 Prozessmanagement
IKS-Integration, 340 Definition, 12
kontinuierlicher Ansatz, 15 Trends, 375
Phasen, 12 Prozessmarketing, 246
projektorientierter Ansatz, 16 Prozessmenge (PM), 163
Process Mining, 138, 288 Prozessmodell, 23, 95
Process Monitoring, 138 Prozessmodellierung, 73, 94, 260
Process Passport, 126 Prozessoptimierung, 25, 137, 167, 189,
Process Portfolio, 127 203, 346
Produkt-Prozess-Matrix, 208 qualitativ, 204
Prozess quantitativ, 137, 167
Benchmarking, 52 Vorgehen, 139, 206
Definition, 12 Prozessoptimierungs-Projekt, 26
fachliches Schneiden, 263 Prozesspfadmenge (PfM), 166
Harmonisierung, 51 Prozessportfolio-Management, 60
Sourcing, 52 Prozessschwachstelle, 26
Standardisierung, 51, 85 Prozessstrategie, 22, 39, 60, 341
Prozessanalyse, 288 Prozessumsetzung, 29, 226, 250, 349
Prozessarchitektur, 38 organisatorisch, 226
Verantwortung, 50 technisch, 250
Prozess-Compliance, 117 Vorgehen, 228, 260
Prozesscontrolling, 30, 64, 274, 350 Prozessvariante, 44
Aufgabe, 276 Prozessverantwortung, 68
Erfolgsfaktor, 290 Prozessziel, 277
IT-Unterstützung, 286 operativ, 62
Regelkreis, 281 strategisch, 61
Vorgehen, 288
Zielsetzung, 274
Prozessdokumentation, 23, 73, 94, 117, 342 Q
Ist-Erhebung, 207 Quantitative Analyse, 137
Prozessdurchführung, 29, 349 Analyseobjekt, 143
Prozess-Engine, 255 Diagnostische Größe, 142
Prozesskennzahl, 64 Entscheidungsgröße, 142
Prozesskostenrechnung, 187, 193 Parameter, 144
Bewertung, 200 Vorgehen, 139
386 Sachverzeichnis
R U
Rechnerische Auswertung, 148 UAZ. Siehe Unternehmensarbeitszeit
Reifegradmodell, 216 Umsetzungsplanung, 229
Risikomanagement, 334 Erfolgsfaktor, 230
Rolle I-K-B-Modell, 232
im Anforderungsmanagement, 269 Medium, 234
im Prozessmanagement, 17 Unternehmensarbeitszeit (UAZ), 146, 166
Prozesscontrolling, 31 Unternehmensarchitektur
Prozessdokumentation, 25 Bewertung, 329
Prozessdurchführung, 30 Definition, 314
Prozessoptimierung, 28 Geschäftsarchitektur, 324
Prozessstrategie, 23, 50 Informationssystemarchitektur, 326
Prozessumsetzung, 252 Unternehmensarchitektur-Management, 314
weiterführende, 19 Vorgehen, 320
Unternehmenskapazität, 167
Ursache-Wirkungs-Diagramm, 215
S
Simulation, 152
Animation, 154 V
Auslastungsanalyse, 154 Veränderungsmanagement, 236
Belastungsanalyse, 153 Eisbergmodell, 242
Pfadanalyse, 152 Phase, 241
Standardisierung
Pattern, 52, 85
Prozess, 52, 85 W
Subprozess, 52, 85 Wissensmanagement, 356
Standardsoftware, 254 Definition, 357
Strategisches Management, 296 Vorgehen, 359
Integrationsmethode, 301 Wissensbilanz, 367
Praxisbeispiel, 306 Wissensmanagement-Rahmenwerk, 358
Wissensprodukt, 358, 361
Workflow-System, 255
T
The Open Group Architecture Framework
(TOGAF), 315 Z
Architecture Development Method, 320 Zielorientiertes Prozessmanagement, 58, 305
Phase Business Architecture, 323 Verantwortung, 65
Phase Information Systems Architectures, Vorgehen, 58
326
Phase Opportunities and Solutions, 329
TOGAF. Siehe The Open Group Architecture
Framework

Prozessmanagement Für Experten: Franz Bayer Harald Kühn HRSG

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Prozessmanagement Für Experten: Franz Bayer Harald Kühn HRSG

Hochgeladen von

Copyright:

Verfügbare Formate

Franz Bayer

Harald Kühn Hrsg.

ISBN 978-3-642-36994-0 ISBN 978-3-642-36995-7 (eBook)

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk

Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier

Januar 2013 Dimitris Karagiannis

Januar 2013 Dr. Franz Bayer und Dr. Harald Kühn

3 Prinzipien für die Gestaltung der Prozessarchitektur. . . . . . . . . . . . . . . . . . . . . . 37

Teil III Prozessdokumentation

5.2.2 Grundsatz der Relevanz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.6.2 Process Passports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

9.3 Ergebnisdarstellung in der prozessbasierten

11.5.3 Kundenumfragen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

13.2.2 Einführung von Standardsoftware/ERP-Systemen. . . . . . . . . . . . 254

Teil VI Prozessdurchführung und Prozesscontrolling

Teil VII Integrierte Managementsysteme

15.1.1 Definition und Abgrenzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

17.3.4 Prozessumsetzung: Überwachung der Prozessumsetzung

Teil VIII Abschluss

ABC Activity-based Costing

EFQM European Foundation for Quality Management

P-FMEA Process Failure Mode and Effects Analysis (deutsch:

A. Gericke (*) · F. Bayer · H. Kühn

F. Bayer und H. Kühn (Hrsg.), Prozessmanagement für Experten, 3

1.2 Fokus und Zielgruppe

1.3 Der Process Management Life Cycle im Kontext

Bei der Umsetzung eines kontinuierlichen Prozessmanagements können diverse Vorge­

Unter Zuhilfenahme dokumentierter Prozesse kann eine Prozessoptimierung angesto-

Abb. 1.1 Aufbau des Buchs

Tab. 1.1 Erläuterung der einzelnen Buchkapitel

Tab. 1.1 (Fortsetzung)

In den zuvor vorgestellten Kapiteln werden einzelne Themen detailliert beschrieben.

Tab. 1.2 Leseempfehlung

Die Kapitel enthalten Handlungsempfehlungen, wie das entsprechende Thema adres-

Junginger S (2000) Modellierung von Geschäftsprozessen: State-of-the-Art, neuere Entwicklungen

A. Gericke (*) · F. Bayer · H. Kühn · T. Rausch

F. Bayer und H. Kühn (Hrsg.), Prozessmanagement für Experten, 11

2.1 Überblick über den Lebenszyklus des

2.1.1 Einordnung der Begrifflichkeiten

Unternehmen unterliegen einem kontinuierlichen Wandel. Die Gründe hierfür sind

Der PMLC hilft Unternehmen, ihre Geschäftsprozesse kontinuierlich zu ver-

2.1.2 Die Phasen des Process Management Life Cycle

Abb. 2.1 Der Process

2.1.3 Anwendung des Process Management Life Cycle

Um einen kontinuierlichen Prozessmanagement- und Prozessverbesserungs-Ansatz

Abb. 2.2 Überspringen von

In einzelnen Fällen ist es ebenso möglich, dass im Rahmen der Prozessdokumentation

Mittel zur Strukturierung der Prozessoptimierungs-Projekte verwendet. Techniken und

2.2 Die Rollen im Rahmen des Prozessmanagements

2.2.1 Wesentliche Rollen

Im Rahmen des Prozessmanagements können im Allgemeinen die folgenden Rollen

• Chief Process Officer/Prozesssponsor

Prozess- Konkreter modelliert

führt aus ist verantwortlich für

2.2.2 Weitere involvierte Rollen

Im Kontext des Prozessmanagements besteht die Möglichkeit – je nach Größe des

Die Rollendefinitionen müssen in den jeweiligen Unternehmensbereichen/Domänen

2.3 Einordnung des Process Management Life Cycle

Ähnliche Vorgehensmodelle im Vergleich zum vorgestellten PMLC finden sich bei-

Der PMLC ist ein häufig in der Praxis eingesetzter Prozessmanagement-Ansatz,

2.4 Die Phasen des Process Management Life Cycle

Tab. 2.2 Typische Detaillierungsebenen der Prozessmodellierung

1.2 Fokus und Zielgruppe

1.3 Der Process Management Life Cycle im Kontext

Bei der Umsetzung eines kontinuierlichen Prozessmanagements können diverse Vorge

2.1 Überblick über den Lebenszyklus des

2.1.1 Einordnung der Begrifflichkeiten

2.1.2 Die Phasen des Process Management Life Cycle

2.1.3 Anwendung des Process Management Life Cycle

2.2 Die Rollen im Rahmen des Prozessmanagements

2.2.1 Wesentliche Rollen

2.2.2 Weitere involvierte Rollen

2.3 Einordnung des Process Management Life Cycle

2.4 Die Phasen des Process Management Life Cycle

Im Zuge der Prozessumsetzung sollte sichergestellt werden, dass die Prozess

3.2 Zusammenspiel Unternehmensstrategie

3.3 Nutzenaspekte der Prozesslandkarte

3.4 Vorgehen zur Gestaltung der Prozesslandkarte

3.4.1 Das Konzept

3.4.2 Techniken zur Strukturierung

3.4.3 Umsetzung der Struktur mit der Prozesslandkarte

3.4.4 Techniken zur Bewertung von Prozesslandkarten

3.5 Regelung von Verantwortung in der Prozessarchitektur

3.6 Ausgewählte Beispiele zur Verwendung der

3.6.1 Standardisierung und Harmonisierung