Die Service-orientierte Architektur bringt neue Anforderungen und Gestaltungsoptionen für CRM-Projekte mit sich. Sie erstrecken sich über die Dimensionen Strategie, Prozess und System. Im Prozess- und Systemzusammenhang erfordert die Implementierung zwei neue Aktivitäten: zum einen das Identifizieren und Definieren fachlicher Services sowie deren Beschaffung. Zum anderen den Aufbau einer Integrationsplattform, das heißt eines Enterprise-Service-Bus.

Erstere Aufgabe muss sowohl im Top-down- als auch im Bottom-up-Verfahren angegangen werden: Während das Identifizieren fachlicher Services Top-down erfolgt, wird deren Design in einem Bottom-up-Ansatz definiert. Auf den Aufbau einer Integrationsplattform soll hier nicht weiter eingegangen werden, da er nicht ausschließlich zu den CRM-Projektaufgaben zählt. Dessen ungeachtet muss sich ein CRM-Projekt aber an der Verfügbarkeit der Integrationsplattform orientieren und gegebenenfalls auf die Architekturanforderungen einwirken.

Woher kommen die Services?

Grundsätzlich lassen sich zwei Methoden unterscheiden, um CRM-Enterprise-Services (CRM-Teilprozesse wie etwa Lead-Generierung) und CRM-Services (zum Beispiel eine Preisanfrage) anhand fachlicher Anforderungen zu definieren: eine funktionale und eine prozessorientierte. Die funktionale Betrachtungsweise identifiziert und definiert Services anhand eines unternehmensspezifischen CRM-Funktions-Frameworks. Diese Vorgehensweise wird oft im Rahmen einer traditionellen Softwareeinführung und -auswahl genutzt. Dabei liegt der Schwerpunkt auf einem reinen Funktionsvergleich zwischen einzelnen CRM-Systemen in den Kategorien Marketing, Vertrieb, Service und analytisches CRM. Diese Sicht behindert allerdings die Orientierung an den auf die Kundenanforderungen ausgerichteten CRM-Prozessen. Außerdem führt sie selten zu einer nachhaltigen Kundenerfahrung und zur Differenzierung vom Wettbewerb. Es empfiehlt sich daher, die Definition der CRM-Services und die Auswahl der Software ausschließlich daran zu orientieren, inwieweit die individuellen Prozesse unterstützt werden.

Vor diesem Hintergrund sollte die Identifikation von CRM-Enterprise-Services und CRM-Services ausschließlich auf Basis einer Service-orientierten Geschäftsprozessmodellierung erfolgen. Für die Modellierung hat sich der Top-down-Ansatz bewährt. Die CRM-relevanten Sollprozesse werden auf Basis eines Prozess-Frameworks dargestellt (siehe Grafik), einer Art integrierter Prozesslandkarte über alle relevanten Haupt- und Teilprozesse. Die aufzunehmenden Hauptprozesse (zum Beispiel Lead-Management) repräsentieren dabei alle Unternehmensprozesse, die über eingebettete CRM-Teilprozesse verfügen.

Nach der Kennzeichnung der relevanten Teilprozesse werden Haupt- und Teilprozesse so gegliedert, dass die entsprechenden Enterprise-Services auf direktem Wege abgeleitet werden können. Im hier vorgestellten Ausschnitt eines Prozess-Frameworks entspricht ein CRM-Teilprozess im Wesentlichen einem (CRM-)Enterprise-Service.

Die Detaillierung eines Teilprozesses durch die Modellierung seiner Aktivitäten bildet dann die Voraussetzung für das Design der zu orchestrierenden CRM-Services. Die Tabelle "Prozess- und Serviceebenen" fasst die korrespondierenden Hierarchieebenen in der Prozess- und der Serviceperspektive nochmals zusammen.

Definition von CRM-Services

Parallel zur fachlichen Prozesshierarchie muss die Servicehierarchie im Bottom-up-Verfahren aufgebaut werden: CRM-Ser- vices werden gemäß der modellierten Aktivitäten innerhalb eines Teilprozesses zu einem CRM-Enterprise-Service gruppiert, der wiederum einem Enterprise-Service-Cluster zu- geordnet und entsprechend orchestriert wird. Spätestens jetzt wird deutlich, ob die Teilprozesse und die Prozessaktivitäten in einer geeigneten Struktur definiert wurden. Denn die Definition der Teilprozesse bestimmt direkt die Granularität und Fachlichkeit der CRM- Enterprise-Services. Ebenso bestimmt die Struktur der Prozessaktivitäten direkt die Granularität der zu orchestrierenden CRM-Services.

Müssen gemäß fachlicher Prozesshierarchie zu grobgranulare (Enterprise-)Services entworfen werden, können die Prozesse zwar mit wenigen Services abgebildet werden, allerdings sind diese komplex und verursachen bei der Implementierung und Wartung einen vergleichsweise hohen Aufwand. Außerdem ist ihre Wiederverwendbarkeit aufgrund ihrer spezifischen Funktionalität sehr begrenzt. Werden die (Enterprise-)Services dagegen zu feingranular definiert, benötigt man sehr viele davon, um die Prozesse abzubilden. Der fachliche Kontext eines (Enterprise-)Service ist gering; im Extremfall handelt es sich ausschließlich um einen technischen Service ohne fachlichen Bezug. Die semantische Lücke zwischen Service und Anforderung ist dementsprechend groß. Ebenso gestalten sich Mana- gement und Wartung zu vieler Services schwierig und ziehen entsprechend hohe finanzielle Aufwendungen nach sich. Es wird schwer, den Überblick zu behalten.

Aus diesem Grund ist es wichtig, dass CRM-Services und CRM-Enterprise-Services in der richtigen Granularität definiert werden. Es gibt sieben Prinzipien, die bei der Definition von CRM-Services und -Enterprise-Services beachtet werden sollten, um die optimale Granularität und fachliche Struktur sicherzustellen (siehe Kasten "Prinzipien für die Definition von Services").

Auswahl von CRM-Services

Sind die Services identifiziert und definiert, kann man sich Gedanken über die Beschaffung machen. Dabei können unternehmensinterne oder externe Beschaffungsquellen berücksichtigt werden. Bei der ersten Option dienen bestehende Unternehmensapplikationen - Standardanwendungen und Individualentwicklungen - als Lieferanten für Services. Allerdings sind die notwendigen Modifikationen häufig nur mit größeren Anstrengungen realisierbar. Darüber hinaus könnten vorhandene Fremdsoftwaresysteme Schwierigkeiten verursachen, wenn nur der Softwareanbieter selbst die Modifikationen umsetzen kann, aber wenig Bereitschaft dazu zeigt.

Alternativ lassen sich Best-Practise-CRM-Softwarekomponenten zukaufen. Eines der größten Potenziale von SOA-basierender Systemunterstützung resultiert aus der Möglichkeit, die erforderlichen Funktionen zur Unterstützung der Unternehmensprozesse auf diese Weise aufzubauen. Es gibt verschiedene Bezugsmodelle wie klassische Lizenzen, Application Service Providing oder On Demand Computing. Obwohl in den letzten Jahren die meisten CRM-Standardsoftwareanbieter begonnen haben, technische Services als Erweiterung ihrer Applikationen zu entwickeln, waren die meisten Plattformen nicht Service-orientiert im originären Sinne. Das hat sich allerdings in letzter Zeit geändert. Insbesondere SAP und Oracle, aber auch Chordiant, Amdocs und Pegasystems sind bei der Umsetzung von SOA-Prinzipien in ihren Applikationen weit fortgeschritten.

Derzeit stehen der herstellerübergreifenden Beschaffung von CRM-Services aber immer noch größere Hindernisse im Weg, beispielsweise die Tatsache, dass CRM-Services etablierter CRM-Softwarehersteller noch kaum verfügbar sind. Hinzu kommt die unzureichende Transparenz bezüglich der fachlichen Abdeckung der Services: viele der bisher angebotenen Beschreibungen sind vornehmlich technischer Natur. Nicht zuletzt gibt es Probleme hinsichtlich der Interoperabilität von CRM-Services unterschiedlicher Hersteller.

Vergleicht man vor diesem Hintergrund Standardsoftwaresysteme mit der Beschaffung einzelner Komponenten, müssen vier SOA-spezifische Eignungsfaktoren berücksichtigt werden. Diese Faktoren ergänzen die klassischen Bewertungsfaktoren von Software bezüglich Kosten (Total Cost of Ownership = TCO), Anbieter und Technologie (siehe Grafik "Eignungsfaktoren von CRM-Services").

Die Bewertung der nachfolgend beschriebenen Faktoren Prozess-, Granularitäts-, Technologie- und Roadmap-Eignung erleichtert die Beantwortung der Frage, welche CRM-Standardsysteme und welche Fremdservices optimal zur Service-orientierten Unternehmensarchitektur beitragen können:

1. Prozesseignung (Process Fit)

Prozessinnovationen und die im Unternehmen einzigartigen CRM-Teilprozesse sind der Schlüssel, um sich gegenüber dem Kunden vom Wettbewerb zu differenzieren. Daher muss die zentrale Frage lauten, inwieweit die verfügbaren CRM-Bausteine eines Herstellers die spezifischen Teilprozesse eines Unternehmens abbilden können. Zum Beispiel: Welcher Anbieter ist in der Lage, CRM-Komponenten zu liefern, die einen individuellen Loyalitäts-Management-Prozess bestmöglich abbilden?

2. Granularitätseignung (Granularity Fit)

Die angebotenen CRM-Elemente können einen unterschiedlichen Grad an Funktionen und Prozesslogik aufweisen. CRM-Bausteine können technische Services, CRM-Services oder sogar Enterprise-Services repräsentieren. Die Frage lautet, ob die erforderliche Granularität der Services geliefert werden kann. Denn je höher ein Baustein auf einer Service-Hierarchieebene einzuordnen ist (vergleiche Tabelle), desto ausgeprägter ist auch seine herstellerseitig implementierte Prozess- logik. Besonders bei innovativen Prozessen mit einem hohen Alleinstellungsgrad sollten tendenziell eher (kleinere) CRM-Services statt CRM-Enterprise Services gewählt wählen.

3. Technikeignung (Technology Fit)

Da der Grad der Ausrichtung an Technikstandards maßgeblich die Interoperabilität einzelner CRM-Services bestimmt, muss dieses Kriterium bewertet werden. Je enger sich ein Produkt an etablierten Softwarestandards orientiert - zum Beispiel einer Service-Beschreibungssprache oder der Kompatibilität zu Integrationsplattformen - desto mehr steigt die Möglichkeit, Services von verschiedenen Herstellern einzukaufen und damit auch das Potenzial, agile Prozesse aufzusetzen und permanent zu verbessern. Ziel ist es, die Abhängigkeit von einem speziellen Softwareanbieter (Lock-in) zu reduzieren.

4. Roadmap-Eignung (Roadmap Fit)

Der vergleichsweise junge SOA-Ansatz und die Defizite hinsichtlich des Angebots an CRM-Services erfordern eine stärkere Konzentration auf Vision, Strategie und auf das zukünftige Angebot an CRM-Bausteinen eines Softwareanbieters. Die SOA-Roadmap eines Anbieters sollte deshalb beim Einschätzen der Eignung von CRM-Services unbedingt einbezogen werden. Im Vergleich mit der eigenen SOA-Roadmap wird deutlich, inwieweit die zukünftige SOA-Ausrichtung des Herstellers damit kompatibel ist. (wh)