Das Wachstum eines Unternehmens hängt entscheidend von seiner Fähigkeit ab, rasch auf veränderte Kundenbedürfnisse zu reagieren. Dazu sind effiziente, auf den Kunden ausgerichtete Geschäftsprozesse notwendig. Für CRM-Systeme bedeutet das zweierlei: Sie müssen stärker in die Unternehmensprozesse eingebettet werden und sich schneller an neue Anforderungen anpassen lassen.

Paradigmenwechsel

Weder traditionelle CRM-Standardsoftware noch klassische Eigenentwicklungen offerieren in dieser Hinsicht zukunftsfähige Lösungen. Fortschritte im Bereich der Service-orientierten Architektur (SOA) eröffnen die Möglichkeit, einen Paradigmenwechsel für die Definition eines CRM-Systems herbeizuführen. Dieser Artikel beleuchtet die neue Struktur SOA-basierender CRM-Systeme. In einem zweiten Beitrag in der nächsten Ausgabe der computerwoche werden die nötigen Aktivitätsschwerpunkte vorgestellt, die in CRM-Projekten nötig sind, um die Potenziale einer SOA umzusetzen.

Defizite klassischer Software

Systeme zur Unterstützung von CRM-Prozessen stammen entweder aus dem Bereich der Standardsoftware oder aus individuellen Entwicklungen. Die Grenzen zwischen diesen Welten sind bisher noch klar umrissen. Unterteilt man den Markt für CRM-Standardsoftware - so genannte Packaged CRM-Systeme - grob in drei Kategorien, so kann man unterscheiden zwischen integrierten Globallösungen (Enterprise-Suiten), autonomen CRM-Systemen (CRM-Suiten) sowie funktionalen CRM-Teillösungen (Best-of-Breed-Lösungen). Typische Anbieter solcher Standardsoftware sind SAP, Oracle/Siebel, Epiphany, SAS und SPSS. Die Lösungen sind dadurch gekennzeichnet, dass sie ein vordefiniertes und integriertes Bündel an CRM-Funktionen bereitstellen und dass sie innerhalb eines gesteckten Rahmens anpassbar und parametrisierbar sind.

Auf der Basis dieser Systeme können laut Angaben der Softwareanbieter alle CRM-Prozesse eines Unternehmens abgebildet werden. Aber was bedeutet das? Stellen diese Systeme tatsächlich alle notwendigen CRM-Funktionen bereit? Die Antwort lautet: Nicht im notwendigen Umfang! Denn allzu oft werden nur Teile von Prozessen abgebildet.

Viele CRM-relevante Aktivitäten sind bereits in anderen Systemen abgebildet oder müssen erst noch abgebildet werden. Ein Grund dafür ist zum Beispiel, dass die nötigen Funktionen nicht im erforderlichen Maß zum Leistungsumfang des CRM-Systems gehören oder dass Funktionen anderer Systeme nicht in das System integriert werden können. Dadurch laufen die CRM-Prozesse über mehrere Applikationen hinweg. Ein klassisches Beispiel ist die Preisermittlung als Teil des Angebotsprozesses. Aufgrund der hohen Komplexität lässt sie sich oft nur über das ERP-System bereitstellen. Auch bei der Berechnung der Verfügbarkeit von Produkten müssen Anwender oft auf spezialisierte Systeme aus dem Bereich Supply-Chain-Management zurückgreifen. Selbst die am Markt verfügbaren integrierten Globallösungen können das Problem nicht beseitigen: Im Vergleich zu CRM-Suiten und Best-of-Breed-Lösungen decken sie in der Regel nur einen Teil der geforderten Funktionen ab und machen daher ebenso den Einsatz weiterer Applikationen erforderlich.

Überdies sind viele CRM-Systeme, trotz aller Integrationsbemühungen, immer noch Applikationsinseln. Systemintegrationen beziehen sich meist nur auf die Datenebene. Prozessintegrationen beruhen - sofern sie überhaupt umgesetzt werden - auf Punkt-zu-Punkt-Verbindungen zwischen einzelnen Applikationen.

Monolithische Altsysteme

Erschwerend kommt hinzu, dass zwar viele CRM-Standardsoftwaresysteme bis zu einem gewissen Grad modular aufgebaut, als Ganzes gesehen aber noch immer monolithisch strukturiert sind. Einzelne Funktionsbausteine lassen sich oft nur schwer aus den Applikationen herauslösen und in die eigene Systemlandschaft integrieren. Ebenso stößt bei vielen Standardsoftwaresystemen die Prozess- und Workflow-Unterstützung an Applikationsgrenzen. Das alles hat zur Folge, dass eine applikationsübergreifende Prozessautomatisierung nur eingeschränkt realisierbar ist. Die in den Unternehmensprozessen eingebetteten CRM-Prozesse erfahren keine durchgängige Systemunterstützung.

Eigenentwickelte CRM-Systeme versprechen in diesem Kontext keine signifikanten Vorteile. Zwar können die benötigten Funktionen maßgeschneidert entwickelt und integriert werden. Allerdings stehen diesem Vorteil in der Regel hohe Implementierungs-, Betriebs- und Wartungskosten entgegen, darüber hinaus längere Entwicklungszeiten (Time to Market) und oft auch ein Mangel an Wissen und Erfahrung im Bereich CRM.

Composite Applications kommen

So genannte Composite-CRM-Applikationen besitzen das Potenzial, die Vorzüge von Standardsoftware mit denen von Individualentwicklungen zu vereinen. Auf Basis der vorhandenen Applikationsinfrastruktur, ergänzt durch Best-Practise-Softwarekomponenten, können Unternehmen Composite-Anwendungen implementieren, die die erforderlichen CRM-Funktionen zur Unterstützung der Unternehmensprozesse liefern. Business-Process-Plattformen, so genannte Integrationsplattformen, stellen dabei die applikationsübergreifende Unterstützung der Prozesse sicher (siehe Grafik "Prozesse unterstützen").

Damit CRM-Standardanwendungen als Quellsysteme für die benötigten Elemente zukünftiger Composite-Applikationen fungieren können, müssen die Funktionen der Softwareanbieter als Services angeboten werden. Diese Tendenz zeichnet sich bereits auf dem Markt ab. So arbeiten zum Beispiel Oracle und SAP mit Nachdruck an Softwarearchitekturen, um CRM-Funktionen als Business-Services zur Verfügung zu stellen.

Siebel positionierte das Produkt "Siebel Component Assembly" (SCA), das jedoch nach der Übernahme durch Oracle nicht weiterentwickelt wurde. Allerdings ist geplant, die SCA-Designkonzepte der Siebel-Business-Services in die Entwicklung von Oracles Fusion-Applikationen einfließen zu lassen und damit den größten Teil der CRM-Funktionen einer neuen Generation SOA-basierender Unternehmenssoftware abzu- decken. Ebenso plant SAP mit der auf der Enterprise Services Architecture (ESA) basierenden Mysap Business Suite, CRM-Funktionen als Business Services anzubieten. Zusätzlich offerieren beide Softwareanbieter als Kern ihrer neuen Technologie die Integrationsplattformen zur applikationsübergreifenden Prozessunterstützung.

Prozesse im Mittelpunkt

Zukünftig können somit die von Softwareanbietern stammenden CRM-Services als elementare Bausteine zukünftiger Composite-CRM-Applikationen ein- gesetzt werden. Eine einzelne Applikation wird nicht mehr zwangsläufig als dominierende Plattform fungieren, sondern als funktionaler Baustein, der neben anderen Softwarebausteinen existiert. Unternehmen können auf diese Weise künftig leichter Funktionen zukaufen und parallel dazu ihre Eigenentwicklungen vorantreiben. Die heute noch vorherrschende Applikationszentrierung kann durch eine echte Prozesszentrierung abgelöst werden.

Enterprise Services

Im Gegensatz zu den bereits beschriebenen traditionellen Prinzipien, bei der fachliche CRM-Anforderungen und Teilprozesse über jeweils spezifische Applikationen abgebildet wurden, besteht das zentrale SOA-Prinzip in der Trennung von Unternehmensprozessen und Applikationen durch die Definition lose gekoppelter Services.

Je nach Abstraktionsniveau von CRM-Services beziehungsweise je nach Umfang der implementierten Funktionen sollten zwei Typen unterschieden werden: CRM-Services und CRM-Enterprise-Services. Letztere sind Service-Cluster beziehungsweise Service-Domänen, die durch eine Aneinanderreihung von Aufrufen einzelner CRM-Services modelliert werden können. CRM-Enterprise-Services sind aufgrund ihres höheren semantischen Niveaus im Vergleich zu einfacheren Services aus fachlicher Sicht besser interpretierbar und aus IT-Sicht effizienter zu verwalten. CRM-Enterprise-Services können selbst wiederum als Services von anderen höhergestellten Services genutzt werden.

Beim Entwurf von CRM-Enterprise-Services stehen ihre fachliche Bedeutung und die Einbettung in die Unternehmensprozesse im Vordergrund. CRM-Enterprise-Services liefern die erforderlichen Funktionen zur Unterstützung der Unternehmensprozesse. Die auf der Ebene darunter liegenden CRM-Services werden unter Verwendung mehrerer technischer Services (Web-Services) zum Beispiel auf der Basis vorhandener Systeme realisiert. Dabei kann es sich um CRM-Standardsoftware, ERP- oder BI-Systeme handeln.

Die Auswahl von Services und deren logischer Zusammenhang bezüglich Aufrufreihenfolge und Abhängigkeit zur Bildung von CRM-Enterprise-Services wird Orchestrierung genannt. Die Grafik "Orchestrierung in der SOA" zeigt beispielhaft die Implementierung des Teilprozesses "Cross-Selling durchführen". Die dafür orchestrierten CRM-Services "Kundenprofil analysieren", "Präferenzen analysieren", "Angebote priorisieren" sowie "Angebot kommunizieren" wurden ihrerseits auf der Basis von technischen (Web-)Services zur Verfügung gestellt. Sie stammen aus CRM-relevanten Applikationsfunktionen. Auf beiden Orchestrierungs-Ebenen nimmt die Integrationsplattform eine zentrale Koordinations- und Steuerungsfunktion ein.

Begreift man folglich ein SOA-basierendes CRM-System als Ansammlung applikationsübergreifender Services und Enterprise-Services, reformiert SOA zwangsläufig die klassische Definition eines CRM-Systems. Das monolithische System löst sich faktisch auf und wird Bestandteil einer unternehmensweiten oder sogar unternehmensübergreifenden Composite-Applikation.

Knackpunkt Interoperabilität

Voraussetzung dafür ist, dass die Probleme hinsichtlich der Interoperabilität von CRM-Services unterschiedlicher Anbieter beseitigt werden. Darüber hinaus müssen sich die einzelnen Bausteine kohärent verwalten und weiterentwickeln lassen und ihre Budgetierung, der Support und die Softwareentwicklung geklärt werden. Dazu gehören Fragen wie zum Beispiel: Welche SOA-CRM-Bausteine werden welchem Budget zugeordnet?

Eine lose Ansammlung von CRM-Bausteinen ohne klare Abgrenzungen zu anderen Subsystemen beziehungsweise anderen Bausteinen wäre problematisch. Aus diesem Grund sollten solche CRM-Bausteine zum Beispiel nach funktionalen, organisatorischen oder auch nach prozesstechnischen Prinzipien neu gruppiert werden. Solche Bausteingruppen könnten künftig als SOA-basierende CRM-Systeme betrachtet werden. (wh)