Hybride Integrationsstrategie für S/4 Hana

Diesmal war es ein global agierender Maschinenbauer, mit bekanntem Bild: In den USA ist die EDI-Integration an einen Provider ausgelagert, in Europa auf SAP Process Integration und in Asien mit einer lokalen Middleware-Plattform implementiert, die noch auf einem Windows-NT-Rechner läuft.

Für E-Invoicing Spanien wurde SAP Cloud Platform Integration, das eDocument Framework und SAP Application Interface Framework eingeführt. Elster und das Lager in Österreich sind über den SAP Business Connector angebunden.

Und die Cloud-Anwendungen? Da wird es nochmal deutlich komplexer. Über die Anforderungen der neuen Datenschutz- Grundverordnung (DSGVO) und die Disaster Recovery wollte dann niemand mehr sprechen. Verständlich.

Rechtzeitige Definition von Integration Guidelines

Heterogen gewachsen und unübersichtlich sind die Systemlandschaften fast überall. Klar ist aber auch: Wer demnächst auf S/4 Hana umsteigen will, benötigt eine One Digital Enterprise Integration Strategy. Und die gilt es schon im Vorfeld der Transition zu erarbeiten.

Zentrale Themen dabei: Schnittstellen-Governance, In- und Outsourcing bestimmter Themenkomplexe, zukünftige Integrationsplattformen und deren Einsatzbereiche, Systemarchitektur und Sicherheitsanforderungen, Integrationsrichtlinien und Betrieb (Monitoring, Alerting, Change Management, Regressionstests).

Meist beginnen wir im ersten Schritt mit einer Ist-Analyse der aktuellen Systemlandschaft. In einem weiteren Workshop findet ein Brainstorming mit Blick auf mögliche Automatisierungs- und Verbesserungspotenziale statt.

Zudem werden künftige Anforderungen dokumentiert. In der dritten Projektphase kategorisieren wir die Schnittstellenanforderungen auf Basis der SAP-Integration-Advisor-Methodik (ISA-M). Dieses Vorgehen unterscheidet nach der Integration auf UI-, Anwendungs- und Datenebene.

In der vierten Projektphase geht es um die Grundlagen für die neue Integrationsstrategie. Welche Technologien, Nachrichtenformate, Protokolle und Integrationsplattformen sollen künftig eingesetzt werden.

Auf dieser Grundlage werden die Integration Guidelines definiert. Diese Richtlinien gilt es dann bei der Auswahl von Cloud-Anwendungen und externen Dienstleistern zu beachten.

Die neue Rolle des Integration Competence Centers

Ein weiteres Arbeitspaket ist die künftige IT-interne Organisation. Mittlerweile haben sich in vielen Firmen Integration Competence Center etabliert. Diesen Spezialabteilungen sollten Integrationsarchitekten angehören, sie sollten aber auch über das technische Implementierungs-Know-how für die relevanten Integrationsplattformen und -technologien verfügen. Und: Das Kompetenzzentrum sollte sich nicht auf die reine Middleware- und technische Ebene beschränken!

Zwei konkrete Fälle zeigen, wie es in der Praxis aussehen kann: Ein Automobilzulieferer hat vor dem globalen ERP-Template-Projekt entschieden, die EDI-Integration Richtung Kunde wieder selbst zu betreiben.

So lässt es sich flexibler auf neue Anforderungen reagieren. Außerdem wird so eine engere Abstimmung mit den Fachbereichen möglich. Zudem stand die Ablösung einer alten, proprietären Middleware-Plattform bevor.

Hier haben die Verantwortlichen in einem Vorprojekt entsprechende Integrationsrichtlinien, ein zentrales Schnittstellenregister und eine Wellenplanung für die Migration nach SAP-Process-Orchestra­tion definiert. Parallel dazu wurde die IT-interne Organisation aufgebaut.

Ein weiterer Kunde aus der Chemieindustrie hat zunächst alle bisherigen Schnittstellen und künftigen Cloud-Anforderungen sauber aufgelistet. Dann hat er sich für die SAP Cloud Platform Integration und das SAP Application Interface Framework entschieden.

So hat man die Basis für die komplexen Anforderungen eines sich anschließenden globalen CRM-Projekts geschaffen. Wir sammeln weiter Best-Practice-Beispiele. Fortsetzung folgt.