Grenzen und Möglichkeiten

Wolfram Jost ist Vorstandsmitglied der IDS Scheer und Chief Technology Officer.

Mit dem Siegeszug integrierter ERP-Systeme in den Neunzigerjahren kamen monolithische Anwendungen auf. Sie unterstützten bewährte und standardisierte Abläufe aus wichtigen Unternehmensbereichen wie Vertrieb, Controlling oder Finanzbuchhaltung. Auf ernsthafte Schwierigkeiten stiessen die Applikationen aufgrund neuer Trends, wie dem ausgefeilten Management der Lieferketten oder der Kundenbeziehungen. Denn bei Supply Chain Management (SCM) und CRM (Customer Relationship Management) standen die Zusammenhänge mit anderen Organisationen und Kunden im Mittelpunkt. Es ging demnach um unternehmensübergreifende Prozesse. Infolge der hohen Marktdynamik entwickelten sich zusätzliche Systeme. Dabei handelte es sich aber um erneut in sich geschlossene Konstrukte wie etwa spezialisierte CRM-Applikationen.

Die so eingeführten Best-of-Breed-Anwendungen mussten dann für die Zusammenarbeit aus Datensicht konsolidiert werden. Als Folge entstanden Produkte für Enterprise Application Integration. Die Datenintegration selbst ist gelungen. Doch am Problem der übergreifenden Prozesse arbeiten die Hersteller noch heute. Der Weg führt über eine Kommunikationsschicht, die Datenredundanzen zwischen den Systemen aufspüren und eliminieren soll und gleichzeitig die Prozesslogik mittels Prozess-Engines stärker in den Mittelpunkt stellt. Am Start stehen Systeme wie SAP NetWeaver, Oracle Fusion oder Fujitsu Interstage.

Bei diesem Schritt setzen die Hersteller vor allem auf die Technik der Service-orientierten Architektur (SOA). Sie soll der Katalysator für die Entwicklung sein. Denn dieses Konzept ermöglicht eine flexible und damit schnelle Anpassung der Systeme und ihrer prozessbasierten Anbindung. Doch die rein technische Vereinfachung genügt noch nicht, um alle Probleme in den Griff zu bekommen.

Unternehmenssoftware soll deshalb künftig so genannte «Enterprise Services» zur Verfügung stellen. Hierbei handelt es sich um sinnvoll unterteilte Funktions- beziehungsweise Prozesseinheiten, die sich miteinander kombinieren lassen. Jedoch fehlt einer SOA die Logik, um die passenden Elemente zu einem Konstrukt zusammenzusetzen, das einen Geschäftsprozess sinnvoll unterstützt. Denn die technische Sicht erfasst die Anforderungen der Fachabteilungen nicht, welche die internen und Organisations-übergreifenden Abläufe prägen. Genau diese sind jedoch ausschlaggebend für die Zusammenstellung der Services.

Eine schnelle Implementation von Prozessen wird heute durch die nötigen umfangreichen Anpassungen am System verzögert. Die modellbasierte Konfiguration will diesen Vorgang dereinst ohne umfangreiche Entwicklungsprojekte ermöglichen. Per Knopfdruck, so die Vision, soll sich die Modellierung und Optimierung betriebswirtschaftlicher Prozesse in der Umsetzung auf der Softwareebene niederschlagen. Die Voraussetzungen hierfür schaffen spezialisierte Applikationen, die Unternehmensanwendungen über die Prozesslogik verknüpfen.

Doch bei diesem Zwischenschritt wird es nicht bleiben. Denn SOA öffnet auch neue Wege für die Anwendungsentwicklung. Die Hersteller werden dazu übergehen, eine Prozessschicht direkt in ihre Applikationen zu integrieren. Sie steuert die Architektur der ERP-Bausteine. Ansatzpunkt sind die fachlichen Geschäftsprozesse, also die betriebswirtschaftlichen Anforderungen eines Vertriebs, einer Produktion oder einer Lagerhaltung. Der Kunde erhält künftig kein CRM-, SCM- oder ERP-System mehr, sondern eine Plattform mit vordefinierten Prozessen. Diese Plattformen werden so offen gestaltet sein, dass Partner oder Kunden die vorliegenden Bausteine mit geringem Aufwand verändern können.

Für den Anwender bedeutet das konkret, dass er aus einem Prozessbaukasten genau jenen Prozess auswählt, der zur Unterstützung seiner Geschäftsabläufe notwendig ist. Ein Unternehmen kauft damit keine vorgefertigten Systeme mehr, sondern Geschäftsprozesse inklusive der dafür nötigen technischen Software-Komponenten. Das Ergebnis wird kein geschlossenes, starres Anwendungssystem sein, sondern die betriebswirtschaftlich sinnvolle Zusammensetzung von Enterprise Services auf der Basis einer einheitlichen Technologieplattform.

Noch ist der Prozessbaukasten Zukunftsmusik. Bis dahin gilt es, die bestehenden Applikationen zu nutzen und die Unternehmensprozesse allmählich auf Basis der angebotenen Technologieplattformen weiterzuentwickeln. Letztlich wandeln sich die heutigen Unternehmensanwendungen im Rahmen dieser Evolution zu einem Betriebssystem für Geschäftsprozesse. Die ERP-Anbieter werden somit zu Prozess-Anbietern.

Ein Schritt in diese Richtung geht beispielsweise SAP mit dem Enterprise Service Repository und der Business Process Platform (BPP). Doch auch die anderen grossen Hersteller entwickeln gegenwärtig eigene Plattformen: Was man in Walldorf NetWeaver und BPP nennt, das heisst bei Oracle Fusion, bei Microsoft Dotnet und bei IBM Websphere.

Aber selbst wenn die Anbieter bei ihren Konzepten konsequent auf Standards setzen, entstehen zum Schluss doch wieder proprietäre Systeme. Die Kooperation untereinander erfolgt wie gewohnt über Schnittstellen, auch wenn diese nun der Einbindung von Services dienen. Da man Neuland betritt, entwickeln die Hersteller zusätzlich eigene Modellierungsmethoden zur Beschreibung der technischen Aspekte der eigenen Services. Der Standard BPEL (Business Process Execution Language) zur Montage von Services ist an dieser Stelle zwar eine gute erste Hilfe - aber alleine bei weitem nicht ausreichend.

Zudem vernachlässigen die technisch motivierten Entwicklungen die Bedürfnisse der Anwender. Diese wollen ihre Prozessstrategien unabhängig von der späteren Implementierung festlegen, gleichzeitig aber nachher die betriebswirtschaftlichen Modelle zur Montage und Konfiguration der SOA-Systeme nutzen können. Auf der technischen Ebene lässt sich eine völlige Offenheit von SOA wegen der herstellerbezogenen Entwicklungen und der fehlenden Standardisierung semantischer Inhalte der Services nicht erzielen. Deshalb muss die Umsetzung auf der betriebswirtschaftlichen SOA-Ebene über spezialisierte Applikationen erfolgen.

Aus diesen Gründen ist offenes SOA deshalb primär betriebswirtschaftlich offenes Geschäftsprozessmanagement (BPM). Es lässt freie Hand bei der Organisationsgestaltung und ist gleichzeitig mit der Implementierungsebene SOA über eine automatische Transformation auf Repository-Ebene verbunden. In der Konsequenz werden hierbei betriebswirtschaftliche und technische Schichten harmonisch miteinander verknüpft, da betriebswirtschaftliche als auch technische herstellerbezogene SOA-Modelle verwaltet werden. Diese Offenheit ist schlussendlich Garant dafür, dass Geschäftsprozesse tatsächlich an neue Anforderungen angepasst werden können. Zugleich schafft sie so den lang geforderten Brückenschlag in die technische Umsetzung. Denn mit einem solchen offenen BPM-Ansatz wächst SOA aus der technischen Umgebung heraus.