Metaprozess.de

Strategie-Schicht in ArchiMate 3.0

2017-03-27T22:53:00.000+02:00

Jetzt wird es strategisch: der Architecture Layer in ArchiMate 3.0 verbindet Geschäftsfähigkeiten mit Handlungen und Ressourcen.

Das Metamodell für die Strategieschicht in ArchiMate 3.0

Die Strategieschicht von ArchiMate 3.0 dient dazu, die Geschäftsfähigkeiten einer Organisation zu modellieren. Es wird dargestellt, wie diese verändert werden (müssen), um das gewünschte Geschäftsergebnis zu erzielen. [1, S. 63]

Im oben abgebildeten Metamodell befinden sich vier verschiedene Elemente: Handlung, Geschäftsfähigkeit, Ressource und Ergebnis.

Handlung (engl.: Course of Action)

Eine Handlung kann strategisch oder taktisch sein.
Eine Handlung kann eine andere Handlung initiieren, Informationen für diese bereit stellen oder dieser dienen.
Eine Handlung beeinflusst ein Ergebnis (positiv oder negativ).
Eine Handlung wird durch eine Geschäftsfähigkeit realisiert oder von einer solchen unterstützt.

Ergebnis (engl.: Outcome)

Das Ergebnis wird von mindestens einer Handlung beeinflusst.
Das Ergebnis stammt aus der Motivationsschicht und wird hier deshalb thematisch nur angerissen.

Geschäftsfähigkeit (engl.: Capability)

Eine Geschäftsfähigkeit kann eine andere Geschäftsfähigkeit initiieren, Informationen für diese bereit stellen oder dieser dienen.
Eine Geschäftsfähigkeit realisiert eine Handlung oder dient dieser.
Eine Geschäftsfähigkeit kann einer aktiven Struktur zugeordnet sein.
Eine Geschäftsfähigkeit wird von einer aktiven Struktur realisiert.
Eine Geschäftsfähigkeit kann Ressourcen zugewiesen bekommen.

Ressource (engl.: Resource)

Eine Ressource ist einer Geschäftsfähigkeit zugewiesen.

Da eine Ressource ein eher abstrakter Begriff ist, kann diese gedanklich in mehrere Gruppen unterteilt werden (siehe separates Metamodell).

Metamodell für Ressourcen in der Strategieschicht von ArchiMate 3.0

Sachanlagen (Tangible Assets)

Physikalische Vermögenswerte wie z.B. ein Kraftwerk, Ausrüstung oder Grund
Finanzielle Vermögenswerte wie z.B. Bargeld, Sicherheiten, Kreditfähigkeit

Immaterielle Werte (Intangible Assets)

Technologien wie z.B. Patente, Urheberrechte, Handelsgeheimnisse
Kultur
Reputation wie z.B. Markenbild, Handelsbeziehungen

Menschliches Kapital (Human Assets)

Fähigkeiten
Wissen
Kapazitäten

Praxisbeispiel

Praxisbeispiel für die strategische Schicht bei ArchiMate 3.0

In diesem Beispiel eines Online-Händlers gibt es die Handlungen Ausbleibende Zahlungen verfolgen und Betrugsfälle verhindern.
Die Handlung Ausbleibende Zahlungen verfolgen beeinflusst positiv (verstärkt) das Ergebnis Zahlungsausfälle reduziert. Die Handlung Betrugsfälle verhindern beeinflusst positiv das Ergebnis Betrugsfälle reduziert, welches widerum das Ergebnis Zahlungsausfälle reduziert positiv beeinflusst.

Die Geschäftsfähigkeiten Inkassobeauftragung, Mahnwesen und Lastschriftsperre dienen der Handlung Ausbleibende Zahlungen verfolgen, wobei der Geschäftsfähigkeit Inkassobeauftragung die Ressource Inkassobüro zugewiesen ist.
Die Geschäftsfähigkeiten Lastschriftsperre und Betrugsprävention dienen der Handlung Betrugsfälle verhindern. Die Geschäftsfähigkeit Lastschriftsperre dient auch der Geschäftsfähigkeit Mahnwesen.
Der Geschäftsfähigkeit Betrugsprävention ist die Ressource Scoring-Patent zugewiesen.

Quellen

[1] Andrew Josey et al.: ArchiMate 3.0 - A Pocket Guide. The Open Group. The Open Group Series; Van Haren Publishing, 2016.

Hier kommt ArchiMate 3.0

2017-03-17T20:57:00.003+01:00

Seit Juni 2016 existiert die Version 3.0 des ArchiMate Standards der Open Group. Ich habe mir den Standard angeschaut und bin so sehr davon begeistert, dass ich es nicht für mich behalten möchte.

Kurzvorstellung

Bei ArchiMate handelt es sich um eine Modellierungssprache, die speziell zur Modellierung von Unternehmensarchitekturen entwickelt wurde.
Die Sprache erlaubt die Definition von Strukturen und Betriebsabläufen von Geschäftsprozessen, Organisationsstrukturen, Informationsflüssen, IT-Systemen und technischer Infrastuktur. [1]
Bemerkenswert ist hierbei vor allem, dass die verschiedenen Architektursichten auf die rein fachliche Welt, die Anwendungen und die Technologie darunter miteinander vereint werden können.
Mit entsprechenden Modellierungswerkzeugen kann so eine ganzheitliche Dokumentation eines Unternehmens erzeugt werden; vor allem dann, wenn die Geschäftsprozesselemente mit den ausmodellierten BPMN-Elementen verknüpft werden.

Konzept und Schichtenmodell

Um eine klare Sicht auf die unterschiedlichen Architekturaspekte eines Unternehmens zu erhalten, gibt es bei ArchiMate seit Beginn der Einführung ein übergreifendes Modell, welches die Elemente in Dimensionen nach Zweck und Art einteilt.

Das vollständige ArchiMate 3.0 Framework mit Erweiterungen [2]

Im abgebildeten Modell bilden die Spalten die Aspekte und die Zeilen die Schichten ab. Die dargestellten Farben werden tatsächlich von den meisten Modellierungswerkzeugen so übernommen. Das erleichtert den schnellen Einstieg und die Übersicht in neuen Modelle.

Aspekte klassifizieren das Objekt

Es wird zwischen drei Aspekten unterschieden: Aktive Strukturen, Verhalten und Passive Strukturen. Diese können mit dem Satzbau in der natürlichen Sprache verglichen werden.

Die aktiven Strukturen sind das Nomen (Mensch/System/Software), das Verhalten repräsentiert das Verb (dienen, realisieren, kapseln, verknüpft sein mit) und die passiven Strukturen das Objekt (Dokument, Datenbanktabelle). [3, S. 27]
Die Elemente (Struktur und Verhalten) sind in ArchiMate durch Beziehungen miteinander verknüpft. Eine Beziehung kann gerichtet (Darstellung mit Pfeil oder Diamant) oder ungerichtet (einfache Linie) sein. Sie gibt Auskunft darüber, in welchem Verhältnis die Elemente zueinander stehen.

Strukturen, Verhalten und Beziehungen in ArchiMate 3.0

Schichten klassifizieren das Umfeld/den Einsatzzweck

Motivationsschicht (Motivation). In dieser Schicht wird schichtenübergreifend modelliert, warum etwas getan wird. Diese Schicht kann auf jeder anderen Ebene referenziert und verknüpft werden.

Strategieschicht (Strategy). Die Strategieschicht legt dar, welche Geschäftsziele mit welchem Maßnahmen umgesetzt werden sollen.

Fachliche Schicht (Business). Die fachliche Schicht bildet ab, mit welchen Prozessen und Geschäftsfunktionalitäten die in der Strategieschicht definierten Maßnahmen umgesetzt werden.

Anwendungsschicht (Application). Die Anwendungsschicht unterstützt durch Softwarekomponenten, Schnittstellen und Services die fachliche Schicht bei der Umsetzung.

Technische Schicht (Technology). Die technische Schicht stellt die IT-Systeme und Gerätschaften bereit, mit denen den Anwendungen der tägliche Betrieb ermöglicht wird.

Physische Schicht (Physical). Hier werden die untergelagerten technischen Prozesse wie z.B. eine Produktionsstätte sowie die Verwendung von Materialien abgebildet.

Implementierung & Migration (Implementation and Migration). Mit dieser Schicht lässt sich abbilden, welche markanten Software-Entwicklungsziele es gibt und mit welchen Arbeitspaketen daran gearbeitet wird.

Im Rahmen der nächsten Beiträge werde ich die einzelnen Schichten sowie die darin enthaltenen Elemente genauer beschreiben und mit konkreten Beispielen besser greifbar machen.

Quellen:

[1] ArchiMate - Wikipedia, https://en.wikipedia.org/wiki/ArchiMate

[2] ArchiMate 3.0 Speficication - The Open Group. http://pubs.opengroup.org/architecture/archimate3-doc/chap03.html

[3] Andrew Josey et al.: ArchiMate 3.0 - A Pocket Guide. The Open Group. The Open Group Series; Van Haren Publishing, 2016.

BPM Architektur: Übersicht der Bestandteile

2015-05-14T19:59:00.000+02:00

Wie alle Systeme hat auch ein BPM System eine Architektur inne. Diese variiert in ihrer Komplexität je nach Zweck und Integrationstiefe des BPM-Systems und muss dem jeweiligen Kontext angepasst werden.

Die in diesem Blog vorgestellte BPM Architektur stellt einen allgemeine Architekturansatz dar, der sich in vielen Aspekten an die Auffassung von Gartner[1] anlehnt. Jede der nachfolgend genannten Schichten (inklusiver ihrer Komponenten) wird in zukünftigen Beiträgen näher beschrieben.

Die Schichten einer allgemeinen BPM-Architektur.

Benutzerinteraktion

Die menschliche Integration in den Ablauf der automatisierten Prozesse mit Hilfe von Benutzerschnittstellen. Die Prozessteilnehmer müssen mit UI-Komponenten interagieren und Informationen einholen oder bereitstellen, die zur Lösung der Ihnen gestellten Aufgaben dienen und den Prozess vorantreiben.

Die Benutzerinteraktionskomponenten sind die Mechanismen, mit denen alle Prozess-Stakeholder - inklusive Prozessteilnehmer, Prozess-Owner, Prozessanalysten oder IT-Abteilung - interagieren.

Design-Time

Die Design-Time Komponenten unterstützen die Dokumentation und die Analyse der Geschäftsprozesse. Die Prozesstreibenden benötigen eine Infrastruktur, welche sie beim Design oder der Modellierung von Prozessen und dem Erschaffen von Prozessautomatisierungsmaßnahmen unterstützt. Dies umfasst u.a.:

■ Prozess-Design

■ Regeldefinition

■ Benutzerinteraktions-Design

■ Simulations-Design

■ KPI Definition

■ Solution Development

Plattform-Persistenz

Die Plattformpersistenzkomponenten werden benötigt, um die Zustände und aufgetretenen Ereignisse von Prozessschritten und davon abhängige Aktionen zu persistieren. Dies ermöglicht auch eine retrospektive Analyse der Prozessinstanzen und Governance-Maßnahmen.

Laufzeit (Runtime Hosting)

Die Laufzeitkomponente ermöglicht den Betrieb der Prozess-Engine und bietet zudem eine unterstützende Umgebung in Form von vermittelnden Systemen, Middleware und Monitoring-Möglichkeiten.

Sicherheit

Die Sicherheitskomponenten unterstützen die Integration sicherheitsrelevanter Features wie z.B. SSO (Single-Sign-On) und Berechtigungssysteme.

Enterprise Service Bus

Der Enterprise Service Bus stellt im Rahmen einer SOA-Architektur den zentralen Zugriffspunkt für Dienste und Datenmodelle dar. Er ist protokollunabhängige Middleware für unterschiedliche

Plattformen und Technologien. Zudem übernimmt er wiederkehrende Aufgaben, wie z. B. das Wandeln von Protokollen, das Filtern und das Routen von Nachrichten.

Datenquellen/Enterprise Systeme

Die Datenquellen und Enterprise-Systeme bilden die unternehmensweite Datenbasis, in welcher die Datenobjekte persistiert werden.

Übersicht der Schichten und Komponenten eines BPM-Systems.

Quellen

[1] Gartner: "Business Process Management Infrastructure"; Richard Watson & Anne Thomas Manes; 2012.

Rollen im Business Process Management

2015-04-25T14:34:00.000+02:00

Im Rahmen von BPM gibt es verschiedene Rollen, deren Aufgaben und Ziele individuell betrachtet werden müssen. Die eingesetzten und vorhandenen Rollen variieren je nach Unternehmensgröße, Führungsmethodik und Kultur.

Die nachfolgend vorgestellten Rollen müssen also nicht zwingend in jedem Unternehmen vollständig vertreten sein. Ebenso können auch je nach Komplexität des Unternehmens und der eingesetzten Prozesse noch andere Rollen beteiligt sein.

Beziehungen der Rollen im BPM-Umfeld

Chief Process Officer - Oberes Management

Der Chief Process Officer (CPO) oder auch „Leiter des Prozessmanagements“ steht hierarchisch gesehen an oberster Stelle und »etabliert eine nachhaltige Prozessorientierung im Unternehmen als zentrale[n] Erfolgsfaktor der wert- und kundengebundenen Ausrichtung.« [1] Er ist hauptsächlich für die Gestaltung des Change-Prozesses zuständig und kümmert sich im Allgemeinen um den Aufbau der prozessorientierten Organisation.

Der Chief Process Officer (CPO)

Process Owner - Strategische Prozessverantwortung & Controlling

Der Process Owner oder auch „Prozessverantwortliche/Prozesseigner“ befindet sich meist
im oberen Management und besitzt die strategische Verantwortung für einen Prozess.
Der Process Owner verwaltet das Budget und entscheidet über die Genehmigung von Optimierungsanträgen.
Er wählt die Kennzahlen zur Erfolgsmessung der Prozessleistung aus und kümmert sich
um den Aufbau und die Ausführung eines Prozesscontrollings.

Der Process Owner

Process Manager - Operative Verantwortung

Der Process Manager oder auch „Prozessmanager“ ist häufig im operativen Management tätig und trägt die operative Verantwortung des Prozesses. Er berichtet dem Process Owner und äußert diesem gegenüber Verbesserungswünsche.
Der Process Manager ist neben der Planung und Ausführung der operativen Prozessleistung auch mit der Koordination von mit seinem Prozess verbundenen Prozessen betraut.

Der Process Manager

Process Participant - Prozessdurchführung

Der Process Participant oder auch „Prozessbeteiligte“ ist derjenige, der im Prozess selbst arbeitet und durch den Einsatz der definierten Prozessmethoden und -dokumente die eigentliche Wertschöpfung (die Umsetzung der Kundenanforderungen) erbringt. Optimalerweise ist der Process Participant auch an der Mitgestaltung von Soll-Prozessen beteiligt.

Der Process Participant

Process Management Consultant - Analyse und Konzeption

Der Process Management Consultant oder auch „Prozessmanagement-Berater“ unterstützt den CPO bei der »Analyse und Konzeption von unternehmensweiten und prozessspezifischen Prozessmanagementmethoden« [BPM] und tritt beratend bei der allgemeinen BPM-Projektplanung in Aktion.

Process Controller - Führungsprozesse entwickeln

Der Process Controller ist Berater der Führungsrollen und unterstützt diese bei der Entwicklung der Führungsprozesse des Prozessmanagements und der effizienten Durchführung der Konzepte.
Er modelliert zudem die Führungsprozesse, nimmt eine erste grobe Prozessplanung vor und führt ein effizientes Prozessreporting ein.

Der Process Controller

Process Management IT-Coordinator - technische Architektur

Der PM IT-Coordinator ist für die technische Architektur und Ausführung der Prozesse verantwortlich. Er wendet die Prinzipien von Service Oriented Architecture (SOA)3 und BPM an und koordiniert die IT-Landschaft mit den Anforderungen aus den Fachabteilungen.

Der PM IT-Controller

Process Engineer - technische Entwicklung

Der Process Engineer oder auch „Prozessentwickler“ ist für die technische Umsetzung der Prozesse verantwortlich, die meist mit Hilfe einer Workflow-Engine erfolgt.

Der Process Engineer

Process Analyst - Schnittstelle zwischen Fachbereich und IT

Der Process Analyst oder auch „Prozessanalyst“ bildet die zentrale Schnittstelle zwischen der fachlichen und der technischen Abteilung. Seine Aufgabe besteht in dem Erreichen eines gemeinsamen Verständnisses für das Geschäfts- und Prozesswesen.
»Innerhalb des Unternehmens ist der Process Analyst meistens entweder in einem Kompetenzbereich
für BPM angesiedelt, z. B. der Betriebsorganisation, oder er gehört zur IT-Abteilung.« [2] Dennoch liegt sein Fokus klar auf der Analyse und er ist eher selten an der Implementierung beteiligt.
Er arbeitet eng mit dem PM IT-Coordinator zusammen, um die Anforderungen aus den verschiedenen Fachabteilungen und deren Hierarchien bewerten und einordnen zu können.
Gerade in etwas kleineren mittelständischen Unternehmen übernimmt der Business Analyst oft zusätzlich die beratenden Rollen „PM Consultant“ und „Process Controller“ ein.

Der Process Analyst

Quellen

[1] BPM-Akademie GmbH: Rollen im Prozessmanagement. http://www.bpm-akademie.de/akademie/opencms/de/know_how/rollen_im_prozessmanagement
[2]

Ereignisse in BPMN 2.0

2015-04-24T12:08:00.000+02:00

Grundlagen der Ereignisse

Ereignisse („Events“) können eintreten oder ausgelöst werden und werden durch einen Kreis dargestellt. Das Auslösen kann aus dem Prozess heraus oder durch eine Nachricht von außen geschehen.
Es gibt Start-, Zwischen- („Intermediate-“) und Endereignisse. Ereignisse können auch an Aktivitäten angeheftet sein (so genannte „Boundary Events“) und so u.a. auftretende Sonderfälle abdecken.
Ereignisse können beim Eintreten den umgebenden Prozess unterbrechen (durchgezogene Umrandung) oder nicht unterbrechen (gestrichelte Umrandung). Eine Übersicht aller Ereignisarten kann der nachfolgenden Abbildung entnommen werden.

Ereignisarten in BPMN 2.0

Einsatz von Ereignissen

Ein Ereignis leitet einen Prozess ein und anderes beendet diesen. Dazwischen kann der Prozess auf definierte Ereignisse warten oder diese erzeugen.
Da Ereignisse keine Aktivitäten darstellen, dürfen sie keine komplexen Abläufe beinhalten. Auch der Name sollte kein aktives Verb, sondern eine Beschreibung des Zustands widerspiegeln (z.B. "Party gefeiert" statt "Party beenden").
Im nachfolgenden Beispiel beginnt der Prozess dann, wenn es einen Grund zum Feiern gibt. Nachdem die Einladungen verschickt worden sind, wartet der Prozess so lange, bis der geplante Tag eintritt. Nachdem die Party gefeiert wurde, hat dieser Prozess den Status "Party gefeiert".

Einfacher Gebrauch von Ereignissen

Ereignis-Gateways

Es kann vorkommen, dass eines von mehreren möglichen Ereignissen den weiteren verlauf des Prozesses bestimmt. In diesem Zusammenhang werden Ereignis-Gateways (engl.: "Event-Gateways") wichtig (eine Übersicht der Gateways gibt in diesem Beitrag).
Im nachfolgenden Beispiel wartet der Prozess darauf, dass entweder eine Antwort erhalten wurde oder 12 Tage verstrichen sind.

Einsatz des exklusiven Ereignis-Gateways

Angeheftete Ereignisse

Es kann sein, dass Aktivitäten durch eintretende Ereignisse beeinflusst werden oder dass diese Aktivitäten selbst während der Durchführung Ereignisse eintreten lassen. Daher können Ereignisse an Aktivitäten oder aufgeklappte Teilprozesse angeheftet werden.
Ob ein Ereignis die Tätigkeit am angehefteten Objekt unterbricht kann an der Umrandung des Ereignisses abgelesen werden: ist die Linie durchgezogen, dann unterbricht das Ereignis den internen Fluss. Ist die Linie gestrichelt, dann wird das Ereignis parallel zum internen Fluss bearbeitet.
Im nachfolgenden Beispiel stehen die Aufräumarbeiten der zuvor gefeierten Party an. Während die Aktivität "Wohnung aufräumen" ausgeführt wird, kann es passieren, dass der Akteur feststellt, dass er wegen eines Aufräum-Solos nicht die notwendige Motivation aufbringt. Die Aktivität wird also unterbrochen und der Prozess wird an einer anderen Stelle fortgesetzt. In diesem Fall endet der Prozess in einem Abbruch-Ereignis, was den hier dargestellten Teilprozess beendet.
Alternativ dazu kann es sein, dass während der Ausführung der Aktivität eine nicht-unterbrechende Nachricht von einem Freund erhalten wird. Der interne Fluss der Aktivität wird nicht unterbrochen. Egal ob der Freund angerufen hat oder nicht: wenn die Aktivität "Wohnung aufräumen" abgeschlossen wurde, wird anschließend noch einmal eine Putzparty gefeiert.

Einsatz von angehefteten Ereignissen an Tasks

Gateways in BPMN 2.0

2014-01-25T12:46:00.000+01:00

In einem Prozess müssen häufig Entscheidungen getroffen werden. Wenn diese einfacher Natur sind (und nicht etwa einem komplexen Regelwerk zugrunde liegen), so können sie mit Hilfe von Gateways ausgedrückt werden.
In BPMN 2.0 werden alle Verzweigungen oder Zusammenführungen als Gateways bezeichnet und durch eine kleine Raute dargestellt. Ein Gateway kann z.B. eine bedingte oder eine parallele Ausführung eines Prozesspfades zur Folge haben.

Gatewayarten in BPMN 2.0

Verwendung von Gateways

Gateways sind keine Aktivitäten
Wichtig ist, dass ein Gateway keine Tätigkeit ausführt. Ein Gateway verändert nicht den Zustand eines Objekts oder beinhaltet eine prüfende Aktivität. Gateways arbeiten nur mit bereits vorhandenen Daten. Für Entscheidungspunkte werden XOR-Gateways verwendet; die Synchronisierung kann direkt an einer Aktivität erfolgen.

Antipattern: Gateways dürfen nicht als Aktivität fungieren.

Korrekt: Die Aktivität zur Entscheidungsfindung ist vorgeschaltet, das Gateway wertet nur aus.

Standardpfad
Wenn angedeutet werden soll, dass einer der Pfade dem Standardfall entspricht, so kann dies mit einem kleinen Querstrich am Sequenzfluss kenntlich gemacht werden.

Standardverwendung von Gateways

Antipattern: Inkonsistenter Gebrauch von Gateways

In der BPMN können Bedingungen auch mit bedingten Sequenzflüssen realisiert werden. Dabei werden die Sequenzflüsse mit einer leeren Raute und einer Bedingung versehen. Wie in der nachfolgenden Abbildung dargestellt, kann so eine etwas kompaktere Darstellung bewirkt werden.

Ersetzung eines Gateways durch bedingte Sequenzflüsse

Da nun aber in einer Aktivität mehrere Sequenzflüsse ein- und ausgehen können, wird die Lesbarkeit beeinträchtigt und somit die Interpretierbarkeit erschwert.

Antipattern: Schlechte Synchronisierung mit Teilprozessen

Wenn Teilprozesse mehrere Endereignisse besitzen, kann es zu Synchronisierungsproblemen mit nachgelagerten Gateways kommen, wenn diese eine falsche Fragestellung aufweisen.
In der nachfolgenden Abbildung ist dargestellt, wie ein XOR-Gateway mit einer Entscheidungsfrage das Ergebnis eines Teilprozesses abfragt.

Antipattern: Entscheidungsfragen nach einem Teilprozess erhöhen das Risiko von Synchronisierungsproblemen.

Sollte der Teilprozess später mehr als nur zwei Endereignisse definiert haben, so kann es bei der Ausführung zu einer Fehlermeldung kommen, wenn das nicht abgefangene Endereignis eintritt.
Wenn das Gateway nicht mit einer Entscheidungsfrage versehen wird, lassen sich relativ unkompliziert weitere, voneinander unabhängige Zustände ergänzen und das Matching von Endereignis und Gateway fällt deutlich leichter.

Korrekt: Das Gateway besitzt keine Entscheidungsfrage und kann mehrere Endereignisse verarbeiten.

Bei vielen zu differenzierenden Ereignissen kann die Verwendung von Boundary Events hilfreich sein.

Lose Kopplung durch SOA

2014-01-02T13:12:00.001+01:00

Ein wesentlicher Bestandteil des Software-Paradigmas SOA - "Service Oriented Architecture" ist die lose Kopplung. Diese dient der Reduzierung von Abhängigkeiten zwischen Systemen.

Ziel der losen Kopplung

Das Ziel von loser Kopplung ist die Erreichung einer größtmöglichen Unabhängigkeit, sodass im Falle eines Systemausfalls oder einer signifikanten Änderung nicht alle weiteren Systeme negativ davon betroffen werden.

Eine lose Kopplung reduziert Abhängigkeiten zwischen Systemen.

Begriff der Kopplung

Der Begriff der "Kopplung" stammt aus dem Software-Engineering und entspringt dem Gedanken eines modularen Software-Designs. Ein modulares Design hat das Ziel, eine maximal hohe Kohäsion bei minimaler Kopplung zu erreichen. Alle Informationen sollen demnach in modularer Programmierung verborgen werden.

Wann ist etwas lose gekoppelt?

Stellen wir uns dazu vor, dass A eine Komponente mit einer Abhängigkeit zu einer Komponente B sei. A ist nach [1] dann mit B lose gekoppelt, wenn die folgenden Aussagen zutreffen:

Wissen

A hat minimale Kenntnis von B. Das kann bedeuten, dass A und B nicht denselben Datenspeicher verwenden. Weiterhin kennt A nicht die Technologie der Implementierung (z.B. Programmiersprache, Datenbanksystem usw.) von B.

Abhängigkeit von Verfügbarkeit

A kann auch dann arbeiten, wenn B (oder die Verbindung zu B) temporär nicht verfügbar ist. Während B im Normallfall synchron aufgerufen wird, kann es im Falle einer Störung als "ausstehend" markiert werden. B wird nun asynchron aufgerufen, sodass die erforderlichen Tätigkeiten durchgeführt werden, sobald B wieder verfügbar ist.

Vertrauen

B vertraut nicht darauf, dass A alle Vorbedingungen erfüllt. B prüft alle Eingangsdaten von A auf Fehler.
A vertraut nicht darauf, dass B alle Nachbedingungen erfüllt. A prüft alle Ergebnisdaten von B auf Fehler.

Regeln für eine lose Kopplung

Lose gekoppelte Systeme benutzen keine gemeinsame Datenbank.
Lose gekoppelte Systeme kommunizieren asynchron (aus Geschäftssicht).
Lose gekoppelte Systeme laufen nicht in einem gemeinsamen transaktionalen Kontext.

Getrenntes Transaktions-Management

Getrennte Datenbanken

Asynchrone Kommunikation

Kompensationen

Die letzte Regel dürfte einige Fragen aufwerfen: Wie kann die Datenkonsistenz gewährleistet werden, wenn es keinen gemeinsamen Transaktionskontext gibt?
Die Antwort lautet: Durch Kompensationen. Es muss für jeden Vorgang ein Kompensationsvorgang vorhanden sein. Wenn ein Abbruch stattfindet, werden die zugehörigen Kompensationsvorgänge aufgerufen. Dabei ist ein solcher Abbruch kein einfaches technisches Rollback, sondern ein Geschäftsvorgang; bei diesem können zum Beispiel Gebühren für eine Geschäftsstornierung auftreten.

Tentative Operations

Wenn damit zu rechnen ist, dass es häufig zu einem Abbruch kommt, werden "tentative operations" (ausstehende Vorgänge) eingesetzt: im Falle einer Reisebuchung wird nicht eine verbindliche Buchung, sondern eine Reservierung implementiert. Die eigentliche Buchung wird erst dann gültig, wenn die Bestätigung erfolgt ist.

Umsetzung und technische Aspekte

Realisiert wird die lose Kopplung u.a. dadurch, dass Dienste beim Benutzer nicht fest mit einer (IP-)Adresse hinterlegt werden. Stattdessen veröffentlicht der Dienstanbieter seinen Dienst in einem Dienstverzeichnis. Bei der Verwendung des Dienstes wird dieser nur über seinen Domänennamen aufgerufen.
Weitere technische Aspekte von loser Kopplung sind u.a. eine Unabhängigkeit der Benutzeroberflächen- und Prozesssteuerung, ein asynchroner Kommunikationsstil und eine ereignisgesteuerte Prozesssteuerung. [2]

Nachteile

Leider ist die Berücksichtigung von loser Kopplung (die übrigens nur schwerlich mit Metriken gemessen werden kann) in einer Architektur auch mit einer größeren Komplexität verbunden, da auf diese Weise umgesetzte Systeme schwerer zu entwerfen, zu realisieren und zu pflegen sind. [3]
Dem entgegen zu setzen ist der Umstand, dass ohne eine SOA und lose Kopplung die Komplexität der IT-Landschaft ein viel größeres Ausmaß annehmen würde und somit langfristig betrachtet gar nicht mehr beherrschbar wäre.

Glossar

Kohäsion = Die Fähigkeit einer Programmeinheit, eine logische Aufgabe oder Einheit abzubilden. In einem System mit starker Kohäsion ist jede Programmeinheit (eine Methode, eine Klasse oder ein Modul) verantwortlich für genau eine wohldefinierte Aufgabe oder Einheit. [4]

Quellen

[1] Gregor Engels, Andreas Hess, Bernhard Humm, Oliver Juwig, Marc Lohmann, Jan-Peter Richter, Markus Voß, Johannes Willkomm: Quasar Enterprise – Anwendungslandschaften serviceorientiert gestalten. dpunkt.verlag GmbH, 2008.

[2] Hajo Normann, Bernd Trops, Clemens Utschig-Utschig, Torsten Winterberg: Lose Kopplung - Warum das Loslassen verbindet. In: SOA Spezial Vol. 1, 2009.
[3] Nicolai Josuttis: SOA in der Praxis. dpunkt.verlag GmbH, 2009.
[4] Wikipedia: Kohäsion (Informatik) — Wikipedia, Die freie Enzyklopädie. Version: 1 2013.

Vision von SOA und BPM

2013-12-27T20:42:00.000+01:00

Um im Zeitalter der Globalisierung als Unternehmen auf dem Weltmarkt bestehen zu können, wird eine solide Infrastruktur benötigt, die es ermöglicht, die global angebotenen Dienste in Anspruch zu nehmen oder die eigenen Dienstleistungen an den Markt zu bringen.
Während die Globalisierung auf der einen Seite die Beschreitung neuer Märkte und Akquise neuer Kundenfelder ermöglicht, erhöht sich gleichzeitig massiv der Konkurrenzdruck. Um nicht in der grauen Masse zu verschwinden, sind Marktanteile ein wichtiges Gut. Deswegen liefern sich die Unternehmen regelrechte Wettrennen, wenn es darum geht, einem Produkt ein neues Feature zu verpassen. Wer zu spät einsteigt, riskiert Teile des Kundenstamms einzubüßen.

Die Globalisierung erfordert eine schnelle Reaktionsfähigkeit am Markt.

Daher fordern Manager neben einer möglichst effizienten Produktion vor allem schnellere Wege von der Idee zur Umsetzung (engl. „Time To Market“). Das ist aber nur möglich, wenn die Abteilungen eines Unternehmens enger zusammen arbeiten und Geschäftsprozesse nicht durch eine zähe Eigenbürokratie gebremst werden.

Verteilte Systeme

Um diese engere Verzahnung der Abteilungen ermöglichen zu können, werden verteilte Systeme geschaffen, die miteinander kommunizieren können und eine Wertschöpfungskette ohne Medienbruch ermöglichen. Um die Kommunikation kontrolliert ablaufen lassen und das Routing elektronischer Dokumente steuern zu können werden zur Abbildung eines Geschäftsprozesses die Geschäftsregeln und Entscheidungspfade in das neue System implementiert.

Vorteile der Prozessvirtualisierung

Dabei soll die Rechnerunterstützung

„die Minimierung der für die Wertschöpfung unproduktiven Transport- und Liegezeiten ermöglichen und den Beteiligten Transparenz über den aktuellen Zustand und die Arbeitsfortschritte verschaffen. Durch die Vorgabe von festen Regeln kann der Ablauf von wiederkehrenden, stark strukturierten Prozessen in einer vom Betrieb gewünschten Art und Weise erzwungen werden.“ [1]

Mit Hilfe elektronischer Geschäftsregeln fällt die Vereinheitlichung und Anpassung von Prozessen leichter.

Qualitätssicherung und Image

Doch die so standardisierten Geschäftsprozesse spielen nicht nur im Bereich der Qualitätssicherung
eine wichtige Rolle – auch das Image des Unternehmens soll vereinheitlicht werden. Bei einem Stamm von 500 Mitarbeitern und mehr ist es aber sehr aufwändig, diese alle auf einem aktuellen Wissensstand zu halten. So ist es für Sachbearbeiter ohne eine strikte Unterstützung der IT nahezu unmöglich, die jeweils neuesten Geschäftsregeln und Kommunikationspfade zu kennen und sich dem Kunden gegenüber immer gleich
(fair) zu verhalten.

Prozesstransparenz

Damit ein Unternehmen erfolgreich gesteuert werden kann, muss das Management seinen „Kurs“ kennen und zügig über auftretende Probleme oder Chancen informiert werden.
Wurden erst einmal alle Geschäftsprozesse virtualisiert, so können mit Hilfe von an entscheidenden Knotenpunkten gemessenen KPIs* und dem Einsatz von BAM* auftretende Probleme schneller identifiziert und entsprechende Gegenmaßnahmen eingeleitet werden.

Gerade in den Zeiten einer Weltwirtschaftskrise muss man darauf gefasst sein, dass selbst langjährige Handelspartnerbeziehungen aufgegeben werden müssen. Damit das Unternehmen keine unnötigen Verzögerungen erfährt oder gar einen Produktionsstillstand erleidet, müssen die Geschäftsprozesse sich leicht an neue Handelspartner anpassen können.

Altsystem müssen ersetzt oder so erweitert werden, dass sie moderne Kommunikationsschnittstellen bedienen können.

Erwartungen

Mit Hilfe von SOA und BPM hofft die Industrie, Unternehmensstrukturen erschaffen zu können, die sich mit minimalem Zeit- und Ressourcenverbrauch auf neue Geschäftsprozesse einstellen können, um sich somit einen entscheidenden Vorteil gegenüber der Konkurrenz zu verschaffen. Mitunter gibt es auch die Wunschvorstellung, dass neue Geschäftsprozesse einfach vom Management selbst zusammengeklickt werden können, ohne dass dabei die Einbindung der IT-Abteilung notwendig ist.

Glossar

KPI = Key Performance Indicator – Kennzahl für den direkten Unternehmenserfolg.
BAM = Business Activity Monitoring – Verfahren zur direkten Überwachung des Geschäftswesens
ohne die Zeitverzögerung durch ein DataWareHouse.

Quellen

[1] Hansen, Hans R. ; Neumann, Gustaf: Wirtschaftsinformatik 1 - Grundlagen und Anwendungen. F. X. Bea, B. Friedl, M. Schweitzer, 2005.

Historische Entwicklung von BPM

2013-12-19T01:28:00.001+01:00

Auf der Suche nach Möglichkeiten, sich das Leben bequemer zu gestalten und mit immer weniger Arbeitsaufwand größere Erträge zu erzielen, begann der Mensch, Werkzeuge zur Erleichterung von monotonen Arbeiten zu entwickeln. Bereits im Altertum verwendete der Mensch Windräder, um Maschinen anzutreiben. Damit diese Windräder mit der maximal möglichen Effizienz funktionierten, wurde 1745 ein zusätzliches Getriebe entwickelt, welches das Windrad veranlasste, sich eigenständig in den Wind zu drehen:
der Automatismus war geboren. [1]

Windmühlen waren die ersten vollautomatischen Maschinen.

„Wenn jedes Werkzeug auf Geheiß, oder auch vorausahnend, das ihm zukommende Werk verrichten könnte, . . . so bedürfe es weder für den Werkmeister der Gehilfen noch für die Herren der Sklaven.“

Aristoteles

Bald darauf folgten vor allem im Kontext der industriellen Revolution viele Erfindungen, die einen menschlichen oder tierischen Krafteinsatz mehr und mehr überflüssig machten. Der Einzug der Elektrizität ermöglichte die verteilte Produktion per Fließbandfertigung und die Entwicklung von integrierten Schaltkreisen (sog. „ICs – Integrated Circuits“) wurde eingesetzt, um in den Werkzeugen erstmals Logik zu implementieren.

Die Automatisierung macht den Krafteinsatz des Menschen oft überflüssig.

Taylorismus

Während technische Innovationen immer effizientere Verfahren zur Erhöhung der Produktivität ermöglichten, fand sich die damalige Gesellschaft mit neuen Problemen konfrontiert. Der Taylorismus – der erfolgreiche Versuch, die Produktion vollständig zu rationalisieren und Menschen als Maschinen zu betrachten – führte zu allgemeiner Unzufriedenheit, zunehmender Arbeitslosigkeit, Arbeitsentfremdung und nicht zuletzt auch vermehrt zu physischen und psychischen Gesundheitsstörungen der Arbeiter. [2]

Wandel der Arbeit

Durch den Einsatz der Computertechnologie und der Software-Entwicklung wurde das Verwaltungswesen grundlegend verändert und die Arbeit der Menschen verlagerte sich zunehmend auf Tätigkeiten wie Administration, Planung, Kontrolle und Dienstleistungen. Die Globalisierung erforderte ein koordiniertes Zusammenarbeiten weit voneinander entfernter Filialen und Geschäftspartner. Die zunehmende Virtualisierung der Arbeit brachte viele Systeme zur Verwaltung von Kunden, Verträgen, Lieferketten, usw. hervor.

Der Wandel der Arbeit macht den Menschen zum Verwalter der Dinge.

Insellösungen

Da diese Anwendungen „in sich abgeschlossen“ sind und für jeweils eine bestimmte Abteilung entwickelt wurden (sog. „Insellösungen“), ist es aufwändig, einen Geschäftsprozess vollständig durch alle Ebenen im Unternehmen zu verfolgen und zu bewerten. Eine Konsequenz dieser Insellösungen waren auch Medienbrüche (z.B. das Ausdrucken von Daten und die erneute Eingabe in das Folgesystem) und damit einher gehende Fehlerraten und Verzögerungen im Business-Zyklus.

Verteilte Architekturen

Bald entstanden Software-Architekturen und Technologien wie z.B. CORBA*, die ein Zusammenarbeiten von heterogenen Systemen ermöglichten. Schließlich ging auch der Architekturtyp „SOA“ – die dienstorientierte Architektur – aus dieser Entwicklung hervor und ermöglichte so die Nutzung der vorher in den Systemen verschlossenen Funktionalitäten als im gesamten Unternehmen angebotene Dienste.

Wie bei einem Speichensystem hält eine SOA die Dienste an einer zentralen Stelle verfügbar.

Diese Dienste können im Rahmen des Geschäftsprozessmanagements (BPM) mit Hilfe von sog. Workflow-Management-Systemen miteinander so verknüpft werden, dass selbst die komplexesten Prozesse, Entscheidungspfade und Geschäftsregeln abgebildet werden können. Der Mitarbeiter wird somit zugunsten der Produktivität zunehmend nicht nur von körperlicher sondern auch von geistiger Arbeit befreit.

Glossar

CORBA = Common Object Request Broker Architecture – eine Middleware mit plattformübergreifenden

Protokollen und Diensten zur vereinfachten Erstellung verteilter Anwendungen in heterogenen

Umgebungen.
SOA = Service-Oriented-Architectue. Ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird.

Quellen:

[1] Wikipedia: Automatisierung — Wikipedia, Die freie Enzyklopädie. Version: 11 2009.
[2] Wikipedia: Taylorismus — Wikipedia, Die freie Enzyklopädie. Version: 11 2009.

Datenobjekte in BPMN 2.0

2013-12-16T00:38:00.000+01:00

Auch wenn die BPMN keine Datenmodellierung abdeckt, so können dennoch Datenobjekte („Data Objects“) oder Artefakte in die Geschäftsprozessmodelle aufgenommen werden. Datenobjekte werden durch ein Dokumentsymbol gekennzeichnet.

Datenobjekte in der BPMN 2.0

Datenmodell und Artefakte

In einem Prozess gibt es meist einen definierten Input und/oder Output. Dieser kann bspw. in Form eines Dokuments, eines Datensatzes oder einer E-Mail vorliegen und ist oft so wichtig, dass er im Prozessmodell nicht fehlen darf.

Fehlende Datenmodellierung

Die BPMN erlaubt zwar die Platzierung von Datenobjekten, aber sie enthält keine Möglichkeiten zur technischen Definition. Dafür gibt es bereits sehr gute Sprachen wie z.B. die UML, welche u. a. mit Klassendiagrammen eine Datenstruktur beschreiben kann.
In der nachfolgenden Abbildung werden exemplarisch ein Data Store (vergleichbar mit einer global verfügbaren Datenbank) und diverse Data Objects (nur verfügbar innerhalb der jeweiligen Prozessinstanz) eingesetzt.

Verwendung von Datenobjekten

Aktivitäten in BPMN 2.0

2013-12-16T00:16:00.001+01:00

Eine Aktivität („Activity“ oder auch „Task“) stellt eine Arbeitseinheit eines Prozesses dar. Sie kann selbst Aktivitäten beinhalten; dann wird sie als Teilprozess („Sub-Process“) bezeichnet. Eine Aktivität wird immer als ein Rechteck mit abgerundeten Ecken dargestellt und kann in vielen Ausprägungen vorkommen. Aktivitäten werden durch gerichtete Kanten miteinander verbunden, die Sequenzflüsse („Sequence flows“) genannt werden.

Aktivitätsarten in der BPMN 2.0

Aktivitätstypen

Optional kann ein kleines Symbol in der linken oberen Ecke Auskunft über den Aktivitätstyp (z.B. „Human Task“ oder „Service Task“) geben. In der BPMN wird zwischen verschiedenen Aktivitätstypen unterschieden, die jeweils den Charakter einer Aktivität beschreiben.
Diese Aktivitätstypen sind mit Ausnahme des Typs „Manuell“ für die Abläufe innerhalb der Process Engine konzipiert. Eine „Benutzer“-Aktivität ist demzufolge als eine Aufgabe zu verstehen, welche die Process Engine an eine menschliche Rolle richtet.

Aktivitätstypen in der BPMN 2.0

Typmarkierung

Die Typmarkierung von Aktivitäten ermöglicht u.a. eine einfache Übersicht über Zugriffe auf andere technische Systeme bzw. deren Schnittstellen. Da ein Teilprozess mehrere (unterschiedliche) Aktivitäten repräsentiert, können Teilprozesse und Aufrufteilprozesse keine Typmarkierungen erhalten.

Einführung in das Geschäftsprozessmanagement

2013-12-14T02:50:00.003+01:00

Es gibt viele Wissensrepräsentationsformulismen, um die Umwelt zu beschreiben. Oft werden Texte verfasst, Diagramme erstellt, Karten gezeichnet oder Modelle erstellt.

Modelle

Modelle stellen im Allgemeinen eine vereinfachte Sicht auf einen Sachverhalt dar. Der Grad der Vereinfachung wird dabei durch den Modellierenden festgelegt. Dieser wählt anhand eines definierten Rahmens (Zielgruppe, Zeitpunkt, Zweck), welche Attribute des Originals in das Modell übernommen werden sollen. [1]

In einem Unternehmen werden mit Hilfe der Prozessmodellierung die hauseigenen Geschäftsprozesse erfasst und sichtbar gemacht. Die so entstandenen Geschäftsprozessmodelle bilden die Grundlage für ein gemeinsames Verständnis über die verschiedenen Ebenen der Wertschöpfungskette sowie deren unterstützenden Prozesse.

Prozessmodelle helfen bei der Orientierung im unternehmensweiten Prozessgefüge.

Der Wandel der Prozesse

Durch den Einsatz von technischen Systemen wie z.B. einem Enterprise-Resource-Planning (ERP)-System, Customer-Relationship-Management (CRM)-System oder einem Document Management System (DMS) werden zunehmend aus manuellen „Offline-Tätigkeiten“ elektronische Prozessschritte.
Damit die IT den Ansprüchen aus den Fachabteilungen gerecht werden kann, werden abstrahierte Vereinbarungen getroffen, deren Anforderungen in einem iterativen Prozess konkretisiert werden.

Technische Modellierung

Für eine Realisierung dieser Anforderungen werden technikzentrierte Modelle, Schnittstellenbeschreibungen und Strukturen von Geschäftsprozessobjekten erstellt, die der IT zur Dokumentation und Verifizierung dienen. Der Grundgedanke dieser technischen Prozessmodellierung

"ist die explizite Repräsentation von dynamischen Aspekten eines Systems. Durch die explizite Repräsentation ist nicht nur eine verbesserte Wart- und Erweiterbarkeit durch Techniken wie automatische Codegenerierung gegeben, vielmehr wird dadurch erst die Erstellung von komplexen Systemen ermöglicht." [2]

Technische Modelle helfen bei komplexen Vorhaben enorm.

Der Ursprung des Prozesswesens

Das bewusste Planen, Optimieren und Steuern von Geschäftsprozessen wird Geschäftsprozessmanagement genannt. Es wurde ca. 1776 durch Adam Smith und seine Arbeit "Wohlstand der Nationen" begründet. Smith hatte damals festgestellt, dass durch Arbeitsteilung und Spezialisierung eine enorme Steigerung der Produktivität erreicht werden kann. [3]

Wandel der Organisation

Das heutige Verständnis des Prozesswesens sowie dessen Struktur ist stark durch das Jahr 1930 beeinflusst, als zunehmend eine Trennung der Organisationsbetrachtung in Aufbau- und Ablauforganisation gefordert wurde. Infolgedessen ergab sich ein Wandel der Unternehmenssichtweise, sodass nun nicht mehr die Strategie die Struktur vorgibt, sondern die aus der Strategie entspringenden Prozesse. [4]
Es folgte eine Organisierung der Mitarbeiter nach funktional getrennten, aber prozessual zusammengehörigen Aufgaben. Den Mitarbeitern wurden so Einblicke in die jeweils vor- und nachgelagerte Tätigkeit ermöglicht.

Das Prozesswesen und die Organisationsbetrachtung hängen eng zusammen.

Eigenverantwortung für den Mitarbeiter

Durch das Prinzip der Subsidiarität - eine Maxime, welche die Entfaltung der individuellen Fähigkeiten, Selbstbestimmung und Eigenverantwortung anstrebt - wurden dem Mitarbeiter mehr Handlungsfreiraum und größere Verantwortung gegeben. [5] Gerade bei komplexen Geschäftsprozessen obliegt es somit dem Mitarbeiter, wie im Einzelfall verfahren werden soll, wie der Kunde behandelt wird und wie somit das Unternehmen nach außen hin wahrgenommen wird.

Prozessstandardisierung

Um sowohl in der Prozessqualität als auch im Unternehmensbild die notwendige Konsistenz zu erreichen, gibt es Arbeitsanweisungen und -vorschriften. Diese Anweisungen können sowohl den Prozess als Ganzen abstrahiert beschreiben als auch genaue Anweisungen für den operativen Part enthalten.

Arbeitsanweisungen dienen der Einhaltung von Qualitätsvorgaben und Prozesskonsistenz.

Notwendigkeit von BPMS

Da jedoch einige Prozessregelungen wegen ihrer Komplexität nur schwierig in einer vollständigen Form in den Köpfen der Mitarbeiter verankert werden können, ein erheblicher Schulungsaufwand damit verbunden ist und die Verzögerung von der geplanten Prozessänderung bis zur geänderten Prozessausführung geschäftsschädigend sein kann, wurden IT-gestützte Maßnahmen verlangt.
Das heutige Business Process Management ist durch den Einsatz von Business Process Management Suites (BPMS) in der Lage, Prozesse zu automatisieren und zu überwachen und somit für einen konsistenten Prozessfluss, schnellere Abarbeitungen und eine deutlich erhöhte Transparenz zu sorgen.

Quellen

[1] Herbert Stachowiak, Allgemeine Modelltheorie.
[2] Frank Puhlmann, Arnd Schnieders und Mathias Weske (Herausgeber): Prozessmodellierung. Potsdam, September 2009. Hasso Plattner Institut für Softwaresystemtechnik.
[3] Tim Weilkins, Christian Weiss und Andrea Grass: Basiswissen Geschäftsprozessmanagement. dpunkt.verlag GmbH, 2010.
[4] Wikipedia: Betriebswirtschaftliche Organisationslehre — Wikipedia, Die freie Enzyklopädie, Februar 2012.
[5] Wikipedia: Prozessmanagement — Wikipedia, Die freie Enzyklopädie, Februar 2012.

BPMN - Eine Notation revolutioniert Fachmodelle

2013-12-14T02:02:00.000+01:00

BPMN steht für "Business Process Model and Notation" und ist ein relativ neuer Standard zur Modellierung von Geschäftsprozessen und Prozessumgebungen. Die BPMN wird von der Object Management Group (OMG) vorangetrieben und stellt mittlerweile eine Grundvoraussetzung für das Geschäftsprozessmanagement dar. [1]

Die BPMN wurde speziell so entwickelt, dass sie einfach zu verstehen ist und dennoch komplexe Geschäftsprozesse abbilden kann. Der Informationsfluss eines Geschäftsprozesses wird durch eine Folge von Aktivitäten und ausgetauschten Nachrichten zwischen verschiedenen Rollen modelliert. [1][2]

Beispiel eines BPMN-Kollaborationsdiagramms.

Ziel von BPMN

Die OMG definiert, dass das primäre Ziel von BPMN darin liegt,

"eine Notation zu schaffen, die sehr einfach zu verstehen ist: sowohl von der Fachabteilung, vom Business-Analysten (der die ersten Entwürfe des Prozesses erstellt), vom technischen Entwickler (der für die Technologieimplementierung zur Abarbeitung des Prozesses verantwortlich ist, als auch für das Management, welches die Prozesse verwaltet und beobachtet.
Somit stellt die BPMN eine standardisierte Brücke für die Lücke zwischen dem Geschäftsprozessdesign und der Prozessimplementierung dar.
Ein weiteres, nicht weniger wichtiges Ziel besteht darin, sicherzustellen, dass XML-Sprachen, die für die Ausführung von Geschäftsprozessen gedacht sind (wie bspw. WS-BPEL), mit einer geschäftsorientierten Notation visualisiert werden können." [3]

BPMN als Brücke zwischen Design und Implementierung

Abgrenzung

BPMN ist nicht zur Modellierung von organisatorischen Strukturen, funktionalen Dekompositionen, Statusübergängen oder Datenmodellen geeignet. [3] Weiterhin handelt es sich nicht um eine Repräsentation im Sinne eines Datenflussdiagramms, obwohl es auch Teile des Datenflusses zeigt und Datenartefakte mit Aktivitäten assoziiert. [4]

Etwas Geschichtsunterricht: Die Historie von BPMN

Die Entwicklung der BPMN begann 2001 als Projekt von Stephen White unter dem Namen "Business Process Modeling Notation" und wurde im Mai 2004 im Namen der Business Process Management Initiative (BPMI) als Version 1.0 veröffentlicht.
Im Jahr 2005 ging die BPMI in der OMG auf, welche im Januar 2008 die Version 1.1 veröffentlichte. Die Änderung der Version 1.1 führte hauptsächlich "catching" und "throwing" Events ein. Im Januar wurde die Version 1.2 veröffentlicht, die vorwiegend aus kleineren Korrekturen bestand. [4]

Die im Januar 2011 veröffentlichte Version 2.0 enthält viele Neuerungen: neue Diagramme, Diagrammelemente und Prozessarten. Dabei wurde auch der Name von BPMN auf "Business Process Model and Notation" geändert, um auf das neue "formale Metamodell" hinzuweisen. [5]

Versionshistorie von BPMN 2.0

Wichtige Neuerungen in der Version 2.0

Die BPMN wurde bei der Version 2.0 vor allem in Hinblick auf Austauschbarkeit, Ausführbarkeit und Erweiterbarkeit optimiert. Vereinfacht beschrieben, beinhalten die Neuerungen folgendes:

Austauschbarkeit: Es wurde das offizielle Format "Business Process Definition Metamodel (BPDM) festgelegt, mit welchem der Transfer von BPMN-Modellen zwischen verschiedenen Modellierungswerkzeugen mit Gewährleistung einer gleichbleibenden Semantik möglich ist. [4]

Ausführbarkeit: BPMN entwickelt sich dahingehend, dass es direkt ausführbar ist und somit keine zusätzlichen Transformationen in Prozessausführungssprachen wie BPEL oder XPDL notwendig sind. [6]

Erweiterbarkeit: Mit Hilfe eines Erweiterungsmechanismus zur Serialisierung von BPMN und XML-Schemata können sowohl das Prozessmodell als auch die grafische Repräsentation erweitert werden. Somit können auch menschliche Prozesse besser definiert werden. [3]

Verschiedene Sichten: Die Darstellung und der Austausch von verschiedenen Perspektiven desselben Modells, sodass ein Nutzer sich auf sein spezielles Aufgabengebiet konzentrieren kann. [3]

Neue Diagramme: Mit den neuen Diagrammtypen können Orchestrierungen und Choreographien einzeln oder in andere Diagrammtypen integriert dargestellt werden. [4]

Quellen

[1] Martin Owen und Jog Raj: BPMN and Business Process Management. Popkin Software, September 2003
[2] Object Management Group: Business Process Model and Notation
[3] Object Management Group: Business Process Model and Notation 2.0 (BPMN), Januar 2011
[4] Wikipedia: Business Process Model and Notation — Wikipedia, The Free Encyclopedia, März 2012
[5] Jakob Freund und Bernd Rücker: Praxishandbuch BPMN 2.0. Carl Hanser Verlag München Wien, 3. Auflage Auflage, März 2012.
[6] Sebastian Klein und Erik Hagen: Adopting BPMN with ARIS. Whitepaper, Software AG, Oktober 2010.

Was ist Business Process Management (BPM)?

2013-12-13T00:14:00.000+01:00

Begriffsdefinition von Business Process Management

Die Meinungen über die exakte Definition von Geschäftsprozessmanagement, auch Business
Process Management (BPM) genannt, ist in fast jeder Fachlektüre eine andere. Nach der European Association of BPM (EABPM), lautet die Definition von BPM wie folgt:

"Business Process Management ist ein systematischer Ansatz, um sowohl automatisierte als auch nicht-automatisierte Prozesse zu erfassen, zu gestalten, auszuführen, zu dokumentieren, zu messen, zu überwachen und zu steuern und damit auch nachhaltig die mit der Unternehmensstrategie abgestimmten Ziele zu erreichen. BPM umfasst die bewusste und zunehmend IT-gestützte Bestimmung, Verbesserung, Innovation und Erhaltung von End-to-end-Prozessen." [1]

BPM ist ein wichtiger Baustein in der Unternehmensplanung und -optimierung.

Aspekte von BPM

Mark Treat stellt in seinem Artikel über die Definition von BPM zusammenfassend fest, dass BPM gleichzeitig folgendes darstellt [2]:

ein Prozess zur Verwaltung der Geschäftsprozesse
eine Management-Disziplin
eine Technologie oder ein Set von Technologien
ein Framework zur schnellen Entwicklung von Anwendungen

Der Prozessbegriff

Dabei wird unter einem solchen Geschäftsprozess

"die inhaltlich abgeschlossene, zeitlich-sachologische Abfolge der Funktionen verstanden, die zur Bearbeitung eines betriebswirtschaftlichen Objekts notwendig sind." [3]

Prozesse werden mit Hilfe von BPM beschrieben, gesteuert, modelliert, überwacht und optimiert. Dies geschieht durch den Einsatz eines BPMS (Business Process Management System).

Ein Geschäftsprozess realisiert ein unternehmerisches Ziel.

Prozessautomatisierung per Software

Mit Hilfe eines solchen BPMS können manuelle Prozesse elimiert und das Routen von Anfragen zwischen Abteilungen und Anwendungen automatisiert werden. [4] Die Vorteile sind eine erhöhte Sichtbarkeit, identifizierte Flaschenhälse, Optimierung der Ressourcennutzung, Reduktion der Durchlaufzeiten und eine Redefinition von Rollen und Pflichten. [5]

BPM ist nicht gleich BPM

Die Abkürzung "BPM" steht gleichzeitig für "Business Process Management" als auch für "Business Process Modelling" (Geschäftsprozessmodellierung). Während Geschäftsprozessmanagement wie bereits beschrieben die Verwaltung und Verbesserung von Geschäftsprozessen umfasst, so beinhaltet die Geschäftsprozessmodellierung ausschließlich wissenschaftliche Repräsentationsformulismen zur Beschreibung von

"Praktiken oder Maßnahmen, ... um alle Aspekte eines Geschäftsprozesses darstellen oder beschreiben zu können. Dazu gehören der Ablauf, Kontroll- und Entscheidungspunkte, Trigger und Bedingungen für den Aufruf von Aktivitäten, der Kontext, in dem eine Aktivität stattfindet und die dazugehörigen Ressourcen." [6]

Ein Prozessmodell stellt eine grafische Repräsentation eines Prozesses dar.

Dieser Blog befasst sich sowohl mit der Modellierung als auch der Planung und Ausführung von Geschäftsprozessen.

Quellen:

[1] European Association of BPM: BPM Common Body of Knowledge
[2] Mark Treat: What is BPM anyway?, Dezember 2006.
[3] Tobias Rieke: Theoretische Grundlagen der Prozessmodellierung. Westfälische Wilhelms-Universität Münster, Dezember 2003.
[4] OMG: Business Process Model and Notation (BPMN), Januar 2011
[5] Stephen Tillemans: An Introduction to Business Process Management, University of Stellenbosch Business School, August 2010
[6] Nicolai Josuttis: SOA in der Praxis. dpunkt.verlag GmbH, 2009.