Ein Rahmenwerk für das Prozessdesign zur Identifikation, Klassifikation und Umsetzung von Anforderungen - Dargestellt an der Konzeption des Prozesskonfigurators

Ein Rahmenwerk für das Prozessdesign zur Identifikation, Klassifikation und Umsetzung von Anforderungen - Dargestellt an der Konzeption des Prozesskonfigurators Von der Universität Bayreuth zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer.nat.) genehmigte Abhandlung von Dipl.-Wirtsch.-Ing. Stephanie Meerkamm geboren in Krefeld-Uerdingen 1. Gutachter: Prof. Dr. Stefan Jablonski 2. Gutachter: Ass. Prof. Dr. Jan Recker Tag der Einreichung: 07. Oktober 2011 Tag des Kolloquiums: 27. März 2012 I Zusammenfassung Prozessmanagement umfasst die Identifikation und Analyse der Unternehmensabläufe sowie deren Dokumentation und die Ausführung der Prozesse inklusive deren Steuerung. Dies sollte mit einer stetigen Verbesserung der Prozesse verbunden sein. Im Hinblick auf die konkrete Realisierung dieses Management-Ansatzes ist eine Fokussierung auf die Phase der Modellierung, welche die Identifikation sowie Dokumentation der Prozesse umfasst, zu beobachten. Dieser Phase geht das sog. Prozessdesign voraus. Auf Basis einer eingehenden Anforderungsanalyse erfolgt die Entwicklung und Evaluierung von Artefakten, wie zum Beispiel Konstrukte und/oder Methoden. Das vollständige Spektrum an Handlungsmöglichkeiten innerhalb des Prozessdesigns wird jedoch nur selten genutzt. Meist werden vorhandene (Standard-) Modellierungssprachen ausgewählt ohne diese in irgendeiner Art individuell zu gestalten. Dies wirkt sich oft negativ auf die Qualität der damit erstellten Prozessmodelle aus, aber auch auf die der Modellierung nachfolgenden Phasen des Management-Ansatzes wie Ausführung und Controlling. Im ersten Teil der vorliegenden Arbeit wurde ein daher methodisches Rahmenwerk für das Prozessdesign entwickelt. Aufgrund der engen Kopplung an die nachfolgende Phase der Prozessmodellierung wird als Grundlage eine Meta-Modell-Hierarchie verwendet, die die Entwicklung, Anpassung sowie Definition von (Meta) Modellen vorsieht. Diese wurde explizit um eine Designkomponente inklusive der initialen Anforderungsanalyse erweitert. Damit liegt ein flexibles Vorgehensmodell für die Durchführung der Designphase vor, das dabei vor allem auch die Definition von Modellierungssprachen vorsieht. Das gesamte Rahmenwerk ist zudem nicht auf eine bestimmte Modellierungssprache oder Anwendungsdomäne der Prozesse ausgerichtet, sondern generisch konzipiert. Im zweiten Teil der Arbeit wird ein Anwendungsfall für das zuvor entwickelte Rahmenwerk vorgestellt. Aus der beispielhaft identifizierten Menge an Anforderungen wurde die des Managements variantenreicher Prozessmodelle ausgewählt und das Konzept eines Prozesskonfigurators entwickelt. Im Hinblick auf die Verwendung der variantenreichen Prozessmodelle wurde ein gestufter Konfigurationsprozess entwickelt. Dieser leitet den Anwender auf der einen Seite durch den Konfigurationsprozess, auf der anderen Seite wird ihm ein Höchstmaß an Freiheit gewährt, wann er welche variantenbezogene Entscheidung treffen möchte. Für die Darstellung der Varianten in einem Modell wurde ein bereits existierendes Konzept zur Abbildung variantenreicher Strukturen in Form des sog. mereologischen Graphen verwendet, das an die Eigenschaften von Prozessen angepasst wurde. Damit kann die gewünschte kompakte sowie strukturierte Modellierung der Varianten in einem Modell realisiert werden. Dieses Modellierungskonzept konnte als Prototyp in einem entsprechenden Modellierungswerkzeug implementiert werden. III Abstract Process management comprises the identification and analysis of procedures within an organization, their documentation and, finally, the execution of the processes inclusive of the monitoring and controlling which is supposed to lead to continuous improvement of these processes. With regard to the implementation of this management approach there is a focus on the phase of modeling which comprehends the identification as well as the documentation of the processes. The so called process design precedes this phase. On the basis of an exhaustive requirement analysis the development and evaluation of artifacts, for example constructs and/ or methods, takes place. The complete scope of action of process design is, however, used quite rarely. Given (standard) process modeling languages are normally selected and no individual design work is carried out. This has a negative impact on the quality of the resulting process models and the phases which follow the modeling, such as, for example, execution and controlling. In the first part of the work in hand a methodical framework for the process design has been developed. Due to the close conjunction with the subsequent modeling phase a meta-modelhierarchy, which allows for the development, adaption and the definition of (meta) models, is used as a basis. This has been extended explicitly by a design component which also includes the initial requirement analysis. By this means a flexible procedure model for the accomplishment of the design phase is available, which mainly envisages the definition of modeling languages. In addition, the framework is not focused on a particular modeling language or application domain, but is conceived generically. In the second part of this work a user case study of the previously developed framework is presented. From the requirements which have been identified and exemplified, the management of variant-rich process models has been selected. For this, the concept of a process configurator has been developed and, in order to facilitate the usage of the variantrich process models, a staged configuration process has been developed. This, On the one hand, guides the user during the configuration process while, on the other hand, the user is accorded the maximum freedom of action concerning the point of time at which he wants to take the variant related decision. In order to model the variant-rich processes efficiently an already existing concept for illustrating variant-rich structures, the so called mereological graph, has been adapted according the characteristics of processes. With the adoption of this concept the desired compact and structured method of modeling variants in one single model could be achieved. It was finally possible to implement the modeling concept as a first prototype in an appropriate modeling tool. V Vorwort Auf dem Weg zu der vorliegenden Arbeit haben mich zahlreiche Leute begleitet und zu ihrem erfolgreichen Abschluss beigetragen. Ich möchte mich an dieser Stelle für ihre Unterstützung, ihre Ratschläge und ihre aufgebrachte Zeit bedanken. Mein Dank gilt Herrn Prof. Dr.-Ing. Stefan Jablonski, an dessen Lehrstuhl diese Arbeit entstanden ist. Herrn Ass. Prof. Dr. Jan Recker danke ich für die Übernahme des Zweitgutachtens. Ich möchte mich bei meinem Kollegen Bernhard Volz bedanken, der mich mit viele und langen Gesprächen unterstützt hat und meine Ingenieur-Fragen zur Informatik stets mit großer Geduld beantwortet hat. Christine Leinberger, der gute Seele des Lehrstuhls, danke ich für selbstlose Unterstützung während meiner Zeit am Lehrstuhl. Mit ihrer fröhlichen und optimistischen Art, ihrem beispielhaft vorgelebten Durchhaltevermögen hat sie mich auf ihre Art und Weise bei meiner Promotion unterstützt. Bernd Schlesier danke ich für die zahlreichen, herzlichen Gespräche und seine stetige Hilfsbereitschaft. Wenn ich ihn nicht kennengelernt hätte, hätte ich wahrscheinlich niemals mit einer Promotion begonnen: Sascha Müller-Feuerstein. Er hat mich mit viel Fingerspitzengefühl, Humor (auch wenn er bei meinen Lachanfällen manchmal seine Zweifel hatte - ich habe ihn ernst genommen) und ungemeinem Fachwissen in die Welt der Wissenschaft bzw. in die Welt der Informatik eingeführt. Für die vielen langen Gespräche, in denen er stets großes Interesse an meiner fachlichen wie auch persönlichen Weiterentwicklung hatte, danke ich ihm ganz herzlich. Ich hoffe ihm mit dieser Arbeit ein wenig von dem zurückgeben zu können, was er mir gegeben hat. Danken möchte ich dem SC Uttenreuth. Das Leben im Verein hat mich persönlich geprägt und Werte vermittelt, die ich hoffentlich noch vielen Menschen innerhalb und außerhalb des Vereins weitergeben kann. Die Zeit, die ich dort verbracht habe, möchte ich nicht missen. Dass ich in Bayreuth nicht komplett in der Dissertation versunken bin, habe ich verschiedenen Leuten zu verdanken. Dazu beigetragen hat die Tennisabteilung des SV Heinersreuth (Ich habe dort das bisher beste Tennis meiner „Karriere“ gespielt). Zusammen mit den „Siemensianern“ aus Kemnath durfte ich, als „Externe“, viele gemütliche Abende verbringen. Mit der „Spielegruppe“ habe ich einen Kreis von Menschen gefunden, zu denen ich hoffentlich noch lange Kontakt halten kann, auch wenn ich nun nicht mehr direkt vor Ort bin. Last but not least möchte ich ganz besonders Sabrina Uhrig bedanken. Direkt am Nachbarlehrstuhl in der Angewandten Informatik haben wir uns gegenseitig bei unseren Arbeiten unterstützt; sie ist für mich mehr als eine Kollegin geworden. Ein Dankeschön geht an meinen Studienfreundeskreis, der „MB-Crew“ aus Erlangen für die Treue, trotz der wenigen Zeit, die ich oftmals für sie aufgebracht habe. Ganz besonders danke ich Stefanie Klingner und Stephan Schuh. Roy Remannifield danke ich für die Reviews meines Papers. Zu aller Letzt, jedoch am allermeisten, möchte ich mich bei denen bedanken, die mich auf dem gesamten Lebensweg bis hier hin begleitet haben. Die notwendige Kraft und das Durchhaltevermögen, um die Promotion letztendlich erfolgreich abschließen zu können, haben mir vor allem der Rückhalt durch meine Eltern und meine Zwillingsschwester ermöglicht. Sie haben mich unermüdlich unterstützt, immer wieder aufgebaut und stets an mich und meine Fähigkeiten geglaubt. Der Wert einer Familie lässt sich nur schwer in Worten fassen, ich sage einfach von ganzen Herzen: Danke! . XIV Abbildung 6-7 Nach PESOA annotiertes BPMN-Prozessmodell .......................................... 158 Abbildung 6-8 Beispiel mit Aufsetzpunkten aus [HaBR08a] ................................................ 160 Abbildung 6-9 Kategorisierung der Anforderungen .............................................................. 163 Abbildung 6-10 Konzept des Prozesskonfigurators ............................................................... 166 Abbildung 6-11 ER-Diagramm .............................................................................................. 167 Abbildung 6-12 Konzeptueller Aufbau der Datenbasis ......................................................... 176 Abbildung 6-13 Generisches Datenmodell [eigene Quelle] .................................................. 179 Abbildung 6-14 Implikation zwischen verschiedenen Aspekten ........................................... 181 Abbildung 6-15 variation point und variant options .............................................................. 182 Abbildung 6-16 Hierarchisch angeordnete variation points [eigene Quellen] ....................... 183 Abbildung 6-17 Darstellung der konfigurierbaren Stellen ..................................................... 186 Abbildung 6-18 Konfigurierbares AOPM-Prozessmodell ..................................................... 189 Abbildung 6-19 Rechnung schreiben – integriertes AOPM-Prozessmodell .......................... 194 Abbildung 6-20 Rechnung schreiben - Variante 1 ................................................................. 195 Abbildung 6-21 Rechnung schreiben – Variante 2 ................................................................ 195 Abbildung 6-22 Rechnung schreiben – generisches Datenmodell ......................................... 197 Abbildung 6-23 Screenhoot OMME ...................................................................................... 201 Abbildung 6-24 Deklaration des Graphen auf M2 ................................................................. 201 Abbildung 6-25 Deklaration der Knoten auf M2 ................................................................... 202 Abbildung 6-26 Deklaration der Kanten auf M2 ................................................................... 203 Abbildung 6-27 Deklaration der Verbindungen auf M2 ........................................................ 203 Abbildung 6-28 Screenhot eines generisches Datenmodells in OMME ................................ 204 Abbildung 6-29 Deklaration des variation points auf M2 ...................................................... 205 Abbildung 6-30 Deklaration der organisatorischen variant option auf M3 ........................... 205 Abbildung 6-31 Konfigurierbares AOPM-Modell in OMME ............................................... 206 Abbildung 7-1 Konkretisierte Teilphasen des Designs .......................................................... 210 XV Tabellenverzeichnis Tabelle 2-1 Übersicht über die befragten Unternehmen .......................................................... 36 Tabelle 3-1 Beispiele Informationsobjekte EPK ...................................................................... 53 Tabelle 3-2 Beispiele für Verwendung von Modellen ............................................................. 56 Tabelle 3-3 Design-Artefakte nach [HMPR04] ....................................................................... 59 Tabelle 3-4 Gegenüberstellung pragmatisches und theoretisches Prozessdesign .................... 69 Tabelle 4-1 Beispiele Phasen ................................................................................................... 97 Tabelle 4-2 Beispiele kreativer bzw. unscharfer Prozesse ..................................................... 100 Tabelle 4-3 Beispiele umfangreicher Prozesse ...................................................................... 103 Tabelle 4-4 Beispiele zeitliche Perspektive ........................................................................... 107 Tabelle 4-5 Beispiele komplexer Entscheidungssituationen .................................................. 109 Tabelle 4-6 Beispiele ausführbare Prozessabschnitte ............................................................ 111 Tabelle 4-7 Beispiele Sprünge ............................................................................................... 113 Tabelle 4-8 Beispiele unterschiedlicher Sichtweisen ............................................................. 116 Tabelle 4-9 Beispiele Datentypen .......................................................................................... 118 Tabelle 4-10 Beispiele Prozesstypen ...................................................................................... 119 Tabelle 6-1 Prozessvorauswahl – Auswahl der variant options ............................................. 184 Tabelle 6-2 Prozessausführung - Entscheidungsmöglichkeit I .............................................. 185 Tabelle 6-3 Prozessausführung - Entscheidungsmöglichkeit II ............................................. 185 Tabelle 6-4 Zuordnung der Elemente - Sprachunabhängigkeit ............................................. 188 Tabelle 6-5 Abbildung generisches Datenmodell - AOPM ................................................... 192 XVI MOTIVATION 1.1 1 Kapitel 1 Einführung 1.1 Motivation Während schon gegen Ende des letzten Jahrtausends Davenport und Short [DaSh90] sowie Hammer und Champy [HaCh93] die Bedeutung der Prozesse im Rahmen einer (Unternehmens-) Organisation herausgearbeitet haben, ist das Management der Anwendungsprozesse [JaBS99] heutzutage mehr denn je eine herausfordernde Aufgabe [GaGr09] [Hamm01] [SmFi03]. Die Globalisierung, die wirtschaftlichen Turbulenzen wie sie die Finanzkrise 2010 mit sich gebracht hat, gestiegene Compliance-Anforderungen an die Unternehmen, wie zum Beispiel im Zusammenhang mit dem Sarbanes-Oxley Act aus dem Jahr 2002, oder auch der technologische Fortschritt der eingesetzten Informationstechnologien erfordern eine entsprechende Organisation der Unternehmen und ihrer Abläufe. Prozessmanagement umfasst die Identifikation und Analyse der Abläufe einer Organisation sowie deren Dokumentation, bis hin zur Ausführung der Prozesse samt ihrer Steuerung, was mit einer stetigen Verbesserung der Prozesse verbunden sein sollte [GaSc95] [ScSe08] [vBRo10]. Dabei geht es sowohl um organisatorische Aspekte im Hinblick auf die eingesetzten Ressourcen, als auch um die Unterstützung durch geeignete Informationstechnologien. Die genannten Aufgaben werden in Form eines sogenannten, sich wiederholenden, Prozesslebenszyklus organisiert [BeKR05] [zMRo04] (in Kapitel 2.3.1 folgt eine umfassend Erläuterung). 1.1.1 Modellierung und der Aspekt des Designs Im Hinblick auf die konkrete Realisierung des Prozessmanagement-Ansatzes konnte in den letzten Jahren eine zunehmende Fokussierung auf die Identifikation sowie Dokumentation der (Geschäfts-) Prozesse beobachtet werden [DGRI06] [Rose06a]. Letzteres, die Modellierung der Prozesse, beinhaltet die graphische Abbildung der Abläufe inklusive der Angabe von Ressourcen (zum Beispiel Daten, Rollen, Werkzeuge [Agui04] [CuKO92] [JaBu96]). Dabei kommen Prozessmodellierungswerkzeuge mit einer zumeist graphischen Modellierungssprache bzw. -notation wie zum Beispiel BPMN [OMG11a] zum Einsatz. Prozessmodelle werden in den verschiedensten Anwendungsdomänen (unter anderem Medizin, Produktentwicklung, Verwaltung…) verwendet; ebenso vielfältig sind die Einsatzzwecke der Modelle (Training, Analyse, Simulation, Ausführung, Entwicklung von Informationssystemen zur automatisierten Prozessausführung, etc., [CuKO92] [DuAH05] 1.1 MOTIVATION 2 [DevA04]), so dass sich die unterschiedlichsten Anforderungen an die Modellierungssprache und das Werkzeug ergeben. Mit der Veröffentlichung des Artikels von Hevner [HMPR04] hat das Interesse bzgl. des sog. Designs im Bereich der Informationssysteme erheblich zugenommen. Zuvor sind dazu bereits zahlreiche Beiträge veröffentlicht worden wie zum Beispiel von [Glas99], [MaMG02], [MaSm95], [WaWE92] oder [Wino97]. Die Designphase umfasst demnach die Entwicklung und Evaluierung von Artefakten, wie zum Beispiel Methoden, Konstrukte oder Modelle, auf Basis konkreter Anforderungen. Im Kontext des Prozessmanagements handelt es sich um Anforderungen bzgl. der Gestaltung der Prozessmodelle und deren Ausführung. Diese Anforderungen werden umgesetzt in der Definition von Modellierungssprachen mit den entsprechenden Konstrukten [DuAH05]. Die im Rahmen der Modellierung erstellten Prozessmodelle dienen der Designphase letztendlich als Instrument bzw. Hilfsmittel, um die Anforderungen und ihre Umsetzungskonzepte festzuhalten und diese dann weiterzuverarbeiten [DaSh90]. Dies bedeutet, dass die Anforderungen zunächst in einer Modellierungssprache soweit wie möglich abgebildet werden und im weiteren Verlauf durch die Modellierung (oder dann durch die Ausführung) umgesetzt werden. Abbildung 1-1 Modelle aus der Produktentwicklung [BuAn89] Auch in der Domäne der Ingenieurwissenschaften haben das Design und die Erstellung von Modellen einen hohen Stellenwert [Dym94] [PaBe97]. Der Vorgang der Modellierung wird als „The Language of the Designer“ [Andr94] bzw. des Produktentwicklers angesehen - als Mittel zur Kommunikation und Dokumentation der Anforderungen und Analyseergebnisse. Wie bei [DaSh90] wird das Modell als Instrument der Designphase betrachtet; die in der Designphase erzielten Ergebnisse werden als Input für die Modellerstellung verwendet. Wie MOTIVATION 1.1 3 unterschiedlich die Modelle je nach Einsatzzweck bereits innerhalb einer Domäne ausfallen können, zeigt Abbildung 1-1. In allen Feldern der Abbildung 1-1 wird prinzipiell dasselbe Objekt modelliert, jedoch mit unterschiedlichem Abstraktionsbzw. Detaillierungsgrad (= Eigenschaften des Modells). Die Eigenschaften stehen in engen Zusammenhang mit dem Zweck (der Verwendung) des Modells: so liefert n in Abbildung 1-1 Informationen über das „Innenleben“ des Objektes; o stellt dar, wie das Objekt zusammenzubauen ist, bei p handelt es sich um ein physisch fassbares Objekt. Oftmals ergeben sich bei mehreren Anforderungen Widersprüche, die es aufzulösen gilt. So soll die Reibung des Wälzkörpers gering sein, zugleich soll jedoch ein bestimmter Festigkeitswert des Materials erfüllt werden. So unterschiedlich die inhaltlichen Eigenschaften und Zwecke sind, so unterschiedlich sind auch die Arbeitsmittel, das heißt der Input, zur Modellerstellung: Für die Modellierung von n sind im einfachsten Fall Bleistift und Papier notwendig, die für die Zeichnungserstellung notwendigen Normen und die geometrischen Angaben des Objekts. Bei p muss ein entsprechender Werkstoff (zum Beispiel Stahl), das Herstellungswerkzeug (zum Beispiel ein Schleifgerät) inklusive einer geeigneten Verfahrensweise bzw. Methodik (zum Beispiel Nassschleifen mit Kühlmittelzugabe) vorhanden sein. Im Hinblick auf die Erstellung von Prozessmodellen muss gemäß den Charakteristiken der vorliegenden Prozesse eine Modellierungssprache mit den entsprechenden Modellierungselementen (zum Beispiel Prozesse, Daten, Rollen) spezifiziert werden. Abbildung 1-2 Teilphasen des Designs Die genannten Anwendungsfälle können folgendermaßen verallgemeinert werden: im Rahmen des Designs kann zwischen der Analyseund der Gestaltungsphase unterschieden werden (siehe Abbildung 1-2). Es müssen zunächst in der Anforderungsanalyse die Eigenschaften des zu modellierenden Objektes und dessen weiteren Verwendung im Rahmen des dazugehörigen Lebenszyklus definiert werden. Die Anforderungen gilt es nachfolgend in der Gestaltungsphase auf folgende Aspekte abzubilden: Input bzgl. Informationen/Material, Werkzeug sowie die dazugehörige Verfahrensweise bzw. Methodik. Diese Ergebnisse fließen dann als Input in die Modellierung ein. Mit einer derart strukturierten Designphase wird die Grundlage für eine anforderungsgerechte Modellierung gelegt. So kann nach eingehender Anforderungsanalyse die entsprechende 1.1 MOTIVATION 4 Vorgabe eines Schleifverfahrens im Rahmen der Gestaltungsphase des Designs (Abbildung 1-2) bei p verhindern, dass das als Wälzkörper in einem Lager verwendet Objekt nach der Herstellung zu übermäßigen Verschleiß führt. Dieser tritt auf bei zu hoher Reibung aufgrund nicht ausreichenden Feinschliffs des Bauteils; das Lager erhitzt sich und schlimmstenfalls erleidet die gesamte Maschine einen Schaden, was diverse weitere negative Folgen (zum Beispiel wirtschaftliche Folgen durch Produktionsausfall) mit sich bringt. Werden die Anforderungen erst später ermittelt, zum Beispiel wenn der Herstellungsprozess des zu schleifenden Bauteils bereits begonnen hat, können sie meist nur noch mit hohen Kosten und viel Aufwand eingebracht werden [RIRG09] [Rose06a]. Die einzelnen Aspekte, ihre Beziehungen und Wechselwirkungen zu einander, sind dann aber bereits festgelegt und können nur schwer bzw. nur mit weitreichenden Folgen geändert werden. So kann die geometrische Form nach dem Schleifvorgang lediglich verkleinert, nicht jedoch vergrößert werden; Schnittkanten müssen gegebenenfalls nachbearbeitet werden. Das Design mit seiner Analyseund Gestaltungsphase stellt ein sehr umfassendes und für die nachfolgenden Phasen einflussreiches Aufgabengebiet dar. Es ist daher nachvollziehbar, dass das Design in keiner Weise vernachlässigt werden darf, wenn qualitativ hochwertige Modellierungsergebnisse erzielt werden sollen, was sich wiederum positiv auf die Qualität ihrer Verwendung auswirkt. Die Beispiele aus der Produktentwicklung, speziell das der Fertigung, stehen für den erfolgreichen Einsatz des Designs. 1.1.2 Prozessdesign Beim Prozessdesign im Rahmen des Prozessmanagements steht die Gestaltung von Input, Werkzeugen und Methodik für die Erstellung anforderungsgerechter Prozessmodelle im Vordergrund. Dazu müssen in der Anforderungsanalyse alle wesentlichen Eigenschaften eines Prozessmodells unter Berücksichtigung des jeweiligen Kontextes identifiziert werden. Ein Prozessmodell für ein Produktionsunternehmen muss zum Beispiel die Kennzahl Rüstzeit, die eine unproduktive Zeit darstellt, bei den für das Einrichten der Produktionsmaschinen notwendigen Schritte abbilden; die damit bei der Ausführung der Schritte erfassten Zeiten werden zum Ableiten von Qualitätsmanagementmaßnahmen verwendet [ScSe08]. Im medizinischen Bereich gilt es zur Unterstützung des medizinischen Personals komplexe Entscheidungssituationen während einer Behandlung mit allen Entscheidungskriterien und Entscheidungsfolgen verständlich abzubilden und gegebenenfalls informationstechnisch durch ein Entscheidungsunterstützungssystem zu unterstützen [Meil05]. An den Beispielen ist zu erkennen, dass auch der Einsatzzweck von Prozessmodellen identifiziert werden muss. Angefangen von der reinen Dokumentation in unterschiedlichen Detaillierungsgraden kann sich dieser bis hin zur automatisierten Ausführung der Prozessmodelle erstrecken. Im Anschluss an die Anforderungsanalyse müssen im Bezug auf die Gestaltungsaspekte Input, Werkzeug und Methodik konkret die zu modellierenden Inhalte (zum Beispiel Prozessschritte mit der Angabe von Inund Output-Daten), eine adäquate MOTIVATION 1.1 5 Modellierungssprache sowie das Werkzeug (zum Beispiel BPMN mit Aris Express [Soft11]) definiert werden. Doch obwohl es inzwischen eine Vielzahl von Modellierungssprachen und Werkzeugen gibt [Sinu04], haben die Erfahrungen aus den Projekten des Lehrstuhls für Angewandte Informatik IV an der Universität Bayreuth in unterschiedlichen Anwendungsbereichen (u.a. Medizin [FMSJ09], Verwaltung bzw. Universität [UnBa11], Produktentwicklung [MePa08]) gezeigt, dass gerade die Definition der Modellierungssprache (und damit auch des Modellierungswerkzeuges) oftmals aus Zeitund Kostengründen oder aus Bequemlichkeit vernachlässigt wird. So wurden in den Projekten stets dieselbe Modellierungssprache (und auch dasselbe Werkzeug) verwendet. Während für die Produktentwicklung und die Medizin zwar geringfügig spezielle Anpassungen der Modellierungssprachen vorgenommen wurden, war dies bei dem verwaltungstechnischen Projekt an der Universität nicht der Fall. Eine zusätzlich vom Lehrstuhl für Angewandte Informatik IV durchgeführt Interviewreihe an ausgewählten deutschen Unternehmen [Meer09] ergab, dass es bzgl. der Wahl einer Modellierungssprache und Werkzeug meist an einer kritischen Gegenüberstellung mit den auf dem Markt vorhandenen Produkten fehlt [MaSc97]. Die Entscheidung fällt allzu häufig auf die Auswahl einer Standardmodellierungssprache, wie zum Beispiel UML [OMG11e] oder BPMN [OMG11a], oder bereits vorhandenen anwendungsbezogene Modellierungssprachen. Diese sollen keinesfalls als ungenügend verurteilt werden. Doch kann davon ausgegangen werden, dass sie nicht alle Aspekte eines individuellen Prozesses anforderungerecht abbilden können [BICS07] [Rose06a]. Dies wirkt sich auch auf die nachfolgenden Phasen der Modellierung aber auch der Ausführung sowie des Monitorings und Controllings aus [RIRG09] [Rose06a], wie an dem Beispiel der Rüstzeit zu sehen ist. Wird dieses Prozessmodell zudem nicht in einer maschinenlesbaren Form erstellt, können die Angaben auch nicht als Grundlage zur Steuerung der Produktionsmaschine verwendet werden. Dieses Beispiel zeigt, dass die Individualität einer Anforderung die Entwicklung einer anwendungsbezogenen Prozessmodellierungssprache erfordert. Diese Vorgehensweise wird in Abbildung 1-2 veranschaulicht. 1.1.3 Konfigurierbare Prozessmodelle Ein in den letzten Jahren viel diskutierte Design-Aspekte sind Varianten bzw. konfigurierbare Prozessmodelle [RovA07]. Der Modellierer steht nicht selten vor dem Problem, dass es zu einund demselben Prozess verschiedene, aber dennoch ähnliche Ausprägungen, sog. Varianten [HaBR08a], gibt. Auch in den am Lehrstuhl für Angewandte Informatik IV erstellten Prozessmodellen (mehr dazu in Kapitel 2.2 bzw. 4.1) konnten zahlreiche Varianten identifiziert werden. Um den verschiedensten Anforderungen des Wettbewerbsumfeldes und der Stakeholder je nach Branche, Organisation/Abteilung oder Projekt, etc. gerecht zu werden ist oftmals eine Vielzahl von ähnlichen, jedoch im Bezug auf einzelne Aspekte unterschiedlichen Prozessen zu definieren. So unterscheiden sich zum Beispiel die 1.1 MOTIVATION 6 Aufnahmeprozesse in einer Klinik, je nachdem ob der Untersuchungsplan von einer Krankenschwester oder aber von einem Arzt erstellt wurde. Da Varianten in vielen verschiedenen Anwendungsbereichen zu finden sind, macht es Sinn diesen Design-Aspekt anwendungsbereichsübergreifend zu betrachten, anstatt diese jeweils einzeln zu behandeln. Eine verbreitete Methode zum Management von Varianten und eine typische Design-Aktivität ist die Konfiguration [BAKF04] [HaBR08c] [LaRo08a] [Riit01] [TrGC95]. Dabei geht es um die Gestaltung von Artefakten basierend auf einer Menge vorab definierte Elemente [MiFr89]. Im Prozessmanagement sind die Artefakte die Prozessmodelle bzw. Varianten und die Elemente die diversen Prozesselemente wie Daten, Prozessschritte oder Werkzeuge. Die wesentliche Grundlage bilden konfigurierbare (Prozess-) Modelle [BDDK04] [TiSo97] [SaWe97], die mehrere Varianten in einem Modell integrieren. Die Unterscheidungspunkte der Varianten werden konzeptionell explizit als variation points (dt. Variationspunkte) erfasst, die als ein Kernpunkt konfigurierbarer Modelle angesehen werden. Abbildung 1-3 zeigt zwei Varianten des Aufnahmeprozesses (Ausschnitt) einer Klinik. Auf der linken Seite sind sie getrennt modelliert; auf der rechten Seite ist ein integriertes Prozessmodell zu sehen. Die variablen Stellen sind durch die gestrichelte Umrandung hervorgehoben. Abbildung 1-3 Varianten und ein integriertes Prozessmodell Während dies nur ein vereinfachtes Beispiel aus einem Prozessmodell eines Lehrstuhlprojektes mit einem einzigen variation point ist, enthalten Prozesse üblicherweise mehrere variation points. Außerdem ist zu beachten, dass diese unterschiedliche Aspekte der Prozesse betreffen können. So wie in dem gerade genannten Beispiel der organisatorische Aspekt variiert, können ebenso der funktionale Aspekt oder die Daten eines Prozesses variieren. Dies ist ein essentieller Punkt bei der Definition von Varianten, da nur unter Berücksichtigung aller relevanten Aspekte eine umfassende Beschreibung der Prozesse PROBLEMSTELLUNGEN UND ZIELSETZUNGEN 1.2 7 möglich ist [CuKO92] [JaBu96]. Darüber hinaus existieren Abhängigkeiten zwischen den Auswahlmöglichkeiten verschiedener variation points. So kann die Rollenwahl in dem obigen Beispiel im weiteren Prozessverlauf die Ausführung eines zusätzlichen Prüfschrittes beeinflussen (hier nicht abgebildet). Die Anzahl der Kombinationsmöglichkeiten wird durch die Definition von Abhängigkeiten eingeschränkt und auf eine sinnvolle bzw. erlaubte Menge begrenzt. Nach diesen Anforderungen gestaltete Prozessmodelle ermöglichen es eine große Menge an Informationen in ein und demselben Prozessmodell abzubilden und bieten eine integrierte Sichtweise auf den Sachverhalt. Doch sind die genannten Punkte nicht immer bzw. nicht vollständig in den existierenden (konfigurierbaren) Modellierungssprachen gegeben. Werden die variation points eines konfigurierbaren (Prozess-) Modells entschieden, wird daraus ein Teilprozessmodell, eine Variante, abgeleitet. Dazu werden die nicht mehr relevanten Varianten aus dem Prozessmodell gelöscht. Die resultierenden Prozesse werden zur Ausführung oder auch zu anderen Einsatzzwecken wie der Analyse, verwendet. Bei umfangreichen Prozessmodellen ist zumeist eine hohe Anzahl an variation points unter Berücksichtigung der Abhängigkeiten aufzulösen, was die Gefahr birgt, dass der für die Gesamtentscheidung verantwortliche Stakeholder schnell den Überblick verliert kann. Dies gilt umso mehr, wenn alle variation points noch vor Beginn der eigentlichen Ausführung aufgelöst werden sollen. Möglicherweise fehlen an dieser Stelle noch entscheidungsrelevante Informationen, die erst mit der Ausführung bekannt werden. Es können essentielle Eigenschaften bzgl. der Variante gefordert sein; es muss garantiert werden, dass diese zum Beispiel nicht durch die vorherige Entscheidung anderer variation points nicht mehr Bestandteil des finalen Prozessmodells sind. Die genannten Punkte zeigen, dass nicht nur die Abbildung der Varianten in einem integrierten Prozessmodell, sondern auch deren Konfiguration eine Herausforderung darstellen. Es ist zu klären, was genau Gegenstand der Konfiguration sein soll, um ein entsprechendes Modellierungskonzept entwickeln zu können. Darüber hinaus gilt es, nicht nur die Korrektheit der entstehenden Modelle zu garantieren, sondern dem Anwender auch eine methodische Unterstützung bei dem Entscheidungsbzw. Konfigurationsprozess an die Hand zu geben. Die Problematik der konfigurierbaren Prozessmodelle ist insgesamt als ein anwendungsfallübergreifendes Beispiel für das (Prozess-) Designs zu sehen. Es kann ideal dafür verwendet werden, die Notwendigkeit einer expliziten Anforderungsanalyse und der daraus sich gegebenenfalls ergebenden Anpassung oder Neudefinition einer Modellierungssprache und die dazugehörigen Methoden zu veranschaulichen. Die im Rahmen dieser Arbeit entstandene Modellierungssprache ist bereits prototypisch anwendbar. 1.4 AUFBAU DER ARBEIT 14 DER PROZESSBEGRIFF 2.1 15 Kapitel 2 Prozessmanagement – Stand in Forschung und Praxis Wie bereits in Kapitel 1 erläutert, ist die Bedeutung von Prozessen für die Steuerung und Optimierung von Abläufen in der Organisation in den letzten Jahren zunehmend erkannt worden [Dave93] [HaCh93] [Hamm01] [Hamm90] [Hamm97] [SmFi03]. Auch verschiedene Studien konnten zeigen, dass sich die Idee des Prozessmanagements zu einem etablierten Management-Ansatz in Theorie und Praxis entwickelt hat, um ein Unternehmen zu führen und zu organisieren (siehe zum Beispiel [ArMa97], [EHLB95], [GaGr07], [Hung06] oder [WoHa10]). Der Fokus liegt auf dem zielorientierten Management von Zeit, Qualität und Kosten. Dabei gilt es strategische wie operative (Unternehmens-) Ziele zu erreichen und die Effizienz der Abläufe zu erhöhen. Der Ansatz ist somit als ein Fundament der wirtschaftlichen Entwicklung der Organisation und der Wirtschaft als Ganzes anzusehen [Meer07]. Ein Blick in die Literatur zeigt: Es existieren viele verschiedene, zum Teil voneinander abweichende, wenn nicht sogar widersprüchliche Ansätze des Prozessmanagements [vAHW03] [ZaSi95]. Dem gegenüber stehen die Ansätze der Praxis bzw. die in der Praxis umgesetzten theoretischen Ansätze. In diesem Kapitel werden Einblicke in die Theorie und Praxis gegeben sowie Gemeinsamkeiten und Unterschiede aufgezeigt. Ziel ist es, das Problemfeld der Designphase zu konkretisieren, welches im weiteren Verlauf der Arbeit behandelt wird. Für ein besseres Verständnis wird zunächst eine Einführung in den Prozessbegriff gegeben und exemplarisch in ausgewählte Anwendungsbereiche eingeführt. Für einen umfassenden Überblick werden Aspekte des Prozessmanagementansatzes erläutert. 2.1 Der Prozessbegriff Der Begriff „Prozess“ leitet sich ursprünglich von dem lateinischen „procedere“ ab, übersetzt „vorgehen“ oder „vorrücken“ [Mitt95]. Die heutige Definition des Begriffs Prozess ist durch die Verwendung in verschiedensten Anwendungsgebieten jedoch sehr viel spezifischer. Auch im Bereich der (Wirtschafts-) Informatik hat sich sich in den letzten Jahrzehnten eine Reihe von Definitionen entwickelt, die je nach Verwendung variieren. Im Folgenden werden Definitionen kurz vorgestellt und diskutiert. Gaitanides [Gait83] liefert folgende, fundamentale Definition: Prozesse sind inhaltlich abgeschlossene Erfüllungsvorgänge, die in einem logischen inneren Zusammenhang stehen. 2.1 DER PROZESSBEGRIFF 16 Gaitanides geht auf zwei Hauptcharakteristika von Prozessen sein: Mit der Durchführung eines Prozesse ist das Erreichen eines Ziels verbunden, was mit „abgeschlossene Erfüllungsvorgänge“ allgemein beschrieben wird. Die Vorgänge stehen dabei in einer sinnhaften Beziehung, das heißt „logischem … Zusammenhang“, zueinander. Konkretere Angaben sind in der Definition von Davenport zu finden [Dave93]: Die Beziehung bzw. der Zusammenhang der Vorgänge (hier „activities“) wird hier näher beschrieben; nach dieser Definition erfolgt eine Strukturierung der einzelnen Aktivitäten (lateinisch „structura“ = ordentliches Zusammenfügen“) und zwar im Bezug auf Raum und Zeit. Die Eckpfeiler der zu definierenden Struktur, des nach Gaitanides „abgeschlossenen Erfüllungsvorgangs“, sind die klar zu definierenden Inputs und Outputs. Mit „Kunde“ und „Markt“ wird auch explizit der Empfänger des Outputs genannt. Dies zeigt, dass Prozesse nicht isoliert von ihrer Umwelt zu betrachten sind. Eine weitere Definition, die die Aktivitäten noch näher charakterisiert, liefern Schwarzer und Krcmar [ScKr95]: Hier wird zum einen der Begriff der Transformation eingeführt. Dies bedeutet, dass mit der Durchführung der Aktivitäten gemäß einer festgelegten Struktur eine Veränderung des Objektes in Raum und Zeit erfolgt. Mensch und Maschine werden explizit als konstituierende Elemente eines Prozesses genannt. Wie bei der Definition von Davenport werden die Prozesse und ihre Aktivitäten nicht isoliert von ihrem Umfeld betrachtet werden können, sondern es werden Werkzeuge eingesetzt und Verantwortliche zugewiesen. Übereinstimmend mit den vorgehenden Definitionen gilt es einen Output, die „vorgegebene Leistung“, zu erzeugen. Schwarzer und Krcmar erwähnen in ihrer Definition außerdem explizit vorund/ oder nebengelagerte Aktivitäten. Sie geben damit einen Hinweis auf die gängige Unterteilung von Prozessen in verschiedene Prozessklassen. Grundlegend wird dabei zwischen primären, wertschöpfenden Prozessen und sekundären, unterstützenden Prozessen unterschieden [ScSe08]. Die Definition von Schwarzer und Krcmar ist bereits sehr umfassend, doch kann sie noch weiter präzisiert werden. Die Prozessklassen sowie der Begriff der Transformation führen zu Prozesse können definiert werden als die Transformation von Objekten durch vorund/oder nebengelagerte Aktivitäten eines oder mehrerer Menschen oder Maschinen in Raum und Zeit. Das Ziel ist dabei immer die Erreichung einer vorgegebenen Leistung. A process is simply a structured, measured set of activities designed to produce a specified output for a particular customer or market. […]. A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action. ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 2.2 17 dem Begriff der Geschäftsprozesse [Gada05] [HaCh93] [JMPW93] [RuBr95] [ScSe08] [ScZi96]. Diese stellen aus der betriebswirtschaftlichen Perspektive eine Untermenge der Prozesse im Allgemeinen dar. Als Beispiele sind Produktentwicklungsoder Entstehungsprozesse [Ehrl07] sowie medizinische Prozesse [Hell02], wie sie in Krankenhäusern bei der Behandlung von Patienten zu finden sind, zu nennen. Überschreitet bei einem Transformationsprozess der Output den Input wertmäßig, wird dies als Wertschöpfung bezeichnet. Im Produktionsprozess stellt das gefertigte Produkt die Wertschöpfung dar; im Kontext der medizinischen Prozesse ist unter Wertschöpfung die Verbesserung des Gesundheitszustandes des Patienten zu verstehen. Eine entsprechende Prozessdefinition ist bei Hammer und Champy [HaCh93] zu finden: Als zusätzlicher Fokus im Vergleich zu den vorherigen Definitionen ist hier die Kundenorientierung zu nennen. Damit werden jedoch unterstützende Prozesse, die keinen direkt sichtbaren Nutzen für den Kunden haben, wie es zum Beispiel bei verwaltungstechnischen Prozessen der Fall ist, vernachlässigt. In Anlehnung an [Stei99] sollen die Geschäftsprozesse und unterstützenden Prozesse daher unter dem Begriff Anwendungsprozesse zusammengefasst werden. Für die vorliegende Arbeit soll der Begriff des Anwendungsprozesses folgendermaßen definiert werden: 2.2 Anwendungsbereiche des Prozessbegriffs Wie bereits in Kapitel 2.1 bei der Definition des Prozessbegriffs erwähnt, kommen Anwendungsprozesse in den unterschiedlichsten Bereichen vor (Produktentwicklung, Medizin, Verwaltung, …). Trotz der Unterschiede sind die gleichen Methoden und Konzepte anwendbar. In diesem Abschnitt sollen exemplarisch Anwendungsbereiche vorgestellt werden, um einen tieferen Einblick in dieses Themengebiet zu bekommen. Die Auswahl der Anwendungsgebiete leitet sich ab aus Projekten des Lehrstuhls für Angewandte Informatik IV. Ein Anwendungsprozess umfasst beliebige Aktivitäten, die in einem logischen und zeitlichen Zusammenhang stehen. Dabei ist es das Ziel aus ein oder mehreren Inputs, über verschiedene Zwischenergebnisse, einen Output zu erzeugen bzw. eine Aufgabe zu erfüllen. Die Aktivitäten werden von ein oder mehr Rollen unter Verwendung von entsprechenden Werkzeugen bzw. Hilfsmitteln ausgeführt. [Geschäftsprozesse sind eine] Menge von Aktivitäten, für die eine oder mehrere unterschiedliche Inputs benötigt werden und die für den Kunden ein Ergebnis mit Wert erzeugen. 2.2 ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 18 Folgende Bereiche werden behandelt: • Produktentwicklungsprozesse Im Rahmen des von der Bayerischen Forschungsstiftung geförderten Forschungsverbunds „FORFLOW“ ( [MePa06], [MePa08]) galt es einen sogenannten Prozessnavigator zur Prozessund Workflowunterstützung von Produktentwicklungsprozessen zu erforschen, zu entwickeln und prototypisch umzusetzen. Als Grundlage galt es ein Prozessmodell zu erstellen, das alle für die Produktentwickler notwendigen Informationen abbildet. • Medizinischer Prozesse Ziel dieses Projektes war die Einführung sog. Klinischer Behandlungspfade für die medizinische Behandlung von Patienten am Klinikum in Fürth. Dabei erfolgte eine Ist-Analyse der im Klinikum vorhandenen medizinischen Prozesse und deren Dokumentation (siehe auch [FMSJ09]). • Verwaltungstechnische Prozesse an der Universität Im Hinblick auf die von der Universitätsleitung der Universität Bayreuth angestrebten System-Akkreditierung galt es die Prozesse im Bereich Studium und Lehre zu Dokumentationszwecken zu erfassen (siehe [UnBa11]). Es folgt eine kurze Definition und Beschreibung der Anwendungsbereiche. Dabei wird auch auf die Eigenschaften der Prozesse im Hinblick auf Modellierung (und Ausführung) eingegangen. 2.2.1 Produktentwicklungsprozess Der Produktentwicklungsprozess beginnt mit der ersten Idee zu einem Produkt und den davon abgeleiteten, in einem sogenannten Pflichtenheft festgehaltenen Anforderungen. Der Prozess endet mit der Einführung des Produktes auf dem Markt [Ehrl07] [PaBe97] [ScSe08]. Üblicherweise wird der Prozess in die Phasen des • Planens • Konzipierens • Entwerfens und • Ausarbeitens unterteilt [PaBe97] [VDI82] [VDI97]. Die Durchführung dieser Phasen erfolgt gemäß verbindlicher Vorgehensweisen und Vorgehensplänen [PaBe97]. Sie beschreiben die einzelnen Teilaktivtäten sowie deren Inund Output, wie es zum Beispiel in den VDIRichtlinien 2221 [VDI93] sowie 2222 [VDI82] [VDI97] zu lesen ist. Sie sind als Richtschnur oder Vorgehenshilfe, gemäß Müller [Müll90] als Prozessmodelle zu verstehen, nicht jedoch als Vorschrift (Beispiel siehe Abbildung 2-1). Sie dienen vor allem dazu das Vorgehen rational zu beschreiben und die Vorgänge transparent zu machen. ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 2.2 19 Dokumente sind vor allem im Hinblick auf die Zwischenziele (Meilensteine) relevant sowie bzgl. der Endergebnisse zur Dokumentation der Vorgänge. Zu Beginn muss das sogenannte Pflichtenheft spezifiziert werden, das die Anforderungen festhält. Deren Umsetzung erfolgt unter Berücksichtigung diverser Vorschriften und Richtlinien, über die informiert werden muss. Darüber hinaus gilt es Werkzeuge zu definieren (zum Beispiel 3D-CAD-Werkzeuge zur Erstellung von Konstruktionszeichnungen bzw. Datensätzen), die den Produktentwickler bei seiner Arbeit unterstützen und gleichzeitig Informationsbasis für die spätere Entwicklung sind. Der Produktentwicklungsprozess ist durch viele iterative (Teil-) Prozesse charakterisiert, das heißt es handelt sich nicht um eine starr sequentielle Vorgehensweise. Angestoßen werden sie oftmals durch viele individuelle Denkprozesse. Durch methodisches Vorgehen sollen die Iterationsschleifen in Zahl und Umfang möglichst klein bleiben. Die Annäherung an die Lösung erfolgt schrittweise [Ehrl07] [PaBe97]. Die Aktivitäten können nicht immer in der Reihenfolge ausgeführt werden, wie es im Prozessmodell beschrieben ist. Hierbei spielen die kreativen Prozesse eine entscheidende Rolle, da der Zeitpunkt einer Ideenfindung nicht festgelegt werden kann. Auch neue Lösungswege sind noch nicht im Prozessmodell abgebildet, sollten aber während der Ausführung in den Gesamtprozess integriert werden können. Der Produktentwicklungsprozess ist außerdem geprägt von einer Vielzahl parallel ablaufender Abschnitte, die in gegenseitiger Wechselwirkung zueinander stehen und somit koordiniert werden müssen. Das Ende einer größeren Etappe wird üblicherweise durch einen Meilenstein gekennzeichnet, an dem es definierte Zwischenziele des jeweiligen Entwicklungsprojektes zu erreichen gilt. Bei der Umsetzung der Vorgehenspläne in realen Abläufen erfolgt eine Vermischung der Vorgaben aus den Prozessmodellen mit dem individuellen Denkprozess der ausführenden Personen [PaBe97]. Die Denkprozesse besitzen einen sehr hohen Innovationscharakter. Der Anteil sogenannter kreativer Prozesse in den Produktentwicklungsprozessen ist sehr hoch [Remu02]. Sie können im Voraus jedoch nicht geplant bzw. in Prozessmodellen festgehalten werden. Die Bereitstellung der Informationen kann gut durch IT-Systeme unterstützt werden, was sich auf die Datenverfügbarkeit und den Informationsstand der Prozessbeteiligten positiv auswirkt. Eine automatische Dokumentation der Ergebnisse ist damit eng verbunden. Fazit In der Produktentwicklung wird die Idee der Prozesse als grundlegendes Konzept zur Strukturierung von Entwicklungsvorhaben verwendet. Die dokumentierten Vorgehensweisen dienen zur Unterstützung der konkreten Ausführung, um zielorientiert zu einem qualitativ guten Entwicklungsergebnis zu kommen. Meilensteine entlang des Prozessverlaufs definieren (Zwischen-) Ergebnisse bzw. Ziele und dienen bei der Durchführung des Produktentwicklungsprozesses die Qualität und den Erfolg sicher zu stellen. Bei der 2.2 ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 20 Ausführung müssen zusätzliche Vorkommnisse und die aktuell vorliegenden Bedingungen, die nicht im Modell festgehalten werden können, berücksichtigt werden, so dass eine flexible Anpassung der Abläufe möglich sein muss. Abbildung 2-1 Beispiel – Produktentwicklungsprozess aus [Meer07b]1 2.2.2 Medizinischer Prozess Die Adaption des Prozessgedankens im Bereich der Medizin wird in der Literatur als Klinischer Pfad bezeichnet [Hell02]. Die Begriffe Clinical Pathway, Geplanter Behandlungsablauf (GBA) und Patientenpfad können dabei synonym verwendet werden. Nach [Hell02] und [Opit04] wird der Klinische Pfad wie folgt definiert: Ein klinischer Pfad ist ein einzigartiger, berufsgruppenübergreifender Behandlungsablauf auf Evidenz-basierter Grundlage (Leitlinie), der Patientenerwartung, Qualität und Wirtschaftlichkeit gleichermaßen berücksichtigt“ Klinische Pfade stellen eine standardisierte Beschreibung dessen dar, was in einer Klinik üblich ist. Sie werden in der Regel an die lokalen Verhältnisse eines Klinikums angepasst [Hell02], so dass sie die vorhandenen Ressourcen optimal nutzen können. Es herrscht nicht unbegründet die Angst vor einer sognannten „Koch-Buch-Medizin“, die dem medizinischen Personal die Handlungsfreiheit nimmt [Hell02] [Opit04]. Im eigentlichen Wortsinn sowie unter betriebswirtschaftlichem Gesichtspunkt wird Standardisierung unter anderem als eine Vereinheitlichung von Verfahrensweisen und Abläufen [Broc93] [Gabl10] verstanden. Prinzipiell sollte jedoch der Patient als Individuum mit seiner Krankheit im Vordergrund stehen. Davon unabhängig ist die Etablierung Klinischer Pfade nicht für alle klinischen 1 Die Erstellung der Beispiele in den folgenden drei Unterkapiteln erfolgte mit der Modellierungssprache AOPM und dem Modellierungswerkzeug i>pm (siehe Kapitel 3.3.1.4). ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 2.2 21 Abläufe sinnvoll, da der Aufwand den zu erwartenden Nutzen deutlich übersteigen würde [HSMR02]. Die Klinischen Pfade stellen eine prinzipielle Vorgehensweise bzw. Leitlinien auf Basis Evidenz-basierter Grundlagen dar. Die Abläufe sind in der Realität jedoch sehr viel variabler und von vielen unvorhergesehene Ereignissen oder nicht vorher bedachten Konstellationen bzgl. des Gesundheitszustandes eines Patienten oder der Verfügbarkeit von Ressourcen geprägt. Dies stellt eine entscheidende Herausforderung für die Handhabung dieser Prozesse dar. Teils enthalten die Abläufe eine Vielzahl von Einzelschritten bei denen die Reihenfolge nicht entscheidend ist, die aber auch nicht parallel ausgeführt werden müssen bzw. können. Ein Beispiel dafür wäre der Bereich der Pflege. Oft muss sie innerhalb eines bestimmten Zeitfensters durchgeführt werden (zum Beispiel nach der Einweisung, vor bzw. nach einer Operation). Diese Schritte lassen sich somit mit einer Checkliste vergleichen, deren Anwendung das Ziel einer Vollständigkeitskontrolle (hier die Durchführung der Schritte) verfolgt (siehe dazu zum Beispiel [Meil05]). Zumeist sind an medizinischen Prozessen sowohl verschiedene Organisationseinheiten (medizinisches Personal, Patienten, Verwaltung, etc.) als auch unterschiedliche Geräte und Systeme (Röntgengerät, CT, KIS, etc.) beteiligt [DaRK00] [LBHH05], was die Komplexität der Prozesse wesentlich erhöht. Abbildung 2-2 Beispiel – Medizinischer Prozess [eigene Quellen] 2.2 ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 22 Die Bereitstellung der Informationen kann gut automatisiert und durch IT-Systeme unterstützt werden, was sich auf die Datenverfügbarkeit und den Informationsstand der Prozessbeteiligten positiv auswirkt. Eine automatische Dokumentation der Ergebnisse ist damit eng verbunden. Zum Teil lässt sich dies direkt mit der Durchführung von Teilschritten koppeln, wenn dort technische Systeme, beispielsweise ein EKG, verwendet werden. Viele funktionale Schritte könne aber nur manuell ausgeführt werden, wie zum Beispiel “Anamnese durchführen“, was mit nicht zu vermeidenden Medienbrüchen verbunden ist. Fazit Auch in der Medizin wird die Idee der Prozesse als strukturierendes bzw. steuerndes Konzept verwendet. Die Steuerung erfolgt vor allem durch Verwendung von Klinischen Pfaden, welche medizinische Leitlinien abbilden. Die Klinischen Pfade dienen als Grundlage für die Durchführung der medizinischen Prozesse. Da deren Definitionen ein hohes Maß an Allgemeingültigkeit besitzen, muss bei deren Verwendung eine Anpassung gemäß dem individuellen Anwendungsfall erfolgen, wie es auch bei der Produktentwicklung der Fall ist. 2.2.3 Verwaltungstechnischer Prozess an der Universität Innerhalb des deutschen Hochschulsystems wird immer häufiger von dem "Unternehmen Universität" [Sieb08] [GrvH00] oder Universität als "Wissenschaftsunternehmung" [GrvH00] gesprochen. Vorbilder dieses Paradigmenwechsels sind vor allem die amerikanischen Universitäten [GrvH00]. Auch diese müssen ihr Ziel der „Wissenschaftlichkeit“ wirtschaftlich und effizient erreichen, um im Wettbewerb zwischen den verschiedenen Universitäten bestehen zu können. Als Produkte der Universität sind Erkenntnisse und Wissen aus der Forschung sowie die Absolventen verschiedener Fachrichtungen aus der Lehre zu nennen. Prozesse, die in dieser Art von Unternehmen ablaufen, werden üblicherweise (vgl. dazu zum Beispiel [Sinz97], [TeUI09] oder [Fähn09]) unterteilt in: • Kernprozesse Studium und Lehre • Kernprozesse Forschung sowie • Verwaltungsbzw. Dienstleistungsprozesse Die Aktivitäten des Kernprozesses Studium und Lehre sind auf die universitäre Ausbildung der Studenten gerichtet. Mit den Schwerpunkten Bewerbung und Zulassung, Prüfungsverwaltung, Studierendenverwaltung und Veranstaltungsmanagement wird dies zusammengefasst unter dem Begriff „Student-Life-Cycle“. Dabei ist eine starke Interaktion zwischen den Studenten und den universitären Organisationseinheiten zu beobachten. Während sich dies auf die Durchführung eines Studiengangs bezieht, sind außerdem die TeilKernprozesse für die Einrichtung sowie Aufhebung eines Studiengangs zu nennen. Diese sind von gesetzlichen Vorschriften, zum Beispiel dem Bayerischen Hochschulgesetz (BayHSchG) oder den Vorgaben der Kultusministerkonferenz, geprägt und stark dokumentenlastig. ANWENDUNGSBEREICHE DES PROZESSBEGRIFFS 2.2 23 Im Kernprozess Forschung sollen Forschungsergebnisse erarbeitet werden, die dann der Öffentlichkeit und Wirtschaft, aber auch den Studenten zugänglich gemacht werden sollen. Die Verwaltungsund Dienstleistungsprozesse sind auf die Kernprozesse ausgerichtet und komplett darin integriert. Beispielhaft zu nennen wären die Personalverwaltung, die Gebäudeund Anlagenverwaltung oder das Bibliothekswesen. Sie sollen so gestaltet werden, dass die Durchführung der Hauptprozesse möglichst effizient unterstützt wird. Zur Selbstdokumentation und/oder im Hinblick auf die seit dem Beginn des BolognaProzesse [BuBF11] durchzuführenden Akkreditierungsmaßnahmen zur Überprüfung des internen Qualitätssicherungssystems einer Hochschule im Bereich Studium und Lehre, werden diese Prozesse in Form von Prozesshandbüchern beschrieben. Obwohl viele verwaltungstechnische Prozesse zu finden sind, die nach vorherrschender Meinung meist als sehr starr und nach festen Ablaufschema durchgeführt werden, spielt aus der Erfahrung des Projektes heraus auch hier die Flexibilität der Ausführung eine große Rolle. Dennoch gibt es viele Abläufe, die dem klassischen Workflow-Konzept [Jabl95] [JaBu96] entsprechen, das heißt automatisiert ausgeführt werden können. Eine Herausforderung ist es Schnittstellen zwischen diesen beiden Arten von Prozessen (flexibel und starr) zu realisieren, wenn sie gemäß der Definition im Prozessmodell direkt aufeinanderfolgen. Die Prozesse erfordern ansonsten generell eine geringe Werkzeugunterstützung, wichtig ist es vor allem die Rollen richtig zu definieren, damit die Verantwortlichkeiten geklärt sind. Eine hohe Dokumentenlastigkeit ist auffällig; es werden für die einzelnen Schritte meist viele Unterlagen benötigt und dann auch viele erstellt. Abbildung 2-3 Beispiel – Universitätsbezogener Prozess [UnBa10] 2.3 PROZESSMANAGEMENT 30 Die Erläuterungen orientieren sich gemäß der noch in Kapitel 2.3.2.2 vorzustellenden Studie an folgenden Aspekten: • strategisches und operatives Prozessmanagement • Modellierung • Ausführung • Informationstechnologien Die genannten Studien folgen nicht explizit diesem Aufbau bzw. haben nicht durchgehend alle aufgelisteten Aspekte erfasst bzw. nicht mit demselben Ausmaß. Daher galt es die Ergebnisse der Studien kritisch zu analysieren, um die relevanten Informationen im Hinblick auf die angestrebte Zusammenfassung extrahieren zu können. Außerdem ist zu berücksichtigen, dass die für die verschiedenen Studien Verantwortlichen jeweils ihre spezifische (subjektive) Sichtweise auf das Thema Prozessmanagement haben, was sich auf die in den Studien gestellten Fragen sowie die Ergebnisanalyse auswirkt. Strategisches und operatives Management (Geschäfts-) Prozessmanagement wird sowohl auf der strategischen als auch auf der operativen Ebene praktiziert. Es gilt die Prozesse zu analysieren und darauf aufbauend zu managen, zu kontrollieren und kontinuierlich zu verbessern. Ziel ist es letztendlich die Qualität der zu erstellenden Produkte bzw. allgemein Leistungen zu verbessern [AnCh07] [LeDa98]. Soweit sind diese Ergebnisse mit der in Kapitel 2.3.1 erläuterten Theorie konform. Demgegenüber haben die Studien jedoch gezeigt, dass es oftmals an der Unterstützung des Managements fehlt, wenn es um die Umsetzung des Prozessmanagements geht [AnCh07] [BICS07] [LeDa98]. Als Ursachen wurden Fehleinschätzungen bzgl. der Bedeutung des Themas Prozessmanagements sowie fehlendes Bewusstsein und Verständnis identifiziert. Gerade auf der strategischen Ebenen ist häufig kein gemeinsames Verständnis bzgl. des Begriffs (Geschäfts-) Prozessmanagement vorhanden [WICS07], während auf taktischer Ebene als Übergang zu operativen Ebenen dieses Thema meist gar nicht angesprochen wird. Somit ist der Übergang von der strategischen zur operativen Ebenen unterbrochen [SIBC07]. Auf operativer Ebene ist ein Mangel bis hin zu Nichtvorhandensein einer entsprechenden Methodik, von Richtlinien oder allgemeingültigen Praktiken zu beobachten [BICS07] [IRRG09] [SIBC07]. Dies geht einher mit fehlender Ausbildung im Hinblick auf den gesamten Managementansatz. Die Umsetzung geschieht vielmehr willkürlich, zufällig [LeDa98]. Aus diesen Erkenntnissen heraus ist es nicht überraschend, dass viele Unternehmen weiterhin funktionsorientiert, statt prozessorientiert, ausgerichtet sind. Es fehlt dabei vor allem an funktionsübergreifender Koordination sowie Kommunikation [LeDa98]. Somit scheint das Prozessmanagement in der Praxis noch einiges an Nachholbedarf zu haben, was auch die folgenden Abschnitte verdeutlichen. PROZESSMANAGEMENT 2.3 31 Modellierung Die derzeit auf dem Markt vorherrschenden Prozessmodellierungssprachen decken ein sehr breites Anwendungsgebiet ab [DGRI06], so zum Beispiel im Rahmen der Gestaltung von Informationssystemen [DuAH05] oder Service-orientierten Architekturen [Erl05] sowie zum Zweck der Dokumentation der Vorgänge in einem Unternehmen [DaSh90]. Im Einzelnen sind die Modellierungssprachen eher allgemeingültig konzipiert, als dass sie auf einen bestimmten Modellierungszweck ausgerichtet sind [BICS07] [DGRI06] [Rose06a] [Rose06b] [SIBC07]. Die am häufigsten verwendeten Techniken sind • ER-Diagramme (= Methode zur Beschreibung von Objekten und ihren Beziehungen zueinander [Chen76]) in kleineren Unternehmen mit weniger als 100 Mitarbeitern sowie in großen mit über 1000 Mitarbeitern [DGRI06] • Flowcharts/ Programmablaufpläne sowie UML-Diagramme in Unternehmen von mittlere Größe [DGRI06] Im Bezug auf die am häufigsten verwendeten Werkzeuge ist an vorderster Stelle • Visio (= weitverbreitete Visualisierungs-Software von Microsoft für Windows [MiCo11]) vor allem in mittelgroßen bis großen Unternehmen zu nennen. Der Nutzen der Modellierung wird vor allem in dem besseren Verständnis der Prozesse durch visuelle Darstellung gesehen [BICS07] [IRRG09]. Die Darstellung der Prozesse in Form der Prozessmodelle wird gerne zur Dokumentation der Abläufe und Organisationsstruktur eines Unternehmens verwendet, aber auch für die Spezifikation von prozessorientierten Systemen im Rahmen der Softwareentwicklung [DaKo05]. Die Vorteile beziehen sich hauptsächlich auf die operative Ebene sowie die organisatorischen und innerbetrieblichen Bereiche des Prozessmanagements und weniger auf den strategischen Bereich [IGRR09]. Trotz des großen Angebots an Modellierungssprachen ist es dennoch oftmals nicht möglich, die Geschäftsprozesse mit den gewünschten Inhalten und/ oder in der entsprechenden Form strukturiert darzustellen [BICS07] [Rose06a] [Rose06b] [SIBC07]. Es herrscht eine Diskrepanz zwischen dem, was dargestellt werden kann, und dem, was dargestellt werden soll. Die Modellierungssprachen scheinen nicht den Anforderungen des Modellierungskontextes zu entsprechen. Dies erklärt, dass oftmals gar keine Dokumentation vorzufinden ist, da keine Abbildung der Sachverhalte möglich ist [LeDa98]. [SIBC07] berichtet, dass die verwendeten Modellierungssprachen bzgl. der Anwendungsfälle zu allgemeingültig definiert sind. (Die in den Studien genannten Modellierungssprachen werden alle von entsprechenden Organisationen definiert.) Dennoch wird vor allem den Standardisierungsvorhaben im Bezug auf Modellierungssprachen eine hohe Bedeutung zugewiesen [IRRG09]. Es wurde nicht explizit danach gefragt, jedoch scheint keine individuelle Entwicklung oder Anpassung von Modellierungssprachen, wie es gemäß dem 2.3 PROZESSMANAGEMENT 32 theoretischen Konzept des Prozesslebenszyklus in Kapitel 2.3.1 in der Designphase möglich ist, vorgenommen zu werden. Daher kann auch keine Aussage darüber gemacht werden, warum diese Möglichkeit nicht genutzt wird, obwohl sich die Anwender bewusst sind, dass die vorhandenen Modellierungssprachen nicht immer adäquat sind. Ausführung Trotz der allgemeinen Anerkennung des (Geschäfts-) Prozessmanagementansatzes lässt sich dieser im Alltag doch manchmal nur schwer „richtig verkaufen“. Dies ist darauf zurückzuführen, dass die Anwender sehr unterschiedliche Vorstellungen von der Realisierung und dem Output des Management-Ansatzes haben [BICS07] [WICS07] bzw. das entsprechende Bewusstsein fehlt [LeDa98] [WICS07]. Zudem scheint nach [BICS07] [WICS07] vor allem eine Lücke zwischen der Designund Ausführungsphase vorhanden zu sein; die in der Design-Phase definierten Anforderungen werden nicht konsequent umgesetzt, was Probleme in der Ausführung zur Folge hat. Der Grund dafür liegt vor allem darin, dass in jeder Phase des Prozesslebenszyklus verschiedene Werkzeuge zum Einsatz kommen, die im Hinblick auf eine durchgehende Umsetzung der Anforderungen entlang des Prozesslebenszyklus nicht aufeinander abgestimmt sind. Zudem stehen nur allgemein definierte Modellierungssprachen zur Auswahl, die den individuellen Sachverhalt einer Organisation bzgl. der späteren Ausführung nicht abbilden können. Um die mit den genannten Punkten verbundenen Schwachstellen bzw. Fehler auszumerzen, müssen entsprechende Maßnahmen eingeleitet werden. [LeDa98] kritisiert, dass aus diesem Grund bei der Ausführung der Prozesse die Durchführung von Verbesserungsmaßnahmen oftmals zu sehr im Vordergrund steht. Die Prozessausführung verläuft also schwerpunktmäßig reaktiv, als dass sie aktiv gestaltet werden kann bzw. wird. Die Probleme werden nicht wirklich an der „Wurzel gepackt“, sondern nur oberflächlich behandelt. Die Motive der Unternehmen, seien es aus zum Beispiel Zeitoder Kostenaspekte, werden in den Studien nicht ermittelt. Informationstechnologien Obwohl die IT (= Informationstechnologie) als ein entscheidender Erfolgsfaktor für das Prozessmanagement angesehen wird [Hung06] bzw. dieser Management-Ansatz als Integrator zwischen IT und der eigentlichen Geschäftstätigkeit fungiert [AnCh07], werden die ITSysteme oftmals nicht ausreichend auf die Prozesse abgestimmt bzw. umgekehrt. Dies führt dazu, dass die Funktionalität der IT-Systeme nicht den Anforderungen der Prozesse entspricht, was bei der Verwendung der Systeme zu Problemen führt und die Qualität der Prozessergebnisse mindert. Die im Verlauf des Prozesslebenszyklus eingesetzten Tools stellen Insellösungen dar [Wesk07]. Dies führt dazu, dass aufgrund fehlender Standards Ergebnisse, die in einer Phase mit einem bestimmten System erzielt wurden, nicht nahtlos in eine sich anschließende Phase PROZESSMANAGEMENT 2.3 33 übernommen werden können, da die Systeme dazu nicht bzw. nicht ausreichend aufeinander abgestimmt sind. Unter Berücksichtigung dessen was in Kapitel 2.3.1 zu den einzelnen Phasen erläutert wurde, zeigt dies, dass wohl zwischen dem Design und der Ausführung eine direkte Verbindung besteht, die im Prozesslebenszyklus in Abbildung 2-4 nicht explizit berücksichtigt ist. Die Entscheidungen im Design dürfen nicht nur die nachfolgende Phase der Modellierung betrachten, sondern müssen den sich danach fortsetzenden Prozesslebenszyklus im Auge haben. So sollte für die Modellierung eine Modellierungssprache und -werkzeug ausgewählt werden, mit denen es möglich ist Prozessmodelle zu erstellen, die in das Ausführungssystem importiert werden können. Laut [Kuen00] ist als eine Ursache die mangelnde Einbindung des operativen Managements in die IT-Projekte zu sehen, so dass eine phasenund fachübergreifende Abstimmung und Diskussion im Hinblick auf die Realisierung eines anforderungsgerechten Systems nicht möglich ist. [Kuen00] bezieht sich in seiner Studie zwar speziell auf Workflow-Systeme, doch kann dies auf prozessorientierte IT-Systeme im Allgemeinen übertragen werden. Vor der Implementierung eines IT-Systems sollten vorhandene Prozessdefinitionen überarbeitet werden, um IT-Systeme und Prozesse aufeinander abstimmen zu können. [Kuen00] und [RevA05] haben jedoch herausgefunden, dass dies, wenn überhaupt, nur zu einem geringen Ausmaß geschieht und die entwickelten IT-Konzepte meist auf die vorhandene Prozessstruktur angewendet wird. Die Phase des Designs wird somit auch hier nicht umfassend ausgeführt und zur Verfügung stehende Handlungsmöglichkeiten für eine möglichst optimale Realisierung des Prozessmanagementkonzeptes bleiben ungenutzt. Fazit Zusammenfassend kann als Ergebnis der Studien festgehalten werden, dass es sich beim Prozessmanagement um einen sowohl auf strategischer als auch operativer Ebene etablierten Managementansatz handelt. Es hat sich gezeigt, dass die prozessorientierte Durchführung der Geschäftstätigkeit zu einer Erhöhung der Qualität des Outputs sowie der Produktivität (vor allem im Hinblick auf die Durchlaufzeit) führt. Dennoch konnten an verschiedenen Stellen des Prozesslebenszyklus Schwachpunkte identifiziert werden. Hervorzuheben ist, dass bei der Modellierung, sei es zum Zweck der Abbildung der Organisationsstruktur oder im Rahmen der Entwicklung von IT-Systemen, gewünschte und notwendige Inhalte nicht dargestellt werden können bzw. die Modellierer sich auf die gegeben Aspekte beschränken. In dem Zusammenhang wurde auch bemängelt, dass die IT-Systeme und (die auf der Basis von Modellen erstellt werden) und Prozesse nicht optimal aufeinander abgestimmt sind. Dies betrifft konkret die von den IT-Systemen angebotene Funktionalität. Leider wird in den Studien nicht analysiert, was die Unternehmen daran hindert die individuellen Anforderungen eines Anwendungsfalles auch individuell umzusetzen. 2.3 PROZESSMANAGEMENT 34 Die genannten Schwachstellen lassen sich mit einer inadäquaten Vorbereitung der Modellierung erklären, was sich auf die Designphase des Prozesslebenszyklus bezieht. Die Designphase ist aufgrund ihrer Position im Prozesslebenszyklus der zentrale Ansatzpunkt für „erfolgreiche“, das heißt effiziente und effektive Prozesse anzusehen, da dort nach Festlegung der Strategie die ersten Grundlagen für den gesamten Prozesslebenszyklus gelegt werden. Die identifizierten Probleme motivieren, in der Designphase nach den Ursachen zu forschen bzw. die Durchführung der Designphase und/oder methodische Vorgehensweis zu optimieren. Damit sollten dann auch Mängel bei der Modellierung oder Ausführung verringert werden können. Es wird sich zeigen, ob die nun vorzustellenden Ergebnisse der eigenen Studie zu demselben Fazit kommen. Diese werden in dem sich nun anschließenden Abschnitt 2.3.2.2 präsentiert. 2.3.2.2 Eigene Studie zum Thema Prozessmanagement Die in Kapitel 2.3.2.1 vorgestellten Interviews sind fast ausschließlich international, das heißt mit Interviewpartner außerhalb von Deutschland, durchgeführt worden. Daher wurde mittels einer qualitativen Untersuchungsmethode [Lamn95] [Maye06] in Form eines sogenannten Leitfaden-Interviews [Lamn95] [Maye06] [Witz00] eine empirische Studie in neun deutschen Unternehmen durchführt, um auch einen Überblick bzgl. des Geschäftsprozessmanagements in Unternehmen direkt „vor Ort“ zu haben und eventuell kulturelle Unterschiede zu identifizieren. Im Folgenden wird zunächst die Untersuchungsmethode näher erläutert, daran schließt sich die Präsentation der Ergebnisse an. Diese Ergebnisse wurden bereits in [Meer09] veröffentlicht. 2.3.2.2.1 Research Design Eine qualitative Untersuchungsmethode verwendet offene Fragen zur Datensammlung. Meist werden Interviews durchgeführt, dies jedoch mit nur wenigen Teilnehmern. Die zu diskutierenden Themen werden vor dem Interview definiert ohne jedoch eine konkrete Hypothese zu formulieren. Die Reihenfolge in der die einzelnen Themengebiete im Laufe des Interviews angesprochen werden und in welchem Ausmaß, ergibt sich aus dem Verlauf des Gesprächs [Lamn95] [Maye06]. Der verwendete Leitfaden gibt sowohl dem Interview als auch den dabei gesammelten Daten eine Ordnung bzw. Struktur. Dazu folgen die Interviewer der vorab definierten Leitlinie, auch um sicherzustellen, dass alle notwendige Punkte angesprochen werden. Dennoch sind spontane Fragen erlaubt. Es erfolgt inhaltlich eine integrierte Betrachtung von Prozesserfassung (Design, Modellierung) und Prozessverwendung (Ausführung), um Zusammenhänge bzw. Wechselwirkungen aufdecken zu können. Zudem wurden Fragestellungen im Bezug auf die Mitarbeiter als separates Themengebiet definiert; schließlich sind sie es, die den Managementansatz realisieren bzw. „leben“ müssen. Auch die PROZESSMANAGEMENT 2.3 35 Informationstechnologien als wesentlicher Bestandteil der heutigen Geschäftswelt werden behandelt. Der detaillierte Leitfaden ist dem Anhang A zu entnehmen. Er entspricht folgendem Aufbau: • Bedeutung des Prozessmanagement Hier wird zunächst ermittelt, inwiefern das Thema Prozessmanagement überhaupt bekannt ist, um eine Orientierung für den weiteren Verlauf des Interviews zu haben. • Rahmenbedingungen Die strategischen und operativen Rahmenbedingungen, welche die Basis zur Umsetzung des Managementansatzes darstellen, werden erfragt. • Prozesserfassung und – Verwendung Zum einen wird ermittelt, wie Identifikation und Definition der Prozesse im befragten Unternehmen erfolgen; zum anderen, wie diese dann umgesetzt werden. • Informationstechnologien Hier wird die Rolle der Informationstechnologien bezüglich der Prozesserfassung und -verwendung analysiert. • MitarbeiterIn Letztendlich wird auf die Rolle der Mitarbeiter eingegangen und wie diese mit dem Thema Prozessmanagement konfrontiert werden. Für die Auswahl der Teilnehmer konnte auf Kontakte des Lehrstuhls durch Forschungsprojekte sowie Kontakte der Universität Bayreuth insgesamt zurückgegriffen werden. Dabei wurde der Fokus auf Mitarbeiter gelegt, die im Bereich des Prozesssowie Qualitätsmanagements bzw. auf Managementebene der Unternehmen tätig waren. Die potentiellen Teilnehmer wurden zunächst per e-Mail angeschrieben Nach der dann folgenden telefonischen Kontaktaufnahme zu den sich zur Verfügung stellenden Teilnehmern wurden die Interviews jeweils vor Ort in den Unternehmen durchgeführt. Einen Überblick über die wichtigsten Kennzahlen der Unternehmen gibt Tabelle 2-1. Die Übersicht zeigt, dass die Unternehmen sowohl im produzierenden als auch im dienstleistungsbezogenen Bereich tätig sind. Die Anzahl der Mitarbeiter ist sehr unterschiedlich, von der kleinsten Firma, die 13 Mitarbeiter hat, bis zu den Größten mit mehr als 330.000. Die Gespräche wurden elektronisch aufgezeichnet, wobei per Hand zusätzliche Notizen erstellt wurden. Nachfolgend wurden die Daten transkribiert. Für die Auswertung der qualitativen Daten wurde das „pragmatische Auswertungsverfahren nach Mühlfeld“ gewählt [Maye06]. Ziel dieses Verfahrens ist es nicht, die Interviews so genau wie möglich zu interpretieren, sondern Problembereiche oder Auffälligkeiten zu identifizieren, um daraus allgemeingültige Aussagen abzuleiten. Der Vorteil zu anderen Auswertungsverfahren ist darin zu sehen, dass die Ergebnisse direkt umgesetzt werden, ohne zum Beispiel den Zwischenschritt einer Paraphrasierung durchführen zu müssen. 2.3 PROZESSMANAGEMENT 36 Nr. Beschreibung der Organisation Rolle des Interviewten Anzahl der Mitarbeiter Umsatz in €/ Jahr 1 Medizintechnik Manager 40.000 k.A. 2 IT-Dienstleistung Geschäftsführer 13 k.A. 3 Handel Manager 170 k.A. 4 Werkzeugbau Geschäftsführer 380 44 Mio €/Jahr 5 Elektrotechnik Manager 170 k.A. 6 Automobil Manager 330.000 108.897 Mio €/Jahr 7 Anlagenbau Geschäftsführer 40 >10 Mio €/Jahr 8 IT Manager 100 k.A. 9 Spedition Controller 1.300 150 Mio €/Jahr Tabelle 2-1 Übersicht über die befragten Unternehmen 2.3.2.2.2 Ergebnisse Im Folgenden werden nun die Ergebnisse der Interviewreihe vorgestellt und gleichzeitig ein Vergleich zu den theoretischem Konzept des in Kapitel 2.3.1 vorgestellten Prozesslebenszyklus sowie zu den Ergebnissen der internationalen Studien durchgeführt. Bedeutung des Prozessmanagements Innerhalb der befragten Unternehmen ist das Prozessmanagement als Managementtool sowohl auf dem strategischen wie auch auf operativem Level grundlegend akzeptiert. Lediglich eine Firma vertritt eine eher kritische Meinung dazu, was aber wohl den schlechten Erfahrungswerten in Form von schlechten Kennzahlen (vor allem bzgl. des Umsatzes) zuzuordnen ist. Mehr als zwei Drittel der Unternehmen sehen die Einführung des Prozessmanagementansatzes in engen Zusammenhang mit bzw. als Grundlage für die Zertifizierung, vor allem im Hinblick auf die ISO-Zertifizierungen nach ISO 9000 und ISO 9001. Da sowohl die ISO-Zertifizierung als auch das Prozessmanagement ein integraler Bestandteil des Qualitätsmanagements sind, werden sie in einem engen Zusammenhang gesehen. Diese Korrelation wird auch in der Literatur viel diskutiert (siehe zum Beispiel [Allw05], [BeKR05], [CuKO92] oder [ZaSi95]). Neben dem ISO-Standard werden darüber hinaus von fünf der neun interviewten Unternehmen auch weitere Standards erwähnt, wie zum Beispiel die VDI-Richtlinien 2221 [VDI93] und 2222 [VDI82] [VDI97] (Regeln des Vereins Deutscher Ingenieure für die Ingenieurwissenschaft) oder ITIL [OoGC11] (Best PROZESSMANAGEMENT 2.3 37 Practice bzgl. der IT-Infrastruktur). Ihre Bedeutung scheint im Zusammenhang mit dem Thema Prozessmanagement jedoch geringer zu sein. Prozessmanagement wird außerdem als Werkzeug für eine komplette Reorganisation des Geschäftsbetriebs verwendet. Dieses Konzept kam bereits 1990 auf (siehe [Hamm90], [DaSh90]) und scheint auch heute noch aktuell zu sein. In zwei Fällen war die Einführung dieses Managementansatzes der „letzte Rettungsanker“ (Nr.4) für die Unternehmen; das Ergebnis der kompletten Umgestaltung war eine drastische Verbesserung des Geschäftsbetriebes. In den anderen Fällen war die Situation weniger dramatisch. Der Ansatz des Prozessmanagements sollte vielmehr zum Zweck der kontinuierlichen Verbesserung eingesetzt werden, hier insbesondere bzgl. der internen Kommunikation zwischen den Mitarbeitern und den Schnittstellen zwischen den verschiedenen Arbeitsbereichen bzw. Abteilungen. Ein Erfolg konnte von allen, bis auf eine Ausnahme, bestätigt werden. Rahmenbedingungen Strategische Rahmenbedingungen Die befragten Unternehmen, die Prozessmanagement erfolgreich praktizieren, weisen eine flache Organisationsstruktur, in Kombination mit einer Projektorganisation für den täglichen Geschäftsbetrieb auf. Dies entspricht dem, was auch in der Literatur allgemein vertreten wird (siehe zum Beispiel [Allw05], [BeKR05]). Die „Richtigkeit“ dieses Organisationstyps wird damit unterstrichen, dass Unternehmen, die unzufrieden mit der Adaption dieses Managementansatzes sind, eine hierarchische Organisationsstruktur mit vielen Ebenen aufweisen. Wie bereits erwähnt waren, mit Ausnahme von zwei Unternehmen, alle interviewten Unternehmen nach ISO 9000 und 9001 zertifiziert; einer der weltweit bekanntesten Qualitätsmanagementstandards, der beschreibt, welchen Anforderungen das Management eines Unternehmens genügen muss, um einem bestimmten Standard bei der Umsetzung des Qualitätsmanagements zu entsprechen. Damit wird der enge Zusammenhang zwischen Prozessund Qualitätsmanagement deutlich. Es sollte erwähnt werden, dass es sich bei den beiden Unternehmen ohne Zertifizierung einmal um ein sehr kleines Unternehmen gehandelt hat, für die Kosten und Nutzen einer Zertifizierung in keinem vertretbaren Verhältnis stehen; im zweiten Fall handelt es sich um ein hochspezialisiertes Unternehmen, für das spezielle Regularien und weniger Standardnormen relevant sind. Die Idee des prozessorientierten Denkens und Arbeitens dient der Planung und Steuerung der strategischen Aufgaben der Unternehmen. Dazu werden zur Darstellung der Kernprozesse Prozessmodelle in Form von „Prozesslandschaften“ oder „Prozesshäusern“, wie es auch in der Literatur beschrieben wird (siehe [Allw05], [BeKR05]), verwendet. Als wesentliche Informationselemente dieser Modelle sind Meilensteine und Arbeitspakete zu erwähnen. Meilensteine werden im Rahmen des Projektmanagements zur Darstellung von (Zwischen-) 2.3 PROZESSMANAGEMENT 38 Ziel verwendet; Arbeitspakete dienen der detaillierten Aufgabenbeschreibung. Ziel ist es letztendlich auch mit Hilfe der Prozessmodelle die verschiedenen Geschäftsbereiche und ihre jeweiligen Wechselwirkungen abzubilden. Im Normalfall schließt sich der strategischen Definition des Prozessmanagement-Ansatzes die Operationalisierung der Prozesse an. Nur in einem Fall konnte dieses Konzept nicht beobachtet werden; es handelte sich jedoch um ein sehr kleines Unternehmen, in dem strategische und operative Ebene sehr eng beieinander liegen und weniger streng getrennt sind, als dies bei großen Unternehmen der Fall ist. Die Durchführung des Prozessmanagements auf rein operativer Ebene wird nicht praktiziert; die strategische und operative Ebene sind zwei sich notwendigerweise ergänzende Bereiche, wobei bzgl. der Umsetzung von der strategischen Ebene her begonnen werden sollte, um ein entsprechendes Rahmenwerk vorzugeben. Konkrete Mängel, Schwachstellen oder Kritikpunkte konnten im Hinblick auf die Gestaltung der strategischen und operativen Rahmenbedingungen bis dahin nicht aufgedeckt werden. Operative Rahmenbedingungen Während die internationalen Studien unter anderem ein Mangel an methodischen Vorgehensweisen feststellen konnten (siehe zum Beispiel [WICS07]), ist der nationale Geschäftsbetrieb von Projekten geprägt. Vorgehensmodelle, so zum Beispiel das WasserfallModell [Royc70] oder das V-Modell XT [BuIn06] sind wenig bekannt und deshalb nur wenig im Einsatz. Nur ein Drittel der befragten Unternehmen verwendet sie. Es scheint, dass die Vorgehensmodelle nicht den Anforderungen der Unternehmen entsprechen, Idee und Umsetzung nicht stimmig zueinander sind. Auch weitere Methodiken im Hinblick auf die Umsetzung des Prozessmanagement wurden von den Unternehmen nicht erwähnt. Lediglich einmal wurde in dem Zusammenhang von SCM (= Supply-Chain-Management) [ScSe08] und CRM (= Customer-Relationship-Management) [ScSe08] berichtet. Es ist somit eine Übereinstimmung mit den Ergebnissen der internationalen Studien festzustellen und die theoretischen Konzepte scheinen eine nur unzureichende Umsetzung nach sich zu ziehen. Ohne Ausnahme betonten alle Unternehmen, dass es nicht allein ausreicht, die Prozesse in Modellen zu definieren und dokumentieren. „Die Prozesse müssen auch in den Köpfen der Mitarbeiter sein“ (Nr.1, Tabelle 2-1). Haben sie eine grundlegende Vorstellung von den Vorgängen, können sie die Prozesse mit der entsprechend vorhandenen Handlungsund Gestaltungsfreiheit in Kombination mit ihrem eigenen Erfahrungsschatz durchführen. Die übergreifende Koordination erfolgt durch den Projektleiter, der dabei neben dem zu erreichenden Projektergebnis das Gesamtziel des Unternehmens zu berücksichtigen hat. Wichtig ist es, die Prozesse den Angestellten und dem gesamten Geschäftsbetrieb nicht einfach aufzuerlegen. Die Prozessmodelle sollen daher nicht immer 1:1 ausgeführt werden, sondern dienen vielmehr als eine Art Rahmenwerk. Nur in zwei Unternehmen wurde dem gewissermaßen widersprochen und eine strikte Ausführung gefordert. In dem einen Fall PROZESSMANAGEMENT 2.3 39 handelte sich um die Abläufe in einer Produktionsanlage; in dem Prozessmodell werden die bei der Produktion gemäß den Vorschriften auszuführenden Schritte abgebildet. Die Einhaltung dieser Regeln ist essentiell für qualitativ gute Produkte. Im anderen Fall wurde das Prozessmodell sehr allgemein bzw. grobgranular im Hinblick auf den funktionalen Aspekt definiert, jedoch sehr genaue Angaben zum Endergebnis gemacht. Die „genaue“ Umsetzung des Prozessmodells war somit bzgl. der definierten Abläufe leicht möglich; entscheidend war, am Ende das richtige Ergebnis zu haben. Prozesserfassung und -Verwendung Im Unterschied zu den internationalen Studien wurde zusätzlich zur Modellierung auch die vorausgehende (Teil-) Phase der Prozessidentifikation empirisch untersucht, um auch einen Einblick in die Designphase zu erhalten. Beides wird zusammengefasst unter dem Begriff Prozesserfassung. Die Prozessverwendung bezieht sich auf die Ausführung der Prozesse. Identifikation + Modellierung Die Identifikation und Modellierung der Prozesse findet nach Aussage der interviewten Partner in allen Funktions-, bzw. Geschäftsbereichen der Unternehmen statt. Dies zeigt, dass aus dieser Perspektive das Prozessmanagement (bzw. zumindest ein Teil davon) ganzheitlich in den Unternehmen integriert ist. Unterschiede sind bei den Unternehmen im Detaillierungsgrad der Analyse zu finden; nicht nur zwischen den Unternehmen, sondern auch innerhalb eines Unternehmens. Je nach Kontext und Prozessart wird auf den Ebenen der Phasen, der Prozesse oder der Aufgaben analysiert und schließlich modelliert. Während Phasen den funktionalen Aspekt sehr grob umreißen, erfolgt mit Prozessen bzw. Aufgaben eine zunehmend detailliertere Spezifikation. Der Detaillierungsgrad unterscheidet sich zudem von Anwendungsbereich zu Anwendungsbereich. Administrative Prozesse werden weitaus genauer abgebildet als Produktentwicklungsprozesse. Für kleinere Unternehmen muss der Inhalt nicht so detailliert angeben werden, wie für größere (Grenzwert liegt hier bei Anzahl der Mitarbeiter > 1300); Grund ist die mit der Unternehmensgröße zunehmende Umfang der Abläufe und der dazugehörigen Aspekte (wie zum Beispiel Inputund Outputdaten), die es zu beherrschen gilt. [LeDa98] beurteilt dies hingegen weitaus negativer. Dies bezieht er vor allem darauf, dass oftmals in vergleichbaren Bereichen auf unterschiedlichem Detaillierungsgrad gearbeitet wird. [LeDa98] berücksichtigt nicht, dass noch weitaus mehr Faktoren den Detaillierungsgrad eines Modellierungsprojektes beeinflussen. Hauptverantwortlich für die Identifikation (und Modellierung) der Prozesse sind die Projektleiter oder (erfahrene) Mitarbeiter, die für das Prozessoder allgemein Qualitätsmanagements zuständig sind. Die Positionen der Verantwortlichen zeigt, welche Bedeutung dem Prozessmanagement beigemessen wird und, dass das Prozessmanagement 2.3 PROZESSMANAGEMENT 46 2.3.2.1) im deutschen Firmenleben unterrepräsentiert zu sein. Trainings werden ansonsten nur zu speziellen technischen Systemen angeboten. Im eigentlichen Tagesgeschäft werden den neuen Mitarbeiter Mentoren zugewiesen, die sie beim Einleben unterstützen sollen. „Training on the Job“ ist eine favorisierte Methode, um neue Mitarbeiter zu integrieren. Die übergreifende, ganzheitliche Einbindung der Mitarbeiter in den Geschäftsbetrieb erfolgt generell über die Projektorganisation, die typische Organisationsform bei Anwendung des Prozessmanagementansatzes (siehe zum Beispiel [BeKR05]). In den meisten Fällen, sieben von neun Unternehmen haben sich entsprechend geäußert, wird dabei im Team gearbeitet. Zur Frage, was im Hinblick auf das Tagesgeschäft (und bzgl. des Umgangs mit den Mitarbeitern) verbessert werden könnte, kamen sehr unterschiedliche Antworten. Allgemein klang durch, dass die Kommunikation bzw. Abstimmung zwischen den Mitarbeitern zu optimieren ist und damit eng verbunden auch die Organisationsstrukturen. Es besteht Übereinstimmung darin, dass die Diskussion der Schnittstellen ein wichtiger Punkt ist, die funktionsorientierte Denkund Arbeitsweise weniger ausgeprägt sein sollte, sowie auch [SIBC07] eine zu geringe Integration des Prozessgedanken identifiziert werden konnte. Die Unternehmen setzen sich also prinzipiell für das Prozessmanagement ein, sehen aber auch dass zwischen Idee, den ausgearbeiteten Konzepten und der Realität noch eine Lücke klafft. Qualifikation Zur Umsetzung des Prozessmanagement-Ansatzes brauchen nicht alle Mitarbeiter eine entsprechende Qualifikation auf diesem Themengebiet. Wichtig ist es, dass die Mitarbeiter ein Grundverständnis von den Abläufen ihres Unternehmens haben. Dies geht einher mit der Anforderung, wie sie bereits im Hinblick auf die Prozessverwendung bzw. –Ausführung, festgestellt wurden. Dort wurde gefordert, dass die Prozesse für eine erfolgreiche Ausführung „in den Köpfen der Mitarbeiter“ sein müssen; ebenso ist „der Mensch mit seinen Fähigkeiten und gesundem Menschenverstand“ (Nr.8, Tabelle 2-1) essentiell. Im Zusammenspiel mit Computer oder auch Roboter ist diese Komponente essentiell für den Alltagsbetrieb des Prozessmanagement-Ansatzes. Darüber hinaus ist es natürlich wichtig, dass die Mitarbeiter prinzipiell eine gute fachliche Qualifikation besitzen, um die in den Prozessmodellen spezifizierten Aufgaben auch inhaltlich und fachlich ausführen zu können. Fazit Zusammenfassend kann, wie bei den internationalen Studien auch, festgehalten werden, dass es sich beim Prozessmanagement um einen sowohl auf strategischer als auch operativer Ebene etablierten Managementansatz handelt. Die Interviewpartner konnten eine wesentliche Verbesserung ihrer Ergebnisse bestätigen, vor allem im Fall einer kompletten Reorganisation des Betriebs. PROZESSMANAGEMENT 2.3 47 Es scheint, dass der Fokus sehr auf den internen Abläufen liegt, da eine Integration externer Partner in diesen Management-Ansatz nicht explizit erwähnt wird. Entsprechende Konzepte wie SCM (= Supply Chain Management) oder CRM (= Customer Relationship Management) (siehe [ScSe08]) wurden lediglich einmal erwähnt. Eine holistischere Umsetzung des Prozessmanagements [Hung06], bei der die externen Partner in diesen (Qualitäts-) Management-Ansatz mit eingebunden werden [ZaSi95], könnte noch weitere Verbesserungen mit sich bringen. Da bei den internationalen Studien dies bzgl. keine Angaben gemacht wurden, ist an dieser Stelle kein Vergleich möglich. Informationstechnische Systeme sind nicht das Hauptwerkzeug zur Umsetzung des Prozessmanagement-Ansatzes. Die Systeme scheinen bzgl. ihrer Eigenschaften und Funktionen Qualitätsmängel zu haben, was vor allem die Modellierungswerkzeuge betrifft. Dies wird durch die Tatsache, dass individuelle Unternehmensaspekte eigentlich überhaupt nicht modelliert werden, unterstrichen; nur die üblichen Aspekte werden modelliert, was mit den Ergebnissen der internationalen Studien korrespondiert. Generell hat es sich herauskristallisiert, dass die IT-Systeme und die Prozesse nicht optimal aufeinander abgestimmt sind. So wird in der Praxis dem Faktor Mensch bei der Ausführung eine hohe Bedeutung beigemessen. Im Hinblick auf die beiden Studien konnten somit übereinstimmend die Schwachpunkte im Bezug auf den Prozesslebenszyklus bzw. den Ansatz des Prozessmanagements identifiziert werden. Generell ist zu erkennen, dass die erzielten Ergebnisse bzw. verwendeten bzw. vorhandenen Systeme, wie es zum Beispiel vor allem bei den Modellierungswerkzeugen der Fall ist, sich nicht immer mit den gewünschten Anforderungen decken. Dies deutet darauf hin, dass genau dieser Stelle, nämlich der richtigen Definition und Umsetzung der Anforderungen, zu wenig Beachtung geschenkt wird. 2.3.3 Fazit bzgl. dem Stand in Forschung und Praxis Das grundlegende Verständnis, was den Ansatz des Prozessmanagements betrifft, deckt sich bzgl. Theorie und Praxis. Als Instrument zur Organisation des Geschäftsbetriebes ist es auf strategischer wie auf operativer Ebene anerkannt. Doch gibt es Diskrepanzen bei der Umsetzung der theoretischen Konzepte in der Praxis, so dass die Ergebnisse bei letzterer nicht immer das liefern, was die Theorie vorgegeben hat. Die Diskrepanz gilt es jedoch differenziert zu betrachten. Es ist zu berücksichtigen, dass die in der Theorie bzw. im akademischen Bereich ausgearbeiteten Ideen und Konzepte unter anderem zukünftige Möglichkeiten darstellen und somit stets noch verbesserungswürdig sind; es handelt sich um Vorstellungen, die noch nicht (vollständig) in der Praxis erprobt wurden, wodurch die Feinabstimmung fehlt. Es ist zu vergleichen mit einem Prototyp aus der Produktentwicklung, der sich auch erst unter echten Bedingungen bewähren muss. Aufgabe der Praxis ist es, herauszufinden, was in welcher Form aus der Theorie übernommen werden kann; die Praxis ist zunächst der „Tester“ der akademischen Ideen. Die Diskrepanzen sind somit ein 2.3 PROZESSMANAGEMENT 48 essentieller Bestandteil für die Weiterentwicklung bzw. kontinuierliche Verbesserung der Konzepte. Abzugrenzen sind davon explizit Ideen und Konzepte, bei denen selbst nach längerer Zeit (das Thema Prozessmanagement wird insgesamt seit ungefähr 20 Jahre diskutiert) noch Diskrepanzen zwischen Theorie und Praxis zu finden sind. In solchen Fällen ist eine grundlegende Analyse des vorliegenden Falls unabdingbar. Die hohe Relevanz der Prozessmodellierung kann mit den analysierten Studien sowie den Ergebnissen der eigenen klar aufgezeigt werden. Mittels Geschäftsprozessmodellen oder ITModellen werden notwendige Informationen für den Geschäftsbetrieb, organisatorische Strukturen wie auch die informationstechnische Aspekte in einer konsolidierten Art und Weise festgehalten [Giag01] [LiPr96]. Die Modelle bilden die Grundlage für die spätere Ausführung der Prozesse sei es mit oder ohne IT-Systeme. Für eine erfolgreiche Realisierung der Modellierung wird in der Literatur die Designphase inklusive der dabei durchzuführenden Anforderungsanalyse (siehe dazu Kapitel 2.3.1 ) als ein essentieller Schritt betrachtet. In keiner der in Kapitel 2.3.2 betrachteten Studien (vor allem bei denen, die allgemein das Thema Prozessmanagement behandeln) sind jedoch explizit Informationen über die Designphase und methodische Vorgehensweisen, Rahmenbedingungen oder zu erreichenden Ziele zu finden. Selbiges gilt für die Anforderungsanalyse. Auch in der eigenen Studie sind nur sehr wenige Informationen dazu zu finden. Das seit der Veröffentlichung des Artikels von Hevner [HMPR04] im Jahre 2004 gestiegene Interesse an diesem Thema [InRe08] scheint den Alltag der Unternehmen noch nicht erreicht zu haben, obwohl die jüngsten der analysierten Studien aus dem Jahre 2010 stammen, so dass ein gewisser Zeitrahmen zur Übernahme der Ideen inzwischen vorhanden ist. Das Design scheint in der Praxis eine weitaus geringere Relevanz als die sich anschließende Modellierung zu haben; und dies obwohl das Design die notwendigen Angaben für die Modellierung liefert. Die Prozessmodelle sind letztendlich „nur“ ein Instrument, um die im Design ermittelten Anforderungen und Umsetzungsmöglichkeiten festzuhalten [DaSh90]. Somit ist die unterschiedliche Relevanz von Design und Modellierung, wie sie identifiziert wurde, nicht nachvollziehbar, jedoch erklärbar: Es scheint noch eine starke Vermischung dieser beiden Phasen vorzuliegen, was sich vor allem darin zeigt, dass die Aufgaben des Designs weniger vorbereitend im Bezug auf die Modellierung, sondern wenn dann begleitend erfolgen. Zeitund Kostendruck, die dazu führen existierende Lösungen (vor allem im Bezug auf Modellierungssprachen und -Werkzeugen) ohne ausreichende Analyse zu übernehmen, können ein Grund dafür sein. Auch scheint es noch an einer klaren Trennung von Verantwortlichkeiten in dem Sinne, dass „Designer“ ihrer Aufgabe nachgehen, zu fehlen. Da die Designphase in der Praxis nur in geringen Ausmaß bzw. fast gar nicht durchgeführt wird, ist erklärbar, dass in den Prozessmodellen der befragten Unternehmen meist nur die gängigen Aspekte (wie Prozesse, Rollen und Werkzeuge [CuKO92] [JaBu96]) dargestellt PROZESSMANAGEMENT 2.3 49 werden, die Modelle nicht zum jeweiligen Anwendungskontext passen und dem Anwender wichtige Informationen fehlen. Auch die IT-Systeme, die letztendlich auf Basis von Modellen entwickelt werden [VeCo94], können folglich nicht zu den durchzuführenden Prozessen passen, vor allem im Bezug auf Funktionalitäten. Es werden vorhandene (Modellierungs-) Werkzeuge, ohne oder mit nur geringen Anpassungen wieder bzw. weiterverwendet, ohne dabei auf den genauen Zweck und Kontext der Prozesse einzugehen und, speziell bei den Modellierungswerkzeugen, auf die „Richtigkeit“ der Modellierungssprachen zu achten [ClSW08]. Da die Designphase am Anfang des Prozesslebenszyklus steht, setzen sich Fehler in alle nachfolgenden Phasen durch und ziehen möglicherweise weitere mit sich. Zwar können sie gegebenenfalls mit geeigneten Maßnahmen ausgeglichen werden, doch nimmt dies zusätzlich Zeit und Kosten in Anspruch. Da ein klares Defizit bzgl. der Beachtung bzw. Durchführung der Designphase festgestellt werden konnte, was bereits mit der unzureichenden Analyse der Anforderung beginnt, gilt es in dieser Arbeit aufgrund der Bedeutung der Designphase deren Aufgaben sowie Ziele zunächst explizit herauszuarbeiten. Die ermittelten Aspekte werden schließlich in einem methodischen Rahmenwerk für das Design integriert. Dies erfolgt im Hinblick auf den gesamten Prozesslebenszyklus, insbesondere der Modellierung. 2.3 PROZESSMANAGEMENT 50 DESIGN UND MODELLIERUNG – EINE ABGRENZUNG 3.1 51 Kapitel 3 Design und Modellierung – Definition und Grundlagen Nachdem in dem vorherigen Kapitel die Begriffe Design und Modellierung bereits kurz eingeführt worden sind, erfolgt nun eine klare Abgrenzung dieser beiden Phasen. Dazu werden Design und Modellierung zunächst jeweils allgemein definiert, um sie dann auf den Kontext des Prozessmanagements zu übertragen. Für einen umfassenden Überblick werden die methodischen Vorgehensweisen der beiden Phasen erläutert. 3.1 Design und Modellierung – eine Abgrenzung Von einer sauberen Spezifikation wird eine klare Trennung der beiden Phasen erwartet, so dass mit der eindeutigen Klärung der Aufgabenstellung auch die zu erzielenden Ergebnisse klar definiert sind. Eine eindeutige Zielvorstellung wirkt sich wiederum auf die Qualität der Ergebnisse der beiden Phasen aus. 3.1.1 Design Der englische Begriff Design bedeutet ins Deutsche übersetzt „Entwurf“ [Weis91]. Er wird in den verschiedensten Sprachen verwendet, so zum Beispiel im Französischen oder Italienischen. Der deutsche Sprachgebrauch fokussiert sich eher auf den formalen bzw. künstlerischen Aspekt und verdinglicht den Designbegriff, während der angelsächsische Designbegriff auch den technischen sowie konstruktiven Anteil des Designs umfasst. Eine sprachübergreifend einheitliche Definition des Begriffes gibt es also nicht [RaWa09]. Design ist in vielen Bereichen ein zentrales Thema. Im Bereich der Architektur und Kunst ist der Begriff wohl am bekanntesten [WaWE92]. Er wird aber zum Beispiel auch im Ingenieurbereich, nämlich in der Konstruktion, verwendet [DyLi00] [PaBe97] [Petr06] und im Bereich der Informationssysteme. Im Bereich der Informationstechnik geht es um die Organisation eines Unternehmens (Strategie, Kultur und Prozesse) und die Gestaltung der Technologien (Infrastruktur, Anwendungen, …) [HMPR04]. [Schn05] und [Stef00] definieren das Design als einen Gestaltungsund Entwurfsvorgang, dem eine eingehende Analysephase bzgl. des zu gestaltenden Objektes vorausgeht. Letztendlich gilt es verschiedene Funktionen zu erfüllen. Einzelne Funktionen werden im Folgenden allgemein erläutert und es wird gezeigt, wie sie im Kontext Prozesslebenszyklus im Rahmen des (Geschäfts-) Prozessmanagements (siehe Kapitel 2.1) zu sehen sind. 3.1 DESIGN UND MODELLIERUNG – EINE ABGRENZUNG 52 Zeichenhaft-semantische Funktion Das Design soll eine Idee, einen Begriff oder Vorgang symbolisch und somit wahrnehmbar bzw. verständlich darstellen. Mit welchem Symbol oder Zeichen eine Vorstellung eindeutig assoziiert werden kann, muss zuvor genau ermittelt werden, um Missverständnisse oder sogar ein Nichtverstehen zu vermeiden [Schn05] [Stef00]. So symbolisieren zum Beispiel üblicherweise Schlegel und Eisen den Bergbau. Bekannt ist auch der sog. Mercedes-Stern, der die entsprechende Automarke repräsentiert. Auf das Prozessdesign bezogen geht es um die Festlegung der textuellen, tabellarischen und/oder graphischen Darstellungsarten (Zeichen, Symbole, Syntax) zur Präsentation der Abläufe einer Organisation [HMPR04] [JaDV08]. Es beinhaltet die Definition von Zeichen, Symbolen mit entsprechender Syntax (welche die Beziehung zwischen den Zeichen und Symbolen festlegt) und Semantik (welche die Bedeutung der Zeichen und Symbole definiert) [Bode06]. In ihrer Gesamtheit bilden diese drei die Definition einer (Prozess-) Modellierungssprache [Bode06] [ClSW08]. Abbildung 3-1 Beispiel zeichenhaft-semantische Funktion Eine mögliche Realisierung dieser Designfunktion ist in Abbildung 3-1 zu sehen. Rechtecke werden als Prozessschritte angesehen, die jeweils über einen Kontrollfluss in Form eines Pfeils miteinander verbunden, d.h. in eine Ablaufreihenfolge gebracht werden. Sollen auch Dokumente angegeben werden, müssen weitere Zeichen inklusive Semantik und Syntax definiert werden. Für eine weitere Optimierung kann zum Beispiel für das Prozessmodell einer Klinik festgelegt werden, dass die Modellierungssprache zwei Arten von Schritten beinhalten soll: ovale und eckige Schritte zur Unterscheidung administrativer und medizinischer Abläufe. Formale Funktion Die von außen sichtbare Gestalt eines Objektes oder der Ablauf einer Handlung (nicht der Inhalt) müssen bzw. sollen bestimmten Vorschriften genügen. Gestalt oder Handlung entsprechen dann einem nach außen sichtbaren Rahmenwerk, das der allgemeinen Orientierung sowie dem Verständnis dient. Diese Vorschriften gilt es im Design entsprechend auszuarbeiten [Stef00] [Schn05]. Dies entspricht im übertragenen Sinn der syntaktischen und semantischen Korrektheit der (Prozess-) Modellierungssprachen sowie der damit erstellten Modelle [FrvL03] [Mend08]. Dies bedeutet, dass die Elemente eines Prozessmodells gemäß den festgelegten Vorschriften, DESIGN UND MODELLIERUNG – EINE ABGRENZUNG 3.1 53 sog. Modellierungsregeln, erstellt werden. So muss ein Prozessschritt immer mit mindestens einem einund ausgehenden Kontrollfluss oder einem Datenelement (bzw. Datenfluss) definiert werden, um syntaktisch korrekt zu sein. Die formalen Aspekte können sich auch aus dem Anwendungskontext der Prozesse ergeben, durch gesetzliche Vorgaben oder Unternehmensrichtlinien, die zum Beispiel die parallele Ausführung administrativer Schritte untersagen. Es zeigt sich hier, dass sich die Umsetzung der Anforderungen sowohl auf das Design als auch auf die Verwendung einer Modellierungssprache beziehen kann. Ästhetische Funktion Das Ergebnis des Gestaltungsvorgangs soll nicht nur seinen Zweck an sich erfüllen, sondern sollte auch ansprechend und akzeptabel sein [Schn05] [Stef00]. Was ansprechend bzw. akzeptabel ist richtet sich nach den Nutzern. Diese definieren die Anforderungen, ihre „Schönheitsideale“, die es dann funktional umzusetzen gilt. Die Problematik ist hierbei, dass Ästhetik nur schwer objektiv definiert und beurteilt werden kann. Dies kann direkt auf die Modellierungssprache und ihre Benutzerfreundlichkeit sowie auf die Modelle bzw. Modellierung als Ganzes übertragen werden [FrvL03]. Die Modelle sollen letztendlich ansprechend und lesbar sein; es reicht nicht aus, sich auf die rein inhaltliche oder formale Darstellung zu konzentrieren. So werden bei EPKs (= Ereignisgesteuerte Prozessketten) Modellierungskonstrukte für Papierdokumente, elektronische Dokumente und allgemeine Informationsobjekte in ihrer graphischen Darstellung unterschieden [KeNS92]. Dennoch ist eine gewisse Ähnlichkeit und damit Zusammengehörigkeit zu erkennen, wie es Tabelle 3-1 zeigt. Lesbarkeit und Verständnis erhöhen sich dadurch. Graphische Darstellung Anmerkung Dokument in Papierform Bsp. Brief Elektronisches Dokument Bsp. E-Akte Informationsobjekt Informationsobjekt als ein Element des Datenflusses Tabelle 3-1 Beispiele Informationsobjekte EPK Aus ästhetischen Gründen und weil ein Leser nur eine begrenzte Zahl an Elementen auf einmal erfassen kann [Mill56], sollten nicht mehr als sieben Prozesselemente auf einem Blatt modelliert sein. Diese Anforderung zeigt wiederum, dass sich eine Anforderung nicht direkt auf die Definition der Modellierungssprache beziehen muss, sondern auch deren Verwendung bei der Modellerstellung betreffen kann. Außerdem handelt es sich um eine Anforderung, die auch der formalen Funktion zugeordnet werden kann. Gesagtes gilt auch für die Einfärbung 3.1 DESIGN UND MODELLIERUNG – EINE ABGRENZUNG 54 der Datenelemente bei der Erstellung eines Modelles gemäß vorab in der Designphase definierter Kategorien; die medizinischen Daten werden demnach zum Beispiel rot, die administrativen blau eingefärbt. Strukturierende Funktion Die strukturierende Funktion dient der Verdeutlichung des Aufbaus eines zu gestaltenden Objektes bzw. der Gliederung von dessen Bestandteilen [PaBe97] [Schn05]. Die Zusammenhänge zwischen den Einzelteilen des Gesamtobjektes und deren Ordnung müssen daher zuvor grundlegend analysiert werden. Dabei kann zum Beispiel zwischen hierarchischen oder logischen Zusammenhängen [PaBe97] unterschieden werden. Genauso müssen auch die Struktur und die Zusammenhänge des zu modellierenden Sachverhaltes in einem (Prozess-) Modell verdeutlicht werden. Die Prozesse lassen sich anhand verschiedener, voneinander unabhängiger Perspektiven (zum Beispiel funktions-, datenorientiert [JaBu96]) logisch strukturieren. Darauf aufbauend kann die Definition aspektorientierter Modellierungssprachen erfolgen [JaBu96]. Es sind Modellierungskonstrukte und Regeln zu definieren, wie zum Beispiel ein kompositer Prozess, der es erlaubt, mehrere logisch zusammengehörende Schritte zusammenzufassen und somit Zusammenhänge zu definieren. Der strukturierende Aspekt geht oftmals mit der ästhetischen sowie zeichenhaft-semantischen Funktion einher. In dem bereits in Kapitel 2.2.3 erwähnten Prozessmodell wurde eine hierarchische Gliederung in Phasen, Hauptprozesse und Arbeitsschritte vorgenommen. Dies wurde zusätzlich ergänzt durch Verwendung verschiedener Farben für den funktionalen Aspekt. Letzteres dient zum einen der zusätzlichen Strukturierung, kann zugleich aber der ästhetischen Funktion zugeordnet werden. Denn die farbliche Kennzeichnung wirkt sich positiv auf die Lesbarkeit des Modells aus, da dem Anwender klar ist, auf welcher Ebene er sich befindet. Dieses Beispiel zeigt, dass die einzelnen Funktionen des Designs nicht isoliert voneinander zu betrachten sind, sondern oftmals ineinander greifen und sich gegenseitig ergänzen. Didaktische Funktion Schließlich möchte der Designer dem späteren Anwender mit seinem von ihm entwickelten Objekt auch immer etwas vermitteln, d.h. er verfolgt ein bestimmtes Ziel [Schn05]. Dabei kann es um die Vermittlung von Tatbeständen, von Wissen und/ oder einem bestimmten Kenntnissen gehen [Ball70]. Dies muss zunächst inhaltlich ermittelt werden, um dann zu definieren, wie es didaktisch vermittelt werden kann. Dies ist vor allem mit der ästhetischen Funktion eng verbunden. Mit jedem Element der Modellierungssprache und dessen Verknüpfung zu weiteren Elementen soll ein Ausschnitt aus der Realität vermittelt werden. Die im Kontext dieser Arbeit erstellten Prozessmodelle sollen dem Nutzer einen Überblick darüber geben, welche DESIGN UND MODELLIERUNG – EINE ABGRENZUNG 3.1 55 Aufgaben die jeweilige Organisation zu erfüllen hat und wie diese Tätigkeiten zum Beispiel rollenund / oder abteilungsübergreifend miteinander zusammenhängen. Die didaktische Funktion bezieht sich somit zunächst auf das Modell und muss dann auf die Modellierungssprache herunter gebrochen werden. Für eine bessere didaktische Vermittlung eines Sachverhaltes kann dann zum Beispiel definiert werden, dass nie mehr als sieben Elemente auf einem Blatt gezeichnet werden [Mill56]. Dieser Aspekt wurde bereits bei der ästhetischen Funktion genannt, was zeigt, dass mit einem im Design definierten Aspekt gleich mehrere Funktionen erfüllt werden können. Folgendes kann somit für das Prozessdesign festgehalten werden: 3.1.2 Modellierung Ursprünglich wurde der Begriff Modell vor allem im Bereich der Architektur verwendet. Dort bezeichnet das italienische Wort „modello“, das aus dem Lateinischen (modellus) stammt (deutsch: Maßstab), einen Maßstab [Mitt84]. Der bezeichnete Maßstab ist Teil eines Messvorgangs, der einen Ausschnitt der Realität in eine für den Menschen verständliche, „leichter realisierbare“ [Mitt84] Darstellung umsetzt. Auch heutzutage werden bei Gestaltungsund Entwicklungsvorgängen zum besseren Verständnis und zum Zweck der Kommunikation Objekte oder ein Sachverhalt vereinfacht, Zu Beginn der Designphase muss zunächst eine genaue Anforderungsanalyse im Hinblick auf den abzubildenden Sachverhalt, den Zweck der Abbildung und das dafür gewünschte Prozessmodell mit seinen individuellen Eigenschaften erfolgen (= Input). Darauf aufbauend gilt es, die notwendigen Funktionen zu realisieren, was in Form der Modellierungssprache und deren Modellierungselementen, deren Eigenschaften und Modellierungsvorschriften erfolgt. Dies kann durch Anpassung oder Auswahl einer existierenden Modellierungssprache oder die komplette Neudefinition erfolgen. Dabei gilt es zu beachten, dass sich im Design eine Anforderung auf mehrere Funktionen beziehen kann bzw. umgekehrt eine Funktion auf mehrere Anforderungen. Desweiteren beschränkt sich die Umsetzung der Funktion nicht nur auf das Design, sondern erstreckt sich auch auf die nachfolgenden Phasen des Prozesslebenszyklus. Das Ergebnis (= Output) ist zunächst eine Modellierungssprache, welche die diskutierten Funktionen im Hinblick auf den aktuell vorliegenden Kontext unterstützt bzw. erfüllt. Sie wird ergänzt durch die Angabe von Modellierungsregel zur Erstellung eines Modells. Dies führt letztendlich zur Festlegung der konzeptionellen Modellgestaltung, was explizit von der Modellierung eines konkreten Sachverhaltes abzugrenzen ist. Auch können Aspekte definiert werden, die sich auf die Verwendung des Models beziehen. 3.2 METHODISCHE GRUNDLAGEN DES DESIGNS 62 Um Zeitund Kostenersparnisse zu erzielen, bietet es sich oftmals an, die Reihenfolger der Schritte zu ändern, wodurch zum Beispiel unnötige Wartezeiten bei zwei aufeinanderfolgenden Schritten vermieden werden können [ReLi04]. Die Neuordnung in Abbildung 3-3 ist jedoch nur möglich, wenn Prozess 3 nicht darauf angewiesen ist, dass Prozess 1 und 2 vor ihm ausgeführt sind. Als eine Sonderform ist die parallele Anordnung von Schritten zu nennen [ReLi04] [Schu06], die vor allem eine Verkürzung der Durchlaufzeit zum Ziel hat. Benchmarking Das Benchmarking (= Maßstäbe setzen) basiert auf einem systematischen Vergleich der eigenen Organisation mit einer Vergleichsorganisation an Hand von Ähnlichkeitswerten bzw. Kennzahlen [Gabl10] [ZdKa02]. Es werden Produkte und Dienstleistungen, aber auch Prozesse betrachtet, d.h. strukturiert verglichen [Gabl10]. Letzteres ist auch unter dem Begriff Process Benchmarking geläufig [MCLP99] [Zair94] [ZaSi95]. Die Methode ist nur anwendbar, wenn zu den eigenen definierten Prozessen Vergleichsprozesse vorhanden sind. Die zu vergleichenden Prozesse müssen dabei derart definiert sein, das ein Vergleich möglich ist. Die vergleichende Analyse kann aus betriebswirtschaftlicher wie auch aus IT-bezogener Sichtweise erfolgen, um unter wirtschaftlichen Gesichtspunkten in qualitativer wie auch quantitativer Hinsicht einen Vergleich aufzustellen [MCLP99] [ZdKa02]. Im Vordergrund steht der Leistungsvergleich der Unternehmen bzw. hier der Unternehmensprozesse [ZaSi95] [ZdKa02]. Dazu werden unter anderem Kundenbefragungen oder Leistungsvergleiche auf Basis von veröffentlichten Statistiken durchgeführt [ZaSi95]. Die Analyse erfolgt anhand zuvor festgelegter Referenzwerte, wie zum Beispiel Durchlaufzeit, Absatzzahlen oder Kostenaspekte [MCLP99] [Zair94]. Werden relevante Abweichungen zwischen Referenzund Ist-Wert identifiziert, gilt es entsprechende Änderungsmaßnahmen vorzunehmen, um die Abweichungen zu beheben oder zumindest zu verringern [Gabl10] [ZdKa02]. Die Relevanz der Abweichungen wird durch deren Ausmaß zum vorgegebenen Referenzwert definiert. Die Spezifikation individueller Referenzwerte ist notwendig, weil sich Unterschiede zwischen den Unternehmen und ihren Prozessen auch aus den individuellen Rahmenbedingungen ergeben können, die sich dann weniger zum Vergleich anbieten. Das Benchmarking ist auch in engem Zusammenhang mit Best Practices (siehe Absatz oben) zu sehen. Denn das Analyseverfahren im Rahmen des prozessorientierten Benchmarking wird auch dazu verwendet Best Practices zu identifizieren [ZaSi95]. In diesem Zusammenhang wird auch von Best Practice Benchmarking gesprochen. METHODISCHE GRUNDLAGEN DES DESIGNS 3.2 63 Bewertung des Pragmatischen Prozessdesigns Leider führen die Methoden des pragmatischen Prozessdesigns nicht zwingend zu dem optimalen Design der Prozesse [ReNV07]. Dies resultiert daraus, dass die Methodik auf Erfahrungswerten aufbaut, die sehr von der persönlichen Wahrnehmung abhängen. Die Erfahrungswerte sind jedoch auch positiv zu bewerten. Bei damit gestalteten Prozessabläufen besteht ein gewisses Maß an Sicherheit, dass ein zufriedenstellendes und verwendbares Ergebnis erzielt werden kann. Aufgrund der Erfahrung können gewisse „Anfänger“-Fehler vermieden werden. Sowohl Best Practices als auch Benchmarking bieten den Vorteil, dass ein Vergleich mit bei anderen Unternehmen erfolgreich eingesetzten Lösungen erfolgt und die direkte Orientierung am Markt möglich ist. Best Practices sind nicht ohne einige zusätzliche Arbeitsschritte einsetzbar, sondern müssen noch an die konkreten Bedingungen innerhalb der betreffenden Organisation angepasst werden. Dieser Anpassungsprozess sollte aufwandstechnisch nicht unterschätzt werden. Selbiges gilt auch für die im Rahmen eines Benchmarkings identifizierten Verbesserungsmaßnahmen. Nicht jedem Unternehmen ist dies aus organisatorischen oder finanziellen Gründen möglich. Beim Benchmarking ist zudem vor allem die Spezifikation der Referenzwerte ein kritischer Schritt. Das Unternehmen muss sich darüber im Klaren sein, welche Zielvorstellungen es genau verfolgt. Bei einem Vergleich mit anderen Organisationen, wie er beim Benchmarking vollzogen wird, besteht zudem stets die Gefahr, dass „Äpfel mit Birnen“ verglichen werden, auch wenn es sich um dieselben Kennzahlen jedoch in einer anderen organisatorischen Umgebung (zum Beispiel im Hinblick auf die Unternehmensgröße, den geographisch zu erreichenden Absatzmarkt) handelt. Es werden möglicherweise falsche Schlüsse gezogen, durch die unnötige, wenn nicht sogar kontraproduktive Maßnahmen veranlasst werden. Bei den hier vorgestellten Methoden wird das Design bereits im Rahmen eines sich wiederholenden, d.h. verbessernden Prozesslebenszyklus durchgeführt. Von einer kompletten Neudefinition einer Modellierungssprache wird daher üblicherweise Abstand genommen, da dies eine sehr umfassende und aufwendige Neumodellierung des gegebenen Sachverhaltes zur Folge haben kann. Das Design beschränkt sich auf die Definition von Modellierungsregeln. Nach Gesagtem macht dies im Kontext eines kontinuierlichen Verbesserungsprozesses durchaus auch Sinn, so dass dies hier nicht negativ ausgelegt werden sollte. Die pragmatischen Ansätze des Prozessdesigns bilden die Grundlage für die Entwicklung der im Folgenden beschriebenen theoretischen, wissenschaftlichen Ansätze. Die beiden Ausrichtungen des Designs ergänzen sich somit gegenseitig bzw. bauen aufeinander auf. 3.2.2 Theoretisches Prozessdesign Im Gegensatz zum pragmatischen Prozessdesign handelt es sich bei der theoretischen Ausrichtung um einen formalen Ansatz, der auch unter dem Begriff scientific design geläufig 3.2 METHODISCHE GRUNDLAGEN DES DESIGNS 64 ist [HoVe01] [ReNV07] [vAHW03] [vAal98]. Es basiert auf formalen Methoden und Techniken und ist von einer sehr analytischen Vorgehensweise geprägt [HoVe01] [RLvA03]. Als design from scratch [ReNV07] [RLvA03] werden Prozesse grundlegend, ohne bereits existierende Prozesse zu berücksichtigen, neu gestaltet, weshalb auch von einem revolutionären Ansatz gesprochen wird [ReNV07] [RLvA03]). Dabei ist es das Ziel, den optimalen Prozessablauf und all seine zusätzlichen Eigenschaften zu spezifizieren. Im Folgenden sollen exemplarisch Ansätze des theoretischen Prozessdesigns vorgestellt werden. Dies sind: • Product Based Design • Algorithmen Product Based Design (PBD) Der Ansatz des Product Based Design [ReNV07] [RLvA03] [vHRe00] ist im Kontext dieser Arbeit von Interesse, da er im Hinblick auf die beispielhaft verwendete Anwendungsdomäne der Produktentwicklung (siehe Kapitel 2.2.1) ein sehr naheliegender und nachvollziehbarer Ansatz ist. Hier bildet das Produkt den primären Ansatzpunkt zur Analyse, um die für die Fertigung des Produktes notwendigen Prozesse definieren zu können. Das Product Based Design ist grundsätzlich eine Übertragung der Idee der Stückliste [Orli72] aus der Produktionbzw. Fertigungswirtschaft auf den Bereich administrativer Prozesse [ReNV07] [vHRe00]. Es gilt die Annahme, dass das Produkt alle für den Herstellungsprozess notwendigen Informationen liefert. Es erfolgt daher zunächst die Identifikation der Produktbestandteile (= data elements) und deren logischen Abhängigkeiten (= production rules). Die sich daraus ergebende Struktur wird im sog. Produktdatenmodell (= PDM) festgehalten. In Abbildung 3-44 ist beispielhaft ein solches Produktdatenmodell zu sehen. Die Knoten stellen die Bestandteile (= data elements) dar; mittels der Kanten werden die Abhängigkeiten verdeutlicht. Der Wurzelknoten an der obersten Stelle in der Abbildung stellt das Endprodukt dar. Ausgehend von dem Produktdatenmodell kann darauf aufbauend das Prozessmodell erstellt werden. Folgende Methodik ist dazu definiert: • Ein oder mehrere data elements werden zu einem Herstellungsschritt (=Activity) zusammengefasst. In Abbildung 3-4 werden zum Beispiel die neun data elements im linken unteren Teil des Produktdatenmodells der Activity G zugeordnet. Dieses Vorgehen wird für alle restlichen Knoten wiederholt, bis kein Knoten mehr übrig ist. • Es erfolgt die Festlegung einer Reihenfolge der Herstellungsschritte (=Acticity) 4 Die Bezeichnung der Knoten in der Abbildung ist in diesem Kontext nicht von Relevanz. METHODISCHE GRUNDLAGEN DES DESIGNS 3.2 65 Mit diesen Informationen kann schließlich das Prozessmodell definiert werden. Damit erfolgt nach der Definition von Design und Modellierung in den Kapitel 3.1.1 und 3.1.2 der Wechsel zur Modellierungsphase, was in der hier zitierten Literatur nicht derart differenziert betrachtet wird. Es handelt sich prinzipiell um eine sehr rationale und auch effiziente Vorgehensweise, da das Produkt als Grundlage des Designs verwendet wird. Jeder Schritt im Prozessmodell kann mit einem data element aus dem Produktdatenmodell begründet werden kann, so dass keine unnötigen Schritte im Prozessmodell zu finden sind. Die Vorgehensweise kann jedoch nicht verhindern, dass dennoch „schlechte“ Abläufe (zum Beispiel durch hohe Wartezeiten) definiert werden. Abbildung 3-4 Produktdatenmodell aus [ReNV07] 3.2 METHODISCHE GRUNDLAGEN DES DESIGNS 66 Algorithmen Algorithmen zeichnen sich dadurch aus, dass sie eine eindeutige Handlungsvorschrift zur Lösung eines Problems vorgeben [Levi02] [HoVe01] [VTMR07]. Dazu muss das Designproblem zunächst formal in einem Modell beschrieben werden, um dann unter Berücksichtigung von Optimierungsfunktionen (zum Beispiel additive oder Min-MaxFunktion) des optimale Design ableiten zu können. Dies erfolgt vornehmlich in Bezug auf die Aspekte Zeit und Kosten. Auch im Bereich des Prozessdesign werden inzwischen Algorithmen angewendet, auch wenn dies aufgrund des formalen Charakters der Algorithmen gegenüber den oft nur qualitativ zu beurteilenden Prozessen schwierig ist [YuLi00] [VTMR07]. Im Folgenden werden drei Techniken, die auch im Rahmen des Prozessdesigns angewendet werden, vorgestellt. Die Erläuterungen sind nur kurz, da es sich um sehr mathematische Verfahren handelt - ein Themengebiet, das im Rahmen dieser Arbeit nicht im Fokus der Betrachtung steht. • Im Rahmen der Mathematischen Programmierung [HoVe01] wird das Optimierungsproblem, hier der Prozess, in Form einer entsprechenden (Ziel-) Funktion erfasst inklusive der Angabe von Variablen und Constraints im Hinblick auf die Ressourcen, wie zum Beispiel Rollen oder Systeme. Berechnet werden damit zulässige und optimale Lösungen für das Problem. Es eignet sich jedoch eher nur für kleinere Fälle, vor allem was die Anzahl der Variablen betrifft. • Bei größeren Designbzw. Optimierungsproblemen kann die sog. Branch-and-boundMethode [AVTa89] [HoVe01] [IcSZ93] verwendet werden. Im Vergleich zur mathematischen Programmierung ist sie leichter zu implementieren, hat meist eine kürzere Rechenzeit und liefert bessere Ergebnisse. Ziel der Methode ist es einen Entscheidungsbaum zu definieren, dessen Knoten Prozessschritte und dessen Kanten den Kontrollfluss darstellen. Beginnend mit der Auswahl einer Start-Aktivität wird dem entstehenden Baum jeweils eine weitere Aktivität hinzugefügt. Die Auswahl erfolgt unter Verwendung einer Bewertungsfunktion, die misst, ob der ausgewählte Knoten einen weiteren Beitrag zur Erzeugung des finalen Prozessoutputs liefert. Dieser Vorgang wird als Branch-Schritt bezeichnet und wird so oft durchgeführt bis das Hinzufügen eines weiteren Prozessschrittes zu keiner besseren Lösung führt. Der Bound-Schritt hat unterdessen die Aufgabe, bestimmte Zweige des Baumes mittels der Definition von Schranken "abzuschneiden". Dies bedeutet, dass diese in der weiteren Berechnung nicht mehr betrachten werden, um den Rechenaufwand zu begrenzen. Die Schranken werden auf Basis von Heuristiken festgelegt. • Des Weiteren gibt es genetische Algorithmen [HoVe01] [LeMR94] [RuLe95], die auch nicht analytisch lösbare Probleme behandeln können. Sie generieren wiederholt verschiedene „Lösungsvorschläge“ für die Prozessmodelle. Dies setzt voraus, dass zuvor alle möglichen Prozesselemente definiert wurden. Die bereits erstellten Lösungen werden immer wieder verändert, miteinander kombiniert und kontinuierlich METHODISCHE GRUNDLAGEN DES DESIGNS 3.2 67 einer Auslese unterzogen, so dass sich die Lösungsvorschläge den gestellten Anforderungen schrittweise annähern. Wie bereits beim Product Based Design findet auch bei den hier vorgestellten Algorithmen eine Vermischung von Design und Modellierung statt. Während die Definition der Algorithmen dem Design zuzuordnen ist, sind die Ergebnisse der Auflösung bzw. Anwendung als Modelle zu verstehen. Die Auflösung der Algorithmen sowie die Ergebnisse sind somit der Modellierungsphase zuzuordnen. Es gilt anzumerken, dass die Algorithmen in Bezug auf das Prozessdesign noch „in den Kinderschuhen“ stecken. So müssen sie bzgl. diverser prozessspezifischer Aspekte noch weiter entwickelt werden, wie zum Beispiel bzgl. der Berücksichtigung der Tatsache, dass ein Prozessschritt je nach Kontext unterschiedliche Outputs haben kann. Bewertung des Theoretischen Prozessdesigns Es handelt sich beim theoretischen Prozessdesign um eine sehr strukturierte und analytische Vorgehensweise, die zu eindeutigen und logisch nachvollziehbaren Ergebnissen führt. Fehler aufgrund von Mehrdeutigkeit einer Designlösung können vermieden werden. Üblicherweise sind die Methoden zuvor in anderen Bereichen außerhalb der Prozessdomäne bei ähnlichen Problemstellungen erfolgreich angewendet worden (so zum Beispiel im Bereich des Ingenieurwesens oder der Fertigung), ehe sie auch im Bereich des Prozessdesigns Einzug gehalten haben. Sie basieren somit auf erprobten Verfahren, die bereits mehrfach optimiert wurden; sie gehen gewissermaßen aus Best Practices hervor und beruhen auf Erfahrungswerten bzw. sind historisch validiert. Daher sind vor allem die Verfahren, aber auch die Ergebnisse oftmals stabiler bzw. verlässlicher als Methoden des pragmatischen Prozessdesigns. Zudem lassen sie sich jederzeit in Bezug auf einen neuen Anwendungsfall wiederverwenden. Doch muss berücksichtigt werden, dass die Umgebung, in der die Design-Artefakte schließlich angewendet, d.h. implementiert werden, aufgrund ihrer Unwägbarkeiten und fehlenden Planbarkeit sowie der kreativen Komponente der Prozessorientierung insgesamt nur schwer zu formalisieren ist [MaSc97] [HaCh93]. Die Ansätze sind aufgrund der Grundlagen und deren Historie gut aufgearbeitet und durchdacht, jedoch wird oftmals kritisiert, dass sie nur mit viel Aufwand umzusetzen und somit unpraktikabel sind [Reij03] [RLvA03]. Dem kann entgegen gehalten werden, dass zahlreiche Anwendungsfälle bekannt sind. Beispielhafte Berichte sind in [Reij03] und [RLvA03] zu finden. Es kann schwierig sein, die zu designenden Elemente und die dazugehörigen Kontextbedingungen so formal zu charakterisieren, wie es die theoretischen Methoden verlangen. Die Qualität eines Prozesses setzt sich zudem aus einer Vielzahl von Kriterien zusammen, die oftmals nur in Form eines Kompromisses zu erfüllen sind. Welcher Kompromiss der Beste ist, ist meist nur subjektiv, nicht jedoch formal zu beurteilen. 3.2 METHODISCHE GRUNDLAGEN DES DESIGNS 68 Der Hauptkritikpunkt an den Methoden des theoretischen Prozessdesigns besteht darin, dass keine klaren Grenzen zwischen Design und Modellierung getroffen werden. Die Ergebnisse des Designs werden nicht explizit bzw. separat als Konzept festgehalten, sondern werden vielmehr gleich in die eigentlichen Prozessmodelle integriert. Das Design bzgl. einer Modellierungssprache tritt somit in den Hintergrund. Die Strukturiertheit und Übersichtlichkeit der Vorgehensweise leidet darunter, das sofort die Vermischung mit/ die Anwendung auf einen konkreten Sachverhalt erfolgt. 3.2.3 Fazit zu den Grundlagen des Designs In Tabelle 3-4 ist eine Gegenüberstellung des pragmatischen und theoretischen Prozessdesigns an Hand ausgewählter Kriterien zu sehen. Die Auswahl der Kriterien hat sich aus der Analyse der beiden Ansätze ergeben. Die Ansätze unterschieden sich grundlegend in ihrem Ausgangspunkt, wodurch sich auch unterschiedliche Einsatzzeitpunkte im Verlauf des gesamten Prozesslebenszyklus ergeben. Beim pragmatischen Prozessdesign wird an existierenden Prozessen angesetzt, die an den identifizierten Schwachstellen überarbeitet werden. Demgegenüber startet der theoretische Ansatz „bei null“, weil entweder noch keine Prozesse definiert wurden oder der neue Prozess soweit wie möglich unvoreingenommen bzgl. bereits existierender Prozesse gestaltet werden soll. Die Unterscheidung in reaktives und aktives Vorgehen ist mit dem eben Gesagten bereits implizit gegeben. Eine Reaktion kann sich immer nur an etwas Vergangenem bzw. Vorhandenem orientieren, wie es beim pragmatischen Ansatz mit den existierenden Prozessen als Ausgangspunkt der Fall ist. Ausgelöst wird eine Reaktion stets durch einen sog. „Reiz“, was den wesentlichen Unterschied zu einer Aktion ausmacht [BiIn09]. Eine Aktion, das Handeln an sich, findet zudem meist innerhalb eines vorgegebenen Regelwerks nach einem bestimmten Ablaufplan statt [Funk03], was mit den Erläuterungen zum theoretischen Prozessdesign einhergeht. Formalisierung bedeutet die „Generalisierung einer (wissenschaftlichen) Aussage unter Absehung ihrer konkret-empirischen Bezüge“ [DeTV95]. Der Formalisierungsgrad der theoretischen Ansätze ist sehr hoch, während die pragmatischen Verfahren sehr stark auf Erfahrungswerten und somit empirischen Daten beruhen. Bei den Best Practices ist dies wohl am besten nachzuvollziehen. Der pragmatische Ansatz geht von existierenden Prozessen aus. Diese werden in den meisten Fällen nur an ausgewählten Stellen, d.h. lokal, überarbeitet. Beim theoretischen Prozessdesign muss der gesamte Prozess vom Grunde auf gestaltet werden, da der Anspruch besteht, auf einem „weißen Blatt Papier“ zu beginnen. Das Design kann dann als global bezeichnet werden. METHODISCHE GRUNDLAGEN DES DESIGNS 3.2 69 Im Hinblick auf den Aufwand ist festzustellen, dass beide Methoden, in ihrer Gesamtheit betrachtet, mit hohem Aufwand verbunden sind. Während beim theoretischen Prozessdesign als Ergebnis ein optimales Prozessdesign das Ziel ist, ist es beim pragmatischen Prozessdesign „nur“ ein verbessertes Design. Diese Formulierung darf jedoch auf keinen Fall missverstanden werden. Sie bedeutet nicht, dass die Qualität bei Letzterem schlechter zu bewerten ist. Verbessert bedeutet hier gewissermaßen „pareto-optimal“, d.h. ein besserer Zustand bzgl. eines bestimmten Aspektes ist nicht möglich, ohne zugleich einen anderen Aspekt schlechter zu stellen [Bont04]. Ob letztendlich das pragmatische oder das theoretische Design besser ist, wird in der Literatur vielfach diskutiert (siehe dazu zum Beispiel [OnSo99]). Beide Ansätze haben ihren jeweiligen Einsatzzweck bzw. – zeitpunkt und jeweils ihren Berechtigungsgrund. Sie ergänzen sich gegenseitig und stehen in Wechselwirkung zueinander, wie es zum Beispiel auch [ReNV07] vertreten. Es muss also gemäß dem individuellen Kontext entschieden werden, welche Ausrichtung gewählt wird. pragmatisch theoretisch Ausgangspunkt existierende Prozesse „weißes Blatt Papier“ Einsatzzeitpunkt bzgl. Prozesslebenszyklus nach den ersten Umläufen im Prozesslebenszyklus vor der ersten Instanziierung des Prozesses oder nach mehreren Prozesslebenszyklusdurchläufen Vorgehen reaktiv aktiv Formalisierungsgrad gering hoch Scope/ Umfang des Anwendungsbereichs lokal: Optimierung einzelner Stellen des Gesamtprozesses global: Gestaltung des Gesamtprozesses Aufwand hoch hoch Angestrebte Ergebnisqualität verbessertes Prozessdesign optimales Prozessdesign Tabelle 3-4 Gegenüberstellung pragmatisches und theoretisches Prozessdesign Es ist festzuhalten, dass bei den vorgestellten Ansätzen mit dem Ergebnis des Prozessdesigns meist schon die wirklichen Prozessmodelle betrachtet werden, die einen realen Sachverhalt abbilden. Dies widerspricht den Definitionen aus Kapitel 3.1.1 und 3.1.3 bzgl. Design und Modellierung, die eine Trennung von Design und Modellierung vorsehen, und ist daher als ein elementare Kritikpunkt zu betrachten. Das Ergebnis des Designs ist die rein 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 70 konzeptionelle Modellgestaltung, auf welcher der eigentliche Modellierungsvorgang dann aufbauen kann. Mit dieser Kritik geht einher, dass sich beide Design-Ansätze darauf beschränken, die Prozesselemente (pareto-) optimal in einem Prozessmodell anzuordnen. Damit bewegen sich die Verantwortlichen in dem von den Modellierungssprachen gegebenen Handlungsspielraum, der sich auf die reine Verwendung der bereits vorhandenen Aspekte, Konstrukte oder Methodiken beschränkt, während eine Neudefinition nicht vorgenommen wird. Auch die verschiedenen Studien haben dieses Verhalten aufgezeigt (siehe Kapitel 2.3.2). Somit unterstreichen die Beschreibungen der verschiedenen Designmethoden die bereits geäußerte Kritik, dass das Design nicht in seinem vollen Maße ausgenutzt wird, was angesichts der Vermischung von Design und Modellierung auch nur sehr schwer möglich ist. Um die Problemstellungen des Designs an der Wurzel zu packen, muss sich der für das Design Verantwortliche jedoch gegebenenfalls auch mit den einzelnen Elementen der Modellierungssprachen und deren Spezifikation auseinandersetzen. Dabei geht es um die Frage, ob alle notwendigen Elemente für das gewünschte Prozessmodell überhaupt vorhanden sind, ob sie den gewünschten Sachverhalt richtig und unmissverständlich abbilden und ob ihre Einbindung in das Prozessmodell korrekt ist. Danach ist zu entscheiden, ob eine existierende Sprache bzw. Standardsprache verwendet werden kann oder nicht doch eine anwendungsbezogene, die gegebenenfalls erst definiert werden muss. Ist Letzteres der Fall, sind die damit verbundenen Aufgaben klar dem Design zuzuordnen. 3.3 Methodische Grundlagen der Modellierung Es existiert eine Vielzahl von Modellierungssprachen, die zum Teil sehr unterschiedliche Anforderungen abdecken [AmSo07] [Sinu04] [SoWa07]. Da in den Organisationen die Standardmodellierungssprachen und ihre reine Anwendung im Vordergrund stehen, soll auf den Aspekt der Definition einer (anwendungsbezogenen) Modellierungssprache, die MetaModellierung, eingegangen werden. Das Kapitel gliedert sich demnach folgendermaßen: • Modellierungssprachen • Standardvs. anwendungsbezogene Modellierungssprachen • Meta-Modellierung 3.3.1 Modellierungssprachen Es wird ein Überblick über allgemein bekannte sowie über eine lehrstuhleigene Modellierungssprachen gegeben. METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 71 3.3.1.1 Unified Modeling Language (UML) Die Unified Modeling Language (UML) [OMG11e] [RaJB04] ist eine universelle, auf die Spezifikation und Dokumentation von Softwareentwicklung ausgerichtete, graphische, objektorientierte Modellierungssprache, die von der Object Management Group (OMG) standardisiert wurde. Neben ihrem ursprünglichen Einsatzzweck zur Softwareentwicklung wird die UML auch für die Prozessmodellierung eingesetzt. Von den vierzehn verschiedenen Diagrammtypen, die an und für sich sehr heterogen sind, sich jedoch sprachlich und inhaltlich überlappen [Tesc03], werden dazu insbesondere die Aktivitätsdiagramme (siehe Abbildung 3-5) verwendet. Abbildung 3-5 Beispiel UML-Aktivitätsdiagramm Mit einem Aktivitätsdiagramm werden Arbeitsabläufe bzw. Workflows mittels elementaren Aktivitäten beschrieben. Ein Beispielprozess ist in Abbildung 3-5 zu sehen. Dabei werden folgende Knoten über Kontrollund Objektflüsse sequentiell hintereinander geschaltet: 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 78 Sie dürfen nicht in den Kontrollfluss integriert werden. Die in Kapitel 3.1.1 eingeführten Aufgaben des Designs können also nicht vollständig realisiert werden. Die Studien von [RIRG06] und [Reck10] zeigen Schwachstellen der Modellierungssprache auf. Unter anderem können mit BPMN keine Zustände, sondern nur Aktivitäten und Ereignisse dargestellt werden. Sachverhalte können mit verschiedenen Modellierungskonstrukten dargestellt werden, da diese semantisch nicht eindeutig definiert sind. So können Rollen mit „Pools“ und „Lanes“ modelliert werden. Die beiden Konstrukte „Pools“ und „Lanes“ sind mit mehrfachen Bedeutungen überladen und können somit nicht eindeutig verwendet werden. Es gibt eine sehr differenzierte Menge an „Events“ mit jeweils spezifischer Bedeutung. Angesicht der Menge von Events ist jedoch Erklärungsbzw. erhöhter Einarbeitungsbedarf vorhanden [Allw10]. BPMN dient vor allem der Modellierung von Geschäftsprozessen auf konzeptioneller Ebene. Für Modelle, die direkt mittels einer Workflow Engine ausgeführt werden sollen, bietet sich BPMN weniger gut an, was jedoch auch nicht das primäre Ziel war bzw. ist [tHAA10] [Whit04]. Dies zeigt sich auch in dem dafür zusätzlich notwendigen Modelltransformationsschritt, der einen zusätzlichen Aufwand erfordert. Trotz der genannten Kritikpunkte wird der Standard BPMN immer häufiger bei den Modellierungsprojekten der Organisationen verwendet [Allw10]. Die Gründe dafür liegen zum einen in der Standardisierung, die ein verlässliches Rahmenwerk vorgibt, aber wohl auch an der fehlenden Konkurrenz. 3.3.1.4 Aspektorientierte Prozessmodellierung Die aspektorientierte Modellierung (AOPM, oder engl. POPM = Perspective Oriented Process Modeling) wurde im Rahmen des MOBILE Projekts [Mobi00] an der Friedrich-AlexanderUniversität Erlangen-Nürnberg entwickelt. Dabei standen zunächst primär die Modellierung von Workflows im Vordergrund und weniger die im Rahmen dieser Arbeit fokussierten Geschäftsprozesse. Das grundlegende Konzept für dieses Projekt wurde erstmals in [Jabl94] vorgestellt, sowie in [Jabl95] und [JaBu96] ausführlich beschrieben. Es gibt sowohl eine textuelle, als auch eine graphische Spezifikation dieser Modellierungssprache [Jabl01], wobei Letztere im Folgenden im Fokus stehen soll. Basierend auf den Projekterfahrungen (u.a. [Horn03]) wurde von der Firma Prodato das Prozessmodellierungswerkzeug i>pm (= Integrated Process Modeler) [Prod05] entwickelt. Dieses adaptiert das Konzept der aspektorientierten Workflow-Modellierung für Anwendungsprozesse und kann somit auch für die Modellierung von Geschäftsprozessen verwendet werden. Inzwischen gibt es mit OMME (Open Meta Modeling Environment, [VoJa10a] [VoJa10b]) einen ersten Prototypen einer grundlegend überarbeiteten Version des Modellierungswerkzeuges (mehr Informationen folgen im weiteren Verlauf der Arbeit). METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 79 Die Grundidee vom AOPM ist, dass ein Modellierungskonstrukt aus verschiedenen, voneinander unabhängigen, orthogonalen Teilen besteht. Diese verschiedenen Aspekte ermöglichen eine umfassende Beschreibung des Modellierungsgegenstandes. Bei einem konkreten Anwendungsfall müssen jedoch nicht zwingend alle definierten Aspekte verwendet werden. Konzeptionell ist die Anzahl der Aspekte beliebig; es können jederzeit neue Aspekte hinzugefügt werden. Ebenso können die Aspekte an sich jederzeit erweitert werden. Die Basis für diese Erweiterungen bildet die der Methode zugrunde gelegte Meta-Modell-Hierarchie nach [AkKü05], [HeGo06] und [JaVD09]. Eine weitere wesentliche Eigenschaft dieser Modellierungssprache ist das sog. TypVerwendungskonzept. Dies bedeutet, dass ein Modellierungskonstrukt einmalig definiert wird (= Typ) und dann beliebig oft in dem zu erstellenden Prozessmodell wiederverwendet werden kann (= Verwendung). So wird zum Beispiel zunächst der Daten-Typ „Untersuchungsplan“ einmal definiert und dann im Beispielprozess in Abbildung 3-8 dreimal verwendet. Abbildung 3-8 Beispiel AOPM-Modell Nach [JaBu96] werden zumeist die folgenden Aspekte bei der Prozessmodellierung verwendet: • Funktionaler Aspekt: Zur Festlegung einer grundlegenden Struktur werden Prozesse und Unterprozesse definiert. Kann ein Prozess nicht mehr in weitere Teilprozesse aufgegliedert werden, handelt es sich um einen elementaren Prozess; andernfalls spricht man von einem kompositen Prozess. 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 80 • Verhaltensbezogener Aspekt: Die einzelnen Prozesse werden mittels Kontrollfluss in eine Reihenfolge gebracht. Der Kontrollfluss kann linear oder verzweigt sein, parallel oder alternativ erfolgen. • Organisatorischer Aspekt: Es wird festgelegt, wer für die Ausführung eines Schrittes verantwortlich ist, wobei lediglich neutrale Rollen definiert werden, statt konkrete Personen anzugeben (siehe Details dazu in [Buss98], [JaTa09] und [TaVJ10]). • Operationaler Aspekt: Es wird angegeben, mit Hilfe welcher Werkzeuge und Systeme die eigentliche Funktionalität erbracht wird, ob zum Beispiel mit Microsoft Word und Excel oder speziellen medizinischen Geräten. • Datenorientierter Aspekt: Dieser Aspekt beschreibt den Datenfluss von einem Prozessschritt zum nächsten. Ein Datenfluss entsteht dabei durch eine Output-InputBeziehung zwischen zwei Prozessen. Während der eine Prozessschritt das Datum produziert, konsumiert der nachfolgende Prozessschritt dieses Datum. Als weitere Aspekte sind der historische [Schl04], der qualitätssowie der sicherheitsbezogene Aspekt [JaBu96] zu nennen. Bewertung Die AOPM definiert grundlegende Konstrukte zur Modellierung von Geschäftswie auch Workflowprozessen. Durch die begrenzte Anzahl an leicht interpretierbaren Modellierungskonstrukten in der Grundversion von AOPM (domänenspezifische Konstrukte sind dabei nicht mit eingeschlossen) ist die Sprache für den Anwender leicht zu erlernen. Alle wichtigen Konstrukte und Eigenschaften sind spezifiziert, wodurch die Sprache sehr mächtig ist. Durch die Definition der verschiedenen Aspekte und die Zuordnung der Konstrukte zu diesen, ist eine klare Strukturierung der Modellierungssprache wie auch der damit erstellten Modelle möglich. Aufgrund der aspektorientierten Komposition und der damit verbundenen Modularisierung ist zudem ein hohes Maß an Flexibilität der Modellierungssprache vorhanden. Es kann eine beliebige Anzahl an Aspekten definiert werden, die auf der einen Seite unabhängig voneinander sind, sich auf der anderen Seite jedoch gegenseitig ergänzen. Durch die jederzeit mögliche Erweiterung um zusätzliche Konstrukte, Attribute und/ oder Aspekte kann die AOPM leicht individuell an spezielle Domänen angepasst werden. So existieren inzwischen mit den Versionen i>PM4Med bzw. i>PM4QM Anpassungen für die medizinische Domäne bzw. für die Aspekte des Qualitätsmanagements. Die in Kapitel 3.1.1 für das Design erläuterten Handlungsmöglichkeiten können bei AOPM vollständig umgesetzt werden. Dies ist ein entscheidender Vorteil gegenüber den in den vorherigen Kapiteln vorgestellten Modellierungssprachen. METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 81 Das Prinzip der Wiederverwendung in Form des Typ-Verwendungskonzepts ist als eine herausragende Eigenschaft dieser Modellierungssprache zu bewerten. Es trägt beim Modellierungsvorgang wesentlich zur Effizienzsteigerung bei, aber auch zur Reduktion von Fehlern bei der Modellierung. 3.3.2 Standardvs. Anwendungsbezogene Modellierungssprachen Wie in den Ausführung in Kapitel 3.3.1 zu sehen war, kann grundlegend zwischen Standardsprachen, wie BPMN, und anwendungsbezogenen Sprachen, zum Beispiel AOPM, unterschieden werden. Der wesentliche Unterschied besteht darin, dass Letztere individuell für einen konkreten Anwendungsbereichbzw. fall erstellt sind. Wie diffizil allein diese Entscheidung bereits ohne konkret vorliegenden Anwendungsfall ist, zeigt folgender Abschnitt. 3.3.2.1 Standardmodellierungssprache Vorteile Für die Standardmodellierungssprachen spricht ihre Allgemeingültigkeit bzw. Generizität. Da diese nicht die Charakteristika einer speziellen Anwendungsdomäne berücksichtigen, sind sie so allgemein definiert, dass sie die bei den meisten Anwendungsfällen vorzufindenden Eigenschaften und Aspekte generisch abdecken [FiHR08] [Meil05] [Wats08] und einen großen Freiheitsgrad bei der Modellierung bieten [Allw06]. So kann zum Beispiel die Standardmodellierungssprache BPMN für die Modellierung von Geschäftsprozessen eines Industrieunternehmens verwendet werden, aber ebenso zur Modellierung klinischer Pfade (= medizinischer Prozesse). Anwendungsbezogene Modellierungssprachen können zwar auch derart verwendet werden. Dies kann jedoch dazu führen, dass Modellierungselemente nicht in ihrem eigentlichen Sinne verwendet werden, so dass die Eindeutigkeit der Sprache leidet. In einem Abstimmungsprozess zwischen den Verantwortlichen und möglichen Anwendern der Standardmodellierungssprache werden allgemeingültige Sprachelemente und eine allgemeingültige Terminologie definiert [DeIN10] [GrKo05]. Damit sind Standardsprachen für den normalen Anwender üblicherweise leichter zu verstehen (allgemeine Verständlichkeit), weil kein spezielles domänenspezifisches Wissen zum Verständnis nötig ist. Die Modelle können somit als Basis zur Kommunikation zwischen den verschiedenen Stakeholdern (dies sind Manager des Unternehmens, Interessenten anderer Organisationen oder auch Kunden) verwendet werden [SmFi03], die keine ausgewiesenen Kenntnisse im Bereich der Modellierung besitzen oder wenn es bei der Kommunikation um domänenübergeordnete Aspekte, wie zum Beispiel strategische Entscheidung innerhalb einer Organisation geht. Der Aspekt der besseren Verständlichkeit gilt jedoch nicht uneingeschränkt. Zum Zweck der Standardisierung muss teils auch in solchem Ausmaß abstrahiert werden, dass der Anwender keinen direkten Zugang mehr zu der Sprache bzw. dem damit dargestellten Sachverhalt findet [ClSW08] [Jabl09] [Wats08]. 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 82 Die Standardmodellierungssprachen sind oftmals kompatibel und können von verschiedenen (Modellierungs-) Systemen interpretiert werden (Interoperabilität bzw. Probabilität), so dass sie vielseitig einsetzbar sind [DeIN10] [GrRe93] [Jabl09] [VoZe09] [Wats08]. Die Wiederverwendbarkeit erspart Aufwand bzgl. Schnittstellenbeschreibungen und Konvertierungstools sowie bzgl. der Entwicklungen von Individuallösungen. Es hat zudem auch eine positive Auswirkung auf den Bekanntheitsgrad einer Modellierungssprache. Die Standardmodellierungssprache BPMN wird zum Beispiel von den Modellierungswerkzeugen ARIS Toolset, dem Interstage Business Process Manager 7.1 (Fujitsu), Signavio Process Editor (Signavio GmbH) sowie SAP NetWeaver Composition Environment (SAP) implementiert; aktuell gibt es 71 Lösungen [OMG11b]. Da Standards prinzipiell einen höheren Bekanntheitsgrad haben als domänenspezifische Sprachen, fallen die Kosten der Einarbeitung geringer aus oder entfallen sogar komplett [Wats08]. Dieser Zusammenhang ist damit zu erklären, dass durch den Bekanntheitsgrad viele potentielle Anwender bereits Kenntnisse über die Sprache haben, so dass der zusätzliche Schulungsaufwand und folglich die Kosten geringer ausfallen. Aus Sicht des Anwenders entfallen zudem die Kosten für die Entwicklung solcher Sprachen. Diese tragen die für die Entwicklung und Pflege der Standards zuständigen Organisationen, wie zum Beispiel inzwischen die Object Management Group OMG für BPMN. Offene Standards werden auch ohne Lizenzgebühr angeboten [SmFi03]. Die Verantwortung für die Entwicklung und Pflege der Standards ist klar definiert und liegt in den Händen einer einzigen verantwortlichen Organisation. Damit können Unstimmigkeiten durch verschiedene Entwicklungsgruppen vermieden werden. So wird BPMN wie bereits erwähnt seit 2005 von der Object Management Group gepflegt. Zudem nimmt diese Organisation dann auch den hohen Kostenund Zeitaufwand der Entwicklung und Pflege auf sich, wovon gerade kleinere Organisation mit geringen finanziellen Mitteln profitieren. Standardsprachen bieten sich als Basis zur Entwicklung domänenspezifischer Sprachen an [GiGW00]. Sie bilden die Grundlage für die Ergänzung um spezielle Aspekte. Damit ergänzen sich Standardund domänenspezifische Sprachen und es zeigt sich hier sehr deutlich, dass beide Ansätze ihren Sinn und ihre Berechtigung haben. Nachteile Bemängelt wird unter anderem, dass Standardmodellierungssprachen inhaltlich oftmals nicht vollständig sind [GrKo05] [Jabl09] [RIRG06]. Aufgrund ihrer Allgemeingültigkeit und Generizität können die Sprachen nicht alle Facetten der möglichen Anwendungsfälle abdecken [GrKo05] [Meil05] [Müll90]. So konnten zum Beispiel konkret für BPMN empirische Untersuchungen das Fehlen von wesentlichen Aspekten aufdecken. Dort fehlt es unter anderem an Möglichkeiten zur Darstellung der Struktur eines Systems [RIRG06] sowie von Geschäftsregeln (= business rules) [Reck10]. METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 83 Im Bewusstsein des Problems der mangelnden Vollständigkeit, wird versucht, möglichst viele Aspekte in einen Standard zu integrieren. Dies führt jedoch unweigerlich dazu, dass sich die Anzahl der Konstrukte und Funktionalitäten und damit der Umfang der Standards erhöht und diese inhaltlich wie funktional überladen sind. Die Produktivität der Modellierung leidet dabei und die Sprachen werden unhandlich. So ist für BPMN eine Vielzahl verschiedener sog. „Events“ definiert (siehe Anhang B). Wie auch in [RIRG06] und [Reck10] bestätigt werden konnte, ist es leicht nachvollziehbar, dass ein Anwender von den zur Verfügung stehenden Möglichkeiten erschlagen ist, auch wenn jedes der Konstrukte für sich verständlich ist. Durch die damit angestrebte Vollständigkeit geht im Bezug auf die einzelnen Elemente jedoch die mit Standardmodellierungssprachen angestrebte Generizität verloren. Da die Spezifikation der Standardmodellierungssprache allgemeingültig gehalten ist [Meil05] [Müll90], leidet oftmals die Präzision der Sprache. Dies führt zum Verlust der Mächtigkeit bzw. wie [ClSW08] es formuliert: “any gain made in widening the applicability of a language to different domains will be at the expense of the richness of the language that makes it so suitable for a particular domain”. Eine kompakte, fachspezifische Formulierung eines Sachverhaltes ist nicht möglich [DSMF10] [FiHR08] [FrvL03]. Die domänenspezifischen Anforderungen an eine Sprache sind jedoch zum Teil so gegensätzlich, dass sie nur schwer allgemeingültig „unter einen Hut“ gebracht werden können [ClSW08] [Jabl09]. Die Konstrukte Lane und Pool sind in BPMN sehr undifferenziert definiert und somit ihr konkreter Einsatzzweck für den Anwender nur schwer ersichtlich oder sogar missverständlich [Reck10]. Eng verbunden mit der allgemeingültig gehaltenen Definition sind Standardmodellierungssprachen nicht an die Erfordernisse einer speziellen Anwendungsdomäne angepasst und daher dann bei anwendungsbezogenen Fällen nur eingeschränkt anwendbar [FrvL03] [Meil05] [Müll90]. Es fehlen die Konstrukte oder dazugehörige Attribute zur Darstellungen gewisser Aspekte eines speziellen, aber in dem vorliegenden Fall essentiellen Sachverhaltes. Beispielhaft zu nennen wäre hier die Angabe einer Kosten-Kennzahl an einem Prozessschritt. Die Standardisierung stellt einen sehr langwierigen, zeitund kostenintensiven Prozess dar, wie auch die sich anschließende Pflege, um den Standard immer aktuell zu halten bzw. mögliche Verbesserungen einzubringen [ClSW08]. Wenn es sich nicht um einen offenen Standard handelt, fallen für den Anwender Lizenzkosten an, die im kommerziellen Bereich meist sehr hoch sind [GrKo05]. 3.3.2.2 Anwendungsbezogene Modellierungssprachen Vorteile Im Bezug auf das genau abzugrenzende Anwendungsgebiet bzw. den Einsatzzweck haben die anwendungsbezogenen Modellierungssprachen durch die speziellen Konstrukte und deren Funktionalitäten eine hohe Ausdrucksmächtigkeit [Allw06] [FiHR08] [MeHS05] [vDKV00]. 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 84 Der abzubildende Sachverhalt kann sehr präzise sowie eindeutig modelliert werden [FiHR08] [Wats08]. Dies wirkt sich positiv auf die Produktivität des Modellierungsvorgangs aus [MeHS05] [ToKe04] [vDKV00], da Diskussionen darüber, wie ein Sachverhalt eindeutig dargestellt oder in der Modelldarstellung verstanden werden kann, erheblich reduziert werden können. Da mit der Verwendung einer anwendungsbezogenen Modellierungssprache eine genauere Abbildung des Anwendungsbereichs gemäß den gestellten Anforderungen möglich ist [FiHR08] [LPZE07], erhöht sich damit prinzipiell (jedoch nicht automatisch) die Qualität der damit erstellten Modelle [ToKe04]. So wurde für AOPM der sog. „Evidenzbasierte Entscheider“ entwickelt [Meil05]. Er dient der Repräsentation evidenzbasierter medizinischer Entscheidungen in Klinischen Pfaden. Diese müssen nicht als Einzelentscheidungen modelliert werden, sondern können über das domänenspezifische Konstrukt zusammengefasst werden. Dabei kann das Konstrukt eine Reihe von Kriterien abbilden, auf denen die Entscheidung beruht. Die anwendungsbezogenen Modellierungssprachen sind mit Konstrukten und speziellen Eigenschaften und Funktionen nicht überladen [ToKe04] [LPZE07]. Es wird nur das spezifiziert, was für die abgegrenzte Anwendungsdomäne relevant ist. Eine Kapselung der Komplexität wird durch den der Domäne entsprechenden Abstraktionsgrad möglich [ToKe04] [DSMF10]. Denn jede Domäne hat ihre eigenen, individuellen Konzepte und Abstraktionsprinzipien [ToKe04]. Ein Beispiel wäre auch hier der Evidenzbasierte Entscheider [Meil05], der eine Vielzahl von medizinischen Einzelentscheidungen und deren Entscheidungskriterien in einem Konstrukt zusammenfasst. Domänenspezifische Sprachen stellen oftmals eine Weiterentwicklung von Standards dar [GiGW00] [ToKe04] [Wats08]. Damit reduziert sich die zeitund kostenintensive Grundlagenentwicklung. Es kann direkt mit der Konzeption und Ausarbeitung der erweiterten anwendungsbezogenen Aspekte begonnen werden, wobei auch dies im Bezug auf den Aufwand nicht unterschätzt werden darf [Wats08]. Ein Beispiel wäre die anwendungsbezogene Erweiterung der UML über sog. profiles, die aus Stereotypen und Importpaketen definiert werden [OMG11e]. Ein profile ist eine Erweiterung des UML2Metamodells und wird für spezielle Anwendungsdomänen erstellt. Auch die Ereignisgesteuerten Prozessketten (EPK) können hier als Beispiel genannt werden, auch wenn es sich nicht um einen offiziell verabschiedeten Standard handelt. Allgemein anerkannt wird diese Modellierungssprache im wissenschaftlichen Bereich zum Beispiel erweitert für den Aspekt der Konfiguration zur c-EPC (configurable Event driven Process Chain). Näheres dazu ist in [LaRo08] oder [LLSD07] zu finden. In der Version 2.0 ist nun auch der Standard BPMN individuell erweiterbar. Bis zu einem gewissen Grad geht damit der Vorteil einer Standardmodellierungssprache verloren, was jedoch durch die Vorteile der individuellen Anpassung ausgeglichen werden kann. Die anwendungsbezogenen Modellierungssprachen sind dadurch gekennzeichnet, dass ihre Konzepte und Symbole direkt mit Begriffen bzw. der Semantik korrespondieren, die dem Anwender vertraut sind [FrvL03] [ToKe04]. Die Modelle sind für den Anwender somit METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 85 leicht(er) verständlich, da sie in seiner „(fachlichen) Muttersprache“ verfasst sind [ToKe04] [vDKV00]. Nachteile Die Entwicklung einer anwendungsbezogenen Sprache ist mit einem hohen Zeitund Kostenaufwand für die Verantwortlichen verbunden, auch wenn als Grundlage eine bereits ausgearbeitete Standardsprache verwendet werden kann (die Entwicklung einer solchen ist ebenfalls mit einem hohen Entwicklungsaufwand verbunden, wie es bei den ContraArgumenten der Standardsprachen zu lesen war). Zur Entwicklung einer domänenspezifischen Modellierungssprache sind sowohl Kenntnisse bzgl. der Entwicklung einer Sprache sowie spezielles domänenspezifisches Wissen notwendig [LPZE07] [MeHS05]. Da für die Anwendung der anwendungsbezogenen Sprache auch das entsprechende Fachwissen notwendig ist, müssen die Anwender explizit in diese Modellierungsmethoden eingeführt werden, was mit zusätzlichem Aufwand hinsichtlich Zeit und Kosten (nicht direkt im Rahmen der Entwicklung, aber im Anschluss daran) verbunden ist. Die Anwendbarkeit einer anwendungsbezogenen Modellierungssprache ist auf die entsprechende Domäne begrenzt [vDKV00]. Es können die typischen Aufgaben aus der entsprechenden Domäne gelöst werden [LPZE07]. Die Lösungen können jedoch nicht auf Probleme in anderen Domänen übertragen werden. So ist i<pm4med speziell auf den medizinischen Kontext abgestimmt. Wie bereits mehrfach erwähnt, wurde der sog. „Evidenzbasierte Entscheider“ [Meil05] als zusätzliches Modellierungskonstrukt konzipiert. Die Erfahrung hat gezeigt, dass sich dieses Konstrukt zur Modellierung komplexer Entscheidungen in anderen Domänen nur ungenügend verwenden lässt. Ein Ansatz zur Problemlösung wäre, das Element bei der Verwendung außerhalb der dazugehörigen Domäne „wegzulassen“. Dann sollte das spezielle Konstrukt aber komplett für den Anwender verborgen sein und nicht nur von der Verwendung ausgeschlossen werden, um den Anwender mit möglichst wenig Konstrukten zu konfrontieren. Oftmals ist dieses „Weglassen“ jedoch mit zusätzlichen Implementierungsschritten an dem Modellierungswerkzeug verbunden, die Zeit kosten und zusätzliche Ressourcen beanspruchen. Für Nicht-Domänenexperten sind die domänenspezifischen Sprachen und die dazugehörigen Modelle schwerverständlich, da ihnen das dazu nötige Wissen fehlt. Sie können zum einen den anwendungsbezogenen Modellinhalt an sich nur schwer verstehen, zum anderen auch die Darstellungsform, die sich am Abstraktionsverständnis der Domäne orientiert. Dies kann gerade bei (strategischen) Entscheidungen, an denen die Nicht-Domänenexperten beteiligt sind, negative Konsequenzen haben, da sich die entscheidungsrelevanten Informationen möglicherweise nicht vermittelt lassen. Es müssen also entsprechende Erklärungen gegeben werden oder eine für die Nicht-Domänenexperten verständliche Darstellungsform zusätzlich erstellt werden. Beides ist mit zusätzlichem Aufwand verbunden und kann zudem schnell zu Missverständnissen führen. Dies ist eindeutig als ein Nachteil der domänenspezifischen Sprachen anzusehen. 3.3 METHODISCHE GRUNDLAGEN DER MODELLIERUNG 86 3.3.3 Meta-Modellierung Metamodelle dienen, stark vereinfacht, der strukturierten Beschreibung anderer Modelle (letztere dienen der Abbildung von Systemen, Objekten oder einem Ausschnitt aus der Realität) [GeKP98]. Oft werden sie auch als „model of a modeling language“ [Seid03] bezeichnet. Ein Modell kann somit nur in Verbindung mit einem weiteren Modell als Metamodell betrachtet werden [Hars94], wodurch stets eine Kontextabhängigkeit geben ist. Die Vorgabe elementarer Modellierungskonstrukte hat das Ziel die verschiedenen Modellierungsprojekte zu vereinheitlichen. Auch im Kontext der Prozessmodellierung erfolgt über die Metamodelle die Definition der Prozessmodellierungssprachen, die dann zur Erstellung von Prozessmodellen verwendet werden. Die Object Management Group (OMG) [OMG11c] hat einen Standard für die Verwaltung von Metamodellen veröffentlicht. Die sog. Meta Object Facility (MOF) [OMG11e] definiert ein Rahmenwerk zur Verwaltung von Metamodellen. [AkKü01], [AkKü05] und [HeGo06] haben dies entsprechend aufgenommen und weiterentwickelt (für eine kurze Beschreibung weiterer Ansätze sei auf [[KaKü02]] verwiesen). Es erfolgt die Definition einer mehrschichtigen, logischen Architektur, bei der jede Schicht eine bestimmte Art von Modellen aufnimmt. Die damit entstehende (Meta-) Modell-Hierarchie umfasst die Definition von Prozessmodellierungssprachen, Prozessmodellen sowie ausführbaren Instanzen dieser Prozessmodelle. Sie stellt dar, wie Anwender über die Definition von Prozessmodellierungssprachen und die Erstellung von Prozessmodellen letztendlich zu Prozessinstanzen gelangen (siehe dazu auch [KaKü02]). Abbildung 3-9 Meta-Modell-Hierarchie zu AOPM [JaVD09] METHODISCHE GRUNDLAGEN DER MODELLIERUNG 3.3 87 In Abbildung 3-9 ist eine Übersicht über die (Meta-) Modellhierarchie zu sehen; die Ebenen sind mit M3, M2, M1 und M0 bezeichnet. Jede der Ebenen ist als Instanz der höheren Ebene zu verstehen; die Ebenen sind also nicht unabhängig voneinander zu sehen. Der einfacheren Darstellung wegen wird die Diskussion der Meta-Modell-Hierarchie nicht chronologisch gemäß Abbildung 3-9 durchgeführt, sondern sie beginnt mit Ebene M1. Es handelt sich dabei exemplarisch um die Meta-Model-Hierarchie zu AOPM [JaVD09], da AOPM bei den im Rahmen dieser Arbeit verwendeten Use Cases verwendet wurde und die entwickelten Konzepte darauf aufbauen. M1Prozess Modelle Diese Ebene beinhaltet Prozessmodelle, welche für ein bestimmtes Anwendungsszenario in einer Organisation oder für die Konzeption einer Anwendung, definiert worden sind. Dazu kann prinzipiell jede beliebige Modellierungssprache verwendet werden. Für Beispiele bzgl. AOPM sei auf die Prozessabbildungen in Kapitel 2.2 verwiesen. Gemäß dem sogenannten „Typ-Verwendungskonzept“ werden hier zunächst Prozesstypen definiert, die in eine Typ-Bibliothek gestellt werden. Neben Prozesstypen können auch Datentypen, Organisationstypen und weitere Bestandteile eines Prozessmodells definiert werden. Die verschiedenen Typen werden schließlich zur Erstellung von Prozessmodellen "verwendet", d.h. modelliert. Der Prozesstyp „Untersuchung durchführen“ beschreibt zum Beispiel allgemein wie ein Arzt eine Untersuchung durchzuführen hat, ohne dabei einen direkten Bezug zu einer Instanz, wie zum Beispiel Herrn Müller als Patient oder Dr. Mayer als behandelnden Arzt, zu haben. Bei der Erstellung des Prozessmodells müssen außerdem Richtlinien für eine ordnungsgemäße Modellierung [BeRS95] [Rose96] eingehalten werden, um eine konsistente und korrekte Modellierung zu garantieren. Eine denkbare Regel für einen medizinischen Prozess wäre die Vorgabe, dass jedem Prozessschritt eine medizinische Rolle (Arzt, Krankenschwester, …) zugeordnet werden muss. Prinzipiell gilt, dass in den Prozessmodellen nur das abgebildet werden kann, was die Eigenschaften und Funktionen der verwendeten Modellierungssprachen beinhaltet. M2 - Prozessmodellierungssprache Bei der Definition der Prozesse auf Ebene M1 kommt eine entsprechende Prozessmodellierungssprache zum Einsatz. Während im Rahmen dieser Arbeit exemplarisch AOPM verwendet wird, könnte ebenso UML oder BPMN verwendet werden. Die Modellierungssprachen, inklusive aller Modellierungskonstrukte und dazugehörigen Eigenschaften sowie Modellierungsregeln, gilt es auf dieser Ebene zu definiert. M2 ist dazu in zwei Bereiche unterteilt. • Abstract Process Meta Model APMM: Zum einen wird eine Basissprache zur Verfügung gestellt, welche das grundlegende Modellierungskonzept wie zum Beispiel 3.4 FAZIT 94 ÜBERSICHT ÜBER DIE PROJEKTE 4.1 95 Kapitel 4 Design und Modellierung – Anforderungen Die Spezifikation der Anforderungen im Rahmen des Designs stellt einen ebenso wichtigen wie auch schwierigen Schritt dar [DaSh90] [Ehrl07] [VeCo94]. Dabei kann es um die Entwicklung eines Informationssystems gehen [VeCo94] oder um die Herstellung eines physischen Produktes in der Produktentwicklung [Ehrl07] [PaBe97]. Auf Basis der Anforderungen wird ein Modell des zu gestaltenden Objektes entwickelt, das dann in die Realität umgesetzt wird. Dies kann die informationstechnisch unterstützte Ausführung eines Prozessmodell oder, im Bezug auf die Produktentwicklung, ein konkretes Produkt, wie zum Beispiel ein geschliffenes Metallteil mit bestimmten geometrischen Abmessungen beinhalten. In diesem Kapitel werden Problemfälle und Anforderungen aus drei (Modellierungs-) Projekten des Lehrstuhls für Angewandte Informatik IV an der Universität Bayreuth erläutert. Es wird gezeigt, wie die Anforderungen derzeit umgesetzt werden; dazu werden beispielhaft die in Kapitel 3.3.1 eingeführten Modellierungssprachen herangezogen. Darüber hinaus wird aufgezeigt welche Verbesserungsmöglichkeiten es geben könnte. 4.1 Übersicht über die Projekte Um die späteren Ausführungen besser verstehen zu können, wird mit einer kurzen Beschreibung der Projekte begonnen. • Projekte 1 – Produktentwicklungsprozesse Im Rahmen des von der Bayerischen Forschungsstiftung geförderten Forschungsverbunds „FORFLOW“ ( [MePa06], [MePa08]) galt es einen sog. Prozessnavigator zur Prozessund Workflowunterstützung von Produktentwicklungsprozessen zu erforschen, zu entwickeln und prototypisch umzusetzen. Die Grundlage für die Unterstützung bildete die Generierung eines umfassenden Prozessmodells, das alle für den Produktentwickler notwendigen Informationen abbilden sollte. Als Grundstruktur wurden dabei das V-Modell®XT [Auto06] verwendet, ergänzt um wesentliche Aspekte der VDI-Richtlinien [VDI04] [VDI82] [VDI97] sowie das Vorgehensmodell nach Pahl/Beitz [PaBe97]. Mit der aspektorientierten Prozessmodellierung inklusive dem Modellierungswerkzeug i>pm (Kapitel 3.3.1.4) stand bereits ein flexibles Modellierungsframework zu Verfügung. Dabei mussten jedoch noch zusätzliche Eigenschaften, die sich aus dem Projekt 4.1 ÜBERSICHT ÜBER DIE PROJEKTE 96 ergaben, in die Modellansicht und damit letztendlich auch in den Prozessnavigator, integriert werden. Dies waren zum einen die für die Produktentwicklung charakteristischen Phasen, durch die der Gesamtprozess in überschaubare Teilabschnitte unterteilt werden kann. Eine weitere Anforderung bestand darin, Informationen über methodische Vorgehensweisen bei der Entwicklungsarbeit geben zu können [Meer07b]. Das Gesamtmodell umfasst ca. 100 Schritte. Eine ausführliche und komplette Darstellung des sog. FORFLOW-Prozessmodells findet sich in [KELR10]. • Projekt 2 – Medizinische Prozesse Im Rahmen eines Qualitätsmanagementprojektes zur Einführung Klinischer Behandlungspfade am Klinikum in Fürth erfolgte eine Ist-Analyse der im Klinikum vorhandenen medizinischen sowie administrativen Prozesse. Daran schloss sich deren Dokumentation in einem Prozessmodell an [FMSJ09]. Ziel war die Erstellung einer patientenorientierten Prozesslandschaft bestehend aus den Kernprozessen des Klinikums gemäß den DRGs (DRG = Diagnosis Related Groups, dt. Diagnosebezogene Fallgruppen, Klassifikationssystem für Leistungen am Patienten [FeBD90] [Fisc01]). Folgende DRGs wurden aufgenommen: Hüft-TEP, Koronare Herzkrankheit, Gastroentritis, Gallensteinleiden, Leistenhernie und Schädelprellung. Von den unterstützenden Prozessen wurden Pflegeüberleitung, operative Intensivpflege, der Sozialdienst und die Klinikums-Apotheke erfasst. Jedes Teilmodell umfasst ca. 150 – 200 Schritte. Es galt die Abläufe inklusive der Verantwortlichen, der notwendigen medizinischen Geräte (Werkzeug), Dokumente bzw. Informationen (bzw. allgemein der Inbzw. Output der Schritte zum Beispiel in Form eines Medikaments) zu erfassen. Es sollte die Dokumentation nicht bis ins letzte Detail oder mit allen Sonderfällen erfolgen; es galt vielmehr eine Art Richtschnur bzw. Standard für die Prozesse abzubilden. Wichtig war es, die Schnittstellen zwischen den Kernprozessen und den unterstützenden Prozessen zu identifizieren. • Projekt 3 – Verwaltungsbzw. universitätsbezogene Prozesse Dieses Projekt fand im Rahmen einer Qualitätsmanagementmaßnahme der Universität Bayreuth statt. Im Hinblick auf die von der Universitätsleitung angestrebte Systemakkreditierung, galt es für die zuständige Akkreditierungsagentur eine Dokumentation der Universität zu dem Bereich Studium und Lehre zu erstellen [UnBa11]. Dazu wurden unter anderem die Prozesse aus dem Bereich Studium und Lehre (Einführung, Durchführung = „Student-LifeCycle“, Aufhebung eines Studiengangs) in einem Prozessmodell abgebildet und umfassend in einem dazugehörigen Prozesshandbuch erläutert. Für eine transparente Darstellung galt es vor allem die Verantwortlichen und alle Beteiligten inklusive ihrer Interaktion und Kommunikation sowie die relevanten Dokumente, Informationen und Zeitangaben zu spezifizieren. Das Gesamtmodell umfasst ca. 250 Schritte. ANFORDERUNGEN 4.2 97 Die Modellierung erfolgte in allen drei Projekten unter Verwendung der aspektorientierten Modellierungssprache AOPM und dem Modellierungswerkzeug i>pm (siehe Kapitel 3.3.1.4). 4.2 Anforderungen Im folgenden Kapitel wird nun auf ausgewählte Anforderungen aus den in Kapitel 4.1 erläuterten Projekten eingegangen. Ein Anspruch auf Vollständigkeit wird dabei nicht erhoben. Die Auswahl erfolgte gemäß Relevanz der einzelnen Anforderungen in den verschiedenen Modellierungsprojekten, d.h. inwiefern sie in mehr als einem Projekt identifiziert worden sind. 4.2.1 Phasen Projekte werden für ihre Durchführung meist in Phasen unterteilt. Nach DIN 69901 ist eine Projektphase ein „zeitlicher Abschnitt eines Projektverlaufs, der sachlich gegenüber anderen Abschnitten getrennt ist“ [DeIn09]. Beispiele sind in Tabelle 4-1 zu sehen. Beschreibung Beispiel (1) Ein Produktentwicklungsprozess wird üblicherweise in die Phasen Planen, Konzipieren, Entwerfen und Ausarbeiten unterteilt. Diese lassen sich jeweils in weitere Arbeitsschritte unterteilen [Ehrl07]. Beispiel (2) Der Verlauf eines Studiengangs an einer Universität kann in die Phasen der Planung, Einrichtung, der Durchführung sowie der Aufhebung gegliedert werden (siehe zum Beispiel [UnBa11]). Sie lassen sich mit einer Vielzahl von Arbeitsschritte konkretisieren. Tabelle 4-1 Beispiele Phasen Anforderungen Phasen werden nicht als konkrete Aufgabe gesehen wie es bei Prozessen der Fall ist, sondern besitzen einen aufgabenbzw. prozessübergreifenden Charakter [Birk06] [VDI93]. Daher erfolgt die Definition der Phasen sehr grob, jedoch als logisch abgeschlossene Einheit [Burg02]. Zur Konkretisierung erfolgt eine Dekomposition der Phasen in Prozesse [Birk06] [VDI93]. Die Phasen sollen sich aufgrund des abweichenden Charakters in der graphischen Darstellung von Prozessen unterscheiden. Die Phasen unterscheiden sich zudem in ihrem zeitlichen Aufwand [Burg02] [Ehrl07]. Daher ist die Angabe eines Zeitfaktors wünschenswert, um das Gesamtbild besser darstellen zu können. 4.2 ANFORDERUNGEN 98 Auch wenn es per Definition (siehe zum Beispiel [Burg02]) nicht vorgesehen ist, hat die Erfahrung gezeigt, dass sich die Phasen oftmals zeitlich überlappen. Es findet kein sequentielles Hintereinanderschalten der Phasen statt, wie es bei Prozessen mittels Kontrollund Datenfluss abgebildet wird; vielmehr findet teils eine parallele Ausführung statt. So kann mit dem Verkauf der ersten Produkte begonnen werden, während die Produktion noch weiter läuft. Rücksprünge in frühere Phasen sind zum Zweck der Ergebnisoptimierung essentiell. Ziel der Modellierung kann es jedoch nicht sein, alle denkbaren Rücksprünge im Voraus zu identifizieren, um diese dann alle abzubilden. Dies würde zu unübersichtlich werden und wäre auch sehr aufwendig. Phasen enden üblicherweise mit sog. Meilensteinen, die ein zu erzielendes Ergebnis (zum Beispiel den Produktentwurf) definieren [Birk06] [Wild07]. Im Unterschied zu den OutputDaten eines Prozesses sind die Ergebnisse im Bezug auf einen Meilenstein von strategischer Bedeutung [DeIn09] und dienen der übergeordneten Strukturierung der Abläufe [Wild07]. Sie sollten daher auch bei der Modellierung hervorgehoben werden. Es ist zudem sinnvoll auf Ebene der Phasen Rollen zu definieren, um Verantwortliche spezifizieren zu können. Werkzeuge oder Systeme gilt es erst für die Prozessschritte anzugeben, da sie im Bezug zu einer konkreten Tätigkeit gesehen werden. Lösungsansätze EPKs oder UML-Diagramme, wie das Aktivitäts-oder das Anwendungsfalldiagramm, bieten kein Modellierungskonstrukt zur expliziten Darstellung von Phasen. Hier liegt der Schwerpunkt auf der Darstellung von Prozessen zur Detailbeschreibung. Der Standard BPMN definiert die Konstrukte Lanes sowie Pools sehr ungenau; diese könnten daher ersatzweise zur Darstellung des prozessübergreifenden Charakters der Phasen verwendet werden. Da dies jedoch leicht zu weiteren Missverständnissen führt, sollte davon Abstand genommen werden. Zudem lassen sich die gewünschten zeitlichen Aspekte damit auch nicht darstellen. Die Verwendung von Aktivitäten ermöglicht keine Abgrenzung zu den „normalen“ Prozessen. Das Artefakt zur Gruppierung kann für die Zusammenfassung jeglicher Art von Elementen verwendet werden, so dass die Eindeutigkeit sowie Klarheit in der Darstellung nicht gegeben ist. Eine Ausarbeitung eines individuellen Symbols für die Darstellung der Phase wäre mit BPMN 2.0 möglich, doch wäre das Konstrukt dann nicht Teil des Standards. Für AOPM wurde in einer speziellen, für die Produktentwicklung angepassten Version, das Modellierungskonstrukt PEP (= ProduktEntwicklungsPhase) definiert. Dies dient der übergreifenden Zusammenfassung von Prozessen. Die Phasen stellen Superprozesse zu den ANFORDERUNGEN 4.2 99 bisher bekannten Prozessen dar, d.h. sie bilden die oberste Ebene eines Prozessmodells und auf der darunterliegenden Ebene werden die Prozesse modelliert. Die Anwendung erfolgt inzwischen nicht nur bei der Modellierung von Produktentwicklungsprozessen, sondern domänenunabhängig, wie es in Abbildung 4-1 an Hand eines Beispiels aus der Medizin gezeigt wird. Abbildung 4-1 Phasen mit AOPM im i>pm modelliert Die graphische Darstellung der Phasen erfolgt in Form von Balken, die untereinander angeordnet werden. Ihre Länge und Position kann in horizontaler Richtung individuell zur Darstellung des Zeitfaktors bestimmt werden; eine Überlappung der Phasen ist somit zeitlich und inhaltlich möglich. Eine explizite Darstellung von Kontrollbzw. Datenflüsse erfolgt nicht. Der organisatorische und operationale Aspekt wird bei der im Rahmen dieser Arbeit verwendeten Version des i>pm erst auf der darunter liegenden Ebene modelliert. Sinnvoll wäre es aber, zumindest auch den organisatorischen Aspekt schon auf Ebene der Phasen verwenden zu können. Meilensteine können prinzipiell auf Phasenund Prozessebene modelliert werden. Werden sie auf beiden Ebenen modelliert, ist damit eine Unterscheidung in (Zwischen-) Meilensteine zur Erfassung von Zwischenergebnissen auf Prozessebene und Meilensteine zur Erfassung von Ergebnissen einer Phase möglich. Zum Zweck der Einheitlichkeit und Übersichtlichkeit 4.2 ANFORDERUNGEN 100 erscheint es sinnvoll, Meilensteine nur auf einer der beiden Ebene zu definieren. Die Definition auf Prozessebene ist dabei von Vorteil da sowohl detaillierte Zwischenmeilensteine als auch Meilensteine in Bezug auf das Ende einer Phase (siehe Abbildung 4-2)5 definiert werden können. Die Meilensteine werden in dem Fall über den Kontrolloder Datenfluss an einer beliebigen Stelle in den Prozessablauf integriert. Zusätzlich besteht die Möglichkeit, Daten, d.h. Dokumente, an diesem Konstrukt zu hinterlegen, was hier nicht dargestellt ist. Werden die Meilensteine nur auf Phasenebene modelliert, gehen die Informationen bzgl. der Zwischenmeilensteine verloren. AOPM liefert somit explizit ein Konzept zur Repräsentation von Phasen das die ermittelten Anforderungen abdecken kann. Abbildung 4-2 Meilenstein mit AOPM im i>pm modelliert 4.2.2 Kreative bzw. „unscharfe“ Prozesse Als kreative Prozesse werden solche Prozesse bezeichnet, die eine Aufgabe mit einem hohen Maß an Einfallsreichtum lösen und schließlich ein reales oder logisch fassbares Ergebnis erzielen [Laut11]. Daneben gibt es Prozesse, die nicht zwingend Kreativität erfordern, sondern sich durch ein Höchstmaß an Abhängigkeiten bzgl. der bei der Ausführung vorliegenden Bedingungen auszeichnen. Diese sind entscheidend für den realen Prozessablauf und bestimmen welche Schritte notwendig sind. Beispiele sind in Tabelle 4-2 zu sehen. Beschreibung Beispiel (1) Die Planung der universitären Lehrveranstaltungen bzgl. Raumund Zeitplanung ist ein Prozess mit vielen Iterationen und oftmals sind viele zeitliche oder räumliche Verschiebungen notwendig, bis das Endergebnis feststeht. Beispiel (2) Die Behandlung eines Patienten (vor allem bei Notfällen) kann nie exakt im Voraus in einem Prozessmodell abgebildet werden, weil stets auf den aktuellen Gesundheitszustand des Patienten reagiert werden muss. Tabelle 4-2 Beispiele kreativer bzw. unscharfer Prozesse 5 Aus implementierungstechnischen Gründen kann bei Verwendung von i>pm der Schriftzug zur Benennung des Prozesses nicht an die geometrischen Abmessungen des Prozessbausteins angepasst werden. ANFORDERUNGEN 4.2 101 Anforderungen Kreative bzw. „unscharfe“ Prozesse lassen sich bzgl. eines genauen Ablaufs sowohl inhaltlich als auch strukturell schwer konkretisieren. Der Formalisierungsgrad der Schritte ist sehr gering. Die kreativen Ideen entstehen dabei hauptsächlich im Kopf der ausführenden Person während der eigentlichen Ausführung, deren explizite Abbildung zum Zeitpunkt der Modellierung verständlicherweise nicht möglich ist [Pete04]. Sie weisen nur wenige, standardisierte bzw. obligatorische Tätigkeiten auf [Hofe99] [PaBe97]. Da die Gesamtanzahl der Schritte an sich jedoch sehr hoch ist, macht es Sinn sie zu kompositen Schritten zusammenzufassen [Hofe99] [PaBe97]. Der Grad der Vernetzung zwischen den einzelnen kreativen Teilschritten ist relativ hoch [Hofe99]. Zudem werden viele Iterationsschleifen durchlaufen, d.h. es erfolgt keine systematische Abhandlung der Aktivitäten, weil die Reihenfolge zur Modellierungszeit nicht genau vorgegeben werden kann [Pete04]. Mit dem Fortschritt der Durchführung der kreativen bzw. unscharfen Prozesse ist eine zunehmende Informationsschärfe, quantitativ wie qualitativ, zu verzeichnen [Hofe99]. Der funktionale Aspekt steht dabei weniger im Vordergrund als der zu erzielende Output. Dieser lässt sich zum Zeitpunkt der Modellierung zumindest als abstraktes Ergebnis in Form von zu erstellenden Dokumenten oder Ähnlichem definieren. Werkzeuge, vor allem IT-Systeme, dienen der Unterstützung bei der Dokumentation bzw. nachfolgenden Umsetzung der kreativen Gedanken und sollten daher abgebildet werden können. Die Darstellung eines kreativen bzw. „unscharfen“ Prozesses sollte sich von einem „normalen“ Prozess nicht zu grundlegend unterscheiden, wie es hingegen bei den Phasen gefordert wurde. Der Charakter eines Prozesses an sich ist immer noch vorhanden. Zudem sind sie Bestandteil des Prozessablaufs; eine Einbindung in den Kontrollbzw. Datenfluss muss also möglich sein. Lösungsansätze Die von der UML hauptsächlich zur Prozessmodellierung verwendeten Aktivitätsdiagramme definieren im Sinne eines funktionalen Aspektes die Aktivitäten und ihre Vernetzungen. Bei den kreativen bzw. „unscharfen“ Prozessen jedoch können weder alle Aktivitäten genau spezifiziert werden, noch kann ihre Vernetzung genau angegeben werden. Eine explizite Darstellung einer anderen Prozessart, wie die eines kreativen Schrittes, ist nicht möglich. EPKs sind von ihrem Grundgedanken her bereits ungeeignet für diese Art von Prozessen, da sie den Fokus auf die Modellierung standardisierter Abläufe legen. Bei diesen sind die Ereignisse und Funktionen sowie deren strukturellen Zusammenhänge definiert, so wie sie allgemein anerkannt sind und angewandt werden. 4.2 ANFORDERUNGEN 102 Auch BPMN legt den Schwerpunkt auf die Darstellung der zeitlogischen Abfolge von Aktivitäten. Bei den kreativen Prozessen soll zwar ein logisch nachvollziehbares Ergebnis erzielt werden, doch spiegelt sich das nicht immer in dem davor ablaufenden Prozess wieder. Eine Abbildung ist mit den vorhandenen (funktionalen) Modellierungselementen somit nicht möglich. Bei AOPM wird bzgl. des funktionalen Aspektes derzeit nur zwischen den Phasen sowie (kompositen oder elementaren) Prozessen unterschieden. Im Gegensatz zu den vorher genannten Modellierungssprachen wäre die Einführung eines entsprechenden Konstruktes jedoch jederzeit möglich. Dieses sollte graphisch einem normalen Prozessschritt ähnlich sein und als komposites Element definiert werden. Im Hinblick auf die Subprozesse muss es möglich sein die obligatorischen Schritte und, wenn bekannt, auch ihre Ablaufreihenfolge zu definieren. Die Angabe von Input und Output sollte ebenfalls möglich sein. Das Konzept des Platzhalters (siehe zum Beispiel [Hofe99]) ist in keinem der uns bekannten (Standard-) Modellierungssprachen vertreten. In vielen Fällen, unabhängig von den erläuterten Modellierungssprachen, hat sich jedoch die Modellierung von Platzhaltern für diese Art von Prozessen als geeignet bzw. ausreichend erwiesen [Hofe99]. Sie stellen eine abstrakte Funktion im Sinne einer „Black Box“ dar. Die Definition weiterer Unterschritte ist nicht im Konzept vorgehsehen, somit ist die Angabe obligatorischer Teilschritte nicht möglich; Zyklen und Rücksprünge sind nicht berücksichtigt. Darüber hinaus werden keine Angaben zur graphischen Darstellung gemacht. Die zur Modellierungszeit bekannten Rahmenbedingen können wie bei einem normalen Schritt als Input angegeben werden, ebenso die abstrakt formulierten Ergebnisse. Durch die fehlende Dekompositionsmöglichkeit ist eine Angabe von Zwischenergebnissen nicht möglich. Zusammenfassend kann festgehalten werden, dass das Konzept der Platzhalter noch verbesserungswürdig ist, jedoch einen Ansatz in die richtige Richtung darstellt. Im AOPM wäre dies dann entsprechend zeitnah umsetzbar. 4.2.3 Umfangreiche Prozessmodelle Bei großen Organisationen, die in ihrem Portfolio breit aufgestellt sind, aber auch in einer Klinik oder Universität, werden viele verschiedene Tätigkeiten ausgeführt, bei denen es eine Vielzahl weiterer Aspekte zu berücksichtigen gilt. Bei der Modellierung, wie auch bei der Modellanwendung, kann leicht der Überblick verlorengehen. Beispiele sind in Tabelle 4-3 zu sehen. Beschreibung Beispiel (1) Große Menge an Informationen, Dokumenten, Gesetzen, Beschlüssen, die im Rahmen der Einrichtung eines Studiengangs an einer Universität relevant sind. Die dazugehörigen Schritte werden außerdem von den unterschiedlichsten ANFORDERUNGEN 4.2 103 Rollen der Universität (aus der Verwaltung sowie den Fakultäten) durchgeführt. Beispiel (2) An der Durchführung einer Hüft-TEP sind, angefangen bei der prä-stationären Sprechstunde, bis hin zur Entlassung mit Nachsorge, viele verschiedene Personen des administrativen und vor allem des medizinischen Personals beteiligt. Für die verschiedenen Untersuchungen, die Operation sowie die Rehabilitation werden die unterschiedlichsten Geräte benötigt. Tabelle 4-3 Beispiele umfangreicher Prozesse Anforderungen Zum besseren Verständnis beim Lesen der Prozessmodelle sollte die große Menge an Elementen logisch strukturiert werden. Dies sollte für jeden Aspekt des jeweiligen Prozessmodells beachtet werden, vor allem für den funktionalen Aspekt. Sieben Elemente auf einem Prozessblatt, die Anzahl, die ein (Modell-) Leser maximal auf einen Blick erfassen kann (siehe dazu [Mill56]), sind meist schnell erreicht. Die einzelnen Schritte müssen daher in logischen Einheiten, die inhaltlich abgegrenzt sind, organisiert werden können. Oftmals sind Prozesse auch von einer hohen Anzahl an Entscheidungen geprägt, wodurch sich die strukturelle Komplexität der Prozesse zusätzlich erhöht. Dabei soll sich der Anwender nicht in der Vielzahl der Entscheidungen verlieren. Vielmehr sollten diese bei ihrer Abbildung sinnvoll kombiniert werden Mit den vielen Prozessschritten wird zudem eine große Menge an Daten verarbeitet sowie produziert. Die Darstellung jedes einzelnen Datenelements lässt die Modelle schnell unübersichtlich und überladen aussehen. Eine entsprechende Abstraktion ist daher notwendig. In einigen Fällen kann auch die Menge der einem Schritt zugewiesenen Rollen und/ oder Werkzeuge eine zusätzliche Ordnungsstruktur bzw. Verwaltungskonzept erforderlich machen (siehe für organisatorischen Aspekt zum Beispiel [Buss98]). Werden einem einzelnen Prozess mehrere Rollen und mehrere Werkzeuge zugeordnet, muss klar sein, wie diese zueinander in Beziehung stehen und wie sie mit einander kombiniert werden dürfen. Selbiges muss außerdem zwischen den einzelnen Prozessen definiert werden. Der Output eines Prozessschrittes wird nicht immer komplett zu dem direkt nachfolgenden Schritt geleitet, sondern verteilt sich auf mehrere nachfolgende Schritte. Umgekehrt kann der Input eines Schrittes aus unterschiedlichen Quellen stammen. Ziel muss es sein diese vielen unterschiedlichen Outund Input-Beziehungen übersichtlich und vollständig in den Prozessmodellen abzubilden. Die Darstellung der Abhängigkeit von Prozesselementen gilt sowohl zwischen den Aspekten als auch auf den einzelnen Aspekt an sich bezogen, wenn nur ein Prozessschritt für sich oder aber der Gesamtprozess betrachtet wird. Die Rolle an Prozessschritt A kann die Wahl der 4.2 ANFORDERUNGEN 110 Abbildung 4-4 Komplexe Entscheidung mittels elementaren Entscheidern (AOPM) aus [Meil05] Speziell für den medizinischen Kontext hat Meiler in [Meil05] für AOPM den sog. Evidenzbasierten Entscheider ausgearbeitet. Wie in Abbildung 4-5 zu sehen ist, sind die einzelnen Entscheidungen bzw. ihre Kriterien zwar einzeln aufgelistet, aber insgesamt als eine Entscheidung dargestellt. Aufgrund besonderer Anforderungen aus dem medizinischen Kontext heraus, gibt es genau zwei Ausgänge, je nachdem, ob die Kriterien erfüllt sind oder nicht; weitere wären denkbar und möglich. Das Konstrukt wird über den Datenfluss in den Gesamtprozess mit eingebunden, so dass Inputund Outputdaten angegeben werden können. Rollen können allerdings auch hier nicht angegeben werden. Im Gegensatz zur obigen Darstellung ist jedoch insgesamt eine prägnante Darstellung möglich. Abbildung 4-5 Evidenzbasierter Entscheider aus [Meil05] 4.2.6 IT-relevante Prozessabschnitte Prozessmodelle dienen dazu, den Stakeholdern einen Überblick über die zur Erfüllung einer Aufgabe auszuführenden Aktivitäten, die Anwendungsprozesse, zu geben [FrvL03] [Maur96]. Die spätere Prozessausführung erfolgt zum Großteil mittels informationstechnischer Unterstützung (Tabelle 4-6). Die technische Umsetzung des Anwendungsprozesses wird als Workflow bezeichnet [FrvL03] [JaBu96] [Maur96]. Sowohl der Anwendungsprozess als auch der Workflow bilden inhaltlich prinzipiell dasselbe ab. ANFORDERUNGEN 4.2 111 Beschreibung Beispiel (1) Die Durchführung der Leistungsabrechnung im Krankenhaus erfolgt mit Hilfe des KIS-Systems (Krankenhaus-Informationssystem). Beispiel (2) Die Anmeldung zu Prüfungen, Seminaren oder Kursen an der Universität Bayreuth erfolgt über das sog. FlexNow, das elektronische Prüfungssystem. Tabelle 4-6 Beispiele ausführbare Prozessabschnitte Anforderungen Für den Anwender sollen die Darstellungen im Prozessmodell möglichst intuitiv und in sich verständlich sein. Eine graphische Modellierungssprache ist dabei zu bevorzugen. Alle Informationen in einem Prozessmodell, die für die IT-technisch unterstützte Ausführung relevant sind, müssen explizit formal definiert sein, syntaktisch wie auch semantisch. Das Prozessmodell zur Ansicht für den Anwender und das Prozessmodell für die informationstechnische Umsetzung müssen prinzipiell denselben Inhalt abbilden. Lösungsansätze Grundsätzliche kann unterschieden werden, ob ein Prozessmodell, das zur Ansicht für den Anwender erstellt wurde, sofort IT-technisch umgesetzt werden kann, oder aber erst in eine ausführbare Sprache übertragen werden muss [Böhm00] [RiSt04] [Stei99]. Bei den Modellierungssprachen, die im Rahmen dieser Arbeit betrachtet werden, scheint letzteres die gängigere Methode zu sein, obwohl ersteres weitaus leichter zu realisieren ist. (Für weitere Details sei dazu zum Beispiel auf [Böhm00] und [Stei99] verwiesen.) Hier soll lediglich aufgezeigt werden, dass bereits bei der Auswahl der Modellierungssprache Aspekte der Ausführung zu berücksichtigen sind. Allgemein ist festzuhalten, dass die Prozessmodelle für die Anwender vorzugsweise in graphischer Form erstellt werden [CuKO92]. Bei den in Kapitel 3.3.1 vorgestellten Modellierungssprachen handelt es sich ohne Ausnahme um solche. Zur Definition ausführbarer Modellierungssprachen sind in den meisten Fällen vor allem zusätzliche implementierungstechnische Detailinformationen nötig [Allw06] [Böhm00] [Stei99]. Diese können sich auf formale Aspekte (zum Beispiel bzgl. der syntaktischen Korrektheit), wie auch auf inhaltliche Aspekte (zum Beispiel bzgl. Detaillierungsgrad und Präzision)beziehen [Böhm00]. Die Aktivitätsdiagramme der UML sind zunächst nicht ausführbar. Sie müssen in einem extra Schritt in ein IT-technisch umsetzbares Modell übertragen werden [Schä10]. 4.2 ANFORDERUNGEN 112 Auch EPKs fokussieren die graphische Notation der Prozesse. EPK-Modelle können zum Zweck der Ausführung nach BPEL (= Business Process Execution Language) [IBM11] abgebildet werden. Wie [StIv07] zu entnehmen ist, sind dabei jedoch einige Einschränkungen im Bezug auf den Informationsgehalt in Kauf zu nehmen. Bei BPMN wird zur ausführbaren Beschreibung der Prozesse WS-BPEL oder XPDL, beides XML-basierte Formate, verwendet [FrRH10]. Für BPEL definiert der BPMN-Standard, wie ein BPMN-Diagramm in BPEL übersetzt werden sollte. Das Mapping ist in keiner Weise trivial, zudem ist keine vollständige Übertagung der Informationen aus dem BPMN-Modell möglich; es fehlt vor allem an technischen Detailinformationen (siehe zum Beispiel [OvAD06], [BPMN2.0]). Die Übersetzung nach XPDL wurde von der WfMC beschrieben (siehe [WoMC11]). AOPM wird aktuell nur für die graphische Modellierung von Prozessen verwendet. Im Rahmen des FORFLOW-Projektes wurde zum Beispiel BPEL zur Modellierung ausführbarer Prozesse verwendet (siehe [MePa08], Teilprojekt 4.2.). 4.2.7 Sprünge Sprünge in einem Prozessmodell stellen Abweichungen des ansonsten kontinuierlich fortlaufenden Kontrollflusses dar. Sie dienen zur Ergebnisverbesserung, indem diese durch erneute Ausführung der dazu notwendigen Schritte überarbeitet werden (= Rücksprung); andersherum kann der Prozessverlauf verkürzt werden, in dem Schritte ausgelassen werden (= Vorsprung), wie es in Abbildung 4-6 zu sehen ist. Den Ansatzpunkt der Sprünge wird als Quelle bezeichnet; der Wiedereinstiegspunkt als Senke. Konkrete Beispiele sind in Tabelle 4-7 zu finden. Abbildung 4-6 Sprünge im Prozessmodell ANFORDERUNGEN 4.2 113 Es handelt sich bei den Sprüngen prinzipiell um Alternativen, die jedoch im Falle eines Rücksprungs im bereits durchgeführten Teil des Prozesses liegen und im Falle eines Vorsprunges unter gewissen Bedingungen Schritte auslassen, die prinzipiell für die Ausführung vorgesehen sind. Beschreibung Beispiel (1) Die Entscheidung über die Einrichtung des Studiengangs an der Universität Bayreuth ist ein iterativer Prozess. Die notwendigen Unterlagen müssen meist mehrmals überarbeitet werden, bis sie vollständig genehmigt sind. Beispiel (2) Ist nach einer Hüft-Operation die Einschaltung des Sozialdienstes/ der Pflegeüberleitung nicht notwendig, kann dieser Schritt übersprungen werden. Tabelle 4-7 Beispiele Sprünge Anforderungen Es muss zwischen Vorsprüngen und Rücksprüngen unterschieden werden. Die Sprünge beziehen sich sowohl auf den Kontroll-, als auch auf den Datenfluss. Letzteres weil die Entscheidung für einen Rückoder Vorsprung auf der Basis von entsprechenden Informationen zu treffen ist. Beide Flussarten müssen also im Kontext der Sprünge definiert werden können. Als Quellen sind Kontrollbzw. Datenflusselemente wie Konnektoren/ Entscheider möglich, als Senken elementare oder komposite Prozessschritte sowie Kontrollflusselemente. Für Quellen muss es erlaubt sein, mehr als einen ausgehenden Fluss zu definieren: einen mit dem der Anwender dem normalen/ Default Kontrollfluss folgt und zum direkt nachfolgenden Prozessschritt übergeleitet wird; einen Weiteren der die Voroder Rücksprünge modelliert. Bei den Senken soll mehr als ein eingehender Fluss erlaubt sein, da von mehreren Stellen innerhalb des Prozessablaufes zu einund derselben Stelle gesprungen werden kann. Da sich vor allem bei großen Prozessmodellen mit langen Abläufen, Sprünge nicht unbedingt auf ein Prozessblatt beschränken, wie es in Abbildung 4-6 zu sehen ist, muss eine prozessblattübergreifenden Darstellung möglich sein. Dabei ist vor allem die Verdeutlichung der Zusammengehörigkeit der jeweiligen Quellen und Senken wichtig. Bei einem hierarchischen Prozessmodell müssen Startund Endpunkte der Voroder Rücksprüngen auf jeder Ebene zu modellieren sein. Die Verbindung zwischen Quelle und Senke muss eindeutig erkennbar und nachvollziehbar sein. 4.2 ANFORDERUNGEN 114 Lösungsansätze Solange sich die Sprünge auf ein Prozessblatt beziehen, wie es auch in Abbildung 4-6 zu sehen ist, stellt eine konsistente und eindeutige Modellierung bei keiner Modellierungssprache ein Problem dar. Von einem Entscheider/ Konnektor ausgehend, kann ein Kontrollfluss zur Senke modelliert werden. Das einzige Problem dabei ist, dass so nur der Kontrollfluss dargestellt wird. Bei prozessblattübergreifenden Sprüngen verhält sich die Situation anders. In einem Aktivitätsdiagramm der UML können einer Aktivität beliebig viele Startknoten zugeordnet werden. Die Diagramme können zudem mehrere Endknoten besitzen. Mit einem solchen Endknoten wird jedoch das vollständige Ausführungsende eines Prozess angezeigt; danach dürfen keine weiteren Aktivitäten mehr folgen. Damit ist eine Modellierung von Sprüngen nicht möglich. Weitere Konstrukte, die zur Darstellung der Sprünge verwendet werden könnten, sind nicht definiert. Bei den EPKs gibt es sog. Prozesswegweiser, die anstelle einer Funktion modelliert sind als Hinweis auf andere Prozesse. Durch die Angabe einer Referenz setzen sie mindestens zwei verschiedene Prozesse miteinander in Beziehung. Somit könnten sie zur Darstellung von prozessblattübergreifenden Sprüngen, explizit zur Darstellung der Quellen, verwendet werden. Die Quellen können an jeder beliebigen Stelle im Modell platziert werden, die Angabe der Senken ist jedoch auf ganze Prozesse und damit die dazugehörigen Prozessanfänge begrenzt. Sprünge in die Mitte eines Ablaufs hinein sind somit nicht möglich. Abhilfe kann dabei eine Restrukturierung des Prozessmodells schaffen, so dass die Senke als erster Schritt eines Teilprozessmodells definiert ist. Die Standardmodellierungssprache BPMN definiert diverse sogenannte Start, Intermediate und End Events (siehe auch Anhang B), jeweils mit eigener graphischer Darstellungsform. Sie zeigen ein Ereignistyp am Anfang, innerhalb bzw. Ende eines Prozesses an. Bei wenigen Events besteht jedoch die Möglichkeit zur Definition einer eindeutigen Verbindung von Quelle (= End Event) und Senke (= Start Event), da es sich um isolierte Einzel-Events handelt, wie zum Beispiel Timer oder Error. None als Start sowie End Event ist sehr allgemein definiert, so dass es zur Darstellung einer Quelle oder Senke verwendet werden kann. Jedoch fehlt es an der Eindeutigkeit des Konstruktes bzgl. des Einsatzzwecks. Mit Multiple besteht zwar die Möglichkeit, zu einem End Event mehrere Start Events, die an beliebiger Stelle im Gesamtmodell definiert sind, zu definieren; diese treten dann jedoch auch alle ein, was im Hinblick auf den default Prozessablauf und die dazu modellierten Sprünge nicht erwünscht ist. Bei Message und Signal, von denen es auch sowohl Start als auch End Event gibt, kann eine Verlinkung definiert werden. Bei Signal ist dies nicht zielgerichtet zu einem bestimmten anderen aufnehmenden Signal möglich. Mit Message ist dies zwar möglich; doch wird eine Message immer erst über den Umweg eines sog. Participant ANFORDERUNGEN 4.2 115 gesendet, der diese dann zu einem Prozessschritt weiterleitet. Dies verkompliziert die Darstellung und das Verständnis. Die Intermediate Events sind zur Darstellung von Sprüngen schon per Definition nicht geeignet. Sie beeinflussen den Kontrollfluss nur insofern, als ein für andere Schritte relevantes Ereignis aus dem Prozess herausgelöst wird und der Prozess danach dem normalen Kontrollfluss folgt ohne einen Schritt zu überspringen; schon allein durch diese Vorwärtsausrichtung sind Rücksprünge definitiv von der Darstellung ausgeschlossen. Als ein Ansatz in die gewünschte Richtung können die sogenannten Off-Page Konnektoren Link betrachtet werden, die der Verbindung von Prozessabschnitten (auch auf verschiedenen Prozessblättern, jedoch auf einer Ebene) dienen. Werden mehrere Links verwendet, ist jedoch nicht genau klar, welche Links zusammengehören. Es ist generell keine Datenflussangabe bei den Events möglich. Die ist ein weiterer Punkt, in dem die genannten Events die Anforderungen nicht erfüllen können. Zudem gilt es zunächst die hohe Anzahl Events und ihre Bedeutung zu verstehen. Bei Verwendung der Modellierungssprache AOPM bieten sich die externen Einund Ausgänge zur Modellierung der Vorund/ oder Rücksprünge an. Dabei handelt es sich um Schnittstellen, die sich sowohl semantisch als auch visuell explizit von den normalen Einund Ausgängen eines Prozesses abgrenzen. Dabei muss einem externen Ausgang nicht zwingend ein externer Eingang (bzw. umgekehrt) zugeordnet werden, die Kopplung mit einem normalen Einoder Ausgang ist ebenfalls möglich. Eine individuelle Benennung dieser Schnittstellen ist möglich, so dass dort Informationen zu der dazugehörigen Quelle oder Senke angegeben werden können. Die Modellierung von Datenflüssen ist zudem möglich. Es kann somit festgehalten werden, dass AOPM die Anforderungen am besten erfüllt. Bei einer statischen Modellierung sind die Sprünge, wenn sie prozessblattübergreifend abgebildet werden, dennoch auch bei AOPM schwer nachvollziehbar. Eine entsprechende Funktionalität des Modellierungswerkzeugs kann dort weitere Unterstützung bieten. 4.2.8 Unterschiedliche Sichtweisen In den meisten Fällen sind an der Durchführung eines Prozesses unterschiedliche Rollen beteiligt (siehe Beispiele in Tabelle 4-8). Je nach Prozess kann damit ein häufiger Rollenbzw. Sichtwechsel verbunden sein, was vor allem bei stark funktionsorientiert ausgerichteten Organisationsstrukturen der Fall ist. Die verschiedenen Rollen sind dabei oftmals mehrfach im Laufe des Prozesses an der Ausführung beteiligt. Beschreibung Beispiel (1) Bei der Durchführung eines Studiengangs erfolgt ein häufiger Wechsel zwischen den Studierenden sowie den verschiedenen Abteilungen und 4.2 ANFORDERUNGEN 116 Verantwortlichen der Universität (Prüfungsausschuss, Prüfungsamt, Referate, Dezernate, Studiengangsmoderator, …). Beispiel (2) Bei der Behandlung eines Patienten in einer Klinik erfolgt ein Wechsel zwischen dem Patienten und den pflegenden bzw. behandelnden Personen (Arzt, Pfleger, Physiotherapeut, Medizinisch-technischer Assistent, …). Tabelle 4-8 Beispiele unterschiedlicher Sichtweisen Anforderungen Es muss klar sein, welche Schritte von welcher Rolle ausgeführt werden sollen. Die Rollenwechsel müssen für den Anwender beim Lesen des Prozessmodells ersichtlich sein. Er muss dabei erkennen können welche Schritte für ihn selbst relevant sind und welche von anderen Verantwortlichen ausgeführt werden. Der Rollenwechsel kann nach beliebig vielen Schritten bzw. nach jedem Schritt vorgenommen werden. Die Darstellung des eigentlichen Prozessablaufs (mittels Datenbzw. Kontrollfluss) darf nicht vernachlässigt werden, da dies für das Gesamtverständnis bzgl. des Prozesses essentiell ist. Lösungsansätze Für eine klare Rollenzuordnung ist die direkte Angabe am eigentlichen Prozessschritt sinnvoll. Da der Fokus damit auf der Darstellung des Prozessablaufes und den Prozessen an sich liegt, ist ein Rollenwechsel nicht auf den ersten Blick ersichtlich. Diese Art der Modellierung wird jedoch lediglich von den EPKs und AOPM unterstützt, nicht jedoch von den UML-Aktivitätsdiagrammen oder BPMN. Ein weiterer Ansatz ist, den Fokus der Darstellung hin zum organisatorischen Aspekt zu verschieben. Dieser Gedanke wird in Form der sog. Swimlanes realisiert. Eine Swimlane stellt einen horizontalen oder vertikalen Balken dar, dem jeweils eine Rolle zugewiesen wird. Entlang dieser Swimlanes werden die Prozesse entsprechend ihrer Rolle angeordnet, wie es in Abbildung 4-7 zu sehen ist. Daten und Datenflüsse sind hier der Übersichtlichkeit wegen nicht modelliert. Mit der Swimlane-Darstellung sind die Rollenwechsel gut zu erkennen, doch ist der Prozessablauf weniger intuitiv zu erfassen, vor allem wenn mehrere Verzweigungen vorkommen. Bei den Aktivitätsdiagrammen der UML können Swimlanes modelliert werden, um den einzelnen Aktivitäten Rollen zu zuordnen. ANFORDERUNGEN 4.2 117 Bei den EPKs steht primär die Darstellung einer Prozesskette im Vordergrund, weniger die Darstellung des organisatorischen Aspektes. Somit werden die Rollen direkt an den einzelnen Funktionen angegeben; die Darstellung von Swimlanes ist in Form von sog. Funktionsbändern möglich. Obwohl auch BPMN die Darstellung der zeitlogischen Abfolge von Aktivitäten fokussiert, sind hier, im Gegensatz zu den EPKs, mit den Pools und Lanes gleich zwei Typen von Swimlanes definiert. Damit sind Rollenwechsel in einem BPMN-Prozessmodell stets gut zu erkennen. Für AOPM ist eine Version vorhanden, in der neben der direkten Rollenangabe an einem Prozessschritt, Swimlanes modelliert werden können. Der Anwender muss sich dann aber vor der Modellerstellung entscheiden, ob er mit Verwendung der Swimlanes den Schwerpunkt auf den organisatorischen Aspekt legen möchte oder die zeitlich-logische Abfolge der Funktionen im Fokus sieht. Beide Darstellungsformen haben somit ihre Vorund Nachteile. Bei reiner Betrachtung der Modellierungssprachen, muss bei der Auswahl der Modellierungssprache abgewägt werden, welche Darstellung zu bevorzugen ist; Bei AOPM sind, unter Verwendung der neusten Version des i>pm (siehe dazu [Volz11]), beide Darstellungsformen für die Anzeige einund desselben Inhalts möglich. Abbildung 4-7 Darstellung eines Prozesses mit Swimlanes 4.2.9 Unterschiedliche Datentypen Im Rahmen eines Prozesses fallen für die verschiedenen Schritte viele Inputund Outputdaten an. Dabei kann es sich um elektronische oder Papier-Dokumente handeln, um physische Gegenstände wie zum Beispiel Chipkarte oder auch um mündliche Informationen in Form von Mitteilungen. Werden alle Daten auf dieselbe Art und Weise dargestellt, kann das Lesen 4.2 ANFORDERUNGEN 118 der Modelle bzgl. des datenorientierten Aspektes sehr mühsam werden; die Unterschiede müssen implizit vom Leser erfasst werden. Beschreibung Beispiel (1) In einem klinischen Behandlungsprozess fallen unterschiedliche Arten von Daten an: die Krankenkassenkarten der Patienten bei der Aufnahme, elektronische Dokumente im KIS, Röntgenbilder oder EKG-Aufzeichnungen. Beispiel (2) Bei der Durchführung des Studiengangs fallen unterschiedliche Arten von Daten an. So werden die Daten der Studenten elektronisch erfasst, dazu gibt es aber auch noch den physisch fassbaren Studentenausweis. Zudem muss der Student die erforderlichen Studienbeiträge an die Universität überweisen; die dabei anfallenden Daten gilt es ebenfalls zu erfassen. Tabelle 4-9 Beispiele Datentypen Anforderungen Eine prägnante Unterscheidung der verschiedenen Datentypen ist notwendig. Die Darstellung der Unterschiede soll visuell erfolgen und direkt im Modell zu erkennen sein. Es muss zu erkennen sein, dass die verschiedenen Datentypen zur Gruppe der Daten gehören. Lösungsansätze Es besteht die Möglichkeit an der Modellierungssprache direkt anzusetzen, in der nicht nur ein Datenelementtyp definiert wird, sondern verschiedene. Bei den Aktivitätsdiagrammen der UML werden jedoch lediglich Objektknoten zur Darstellung von Daten oder Informationen definiert. Bei den EPKs gibt es Informationsobjekte mit unterschiedlicher Bedeutung und jeweils eigener Darstellungsart (siehe Tabelle 3-1 in 3.1.1). Es werden elektronische Dokumente, Dokumente in Papierform und Informationsobjekte im Allgemeinen unterschieden. Damit sind bereits wesentliche Unterscheidungen getroffen, auch wenn die Unterteilung nicht individuell nach den eigenen Bedürfnissen vorgenommen werden kann. Da alle Elemente an die Form eines Rechteckes angelehnt sind, ist eine Zusammengehörigkeit erkennbar. BPMN definiert lediglich sog. Data Objects. Damit werden sowohl elektronische Objekte wie Dokumente oder Datensätze, als auch die physische Objekte aus der realen Welt wie die Krankenkassenkarte eines Patienten oder das Produkt eines Fertigungsprozesses dargestellt. Ebenso definiert auch AOPM lediglich eine Art von Datum. Zusätzlich gibt es lediglich das Konstrukt einer Checkliste; doch handelt es sich hier um ein sehr spezielles Konstrukt, das ANFORDERUNGEN 4.2 119 nicht unbedingt allgemeingültig anwendbar ist. Es besteht jedoch die Möglichkeit, die Daten zu kategorisieren. Die Modellierungselemente der Daten können der Kategorie entsprechend eingefärbt werden, sowie es auch in den Modellierungsprojekten des Lehrstuhls erfolgt ist, die mit AOPM modelliert worden sind (siehe zum Beispiel Abbildung 2-2 und Abbildung 2-3). 4.2.10 Unterschiedliche Prozesstypen Innerhalb einer großen Organisation fällt oftmals eine Vielzahl unterschiedlicher Prozesse an, im medizinischen Kontext zum Beispiel neben den medizinischen Prozessen auch verwaltungstechnische Prozesse. Letztere fallen auch im Rahmen der Produktentwicklung neben den Entwicklungsprozessen an. Die unterschiedlichen Prozesstypen unterscheiden sich in wesentlichen Charakteristiken, wie zum Beispiel manuelle oder automatisierte Ausführung. Wie bei den verschiedenen Datentypen in Kapitel 4.2.9 kann die visuelle Hervorhebung der unterschiedlichen Typen von Interesse sein. Im Bezug auf Beispiel (2) in Tabelle 4-10 ist damit zum Beispiel bei apparativen Untersuchungen zusätzliches Personal für die Durchführung notwendig. Beschreibung Beispiel (1) Neben den fachspezifischen Prozessen (zum Beispiel medizinisch, entwicklungstechnisch, …) fallen in großen Organisationen auch meist verwaltungstechnische Prozesse an. Beispiel (2) Bei den medizinischen Prozessen einer Klinik kann nach apparativ und nichtapparativ Untersuchungen unterschieden werden. Tabelle 4-10 Beispiele Prozesstypen Anforderungen Eine prägnante Unterscheidung der verschiedenen Prozesstypen ist notwendig. Die Darstellung der Unterschiede soll visuell erfolgen und direkt im Modell zu erkennen sein. Die verschiedenen Prozesstypen müssen dennoch als Prozess zu erkennen sein. Lösungsansätze Bei den im Rahmen dieser Arbeit berücksichtigten Modellierungssprachen (siehe Kapitel 3.3.1) wird in den Definitionen der Modellierungssprachen nicht zwischen verschiedenen Prozesstypen unterschieden. Bei AOPM besteht jedoch die Möglichkeit, Prozesse entsprechend festgelegter Kategorie einzufärben, wie es bereits im Zusammenhang mit den verschiedenen Datentypen in Kapitel 5.3 KLASSIFIKATION DER ANFORDERUNGEN 126 Modellierungssprachen sind diese oftmals zusammengefasst in Kriterienkatalogen, mit Hilfe derer die Modellierungssprachen grundlegend entwickelt werden können. Beispielhaft zu nennen wäre hier [FrvL03], die generelle Anforderungen sowie zusätzliche einige spezielle Anforderungen im Bezug auf die Darstellung von Geschäftsprozessen nennen oder [FrPr97] und [Fran98], die Anforderungen im Hinblick auf objektorientierte Modellierungssprachen definieren. Anforderungen bzgl. der Erstellung von Modellen sind zum Beispiel in [BeRS95] oder [MeRA10] zu finden. Es ist nicht das Ziel dieser Arbeit einen neuen Kriterienbzw. Anforderungskatalog aufzustellen, auch weil dies für jedes Anwendungsgebiet und jeden Anwendungsfall individuell erfolgen sollte. Vielmehr ist ein Rahmenwerk aufzustellen, das für die genaue Spezifikation der Anforderungen eine Unterstützung bietet. Abbildung 5-3 Klassifikation von Anforderungen gem. der Meta-Modell-Hierarchie Es gilt die zunächst zu Beginn einer Designphase lose, zum Beispiel im Rahmen eines Brainstormings ermittelten Anforderungen (dies ist in Abbildung 5-3 durch die Box auf der linken Seite dargestellt) im Hinblick auf ihre Umsetzung (die Gestaltungsmöglichkeiten) zielorientiert zu organisieren. Dies erfolgt unter Verwendung der Strukturierung der Designund Modellierungsphase, wie sie gerade in Kapitel 5.2 beschrieben worden ist. In Abbildung 5-3 ist die Kategorisierung der Anforderungen durch die an der linken Bildseite startenden horizontalen Pfeile dargestellt. Durch die explizite Strukturierung gemäß den Ebenen der Meta-Modell-Hierarchie kann eine wesentlich präzisere und differenziertere Definition und Abgrenzung von Anforderungen und deren Umsetzung (die Gestaltungsmöglichkeiten) gewonnen werden. Der Anwender wird sensibilisiert über die explizite Definition oder Anpassung einer Prozessmodellierungssprache nachzudenken, so dass er sich nicht nur auf den Modellierungsvorgang auf M1 beschränkt. DAS VORGEHENSMODELL 5.4 127 Es kann vorkommen, dass sich eine Anforderung und deren Umsetzung über mehrere Ebenen der Meta-Modell-Hierarchie erstrecken. Hierarchische Prozesse können nur dann modelliert werden, wenn dies die Modellierungssprache ermöglicht; solch eine Anforderung muss auf M2 definiert werden; eine Hierarchie der Prozesse an sich kann aber erst während des Modellierungsvorgangs auf M1 erstellt werden. Gleichzeitig gilt es zu berücksichtigen, dass sich die Umsetzung der Anforderungen nicht immer nur auf die Phase des Designs beschränken muss bzw. kann. Wie auch bereits in den Beispielen in Kapitel 4 aufgezeigt wurde, können manche Anforderungen erst im Rahmen der Modellierung realisiert werden. Beispielhaft zu nennen wäre die Anforderung, dass ein Prozessblatt nur so viele Elemente abbilden soll, wie der Anwender auf einen Blick erfassen kann. Wird daher in der Designphase auf M1 festgelegt, dass ein Prozessblatt nie mehr als sieben Prozessschritte enthalten darf, kann dies erst bei dem eigentlichen Modellierungsvorgang, der ebenfalls M1 zuzuordnen ist, umgesetzt werden. Nichtsdestotrotz soll es dem Anwender zugestanden werden, dass ihm gewisse gute Gestaltungsmöglichkeiten erst bei der Modellierung in den Sinn kommen, weil er sich dann weniger abstrakt und theoretisch, sondern praktisch mit der Sache beschäftigen kann. Dies führt zu Iterationsschleifen in dem Gesamtprozess, die sich jedoch bekanntlich positiv auf die Qualität des finalen Ergebnisses auswirken. Anforderungen, die erst nach der anfänglich durchgeführten Anforderungsanalyse auftreten, sind in diesem Konzept nicht berücksichtigt und sind auch nicht Schwerpunkt dieser Arbeit. Folgendes Beispiel dient der Veranschaulichung: Die Phasen in einem Prozessmodell sollen ohne Applikationen, d.h. ohne den operationalen Aspekt modelliert werden. Es ist nun zu unterscheiden, ob diese Eigenschaft in der zu verwendenden Prozessmodellierungssprache an sich berücksichtigt werden soll, oder ob lediglich eine Reihe von Prozessmodellen ohne den operationalen Aspekt modelliert werden soll. • Im ersten Fall muss diese Anforderung auf der Ebene M2 definiert werden, das heißt die zu verwendende Prozessmodellierungssprache verzichtet explizit auf die Definition des operationalen Aspekts und eines Modellierungselements. So ist es zum Beispiel bei AOPM für die Phasen definiert. • Im zweiten Fall wird diese Anforderung auf Ebene M1 realisiert, das heißt bei den relevanten Prozessmodellen wird kein operationaler Aspekt modelliert, obwohl dies die Sprache per Definition erlauben würde bzw. vorsieht. 5.4 Das Vorgehensmodell Bei dem entwickelten Ansatz handelt es sich um ein Phasenmodell. Phasenmodelle werden generell dazu verwendet größere Projekte in überschaubare Abschnitte, d.h. Phasen zu untergliedern [Burg02] [CKKP06] [Köhl06] [DeIn09]. Laut DIN 69901 ist eine Projektphase 5.4 DAS VORGEHENSMODELL 128 ein „zeitlicher Abschnitt eines Projektablaufs, der sachlich gegenüber anderen Abschnitten getrennt ist“ [DeIn09]. Design und Modellierung sind Phasen des Prozesslebenszyklus (siehe Kapitel 2.3). Darüber hinaus können die einzelnen Ebenen der Meta-Modell-Hierarchie M3 bis M0 den Phasen des Prozesslebenszyklus zugeordnet werden. In Kombination mit dem für Design und Modellierung entwickeltem methodischen Rahmenwerk bedeutet dies: jede dieser als Phase interpretierte Ebene M3 bis M0 wird durch die (Teil-) Phasen Design und Modellierung konkretisiert bzw. umgekehrt werden Phasen Design und Modellierung durch die einzelnen Ebenen in Teilphasen untergliedert. Damit lässt sich ein Vorgehensmodell definieren, wie es in Abbildung 5-4 zu sehen ist. Abbildung 5-4 Vorgehensmodell für Design und Modellierung DAS VORGEHENSMODELL 5.4 129 Abbildung 5-4 gibt als Zusammenfassung Aufgaben und Inhalte von Design und Modellierung auf den verschiedenen Ebenen der Meta-Modell-Hierarchie wieder. Die detaillierten Ausführungen folgen in Abschnitt 5.5. Von der Grundidee der zugrunde gelegten Meta-Modell-Hierarchie wird das Vorgehensmodell von oben nach unten, d.h. von M3 nach M0, durchlaufen, wie es in Abbildung 5-4 durch den Verlauf der Pfeile angezeigt wird. Der Einstieg ist jedoch, je nach Anwendungsfall, auf jeder Ebene möglich. Zudem wird der Gesamtprozess nicht so linear ablaufen, wie es die Abbildung vermuten lässt. Vielmehr wird der Ablauf von vielen ebenensowie phasenübergreifenden Sprüngen geprägt sein. Dies ist für die Qualität des Endergebnisses unabdingbar, da oftmals erst die Iterationen zum Optimum führen. Vorgehensmodell Design Im Rahmen der Anforderungsanalyse zu Beginn der Designphase wird zunächst das so genannte Lastenheft definiert. Das Lastenheft (= Anforderungsspezifikation, Anforderungskatalog) beschreibt die Gesamtheit der Anforderungen an ein zu erstellendes Objekt und dient der Klärung und Präzisierung der Aufgabenstellung [Pahl70] [Pahl74] [VDI93] [DeIn09]. Eine Anforderung wäre zum Beispiel die Möglichkeit der Unterscheidung zwischen medizinischem und administrativem Prozess. Hier erfolgt zunächst keine direkte Zuordnung der Anforderungen zu einer der Ebenen des Vorgehensmodells in Abbildung 5-4. Das zu erstellende Objekt ist hier die Prozessmodellierungssprache (inklusive Modellierungswerkzeug) sowie das Prozessmodell. Aufbauend auf dem Lastenheft wird das Pflichtenheft erstellt. Dieses beschreibt in konkreterer Form die Umsetzung des Lastenhefts [DeIn09], d.h. wie und womit die Anforderungen im Lastenheft zu lösen sind. Dabei werden nun explizit die verschiedenen Ebenen des Vorgehensmodells berücksichtigt. Somit ist im Grund pro Ebene ein Pflichtenheft zu erstellen. Zum Beispiel wird auf M2 festgelegt, dass zur Unterscheidung administrative Prozesse oval, medizinische Prozessen rechteckig dargestellt werden. Zusammen mit dem jeweiligen Anwendungskontext bildet das Pflichtenheft den Input für die anschließende Modellierung. Vorgehensmodell – Modellierung Es erfolgt schließlich in der Phase der Modellierung die Modellerstellung. Dabei wird das umgesetzt, was im Design mittels Lastenund Pflichtenheft identifiziert und festgelegt worden ist. Die Ergebnisse werden in den Ebenen-entsprechenden Modellen festgehalten. Nach der initialen Anforderungsidentifikation stellt nun die Identifikation der Modellinhalte aus dem aktuell vorliegenden Anwendungsfall eine Herausforderung dar. Dies ist sehr zeitintensiv und setzt gute analytische Fähigkeiten voraus. Auch der Abbildungsvorgang an sich muss sehr sorgfältig durchgeführt werden. 5.5 ERLÄUTERUNGEN DER EINZELNEN EBENEN 130 5.5 Erläuterungen der einzelnen Ebenen Im Folgenden werden die Aufgaben und Inhalte der einzelnen Ebenen, getrennt nach Design und Modellierung, erläutert. Es wird auch kurz auf die unterste Ebene M0 mit der Ausführung sowie dem Monitoring/ Controlling eingegangen. 5.5.1 M3 – Design und Modellierung Auf M3 gilt es abstrakte Modellierungsprimitive für das grundlegende Modellierungsund Sprachparadigma zu definieren. Das Ergebnis wird in einem Sprachdefinitionsmodell festgehalten. Input – Anforderungen M3 Die auf dieser Ebene zu berücksichtigenden Anforderungen sind von generischer Natur. Sie sind auch losgelöst von dem Prozessgedanken, der den Schwerpunkt dieser Arbeit ausmacht. Es besteht kein Bezug zu einer Anwendungsdomäne oder einem Anwendungsfall wie in Kapitel 2.2 beschrieben. Design M3 Für die Modellierungssprache werden zunächst in abstrakter sowie generischer Form die grundlegenden Modellierungsprimitive spezifiziert. Werden als Modellierungs-Paradigma gerichtete Graphen definiert, sind dies zum Beispiel Knoten und Kanten. Die Anzahl der definierten Modellierungsprimitive ist gering. Erst auf den darunter liegenden Ebenen werden für jedes dieser Modellierungsprimitive mehrere konkrete Konstrukte abgeleitet. Zur Festlegung der Struktur der Modellierungselemente, inklusive deren Beziehungen zueinander, wird eine abstrakte Syntax definiert [KrRV07]. Zum Beispiel wird festgelegt, dass Knoten durch Kanten verbunden werden oder dass eine Schachtelung von Knoten möglich ist. Die Definition erfolgt auf abstraktem Niveau und “describes the vocabulary of concepts provided by the language and how they are combined to create models” [ClSW08]. Da ein konkreter Anwendungsbezug auf M3 fehlt, werden Aspekte der Semantik kaum spezifiziert, sondern nur abstrakt im Sinne von Knoten und Kanten. Damit besteht jedoch die Flexibilität einen Knoten auf einer der unteren Ebene in der einen Modellierungssprache (zum Beispiel in AOPM) als Prozessschritt zu interpretieren, in einer anderen hingegen (zum Beispiel in einem ER-Diagramm) als Beziehungstyp. Beide Modellierungssprachen können dann aber auf dieselben Grundelemente zurückgeführt werden, was die Vergleichbarkeit erhöht. Angaben zur visuellen Darstellung werden nicht gemacht. ERLÄUTERUNGEN DER EINZELNEN EBENEN 5.5 131 In enger Wechselwirkung mit der Definition der Modellierungsmethode werden auch die ersten, noch abstrakten Konzepte eines Modellierungswerkzeuges entworfen. Auf diesen Aspekt soll jedoch im Folgenden nicht näher eingegangen werden. Modellierung M3 Die in der Designphase definierten Konstrukte können unter Berücksichtigung der definierten Syntax in einem Modell konkretisiert, d.h. modelliert werden. Damit erfolgt die Definition eines abstrakten, syntaktischen Meta-Meta-Modells, eines sog. Sprachdefinitionsmodells. Der Begriff „abstrakt“ soll nicht im Sinne der Informatik verstanden werden, wo es um das Ableiten eines wesentlichen bzw. charakteristischen Aspekts aus einer Menge von Einzelobjekten geht. Vielmehr ist der Begriff in einem allgemeineren Sinn zu verstehen, nachdem die „Gegenstände nur dem Denken, nicht aber der (sinnlichen) Wahrnehmung zugänglich sind“ [Mitt05]. Mit Gegenständen sind hier die Modellierungsprimitive gemeint. Das Modell wird explizit als syntaktisch bezeichnet, da eine Semantik kaum (lediglich im Sinn von Knoten und Kanten) spezifiziert ist. Diese Konkretisierung beinhaltet prinzipiell keine visuelle Darstellung, auch wenn mit Knoten und Kanten durchaus bereits Darstellungsformen assoziiert werden können. 5.5.2 M2 – Design und Modellierung Das Ergebnis dieser Ebene ist das Modell einer Prozessmodellierungssprache, kurz Sprachmodell genannt. Dabei müssen sprachbezogene Anforderungen berücksichtigt werden. Input – Anforderungen M2 Das Sprachdefinitionsmodell von M3 ist als wesentlicher Input dieser Ebene anzusehen. Für die Weiterentwicklung werden hier nun sowohl weitere generische als auch bereits domänenspezifische bzw. anwendungsbezogene Anforderungen berücksichtigt. Die generischen Anforderungen beziehen sich allgemein auf den (die) späteren Anwendungsbereich(e) der zu entwickelnden Modellierungssprache. Die domänenspezifischen Anforderungen beziehen sich auf spezielle Aspekte einzelner Anwendungsbereiche, wie zum Beispiel erst einmal die Domäne der Prozesse an sich, konkret die der Medizin oder der Produktentwicklung (siehe Kapitel 2.2). Es kann aber auch bereits um ein spezielles Modellierungsprojekt einer Organisation gehen, die dann anwendungsbezogene Anforderungen definiert. Die Anforderungen spiegeln wieder, welche Eigenschaften und Aspekte (zum Beispiel Daten und Rollen) Bestandteil des Sprachmodells sein müssen. 5.5 ERLÄUTERUNGEN DER EINZELNEN EBENEN 132 Design M2 Zunächst fließen die generischen Anforderungen in eine abstrakt zu definierende Zwischensprache ein (siehe Kapitel 3.3.2), die jedoch nicht für die Erstellung der Prozessmodelle auf M1 verwendet werden kann. Dazu erfolgt die Definition einer domänenspezifischen Modellierungssprache, die diejenigen domänenspezifischen Anforderungen umsetzt, die für den weiteren Verlauf in dem Vorgehensmodell von Interesse sind. Dabei muss nicht immer eine Neudefinition erfolgen, ebenso können existierende Modellierungssprachen angepasst werden. Es wird unterschieden zwischen Sprachen zur Modellierung von Geschäftsprozessen (Prozesse, bei denen die Darstellung betriebswirtschaftlich-fachlicher Aspekte im Vordergrund steht [FrvL03] [Maur96]) oder aber Workflows (Prozesse, die automatisiert ausgeführt werden oder zumindest in Teilen informationstechnisch unterstützt werden sollen [FrvL03] [Maur96]). Bei Letzteren ist eine formale bzw. exakte Definition der Modellierungssprachen unabdingbar [JaBu96] [KBGS11]. Basierend auf den Modellierungsprimitiven von M3 werden konkrete Konstrukte definiert. Dies erfolgt inklusive der Angabe von Attributen und Parametern, die beide erst auf den noch folgenden Ebenen mit konkreten Werten und/ oder Wertebereichen versehen werden können. Für die Beziehung der Konstrukte wird eine konkrete Syntax spezifiziert. Darauf aufbauend wird eine explizite Semantik definiert [KrRV07] [HaRu04]. Im Unterschied zur Ebene M3 können hier nun für die instanziierbaren, domänenspezifischen Sprachelemente Angaben zur Visualisierung gemacht werden. In Abbildung 5-5 wird dies beispielhaft in Form des Rechtecks für den „Prozess“ und den durchgezogenen Pfeil mit gefüllter Spitze für einen „Verbindungspfeil“ gezeigt. Form, Linienart, Farbe oder andere graphische Aspekte lassen sich beliebig anpassen. Wird zum Beispiel bei einer graphischen Modellierungssprache, wie es die perspektivenorientierte Modellierung (siehe 3.3.2.2) ist, die Anforderung nach zweierlei Arten von Verbindungspfeilen zum Verbinden der Prozesselemente gestellt, nämlich Kontrollund Datenflusspfeile, können diese als durchgezogene bzw. gestrichelte Linie modelliert werden. Bei textuellen Sprachen kann die Darstellung der Schriftzeichen bzgl. Schriftart (Arial, Times New Roman; fett, kursiv), Größe sowie Farben individuell bestimmt werden. Abbildung 5-5 Beispielhafte Interpretation von "node & edge" (M3) auf der Ebene M2 ERLÄUTERUNGEN DER EINZELNEN EBENEN 5.5 133 Darüber hinaus wird hier auch ein Modellierungswerkzeug ausgearbeitet. Wie bereits erwähnt wird darauf im Rahmen dieser Arbeit nicht weiter eingegangen. Näheres dazu ist [Volz11] zu entnehmen. Modellierung M2 Die im Design spezifizierte Sprache kann nun definiert werden. Dazu werden alle Konstrukte als Instanzen der Knoten und Kanten, den Modellierungsprimitiven von M3, erzeugt. Dabei werden die bereits in Kapitel 3.3.2 vorgestellten Modelltypen (APMM = abstraktes Prozess Meta Modell für die Zwischensprache, SDPMM = domänenspezifisches Prozess Meta Modell) unterschieden. Letzteres ist ein Sprachmodell in Form einer Prozessmodellierungssprache wie BPMN als Standardmodellierungssprache oder AOPM4MED als anwendungsbezogene Modellierungssprache, hier in Bezug auf die Medizin. Anmerkung Die bisher beschriebenen Ebenen M3 und M2 sind von den nun folgenden Ebenen M1 und M0 abzugrenzen. Auf M3 und M2 erfolgt die Gestaltung (= Design) sowie Konkretisierung (= Modellierung) einer Modellierungssprache mit individuellem Bezug zu einer Domäne oder einem Anwendungsfall. Auf M1 und M0 liegen nun konkrete Anwendungsfälle vor, die mittels der auf M2 entwickelten Modellierungssprache abgebildet (M1) und dann ausgeführt (M0) werden können. Es werden keine Änderungen der zugrundeliegenden Modellierungsparadigmen und - sprachen mehr vorgenommen. 5.5.3 M1 – Design und Modellierung Ab der Ebene M1 steht nun die Erstellung eines konkreten Prozessmodells im Vordergrund, das einen speziellen Anwendungsfall darstellt. Dabei wird die auf M2 definierte Modellierungssprache bzw. das Sprachmodell verwendet. Input – Anforderungen M1 Als Input ist zum einen das Sprachmodell relevant, sei es das einer Standardmodellierungssprache oder das einer anwendungsbezogenen Modellierungssprache. Zudem gilt es weitere anwendungsbezogene Anforderungen zu berücksichtigen, die sich aus dem konkreten Anwendungsfall ableiten (eine bestimmte Organisation und ihre Prozesse oder ein Klinikum und seine klinischen Pfade). 5.5 ERLÄUTERUNGEN DER EINZELNEN EBENEN 134 Design M1 Auf dieser Ebene geht es im Design nun nicht mehr darum, konkrete Konstrukte, wie zum Beispiel einen Prozessschritt oder Kontrollfluss an sich und deren prinzipiellen Beziehungen zu den anderen Konstrukten, zu spezifizieren. Dieser Aufgabenteil ist auf der darüber liegenden Ebene M2 abgeschlossen worden. Der Schwerpunkt liegt unter anderem auf der Formulierung von Regeln, die die Verwendung der Elemente sowie das Layout des Modells betreffen. Beispielsweise kann für ein bestimmtes Projekt entschieden werden, dass der organisatorische Aspekt nicht bei kompositen Prozessen verwendet werden soll, sondern nur bei elementaren Prozessen. Ein weiteres Beispiel wäre die Regel, nie mehr als sieben Sub-Prozesse für einen Prozess und somit ein Prozessblatt zu erlauben. Diese Angaben gelten nicht allgemein in Bezug auf die Modellierungssprache, sondern nur für den aktuell vorliegenden Anwendungsfall. Modellierung M1 Es erfolgt nun unter Verwendung einer Prozessmodellierungssprache, wie zum Beispiel AOPM oder UML, und unter Berücksichtigung der Designvorgaben, die Erstellung von Prozessmodellen. Es werden hier kurz grundlegende bzw. mögliche Modellarten vorgestellt, um ein Bild zu vermitteln, wie die Modellierungssprache verwendet werden kann. • Soll-Ist-Modelle Ist-Modelle werden zunächst im Rahmen einer erstmaligen Dokumentation der Prozesse erstellt und geben den aktuellen Status Quo der Abläufe, so wie sie aktuell ausgeführt werden, wieder [Fisc06] [FrRH10] [ScSe08]. Auf der Basis einer eingehenden Analyse, werden Schwachstellen, Fehler und Unstimmigkeiten aufgedeckt. Die Analyse führt zu der Definition von sog. SollModellen, um Schachstellen und Fehler zu eliminieren. Diese dienen dann als Basis für die Ausführung der Prozesse auf der Ebene M0 [Fisc06] [FrRH10] [ScSe08]. Die Prozessmodelle gilt es durch regelmäßige Überarbeitung einer Qualitätskontrolle zu unterwerfen, was zu einem Kreislauf der kontinuierlichen Verbesserung führt. • Strategisch-operative Modelle Strategische Modelle werden zur Darstellung des Portfolios einer Organisation eingesetzt. Dazu erfolgt die Abbildung der Hauptprozesse des Unternehmens in einer sog. Prozesslandschaft [FrRH10] [Remu02] [ScSe08] [Wilh07]. Als Beispiel wären Beschaffungs-, Produktentwicklungs-, sowie Vertriebsprozesse aus dem betriebswirtschaftlichen/ ingenieurwissenschaftlichen Bereich zu nennen. In den operativen Modellen werden die Prozesse nun so detailliert abgebildet, dass die Prozesse mit den darin enthaltenen Informationen auf der Ebenen M0 mit oder ohne Systemunterstützung ausgeführt werden können. [Fisc06] [FrRH10] [JaBu96] [ScSe08] [Wilh07]. So wird zum Beispiel in einem universitären Prozessmodell für die Phase der Durchführung eines Studiengangs der Prozess „Einschreibung ERLÄUTERUNGEN DER EINZELNEN EBENEN 5.5 135 durchführen“ mit dem Inputdatum „Zeugnis“ und der Organisation „Studierender“ modelliert. 5.5.4 M0 – Design und Modellierung Es erfolgt hier nun ein Wechsel von der Modellierungsumgebung zur Ausführungsumgebung. Die Prozessmodelle werden zunächst instanziiert. Daher können auch auf dieser Ebene in geringem Ausmaß noch Aufgaben durchgeführt werden, die dem Design und der Modellierung zuzuordnen sind. Input – Anforderungen M0 Bei der Instanziierung müssen anwendungsbezogene Anforderungen in Bezug auf das bei der späteren Ausführung zu verwendende Prozessmodell berücksichtigt werden. Es handelt sich hier um planbare Anforderungen, die die Kontextbedingungen konkretisieren und noch vor der Ausführung entsprechend in das Modell integrierbar sind bzw. integriert werden müssen. Grundlagen liefern üblicherweise die Projektpläne der Organisationen wie Termin-, Kostenund Kapazitätspläne. Design M0 Das Prozessmodell muss aus organisatorischen sowie implementierungstechnischen Gesichtspunkten an die nun konkret vorliegenden Ausführungsbedingungen angepasst werden, um ein ausführbares Prozessmodell zu erhalten. Dazu werden Parameter und Attribute mit konkreten Werten besetzt. Es kann sich auch um rein organisatorische Aspekte handeln, wie zum Beispiel dass die Mitarbeiter von ihrem Vorgesetzten ihren Aufgabenbereich zugewiesen bekommen. Ebenso kann im Hinblick auf die (informations-) technische Unterstützung der Prozessausführung festgelegt werden, dass nicht mehr als fünf Schritte pro Zeiteinheit gleichzeitig ausgeführt werden dürfen. Eine Ausführungsumgebung für einen konkreten Anwendungsfall/ ein Projekt in einer Organisation wird entsprechend definiert bzw. im Hinblick auf die Ausführung konfiguriert. Dabei muss es sich nicht zwingend um ein IT-System handeln; es kann auch rein organisatorische Aspekte betreffen. Wie bei den Modellierungswerkzeugen soll auch darauf hier nicht näher eingegangen werden. Modellierung M0 Die im Rahmen des Designs konkretisierten Angaben werden bei der Instanziierung in das Prozessmodell übernommen. Die Instanziierung des Prozessmodells beinhaltet die Einbettung in die technische und/ oder organisatorische Ausführungsumgebung. Dies kann sich von der weboder papierbasierten Veröffentlichung der Prozessmodelle als Anleitung für die Mitarbeiter, über die ein teilautomatisierendes Prozessunterstützungssystem bis hin zu einem 238 [Weis91] Weis, E. (ed.) Pons-Kompaktwörterbuch - Englisch-Deutsch, Deutsch-Englisch. Klett Verlag, Stuttgart, 1991. [Wesk07] Weske, M. Business Process Management - Concepts, Languages, Architectures Springer, Berlin, Heidelberg, New York, 2007. [Whit04] White, S. Introduction to BPMN, http://www.bpmn.org/, Abruf am 2010-11-26, 2004. [Wild07] Wildemann, H. Projektmanagement - Leitfaden zu Koordination und Controlling von Funktionsübergreifenden Projekten TCW-Verlag, München, 2007. [Wilh07] Wilhelm, R. Prozessorganisation. Oldenbourg Wissenschaftsverlag GmbH, München, 2007 [Wino96] Winograd, T. Bringing Design to Software. Addison-Wesley, Inc., Reading, MA, 1996. [Wino97] Winograd, T. The Design of Interaction. In Denning, P. und Metcalfe, R. eds. Beyond Calculation, The Next 50 Years of Computing, Springer-Verlag, New York, 1997, 149-162. [WKWI08] Wissenschaftliche Kommission Wirtschaftsinformatik im Verband der Hochschullehrer für Betriebswirtschaft e. V. (WKWI) und Fachbereich Wirtschaftsinformatik der Gesellschaft für Informatik (GI-FB WI). WI - Orientierungsliste. Wirtschaftsinformatik, 50 (2). 155-163 2008. [Witz00] Witzl, A. Das problemzentrierte Interview. Forum Qualitative Sozialforschung, Volume 1 (1) 2000. [WoHa10] Wolf, C. und Harmon, P. The State of Business Process Management Business Process Trends BPTrends Report. 2010. [WoMC11] Workflow Management Coalition (WfMC). XPDL. http://www.wfmc.org/xpdl.html, Abruf am 2010-11-22, 2011 [YuLi00] Yu, C.-S. und Li, H.-L. A robust optimization model for stochastic logistic problems. International Journal of Production Economics, 64. 385-397 2000. [Zair94] Zairi, M. Practical Benchmarking - A Complete Guide. Chapman & Hall, London, 1994. [ZaSi95] Zairi, M. und Sinclair, D. Business process re-engineering and process management - A survey of current practice and future trends in integrated management. Business Process Re-engineering & Management Journal, 1 (1). 8-30 1995. 239 [ZdKa02] Zdrowomyslaw, N. und Kasch, R. Betriebvergleiche und Benchmarking für die Managementpraxis: Unternehmensanalyse, Unternehmenstransparenz und Motivation durch Kennund Vergleichsgrößen. Oldenbourg Verlag, München, 2002. [zMRo04] zur Mühlen, M. und Rosemann, M. Multi-Paradigm Process Management. 5th Workshop on Business Process Modeling, Development and Support (BPMDS 2004), Riga, Latvia, 2004. 240 241 Anhang A Leitfaden - Interview Einleitung Wie wird Prozessmanagement umgesetzt? Erst einmal vielen Dank, dass Sie sich die Zeit für unser Gespräch genommen haben. Ich habe ja am Telefon/gegebenenfalls Infoblatt schon kurz umrissen, worum es in unserem Gespräch gehen soll. Mich interessiert, wie Sie dieses Thema bewerten und einschätzen. Wir befragen Unternehmen aus verschiedenen Branchen, unter anderem auch Ihre. Vorab möchte ich Sie schon einmal darauf hinweisen, dass die Fragen, die ich Ihnen im Verlauf des Gesprächs stellen möchte, nicht unbedingt meinen eigenen Ansichten entsprechen. Bei unserem Gespräch gibt es keine richtigen oder falschen Antworten. Ich möchte Sie bitten, mir Ihre ganz persönliche Meinung und Ihre Erfahrungen zu erzählen. Ihre gesamten Angaben werden anonym und vertraulich behandelt. Wenn bei Ihnen während des Interviews Fragen auftauchen, können Sie diese natürlich jederzeit stellen. Bevor wir jetzt speziell auf das Thema „Umsetzung des Prozessmanagements“ kommen, würde mich zunächst einmal ganz allgemein interessieren … Interviewleitfaden – Themenübersicht I. Einführung II. Rahmenbedingungen III. Prozesse (Erfassung und Verwendung) IV. Informationstechnologie V. Mitarbeiter [Bemerkung: die unterstrichenen Fragen sollen auf jeden Fall gestellt werden; die Kursiv gedruckten Bereiche dienen dazu, dem Interviewten bei der Strukturierung seiner Antworten behilflich zu sein] 242 I. Einführung … ist Prozessmanagement oder Prozessorientierung bei Ihnen ein Thema? II. Rahmenbedingungen Das Unternehmen und seine Struktur bilden das grundlegende Gerüst, den Rahmen zur Durchführung der einzelnen Aufgaben im Geschäftsalltag und beeinflussen daher wesentlich das Prozessmanagement. Uns interessiert daher: … A. Strategische Ebene 1. Wie stellt sich die Aufbauorganisation des Unternehmens, d.h. die Strukturierung der organisatorischen Einheiten dar? ... bzgl. Hierarchieebenen (viele, wenige)? … bzgl. Geschäftseinheiten, - Bereichen, Abteilungen? …bzgl. Einlinien,- Mehrlinienorganisation/ funktionale, divisionale, Matrixorganisation? 2. Ist ihr Unternehmen zertifiziert z.B. nach ISO 9001? … Ja: Spielt PM dabei eine Rolle (a) Ja: Inwiefern? (b) Nein: Æ … Nein: Æ 3. Inwiefern verwendet das Management Prozesse zur Planung/ Steuerung/ Kontrolle/ etc.? B. Operative Ebene 1. Wie erfolgt eine Strukturierung der Abläufe im Unternehmen? … als Prozessorganisation? … welche anderen Konzepte gibt es? 2. Sind (Standard-) Vorgehensmodelle bei Ihnen ein Thema? … VDI 2221/ RUP/ V-Modell 243 III. Prozesserfassung und -Verwendung Drehund Angelpunkt beim Prozessmanagement sind die Prozesse. Zur Umsetzung des Prozessmanagements sollten die Prozesse jedoch entsprechend aufbereitet werden. A. Identifizierung/Modellierung Werden Abläufe bei Ihnen erfasst bzw. dokumentiert? Und zwar nicht während der Aus-/ Durchführung der Prozesse, sondern es soll dabei um die Identifizierung/ das Erkennen der Prozesse gehen. … wenn ja: Æ (1) Werden Prozesse in allen Bereichen/ Ebenen des Unternehmens erfasst? …ja/ nein: Æ Warum? (2) Wie werden die Prozesse erfasst bzw. identifiziert werden? (3) Wo liegt der inhaltliche Schwerpunkt (der Erfassung bzw. Darstellung)? … d.h. welche Aspekte werden betrachtet bzw. fokussiert? … welche Aspekte fehlen ihrer Meinung nach? (4) Welche Anforderungen werden an die Erfassung bzw. Darstellung gestellt? … fehlerfrei, vollständig, subjektiv, informeller Charakter…. (inhaltlich) … syntaktisch korrekt, ausgezeichnete Ausdrücke, berechenbar … (formal) …wenn nein: Æ (1) Aus welchen Gründen werden bei Ihnen Prozesse nicht identifiziert? … z.B. wird es nicht als notwendig erachtet … z.B. wurde daran bisher nicht gedacht B. Verwendung/ Umsetzung: 1. Wie werden Prozesse bei Ihnen umgesetzt/ eingesetzt/ verwendet? …Darstellung/ Illustration der Abläufe im Unternehmen (zur Kommunikation/ Training,…)? … Ausführung/ Umsetzung durch ein technisches System (mit /ohne Interaktion des Menschen)? … Monitoring von Vorgängen? … Optimierung von Vorgängen? 2. Helfen Ihnen Prozesse ihre Arbeit zu strukturieren? 244 IV. Informationstechnologie Insbesondere die Informationstechnologie hat Einfluss auf das Prozessmanagement. Sie beeinflusst die operativen Abläufe im Unternehmen. Uns interessiert daher: A. Aufbau/ Konzept 1. Verwenden Sie ein globales System oder arbeiten Sie mit verschiedenen Anwendungen? … verschiedene Anwendungen: Æ (1) Besteht eine Integration zwischen den verschiedenen Anwendungen? … über Prozesse? … über eine zentrale Datenbank, …? … globales System: Æ (2) Wonach ist das globale System strukturiert/ gegliedert? … nach Funktionen? … nach Prozessen? B. Funktionalität 1. Welche Arten von Anwendungen/Technologien/Informationstechnologien werden verwendet? (Umformuliert = Wie ist die Ausrichtung ihrer Technologien?) … Datenverwaltung, z.B. als Kundenverwaltungssystem? … Abrechnung, z.B. Reisekostenabrechnung? … Planungssystem/ ERP-Systeme, z.B. zur Ressourcenplanung, Materialwirtschaft? 2. Wie erfolgt die Informationsversorgung des Anwenders? … über eine zentrale/ dezentrale Speicherung? … durch automatisches Weiterleiten, persönliches Weiterleiten der Daten? 3. Gibt es einen Zusammen/ eine Kopplung/ eine Verbindung zwischen den Prozessen und der IT? C. Operative Ebene/ Umsetzung/ Verwendung 1. Wie finden Anwender für ihre Tätigkeiten geeignete Anwendungen bzw. Informationssysteme, d.h. wie/womit werden die Funktionen dem Anwender vermittelt? … Systeme leiten Anwender komplett… 245 … Prozessbeschreibungen ... 2. Welche Technologien fehlen in Ihren Betrieb/ ihre Abläufe und sollten daher als nächstes erworben oder auch entwickelt werden? V. Mitarbeiter Zur Umsetzung des Prozessmanagements tragen im Wesentlichen auch die Mitarbeiter bei da durch sie das Prozessmanagement quasi im Alltag gelebt wird. Daher interessieren uns zum einen der Berufsalltag im Unternehmen, wie auch einige Aspekte zur Qualifikation/ Fortbildung der Mitarbeiter. A. Berufsalltag: 1. Wie werden (neuen) Mitarbeitern die Abläufe im Unternehmen vermittelt? …Coaching, Training…? … Prozessmodell/ Prozesshandbücher? 2. Wie ist ein Mitarbeiter in den Geschäftsablauf eingebunden? … über Prozesse/ Netzwerk bzw. Prozessgeflecht? …als isoliertes Teilgebiet? 3. Wo besteht Optimierungsbedarf bzgl. eines effektiveren Arbeitsablaufs? B. Qualifikation/ Fortbildung: 1. Inwieweit wird Wert auf Kenntnisse über Prozessmanagement gelegt? 2. Werden die Mitarbeiter in Prozessen geschult? 246 233 Anhang B BPMN Events Start Zwischen Ende Top-Level Ereignis-Teilprozess unterbrechend Ereignis-Teilprozess Nicht-unterbrechend Eingetreten Angehaftet unterbrechend Angehaftet nicht-unterbrechend Ausgelöst Blanko: Untypisierte Ereignisse, i. d. R. am Start oder Ende eines Prozesses Nachricht: Empfang und Versand von Nachrichten Timer: Periodische zeitliche Ereignisse, Zeitpunkte oder Zeitspannen Eskalation: Meldung an den nächsthöheren Verantwortlichen