Wie Daimler den PKW-Vertrieb beschleunigt

Vor elf Jahren nannte es noch keiner SOA. Doch ein gemischtes Team aus Mitarbeitern von Daimler und der ehemaligen sd&m AG (heute: Capgemini sd&m) stand 1997 bei der damaligen Daimler-Benz AG vor der Frage, wie der Prozess von der Bestellung bis zur Fahrzeugübergabe mit Einführung der A-Klasse stringenter organisiert werden könnte. Der schwäbische Autobauer wollte seinen Kunden eine sofortige, verbindliche Lieferterminzusage direkt bei der Automobilbestellung geben und zusätzlich die Lieferzeit von 30 auf 15 Tage verkürzen - verfügbare Kapazitäten vorausgesetzt. Ein IT-System sollte all diese Wünsche erfüllen, den Prozess transparent machen und so gestalten, dass er zu einem späteren Zeitpunkt auf alle Baureihen von Daimler übertragen werden konnte. Das Projektmanagement von Daimler gab den Software-Architekten des Projekts mit auf den Weg, unternehmensweit zu denken - ganz im Sinne des damaligen Ansatzes der so genannten Integrated Sales- und Production Database.

Und so begann das Team Schritt für Schritt, die bestehende Anwendungslandschaft bei der damaligen Daimler-Benz AG umzugestalten. Eine zentrale Rolle spielte dabei das Verstehen der Fachlichkeit entlang der Kernprozesse - und zwar über alle Abteilungsgrenzen hinweg. Bei der Entwicklung und Umstrukturierung der IT-Landschaft unter dem Namen "Global Ordering" setzte das Team auf erprobte Gestaltungsansätze, die heute als die zentralen Bausteine von Service-orientierten Architekturen (SOA) gelten:

• Definition von Komponenten, die unternehmensweit eindeutig für bestimmte Geschäftsobjekte zuständig sind und Services zu diesen Geschäftsobjekten anbieten;

• Lose Kopplung der bestehenden Anwendungen mit den neu entwickelten Services, um schrittweise neue Funktionen zu entwickeln und gleichzeitig den unternehmensweiten Ansatz zu wahren;

• Entwicklung von Schnittstellen, die geschäftsbezogen, grobgranular und kontextfrei sind.

In einem ersten Schritt führte Daimler damals die Buchung eines Produktionsplatzes einschließlich der Lieferterminzusage für ihre A-Klasse-Kunden ein. So konnten die Prozesse ohne übermäßigen Aufwand deutlich verbessert werden, denn: Die Orderingsysteme der einzelnen Märkte und der Stuttgarter Zentrale wurden hierfür nur geringfügig angepasst. Das Produktionsplanungssystem lieferte Volumenzahlen, die bei der Buchung eines Produktionsplatzes und damit eines Produktionstermins berücksichtigt wurden. Schon hier zeigt sich, dass der Charme von SOA für viele IT-Verantwortliche darin besteht, alte Systeme beibehalten und Stück für Stück ausbauen oder verändern zu können (siehe auch: In zehn Schritten zur SOA).

Feste Lieferterminzusage trotz loser Kopplung

Um die Lieferzeit der Daimler-Fahrzeuge zu verkürzen, musste die nächtliche Batchabwicklung durch lose gekoppelte Online-Systeme ersetzt werden. Das führte dazu, dass alle Werke Auftragsänderungen ab diesem Zeitpunkt zeitnah online erhielten und nicht mehr nur einmal pro Nacht. Gleiches galt für die Status- und Terminrückmeldungen der Werke an den Vertrieb. Einer festen Lieferterminzusage gegenüber dem Käufer standen dabei zwei Hindernisse im Weg:

1. Technisch existiert zwischen lose gekoppelten Systemen keine Transaktionssicherheit. Das heißt: Fehlgeschlagene Prüfungen im zweiten System können nicht mehr zur Ablehnung im ersten System führen, da dort die Transaktion schon erfolgreich beendet wurde.

2. Fachlich kann eine optimale Produktionsreihenfolge für einen Tag und somit ein verbindlicher Liefertermin erst ermittelt werden, wenn schon genügend Aufträge für die Folgetage vorliegen. Typische Fragestellungen bei der Optimierung sind: Wie erreiche ich möglichst wenig Farbwechsel in der Lackierung oder wie mische ich komplexe und weniger komplexe Fahrzeuge, damit der Bandtakt konstant gehalten werden kann?

Aus SOA-Sicht ist die passende Antwort für das technische Problem: Entwickelt kompensierende Services. Doch eine Kompensation hätte im Falle Daimler eine Stornierung des kompletten Auftrags bedeutet und damit zu einer Lieferterminverschiebung für den Kunden geführt. Mit dem Käufer hätte ein neuer Liefertermin vereinbart werden müssen, der sich dann unter Umständen erneut verschoben hätte. Das Projektteam löste sowohl das technische als auch das fachliche Problem mit einer geschickten vertraglichen Lösung. Produktion und Vertrieb verpflichteten sich wie folgt zu verfahren: Die Produktion teilt der Ordering-Komponente freie Tagesproduktionsplätze zu, in die der Vertrieb die Aufträge bucht. Der Autokäufer erhält zugleich statt eines festen Liefertermins eine Lieferterminspanne zugesagt. Diese gilt bei der Produktionseinplanung als fest einzuhalten, wobei die Terminspanne fünf bis zehn Arbeitstage beträgt und sich von Werk zu Werk unterscheidet. Sie ist abhängig von der Komplexität des Produkts und der jeweiligen Produktionsflexibilität am Standort. Und der Spielraum von fünf bis zehn Arbeitstagen reicht in der Produktion aus, um eine optimale Produktionsreihenfolge zu bilden.

Mit dieser Lösung hält Daimler Liefertermine mit Ausnahme von Streiks oder kurzfristigen Lieferantenengpässen konstant ein. Diese Tatsache beeindruckt umso mehr, als pro Fahrzeug zur Abstimmung durchschnittlich 35 Telegramme von der Produktion an den Vertrieb und sieben vom Vertrieb an die Produktion zurück geschickt werden. Insgesamt erhalten die Werke von Daimler circa 40.000 Telegramme täglich mit Auftragsänderungen oder zusätzlichen Kundenwünschen, während die Werke an den Vertrieb etwa 200.000 Telegramme pro Tag verschicken. Dabei handelt es sich im Wesentlichen um aktualisierte Einplanungstermine, die dem Vertrieb eine genauere Bestimmung des endgültigen Liefertermins erlauben - innerhalb der vereinbarten Lieferterminspanne.

Schnittstellen wie aus dem SOA-Lehrbuch

Im Zusammenspiel zwischen der Zentrale und den einzelnen Marktgesellschaften verbarg sich eine weitere Herausforderung. Als global agierendes Unternehmen kann Daimler nicht alle Services für die Marktgesellschaften mit den einzelnen Beteiligten konzipieren. Wie aber können Schnittstellen gestaltet werden, damit nicht übermäßig viele Versionen der Schnittstellen entstehen und unterstützt werden müssen? In diesem Fall half die klassische SOA-Antwort dem Projektteam weiter. Es verwendete im PKW-Vertrieb von Daimler grobgranulare Schnittstellen und definierte vorab klare Verantwortlichkeiten innerhalb der Prozessverantwortung "Kundenauftragsprozess" - ein entscheidender Schritt (siehe dazu auch: Wie granular müssen SOA-Dienste sein?).

Die Verantwortlichkeiten wurden damals unterteilt nach Auftragsmanagement, Vertriebsplanung und Fahrzeugdistribution - heute sind das Domänen. Die Services der neu entwickelten Komponenten innerhalb dieser Domänen wurden gemeinsam mit wenigen Marktgesellschaften konzipiert und in Form einer versionierten Programmierschnittstelle (API) oder alternativ als Dialog (GUI) implementiert. Diese Vorgehensweise kam einem Richtungswechsel im Denken gleich, weil das Projektteam ausgehend von einem klar strukturierten Komponentenschnitt von Anfang an vollständige, grobgranulare und geschäftsbezogene Services angeboten hat anstatt zuerst eine minimale Schnittstelle zu definieren und diese dann sukzessive für weitere Märkte zu erweitern.

Von dieser Schnittstellengestaltung profitieren heute die Zentrale ebenso wie 150 Länder mit vielen unterschiedlichen und historisch gewachsenen IT-Systemen. Von 1998 bis heute gab es zum Beispiel lediglich sechs Versionen des Daimler-Ordering-Services - von denen drei parallel unterstützt werden - für etwa 60 Märkte. Zusätzlich steht für kleinere Märkte ohne eigene IT eine Internet-fähige Oberfläche bereit, so dass auch sie den Daimler-Ordering-Service nutzen können.

Fordern die Marktgesellschaften beispielsweise Distributionsinformation für ihr Ordering-System im Markt, so bietet Daimler einen Service aus der Domäne "Fahrzeugdistribution" an und spart sich damit die Anpassung des Ordering-Services. Der saubere Komponentenschnitt ermöglichte außerdem die reibungslose Integration des Bereichs "smart", indem die Daimler-Software Komponente für Komponente die Aufgaben der alten smart-Software übernahm.

Kunden konfigurieren PKWs online

Konfiguriert ein Kunde sein Fahrzeug zu Hause in liebevoller Kleinarbeit vor dem Rechner und erhält dann beim Händler die Antwort, dass die gewünschte Fahrzeugkonfiguration leider nicht baubar ist, dann ist Frust auf Kundenseite vorprogrammiert. Um geweckte Erwartungen gar nicht erst enttäuschen zu müssen, hat das Projektteam eine Baubarkeitsprüfung und einen Konfigurationsservice entwickelt. Damit lassen sich Fahrzeugkonfigurationen auf die technische Baubarkeit hin prüfen und nötigenfalls Optionen anzeigen, wie die Baubarkeit erlangt werden kann. Diese Services werden heute schon beim Ordering eingesetzt und sollen in Zukunft auch vom Internetkonfigurator genauso genutzt werden wie vom Verkäuferportal. Für das einwandfreie Funktionieren müssen die Daten konsistent und aktuell sein, die komplexe Prüflogik sollte nur einmal implementiert und die Produktdaten und -regeln nur einmal gepflegt werden müssen.

Der klassische Rat aus der SOA-Literatur, die Domänen und Komponenten nach fachlicher Verantwortung zu trennen und den richtigen Schnitt zwischen geschäftsprozess- und geschäftsobjektorientierten Domänen zu finden, hilft hier weiter. Es reicht nicht aus, Produktdaten an einer Stelle im System zu pflegen und dann zu verteilen. Vielmehr verwaltet die geschäftsobjektorientierte Domäne "Produkt" die Produktdaten und bietet zusätzlich Baubarkeitsprüfungen und Konfigurationsdienste für alle Nutzer an. Der Konfigurationsdienst darf so zum Beispiel nicht allein für den Internetkonfigurator in einem entsprechenden Projekt entwickelt werden, sondern ist kontextfrei mit dem Produktstammdatensystem zu entwickeln und kann dadurch von vielen unterschiedlichen Nutzern eingesetzt werden.

Seit dem Jahr 2005 prüft Daimler Fahrzeugkonfigurationen mit Hilfe der neuen Baubarkeitsprüfung. Der Konfigurationsdienst ist seit April 2008 produktiv. Darüber hinaus wird derzeit ein Verkäuferportal, das sowohl den Konfigurations- als auch den Ordering-Dienst nutzt, spezifiziert und in den nächsten Jahren eingeführt. So arbeiten alle Nutzer mit den gleichen und damit konsistenten Daten und vermeiden Verwechselungen oder Verzögerungen. Auch in puncto Geschwindigkeit sieht sich Daimler vorne: Die Zeitspanne, die benötigt wird, um eine Produktdatenänderung oder neue Produktdaten vom Zentralvertrieb an die lokalen Marktsysteme zu geben, reduziert sich mit dieser Anwendung von sechs Wochen auf einen einzigen Tag.

IT-Landschaften schnell und effizient anpassen

Eine Anwendungslandschaft, die weltweit über 150 Marktgesellschaften, mehrere Hundert Transportdienstleister und mehr als zehn Produktionsstandorte in die Wertschöpfungskette einbindet, kann nicht mehr nach den klassischen Regeln des Requirements Engineering entwickelt werden. Denn es ist schlichtweg unmöglich, die Anforderungen aller Beteiligten genau zu erheben. Deshalb hat der PKW-Vertrieb in den letzten zehn Jahren evolutionär eine Service-orientierte Anwendungslandschaft entwickelt, die durch ein langfristig angelegtes Change Management unterstützt und allen Beteiligten angeboten wird. Ein fachlich orientierter Komponentenschnitt und grobgranulare Services sind die entscheidenden SOA-Prinzipien, die helfen, von Anfang an die IT-Landschaft richtig zu entwickeln. Bestehende Services können jederzeit neu orchestriert, verändert oder neue Services hinzugenommen werden. Die klare Definition der Verantwortlichkeiten, so wie es heute von einem SOA-Domänenmodell erwartet wird, stellt sicher, dass Änderungen und Erweiterungen nur an einer Stelle erforderlich sind. So muss nicht vor jeder Prozessänderung eine langwierige Untersuchung zeigen, welche Systeme anzupassen sind. Die Service-orientierte Architektur sorgt bei Daimler für mehr Flexibilität und Agilität. Dabei bleibt sie keine abstrakte Vision, sondern erlaubt eine schnelle und effiziente Anpassung der IT-Landschaft an sich ständig verändernde Prozesse. (wh)

Mehr zum SOA und Business-Process-Management im CW-Experten-Blog SOA meets BPM.