Hybrid integration strategy for S/4 Hana
This time it was a globally active machine manufacturer, with a familiar picture: In the USA, EDI integration is outsourced to a provider, in Europe to SAP Process Integration, and in Asia implemented with a local middleware platform still running on a Windows NT machine.
For e-invoicing Spain, SAP Cloud Platform Integration, the eDocument Framework and SAP Application Interface Framework were implemented. Elster and the warehouse in Austria are connected via SAP Business Connector.
And the cloud applications? That's where things get even more complex. No one wanted to talk about the requirements of the new data protection regulation (DSGVO) and disaster recovery. Understandably so.
Timely definition of integration guidelines
System landscapes have grown heterogeneously and are confusing almost everywhere. But it is also clear that anyone who wants to switch to S/4 Hana in the near future needs a One Digital Enterprise Integration Strategy. And this needs to be developed in advance of the transition.
Central topics here: interface governance, in- and outsourcing of certain topic complexes, future integration platforms and their areas of application, system architecture and security requirements, integration guidelines and operation (monitoring, alerting, change management, regression tests).
In the first step, we usually start with an as-is analysis of the current system landscape. In a further workshop, brainstorming takes place with a view to possible automation and improvement potentials.
In addition, future requirements are documented. In the third project phase, we categorize the interface requirements based on the SAP Integration Advisor Methodology (ISA-M). This approach differentiates between integration at the UI, application, and data levels.
The fourth project phase focuses on the foundations for the new integration strategy. Which technologies, message formats, protocols and integration platforms are to be used in the future.
The integration guidelines are defined on this basis. These guidelines must then be observed when selecting cloud applications and external service providers.
The new role of the Integration Competence Center
Another work package is the future internal IT organization. Integration competence centers have now been established in many companies. These special departments should include integration architects, but they should also have the technical implementation know-how for the relevant integration platforms and technologies. And: The competence center should not be limited to the pure middleware and technical level!
Two concrete cases show how it can look in practice: Before the global ERP template project, an automotive supplier decided to operate the EDI integration in the direction of the customer itself again.
This makes it possible to react more flexibly to new requirements. It also enables closer coordination with the business departments. In addition, the replacement of an old, proprietary middleware platform was imminent.
Here, those responsible defined appropriate integration guidelines, a central interface register and wave planning for the migration to SAP Process Orchestration in a preliminary project. In parallel, the internal IT organization was set up.
Another customer from the chemical industry first neatly listed all previous interfaces and future cloud requirements. Then he decided on SAP Cloud Platform Integration and the SAP Application Interface Framework.
This has created the basis for the complex requirements of a subsequent global CRM project. We continue to collect best practice examples. To be continued.
