In vielen Unternehmen hat sich das Phänomen des "BPM Backslide" zu einem nicht mehr vernachlässigbaren Problem entwickelt. Unter "BPM Backslide" wird die Rückkehr der Anwender zu bisher vertrauten, eingefahrenen Arbeitsmustern verstanden. Die Gründe dafür sind mannigfaltig, vor allem aber die von Anwendern wahrgenommene Inflexibilität der Software-Applikationen. Geschäftsprozesse sind zu starr und lassen sich nur aufwändig an geänderte Anforderungen anpassen. Die meist personell unterbesetzte Informatikabteilung hinkt chronisch hinterher und kann Änderungs- und Erweiterungsanforderungen nicht zeitnah befriedigen.

Anwender finden kreativ Wege, die sie für produktiver halten, wobei die Informatikabteilung von diesen Arbeitsmustern meist nichts erfährt. Oft nutzen Anwender unterstützend bereits vertraute Office Software wie etwa Microsoft Excel und Microsoft Access. Das Ergebnis ist "BPM Backslide".

Die Gefahr des "BPM Backslide" lässt sich durch frühzeitiges Einbeziehen der Anwender bei der Prozessmodellierung zumindest eindämmen. Oft aber werden Anwender nicht gehört oder deren Vorschläge nicht genügend berücksichtigt. Dann entsteht eine Art "Paralleluniversum", das Reibungsverluste und Kosten verursacht..

Im Ergebnis verliert die Informatikabteilung kontinuierlich die Kontrolle über die Geschäftsprozesse, denn es koexistieren zwei Versionen eines Geschäftsprozesses: die "offizielle" Version und eine "Schattenversion". Ein "Schatten-Geschäftsprozess" ist der Prozess, der aus Anwendersicht die geforderten Ergebnisse erzielt. Manche Geschäftsprozesse haben sogar mehrere Schattenversionen, wobei im Extremfall jeder Anwender seine eigene Version entwickelt.

Um das "Zwei-Welten-Syndrom" zu eliminieren und die Kluft zwischen offiziellen und Schatten-Geschäftsprozessen zu beseitigen, müssen die Fachabteilungen eine ausgedehntere Kontrolle über den gesamten Lebenszyklus ihrer Geschäftsprozesse erhalten. Bisher sind derartige Bestrebungen allerdings wegen mangelnder Flexibilität und Leistungsfähigkeit der Geschäftsprozess-Managementsysteme (Business Process Management Systems, BPMS) fast immer gescheitert.

Zusätzlich zu den stark strukturierten Geschäftsprozessen, wie z.B. Auftragsbearbeitung, wird zunehmend Unterstützung für unstrukturierte bzw. ad hoc-Geschäftsprozesse gefordert. Unstrukturierte Geschäftsprozesse übersteigen die Anzahl strukturierter Geschäftsprozesse in vielen Unternehmen bei weitem. Allgemeinen Schätzungen zufolge liegt der Anteil unstrukturierter Geschäftsprozesse bei über 60%, und in manchen Branchen noch weit darüber.

Unstrukturierte, vom Ablauf her nicht vorhersehbare Geschäftsprozesse, sind wissensintensiv und verlangen eine völlig andersartige Technologie und Methodologie. Mit dem Begriff "Adaptive Case Management" (ACM) wird das Management hochgradig dynamischer, Geschäftsprozesse beschrieben, die durch ein intensives Zusammenwirken vieler Personen geprägt sind. Weiteres Differenzierungsmerkmal ist die zielorientierte (goal-.oriented) Ausführung unstrukturierter Prozesse, während strukturierte Prozesse (z.B. Bearbeitung eines Zahlungseingangs) als prozedurale Prozesse den Ablauf von Anfang bis Ende spezifizieren.

Jedes Unternehmen verfügt über ein breites Spektrum an Geschäftsprozessen, die alle Schattierungen von unstrukturierten bis hin zu hochgradig strukturierten Prozessen überspannen. Die heute eingesetzten BPMS können nicht die gesamte Bandbreite an Geschäftsprozessen gleich gut unterstützen. Sie unterstützen vor allem strukturierte Prozesse mit relativ geringer Änderungsdynamik und werden unter Kontrolle der Informatikabteilung betrieben.

Viele Unternehmen haben schon vor Jahren ein BPMS eingeführt. Hinzu kommen Anwendungssysteme wie beispielsweise Customer Relationship Management (CRM), die in bestimmten Grenzen ebenfalls BPM unterstützen. Eine Lösung für unstrukturierte und änderungsintensive teilstrukturierte Prozesse fehlt jedoch weiterhin.

Um einer Lösung näher zu kommen, bieten sich im Wesentlichen zwei Alternativen an: zum Einen könnte die Beschaffung eines Adaptive Case Management (ACM) System erwogen werden, zum Anderen eine Lösung, die das gesamte Spektrum an Prozessstrukturierungsgraden unterstützt. Während ein ACM-System die Phalanx eigenständiger IT-Lösungen erweitert, eröffnet eine Integrationslösung das Potenzial, Speziallösungen langfristig überflüssig zu machen und die umfängliche Verantwortlichkeit für BPM zunehmend in die Fachabteilungen zu verlagern.

An dieser Stelle soll lediglich die letztgenannte Alternative eingehender beleuchtet werden. An diese wären konsequenterweise Anforderungen zu stellen, die hauptsächlich auf die Einsatztauglichkeit in den Fachabteilungen abzielen.

Wesentliche Anforderungen orientieren sich an den Charakteristika unstrukturierter Prozesse. Diese sind typischerweise nicht wiederholbar, obgleich es häufig einen Standardablauf gibt, der "Best Practice" abbildet. Jedoch kommt es häufig vor, dass der Ablauf während der Prozessausführung geändert werden muss. Beispielsweise kann es notwendig werden, während der Bearbeitung einer Reklamation eines wichtigen Kunden in den Prozess weitere Aktivitäten einzufügen.

Anwender, die unstrukturierte Prozesse modellieren und ausführen, benötigen eine Software-Umgebung, die sich von der von herkömmlichen BPMS bekannten grundlegend unterscheidet. Da sich der Ausführungsfluss nicht vorhersehen lässt, kann ein Prozess nur ansatzweise modelliert werden. Vielmehr "wächst" ein Prozess zur Ausführungszeit. Am Prozess beteiligte Anwender müssen deshalb Prozessmodellierung und -ausführung kombinieren können.

Seit wenigen Jahren sind Software-Systeme verfügbar, die mit einem universalen Ansatz das gesamte Spektrum von unstrukturierten bis hin zu hochgradig strukturierten Prozessen unterstützen. Dieser Spagat kann jedoch nur mit einer neuartigen Architektur der Software gelingen.

Den Kern der Architektur bildet das Konzept des Business Artifact, von IBM auch als Business Entity bezeichnet. Ein Business Artifact verkapselt Prozesse und Daten, ein grundlegender Unterschied zu Software-Systemen, die Prozesse und Daten getrennt voneinander halten (beispielsweise Daten und Prozesse in getrennten Datenbanktabellen).

Durch das Verschmelzen von Prozessen und Daten eröffnen sich völlig neue Möglichkeiten zur Komposition von Business Artifacts. Das Prinzip lässt sich sehr gut anhand der Chemie illustrieren. Materie existiert in chemischer Form als Atome und Moleküle. Während Atome, repräsentiert im Periodensystem, die Grundbausteine von Materie ausmachen, bestehen Moleküle aus mindestens zwei unterschiedlichen Elementen, die durch chemische Verbindungen zusammengehalten werden. Atome und Moleküle lassen sich zu komplexeren Verbindungen zusammenfügen.

Business Artifacts können sowohl Atome als auch Moleküle sein. Ein Atom wäre beispielsweise ein Attribut wie z.B. "Rechnungsnummer" oder "Vorname". Es wäre irreführend, den Begriff "Datenfeld" zu verwenden, da das Business Artifact auch Prozesse verkapselt. Gemeint sind Prozesse, die den Lebenszyklus eines Business Artifact steuern, wie beispielsweise das Erzeugen einer Rechnungsnummer, das Ändern eines Familiennamens usw. Auch Änderungen von Datenwerten erfolgen prozessgesteuert, auch wenn der Prozess nur wenige Prozessschritte umfasst, die wiederum nur von dazu berechtigten Rollen ausgeführt werden dürfen.

Business Artifacts lassen sich durch Komposition zu grösseren Einheiten aggregieren. Beispiele sind Implementierungen von Konzepten der realen Welt, wie etwa "Rechnung" oder "Artikel". Ebenso lassen sich auch Geschäftsprozesse durch Komposition von Business Artifacts realisieren. Ebenso lassen sich auch Geschäftsprozesse durch Komposition von Business Artifacts, die Konzepte wie etwa "Aktivität" (Activity), "Ereignis" (Event) oder "Gateway" verkörpern, realisieren.

Jedes Business Artifact ist integrales Element der Business Architecture, dem "Bauplan" eines Unternehmens, der Strukturen, Prozesse und auch Business Semantics sichtbar macht. Die Business Architecture ist im Umkehrschluss gewissermassen das allumfassende Business Artifact.

In den meisten Unternehmen spielt das Konzept der Business Architecture faktisch keine Rolle. Der Versuch, die Business Architecture zu beschreiben, scheitert an Modellbrüchen und hoher Änderungsdynamik. Die dokumentierte Business Architecture hinkt der Realität stets hinterher und hat daher nur sehr beschränkten Aussagewert. Deshalb kann eine Business Architecture nur dann einen wirklichen Wert entfalten, wenn sämtliche Änderungen auf der Ebene der Business Architecture erfolgen und Modellbrüche vollständig eliminiert sind. Dann ist Real-time Change Management auf Unternehmensebene realisierbar.

Die Business Architecture gründet auf einem Metamodell, das die Elemente beschreibt, die in der Business Architecture vorkommen dürfen. Ausserdem beschreibt das Metamodell die möglichen Beziehungen zwischen Modellelementen. Als praktisches Beispiel mögen zwei Konzepte auf der Metamodellebene dienen, "Geschäftsprozess" und "Key Performance Indicator", die über eine Beziehung miteinander verbunden sind. Dies bedeutet, dass einem Geschäftsprozess ein Key Performance Indicator zugewiesen werden kann.

Im weiteren Kontext der Business Architecture wurden bereits diverse Metamodell-Spezifikationen von Standardisierungsgremien erarbeitet bzw. befinden sich derzeit in Arbeit. Die Object Management Group (OMG) verantwortet die meisten dieser Spezifikationen. Jede dieser Metamodell-Spezifikationen, wie beispielsweise das Organization Structure Metamodel, repräsentiert ein Fragment eines virtuellen, gesamtheitlichen Business Architecture Metamodells.

Standardisierungsgremien arbeiten fokussiert auf einen bestimmten Problembereich im Rahmen eines umrissenen Mandats. Dass dabei der Blick auf das grosse Ganze fehlt, verwundert nicht. Deshalb werden Spezifikationen parallel und oft ohne Abstimmung der verschiedenen Gruppen untereinander erarbeitet. Mögliche Überlappungen sind deshalb nicht verwunderlich. Andererseits können sich Software-Hersteller auf solche Metamodell-Standards verlasen und diese in ein kohärentes Metamodell integrieren, das einem Software-Produkt zugrunde liegt.

Aus dem Modellblickwinkel betrachtet besteht die Business Architecture aus einer Vielzahl von Business Artifact-Modellen. Jedes Modell ist gleichzeitig eine Vorlage (Template) für das Erzeugen von realen Objekten (Modellinstanzen). Beispielsweise lässt sich aus dem Template des Geschäftsprozesses "Ware ausliefern" die Geschäftsprozessinstanz erzeugen, die die Warenauslieferung für Auftrag 12345 konkret steuert.

Sodann stellt sich die Frage, wie in Business Artifacts verkapselte Prozesse ausgeführt werden können. Wenn Anwender zur Ausführung in der Lage sein sollen, muss die Übersetzung von Modellen in ausführbaren Programm-Code unmerklich erfolgen. Übersetzung und Ausführung verschmelzen somit zu einem Schritt, der von einer "Ausführungsmaschine" (Execution Engine) gesteuert wird.

In der Konsequenz ist ein Kontrapunkt zur gängigen Art und Weise der Software-Bereitstellung gesetzt, die aus einer Vielzahl von Modellen unterschiedlichen Typs ausführbaren Code erzeugt und ohne Reibungsverluste zwischen fachlicher Seite und der Informatikabteilung nicht auskommt.

Business Artifacts lassen sich mit einem einzigen Modelltyp beschreiben. Modelltransformationen können entfallen, und damit werden auch die unvermeidlichen Informationsverluste bei Transformationen eliminiert. Dem "Modellchaos" mit sichtspezifischen, einander teilweise überlappenden Modellen, ist Einhalt geboten. Wenig überraschend wird somit die "Wertschöpfungskette" der Software-Produktion drastisch verkürzt. Im Ergebnis wird die Produktivität gesteigert und die Reaktionsfähigkeit beschleunigt.

Bisherige Erfahrungen mit dem Business Artifact-Konzept überzeugen. Im Vergleich zu herkömmlicher Software-Entwicklung sind Business Artifacts sehr viel schneller erstellt und miteinander kombiniert. In manchen Fällen bewegte sich die Realisierungsdauer im Bereich von 5% gegenüber herkömmlicher Software-Entwicklung.

Die Produktivität lässt sich mit Hilfe von Content Packs weiter steigern. Content Packs umfassen vorgefertigte Business Artifacts für bestimmte Wirtschaftszweige oder Anwendungsbereiche (z.B. Customer Relationship Management, Innovation Management usw.). Vorgefertigte Business Artifacts verkapseln Standardlösungen, die sich natürlich an unternehmensspezifische Anforderungen anpassen und verfeinern lassen. Content Packs werden vom Software-Hersteller selbst oder von einem Drittanbieter bereitgestellt.

Das Anpassen und Zusammenfügen von Business Artifacts lässt sich von Personen ohne spezielle IT-Kenntnisse bewerkstelligen und erfordert in etwa ein Kenntnisniveau, das auch für das Arbeiten mit Office-Software erforderlich ist. Gleichwohl kann auf konventionelle Programmierung nicht vollständig verzichtet werden, etwa wenn komplexere Berechnungen erforderlich sind.

In der Gesamtschau lässt sich ein derartiges, auf dem Business Artifacts-Konzept gegründetes, Software-System als Dynamic Enterprise Management System (DEMS) bezeichnen. Es vereinigt bisher getrennte Software-Systeme, insbesondere Business Process Management (BPM), Adaptive Case Management (ACM), Information Asset Management (IAM), Enterprise Architecture Management (EAM) und Business Semantics Management (BSM). Damit sind alle wichtigen Bereiche des integrierten Enterprise Management abgedeckt.

Das Attribut "dynamic" ist vollauf berechtigt. Schliesslich lässt sich die Ausführung von Prozessen zu jeder Zeit von jeder Person, die über die erforderlichen Rechte verfügt, beeinflussen. "Schattenprozessen" ist die Grundlage entzogen. Real-time Change Management ist Realität.

Seit einigen Jahren sind einige wenige Software-Produkte verfügbar, die als Dynamic Enterprise Management System (DEMS) angelegt sind. Dazu zählen die Living Systems Suite (Whitestein Technologies AG), Appway (Appway Software AG), CONTINUITY (ICS GmbH) sowie die Communications and Process Platform (ISIS Papyrus Group).

Software-Herstellern scheint die Produktpositionierung und das Erschliessen neuer Akquisitions- und Vertriebskanäle Schwierigkeiten zu bereiten. Während bisher primär die Informatikabteilung Adressat der Vertriebsbemühungen war, wandelt sich jetzt das Vertriebsmodell grundlegend. Jetzt befinden sich die Ansprechpartner in den Fachabteilungen. Betriebswirtschaftlich orientierte Argumentation hat Vorrang vor der bisher geübten techniklastigen.

Auch bei der Akquisition von Dienstleistungspartnern, wie etwa Consulting Services Partner oder Cloud Computing Services Provider, haben es die Software-Hersteller nicht leicht. Gerade Cloud Computing Services sind auf Skaleneffekte ausgelegt. Die Zurückhaltung unabhängiger Services Provider ist verständlich solange DEMS-Lösungen noch wenig verbreitet sind. DEMS-Hersteller können jedoch selbst die Rolle eines Cloud Computing Services Provider übernehmen, um Kunden eine niedrige Einstiegschwelle zu bieten.

Die bisher gering ausgeprägten Marketing- und Vertriebsbemühungen der Software-Hersteller lassen eine zögerliche Verbreiterung der Installationsbasis der DEMS erwarten. Dem enormen Marktpotenzial steht eine begrenzte Marketing-Feuerkraft der vornehmlich kleinen und mittelständischen DEMS-Hersteller gegenüber.

Dabei klingen die Nutzenargumente überzeugend. Der Einstieg in die DEMS-Nutzung gelingt mit geringstem Risiko und niedrigsten Kosten mit einer Cloud Computing-Lösung. Der Software-Hersteller oder ein Drittanbieter betreiben das DEMS für mehrere Kunden parallel, wobei aber für jeden Kunden eine abgeschottete Umgebung bereit gestellt wird. Kunden nutzen das DEMS über das Internet. Der Wechsel auf eine Inhouse-Installation ist problemlos möglich.

In der Gesamtschau betrachtet lässt sich das Problem des "BPM Backslide" nur durch eine Flexibilisierung des Modellierungsprozesses auf Basis ausführbarer Modelle lösen. Die Modellierung von Geschäftsprozessen wird in die Fachabteilungen rückverlagert, wobei im Wesentlichen der Prozessstrukturierungsgrad bestimmt, wer die Modellierung übernimmt. Während strukturierte Prozesse mit geringer Änderungsdynamik vorwiegend in den Bereich des Business Analyst fallen, werden unstrukturierte Prozesse zur Ausführungszeit von Personen „komponiert“, die als "Wissensarbeiter" ohne spezifischen IT-Hintergrund bezeichnet werden können. Die Business Architecture bildet die gemeinsame Grundlage, und deshalb ist es auch möglich, neue Geschäftsprozesse sehr schnell aus strukturierten und unstrukturierten Teilprozessen zu erzeugen.

Im Endeffekt ist den Argumenten für "BPM Backslide" der Boden entzogen. Die Individualisierung von Geschäftsprozessen wird mit einem DEMS wesentlich erleichtert, und die Zeitspanne zwischen Modellierung und Ausführung schrumpft praktisch auf Null.

Aus betriebswirtschaftlicher Sicht ergeben sich ebenfalls messbare Nutzeneffekte. Signifikante Kosteneinsparungen durch wesentlich kürzere Implementierungszeiten, durch Vermeidung von Mehrfacharbeit und geringere Fehlerraten sind beileibe nicht das einzige Argument. Das Konzept der Business Artifacts unterstützt auch auf natürliche Weise die Einbindung von Governance- und Compliance-Prozessen. So lässt sich der gesamte Lebenszyklus von Prozessen auf einheitliche Weise beschreiben und verwalten.