Das Verhältnis zu den Kunden ist schon sehr speziell. Der Grazer Autobauer Magna Steyr baut im Auftrag für Autokonzerne komplette Fahrzeuge wie den Chrysler 300c, den BMW X3 und den Jeep Grand Cherokee. Weil dieses Geschäftsmodell nur selten vorkommt, gibt es in der Magna-Steyr-IT zu den Kunden fast nur Individualschnittstellen - die der OEM (Original Equipment Manufacturer) vorgibt. "Wir brauchten ein standardisiertes Interface, um den Schnittstellenwald in den Griff zu bekommen“, berichtet Roland Kortschak, Leiter der Softwareentwicklung.
Zwar begann Magna Steyr bereits 1999 damit, ein eigenes Standardschnittstellen-Tool als Integrationssystem zu bauen. Bis dahin war es bei Magna Steyr noch üblich, dass jede Entwicklungsabteilung ihre Schnittstellen je nach Bedarf selbst baute. Doch die Eigenentwicklung stieß bald an ihre Grenzen. Durch neue Kunden, Fahrzeugmodelle und neue beteiligte IT-Systeme mussten immer mehr Daten über das Tool integriert werden. „2003 war das Tool ausgereizt und der Druck groß, ein flexibleres Integrationswerkzeug einzusetzen“, sagt Kortschak. Die Weiterentwicklung des eigenen Tools wäre zu teuer geworden und gehörte auch nicht zum Kerngeschäft der IT. „Eigene Tools lösen wir ab, sobald es günstigere Standard-Tools gibt“, erläutert Kortschak die Strategie.
Im Jahr 2004 entschied sich Magna Steyr für das EAI-Tool der Inubit AG. Im ersten Testprojekt bereitete das Unternehmen darüber Daten für das über SAP vermittelte Antragswesen auf. In einem weiteren Schritt verknüpfte Magna Steyr mit dem Tool das Hauptsystem der Produktionssteuerung und Logistik SAM (Steyr Automotive) mit dem SAP-System. Unterhalb der „SAM-Ebene“ arbeiten wiederum weitere produktionsunterstützende Systeme, die Mitarbeiter am Fließband verwenden. Auch diese Subsysteme verbindet das Werkzeug mit SAM. „Alle neuen Schnittstellen laufen seit 2004 über das Tool“, so Kortschak.
Künftig massiv SAP integrieren
Noch spielt SAP als ERP-System keine große Rolle, obwohl der Autohersteller einer der ersten SAP-Anwender in Österreich war. Der Einsatz beschränkt sich im Wesentlichen auf die Module Buchhaltung, Controlling sowie Instandhaltung. Doch die Integration mit dem SAP-System wird künftig einer der Kerneinsatzbereiche für das EAI-Tool werden. „Wenn wir neue Werke bauen und neue Systeme einführen, setzen wir massiv auf SAP als ERP“, erläutert der Software-Chef die Strategie.
Zur Harmonisierung der IT-Landschaft gehörte auch die Standardisierung von Tools. Den großen Vorteil eines Standard-Tools für die Integration sieht Kortschak darin, dass der Support deutlich besser funktioniert. Die Autoproduktion läuft im Grazer Werk in drei Schichten 24 Stunden am Tag. Wenn ein IT-Mitarbeiter in Bereitschaft nachts gerufen wird, muss er den Fehler finden können. Erst ein Standardwerkzeug ermöglicht dieses schnelle Arbeiten. "Wir sind nicht mehr so abhängig vom tiefen Wissen über einzelne Schnittstellen“, erläutert Kortschak. Auch lasse sich die Datenqualität durch ein Standard-Tool besser bewahren. Allerdings sei der Aufwand gleich geblieben, die Qualität der Daten hoch zu halten: Ständig steigende Inforderungen und mehr Systeme verhindern Erleichterungen. Nur: "Mit individuellen Lösungen wäre die Komplexität explodiert“, erklärt er.
Entwickler mögen keine Standards
Doch Kortschak erlebte auch, dass Komplexität trotz Standardwerkzeugen steigen kann. So gab es in der IT eine Gruppe, die sich zentral um EAI-Projekte kümmerte. Die EAI-Spezialisten sollten darauf achten, dass neue Schnittstellen standardisiert entwickelt wurden. Doch nicht immer gelang das. "Der Drang in Entwicklungsgruppen, Schnittstellen individuell zu lösen, ist größer, als einen Standard einzusetzen“, weiß Kortschak. „Für einzelne Schnittstellen ist ein Standard manchmal aufwendiger. Über die ganze Landschaft gesehen ist das aber bei der Integration aller Systeme ein riesengroßer Vorteil.“ Durch organisatorische Änderungen sind nun die EAI-Spezialisten direkt in den Entwicklungsgruppen angesiedelt und können so koordiniert direkter darauf Einfluss nehmen, dass Schnittstellen nach einer einheitlichen Methode programmiert werden.
EAI läuft heute als Service für den Betrieb der Systeme. "Wir verrechnen den Service der Integration, indem wir die Kosten auf die einzelnen Systeme verteilen“, erläutert Kortschak. Neue Projekte gibt es beispielsweise dann, wenn wie in diesem Jahr ein neues MES-System (Manufacturing Execution System) für die Produktion eingeführt werden soll.
Neue Integrationsarbeiten fallen auch an, wenn der Autobauer einen neuen Auftrag gewinnt und ein neues Werk in der Nähe des OEMs bauen muss. Wenn nach langen Verhandlungen ein Vertrag perfekt ist, will Kortschak nicht erst mir seiner Arbeit anfangen. Auf diesen Fall muss die IT vorbereitet sein und möglichst wenig Vorlauf haben. "Allein in der Durchdringungstiefe von Standardsystemen unterscheiden sich die Systemansätze für die neuen Werke stark von den bestehenden Konzepten in Graz“, sagt Kortschak.
Mit den neuen Konzepten gestaltet Magna Steyr die IT-Landschaft noch stärker serviceorientiert als bisher. So laufen seit rund einem Jahr alle neuen Integrationen über Web-Services. "Neue Systeme basieren auf unseren strategischen Plattformen Microsoft .NET und SAP Web Dynpro. Das sind unsere Entwicklungsplattformen, auf denen wir serviceorientiert arbeiten“, sagt Kortschak. Soweit das möglich ist: Nicht überall, wo Service-orientierte Architektur (SOA) draufsteht, steckt auch SOA drin. So fiel ihm auf, dass Lösungsanbieter längst nicht alle Schnittstellen ihrer Tools serviceorientiert bereitstellen: "Das ist ein Hindernis bei Projekten."
Der Begriff EAI wurde aber nicht nur durch das Hype-Kürzel SOA überlagert. Auch sind Marketing-Abteilungen der Hersteller darangegangen, EAI durch den Ausdruck Business Integration abzulösen. Doch wie Anbieter und Berater es auch nennen, es gibt noch wenige Entwicklungen in diesem Bereich. „Es wird nicht so schnell kommen, dass man beliebig Funktionen aus verschiedenen Systemen verknüpft und daraus einen Prozess gestaltet. Den Schritt sehe ich noch nicht“, resümiert Kortschak.
Unüberwindliches Silo-Denken
Service-orientierten Prozessen steht noch etwas viel Grundsätzlicheres entgegen. IT-Abteilungen arbeiten und denken noch zu sehr in Silos: Das ist ein ERP-System, das ein MES-System (Manufacturing Execution System), und das ist ein Leitsystem. „Es sagt aber niemand, ich brauche diese Funktion x, ohne darüber nachzudenken, zu welchem System diese Funktion gehört“ sagt Kortschak. Es sollte egal sein, wo die Funktion hergeholt wird. Sie muss nur immer verwendbar sein. „Das wäre Business Integration ohne Ansicht der Ebene“, beschreibt er das Ideal.
Er ist sich nicht sicher, ob überhaupt schon jemand diese Denkweise verinnerlicht hat: die IT-Systeme integriert über alle Ebenen hinweg betrachten. Kortschak: „Wir arbeiten daran. Aber ich kann nicht garantieren, dass eine Funktion auf der MES-Ebene morgen nicht auch auf der ERP-Ebene geschaffen wird, weil man es nicht weiß oder es übersieht.“