SAP S/4 HANA – Paths to a Successful Transition

Introduction to SAP S/4 HanaSAP S/4 HANA – Paths to a Successful Transition

Since its implementation on a massive scale starting in the 1990’s, SAP’s ERP Central Component has certainly come of age.  It’s been effective at giving businesses a centralized view of their critical functions, and while it’s never been an easy task to manage all of that complexity, few would argue against the claim that the application suite continues to represent the top tier in mission critical ERP.

S/4 HANA, the latest iteration in the evolution of the core product, is a completely new code line, marketed as a way to “run simple”. As advertised by SAP, “This is a move that can bring real competitive advantages to your business. With its simplified architecture, real-time analysis, and performance improvements, SAP S/4HANA will enable you to achieve more – from time efficiency to faster ROI.”(Ezra, 2019) The main area of improvement is in financials. According to Christopher Carter, CEO of Approyo, “The revenue recognition alone is a game changer in financials, and the hyperability for analytics is fantastic. ” (Parizio, 2019)

To time box the move to S/4, SAP has issued an end of support date of 2025 for the ECC 6.0 version of the core ERP module, while also defining similarly near-term support terminations for running SAP on the Microsoft Windows operating system or any non-HANA database (SAP, 2019). To clients with 10-15 years of history with the legacy ECC 6.0 product, the prospect of performing what is essentially a re-implementation, without new breakthrough functionality, can be off-putting in the extreme. We have heard that very sentiment first hand and this reluctance is further supported in a recent (April 2019) ASUG study:

Enterprises don’t seem as ready to move to SAP S/4HANA as SAP expects, despite the SAP ECC sunset date of 2025 and the continuous announcement of new features. Recently available numbers from SAP indicate that, in Q4 2018, 10,500 customers purchased S/4HANA licenses. Yet compared to SAP’s approximately 425,000 customers, that doesn’t seem like a lot. And that number doesn’t account for customers who may have purchased licenses but are still grappling with implementation questions.

According to ASUG’s 2019 State of the Community Study, more than half of businesses plan to adopt SAP S/4HANA. However, the same study found that only 16% of customers are live. One of the top reasons why respondents are waiting on S/4HANA migration is that they are waiting for the product to mature so that it can fulfill the same needs that their existing systems already do. (Parizio, 2019)

Whether or not the stated deadline is as firm as SAP would suggest, we nonetheless believe that this reluctance to adopt will be slowly overcome. Expect to see this trend accelerate in the coming two to three years as ever increasing feature sets become available within S/4 and the looming SAP support cliffs mentioned above draw near.

Regardless of one’s perspective on the currently available product suites, our intention here is to provide a review of the various paths an organization may take when evaluating the move to S/4 and highlight some of the benefits and risks associated with each. As a company with a new approach to mission critical, our recommendations are tailored to allow our clients to make the required jump without sacrificing the scale, resilience, and efficiencies inherent within apiphani’s managed services offering: SAP domain experts, completely managed public/private/hybrid cloud platforming options, and proprietary Deep Automation and machine learning powered incident avoidance technologies.

Evolving to S/4 HANA

There are three primary options which may be considered when moving to S/4 HANA: A new implementation, a landscape transformation, and a system conversion. The choice depends upon the state of the organization’s existing ERP solution, the complexity of the business, budgetary constraints, and – most critically – the business requirements which have mandated the migration project.

New Implementation

It is of course possible to execute a new “greenfield” implementation of S/4. Although far less attractive to clients with a medium to long term history on ECC 6.0, it may be the right answer for both new implementations and older systems with outdated configuration that no longer models the current state of the business organization or its processes. Sometimes a fresh start allows for a better future, and as we discuss below, this is not so drastically set apart from other options as one would assume.

Landscape Transformation

Another option is to perform a Landscape Transformation (LT). Sometimes referred to as a Consolidation or Selective Data Transition, this approach is meant to support “Customers who want to consolidate their landscape or carve out selected entities or processes into an existing SAP S/4HANA system or Customer-specific migration project re-using standard migration content…” (Chauhan, 2017) Here we are performing a table by table migration where the focus is not on transitioning an entire system, but rather on selecting which entities we wish to extract and move to the SAP S/4HANA platform. This option will be attractive to larger enterprises that have grown through acquisition and have disparate SAP landscapes on various versions and OS/DB combinations that they wish to combine.

Conversion

A system conversion, also referred to as a “Brownfield” implementation, is the approach that is most often recommended for existing ECC 6.0 implementations. This process is well documented within the S/4 HANA conversion guide, and involves moving the back-end SAP application release to Netweaver 7.5, installing and populating the HANA database, implementing the Fiori UX, and finally migrating the data. The transition is fully supported by the SUM tool, a mature utility that has been used to perform SAP upgrades for many years. There are several conversion paths available.

Conversion Paths

• An ECC 6.0 system running on any supported database (ex: Oracle, MSSQL, DB2) can be converted to SAP S/4 HANA directly. This presupposes the system is already on Unicode and is deployed on the AS ABAP stack. Dual stacks are no longer supported on S/4.
• The database on an ECC 6.0 system can be migrated from any supported legacy database, e.g. Oracle, MSSQL, DB2, etc. to HANA. This configuration is often referred to as “Suite on HANA” or simply SoH. In addition to the performance gains associated with running on an in-memory database, adopters of this approach will be able to leverage the new functionality of S/4 HANA Finance (formerly Simple Finance) which can be configured as an add-on. Excluding Finance, this path essentially allows the business to make a more incremental move to S/4 HANA by splitting the database and application migrations into separate initiatives. This option makes sense if you are not yet ready to adopt to the new S/4HANA code-line and new S/4HANA data model, but you are facing a near term contract renewal date, support is coming to an end for a legacy database vendor within your SAP landscape, or you have  legacy hardware support contracts you would like to dispense with in the short term (Meleegy, 2018). In these situations, moving the database first might well be the most economically viable next step. A note of caution: SoH is not the same animal as S/4HANA. As you are technically running “ECC powered by HANA” in this scenario, you will ostensibly be subject to the 2025 End of Support deadline along with any other ECC implementation running on top of a legacy database (See SAP Note 1648480 – “Maintenance for SAP Business Suite 7 Software” for more details). The key take away here is that SoH is a step on the path to S/4, not a destination in and of itself.

apiphani would support either of these options, with stability throughout the process being of paramount importance.

Simplifying the Way Forward

There are already stories in the press about failed S/4 HANA transformations. In his presentation “5 Steps to Upgrade from Legacy SAP to S/4 HANA” Third Stage Consulting CEO Eric Kimberling underscores the importance of considering questions of business culture and process before embarking on this journey, that is:

1. Understand what went well with your company’s original ERP implementation. Ensure these factors are mapped into the S/4 solution.
2. Understand that S/4 HANA is a complete re-write of the software and so it does not yet have the maturity of the legacy product suite
3. When deciding between the On-premise and Cloud deployment options, understand your needs around flexibility. The Cloud version is less flexible than the on-premise version.
4. Understand how big of a change are you willing to make – S/4 does have breakthrough functions around Machine Learning and Artificial Intelligence. Is your organization ready to grow into these?
5. Understand the impact on people – S/4 is a bigger leap than many people recognize (Kimberling, 2019)

Simply put, look before you leap. Think about organizational readiness, think about quality assurance and testing.

There are some tactical steps that can smooth the transition as well. Business disruption can be minimized if, before embarking on the journey, the business performs (1) a clean-up/archival of any unneeded historical data, and (2) an evaluation and winnowing out of any deprecated custom code (“Z” programs or transactions). The latter will make the final step of adopting custom code to SAP HANA much simpler (see below). There are many products available that assist in the management of this aspect of the project. The evaluation of these is beyond the scope of this document, but apiphani does partner with providers who offer these services.

Figure 01: Custom Code Activities: SAP ERP vs. SAP S/4 HANA (Hamm, 2016)

apiphani will support both of the above efforts from a technical perspective and also provides architectural guidance, including design for performance and design for resilience and stability, as part of its base offering. The SAP Regional Implementation Group (RIG) also provides architectural guidance services, and lastly, there is a readiness check available via the SAP S/4 HANA value assurance packages.

Cloud Hosted vs S/4 HANA Cloud

In concert with the move to S/4, it makes sense to evaluate the end state, or “day 2”, support model.   Due to the technical effort required and the physical relocation of data, on premise clients that are internally supported may wish to consider this an opportunity to migrate to the cloud, either independently or with the support of a partner such as apiphani. S/4 HANA can be consumed in one of two flavors; the S/4 HANA Cloud or what SAP broadly refers to as “On-Premise”. Note that even though many SAP hosting partners use the public cloud as a platform, they will make use of the on-premise SAP licenses procured by our clients. The table below summarizes the differences.

Figure 02: Main differences between on-premise and cloud editions (SAP S/4HANA: On-premise vs. Managed Cloud. Which is right for your Enterprise?, 2018)

S/4 HANA Cloud

SAP offers its own SaaS offering for S/4 HANA called the S/4 HANA cloud. This flavor of deployment involves SAP taking over complete control of the infrastructure.  It offers a subset of ECC 6.0 functionality, although this subset does appear to be growing over time. Back-end integrations to Ariba and SAP Concur are also provided. With a controlled subset of functionality available and minimal customizing allowed, SAP can be much more “agile” with this approach and offer additional functionality and an ease of deployment that is not possible with a traditional model. As part of this solution, SAP will upgrade the application four times per year and they will set the schedule. Although the MTE solution provides some automated testing tools, adopters should plan on streamlining their regression testing models accordingly.

The appeal of SaaS model is undeniable for both SAP and a certain subset of their clients. We see this being particularly attractive to smaller and mid-sized companies who would like to avoid the complexities and overhead that come with more a traditional architecture. Certainly, if you are planning a greenfield implementation of S/4 this would catch your attention. However; organizations considering this path will need to weigh the benefits against their long-term strategy and ensure that SAP’s functionality roadmap matches their own as again, customization of the core is not allowed in this model.

SAP offers two approaches to adopt their SaaS model; an “all-in” approach that brings the client into the multitenant cloud (MTE), and a single tenant option (STE) that is meant as a way to ramp clients into their cloud offering by first adopting many of the benefits of that model, and it’s inherent limitations, before fully embracing the multitenant SaaS architecture. This allows companies with functionality not yet available on the S/4 HANA Cloud to effectively migrate to a platform tailored for future migration. The upgrade schedule is far less rigorous and some custom configuration is allowed in this model, as long as the core is kept clean. For example, it is not allowed to extend an SAP core table, but it is possible to create separate tables of your own within the customer namespace. Any changes made to the core would not be portable. The STE solution is not a viable option for those organizations unable to strictly enforce process discipline. Where upgrade cadence and configuration changes are not possible in the MTE solution, much of the responsibility for keeping the application “clean” and properly patched is left largely to the client with STE.

Partner Hosted Cloud

We believe that the S/4 HANA cloud is a solid solution for many entities and expect SAP to continue to grow the functionality on offer. That said it is not, and may never be, for everyone. The S/4 HANA Cloud option is certainly less attractive if you have an industry solution that hasn’t been incorporated as yet, e.g. Oil and Gas, utilize complex multi-ledger functionality, and/or if you have customization that you wish to retain.  By staying with on-premise licensing, but working with the right provider to leverage the benefits of the public cloud platform, clients can retain a measure of control over their environments while still seeing many of the benefits typically associated with a SaaS offering.

A Partner Hosted Cloud solution is preferred if

• Full Spectrum ECC 6.0 functionality is required
• Uptime requirements for the application are above 99.9% (or about 40 minutes of unplanned downtime per month)
• Specific Security/Compliance requirements
• Compliance with an as yet unavailable industry specific business processes, i.e., an unsupported industry solution is deployed
• The company has well established business processes integrated into ECC 6.0 that they do not want to change

It should be noted that this model also gives clients “one throat to choke”. Providers front the infrastructure, maintain partnership agreements with the appropriate operating system and monitoring tool vendors, and coordinate with SAP on all functional and technical issues. What has been lacking in this model over the course of the past decade or so has been consistent delivery and the ability to scale operations as business and client demands increase.

Conclusion – Current Trending and apiphani’s Position

Net-net, the decision to move to S/4 must be justified at the business level, and it is clear that SAP has some way to go in order to convince its clients that the value is there, deadline or no. The technical decision as to which path to take should be clear by reviewing the business requirements as described previously. The question of cloud adoption as part of this effort will depend on the degree of customization required to support the business, what level of integration with other systems in the ecosystem is needed, and if the business and IT organizations can stand the pace of 4x upgrades per year. The security posture and downtime tolerance of the organization will also have a place in the conversation.

apiphani has always seen value in the close technical management of an SAP system, from the infrastructure up through the operating system, and finally at the database and SAP basis layers. We feel this is the best way to engineer a stable experience for the business users of an SAP system at the application layer, which is really the only place where it matters. This is the guiding principle behind the design of our tools, our use of machine learning and Deep Automation, our platforming choices, and our hiring decisions.  It is therefore perhaps not surprising that, for most cases, we believe outcomes can be better managed by adopting the on-premise licensing model. We are not alone in this, however.

Per the Parizio article, “Most customers, particularly those in complex manufacturing and oil and gas, would avoid the cloud version of S/4HANA because the ability to customize the software is limited, according to Nguyen. While SAP offers the option to build extensions on the SAP Cloud Platform to address this shortfall, that also means companies will need to hire more developers with cloud skills. On the other hand, to maintain S/4HANA on-premises, they can train existing developers on S/4HANA, he noted. This learning curve appears to be much less steep.”

So, while we have little doubt that SAP will continue to provide a consistent SaaS platform, there is no question that to adopt this approach their clients must, by definition, sacrifice a certain amount of flexibility and control. Nor does this SaaS model address the need for enterprises to manage their ancillary applications. Many AMS providers include the management of these workloads as part of their core offering, keeping a focus on these as an integral component of the landscape.

We believe that through a unique combination of technology and talent we have effectively cracked the “quality at scale” code that has long been the Achilles heel of application managed services. Therefore, we provide a compelling answer for enterprises in search of a solution that retains the benefits of an on-prem model while avoiding the pitfalls so frequently associated with it.

apiphani looks forward to continuing this journey with its clients in the coming years and to keeping this conversation alive. As we embark on what is undoubtedly a significant shift in the way mission critical applications are deployed and managed, we hope to engage with the community to help support enterprises and service providers alike. Our mission is to redefine how tier one applications are supported, to use all of the tools at our disposal in order to ensure that we are providing tangible value to our clients and to the wider SAP ecosystem. We sincerely appreciate the time you have invested in reading this paper and welcome any constructive feedback you may have regarding the contents herein.

References

AG, S. (2019, October 21). 1648480 – Maintenance for SAP Business Suite 7 Software including SAP NetWeaver. Retrieved from SAP Support Launchpad

Chauhan, J. (2017, July 17). Converting to SAP S/4HANA: technical options. Retrieved from SAP Community Blogs

DAELE, R. V. (2017, August 28). Question on Support Lifecycle for Suite on HANA. Retrieved from answers.sap.com

Denecken, S. (2019, October 13). Where to find the latest information on running a successful system conversion to SAP S/4HANA. Retrieved from SAP Community Blogs

Ezra, Z. (2019, June 25). SAP S/4HANA Cloud vs. On-Premise. Retrieved from Panaya Blogs

Gupta, R. P. (2018, November 10). S/4 HANA On-Premise Vs S/4 HANA Cloud. Retrieved from SAP Community Blogs

Hamm, R. (2016, November 2). SAP S/4HANA System Conversion – At a glance. Retrieved from SAP Community Blogs

Kimberling, E. (2019, January 23). 5 Steps to Upgrade from Legacy SAP to S/4 HANA. Retrieved from Third Stage Consulting YouTube Channel

Meleegy, A. E. (2018, November 14). Is There Value in Moving to Suite-on-Hana First Prior to S/4HANA. Retrieved from SAP Community Blogs

Parizio, C. (2019, April 2). SAP S/4HANA Cloud vs. on-premises — benefits, limitations, adoption. Retrieved from Techtarget Search SAP

SAP S/4HANA: On-premise vs. Managed Cloud. Which is right for your Enterprise? (2018, May 28). Retrieved from Savantis

SAP, A. (2019). SAP Release Strategy. NA: SAP AG. Retrieved from SAP Support

Saran, C. (2018, August 21). The risk of upgrading to S/4 Hana. ComputerWeekly.com.

Smith, M. (2018, May 15). Is SAP’s 2025 Deadline Real? . Retrieved from Computer Business Review (CBR)

Snapp, S. (2019, April 5). A Comparison of SAP HEC with Virtustream Versus AWS. Retrieved from Brightwork Research SaaS Economy