Why a S/4 HANA project should be a business transformation?
With the sunset of SAP ERP Version ECC in 2027 currently the SAP community is in uproar. The new release featured by SAP is well known as S/4HANA - on premise or cloud. During the development SAP did several things quite well: they are faced with disruptive events. set-up a design and analysis phase, and reviewed their former software-solutions. They analyzed what was good, what was less good and what could be done in a better way.
And yet the resulting product S/4HANA drives SAP customers in the same way. Cloud, social media, mobility and in-memory computing are modern technology developments that have transformed workflows, business models, and overall business strategies. Although this technology revolution is putting pressure on IT organizations, its effects go beyond IT. Investors, regulators and financiers all expect high levels of transparency into companies' financial status, pushing CEOs to adapt to change as well.
These new technologies build up in S/4HANA unlock new opportunities, evolve business processes and can solve previously intractable challenges. Organizations can make a leap forward - but be aware of the challenge.
What happend to grown ECC systems?
Todays system-landscapes are grown over years with different demands to cover. A lot of companies are nowadays understand that those investments had to be made but for future demands investments are more vulnerable. Today processes need to be standard but also flexible. Well this is also valid for processes in e.g. SAP ECC 6.0 - and as a result you find in nearly every ECC a customizations (also known as modifications): custom software changes the ERP system's inner workings fundamentally. ECC customization generally involves changing the ABAP code that drives the core system's functional behavior. But we all know problems can arise if SAP subsequently makes any changes to the software. Ok - so let's take User-Exits or business add-ins provided by SAP...
SAP provides several standard-processes in ECC and it's successor S/4HANA. But industry business practices are most certainly a starting point for specialized functionality. For example for construction companies it is necessary to use software that can accommodate processes such as purchasing, sales and invoicing, and project management. Those needs of industry specific solutions drove SAP to launch its Industry cloud program several years ago.
Nowadays SAP and third parties provide these types of specialized capabilities through Industry Cloud solutions: software for automotive companies; engineering, construction and operations; consumer products; industrial machinery and components; professional services; retail; and utilities
SAP Intelligent Enterprise
Challenges of Integration today
Based on our experience over the years, it is very difficult to make a business case with a high ROI solely based on technology promises. In the case of SAP S/4HANA, higher speeds and new interfaces alone are only of limited benefit to businesses.
Mostly you get recommendations to not just take IT aspects into consideration for your own SAP S/4HANA strategy. In order to gain a strong return on investment from SAP S/4HANA, it is also recommended that you incorporate process improvements. But improvements also come with new details in technical opportunities - which than drives IT strategy.
SAP calls this strategy outcome 'The Intelligent Enterprise'. An intelligent enterprise has one topic in front - integrated business processes; an 'Integrated Enterprise'.
This integration approach breaks up the siloed IT landscapes and sets up a holistic integration of data, technology and business processes. This does speed up innovation and pushes down the effort of integration. It also gives the opportunity of real-time insights and clearly improves operations.
A lot of customer integration landscapes are typically tightly coupled with various point to point connections. While not being generally bad at all, there are certain downsides to this such as a lack of a central repository. As each scenario tends to be highly individual, the amount of reusability is often relatively low. Also, the knowledge on how to integrate certain systems often remains in the head of individual experts on that matter which could also often lead to a landscape which is not properly governed and every experts does the integration which he deemed the most appropriate be it the coding on the sender side, the receiver side, the development of a custom csv processing tool etc.
typical integration scenario
Whats new in the SAP S/4HANA Integration world?
SAP S/4 HANA offers many new ways to integrate your systems. But do you know them already and thought about how to use them? More than ones I also caught myself in sticking to the “old” and maybe also often proven ways like using IDoc and RFC calls, but what is available in addition and what integration scenarios can be achieved combining SAP S/4HANA with SAP BTP Services in a side-by-side scenario?
SAP S/4HANA is the further development of SAP ERP and is delivered with comprehensive functionality in three variants (editions):
- SAP S/4HANA on-premise version
- SAP S/4HANA Cloud (Private Edition)
- SAP S/4HANA Cloud
From an integration perspective SAP S/4HANA Cloud is to a certain extend limited in functionality compared to the on-premise solution, especially with regard to extensibility through customer-specific ABAP programs and the use of self-developed and some standard interfaces. Many industry-specific functions are also missing, so large companies (especially in the manufacturing sector) often opt for the on-premise version. However, with the latest installment of Embedded Steampunk and the possibility for ABAP development directly on the SAP S/4 HANA cloud stack, this constraint seems to be lifted for most customers.
In the past, SAP customers could extensively extend their systems and add many of their own functionalities. Now with the mantra of a “Clean Core Philosophy”, the extensibility of SAP S/4HANA should mainly take place in SAP BTP and is supported by a software development kit (SAP Cloud SDK). This is especially true for decoupled extension scenarios.
Modern SAP landscape with Digital Core and BTP Services
Extensions can be divided into in-app extensibility and side-by-side extensibility. In-app extensions takes place within the system itself and include objects such as:
- Key User extensibility covers the adjustments in regard to the customization of the user interfaces (show/hide/arrange), creation of custom fields, custom logic to a certain extend and the creation of forms and reports
- Classic extensibility which can be seen as the typical adjustments also done in an on-premise SAP R3 world and cover the customization of User Exits, BADIS etc.
More extensive developments, such as completely new user interfaces and the creation of own APPs, as well as the integration to other SAP or NON-SAP applications and systems takes place as side-by-side enhancements in SAP BTP.
New Integration Technologies
From an integration standpoint in SAP S/4HANA the known technologies like RFC, BAPI, ALE IDOC etc. are still available. Lets call them Legacy integration technologies. And of course, the underlying database structure in SAP S/4 has changed here and there and during a conversion from R3 to S/4HANA the usage must be tested and verified but they are still available. However, to be frank this only applies to the On-Premise & private Cloud version of SAP S/4HANA.
Looking into the new technologies of SAP S/4HANA, SAP is increasingly trying to push the dedicated APIs for SOAP Webservices and Rest/OData Services, Business events and CDS Views, which are also used in combination with the SAP BTP for the side-by-side extensibility. Let’s take a closer look at each one of them.
Comparison og lagacy and strategic integration technologies
APIs
SAP provides a list of documented and available standard APIs not only for SAP S/4HANA but also for different SAP applications like Successfactors, Ariba etc. These are based on standards such as REST, OData and SOAP. They can then either be used to create you own custom apps/logic with the services of the SAP Extension Suite or to integrate your SAP system with other SAP or NON-SAP systems using the tservices of the SAP Integration Suite.
Business Events
Events that can be triggered and processed within SAP applications. Such events are typically provided via messages in queues and can thus be integrated into subsequent processing. A typical business event might be the creation of a sales order in your SAP S/4 HANA system which then creates the event message. This message can then be consumed via an Event Broker through MQTT or AMQP.
CDS Views
CDS Views describe a database view that provides access to SAP systems based on the SAP HANA database. In terms of integration CDS Views can be exposed via the OData protocol to allow external APPs to call specific data.
Challenges in the future in the Integration area
Fun note from SAP Global Partner Summit a couple of years ago given by a SAP Executive Board Member: 'We want to be best of breed & best of sweet. To be best of sweet the integration of components is the key.' That said at a partner summit sums it up: integrate the partner intelligence into the SAP world. Partnering opens up SAP solutions to a broad range of technical integration possibilities - but also to the aspect on how to best serve customers.
SAP currently offers solutions that cover the complete enterprise - giving the opportunity by adding value by e.g. hyperscaler-services: AWS, Azure, GCP etc.
This companies are well known for their disruptive innovations - but innovation is the key. Opening the world of SAP to open-standards is giving customers the oppurtunity to seamlessly integrate new technologies such as APIs, IoT-scenarios, data-analytics - just to stay at the surface of possibilities.
Let's take a look at some possible use cases:
Order Creation in SAP Backend:
Taking a simple scenario in variant A with direct peer-to-peer integration where the external client A1 send data to the ECC system A2. In this scenario you would normally use a provided standard interface in the SAP systems like the ORDERS Idoc, an RFC call or even the Odata or SOAP services of the SAP S/4 HANA system, but that would mean that sender system would have to adapt the protocol and message format of the receiving system. What would that mean from an integration standpoint? Frankly, that would be of course the easiest and probably also cheapest implementation method. But of course, it comes with certain downsides such as:
- Strong coupling of systems through proprietary interfaces.
- Usually P2P connection, no reuse, 1-N or M-N topologies can hardly be mapped.
- Reduction of flexibility: Interchangeability of one of the systems is usually not possible.
- Limited possibility to realize individual requirements, functional as well as non-functional.
- Vendor dependency in the system network.
Variant B would use the integration capabilities of SAP Integration Suite in a side-by-side manner. In this scenario each side can remain without further adjustment and could rely on its own proprietary message format as well as communication adapter. The logic of the message processing would be handled within the SAP Integration Suite like message transformation, routing etc. Benefits of such an apporach would be:
- Support of multiple integration patterns
- High connectivity via different adaptors supporting different technologies, formats, protocols
- Centralized management services such as monitoring, security, persistence, error handling, transaction mgmt, etc.
- Strong routing and transformation tools & engine
- Integration logic (transformation, etc.) in the middleware
- Housekeeping in the middleware
However, this does not come without a cost. Leaving the cost aspect aside, this platform needs also to be managed and be well integrated in the overall integration governance process.
different options of use case implementation
API-fication of endpoints
Taking this scenario one step even further, why shouldn’t other systems use this order creation process as well? While the systems in variant B are decoupled via the Integration Suite and reusability is already improved as we can maybe use existing scripts and logic steps also for other scenarios, it is still focused on the integration of that one external client system.
Why not make it even more accessible from the outside?
Let’s assume the following scenario. In a heterogeneous system landscape with several SAP systems, but also non-SAP systems, data from different teams and possibly also subsidiaries is required from a central SAP systems, e.g.: FI or also HR data. For this purpose, different solutions with different technologies are always built between the systems, which are sometimes complex in their implementation and also have to be adapted and monitored again and again over their lifetime.
Typical interface are read accesses e.g. to master data or a status of orders as well as transactional or write accesses e.g. entry of orders.
One solution approach is that there should be a central access point for access, via which all relevant systems are technically accessible, including documentation of which data is queried and which accesses are offered. In this scenario, the SAP systems are always accessed centrally via the API gateway – SAP API Management as part of the SAP Integration Suite (possible exception: SAP to SAP integration and classic EDI), and individual point-to-point interfaces are no longer built.
APIs are documented in a developer portal and can be tested there. In the published APIs, SAP specifics (cryptic fields and process specifics) are abstracted so that developers do not have to learn them. The authentication to these APIs from external clients the Integration Authentication Service can be used connecting your Active Directory. For simple Get accesses from master data, the values are read from the cache without checking the backend again. Besides synchronous APIs also asynchronous APIs are offered with a call back API for the results of the processing.
possible solution diagram
Way to go: ISA-M
SAP provides a methodology to master all aforementioned challenges. It is called the 'Integration Solution Advisory Methodology (ISA-M).
ISA-M cycle
It utilizes a proven methodology for cloud and hybrid landscapes, which includes integration patterns, architectural blueprints, and best practices. The goal of ISA-M is to simplify integration and help enterprise architects to manage the complexity in their hybrid landscapes.
First you assess your integration strategy of your organization. You scope your integration domains and scope integration use case patterns (both technology-agnostic) and map those to integration technologies or services to define your hybrid integration platform.
ISA-M approach
You might define best practices for integration scenarios by creating architecture blueprints for relevant integration use case patterns. These document the scope and the interaction of integration technologies with business applications.
Once integration best practices have been defined, they can be rolled out throughout the company and beyond (to external integration developers). By doing so, project teams can develop interfaces in an agile manner, based on a clearly defined integration strategy.
This sounds to easy but you have to consider different factors of your organizations or customer context: general IT strategy, existing investments, skillsets of your staff and also the existing and future application landscape.
Want to get started?
Covering given topics in daily business allows me and my colleagues to offer precise guidance for your 'integration journey'. We use the SAP provided methodology and added additional value based on our experience e.g. executing the integration assessment, defining the integration strategy and for sure considering the implementation of the results. Our integration advisory journey focus strategies concerning application management too.
Integration advisory
What will be the future with a Modular ERP SAP landscape build by RISE with SAP?
A Modular (Cloud) ERP brings the necessary core functions across your lines of business in a comprehensive suite with the qualities in a modular way. There will be a Cloud ERP with flexible scope to streamline operations across organizational units in the future.
Evolution of SAP ERP
The business challenges and loosly coupled processes require a modular, composable and flexible ERP solution in the future with a smaller but clean core (e.g. for Finance) and an intelligent combination of (micro)services for other processes (e.g. Lead-to-Cash). This approach has some challenges, like a consistent document flow or an End2End monitoring of processes, but it seems to be the best option for organisations in a more complex and highly changing world. With a modular ERP there are still End2End processes for your end user. They should have the best possible UX (user experience) e.g. with a Central Fiori Launchpad (CFLP), but the processes will be supported by a set of different services.
Future implementation of a business process
All services must be built and operated on a stable and open platform e.g. the Business Technology Platform (BTP). Important platform capabilities are:
- a seamless user experience (Fiori, Central Fiori Launchpad)
- One central Inbox (Taskcenter)
- End-to-End business blueprints (EML, Best Practises)
- An Aligned Domain Model (Graph)
- Consistent Security and Identity Management (IAS, IDP, IAG)
- Cross Product Analytics (SAC & Data Warehouse)
- Open Integration based on Standard Content, flexible Governance, APIs, Events etc.
In a Modern ERP, the job of integration is to build intelligent solutions, e.g. the automated creation of sales orders from unstructured data.
Modern integration use case implementation
A significant amount of sales orders are still captured from email, fax, PDF or other unstructured format. To generate the sales order, internal sales representatives have to enter this data manually in the structured format as required by the system. Automated creation of Sales Orders from unstructured Data leverages a machine learning based recognition engine based on SAP’s Document Information Extraction service to extract content from an unstructured source format (email, pdf, fax, etc.) and creates a draft sales order autonomously.
Business Benefits
- Cost savings by reducing manual effort to create sales orders
- Improvement of data quality by sales order process automation
- Automation shifts effort towards better service quality
To be able to support such use cases, your SAP team should perform some tasks, like:
- Build an Integration Strategy
- Gain Knowledge in Integration Pattern, Cloud- and BTP capabilities, security strategy and available SaaS solutions on the market
- Create a Cloud-Ready mindset in your teams
- Keep talking to other people in and outside your organisation
- Try out new technologies and implement what helps for your use cases
These topics and ideas may be a big change compared to your way of working today? It may sound like "fancy stuff" when you have a stable On Premise ERP architecture running in production? But keep in mind, that there will be a lot of challenges in the future with new market players, disruptive technologies or solving the climate crisis. For these and more challenges you will be happy to have a Modern ERP with a modular, composable and flexible integration architecture. So I propose to start today: Perhaps with your S/4 HANA Transformation, RISE with SAP implementation or by building a modern integration platform to improve and secure your business.
Technology is only an enabler
In summary what does that all mean? Well, it means that a lot is possible in todays world. But, technology can only ever be the enabler for something new. The benefit comes when it is used in a pervasive strategy and underpinned by business processes.
If you want to get started today with your S/4HANA system the best advise is do not overthink. Do not do a big upfront design (of course this is needed up to a certain extend) but rather start with small integration scenarios where you can complete the implementation in one step. Specify less and implement smaller requirements more quickly in a small way. This helps you to get smaller achievements early on which helps you to get trust within your organization. Try to follow a more agile approach and build up MVPs (minimum viable products) to get feedback from the business early on. Because again, a fancy technical solution does not help anybody if the business be it internal or external partner gain nothing.
Your thoughts - Whats next?
I am quite curious about your experiences in given context. What are your lessons-learned on this subject? Where you started, what did work out properly - what doesn't? What is your feedback on these topics? Please add your comment shere or follow 573fd36af7aa44e9a1f43389f1641904 for upcoming blogs. Always ask your questions here and follow other posts on the topic.
Sources:
- SAP TechEd, DT105: "Explore the Modern, Modular, and Flexible Architecture of SAP S/4HANA", Stefan Batzdorf
- DSAG Technologietage: "SAP S/4HANA Architekturstrategie – Modern, Modular, Flexibel", Stefan Batzdorf
- SAP: Modular Cloud ERP - A New Way of Working
- SAP: RISE with SAP for Modular Cloud ERP- SAP S/4HANA Cloud
- SAP Managed Tags:
7 Comments
