.svg)
Warum die Modernisierung der Fertigung selten ein Komplettprojekt ist
In der IT der Fertigungsindustrie besteht die Versuchung, die Modernisierung als ein einziges ERP-Migrationsprojekt zu planen. Wählen Sie das neue System aus, legen Sie das Umstellungsdatum fest, migrieren Sie die Daten, schulen Sie die Teams, nehmen Sie das alte System außer Betrieb. Dieses Modell funktioniert in Präsentationen, versagt aber in Anlagen. Moderne Fertigungsbetriebe tolerieren selten das Risiko von Ausfällen, das ein vollständiger ERP-Ersatz mit sich bringt. Das umgebende Ökosystem aus Cloud-Anwendungen, Kundenportalen und Analysetools benötigt ebenfalls zuverlässige ERP-Daten, lange bevor eine Migration abgeschlossen sein kann.
Aus diesem Grund gehen die meisten Hersteller letztlich einen anderen Weg. Sie betreiben ihr veraltetes ERP weiter und verbinden gleichzeitig Cloud-Anwendungen über eine Integrationsschicht mit dem bestehenden System. Die Modernisierung erfolgt schrittweise, wobei die Integrationsschicht die Komplexität abfängt, die sonst in riskanten Migrationsprojekten stecken würde.
Veraltete ERPs enthalten die Geschäftslogik, auf die Hersteller nicht verzichten können
Der Grund, warum ältere ERPs weiterhin bestehen, ist nicht nur Nostalgie oder Budgetbeschränkungen. Es ist die angesammelte Geschäftslogik, die in ihnen steckt. Ein typisches ERP für die Fertigung enthält jahrzehntelange kundenspezifische Preisregeln, Produktionsabläufe, Lieferantenbedingungen, EDI-Flows und betriebliche Abhängigkeiten, die im Laufe der Zeit um das System herum entstanden sind. Der größte Teil dieser Logik wurde von Anfang an nie richtig dokumentiert.
Das macht einen Austausch riskant, und das ist im Voraus schwer zu beziffern. Ein übersichtlicher Umstellungsplan kann jedes Modul, jede Schnittstelle, jeden Bericht auflisten. Er kann nicht jeden undokumentierten Workaround auflisten, den ein Produktionsplaner vor sechs Jahren erstellt hat, um ein bestimmtes Lieferantenproblem zu beheben. Diese Workarounds sind wichtig, da sie zu betrieblichen Abhängigkeiten geworden sind, von denen das Unternehmen nichts weiß.
Das Ergebnis ist, dass ERP-Ersatzprojekte ihren tatsächlichen Umfang in der Regel erst während der Migration erkennen. Zu diesem Zeitpunkt läuft das Projekt bereits und die Kosten für einen Abbruch steigen von Woche zu Woche.
Was ist eine hybride Integrationsplattform?
Eine hybride Integrationsplattform ist eine Softwarekategorie, die On-Premise-Systeme über eine verwaltete Integrationsschicht mit Cloud-Anwendungen verbindet. Das Wort „Hybrid“ beschreibt die Architektur, die sie ermöglicht, bei der ältere Systeme, die in privaten Rechenzentren oder auf dedizierter Hardware betrieben werden, mit Cloud-Anwendungen, die in gemeinsam genutzten Umgebungen betrieben werden, koexistieren.
Für die Fertigung ist dies wichtig, da sich der Technologie-Stack selten an einem einzigen Ort befindet. Das ERP wird häufig On-Premise auf AS/400-, IBM i- oder älteren Windows- oder Unix-Infrastrukturen betrieben. Im Gegensatz dazu sind die Handelsplattform, das CRM und die Analyseumgebung in der Regel Cloud-nativ und verfügen jeweils über eine eigene Verbindungsmethode, ein eigenes Sicherheitsmodell und ein eigenes Datenformat.
Eine hybride Integrationsplattform kümmert sich um die Verbindungsmechanismen für all diese Bereiche, einschließlich API-Aufrufen, Dateiübertragungen, EDI-Nachrichten, Datenbankabfragen und ereignisgesteuerten Prozessen. Sie verwaltet auch die Transformation, Validierung und Überwachung von Daten während der Übertragung zwischen Systemen, sodass Cloud-Anwendungen ERP-Daten in Formaten erhalten, die sie tatsächlich nutzen können.
AS/400, IBM i und SAP ECC über eine Integrationsschicht mit Cloud-Apps verbinden
Die technische Herausforderung bei der Legacy-ERP-Integration liegt selten in einem einzigen Protokoll. Mainframe-Konnektivität, AS/400-Integration und SAP ECC-Integration haben jeweils ihre eigenen Konventionen. AS/400-Umgebungen stellen Daten in der Regel über DB2-Abfragen, Dateiübertragungen oder ältere nachrichtenbasierte Schnittstellen bereit. SAP ECC unterstützt in der Regel BAPIs, IDocs und RFC-Aufrufe. Andere Systeme basieren immer noch auf der MQ-Serie, FTP-basierten Datenaustausch oder proprietären Protokollen.
Eine Allzweck-Integrationsplattform als Service (iPaaS) verarbeitet all dies über eine einzige Konfigurationsschicht, sodass für jede einzelne Schicht kein benutzerdefinierter Code erforderlich ist. Das Alumio iPaaS unterstützt direkte Datenbankkonnektivität (MySQL, PostgreSQL, MSSQL), dateibasierten Austausch über FTP und SFTP, EDI-Standards (X12, EDIFACT), REST- und SOAP-APIs sowie SAP-spezifische API-Plugins, die ECC- und R/3-Endpunkte exponieren. Diese Bandbreite ist wichtig, da die meisten Hersteller mehrere Altsysteme integrieren müssen, die jeweils unterschiedliche Konnektivitätsanforderungen haben.
Pelican Products, ein US-amerikanischer Hersteller von Reiseschutzausrüstung mit 1.400 Mitarbeitern in 27 Ländern, integrierte sein lokales SAP ECC R/3 ERP mit Adobe Commerce durch das Alumio iPaaS. Das SAP-System dient weiterhin als Betriebsdatensatz für Finanzen, Inventar und Auftragsabwicklung, während Adobe Commerce die Kundenbetreuung übernimmt. Die beiden Systeme tauschen Echtzeitdaten über die Integrationsebene aus, wodurch die Finanz- und Inventarfehler behoben wurden, die bei der vorherigen Standalone-Installation verursacht wurden. Dieses Modell, bei dem das alte ERP an Ort und Stelle bleibt und die Cloud-Ebene durch Integration miteinander verbunden wird, gilt für die meisten Modernisierungsszenarien der Fertigung.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
