Der Dienstleister Havi Logistics muss beim Supply Chain Management (SCM) für die Systemgastronomie eine wachsende Zahl heterogener Prozesse integrieren. Die selbst entwickelte EAI-Lösung kam dabei an ihre Grenzen. Mit dem Wechsel zu einer serviceorientierten Architektur (SOA) erreichte der Logistikdienstleister eine wesentlich höhere Flexibilität.
Havi Logistics ist für eine reibungslose Distribution sämtlicher Food- und Nonfood-Artikel nach einem "one-stop-shopping"-Konzept verantwortlich. Die Kernkompetenzen definieren sich in physischer Warenversorgung, Handelsfunktionen sowie Supply-Chain-Informations- und Planungsleistungen. Havi möchte die Restaurants von allen logistischen Aufgaben entlasten, damit sich diese auf Ihre Kernkompetenz - die Bedienung der Gäste - konzentrieren können.
Havi sieht sich dabei als "The Global Lead Logistics Provider" für die Food Service Industry und beliefert mit seinem "one-stop-shopping"-Konzept neben mehreren Tausend McDonald’s Restaurants in Europa auch Tankstellen-Shops, Supermarktketten und Catering-Betriebe. Das Geschäftsmodell bedingt eine hohe wechselseitige Integration der Geschäftsprozesse und resultiert in langfristigen Kundenbeziehungen, die neben McDonald's beispielsweise auch mit BP, Bone's, Compass, Danone, Ikea, Rimi und Vapiano bestehen.
Während sich das Angebot der Systemgastronomie in der Regel gegenüber dem Gast sehr homogen präsentiert, sind die dahinter liegenden Geschäftsprozesse oft heterogen organisiert. Die Restaurants von McDonald's werden beispielsweise überwiegend von Franchise-Nehmern betrieben, die eigenständige Unternehmer sind und die innerhalb Europas auch über eine unterschiedliche IT-Ausstattung verfügen. Dies stellt an die Integration der Geschäftsabläufe besonders hohe Anforderungen, und damit notwendigerweise an die IT, die diese Integration zu tragen hat.
Da für die komplexen Prozesse zwischen Lieferanten, Restaurants, Franchise-Nehmern und Logistikdienstleister keine fertige Software zur Verfügung stand, hat die heutige Havi Logistics IS GmbH, das IT-Unternehmen von Havi Logistics, in den 90er-Jahren mit eigenen Entwicklern eine eigene Lösung entwickelt. Das Kernsystem ILOS wurde mit Progress-Technologien erstellt. Zusammen mit einer hinzugekauften Finanzbuchhaltung bildete diese Lösung zunächst alle wesentlichen Prozesse ab.
Integration heterogener Systeme
So einfach und übersichtlich ist die IT-Landschaft bei Havi inzwischen nicht mehr. Das Geschäftskonzept erforderte eine immer höhere Integration, immer mehr Kundensysteme mussten eingebunden, immer mehr Aufgaben in den Business-Prozessen übernommen werden. Damit wuchs auch die Anzahl der beteiligten IT-Systeme. Aus den zwei Applikationen des Jahres 1997 waren bis 2006 über 25 sehr heterogene Lösungen geworden – und alle mussten sie unter einen Hut gebracht werden, weil jedes Element seinen Teil zum Gesamtprozess beisteuerte. Wobei die Skala der zu integrierenden Applikationen sehr weit ist und von Alt-Anwendungen auf Basis von Clipper und dBase über Web-Applikationen bis hin zu SAP-Modulen reicht. "Da wir unsere Kunden bestmöglich unterstützen möchten, aber keine einheitliche Technologie vorschreiben können", erklärt Stefan Lang von Havi, "müssen wir alle uns angebotenen Systeme integrieren."
So ging man daran, für die Integration dieser Systeme eine eigene, ganz an die konkreten Bedürfnisse angepasste EDI-Lösung zu entwickeln. Sie erlaubt es, die verschiedenen Systeme über Konnektoren zu verbinden: die eigene Individual-Lösung, aber auch die vorhandene Standard-Software der Kunden. Dabei mussten ganz unterschiedliche Systeme zusammengebracht werden, beispielsweise eine AS/400-Lösung von McDonald's, die eigene Data-Warehouse-Anbindung oder SAP-Module eines Lieferanten. Diese EDI-Lösung war auf Basis von Java und einer Oracle-Datenbank erstellt und wuchs im Laufe der folgenden Jahre mit den an den Geschäftsprozessen beteiligten Systemen.
Mit wachsendem Geschäftsumfang und der immer größeren Zahl zu integrierender Systeme machten sich jedoch auch die Grenzen dieser EDI-Lösung bemerkbar. So war die verwendete Hub-and-Spoke-Architektur mit den mittlerweile auf rund 4.000 bis 5.000 angewachsenen Filial-Standorten im In- und Ausland allmählich überfordert. "Hier war der Übergang zu einer verteilten Struktur dringend geboten", erklärt Lang.
Ein weiteres Problem stellte die unzureichende Skalierbarkeit der Lösung dar, die sich nicht so einfach erweitern ließ, wie das im Zuge des Ausbaus des Geschäfts erforderlich gewesen wäre; die Grenzen des Wachstums waren hier abzusehen. Vor allem aber mangelte es dem System an Flexibilität. Denn kurzfristige Änderungen von Organisation oder Prozessen – wie sie in einem derartig komplexen Geschäftsbetrieb immer vorkommen – ließen sich mit dieser proprietären Lösung nur schwer umsetzen.
Von EDI zu SOA
"Auch unser langfristiges Ziel, IT-Services dort zu kaufen, wo sie kostengünstig sind, ließ sich mit dem EAI-System nicht realisieren", erläutert Lang. So war auch die Nutzung von externen Ressourcen nur eingeschränkt möglich, weil das erforderliche Know-how eben nicht Allgemeingut war.
Damit stellte sich für Havi die Grundsatzfrage: Was kommt nach EAI? "Wir haben auch festgestellt, dass sich der Markt seit der Entwicklung unserer eigenen EAI-Lösung sehr verändert hat", sagt Lang. "Damals, gegen Ende der 90er-Jahre, mussten wir selbst programmieren, weil die nötigen Funktionalitäten auf dem erforderlichen Niveau einfach nicht frei verfügbar waren. Mittlerweile aber hat sich der Markt weiterentwickelt, und man kann vieles einfach kaufen, was man früher aufwändig entwickeln musste." Es zeigte sich dabei auch, dass die serviceorientierte Architektur (SOA) mittlerweile eine breite Unterstützung findet.
Für den Übergang zu SOA erwies es sich als vorteilhaft, dass das bisherige EDI-System bereits message-basiert arbeitete. "Durch unsere Supply-Chain-Integration sind Vorgänge schon als entkoppelte Services vorhanden und viele Dinge nachrichtenbasiert, so dass die Voraussetzungen für SOA günstig waren", merkt Lang an. "Dennoch haben wir auch mit grundsätzlich nicht serviceorientierten Systemen zu tun. Hier müssen wir Services durch Programmierarbeit herstellen. Allerdings gibt es auf SOA-Basis immer auch die Alternative, fertige Services zu kaufen." Die Umstellung auf SOA ist jedoch kein eigenständiges Projekt. Neue Lösungen entwickelt Havi nun immer serviceorientiert, bei bestehenden wird die Technologie erst im Rahmen von größeren Release-Wechseln angepasst.
Die große Herausforderung für einen Übergang von EAI zu SOA stellen aber ohnehin nicht die eigenen Systeme dar, in deren Code Havi bei Bedarf eingreifen kann, sondern die der Kunden. Hier lassen sich jedoch die vorhandenen Konnektoren zu diesen Systemen auch weiterhin nutzen, in vielen Fällen sogar unverändert. Da die Konnektoren des EAI-Systems bereits in Java programmiert sind, sind sie in der Regel wie Services ansprechbar. Für die Kunden ändert sich daher nichts: Erfolgt beispielsweise die Abgabe eines Verkaufs-Forecasts aus einer altgedienten dBase-Datenbank über MQSeries, so kann Havi diese Nachricht weiterhin über den Konnektor entgegennehmen. "Sofern Kunden ihrerseits auf SOA umschwenken, können wir diese Systeme innerhalb kürzester Zeit unterstützen", sagt Lang. Insgesamt rechnet Havi mit einer Übergangsphase von fünf bis acht Jahren, während dieser Zeit sollen SOA und Legacy-EDI gemeinsam genutzt werden.
Die Steuerung der Kommunikation in der SOA erfolgt über den Enterprise Service Bus (ESB) Sonic von Progress Software. Diese Messaging-Middleware, die in reinem Java implementiert ist, stellt eine verteilte, standardbasierte Infrastruktur bereit, mit der sich Applikationen verschiedenster Art verbinden lassen. Auch unternehmensübergreifende Business-Prozesse können damit organisiert werden.
SOA zahlt sich aus
Auf diese Weise wird die SOA-Lösung auch betriebswirtschaftlich interessant. "Die SOA-Anlaufkosten sind höher als die Kosten für EAI-Projekte, bei denen man mit vertrauen Technologien und Prozessen arbeitet", betont Lang. " SOA bedeutet daher, dass zwar zunächst manches langsamer geht und teurer wird. Aber sobald SOA greift und neue Implementierungen oder Erweiterungen wirklich um ein Vielfaches schneller zu realisieren sind, zahlen sich die Investitionen aus."