Donnerstag, 14. Mai 2015

BPM Architektur: Übersicht der Bestandteile

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.

Samstag, 25. April 2015

Rollen im Business Process Management

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]

Freitag, 24. April 2015

Ereignisse in BPMN 2.0

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

Samstag, 25. Januar 2014

Gateways in BPMN 2.0

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.

Donnerstag, 2. Januar 2014

Lose Kopplung durch SOA

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.

Freitag, 27. Dezember 2013

Vision von SOA und BPM

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.

Donnerstag, 19. Dezember 2013

Historische Entwicklung von BPM

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.

Montag, 16. Dezember 2013

Datenobjekte in BPMN 2.0

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

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.

Samstag, 14. Dezember 2013

Einführung in das Geschäftsprozessmanagement

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.