Die zentrale Aufgabe von Unternehmen der Prozessindustrie ist im Gattungsnamen bereits beschrieben: die Optimierung von Prozessen über eine Vielzahl von Komponenten hinweg. Ein Chemieunternehmen etwa kann aus Hunderten von Einzelbetrieben zusammengesetzt sein, in jedem müssen wiederum zahlreiche Funktionen zusammenspielen, von der Beschaffung über die Herstellung vielfältiger Produkte mit unterschiedlichsten Rohstoffen, Rezepten und Planungsvarianten bis zur Verwaltung der Chargen und schließlich deren Auslieferung.
Die Integration der Anwendungssysteme, die diese Einzelprozesse steuern, in einen übergreifenden Gesamtprozess ist die zentrale He-rausforderung für IT-Manager dieser Industrie. Wie diese Integration gelingt, entscheidet über wichtige Wettbewerbsfaktoren: Produktivität durch gute Auslastung der Kapazitäten - was voraussetzt, dass die Einsatzstoffe sicher verfügbar sind und die Planungen auch kurzfristig geändert werden können. Lieferbereitschaft - weil die Bestände aktuell geführt werden und die Planungssysteme die vorhandenen Ressourcen wirklich kennen. Hohe Qualität - durch konsistentes Rezept-Management, exakt eingehaltene Prüfpläne sowie die Fähigkeit, Prozesse genau zu dokumentieren. Und: Senkung der Kosten - indem unter anderem die Lagerbestände durch exakte Prognose und Planung reduziert werden können.
Die Liste ließe sich fortsetzen, die Voraussetzungen wären stets die Gleichen: Zwei Anwendungsebenen, die sich historisch völlig unabhängig voneinander entwickelt haben, müssen möglichst nahtlos ineinandergreifen. Das ist zum einen die Unternehmensleitebene mit strategischen, kaufmännischen Aufgaben und einem längerfristigen Zeithorizont, zum anderen die Prozessleitebene zur Automatisierung der Anlagen mit kurzen Reaktionszeiten. In Ersterer sind heute ERP-Systeme wie etwa SAP, Navision oder Psipenta quasi Standards. Die Prozessleitebene hingegen besteht aus einer Vielzahl von gewachsenen, autonomen und für den jeweiligen Einsatzzweck optimierten Systemen mit wechselseitigen Abhängigkeiten.
Das klassische Instrument, um beide Welten zu koppeln, sind Betriebsführungssysteme (Manufacturing Execution Systeme = MES). Zu ihnen zählen unter anderem Laborinformationssysteme (LIMS), die Prüfungen beim Wareneingang oder zur Prozesslaufzeit organisieren, was zur Dokumentation der Qualität - etwa bei Reklamationen - unerlässlich ist. Hierzu gehören auch Systeme zur Produktionsplanung, von der Bedarfsermittlung mit mittelfristigem Zeithorizont bis zur Feinplanung der Produktions- beziehungsweise Prozessaufträge. Sie bestimmen, welches Teilrezept wann auf welcher Teilanlage läuft, berechnen, welche Ressourcen an Anlagen und Personal dafür benötigt werden, und verlegen bei Bedarf auch mal kurzfristig geplante Produktionsaufträge auf andere Anlagen. Eine besondere Herausforderung ist das Management der Rezepte. Diese werden primär von der Produktionsanlage zur Prozesssteuerung benötigt und von Technikern entworfen. Wichtige Daten daraus braucht aber auch das ERP-System für grundlegende betriebswirtschaftliche Funktionen wie Kalkulation, Nachkalkulation oder Richtpreise. Hier muss das MES eine sinnvolle Balance herstellen.
Das Zusammenspiel von ERP und MES entscheidet über die reibungslose Organisation von Betriebsabläufen. Allerdings handelte es sich bei den MES bisher meist um Client-Server-Systeme mit relativ starrer Architektur. Zudem wurden sie - anders als bei der in der Grafik skizzierten Verbundlösung - auch zunehmend direkt über Punkt-zu-Punkt-Verbindungen an das ERP angeschlossen. Diese "feste Verdrahtung" war nicht nur komplex und wegen umfangreicher Schnittstellen schwer zu pflegen. Sie konnte auch mit der geforderten Flexibilität der Abläufe in Konflikt geraten. Beispielsweise werden Produktionsaufträge in einem Chemiebetrieb durchaus unterschiedlich behandelt: In einem Fall soll das Labor schon sehr frühzeitig Qualitätsprüfungen vornehmen; der entsprechende Prüfauftrag wird dann vielleicht von der Anwendung ausgelöst, welche die Kundenbestellung abwickelt. Im anderen Fall sollen die Prüfläufe erst parallel zum Produktionsprozess stattfinden. All dies musste für jeden Einzelfall am ERP-Standard vorbei fest programmiert werden.
Problem: Sehr großer DatenumfangEine neue Generation von ERP-Systemen erlaubt jetzt neben den betriebswirtschaftlichen Funktionen auch die Einbindung von Qualitäts-Management, Prozessanbindung, betrieblicher Feinplanung und anderen Funktionen, für die eigenständige MES-Lösungen existieren. Der Versuch liegt also nahe, das ERP direkt an die Prozessleitebene zu koppeln.
Allerdings wirft dieser monolithische Ansatz zur Integration der Prozesse mehr Fragen auf, als derzeit beantwortet werden können. Ist es sinnvoll, eine bewährte, für den jeweiligen Einsatzzweck optimierte Funktionalität nachzubauen - vor allem wenn es sich um äußerst geschäftskritische Bereiche handelt und keine Erfahrungen mit dem Einsatz der neuen Funktionen vorhanden sind? Neben dem notwendigen Aufwand an Zeit und Personal sind auch die Probleme zu bedenken, die eine derart zentralistische IT-Architektur mit sich bringt. Eine ERP-Lösung wie beispielsweise SAP R/3 zeichnet sich durch einen sehr großen Datenumfang aus. Bei einer Lösung mit MES wird das Datenmodell des ERP nur auf die Felder und Tabellen projiziert, die in der Produktion wirklich eine Rolle spielen.
Daten und Reports für die VorschauZudem benötigt der Produktionsbetrieb für seine tägliche Arbeit aktuelle Daten und Reports, die auch eine Vorschau erlauben. Der Direktzugriff auf das ERP-System ist nicht nur aufwändig zu programmieren: Wenn Mitarbeiter in Hunderten von Werken täglich beispielsweise für Auswertungen, Reports oder Fehler-Management auf die operativen Daten zugreifen, bringt dies enorme Performancebelastungen mit sich. Notwendig wird deshalb ein Caching, in der Regel in einem Data Warehouse. Die Zyklen, in denen diese Daten geladen werden, lassen sich zwar definieren. Auf keinen Fall jedoch erfolgt die Aktualisierung ereignisgesteuert. Damit sind diese Daten nicht wirklich aktuell und damit nur bedingt zur operationellen Steuerung des Betriebs zu gebrauchen. Auch kann es zu Konflikten zwischen betrieblichen DV-Anforderungen vor Ort und zentralen IT-Vorgaben kommen.
Neue MES-Generation nutzt EAI-TechnikenDer zentralistische Ansatz ist in einer hochgradig individuellen, heterogenen und vielschichtigen Welt wie der Prozessindustrie wenig sinnvoll. Zumindest bei komplexen Produktionen wie Mehrprodukt- und Mehrstranganlagen wird nach wie vor eine vermittelnde Instanz benötigt. Dies ermöglicht eine neue Generation von MES-Systemen durch eine deutlich erhöhte Flexibilität. Sie greift eine Technologie auf, die in einer völlig anderen Welt entwickelt wurde, nämlich dem E-Com-merce. Welche Anforderung ist hier zu lösen? Die Integration von Geschäftsprozessen über heterogene Anwendungs- und Plattformgrenzen hinweg. Genau dies auch ist die klassische Aufgabe in der Prozessindustrie. Was also liegt näher, als diejenige spezifische Lösung zu übertragen, die beim E-Commerce genau dafür entwickelt wurde: die unter dem Schlagwort EAI bekannten Techniken zur netzweiten Integration unterschiedlicher betrieblicher Anwendungssysteme?
Ein Message- oder Informations-Broker fungiert als "Bote" zwischen den verschiedenen IT-Ebenen. Er vermittelt zwischen heterogenen (und für den jeweiligen Zweck optimierten) Systemen, statt sie zu ersetzen. Bewährte Anwendungen und Reports können weiterverwendet werden. Da der Broker die feste Punkt-zu-Punkt-Programmierung ersetzt, entsteht mehr Flexibilität. Und da weniger Schnittstellen zu verwalten sind, sinken Komplexität, Fehleranfälligkeit und Betreuungsaufwand.
Über Adapter "zapft" ein Informationsbroker das ERP-System an, empfängt dort die entsprechenden Nachrichten - etwa einen Strom von Aufträgen, die auf die unterschiedlichen Produktionsbereiche verteilt werden müssen - und übergibt sie je nach Inhalt an den Empfangsadapter des "zuständigen" Subsystems. Umgekehrt erhält er vom MES Nachrichten, etwa wenn ein Subsystem einen Prozessauftrag erzeugt, und übergibt sie an die ERP-Ebene.
Im Repository des Brokers ist das Wissen gespeichert, das benötigt wird, um die Nachrichten in eine Form zu transformieren, die das jeweilige Empfängersystem versteht (Mapping), und in vernetzten Strukturen das richtige System zu finden (Routing). Entsprechend den sich herausbildenden Standards sind die Daten applikationsunabhängig in XML beschrieben. Der Broker kann diese Metadaten interpretieren und da-raus direkt Strukturen generieren.
Mit der Broker-Technologie lassen sich auch wesentlich einfacher und flexibler Workflows zwischen verschiedenen Anwendungssystemen definieren.
Mit der Übernahme von Technologien aus der Welt des E-Business wird zugleich die Zweischicht-Architektur der ClientServer-Welt durch eine Mehrschicht-Architektur ersetzt (Thin Client als Oberfläche, Applikations- und Datenbankserver). Damit können MES-Funktionen in Form wiederverwendbarer Komponenten realisiert werden, deren Schnittstelle durch Business-Objekte definiert wird. Die Komponenten besitzen die für ihre Aufgabe benötigten Daten - und nicht mehr. So muss nicht - wie beim ERP-Ansatz - jeweils das gesamte Datenmodell genutzt werden. Zur Kommunikation untereinander benötigen die Komponenten - gewollte - Datenredundanzen. Funktionalität kann ergänzt oder reduziert werden, ohne dass man darauf achten muss, ob andere Anwendungen diese Daten nutzen. Diese autonomen Funktionsbausteine schaffen eine wesentlich höhere Flexibilität.
In einer derartigen Architektur werden nicht - wie bei einem zentralistischen Datenbankansatz, auf dem die heutigen ERP-Systeme basieren - alle potenziell benötigten Daten in der Datenbank gehalten. Vielmehr werden zur Laufzeit externe Systeme über das Internet in den Prozess eingebunden. Dies ist für eine Vielzahl von Daten sinnvoll, wie zum Beispiel Auszüge aus Gefahrstoffdatenbanken, Verfahrenshinweise von Anlagen- und Ausrüstungslieferanten oder auch Produktions- und Qualitätsdaten von internen wie externen Zulieferern. Umgekehrt können auch Daten aus dem eigenen Betrieb in Form der Business-Objekte im Netz bereitstellt werden, um auf sie von Web-Browsern oder anderen Anwendungen aus zuzugreifen. Für die Implementierung dieser Anwendungsarchitektur kommen unterschiedliche Komponententechnologien in Betracht: Microsofts .NET for Manufacturing beziehungsweise auf Corba und Java basierende Ansätze (Java Enterprise Beans) .
Die gesamte IT-Welt der Prozessindustrie entwickelt sich so immer mehr in Richtung kollaborativer Systeme. Die Integration setzt nicht an der Oberfläche an, sondern bereits auf der Prozessebene.
IT-Verantwortliche wie Nutzer profitieren davon. Zum einen werden Kosten und Aufwand der IT gesenkt; die Wartung der Software wird einfacher, und neue Lösungen beziehungsweise Versionen können mit Hilfe der Browser-Technologie eingeführt werden, ohne dass Installationsaufwand entsteht oder die Anwendungen heruntergefahren werden müssen. Zum anderen werden die betrieblichen Ziele besser unterstützt. Dank einer tagesaktuellen Bestandsführung kann das Unternehmen jederzeit an jedem Ort exakte Zusagen machen, wann was geliefert wird. Es wird endlich "available to promise".
*Walter Hetzel-Herzog ist Projekt-Manager bei der PSI-BT AG in Berlin.
Abb.1: Lose gekoppelt, aber eigenständig
Informationsfluss zwischen Unternehmens- und Prozessleitebene unter Einsatz eines Verbunds von lose gekoppelten eigenständigen Betriebsführungssystemen (Manufacturing Execution Systems = MES), die jeweils einen bestimmten Zweck erfüllen sollen ("best-of-breed"-Lösung). Quelle: PSI
Abb.2: Manufacturing Execution Systems (MES)
Zusammenstellung der MES-Funktionen aus der Sicht der gemeinnützigen Organisation MESA International (www.mesa.org). Quelle: PSI