Häuslebauer und IT-Verantwortliche haben vieles gemeinsam. Beide müssen auf eine solide Architektur achten - das gilt für das Häuschen im Grünen genauso wie für das Enterprise-Resource-Planning-System (ERP-System) als tragende IT-Säule in vielen Unternehmen. Architekturen rund um Business-Software sind pflegebedürftig und müssen sorgfältig überwacht werden.
Der Aufbau klassischer ERP-Systeme besteht aus mehreren Schichten. Norbert Gronau vom Lehrstuhl für Wirtschaftsinformatik und Electronic Government an der Universität Potsdam unterscheidet folgende Ebenen:
-
Die Basis einer ERP-Lösung bildet das Datenbank-Management-System (DBMS), das alle wichtigen Informationen aus den verschiedenen Bereichen wie beispielsweise Produktion, Vertrieb und Finanzbuchhaltung vorhält. Im Regelfall setzen Anwender an dieser Stelle auf relationale Datenbanken. Systeme wie Oracle, IBMs DB2 und der SQL Server von Microsoft dominieren derzeit den Markt.
-
Auf der Datenbank setzt die Applikationsschicht auf, die sich wiederum in verschiedene Komponenten untergliedern lässt. Ein datenbankabhängiger Teil regelt den Zugriff auf die Informationen in der Datenbank, ein unabhängiger Teil reicht die Daten an den Applikationskern des ERP-Systems weiter. Diese Trennung dient dazu, Optimierungsroutinen für den Zugriff auf die Datenbank möglichst effizient nutzen zu können. Neben dem eigentlichen Applikationskern, in dem typische ERP-Prozesse wie Finanzbuchhaltung, Produktionsplanung und Materialwirtschaft oder das Personal-Management abgewickelt werden, verfügen die Systeme in der Regel auch über eine eigene Programmierumgebung. Damit sind Anwender in der Lage, die Anwendungen eigenständig zu ergänzen. Middleware-Komponenten in der Applikationsebene sorgen zudem dafür, dass das ERP-System andere Programme ansprechen kann. Das funktioniert beispielsweise über "Remote Procedure Calls" (RPCs) oder über so genannte User Exits.
-
Eine Adaptionsschicht gestattet es den Anwendern, ihr ERP-System an individuelle Anforderungen anzupassen. Wie tief diese Anpassungen eingreifen und das ERP-System modifizieren, hängt von den einzelnen Lösungen ab. Viele Applikationen bieten den Anwendern eine Reihe vorkonfigurierter Stellschrauben, mit deren Hilfe sich das System parametrisieren lässt. Der Vorteil dieser Parametrisierung liegt darin, dass die hier vorgenommenen Einstellungen am System in aller Regel Release-fähig sind. Wer sein System über diese vom Hersteller vorgegebenen Parameter hinaus verändern möchte, muss auf das Customizing zurückgreifen. Relativ unproblematisch sind Modifikationen über User Exits. Diese vordefinierten Anknüpfungsstellen werden vom Hersteller gepflegt und sind daher ebenfalls Release-fähig. Schwieriger wird es mit Veränderungen direkt im ERP-Code. In diesem Fall muss bei allen weiteren Veränderungen am System oder im Zuge von Updates ständig geprüft werden, ob das individuelle Customizing noch funktioniert.
-
Das oberste Stockwerk des ERP-Gebäudes bildet die Präsentationsebene, die im Wesentlichen aus der Benutzeroberfläche, dem GUI (Graphical User Interface), besteht. Typischerweise nutzen die meisten aktuellen ERP-Systeme an dieser Stelle standardsierte Web-Clients. Anwender können so via Web-Browser von verschiedenen Endgeräten aus auf die ERP-Anwendungen zugreifen. Eine spezielle Client-Installation mit Anpassungen an das jeweilige Endgerät entfällt mit Browser-basierenden GUIs.
Dieses Schichtenmodell, das auf den ersten Blick eine solide und geordnete ERP-Architektur suggeriert, ist nicht in Stein gemeißelt. In den vergangenen Jahren haben sich in der Business-Software-Liga verschiedene Spezialdisziplinen herausgebildet, die rund um das ERP-System eingebunden werden wollen. Dazu zählen beispielsweise Systeme für Customer-Relationship-Management (CRM), Supply-Chain-Management (SCM) und Business Intelligence (BI). Mit diesen das ERP-System flankierenden Softwaremodulen wuchs auch der Integrationsaufwand.
Integrationsdruck verstärkt sich
Der Integrationsdruck verstärkte sich außerdem durch verschiedene Entwicklungen bei den Anwendern. Beispielsweise griff der Softwareeinsatz in den Unternehmen immer weiter um sich. Fabriken, Filialen, Lager und andere Firmenbereiche mussten in der ERP-Architektur berücksichtigt werden. Im Rahmen der Globalisierung weiteten viele Firmen ihre Geschäfte zudem international aus, sei es dass sie im Ausland produzierten oder neue Absatzmärkte erschlossen. In der Folge mussten die IT-Abteilungen die Business-Softwaresysteme entsprechend nachziehen. Im Zuge dieser Entwicklungen rückten Aspekte rund um die Architektur der ERP-Systeme immer stärker in den Vordergrund.
Die Liste der Integrationsaufgaben wurde im Lauf der Zeit immer länger. Was vor Jahren unter dem Begriff Enterprise Application Integration (EAI) begann, mündete schließlich in die Entwicklung von ganzen Middleware-Plattformen und Service-orientierten Architekturen (SOA).
Doch die Versprechungen der Softwarehersteller, der Betrieb der Softwarelandschaften werde sich damit vereinfachen, erfüllten sich vielfach nicht. Im Gegenteil: Gerade in der jüngeren Vergangenheit häuften sich die Klagen von Anwendern, der Betrieb der ERP-Systeme werde zunehmend komplexer.
Man wird den Schwarzen Peter sicher nicht allein den Softwareanbietern zuschieben können, zumal viele Anwender in der Vergangenheit ihre Architekturen durch massives Customizing teilweise so extrem verbogen haben, dass sich das ERP-Handling im Lauf der Zeit deutlich erschwert hat. Es sei dahingestellt, wem man Fehler anlasten will, unüberhörbar bleibt der Ruf nach leichter zu bedienenden und effizienteren ERP-Systemen.
"Moderne ERP-Lösungen müssen aus Sicht der Anwender einfach sein", formulierte schon die Deutschsprachige SAP-Anwendergruppe (DSAG) ihre Forderungen. "Wir brauchen eine sichere, stabile, performante, einfach und intuitiv zu bedienende, flexible und einfach anpassbare sowie erweiterbare IT-Lösung zur effizienten und effektiven Durchführung aller Geschäftsprozesse mit einem vernünftigen Kosten-Nutzen-Verhältnis."
ERP-Herausforderungen wachsen
Diesen Wunsch zu erfüllen dürfte nicht einfach werden. Auf die IT-Verantwortlichen warten bereits die nächsten ERP-Herausforderungen. Der Takt, in dem das Business neue Anforderungen an die Systeme stellt, wird schneller. Dabei geht es in erster Linie um mehr Flexibilität und Agilität, um schnell auf veränderte Geschäftsparameter reagieren zu können. Dazu kommen neue technische und strategische Entwicklungen. In-Memory-Computing rüttelt an den Grundfesten der Datenarchitektur, die verstärkte Nutzung mobiler Devices erfordert einen Ausbau der bestehenden Architekturen, und neue Methoden der IT-Nutzung rund um Cloud Computing stellen die Art und Weise, wie Unternehmen ihre ERP-Architekturen betreiben und pflegen sollten, grundsätzlich in Frage.
Integrationsmodelle
Die ERP-Architektur beeinflusst auch maßgeblich, wie gut oder schlecht sich Business-Software integrieren lässt. Folgende Integrationsmodelle lassen sich unterscheiden:
Punkt zu Punkt: Bei herkömmlichen Punkt-zu-Punkt-Ansätzen werden je nach Bedarf individuelle Schnittstellen zwischen den verschiedenen Anwendungen entwickelt. Wächst das Sys-tem, werden die Zusammenhänge schnell unübersichtlich. Außerdem erfordert die Pflege der Schnittstellen einen hohen Aufwand. Immer wenn sich einzelne Anwendungskomponenten ändern, muss geprüft werden, ob die Verbindungen noch funktionieren.
Hub and Spoke: Für mehr Ordnung sorgen zentral organisierte Hub-and-Spoke-Architekturen, die auf Middleware-Konzepten basieren. Dabei werden Nachrichtendokumente (Messages) über Adapter (Spokes) an einen zentralen Hub gesendet, dort nach definierten Regeln bearbeitet und an die Zielsysteme weitergeleitet. Eine Variante dieses Modells sind Bus-Sys-teme, die auf einem Enterprise-Service-Bus (ESB) aufbauen.
Service-orientierte Architekturen (SOA): Das SOA-Modell greift im Grunde wieder den dezentralen Ansatz der Punkt-zu-Punkt-Verbindungen auf. Allerdings basieren die Schnittstellen auf Standards wie Web-Services. Zudem stellt dieses Modell im Backend neutrale gekapselte Services (Funktionen) zur Verfügung, die sich verteilt in verschiedenen Prozessen einsetzen und damit auch in verschiedenen Anwendungszusammenhängen wiederverwenden lassen.
Lesen Sie dazu auch: Belastungsprobe für die ERP-Architekturen