Abstract: When converting to S/4HANA, this blog article recommends a structured analysis of conversion systems and interfaces using the “Integration Solution Advisory Methodology (ISA-M)” in order to identify and solve potential problems at an early stage.

 

When converting to S/4HANA, it is obvious that you should also critically review your entire application landscape in order to streamline it as much as possible, purge it of unnecessary information flows that have grown up, standardize it across locations and thus simplify it. My recommendation is the following approach:

  1. Clarify the business and IT ownership for each peripheral system and interface (if this is not already crystal clear).
  2. Classify all peripheral systems and interfaces. Here’s an example:
    1. 3rd party system for communication specified by customers or authorities -> must be connected again
    2. 3rd party system unified across all sites, whose functionality is not available in S4/HANA -> must be reconnected
    3. 3rd party system unified across all sites, whose functionality may be available in S4/HANA -> check of replacement by S4/HANA
    4. 3rd party system used at only one location, whose functionality is not available in S4/HANA -> check of future unified (non-) use in the company
    5. 3rd party system used at only one location, whose functionality may be available in S4/HANA -> Check of future uniform (non-) use in the company or replacement by S4/HANA.
  3. Do a structured interface analysis to determine the target technologies / communication techniques for the remaining interfaces. SAP offers what I consider to be a very good coached approach for this: “Integration Solution Advisory Methodology (ISA-M)“. I would recommend to be coached by an ISA-M expert from SAP, because the possibilities that come along with S/4 HANA are so diverse that one is usually simply not aware of them and with coaching in the order of 5 – 10 md by specialists from SAP, one can generate an extremely large amount of added value for one’s future application and interface landscape.

conversion systems and interfaces

 

The future deployment model for the S/4 HANA system (cloud / on premise) and, if applicable, the choice of the appropriate hosting partner and its options also play an important role:

The following links provide information on what is available in SAP’s cloud solutions in terms of communication options (BAPIs and IDOCs):

In the cloud as on premise can use BAPI’s, Idocs from S4HANA and also the cloud API’s listed in the SAP API Hub at https://api.sap.com/.

Full integration is available for S4HANA Public Cloud, Ariba, SuccessFactors and OnPrem systems. Like a customer-owned on-premise system, you can extend and modify it as you see fit, including rendering data over SAP tables with your own custom interfaces (Read, Write). For the HEC STE, the same applies as above, with an important restriction: the SAP code must remain unchanged, i.e. customers cannot modify the SAP code. Exceptions to this are only available in the Private Edition (see BLOG 17).

Available BAPIs and Idocs for integration are documented in the following notes:
Available iDocs in S/4HANA Cloud for integration with SAP On Premise solutions.
Available BAPIs in the S/4HANA Cloud for integration with SAP On Premise solutions.
There is a good blog worth reviewing on STE implementation.

Unresolved and unresolved interface issues can quickly set a project back by weeks or months and blow the budget and schedule. Therefore, my recommendation is to solve them as completely as possible in a pre-project and to have both the current ERP environment model and the future one around the S/4 HANA ERP already defined and decided before the start of the project.