Agiles Prozessmanagement für IT Unternehmen

Juli 3, 2007

Agilität durch Projektmanagement-Prozessmodule

Filed under: Bodies of Knowledge,Business Rules,PMI,Prozesse — Armin Guenther @ 14:56

 


Die obige Abbildung soll die „Anwendungslogik“ der Prozesse verdeutlichen, welche die Leistungserstellung, des Unternehmens für das die Diplomarbeit erstellt wird, konstituieren. Beispielhaft wird hier nur der Prozess „Risikomanagement“ mit den Teilprozessen R_1 bis R_6 aufgeführt.

Dabei zeigt die Abbildung die Dimensionen der Agilität, die sichergestellt werden sollte, auf. Das Unternehmenswachstum das auf der Abszisse abgetragen ist und die angestrebten Entwicklungsstufen des CMMI, welche in der Zukunft angestrebt werden können, verkörpern eine Form von Agilität. Die Entwicklungsstufen geben dabei den möglichen Entwicklungspfad vor, lassen aber Spielraum für die unternehmensindividuelle Ausgestaltung. Werden im Geschäftsjahr 2008 im Bereich des Projektmanagements die Projektplanung, die Projektverfolgung und Steuerung und das Management von Lieferantenvereinbarungen und im Bereich Ingenieurdisziplinen das Anforderungsmanagement sowie im Bereich der Unterstützung eine Messung und Analyse, eine Qualitätssicherung von Prozessen und Produkten sowie ein Konfigurationsmanagement im Sinne des CMMI (Definition der spezifischen Ziele und Auswahl der für TwentyOne sinnvollen Praktiken etc.) ausgestaltet, kann der Reifegrad „definiert“ als Verbesserungsziel („nächste Stufe“) bis zum Geschäftsjahr 2010 angestrebt werden. Die Verbesserungsaktivitäten sollten sich somit auf das Prozessmanagement (Organisationsweiter Prozessfokus, Organisationsweite Prozessdefinition, Organisationsweites Training) ausdehnen, ein integriertes Projektmanagement und verbessertes Risikomanagement forcieren, die Ingenieurdisziplinen weiter systematisieren und strukturieren (Anforderungsentwicklung, technische Umsetzung, Produktintegration, Verifikation, Validation) und eine fundierte Entscheidungsanalyse und -findung etablieren.

Der Leistungserstellungsprozess sowie die Wertsicherung und das Lernen werden den Prozessgruppen parallel zu der Ordinate gegenübergestellt. Die Prozessmodule (bspw. das Risikomanagement) werden mit Hilfe der dispositiven Geschäftsregeln an die
verschiedenen Projekttypen (z. B. Kleinprojekt = Typ A, Projekt= Typ B) angepasst. Der mit dem x gekennzeichnete Punkt zeigt dabei, welche Teilprozesse (R_1 – R_2) für welchen Projekttyp durchgeführt werden müssen, wobei der Gestaltungsrahmen für den Prozessgestalter durch Geschäftsregeln aufgespannt wird (solche dispositiven Regeln -vgl. jeweiligen Datenblättern Interne Dokumente – sichern also Agilität, da man mit ihnen unterschiedlichste Umweltzustände abbilden kann). Die übrigen Teilprozesse (schwarzer Punkt) müssen projektindividuell ausgestaltet werden. Operative Geschäftsregeln können hier den konkreten Prozessverlauf noch weiter spezifizieren.

Als dritte „Dimension“ der Agilität ist folgendes Vorgehen entwickelt worden. Das betreffende Unternehmen kann nun für jedes Prozessmodul (z.B. Risikomanagement) und dessen Teilprozesse feststellen, ob sie schon im Unternehmen durchgeführt werden oder ob sie für die Zukunft geplant sind. Zum Einsatz kann hier die Matrix mit den Process Groups und den Knowledge Areas (Vgl. PMBOK) mit den jeweiligen Teilprozessen kommen.

Ähnlich der Ampelfunktion bei der Anwendung der Geschäftsregeln (siehe Abbildung am Anfang des Beitrags) kann in der Matrix jeder Teilprozess betrachtet und evaluiert werden. Ein weiteres Instrument in diesem Zusammenhang ist die Übersicht/ Checkliste über die Projektmanagementmethoden(Vgl. Gareis/ Stummer, Projekte & Prozesse, 2006). In dieser kann für die verschiedenen Projekttypen festgelegt werden welche Methoden angewandt werden „müssen“ und welche angewandt werden „können“.

Juni 5, 2007

Modellierung von Geschäftsregeln mit der EPK

Filed under: Business Rules,Prozesse — Armin Guenther @ 11:36

In vorangegangenen Beiträgen wurde gezeigt, wie Prozessabläufe mit der EPK modelliert werden können und wie Abläufe mit der ECAA Notation modelliert werden. In diesem Beitrag soll gezeigt werden wie der regelbasierte Ansatz in die EPK integriert werden kann. Es ist möglich sowohl EPKs mit geeigneten Transformationsregeln in Geschäftsregeln zu übersetzen (diesen Ansatz verfolgen Knolmayer u.a.) als auch Geschäftsregeln mit der EPK zu modellieren. Steht die Visualisierung und Transparenz im Vordergrund kann der Geschäftsprozess mit der EPK gestaltet und dargestellt werden. Soll dieser weiter spezifiziert werden, um bspw. Informationssysteme zu entwickeln, können hieraus Geschäftsregeln abgeleitet und detailliert werden.

Es gibt vier grundlegende Transformationsregeln um EPK Modelle in die ECAA Notation zu überführen. Diese sind in der folgenden Grafik dargestellt:

Wenn man nun eine ECAA Regel betrachtet enthält diese implizit eine Selektion. Die folgende Abbildung zeigt die allgemeine Modellierung einer Selektion mit Hilfe der EPK:

 

Auch die Möglichkeiten der Gestaltung paralleler Abläufe werden direkt von der EPK Notation unterstützt. Man beachte aber stets, dass in beiden Notationen der Kontrollfluss durch einen Operator des gleichen Typs wieder geschlossen werden muss.

Mai 22, 2007

Geschäftsregeln im Kontext der Prozessmodellierung

Filed under: Business Rules,Prozesse — Armin Guenther @ 21:27

Da keine einheitliche Definition des Begriffs Geschäftsregel existiert, muss zunächst geklärt werden wie der Begriff im Rahmen dieser Arbeit aufgefasst wird. Der Begriff wird meist technisch bei der Entwicklung von Informationssystemen verwendet. Eine ausschließliche Fokussierung bspw. auf die Sicherstellung der Integrität in Datenbanken vernachlässigt die betriebswirtschaftliche Sichtweise des Begriffs. Geschäftsregeln beschreiben eben auch wie ein Unternehmen organisiert ist und wie es den Geschäftszweck erfüllt. Regeln werden also zunehmend als Aussagen über die Art und Weise der Geschäftsabwicklung verstanden. Geschäftsregeln enthalten Informationen über Anforderungen an Abläufe in einer Organisation. Endl setzt Geschäftsregeln mit organisatorischen Regeln gleich, da beide die effiziente Durchführung der Geschäftsprozesse als Ziel haben und somit Richtlinien und Restriktionen darstellen, die sich auf Zustände aber auch auf Prozesse beziehen und die Geschäftslogik beschreiben. Geschäftsregeln bilden daneben wichtige Bausteine von wissensorientierten Unternehmen.

Um mit Geschäftsregeln Systeme und Informationssysteme modellieren zu können, müssen diese bestimmt Kerneigenschaften aufweisen, damit sie im Sinne von Modellierungselementen verwendet werden können und das angestrebte Nutzenpotential erschlossen werden kann:

  • Orientierung an Geschäftsprozessen: Geschäftsregeln müssen die Geschäftslogik enthalten. Eindeutigkeit und Präzision bei der Beschreibung der Regeln ist hierbei notwendig.
  • Deklarative Beschreibung: Die Geschäftsregeln beinhalten nicht den konkreten Lösungsweg im Einzelfall.
  • Formuliert in natürlicher Sprache: Hierdurch ist vorerst keine Übersetzung notwendig.
  • Atomare Regeln: Eine einzelne Regel darf keine andere Regel enthalten. Dies ist jedoch nur auf der untersten Modellierungsebene möglich. Allgemein gehaltene oder globale Regeln können andere Regeln beinhalten.
  • Nachvollziehbarkeit: Der Entstehungshintergrund und die Herkunft der Regel sollte bekannt sein und festgehalten werden. Ist eine Regel aus einer anderen Regel abgeleitet worden, so sollte dies feststellbar sein.
  • Strukturiertheit: Es sollten einheitliche Formulierungen gewählt werden um die Vielfalt und damit die Komplexität zu reduzieren.

Für eine Regelmenge die einen bestimmten abgegrenzten Unternehmensbereich, z.B. einen Geschäftsprozess, beschreibt sollten ebenso bestimmte Eigenschaften eingehalten werden. Zuerst müssen die Regeln den Realitätsausschnitt umfassend beschreiben. Dabei dürfen sich die einzelnen Regeln jedoch nicht überschneiden oder widersprechen. Damit bei einer Veränderung des Unternehmensbereichs eine Regelanpassung stattfindet, und die Regeln weiterentwickelt werden, müssen Verantwortlichkeiten für einzelne Ausschnitte der Realität und der damit verbundenen Regeln festgelegt werden.


Abbildung: Formale Beschreibung von Geschäftsregeln in EA, ECA, ECAA Notation

 

Abläufe mit der ECAA Notation modellieren

Ähnlich wie bei der Ereignisgesteuerten Prozesskette entstehen regelbasierte Abläufe dadurch, dass bei der Ausführung des Aktionsteils der Regel ein Ereignis eintritt, welches andere Regeln auslösen kann. Die Möglichkeiten der Modellierung von Sequenzen, Selektionen, Iterationen und Parallelitäten durch Geschäftsregeln werden im Folgenden erläutert. Dabei zeigen Folgepfeile innerhalb der Aktionskomponente die „auslösende Funktion“ dieser an. Es tritt ein (Folge-)Ereignis, welches für eine andere Regel relevant ist, ein.

Sequenz: Einfache Sequenzen werden durch die EA Regel modelliert. Im Aktionsteil dieser Regel tritt ein Ereignis ein, dass für die nächste Aktivität relevant ist.

Abbildung: Modellierung einer Sequenz mit Geschäftsregeln

Selektion: Ebenso wie bei der EPK kann eine Selektion sowohl exklusiv mit einem XOR oder nicht exklusiv mit einem OR modelliert werden. Man spricht hier auch von einem XOR bzw. OR-Split. Die ECAA Regel beinhaltet immer einen XOR Split, da nach der Bedingungsprüfung (IF) immer eine der beiden Aktionen ausgeführt wird. Die Zusammenführung des Splits ist durch folgende Möglichkeiten zu realisieren:

  • Die aufgeteilten Abläufe lösen jeweils ein identisches Ereignis aus. Damit „fließen“ die alternativen Abläufe wieder zusammen.
  • Die alternativen Abläufe werden in einer folgenden Geschäftsregel mit einer Disjunktion (Im Kontext der regelbasierten Modellierung werden komplexe Ereignisse die durch einen XOR oder durch einen ODER verknüpft sind als Disjunktionsereignisse bezeichnet) verbunden.

Für weitere Spezifikationen alternativer Teilprozess sei auf Knolmayer u.a. (Vgl. Knolmayer u.a. 1997, S. 16 f)
verwiesen.

Iteration: Durch den XOR Split lassen sich auch iterative Abläufe modellieren, indem in einem der Aktionsteile einer ECAA Regel ein Ereignis ausgelöst wird, das wiederum eine Regel aktiviert, die im Ablauf des Prozesses schon einmal aktiviert wurde.

Parallelität: Parallele Abläufe können grundsätzlich durch zwei Konstruktionsideen modelliert werden:

  • Mehrere Regeln werden durch dasselbe Ereignis ausgelöst. Nach Eintreten dieses Ereignisses werden alle aktivierten Geschäftsregeln parallel ausgeführt.
  • Im Aktionsteil einer Regel werden mehrere konjunktiv (AND) verknüpfte Ereignisse aktiviert. Diese wiederum sind Auslöser (event) paralleler Abläufe

Zusammengeführt werden die parallelen Teilprozesse, indem in einer weiteren Regel im Eventteil die letzten Aktionen (bzw. deren (Folge-)Ereignisse) der parallelen Prozesszweige konjunktiv verknüpft werden.

Der ECAA Ansatz kann, um in der Unternehmensmodellierung mehr Relevanz zu erlangen, um strukturelle Aspekte (Zuordnung einer Organisationseinheit zu einer Regel oder Regelkomponente, Erweiterung um ein Informationsobjekt, Beschreibung der verbundenen Arbeitsschritte) sowie um temporale Aspekte (Gültigkeitszeiten von Ereignissen, Reaktion auf in einem bestimmten Zeitintervall nicht eingetretenes Ereignis) erweitert werden.

Mai 21, 2007

Modellierung von Prozessabläufen mit der EPK

Filed under: Prozesse — Armin Guenther @ 16:46

Im Folgenden sollen die Modellierungsmöglichkeiten mit der EPK anhand von unterschiedlichen Ablaufformen beschrieben werden.

Sequenz: Sequenzielle Abläufe sind sehr einfach durch Ketten, in denen Ereignisse und Funktionen sich abwechseln, zu modellieren. Da keine Operatoren zum Einsatz kommen, hat jedes Ereignis und jede Funktion sowohl einen eingehenden, als auch einen ausgehenden Pfeil. Somit werden die Elemente sequentiell abgearbeitet.

Selektion: Alternative Abläufe werden mit den Operatoren XOR bzw. „ODER“ modelliert. Die Entscheidung über eine der Alternative wird innerhalb der davor stehenden Funktion getroffen. Ereignisse kommen hierfür nicht in Betracht.

Iteration: Nach Knolmayer u.a. werden iterative Teilprozesse mit einer Funktion dargestellt, in der die Entscheidung über Widerholung oder Nicht-Wiederholung erfolgt. Ein XOR Operator wird eingefügt, aus dem ein ausgehender Pfeil die Iteration über den bereits durchlaufenen Teil der EPK darstellt. Dieser ausgehende Pfeil wird ebenso über einen XOR Operator in die EPK wieder eingeschleift. Staud ergänzt, dass die Rückschleife mit einem Ereignis beginnen kann, das den Bedarf an der Wiederholung eines Abschnittes aufzeigt. Die Folgenden Darstellungen zeigen diese Möglichkeiten:

Abbildung : Zyklische EPK

Parallelität: Parallele Abläufe können mit dem UND Operator modelliert werden. Die parallelen Teilprozesse können dabei von einer Funktion ausgehen, die zwei oder mehrere Ereignisse auslöst bzw. von einem Ereignis ausgehen das zwei oder mehrere Funktionen auslöst. Die Teilprozesse werden auch wieder über einen UND Operatorzusammengeführt.

Mai 14, 2007

Elemente einer EPK

Filed under: Prozesse — Armin Guenther @ 17:24

In dem Beitrag „Prozessmodellierung mit der EPK“ vom 17. April wurde die EPK kurz dargestellt. Im Folgenden soll auf die einzelnen Elemente näher eingegangen werden:

Funktionen: Die in einem Geschäftsprozess zu leistenden Tätigkeiten werden in Funktionen erfasst. Es wird also beschrieben was gemacht werden soll. Funktionen können zerlegt bzw. aggregiert werden. Eine Zerlegung sollte jedoch dort enden, wo die einzelne Funktion in einem Arbeitsablauf bearbeitet wird und keine betriebswirtschaftlich sinnvolle Zerlegung mehr stattfinden kann. Somit beschreibt eine Funktion innerhalb eines EPK Modells je nach Abstraktionsgrad eine Aktivität des Geschäftsprozesses, die bei Bedarf verfeinert werden kann.

Ereignisse: Bei diesem Begriff beschränkt man sich auf betriebswirtschaftlich relevante Ereignisse, die Abläufe im Unternehmen beeinflussen und steuern. Ereignisse beschreiben die Ergebnisse oder die Bedingungen für die Ausführung von Funktionen und können wie diese zusammengefasst oder zerlegt werden. Die Ereignisse müssen sich hier an dem Aggregationsniveau der Funktionen orientieren. Für die Funktionsverknüpfung ist es wichtig zu betonen, dass Ereignisse passive Objekttypen sind.

Prozesswegweiser: Diese Elemente werden in der Praxis häufig verwendet. Sie sind ein Verweis auf andere EPK und symbolisieren den weiteren Verlauf eines Prozesses in einer anderen EPK auf die hierdurch referenziert wird. Es gibt drei Gründe Epks durch Prozesswegweiser miteinander zu verknüpfen:

1.      Ein unübersichtlicher Prozess (bzw. eine unübersichtliche, lange EPK) muss in verschiedene Teilprozesse aufgeteilt werden.

2.   Kleine EPKs werden in zahlreichen anderen Teilprozessen benötigt. Durch den Verweis auf diese wird die Modellierung vereinfacht.

3.   Die Zusammenhänge von Geschäftsprozessen sollen erfasst werden.

Es gibt bei einer Modellierung mit einem Prozesswegweiser immer zwei EPKs. Eine „aufrufende EPK“ enthält einen Prozesswegweiser, der den Aufruf eines anderen Prozesses signalisiert. Eine „aufgerufene EPK“ in der ein Prozesswegweiser anzeigt, dass sie aufgerufen wurde. Daraus leiten sich folgende Regeln ab:

  • Der Prozesswegweiser in einer aufrufenden EPK steht an Stelle einer Funktion und gibt sowohl die Verknüpfungsstelle an, als auch welche EPK aufgerufen werden soll.

  • Der Prozesswegweiser in einer aufgerufenen EPK, steht anstelle einer Funktion und auch die Verknüpfungsstelle an. Daneben bezeichnet er von welcher EPK der Aufruf kommt.

  • Das Ereignis vor dem Prozesswegweiser in der aufrufenden EPK wird nach dem Prozesswegweiser wiederholt. Hierdurch kann man sich das Zusammenführen der zwei EPKsvorstellen.

Operatoren: Die Verknüpfungsoperatoren legen die jeweilige Ablauflogik innerhalb eines Geschäftsprozesses fest. Ein Verknüpfungsoperator kann entweder eine Eingangs- und mehrere Ausgangskanten (Operator = Verteiler) oder mehrere Eingangs- und eine Ausgangskante (Operator = Verknüpfer) haben. Es werden die konjunktiven („UND“), disjunktiven („XOR“) und adjunktiven („ODER“) Operatoren benötigt, da in der Praxis Funktionen von mehreren Ereignissen angestoßen werden und auch mehrere Ereignisse auslösen. Mit diesen Operatoren lassen sich nun zwei verschieden Verknüpfungsarten differenzieren. Die Ereignisverknüpfung verknüpft zwei oder mehrere Ereignisse mittels eines Operators mit einer Funktion. Bei einer Funktionsverknüpfung verbindet der Operator zwei oder mehrere Funktionen mit einem Ereignis. Alle möglichen Kombinationen sind in der unten stehenden Abbildung, eingezeichnet. Man beachte, dass die Funktionsverknüpfung mit einem auslösenden Ereignis nur über eine „UND“ Verknüpfung möglich ist, da, wie bei der Erläuterung der Ereignisse erwähnt, die Passivität dieser keine aktive Entscheidung erlaubt. „ODER“ und „XOR“ Verbindungen sind in diesem Fall also nicht möglich.

Download: Dieser Beitrag mit Quellenangaben

Mai 1, 2007

Konstruktionsprinzipien agiler Prozesse

Filed under: Prozesse — Armin Guenther @ 18:41

Die folgenden Konstruktionsideen werden von Grief und Seidelmeier herangezogen um eine gewisse Flexibilität zu erzeugen. Diese organisatorische Flexibilität wird durch entkoppelte Teilprozesse erreicht, die eine leichte Neukonfiguration von Strukturen und Prozessen erlaubt. In dem Paper wird zudem die Umsetzung der Konstruktionsideen mit der EPK dargestellt. Die Vorschläge geben konkrete Ansatzpunkte für die Modellierung der im Rahmen der Diplomarbeit zu entwerfenden Prozesse. Dabei spannen die Ansätze „Erzeugung von Prozessvarianten“, „Verwendung robuster Modellierungsmethoden“ und „Wahl des geeigneten Abstraktionsgrad“ den Rahmen auf, in dem sich die Modellierung bewegen wird.

Konstruktionsvorschlag 1: Modularisierung

Der Aufbau der Prozesse erfolgt hier zusammensetzen von Modulen. Die einzelnen Module bestehen aus Schnittstellen und einem Kern. Im Kern ist die eigentliche Funktionalität in freien Bausteinen festgehalten.

Konstruktionsvorschlag 2: Entkopplung der Module

Die erforderliche Flexibilität der Prozesse, d.h. ein Vorhalten von Wandlungsfähigkeit, wird durch die Entkopplung der einzelnen Module erreicht. Somit entstehen autonome Prozessmodule, bzw. Teilprozesse, die situationsbezogen, aber zielgerichtet zusammengeführt werden können.

Konstruktionsvorschlag 3: Modul Intra- und Interflexibilität

Der Konstruktionsvorschlag 1 und 2 erzeugen Flexibilität auf zwei Ebenen:

  • Modul-Intraflexibilität: Die freien und entkoppelten Prozessbausteine können innerhalb eines Moduls beliebig kombiniert werden.
  • Modul-Interflexibilität: Die entkoppelten Teilprozesse bzw. Prozessmodule können beliebig zu einem Gesamtprozess zusammengeführt werden.

Konstruktionsvorschlag 4: Selbststeuernde Prozesskonfiguration

Durch die gewonnene Flexibilität entsteht Komplexität. Es wird ein „Kopplungssystem“ notwendig, dass die Methodik sowie die notwendigen Umweltinformationen enthält, um die Module zu einem Gesamtprozess zusammenführen zu können. Damit besteht nicht die Notwendigkeit, alle möglichen Modulkombinationen vorzuhalten. Wird Wandlungsbedarf durch eine nicht beeinflussbare Umweltveränderung ausgelöst, wird eine entsprechende Prozessvariante selbständig erzeugt. Aber das Wandlungspotential ist nicht explizit modelliert, sondern liegt in dem skizzierten modul-inter- und intraflexiblen Kopplungssystem.

Konstruktionsvorschlag 5: „Kernmodell“

Im Kernmodell werden zwingend notwendige Prozessmodule festgelegt. Die Notwendigkeit dieses Modells können zum einen spezifische Unternehmensziele oder Prozessziele sein, die es zu erreichen gilt. Zum anderen können rechtliche Verordnungen ein Kernmodell erzwingen. Daneben verhindert das Kernmodell Willkürlichkeit bei der Prozesszusammenstellung und Prozessdurchführung.

April 27, 2007

Konstruktion agiler Prozesse

Filed under: Interessantes,Prozesse — Armin Guenther @ 12:58

Ich habe einen sehr interessanten Artikel gefunden der Möglichkeiten ausführt, Prozesse agil zu gestalten. Der Artikel ist ein Diskussionsbeitrag des 4. Workshop der Gesellschaft für Informatik e.V. (GI) und Treffen ihres Arbeitkreises „Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten (WI-EPK)“. Der Arbeitskreis soll Praktikern und Wissenschaftlern als Forum zur Kontaktaufnahme, zur Diskussion und zum Informationsaustausch dienen. Die Aktivitäten des Arbeitskreises werden unter der Internetadresse http://www.epk-community.de dokumentiert. Der Tagungsband wurde in digitaler Form publiziert. Er ist hier verlinkt.

Der Artikel hat den Titel: „Modellierung von Flexibilität mit Ereignisgesteuerten Prozessketten (EPK)„, von Grief, J., Seidlmeier, H.. Sie führen aus wie „Modularisierung“ und „Entkopplung“ zu einer selbststeuernden Prozesskonfiguration und einer variablen Funktionsreihenfolge führt.

Der Artikel beinhaltet Ansätze die bei der Gestaltung der agilen Prozesse im Rahmen der Diplomarbeit Anwendung finden können. Eine tiefer gehende Analyse wird im Laufe der Diplomarbeit ausgeführt.

April 17, 2007

Prozessmodellierung mit der Ereignisgesteuerten Prozesskette

Filed under: Prozesse — Armin Guenther @ 10:11

Modellorientierte Prozessbeschreibung

Um die Eindeutigkeit und die Lesbarkeit von Prozessbeschreibungen zu erhöhen, ging man in den letzten zehn Jahren dazu über, Prozesse grafisch zu beschreiben. Der wesentliche Vorteil der grafischen Darstellung gegenüber der textlichen oder tabellarischen Darstellung ist die leichte Lesbarkeit und die damit verbundene schnelle Erfassung selbst komplexer Prozesse. Nicht zuletzt wird hierdurch die Verbreitung und Kommunikation der Prozessmodelle sowohl intern als auch gegebenenfalls extern deutlich erleichtert.

Ebenso wie die Tabellarische- oder die Textform weißt die graphische Beschreibung das Problem der fehlenden Eindeutigkeit und Klarheit auf. Daher wurden eigene Methoden der Prozessdarstellung – so genannte Modellierungssprachen – entwickelt. Modellierungsmethoden wie die UML (Unified Modelling Language) sind häufig stark formalisiert und auf die Gestaltung von Programmabläufen oder Datenzusammenhängen ausgerichtet. Die hohe Abstraktheit von UML macht die Prozessmodelle für Fachbereichsmitarbeiter schwer lesbar. „Einen Durchbruch bei der Überbrückung des Spagats zwischen Formalität und Lesbarkeit erzielte Scheer mit dem Entwurf des ARIS-Konzepts und den ereignis­gesteuerten Prozessketten (EPK) im Kern dieses Modellierungsansatzes.“ Die Methode der Ereignisgesteuerten Prozesskette wurde 1991 am Institut für Wirtschaftsinformatik der Universität des Saarlandes in Kooperation mit der SAP AG als Ansatz zur Geschäftsprozessmodellierung entwickelt. Die EPK bildet den Kern des Modellierungskonzepts der Architektur Integrierter Informationssysteme (ARIS, bzw. ARIS- Werkzeugsystem der IDS Scheer GmbH) und des Business Engineering und Customizing des SAP R/3-Systems.

Der Modellierungsansatz der EPK hat sich in der Praxis als semi-formale Modellierungsmethode für Geschäftsprozesse durchgesetzt. Im Spannungsfeld zwischen Exaktheit und Verständlichkeit verbindet die EPK Methode die Welt der Fachbereiche mit der Welt der Informationstechnologie. Sie ist dabei ausreichend formal, um den wichtigsten strukturellen Anforderungen zu genügen damit eine Basis für verschiedenste Prozessanalysen zu schaffen. Daneben stellt die gleichzeitige Einfachheit sicher, dass sie von Fachbereichsmitarbeitern sowie von Prozessmanagern leicht erlernt werden kann.

Die EPK, die nicht eine Erweiterung der Petrinetze sondern eine besondere Ausprägung der Kanal-Instanzen-Netze darstellt, beantwortet Fragen zum Geschäftsprozess, die durch entsprechende Symbole repräsentiert werden. (Abbildung 2) Der Ausgangspunkt eines jeden Prozesses ist ein Ereignis. Beispielhaft lautet die Frage hier: Wodurch wird der Prozess ausgelöst? Nach diesem „Startereignis“ wird eine Funktion ausgelöst. Der Prozess ist eine Kette von Funktionen, wobei die Funktionen durch Ereignisse verknüpft sind und dynamische Elemente darstellen. Eine ausgeführte Funktion kann ein oder mehrere weitere Ereignisse, welche als Startereignisse anderer Funktionen dienen können und bestimmte Zustände darstellen, erzeugen. Wie in Abbildung 1 dargestellt werden Funktionen durch abgerundete Rechtecke abgebildet. Die Ereignisse werden durch Sechsecke und Verknüpfungen durch Pfeile repräsentiert. Durch logische UND Verknüpfungen können bspw. parallele Abläufe modelliert werden. Konflikte werden durch ODER Verknüpfungen dargestellt.

Abbildung 1: Notation derGrundelemente der EPK

Abbildung 2: Grundfragen der EPK

 

Die in Abbildung 1 aufgezeigten Grundelemente werden in der erweiterten EPK (eEPK vgl. Abbildung 3) um zusätzliche Elemente zur Integration weiterer Fachkonzeptsichten ergänzt. Mit dieser Erweiterung lassen sich neben dem Prozessablauf weitere Aspekte eines Geschäftsprozesses abbilden. Zum einen kann einer Funktion eine organisatorische Einheit, die für die Ausführung dieser zuständig ist, zugeordnet werden. Zum anderen können Funktionen mit Informationsressourcen verbunden werden. Darüber hinaus kann die eEPK mit Elementen zu Abbildung von Informationssystemen oder Materialressourcen erweitert werden.

Abbildung 3: Erweiterung der Notation der EPK

Download: Dieser Beitrag mit Quellenangaben

 

 

 

April 14, 2007

Ziele der Prozessanalyse und der Prozessmodellierung

Filed under: Grundlagen,Prozesse — Armin Guenther @ 10:08

Transparenz als Voraussetzung für Prozessteuerung
Um eine Transformation und Steuerung von Prozessen zu ermöglichen, müssen die durchgeführten Prozesse analysiert und dargestellt werden. Die Prozessstrukturen des Unternehmens sind aufzuzeigen und zu kommunizieren. Dies geschieht durch das Erstellen eines Prozessmodells und der Modellierung und Beschreibung der Prozesse. Um Prozesstransparenz sicherzustellen sind zunächst die einzelnen Prozessschritte darzustellen. Daneben sind weitere Informationen, die CMMI als „Prozess-Assets“ bezeichnet, notwendig:

  • Informationen über beteiligte Organisationseinheiten
  • Performancedaten
  • Verwendete (IT-) Systeme und Richtlinien, z.B. Arbeitsanweisungen

Die gewünschte Prozesstransparenz wird durch die Instrumente der Prozessanalyse und der Modellierung der Prozesse geschaffen (vgl. Abbildung 1).

Prozessanalyse und -modellierung

Abbildung 1

Im Rahmen des Prozessmanagements kommt der Prozessanalyse eine entscheidende Bedeutung zu. Bergsmann, Grabek und Brenner arbeiten vier Zielsetzungen der Prozessanalyse und –modellierung heraus:

  • Aus Sicht des Qualitätsmanagements steht die Erfüllung der Prozessanforderungen im Vordergrund. Standards und Mindestanforderungen sollen erfüllt werden. Eine Dokumentation von Prozessen mach sowohl ihre statische als auch dynamische Struktur transparent.
  • Für die Kostenrechnung ist es relevant, dass die Prozesse eine Bewertung der Komplexität von Kunden und Produkten ermöglichen. Diese Bewertung muss ebenso in die Kalkulation und Ergebnisrechung integriert werden können.
  • Aus ablauforganisatorischer Sicht fördert die Darstellung eine gewisse Übersichtlichkeit und erlaubt eine Analyse der logischen und zeitlichen Prozessreihenfolge, um Schwachstellen zu identifizieren und Prozesse bzw. deren Abläufe zu optimieren. Medienbrüche und häufige Systemwechsel werden erkennbar.
  • Ein anderes Anwendungsfeld ist die Entwicklung von komplexen IT-Systemen. Die Prozessabläufe können in die IT-Pflichtenhefte übernommen werden und das zu konzipierende IT-System wird entsprechend der Prozessspezifikation ausgestaltet.

Um Optimierungspotentiale erschließen zu können sind wie erwähnt Prozesse über alle Unternehmensbereiche hinweg zu analysieren und transparent zu machen. Die Automatisierung von Geschäftsprozessen ist in einem turbulenten Wettbewerbsumfeld, neben den erwähnten Zielsetzungen, unumgänglich. Diese Automatisierung bedingt häufig eine Standardisierung was zu effizienter und effektiver ablaufenden Prozessen führen kann,

Bei dem Unternehmen das Gegenstand der Diplomarbeit ist steht die Sicherung der Qualität von Dienstleitung und Produkten des Unternehmens im Vordergrund. Daneben ist die ablauforganisatorische Optimierung der Prozesse ein angestrebtes Ziel. Die Kostenrechnung und die Entwicklung eines IT-Systems treten hier in den Hintergrund.

Um eine Prozessanalyse und –modellierung erfolgreich durchführen zu können muss das Geschäftsmodell in prozessorientierter Sicht abgebildet werden. Hierzu muss ein Grundverständnis über die wesentlichen Geschäftsprozesse sowie deren Bedeutung geschaffen werden. Darüber hinaus ist eine Prozesshierarchie notwendig um eine einheitliche Nomenklatur vorzugeben, die eine weitere Detaillierung der Geschäftsprozesse erlaubt.


Abbildung: Prozesslandkarte

Abbildung 2 zeigt bspw. die Hauptprozesse gegliedert nach Management-, Leistungs- und Supportprozesse auf. Bevor jedoch ein hierarchisches Prozessmodell konzipiert werden kann, muss Klarheit über den Anwendungszweck sowie die Ziele der Prozessdarstellung herrschen.

Download: Dieser Beitrag mit Quellenangaben

März 29, 2007

Geschäftsregelbasierte Prozessmodellierung

Filed under: Analyse,Business Rules,Prozesse — Armin Guenther @ 21:22

Dieser Beitrag umreisst die Möglichkeiten Geschäftsprozesse mit Hilfe von Geschäftsregeln zu modellieren (In dem Beitrag „Begrifflichkeiten“ unter dem Gliederungspunkt Agilität wurde diese Thematik schon angesprochen).

Aus meiner Sicht eignet sich diese „Form“ der Modellierung aufgrund folgender Punkte:

  1. Sie ist einfach in eine EPK Visualisierung zu überführen
  2. Die Prozessbeschreibungen können flexibel an veränderte Bedingungen angepasst werden
  3. Die Prozessbeschreibungen bieten den Mitarbeitern die nötige Flexibilität um bspw. kundenindividuelle Anpassungen bei der Abarbeitung eines Prozesses zu ermöglichen
  4. Die Notation ist für IT Spezialisten leicht verständlich

Die folgenden Ausführungen sind der Dissertation von Reiner Endl entlehnt: Regelbasierte Entwicklung betrieblicher Informationssysteme, Gestaltung flexibler Informationssysteme durch explizite Modellierung der Geschäftslogik

“Moderne Unternehmensorganisationen und Management-Konzepte setzen die optimale Gestaltung der relevanten Geschäftsprozesse voraus. Sie betonen deren Flexibilität sowie die Fähigkeit, kundenindividuelle Produkte und Dienstleistungen herzustellen und sich schnell an Veränderungen in der Unternehmensumwelt anpassen zu können. Eine Schlüsselrolle spielt dabei der effiziente Einsatz der Informationstechnologie, der bestimmte Strategien und Prozessvarianten – z. B. weltweiter Vertrieb bisher nur lokal angebotener Produkte via Internet – erst ermöglicht und unterstützt. Regeln bilden die Basis für das im Unternehmen vorhandene geschäftsrelevante Wissen.“

„Ein Ansatz besteht darin, den Geschäftsprozess selbst als eine Folge von Geschäftsregeln aufzufassen, d.h. die kausalen und temporalen Ablaufvorschriften in geeigneter Weise zu modellieren. Die unter bestimmten Bedingungen auszuführenden Aktivitäten und die sie auslösenden Ereignisse können in Beziehung zueinander gesetzt werden, so dass Prozesse auf der Grundlage von Geschäftsregeln beschrieben und ausgeführt werden können.

Die Prozessmodellierung mit Geschäftsregeln basiert auf ECAA-Regeln. Durch die drei Konstrukte Ereignis, Bedingung und Aktion ergibt sich so eine Analogie zu den in aktiven Datenbanksystemen verwendeten ECA-Regeln. Das ECA-Konstrukt wird um eine zweite Aktionskomponente erweitert, um bei Nichteintreten einer Bedingung eine alternative Aktion ausführen zu können. Damit können für einen Geschäftsprozess typischen Entscheidungsaktivitäten modelliert werden. Die ECA- und EA-Regeln, d.h. Regeln ohne Bedingungskomponente, werden als Sonderfälle von ECAA-Regeln betrachtet“

“Die mit Geschäftsregeln modellierten Prozesse müssen daher mit Hilfe einer geeigneten graphischen Darstellung visualisiert werden können. Dabei werden entweder ganze Regeln oder einzelne Regelkomponenten mit Hilfe unterschiedlicher Symbole abgebildet.“ Das regelbasierte Prozessmodell umfasst auch Erweiterungen bezüglich struktureller, organisatorischer und temporaler Hinsicht. Die EA-, ECA- bzw. ECAA-Notation ist bestenfalls für kleine Prozessmodelle ausreichend übersichtlich. Bei größeren Prozessmodellen erfüllt die Notation vor allem im Hinblick auf die Visualisierungsmöglichkeiten formulierten Anforderungen nur ungenügend. Die mit Geschäftsregeln modellierten Prozesse müssen daher mit Hilfe einer geeigneten graphischen Darstellung visualisiert werden können.“

Somit können die mit Geschäftregeln modellierten Prozesse in die eEPK (erweiterte Ereignisgesteuerte Prozesskette) Notation übertragen werden.

Erstelle eine kostenlose Website oder Blog – auf WordPress.com.