Bei der Erschließung neuer Märkte und der Entwicklung neuer Produkte sind die Prozesse im Unternehmen meist auf den Vertrieb von Produkten ausgerichtet. Das zeigt sich in den vorhandenen DV-Landschaften, in denen es für die einzelnen Produkte und Produktlinien verschiedene Systeme sowohl im Front- als auch im Backoffice-Bereich gibt. In diesen Systemen ist der Kunde den Produkten zugeordnet.

In den gesättigten Märkten, die heute in vielen Branchen vorzufinden sind, erhält die Dienstleistung am Kunden eine weit größere Rolle als das pure Verkaufen einer Ware. Die Kundenbindung ist an die Stelle der Kundengewinnung getreten. Die Zufriedenheit eines Kunden, das heißt seine effektive und effiziente Behandlung durch das Unternehmen, hat den optimalen Verkauf eines Produktes abgelöst. Diese neue Sicht muß sich nun auch in den DV-Systemen widerspiegeln: Es gilt, eine einheitliche Kundensicht zu schaffen, in der der Abnehmer das zentrale Objekt ist, an dem sich alles ausrichtet. Diese Aufgabe soll durch die Einführung von CRM-Systemen erleichtert werden.

Mit der Bedeutung von CRM wuchs auch die Anzahl der Produkte, die es dem Unternehmen gestatten, Kundenkontakte und -beziehungen zentral zu verwalten. Nun bieten CRM-Produkte wie "Siebel" und "Clarify" zwar die Möglichkeit, Kunden und Kundenkontakte zu verwalten, und sie unterstützen die geforderte Ausrichtung auf den Kunden, aber sie schaffen nicht die für die Integration benötigte Verbindung zwischen den einzelnen Anwendungen und Systemen im Unternehmen. Die eigentliche Schwierigkeit bei der Ausrichtung auf den Kunden liegt aber genau darin, die vorhandenen DV-Systeme und die enthaltenen Kundendaten so zu integrieren, daß wirklich eine zentrale Sicht mit für das ganze Unternehmen einheitlichen Kundenkontakt- und Geschäftsfalldaten geschaffen wird, damit das CRM-Tool nicht zu einer bloßen Kontakt- und Marketing-Database verkommt.

Zur Lösung dieser Aufgabe bedient man sich der Methoden der Enterprise Application Integration (EAI). Sie geben dem Unternehmen die nötigen Werkzeuge an die Hand, die den Austausch von Informationen zwischen verschiedenen Anwendungen und Geschäftsprozessen innerhalb und zwischen Firmen ermöglichen und steuern. Verteilte Applikationen und Datenquellen, die der Produktstruktur entsprechend vorhanden sind, werden so integriert, daß die neue Ausrichtung auf Prozesse, mit denen der Kunde bedient wird, möglich ist.

Diese Art der Integration bedeutet nicht, einzelne Komponenten zu integrieren oder den existierenden Teilintegrationen neue hinzuzufügen. Solche Teilintegrationen können den Aufbau einer ganzheitlichen Kundensicht eher behindern als fördern. EAI hat zum Ziel, eine einheitliche, integrierte Systemlandschaft zu schaffen. Es läßt sich am besten als ganzheitliches Konzept verstehen, das auf verschiedenen Integrationstechniken aufbaut, die aber für alle beteiligten Komponenten im Unternehmen durchgängig eingesetzt werden.

Die reale Welt ans CRM-Ideal heranführen

Was bedeutet das nun für die Einführung des Customer-Relationship-Managements? Zur Beantwortung dieser Frage muß man zunächst einen Blick auf die reale Ausgangslage werfen, in der sich die DV-Welt vieler Unternehmen vor der Einführung von CRM befindet. Die meisten Anwendungslandschaften bestehen aus historisch gewachsenen Applikationen, die in unterschiedlichen Sprachen geschrieben wurden. Es existieren Betriebssysteme aus verschiedenen Zeitaltern der Informationstechnologie und Datenbanken mit allen möglichen Formen der Datenhaltung, von sequentiell bis relational und multidimensional. Jedes dieser Systeme erfüllt im Unternehmen eine bestimmte Aufgabe, sei es im Verkaufsbereich, in der Verwaltung der Lagerbestände und Beziehungen zu einzelnen Lieferanten oder im Marketing-Sektor.

Dieses Nebeneinander von Anwendungen ist der Punkt, an dem man mit EAI ansetzt. Ermöglicht werden muß eine Kommunikation zwischen diesen Anwendungen auf technischer, logischer und funktionaler Ebene mit dem Ziel, die reale Welt langsam zum CRM-Ideal hinüberwachsen zu lassen.

Eine Integration vorhandener DV-Systeme kann auf Daten-, Service- und Anwendungs- sowie auf Prozeßebene erfolgen. Die Entscheidung hängt von der Zielarchitektur, aber vor allem von der vorhandenen Systemumgebung und Teilintegrationen ab. Ein wichtiges Kriterium ist zum Beispiel die Schichtung der Anwendungen. So lassen sich in einer Anwendungslandschaft mit objektorientierten Client-Server-Systemen andere Techniken einsetzen als in monolithischen Mainframe-Anwendungen, remote Systeme für den Außendienst sind anders zu integrieren als solche, die immer online sind.

Auf unterstem Level sind Integrationen auf Datenebene angesiedelt. Hier werden verschiedene Datenbanken miteinander synchronisiert, so daß die Anwendungen, die auf diesen Systemen aufsetzen, mit konsistenten Daten arbeiten können. Eine solche Lösung läßt sich mit relativ geringem Aufwand realisieren. Allerdings ist es dafür oft erforderlich, Geschäftslogik an mehr als einer Stelle zu implementieren. Für die Integration auf Datenebene eingesetzte Methoden sind zum Beispiel:

-Message Broker (asynchrones Verfahren); Datenänderungen werden allen anderen betroffenen Datenquellen mitgeteilt, so daß die Änderungen dort nachvollzogen werden. Datenquellen unterschiedlichen Typs (Dateien, DL/I, SQL) können über diese Verfahren integriert werden.

-Replikationsmechanismen: Mehrere SQL-Datenbanken gleichen die Daten transaktionsgesteuert untereinander ab.

-DRDA (Distributed Relational Database Architecture): Mehrere Datenbanken werden zu einer virtuellen Datenbank zusammengeschlossen.

Komfortabler ist die Integration der DV-Systeme auf Service- und Anwendungsebene. Sie erlaubt es, die in den verschiedenen Applikationen abgebildeten Teilprozesse entsprechend den neu definierten Prozessen zu verknüpfen. Die Regeln für die Verknüpfung werden in einem Repository (einer Metadatenbank, die Beschreibungen von Daten, Applikationen und Teilprozessen enthält und deren Verknüpfung zuläßt) abgelegt und sind dadurch flexibel. Die Integration auf Anwendungsebene zieht Eingriffe in den bestehenden Applikationen nach sich, wenn diese nicht ohnehin objektorientiert mit standardisierten Schnittstellen realisiert wurden. Hierzu werden auch Application Server herangezogen, die die verschiedenen Anwendungen verwalten und den Informationsfluß zwischen ihnen steuern.

Ein Zusammenschluß der Komponenten auf Service- und Applikationsebene führt zu einem hohen Integrationsgrad und zu einer größeren Effizienz für den Bearbeiter. Diese Integration bietet sich in Architekturen an, die auf objektorientierten Techniken aufsetzen. Besonders im Bereich der Integration auf Anwendungsebene sind in der letzten Zeit neue Produkte auf den Markt gekommen, die diese Integration erst ermöglichen und vor allem erleichtern. Zu diesen Methoden zählen

-Message Broker: Sie lassen sich auch für die Applikationsintegration einsetzen. Darüber werden dann keine Daten zwischen verschiedenen Datenbanken, sondern Nachrichten zwischen verschiedenen Anwendungen ausgetauscht und abgeglichen.

-Application Server: Er enthält Objekte, die bei Bedarf von verschiedenen Applikationen angefordert und ausgeführt werden können. Altanwendungen lassen sich über Wrapping-Techniken ebenfalls in Objekte verpacken und einsetzen.

-Object Request Broker: Er integriert Applikationsteile, die mit den unterschiedlichen Techniken implementiert wurden. Der Corba-Standard (Common Object Request Broker Architecture) legt dabei fest, welche Schnittstellen die Anwendungsteile (Objekte) haben müssen, um sich innerhalb eines ORB einsetzen zu lassen.

Besondere Bedeutung kommt in vielen Unternehmen der Integration von Clients zu, die für Backoffice und Außendienst gleichermaßen zur Verfügung stehen müssen. Auch für die Integration gibt es neben Corba ebenfalls verschiedene Techniken:

-Transaction Server: Ein Terminal-Server, auf dem die eigentliche Anwendung läuft, "verpackt" nur die Anzeige und schickt sie über das Netz an einen entfernten Client, der dann die Tastatur- und Mauseingaben des Anwenders erfaßt und wieder zurückschickt.

-Wrapping: Verschiedene Tools unterstützen die automatische Übersetzung von Anwendungsoberflächen in HTML/XML und CGI (Common Gateway Interface). Auf diese Art und Weise können die Oberflächen automatisiert WEB-fähig gemacht und auf einem Browser angezeigt werden.

Die aus fachlicher Sicht umfassendste Eingliederung versprechen Tools, die es erlauben, die Integration der DV-Landschaften auf der Ebene der Geschäftsprozesse zu verwirklichen. Änderungen in den fachlichen Abläufen ziehen Anpassungen in der DV-Landschaft nach sich. Dazu ist es notwendig, den definierten Teilprozessen Anwendungen zuzuordnen, die dann entsprechend den Business Rules miteinander verknüpft werden. Die Integration auf Prozeßebene bietet daher die größte Flexibilität, stellt aber auch die höchsten Ansprüche an Modularität und Konsistenz der beteiligten Anwendungen.

Mit der wachsenden Bedeutung von CRM entwickelt sich EAI zu einem wichtigen Instrument zur Umsetzung entsprechender Strategien. Folglich ist die Zahl der Anbieter, die sich auf dem Markt der EAI-Tools plazieren, in letzter Zeit gewachsen. Aus dieser Fülle von Anbietern werden sich in den nächsten Jahren einige hervortun, deren Konzepte am Markt Bestand haben. Zu diesen Konzepten werden bewährte Ansätze wie zum Beispiel das Messaging, aber vor allem auch neue Ansätze wie XML gehören.

Customer-Realationship-Management/Adressen

Für weiterführende Informationen zu den diversen Integrationsprodukten sind folgende Internet-Seiten hilfreich.

Active Software: http://www.activesw.com

BEA: http://www.beasys.com

Candle: http://www.candle.com

Crossworlds: http://www.crossworlds.com

Forté: http://www.forte.com

IBM: http://www.ibm.com

Iona: http://www.iona-iportal.com

Micorosoft: http://www.microsoft.com

Oberon: http://www.oberon.com

Systar: http://www.systar.com

Template: http://www.template.com

Tibco: http://www.tibco.com

Integrationsprodukte

Zur Datenintegration lassen sich Message Handler wie zum Beispiel "MQ Series" von IBM oder "MSMQ" von Microsoft einsetzen.

Für die Integration auf Service-Ebene sind auch Standards wie Corba oder DCOM (Distributed Common Object Model) einsetzbar. Hersteller von Object Request Brokern sind zum Beispiel BEA (Tuxedo) und IONA (Orbix) via Message Broker (auch Corba). Umfangreichere Tools zur Integration auf Anwendungsebene sind zum Beispiel "Active Works" von Active Software, "Prospero" von Oberon. Tools zur Integration auf Prozeßebene sind "Business Bridge" von Systar oder die "Integration Applications" von Crossworlds.

In einer heterogenen Systemumgebung wird es nötig sein, verschiedene der hier gezeigten Integrationsmechanismen zu kombinieren. Ein EAI-Tool ist daher um so besser, je vielfältiger seine Integrationsmöglichkeiten sind. Beispiele sind die Integrationssuiten "Roma" von Candle oder "TIB/Active Enterprise" von Tibco, die Produkte zur Integration des Datenaustauschs über Messaging, zur Datentransformation, Prozeßmodellierung und zum System-Management enthalten (siehe Kasten Adressen).

Geschäftsprozesse

Bei der Trennung von Front- und Backoffice werden Geschäftsprozesse, die aus Kundensicht nur einen Wunsch erfüllen, in mehrere Teilprozesse zerlegt. Ein Beispiel dafür ist der Abschluß einer Versicherung über ein Call-Center. Während das Angebot im Frontoffice sehr schnell erstellt und verschickt wird, muß der Kunde auf die Policierung warten, weil diese im Backoffice auf einem System stattfindet, das vom Frontoffice im Call-Center getrennt arbeitet und von anderen Sachbearbeitern bedient wird. Der Prozeß "Angebot erstellen" ist von den Prozessen "Policieren" und "Vertrag verwalten" getrennt. Dadurch müssen dann unter Umständen Informationen doppelt erfaßt und bearbeitet werden.

Bei einer Integration sind die Prozesse zur Angebotserstellung und Policierung Teilprozesse eines übergreifenden Prozesses "Vertragsabschluß". EAI gestattet die technische Integration der betroffenen Systeme, so daß der Agent im Call-Center die Policierung auch von dort anstoßen kann, wenn der Kunde den Vertrag akzeptiert. Umgekehrt hat auch ein Mitarbeiter im Schadenservice immer einen aktuellen Überblick darüber, welche Verträge der Kunde hat, wie sein Zahlungsverhalten ist etc.

*Dr. Holger Rommel arbeitet als Consultant bei der Tieto Enator Consulting in Frankfurt am Main.