Gemeinsames Konventionshandbuch für eine einheitliche Prozessmodellierung an den Hochschulen in Rheinland-Pfalz

Transkript

1 Gemeinsames Konventionshandbuch für eine einheitliche Prozessmodellierung an den Hochschulen in Rheinland-Pfalz v0.11

2 Änderungsverzeichnis Nr. Datum Version Geänderte Beschreibung der Änderung Autor/in Zustand Kapitel Alle Bereitstellung des Handbuchs der HS Witchen, Entwurf Koblenz als Ausgangspunkt zur Entwicklung des gemeinsamen Handbuchs. HS KO Alle Vorschläge der FH KL eingearbeitet Allweyer, Entwurf FH KL Anmerkungen der HS WO, BI + KL Küßner, Entwurf eingearbeitet. FH KL Alle Ergebnisse des Workshops vom Küßner, Entwurf eingearbeitet FH KL einige Nachkorrektur der Version 0.6 Witchen Entwurf HS KO einige Ergänzung Witchen Entwurf HS KO einige Anmerkungen von Prof. Allweyer Küßner, Entwurf FH KL einige 03. BPM-Workshop am an der FH KL FH BI, HS KO, FH KL, Verabschiedet HS LU, FH MZ, HS TR einige Einfügen redaktioneller Anpassungen wie am vereinbart Küßner Ansprechpersonen der Hochschulen FH Bingen: QM/PM: Florian Link, f.link@fh-bingen.de, Tel.: Technische Betreuung seitens des RZ: Michael Mielke Verantwortung Vizepräsidentin: Prof. Dr. Antje Krause HS Koblenz: QM/PM: Alexander Witchen, witchen@hs-koblenz.de, Tel.: Technische Betreuung seitens des RZ: Johannes Fondel Verantwortung Projektleitung icms: Prof. Dr. Udo Gnasa FH Kaiserslautern: QM/PM: Viola Küßner, viola.kuessner@fh-kl.de, Tel.: Fachbegleitung: Prof. Dr. Thomas Allweyer, thomas.allweyer@fh-kl.de Verantwortung Vizepräsident: Prof. Dr. Hans-Joachim Schmidt HS Ludwigshafen PM: Heidrun Bleiziffer, heidrun.bleiziffer@hs-lu.de, Tel.: Verantwortung Projektleitung icms: Alexis Steppat FH Mainz: Projektleitung icms/qm: Burkhard Simon, burkhard.simon@fh-mainz.de, Tel.: Projektleitung icms/controlling: Dagmar Liebscher HS Trier QM: Barbara Hellinge, b.hellinge@hochschule-trier.de, Tel.: icms-projektbeauftragter: Martin Greving FH Worms: NN Seite 2

3 Inhalt 1. Einleitung Hintergrund / Ziele Prozessmodellierung an den Hochschulen in Rheinland-Pfalz Zweck des Dokuments Weiterentwicklung des Dokuments Zielgruppe Aufgaben der Hochschulen Grundsätze ordnungsmäßiger Modellierung Notation Konventionen zur Modellierung Ordnerstrukturen Organisationssicht / Organigramm Datensicht / Dokumente Prozesssicht Ebenen- Konzept Wertschöpfungskettendiagramm (WKD) Strukturierung der Prozesslandkarte Business Process Model and Notation (BPMN) Prozessattribute Modellierungsrichtlinien Allgemeine Namenskonventionen Benennung von Aufgaben Benennung von Ereignissen Benennung nach Entscheidungen Benennung von Organisationseinheiten Darstellungsempfehlungen BPMN-spezifische Modellierungsregeln Seite 3

4 Abbildungsverzeichnis Abbildung 1. Beispiel Organigramm Abbildung 2. Beispiel der Prozesslandkarte Abbildung 3. Beispiel der Wertschöpfungskette im Bereich der Kernprozesse Abbildung 4. Beispiel Prozess BPMN Tabellenverzeichnis Tabelle 3. Pools / Lanes Tabelle 4. Symbole eines Prozessdiagramms Aufgaben (Activities) Tabelle 5. Symbole eines Prozessdiagramms Ereignisse (Events) Tabelle 6. Gateway-Symbole Tabelle 7. Sequenzen Tabelle 8. Assoziationen Seite 4

5 Abkürzungsverzeichnis Begriff BPM BPMN DBMS ERP IT GoM OLAT OMG WKD Definition Business Process Management / Geschäftsprozessmanagement Business Process Model and Notation Database Management System Enterprise Ressource Planning Informationstechnologie Grundsätze ordnungsmäßiger Modellierung Online Learning And Training Object Management Group Wertschöpfungskettendiagramm Seite 5

6 Überblick über die verwendeten BPMN-Symbole Standard Individuel Swimlanes Flüsse Gateway s Ereigniss e Start Zwischen Ende Aktivitäten Daten Artefakt e Assoziationen Ungerichtete Assoziation l Seite 6

7 1. Einleitung 1.1. Hintergrund / Ziele Die sieben Fachhochschulen des Landes Rheinland-Pfalz setzen zur EDV-Unterstützung im sogenannten Student Life Cycle derzeit Module der HIS GX-Generation ein. Im Zuge des Auslaufens des Supports für diese Software Generation und aufgrund der dadurch entstandenen Notwendigkeit für die Planung eines Nachfolgesystems haben sich die rheinlandpfälzischen Fachhochschulen für die Durchführung eines gemeinsamen, landesweiten Projekts entschlossen. Damit wird das Ziel verfolgt, ein integriertes Campus Management System (icms) zu implementieren, das die Qualität des Services im Studienmanagement nachhaltig optimiert. Im Bereich Studium und Lehre verändern sich die Anforderungen rasant. Daraus resultieren auch Chancen, die langfristig zu einer Verbesserung der Qualität von Lehre, Forschung und Studium beitragen werden. Folgende Vorteile werden von der Einführung eines icms erwartet: - Qualitative Verbesserung der Prozesse im Student Life Cycle, - Qualitative Verbesserung der Hochschulsteuerung, - Ablösung und Modernisierung der alten IT-Infrastruktur, - Straffung und Ausrichtung der Hochschulgeschäftsprozesse hinsichtlich Bologna und Hochschulpakt, - Qualitätssteigerung in der Bearbeitung von Hochschulgeschäfts- und Organisationsprozessen, - Ausloten von Synergien im Bereich des Qualitäts- und Prozessmanagements sowie im Bereich der IT durch hochschulübergreifende Aufgabenbewältigung, - Einsparung von Ressourcen durch einen gemeinsamen Beschaffungsprozess. Im Verlauf der Zusammenarbeit der Hochschulen ist deutlich geworden, dass eine gemeinsame Prozessbetrachtung im Hinblick auf die Implementierung eines icms erforderlich ist. Dafür wurde eine Arbeitsgruppe BPM Business Process Management eingerichtet, die in Abstimmung mit den jeweiligen Beauftragten an den verschiedenen Hochschulen Prozessbereiche definiert und Prozesse aufnimmt, die von einem icms zukünftig abgebildet werden. Diese Ist-Prozesse werden in einem nächsten Arbeitsschritt in Soll- Konzeptionen überführt. Die Entwicklung eines landesweiten Konventionshandbuchs dient als gemeinsame Arbeitsgrundlage aller beteiligten Hochschulen für eine Prozessaufnahme und analyse, die einem einheitlichen Darstellungsstandard folgt. Am Ende dieser Maßnahmen steht die Etablierung IT-gestützter prozessorientierter Prozessmanagementsysteme, die bei gleichbleibenden Ressourcen zur Transparenz und Effizienz im Sinne eines kontinuierlichen Verbesserungsprozesses beitragen sollen Prozessmodellierung an den Hochschulen in Rheinland-Pfalz Die Modellierung von Geschäftsprozessen an den Hochschulen in Rheinland-Pfalz dient verschiedenen Zielen, wie z. B. Schaffen von Transparenz und einem einheitlichen Verständnis der Prozesse Dokumentation und Kommunikation für Mitarbeiter/innen, Studierende und Partner der Hochschulen Wissenstransfer an neue Mitarbeiter/innen Festlegen verbindlicher Abläufe, z. B. im Rahmen der Systemakkreditierung Grundlage für ein Qualitätsmanagement-System Nachweis der Ordnungsmäßigkeit von Prozessen Seite 7

8 Analyse und Verbesserung von Prozessen Verfahrensanweisungen für Mitarbeiter/innen Einführung von Informationssystemen, z. B. einem Campusmanagement-System Wissenstransfer zwischen den Hochschulen, z. B. mit Hilfe von Referenzmodellen. Je nach Modellierungszweck und Modellierungsgegenstand können sich die Modelle unterscheiden, z. B. hinsichtlich Umfang und Detaillierungsgrad. Dennoch ist es sinnvoll, innerhalb jeder Hochschule eine Prozessarchitektur aufzubauen und sich auf gewisse Modellierungskonventionen zu einigen. Damit wird es leichter, Modelle zu verstehen und den inhaltlichen Zusammenhang zwischen unterschiedlichen Modellen herzustellen. Die Konventionen dienen außerdem als Hilfestellung für die Modellierer/innen. Auch wenn sich die Hochschulen und die jeweils vorliegenden Voraussetzungen unterscheiden, ist es dennoch hilfreich, die verwendeten Modellierungsnotationen und konventionen miteinander abzustimmen und sich zumindest bis zu einem gewissen Grad auf gemeinsame, hochschulübergreifende Festlegungen zu einigen. Dies hat folgende Vorteile: Die Diskussion und der Gedankenaustausch in gemeinsamen Arbeitsgruppen, z. B. der Qualitätsmanagementbeauftragten, werden durch ein gemeinsames Verständnis sowie durch gleichartige Modelle und ähnliche Prozessarchitekturen vereinfacht. Prozessmodelle können einfacher ausgetauscht werden. Hierdurch werden der Wissenstransfer und das Lernen von anderen unterstützt. Gute Lösungen können als Best Practices verbreitet werden. Es können Referenzmodelle auf Basis der einheitlichen Konventionen erstellt werden, die wiederum als Grundlage für die Entwicklung und Verbesserung der Prozesse an einzelnen Hochschulen genutzt werden können. Auf Basis übergreifender Konventionen lassen sich einheitliche Dokumentationen und Anforderungsspezifikationen in gemeinsam durchgeführten Initiativen erstellen, z. B. bei der gemeinsamen Ausschreibung für ein Campusmanagement-System Zweck des Dokuments Zweck des Konventionshandbuches ist es, die Vielfalt der angebotenen Modellierungsmöglichkeiten auf eine sinnvolle und überschaubare Auswahl zu beschränken. Es ist die Grundlage für eine einheitliche Methodik zur Prozess- und IT-Dokumentation sowie -Modellierung. Vorrangiges Ziel der Arbeit ist die standardisierte Dokumentation der Geschäftsprozesse (einheitliches Prozessmodell). Um das Ziel der gemeinsamen Modellierung und des Austauschs von Prozessmodellen über gemeinsam verwendete Tools oder Austausch-Schnittstellen möglichst effektiv verwirklichen zu können, muss gewährleistet sein, dass alle beteiligten Modellierer und Modelliererinnen eine gemeinsame Modellierungssprache sprechen. Neben der allgemeinen Festlegung auf eine einheitliche Notation, Business Process Model and Notation (BPMN), müssen detaillierte Vereinbarungen getroffen werden. Nur so können die folgenden Vorteile einer modellhaften Dokumentation der Geschäftsprozesse genutzt werden: Vereinheitlichung von Modellen Konsistenz der Modelle Erhöhung der Verständlichkeit und Akzeptanz der Modelle Vermeidung von Redundanzen und Widersprüchlichkeiten Reduktion der Komplexität Grundlage für Analysen und Vergleiche von Prozessen Seite 8

9 Wiederverwendbarkeit für verschiedene Zwecke Vergleichbarkeit von Modellen (z.b. SOLL IST) Vereinfachung und Steigerung der Effizienz der Modellierung 1.4. Weiterentwicklung des Dokuments Ausgangspunkt für dieses Dokument war das Konventionshandbuch der Hochschule Koblenz, das im zweiten Schritt um Vorschläge und Konventionen anderer rheinland-pfälzischer Hochschulen erweitert wurde. Die jeweiligen Ansprechpersonen an den Hochschulen (siehe S. 2) sind für die Weiterentwicklung der Modellierungsrichtlinien landesweit sowie hochschulintern verantwortlich. Auf der entsprechenden OLAT- Plattform werden notwendige Anpassungen der Modellierungsrichtlinien diskutiert und abgestimmt. Die Vorschläge für gemeinsame Konventionen im vorliegenden Dokument stellen einen Kern an landesweiten Modellierungsempfehlungen dar. Darüber hinaus gehende individuelle Modellierungsrichtlinien werden in zusätzlichen hochschulspezifischen Konventionshandbüchern definiert, die als Ergänzung zu den landesweiten Standards zu verstehen sind. Die hochschulspezifischen Modellierungshandbücher werden auf OLAT eingestellt, so dass sie für alle Hochschulen zugänglich sind. Zugleich sind alle Hochschulen aufgerufen, Vorschläge für Änderungen und Erweiterungen in die Weiterentwicklung des vorliegenden Dokuments und damit den landesweiten Modellierungsempfehlungen einzubringen. Das vorliegende Dokument und die hochschulspezifischen Zusatzkonventionshandbücher werden ständig weiterentwickelt Zielgruppe Zielgruppe des Konventionshandbuches sind Modellierer/innen und User. Modellierer/innen besitzen die Rechte, die Prozesse zu modellieren und zu bearbeiten. User (Studierende, Lehrende, Mitarbeiter/innen) besitzen die Rechte, die Prozesse zu lesen Aufgaben der Hochschulen Das vorliegende Dokument besitzt eine beratende Funktion für die Hochschulen, aber keine bindende. Darüber hinaus ist jede Hochschule u. a. für folgende Aufgaben selbst verantwortlich: Prüfung, ob die vorliegenden Modellierungskonventionen für die konkrete Situation der Hochschule geeignet sind. Ggf. hochschulspezifische Anpassung und Erweiterung der Modellierungskonventionen Erstellung, Qualitätssicherung, Freigabe und Weiterentwicklung der Modelle Nutzung der Modelle Sicherstellung, dass die Modelle vertraulich bleiben - soweit dies erforderlich ist Auswahl geeigneter Modellierungstools und ggf. Hostingdienstleister Administration, Schulung und Bedienung des Modellierungstools Datensicherung der Modelle Seite 9

10 2. Grundsätze ordnungsmäßiger Modellierung Die Grundsätze ordnungsmäßiger Modellierung (GoM) geben Empfehlungen zur Darstellung, Detaillierung etc. ab, die über die Regelungen der Methoden (WKD, BPMN) hinausgehen. Folgende Grundsätze wurden definiert 1 : Grundsatz des systematischen Aufbaus Der Grundsatz des systematischen Aufbaus besagt, dass eine sichtenübergreifende Konsistenz der Modelle hergestellt werden kann. Demnach kann die Organisationseinheit, die im Geschäftsprozess modelliert wurde, auch im Organigramm wiedergefunden werden. Grundsatz der Richtigkeit Der Grundsatz der Richtigkeit lässt sich untergliedern in die syntaktische Richtigkeit und die semantische Richtigkeit. Die syntaktische Richtigkeit ist gegeben, wenn die ausgewählte Modellierungsmethode richtig eingesetzt wird. Die semantische Richtigkeit gibt vor, dass die korrekte inhaltlich-fachliche Darstellung gewährleistet sein muss. Grundsatz der Relevanz In einem Prozessmodell müssen alle Elemente hinsichtlich des Modellierungszweckes relevant sein. Aus diesem Grund ist es wichtig, dass man sich den Zweck der Modellierung im vornherein bewusst macht. Grundsatz der Wirtschaftlichkeit Die Modellierungsmethode sollte durch den erzielten Nutzen, d.h. durch die qualitativen, quantitativen und monetären Vorteile der Modellerstellung, überkompensiert werden. Um dies zu ermöglichen, muss ein optimaler Detaillierungsgrad der Modelle gefunden werden. Grundsatz der Klarheit Der Grundsatz der Klarheit beinhaltet, dass die erstellten Modelle übersichtlich, lesbar und gut verständlich sein müssen. Sie sollten so einfach wie möglich und nur so kompliziert wie nötig sein. Dabei sollte u.a. auf die Anforderungen der entsprechenden Zielgruppen der Modellierung eingegangen werden. Grundsatz der Vergleichbarkeit Der Grundsatz der Vergleichbarkeit ist gegeben, wenn eine einheitliche oder zumindest übertragbare Modellierungsmethode verwendet wird. 3. Notation Für die Prozessdarstellung kommt in der Regel die BPMN-Methode zum Einsatz. Die Business Process Model And Notation (BPMN) ist ein Industriestandard der Object Management Group (OMG) und dient der grafischen Darstellung und Modellierung von Geschäftsprozessen und deren Interaktionen. 1 Becker, Jörg; Schütte, Reinhard: Handelsinformationssysteme.2. Auflage, Frankfurt am Main: Verlag Moderne Industrie 2004, S. 128f. Seite 10

11 4. Konventionen zur Modellierung In diesem Abschnitt werden die Regelungen beschrieben, die die operative Umsetzung regeln sollen. Ein wesentlicher Aspekt der Methode ist die Zerlegung des Gesamtsystems und Verwendung von verschiedenen Sichten und Ebenen: Datenbank (Repository) Organisationssicht, Datensicht, Prozesssicht Ordnerstrukturen Die Ablage von Modellen wird in Ordnerstrukturen organisiert. Zur Gliederung der Ordnerstruktur können folgende Kriterien genutzt werden: Verantwortlichkeitsbereich für die Modellierung. Z. B. kann für jeden Fachbereich oder jedes Dezernat ein Ordner eingerichtet werden, in dem diese ihre eigenen Modelle ablegen. Status des Modells, z. B. In Arbeit oder Freigegeben Hierarchieebene (Prozesslandkarte, Hauptprozesse, Geschäftsprozesse, Einzelprozesse, ) Modellierungssicht (Prozesse, Organisation, ) Prozessarten (z. B. Ordner für Kern-, Supportprozesse usw.) Hauptprozesse (z. B. Ordner für Studium und Lehre, Forschung usw.) Die Kriterien können kombiniert angewandt werden, z. B. kann auf oberster Ebene nach Modellstatus unterschieden werden, auf der zweiten Ebene nach Hierarchieebene und auf der dritten Ebene nach Prozessarten. Eine einheitliche Ordnerstruktur wird nicht vorgegeben, da die Organisation an den verschiedenen Hochschulen zu unterschiedlich ist. Informationen hierzu finden Sie im individuellen Konventionshandbuch jeder einzelnen Hochschule Organisationssicht / Organigramm In der Organisationssicht wird die Aufbauorganisation beschrieben. Wichtigster Modelltyp ist hier das Organigramm, in dem die statischen, hierarchischen Beziehungen von Organisationseinheiten wie Referaten, Abteilungen oder auch Stellen beschrieben und definiert werden. Organigramme werden an jeder Hochschule zentral erstellt und Bezeichnungen in diesem Zuge vergeben. Sie bedürfen der kontinuierlichen Aktualisierung. Die in folgender Übersicht verwendeten Symbole sind als Erläuterungshilfe zu verstehen. An jeder Hochschule können spezifische Symbole Verwendung finden. Es sollte aber an jeder Hochschule ein Organigramm existieren, um eine konsistente Verwendung von Begriffen in den Prozessen gewährleisten zu können. Seite 11

12 Tabelle 1. Symbole der Organisationssicht Symbol OPTIONAL Objekttyp Name & Definition Standort Der Standort beschreibt die geografische Lage bspw. einer Abteilung. Organisationseinheit Organisationseinheiten sind zusammengehörige Bereiche einer Organisation (z.b. Geschäftsbereiche oder Abteilungen). Sie kommen im Organigramm i.d.r. jeweils nur einmal vor. Rolle Rollen sind eine Abstraktion von Positionen bzw. Zusammenfassung von gleichen Tätigkeitsbereichen (z.b. Abteilungsleiter, Sachbearbeiter), die im Organigramm mehrfach vorkommen können, da sie sich nicht explizit auf eine Organisationseinheit beziehen. Person Eine Person ist eine namentlich genannte, konkrete Person. Namenskonvention Standorte sind mit offiziellen Bezeichnungen benannt. Organisationseinheiten sind mit offiziellen Bezeichnungen benannt. Rollen sind mit offiziellen Bezeichnungen benannt. Personen werden benannt mit Titel, Vorname und Nachname. Abbildung 1. Beispiel Organigramm Seite 12

13 4.3. Datensicht / Dokumente Die Datensicht dient der Dokumentation ein- und ausgehender Daten in Form von Dokumenten, Protokollen o.ä. In der Datensicht wird die (statische) Struktur der im Untersuchungsbereich verwendeten Nutzendaten beschrieben. Die Beschreibung der Datenstruktur ist in erster Linie für Projekte im Bereich Anwendungssystementwicklung vonnöten, da aus ihr das notwendige Datenbankschema abgeleitet wird. Daher werden an dieser Stelle keine einheitlichen Vorgaben für die Datenmodellierung gegeben Prozesssicht In der Prozesssicht werden die Prozesse in ihrem zeitlich logischen Ablauf beschrieben. Sie ist damit von grundlegender Bedeutung für ein Projekt zur Prozessmodellierung und -verbesserung. Im Gegensatz zu den rein statischen Beschreibungen der anderen Sichten wird hierunter die Verwendung der in eben diesen Sichten definierten Organisationseinheiten, Funktion und Daten - Prozesse in ihrer dynamischen Folge dargestellt. Relevant für die Prozesssicht sind Das Ebenen-Konzept Prozesslandkarten und Wertschöpfungsdiagramme BPMN-Modelle Seite 13

14 4.5. Ebenen- Konzept Das prinzipielle Ebenenkonzept, das von allen Hochschulen verwendet wird, ist folgendermaßen aufgebaut: Abbildung 2. Ebenen- Konzept Optional kann eine Zwischenebene 3. a oder 4. a eingezogen werden, so dass die Hochschulen nach Bedarf über sechs Ebenen verfügen. Das Ziel sollte aber sein, nicht mehr als sechs Ebenen zu verwenden. Diese Zwischenebenen könnten für die Varianten genutzt werden (Typenbildung). Bei der Benennung der Ebenen sind hochschulspezifische Varianten möglich. Seite 14

15 4.6. Wertschöpfungskettendiagramm (WKD) Das Wertschöpfungskettendiagramm zeigt einen groben Überblick über einen Prozess und seine Gliederung in Unterprozesse. Über die Wertschöpfungskette ist der logische Ablauf der einzelnen Unterprozesse ersichtlich. Tabelle 2. Symbole der Wertschöpfungskette Symbol Objekttyp Name & Definition Funktion Funktion (WKD-Anfang) Das Wertschöpfungskettendiagramm dient im Wesentlichen zur Darstellung übergeordneter Prozessstrukturen und Hierarchien bzw. um einen oder mehrere Unterprozesse oder Aktivitäten zu repräsentieren. In WKDs beschreibt dieses Symbol die aggregierten Aufgaben z.b. auf den Ebenen 1 bis 3 des Prozessmodells und wird am Beginn der Wertschöpfungskette eingesetzt. Funktion Funktion (WKD- Fortsetzung) Dieses Symbol hat die gleiche Bedeutung wie das oben genannte. Es wird jedoch bei einem nachfolgenden Prozessschritt in einer Wertschöpfungskette eingesetzt. Namenskonvention Der Name einer Wertschöpfungskette wird aus einem (zusammengesetzten) Substantiv gebildet; z. B.: Haushalt, Beschaffung, Materialbewirtschaftung, etc. s. Funktion WKD-Anfang Die folgenden Abbildungen zeigen ein Beispiel, wie Wertschöpfungskettendiagramme eingesetzt werden können. Hier werden zusätzlich Rahmen zur Abgrenzung von Prozessarten und Prozessbereichen eingesetzt, d. h. diese Einteilungen werden nicht hierarchisch modelliert, sondern nur optisch hervorgehoben. Ansonsten finden keine Hierarchiedarstellungen innerhalb eines Modells statt. Hierarchien werden nicht durch Kanten, sondern nur durch Hinterlegungen modelliert. Seite 15

16 4.7. Strukturierung der Prozesslandkarte Für die landesweiten Modellierungsrichtlinien wird eine Musterprozesslandkarte empfohlen, die generell eine 3er-Gliederung in Steuerungsprozesse, Kernprozesse und Unterstützungsprozesse vorsieht und folgende Elemente enthält: Abbildung 3. Beispiel der Prozesslandkarte (WKD) Abbildung 4. Beispiel der Wertschöpfungskette im Bereich der Kernprozesse Seite 16

17 4.8. Business Process Model and Notation (BPMN) BPMN-Diagrammarten Das Ziel dieser Diagrammart ist es, Abläufe zur Durchführung einer Aufgabe mit ihren einzelnen Schritten zu definieren und darzustellen. Dabei beschreiben die Knoten im Prozessgraphen einzelne Tätigkeiten oder Ereignisse. Kollaborationsdiagramm Kollaborationsdiagramme stellen den Austausch von Nachrichten zwischen Prozessbeteiligten dar. Zusätzlich wird hier jedoch eine stärkere Verbindung zu den Prozessdiagrammen geschaffen und die Aufgaben der einzelnen Prozessbeteiligten werden mehr betont. Abbildung 5. Beispiel Prozess BPMN BPMN Symbolauswahl Tabelle 3. Daten Symbol Objekttyp Name & Definition Datenobjekte Datenobjekte beschreiben Prozessschritte näher und/oder müssen bei der Ausführung der Prozessschritte beachtet werden (z.b. Prozessanweisungen oder Gesetze). Sie werden i.d.r. nicht im Prozessschritt verarbeitet [vgl. hierzu das Symbol Input/Output ]. Erläuterungen Ein Datenobjekt repräsentiert Informationen, die durch den Prozess fließen, wie z.b. Dokumente, Vorlagen, Formulare, Datensätze etc. Seite 17

18 Symbol Objekttyp Name & Definition Datenspeicher Ein Datenspeicher ist ein Ort, auf den der Prozess lesend und schreibend zugreifen kann, z.b eine Datenbank oder ein Aktenschrank. Er existiert unabhängig von der Lebensdauer der Prozessinstanz. Textanmerkung Eine Annotation ist ein Kommentar, der einem Element eines Geschäftsprozesses zugeordnet werden kann. Erläuterungen Tabelle 4. Pools / Lanes Symbol Objekttyp Name & Definition Soll in einem Prozessmodell erkennbar gemacht werden, wer für die Ausführung von Tasks oder Subprozessen verantwortlich ist, so bietet die BPMN 2.0 die Modellierungselemente Pool und Lane an. Pool Ein Pool repräsentiert eine Verantwortliche oder einen Verantwortlichen in einem Ablauf. Dies kann beispielsweise eine übergreifende Organisationseinheit, Abteilung, oder auch ein übergreifendes Softwaresystem sein. Lane Eine Lane ist eine Unterteilung eines Pools, die sich über die komplette Länge des Pools erstreckt. Sie wird zur Zuordnung einer oder eines Prozessbeteiligten (dies kann auch eine Organisationseinheit, eine Abteilung, eine definierte Rolle sowie Person, oder auch ein Softwaresystem sein.) zu den Aktivitäten eines Prozesses verwendet. Eine Lane unterbricht dabei nicht den Fluss (Sequenz) eines Prozesses. Aufgaben Tabelle 5. Symbole eines Prozessdiagramms Aufgaben (Activities) Symbol Objekttyp Name & Definition Aufgabe Eine Aufgabe beschreibt eine Arbeitseinheit, eine Tätigkeit, die in einem Prozessschritt zu erledigen ist. Aufgabe / Teilprozess Eine Aufgabe, unter der ein Teilprozess hinterlegt ist. Eine Namenskonvention Der Name einer Aufgabe wird mindestens aus einem Substantiv und einem Verb im Infinitiv gebildet, um die Art und Weise der Tätigkeit zu beschreiben: Unterlage scannen, Rechnung freigeben, etc. Seite 18

19 Symbol Objekttyp Name & Definition elementare Aufgabe heißt Task, komplexere Aufgaben werden als Subprozess bezeichnet. Subprozesse können in kollabiertem oder expandiertem Zustand dargestellt werden. Namenskonvention Ereignisse Tabelle 6. Symbole eines Prozessdiagramms Ereignisse (Events) Symbol Objekttyp Name & Definition Namenskonvention Ein Event (Ereignis) ist etwas, das sich in einem Geschäftsprozess ereignen kann, zum Beispiel das Eintreffen einer Nachricht, das Erreichen eines bestimmten Datums oder das Auftreten einer Ausnahmesituation. Link (eingehend - vorheriger Prozess) Modelliert ein Verbindungselement für verschiedene Prozessabschnitte. Link Events können als Sprünge im Prozessmodell verwendet werden, um beispielsweise lange Sequence Flow-Linien quer durch ein Prozessmodell zu verhindern. Für den Ausdruck von Prozessmodellen auf Papier können sie den Seitenübergang verdeutlichen. Im hochschulübergreifenden Modellierungshandbuch wird an dieser Stelle lediglich auf die Thematik aufmerksam gemacht. Die Verwendung dieses Verbindungselements kann an den jeweiligen Hochschulen unterschiedlich sein. Deshalb wird an dieser Stelle auf die hochschulspezifischen Modellierungshandbücher verwiesen. Link (ausgehend - Folgeprozess) s. Link (eingehend - vorheriger Prozess) Start- Ereignis Ein Start-Ereignis erkennen Sie an der dünnen äußeren Line. Es markiert den Start eines Prozesses und hat keinen eingehenden Prozessfluss (Sequenz). Sie beschreiben einen eingetretenen, relevanten betriebswirtschaftlichen Zustand. Der Name eines Ereignisses wird mindestens aus einem Substantiv und einem Verb im Partizip Perfekt gebildet, um das Eingetreten sein eines Zustandes zu beschreiben; z. B.: Rechnung ist eingegangen, Vertrag liegt vor etc. Seite 19

20 Symbol Objekttyp Name & Definition Zwischen- Ereignis Ein Zwischen-Ereignis erkennen Sie an zwei dünnen äußeren Linien. Es hat immer mindestens einen eingehenden und einen ausgehenden Prozessfluss (Sequenz). Wird beispielsweise verwendet, um eine Statusänderung zu propagieren. End- Ereignis Ein End-Ereignis erkennen Sie an der dicken äußeren Line. Es markiert das Ende eines Prozesses und hat keinen ausgehenden Prozessfluss (Sequenz). Timer Periodische zeitliche Ereignisse, Zeitpunkte oder Zeitspannen Namenskonvention s. Start- Ereignis s. Start- Ereignis Ermöglicht die Definition eines bestimmten Zeitpunkts, zu dem ein Prozess starten soll. Wird vor allem bei regelmäßig auszuführenden Prozessen verwendet. Nachricht Empfang einer Nachricht Eine Nachricht trifft von einem externen System ein und startet damit einen Prozess oder einen Event-Subprozess. Als externes System werden dabei vor allem weitere Prozesse oder Web Services verwendet. In BPMN werden Ereignisse tatsächlich nur dort modelliert, wo sie benötigt werden. D. h. nach Entscheidungen sind keine Ereignisse erforderlich. Schnittstellen als solche existieren in BPMN nicht, so dass hierfür eine geeignete Modellierungskonvention vorzusehen ist, z. B. in Verbindung mit Start- bzw. End-Ereignis und einer Textanmerkung. Seite 20

21 Gateways Tabelle 7. Gateway-Symbole Symbol Objekttyp Name & Definition Erläuterungen Ein Gateway beschreibt einen Entscheidungspunkt (Aufteilung) oder einen Punkt, an dem verschiedene Kontrollflüsse zusammenlaufen (Zusammenführung). Ein Gateway wird als Rhombus gezeichnet. Das Symbol im Inneren definiert seinen Einfluss auf den Prozessfluss. Exklusives Gateway XOR = entweder/oder (d.h. nur ein Pfad möglich). Genau einem ausgehenden Prozesspfad muss gefolgt werden. Genau ein eingehender Prozesspfad muss erfüllt sein. Inklusives Gateway OR = oder (d.h. mehrere Pfade möglich) Bei einer Zusammenführung wird auf eine der eingehenden Kanten gewartet, um den ausgehenden Fluss zu aktivieren. Inklusives Gateway. Es werden je nach Bedingung eine oder mehrere ausgehende Kanten aktiviert bzw. eingehende Kanten synchronisiert. Paralleles Gateway AND = und (d.h. alle Pfade notwendig) Allen ausgehenden Prozesspfaden muss gefolgt werden. Alle eingehenden Prozesspfade müssen erfüllt sein. Wenn der Sequenzfluss verzweigt wird, werden alle ausgehenden Kanten simultan aktiviert. Bei der Zusammenführung wird auf alle eingehenden Kanten gewartet, bevor der ausgehende Sequenzfluss aktiviert wird (Synchronisation). Kanten / Sequenzen Tabelle 8. Sequenzen Symbol Objekttyp Name & Definition Nachricht Ein Nachrichtenfluss zeigt an, dass zwei Elemente in einem Kollaborationsdiagramm Meldungen austauschen. Nachrichtenflüsse verbinden Aufgaben, Teilprozesse, Ereignisse oder Pools (Flussobjekte) mit anderen Aufgaben, Teilprozessen, Ereignissen oder Pools. Nachrichten sind immer poolübergreifend. Sequenz Sequenzflüsse verbinden Aufgaben, Gateways und Ereignisse. Sie zeigen als Kontrollfluss, in welcher Reihenfolge Aufgaben ausgeführt werden. Seite 21

22 Assoziationen Tabelle 9. Assoziationen Symbol Objekttyp Name & Definition Ungerichtete Assoziation Verbindet ein Datenobjekt mit einem Sequenzfluss und gibt damit an, welche Daten zwischen den Aktivitäten weitergegeben werden. Verbindet Anmerkungen mit dem Objekt, auf die sie sich beziehen. Gerichtete Assoziation Ausgehende Kanten zeigen Output, eingehende zeigen Input an Prozessattribute Prozessattribute werden in den jeweiligen hochschulspezifischen Modellierungshandbüchern definiert. Lediglich der Name des Prozesses wird als eine MUSS-Angabe landesweit empfohlen. Die unten stehende Tabelle zeigt Vorschläge auf, welche Prozessattribute Eingang in die Modellierungskonventionen der jeweiligen Hochschulen finden können. Tabelle 10. zu pflegende Modellattribute und deren Bedeutung Attribut Definition Soll/Muss Name Beschreibung Name des Prozesses, z.b Lehrveranstaltungsplanung Detaillierte Beschreibung Prozessverantwortlicher Prozessmodellierer Prozessziel Hinterlegungen Verknüpfungen Status seit/am Erstellt von Geprüft von Freigegeben von Organisation Berichtsformat Name bzw. Rolle der oder des Prozessverantwortlichen Name der Modelliererin oder des Modellierers Definition des Ziels, das mit dem Ablauf erreicht werden soll Unter Hinterlegungen versteht man hinterlegte Folge-, Teilprozesse Unter Verknüpfungen versteht man einen Link zum Abrufen der externen Informationen; z.b. Datei, Internetseite etc. Status zeigt in welchem Stadium sich der Prozessentwurf befindet; in Bearbeitung, Fertig, Freigegeben. seit/am zeigt seit wann trat der Prozess in Kraft. Name der Prozessmodelliererin oder des Prozessmodellierers Name der Prozessexpertin oder des Prozessexperten Name der oder des Prozessverantwortlichen Bezeichnung der Abteilung, die für reibungslosen Prozessablauf verantwortlich ist. Orientierung = Querformat - optional zu pflegende Attribute (Soll) - immer zu pflegende Attribute (Muss) Seite 22

23 5. Modellierungsrichtlinien Namenskonventionen Zweck von Namenskonventionen: - Alle Objekte (Aufgaben, Ereignisse, Dokumente, Organisationseinheiten usw.) werden eindeutig identifiziert. - Für die Fachbereiche erfolgt die eindeutige Identifizierung der Objekte über deren Namen. Die Einhaltung der Namenskonventionen führt einerseits zu einem einheitlichen und übersichtlichen Erscheinungsbild der Dokumentation (einfachere Lesbarkeit und Verständlichkeit) und andererseits werden Redundanzen vermieden, wird die Wiederverwendbarkeit von bereits erstellten Objekten und Dokumentationen ermöglicht und sind verschiedene, aussagekräftige Auswertungsmöglichkeiten der Datenbank sichergestellt 5.1. Allgemeine Namenskonventionen Sprache Die Modellierung erfolgt grundsätzlich auf Deutsch. Korrekte und einheitliche Schreibweise Bei der Namensgebung ist auf die Rechtschreibung zu achten und eine einheitliche Schreibweise einzuhalten. Namensidentität Der Name eines Objektes entspricht dem Namen des hinterlegten Modells. Demnach ist z.b. die Bezeichnung einer Aktivität identisch mit dem Namen des durch sie aufgerufenen Modells. Eindeutige Bezeichnung Objekte sind so zu benennen, dass der Sachverhalt deutlich daraus hervorgeht. Ein Beispiel ist das häufig auftretende Versenden von Dokumenten. Sollte im Laufe des Prozesses eine entsprechende Funktion vorkommen, ist die vereinfachte Benennung Dokument versenden zu vermeiden und wenn möglich der eindeutige Name des Dokumentes zu verwenden (z.b. Prüfungsprotokoll versenden ). Kombinationsbenennungen Objektnamen sollten keine Kombinationen beinhalten, z.b. von verschiedenen Tätigkeiten oder Ereignissen (z.b. Dokument ausfüllen und verschicken ). Um dies zu umgehen, sollte entweder ein gemeinsamer Oberbegriff verwendet oder die Funktionen/Ereignisse einzeln aufgeführt werden. Ggf. ist zwischen der Übersichtlichkeit des Modells und der Vermeidung von Kombinationsbezeichnungen zu entscheiden. Verbot von Eigennamen (nur beim externen Austausch der Prozesse) In Modell- und Objektnamen sind Namen von Beteiligten, Adressaten etc. verboten. Verbot technischer Kürzel Die Verwendung technischer oder anderer nicht allgemein bekannter Kürzel ist nicht erlaubt. Seite 23

24 5.2. Benennung von Aufgaben Der Name einer Aufgabe wird mindestens aus einem Substantiv und einem Verb im Infinitiv gebildet, um die Art und Weise der Tätigkeit zu beschreiben (Unterlage scannen, Rechnung freigeben, etc.): 1. Name des Bearbeitungsobjektes / Sachverhaltes (Substantiv, ohne Artikel) 2. Verb, das die Verrichtung dieses Bearbeitungsobjekts / diesen Sachverhalt beschreibt (Verb im Infinitiv) 5.3. Benennung von Ereignissen Die Bezeichnung von Ereignissen wird aus folgenden beiden Teilen gebildet (z.b. Kundin/Kunde hat angerufen, Studienbescheinigung ist verschickt, etc.): 1. Name des Bearbeitungsobjektes / Sachverhaltes (Substantiv im Singular) 2. Verb abgeleitet aus vorangegangener Funktion oder als Zustandsbeschreibung (Verb in Partizipform) 5.4. Benennung nach Entscheidungen Wenn es sich um eine geschlossene Frage handelt bzw. wenn die Frage klar mit einem ja oder einem nein beantwortet werden kann, ist es zulässig, ledig ja oder nein an den entsprechenden Stellen im Modell einzutragen. Ansonsten sollte eine eindeutige Kennzeichnung bzw. Benennung der verschiedenen Alternativentscheidungen vorgenommen werden Benennung von Organisationseinheiten Die Benennung der Organisationseinheiten entspricht der jeweiligen Bezeichnung an der Hochschule. Um Missverständnisse aufgrund verschiedener Definitionen auszuschließen (z.b. Fakultät Fachbereich) sind die entsprechenden Beschreibungen aus dem Glossar der jeweiligen Hochschule zu beachten (siehe hochschulspezifische Modellierungshandbücher). Darüber hinaus sind die Bezeichnungen geschlechtsneutral zu halten (z.b. Dekan/-in) Darstellungsempfehlungen Um von den genannten Vorteilen der modellhaften Dokumentation von Geschäftsprozessen profitieren zu können, sollten folgende Anforderungen an die Darstellung erfüllt werden. Hinter den folgenden Regelungen steht die grundlegende Forderung, dass die erstellten Modelle auch für Außenstehende oder ungeübte Benutzer/innen übersichtlich und lesbar sein müssen. Ausrichtung Die BPMN-Diagramme werden horizontal modelliert. Detaillierungsgrad und Größe der Modelle Orientieren Sie sich an der Zielgruppe Die Modelle sollen Verständnis schaffen, nicht verwirren! Zu detaillierte Modelle sind schwer verständlich und aufwändig zu pflegen Seite 24

25 Beschränkung auf die wesentlichen Aspekte Ggf. wichtige Details in Anmerkungen erläutern Überlegen Sie sich, ob Zusatzinformationen wie Dokumente und Informationssysteme in der Grafik auftauchen sollen Erstellen Sie keine Prozesstapeten Die Beschriftungen sollten möglichst noch lesbar sein, wenn man das komplette Modell auf einem A4-Blatt ausdruckt. Ggf. Aufteilung auf mehrere Modelle Das Modell sollte bereits mit Hilfe der grafischen Darstellung verständlich sein: Aussagekräftige Namen verwenden, ggf. Anmerkungen verwenden Spezielle Farben und Hervorhebungen verwenden Farben sollen nicht aus optischen Gründen verwendet werden, sondern weil eine einheitliche, begründbare Farbgebung erfolgen soll, um z.b. Prozessvarianten unterscheiden zu können Attributplatzierung Zur Erläuterung einzelner Objekte können die gepflegten Objektattribute angezeigt werden. Dabei sollte darauf geachtet werden, dass diese durch geeignete Wahl der Platzierung eindeutig dem entsprechenden Objekt zugeordnet werden können und sich nicht mit anderen Attributen oder Objekten überschneiden. Symbolgröße Die Größe der Symbole ist entsprechend der Standardvorgabe zu übernehmen und sollte z.b. trotz längerer Objektbezeichnungen nicht verändert werden. Sequenzüberschneidungen Sequenzüberschneidungen sind möglichst zu vermeiden. Gegebenenfalls kann auf grafische Brücken bzw. Hinterlegungen und Prozessschnittstellen zurückgegriffen werden. Varianten Um trotz der hochschulspezifischen Unterschiede einen Austausch der Modelle zu ermöglichen, sind die Referenzprozesse möglichst allgemeingültig darzustellen. Dementsprechend wird auf die Modellierung von Ausnahmefällen verzichtet, wenn kein besonderer Grund vorliegt. Darüber hinaus ist es möglich, dass detailliertere Varianten dieser allgemeingültigen Modelle erstellt werden BPMN-spezifische Modellierungsregeln Exklusiver Gateway Wird mit Symbol (X) dargestellt Enthält i.d.r. eine Frage An den Kanten stehen die Antworten Endereignisse Unterschiedliche Ergebnisse eines Prozesses durch unterschiedliche Endereignisse darstellen Seite 25