Wieso die ERP-Systemarchitektur mehr Aufmerksamkeit verdient

Systemarchitektur-ERP-Software

Berater und Anbieter werden nicht müde zu betonen, dass jedes ERP-Projekt ein Projekt des Business‘ sei. Gemeint ist, dass nicht die IT-Abteilung bestimmt, welche ERP-Software gekauft wird sondern die Nutzer aufgrund der Anforderungen im Tagesgeschäft und der Unternehmensentwicklung. Allerdings sollte die Rechnung nicht ohne die IT gemacht werden. Denn einige grundlegende Fragen im Bereich der Systemarchitektur sind wichtig weil wegweisend für die Möglichkeiten und die Umsetzung auf Ebene der Anwender und Kunden.

Ein ERP-System ist nicht allein

ERP-Systeme bestehen heute praktisch immer aus verschiedenen Komponenten. Neben der ERP-Software, die man von einem ERP-Hersteller bezieht sind häufig weitere Applikationen im Einsatz. Die Palette reicht von der Zeiterfassung, über Maschinenterminals, PDM/PLM-Systeme, Tourenplanung, Ticket-, Mailing- und Zugangssicherungssysteme bis hin zu spezialisierten Kalkulations-, Planungs-, Mess- oder Auswertungstools (siehe Tools für ERP-Systeme).  Die am Markt verfügbaren ERP-Lösungen der verschiedenen Anbieter decken unterschiedliche Bereiche ab. Wenn ein neues ERP-System evaluiert werden soll stellt sich somit ganz zu Beginn die Frage, nach was suchen wir genau? Welche Bereiche sollen durch ein ERP-System abgedeckt werden (hohe Integration), wo sind evtl. hochspezialisierte Anwendungen sinnvoll (Abdeckung hochspezifischer Anforderungen) und wo greift man auf eine externe Standardlösung zurück? Oder anders gesagt: welche vorhandenen Systeme werden angebunden und welche abgelöst? Wie sieht die Architektur auf Ebene der Teilsysteme aus? Und welchen Einfluss hat die Wahl der Architektur auf Performance, Verfügbarkeit und Datensicherheit?

Im Laufe eines ERP-Projekts werden die Fragen zunehmend konkretisiert. Damit verbunden sind Überlegungen zu Schnittstellen, Datenmodell, Betrieb, Release- und Lebenszyklus-Management des Gesamtsystems. Eine gute Hilfestellung in dem Zusammenhang ist das Systemkontextdiagramm.

ERP-System-Kontextdiagramm

Systemkontextdiagramm

 

Systemarchitektur auf verschiedenen Ebenen

Viele Unternehmen in der Schweiz verfügen über Niederlassungen oder Partnerbetriebe im In- oder Ausland oder sind selber Teil eines Konzerns (oder beides). Nehmen wir als Beispiel ein Produktionsunternehmen mit einem Lager in der EU und Produktionsstätten in den USA und Asien. Hier stellt sich die Frage, wie die einzelnen Geschäftseinheiten in einem ERP-System zusammenarbeiten wollen. Gibt es eine einheitliche ERP-Software für alle Geschäftseinheiten (Architektur 1)? Die ERP-Software müsste die gesetzlichen Anforderungen und regionalen Usanzen aller vier Standorte abdecken können. Oder arbeiten die Geschäftseinheiten in wichtigen zentralen Prozessen zusammen (z. B. in der Auftragsabwicklung und der Produktion), lokale Anforderungen werden jedoch durch vor Ort etablierte Systeme realisiert (Architektur 2)? Oder baut jede Niederlassung ihr eigenes System auf und man tauscht Daten über Schnittstellen aus (Architektur 3)?

Systemarchitektur-ERP-System

Genauso kann es innerhalb der Niederlassungen verschiedene Bereiche geben, sagen wir die Kunststoff-, die Metallverarbeitung und die Maschinenvermietung. Auch hier stellt sich die Frage nach der Systemarchitektur, der Schnittstellen und des Datenmodells (z. B. gemeinsamer oder getrennter Artikel-, Lieferanten-, Kundenstamm?).

Die Systemarchitektur beeinflusst Funktionsumfang und Qualität

Die Beantwortung der Fragen hat unmittelbaren Einfluss auf die Funktionalität und die Qualität des Systems. Die Auswertung von Kundendaten in einem übergreifenden ERP-System dürfte ungleich leichter sein als bei unterschiedlichen, regional ausgewählten ERP-Lösungen. Auch die Auftragsübergabe in ein Fremdsystem ist schwieriger als innerhalb einer ERP-Software. Umgekehrt kann die Einführung, das Anpassen, Testen und Erneuern von einzelnen Lösungen einfacher sein, je unabhängiger die Geschäftseinheiten aufgestellt sind.

Ähnliche Fragestellungen ergeben sich in viele Bereichen bezüglich der technischen Realisierung. Als Beispiel für den unmittelbaren Zusammenhang zwischen Systemarchitektur, Funktionsumfang und Qualität sei hier der Betrieb von mobilen Geräten genannt. Hierzu gibt es mehrere Lösungsansätze:

  • Daten in der Public-Cloud: Die Daten werden auf Infrastruktur ausserhalb der Firma gelagert. Die Anwender können die Daten nutzen und teilen. Sie werden vor dem Upload verschlüsselt. Nicht möglich ist es jedoch, die Daten von einem mobilen Gerät zu löschen (z. B. wenn es verloren geht).
  • Über Enterprise Mobility Management (EMM) kann definiert werden, wo welche Daten und Dienste für mobile Geräte verfügbar sein sollen. Auch das Löschen von Daten auf externen Geräten ist möglich allerdings nur, wenn diese über das EMM verwaltet werden. Für alle anderen mobilen Geräte werden separate Zugangslösungen benötigt. Zudem ist das Teilen von Daten nicht ohne Weiteres möglich.
  • Daten in einer selber betriebenen Private-Cloud bleiben im Unternehmen. Der Zugang ist für Anwender von extern leicht möglich, die Gefahr, dass Daten nach aussen verschoben werden gering. Zudem wird der Zugriff geloggt.

Das Beispiel zeigt, dass eine Anforderung (Daten sollen von extern über mobile Geräte bearbeitet werden können) über verschiedene Systemarchitekturen umgesetzt werden kann. Die Umsetzung hat unmittelbaren Einfluss auf die Funktionalität (Teilen, Löschen) und die Qualität (Sicherheit, Zugriff) des Systems.

Von Best Practice-Ansätzen und Fragebogenberatern

Welche die für eine Organisation passende Systemarchitektur ist, lässt sich nicht pauschal beantworten. Die Fragestellungen in dem Zusammenhang sind vielfältig, die Antworten weitreichend. Was für die eine Organisation passt, kann für andere unzureichend sein. Damit ist auch klar, dass Best-Practice-Ansätze oder ein Fragebogen nicht ausreichen, um eine Systemarchitektur abschliessend zu definieren. Eine gute Praxis ist allerdings, sich frühzeitig und umfassend mit der Systemarchitektur auseinanderzusetzen, unter Einbezug der Fachleute aus der IT. Denn ERP-Einführungen sind nicht nur, aber auch IT-Projekte 😉

Veröffentlicht am 24. Mai 2016

Kommentar schreiben