As we continue to build our experience with early adopter SAP S/4HANA migrations, and more broadly engage our customer base on their S/4HANA strategies, a clear migration path is emerging for those with complex and heavily customized ERP systems. 

Modern CIOs know that the future will be built on maximizing the use of standard commoditized (cheap) software while minimizing the use of custom, bespoke (expensive) software.  As our customers contemplate how they will use S/4HANA their objective is to dramatically simplify and standardize their SAP systems. That said, they must rationalize what to do with their current inventory of major software customizations that are heavily embedded in their day-to-day critical operations.  For our large customers, a ‘Greenfield’ ERP reimplementation is overwhelming for a number of reasons, including:

  • Business disruption due to massive change
  • Business risk in implementing the requisite change control processes
  • Financial challenges due to implementation expense and accelerated amortization
  • Current product gaps that will require re-creating custom software in a new architecture

The conventional ‘Brownfield’ migration is also potentially flawed as it requires a significant investment in migrating current ERP customizations to the S/4HANA architecture, essentially investing heavily in an approach that is not consistent with the organization’s future vision.   

As we work through this problem with leading organizations, we are finding a common architecture and approach that is consistent with the CIO’s future vision, while eliminating the major barriers to immediate and meaningful progress.   There is one basic premise - consider the digital ERP core and ERP customizations as two separate and distinct software stacks.  Thinking about the problem this way we come up with a different approach for each stack.

This diagram displays the separation of the system into the 2 logical stacks, core Cloud ERP and Customer Specific Customizations:

s4migrations

For the digital ERP core, the organization will do an all-out migration to S/4HANA adopting the new and improved processes, UI and feature sets like Leonardo.  While this is essentially a ‘Greenfield’ approach, SAP has mapped standard ERP features from ECC to S/4HANA minimizing the disruption to the business in this migration.  

For example, Executives should consider the following benefits of the S/4HANA finance solution:

  • One, unified platform for prediction, analytics, and transactions, eliminating data silos, enabling real-time analytics (vs. delayed with traditional BW), and embedded monitoring and controls.  This is about digitization and realization of the power of real-time data on-the-fly vs. in hindsight.
  • One universal journal for financial and managerial accounting, for current aggregations without losing the ability to dive into extreme granular transaction detail, and the avoidance of aggregation closing activities.  This is about knowing exactly what's happening in the business in real-time without the need for running a close.  In fact, you can think about this as being able to make period closure obsolete.  We can see where the business stands precisely at a real point in time whenever we want without going through monthly closure activities.  Historically, "closing the books" has focused on assembling aggregates and controlling data that can now be aggregated in real-time time and managed with real-time controls for accuracy.
  • For complex enterprises, centralizing finance with real-time full-depth data replication, enabling even complex organizations to realize the above enabled advantages from S/4.

SAP talks about these concepts in the context of the "digital boardroom".  Instead of arguing about accuracy and sources, the business should be able to focus on the bare facts the numbers show.  i.e. stop arguing about what you think you know and start taking action with real information.

For the customer specific customizations we take a different approach.  In the long run, many of these customizations may be phased out, subsumed into standard S/4HANA functionality or replaced with other commoditized software.  Our requirements here are to minimize investment while keeping this functionality interoperable and accessible from the digital S/4HANA core.  We also want to make sure this functionality is modular meaning that it exists in small, logical and discrete ‘chunks’ that can be replaced or shut down one at a time., leveraged across multiple systems and centrally managed.   The architectural solution to this problem exists today: we move the current SAP customizations out of ECC to microservices running on the HANA database.  With the architecture understood, the challenge becomes finding a process that gets us there reliably and efficiently.

The following diagram shows the inventory of the SAP customizations within the Microservices framework, with the plan to migrate the customization to standard functionality over time.

s4_migrations_edit

smartShift’s S/4 migration program can be thought of according to the diagram below:

  • Automatically extract the customizations (using smartShift’s platform)
  • Use the same smartShift platform to automatically transform these extracted customizations to micro-services on the platform of your choice
  • Leverage functionality of the S/4HANA core for standard processes and functions

s4migrationss

Finding a process that allows us to migrate the customizations to this new architecture efficiently with minimal risk is based on three principles:

  1. Do not perform a redesign of the customizations, rather ‘containerize’ them as they sit today.   SAP custom code is organized into objects today.  We can think of each object as a microservice and port them accordingly.  In the future, we may choose to consolidate and reorganize these objects, but in the interest of efficiency, we should minimize this in phase one.
  2. Use a standard, pre-built architecture to run these services rather than develop a custom approach.  HANA Cloud Platform and CloudFoundry represent two good options for pre-built architectures that can be leveraged for this purpose, eliminating the need for complex architectural work.
  3. Use automation to implement the required changes to make the code function.  In moving to microservices on HANA that will interoperate with S/4, there are a few categories of changes that are instantiated numerous times.  Examples include data model reference changes, SQL optimization and field changes like material number.  Making these changes cheaply and reliably with automation not only saves significant time and money, but eliminates the quality risk involved in performing the changes manually.

Applying these principles is the key to implementing manageable and affordable migration of the customizations, rather than something that looks like a massive project rewriting custom software.  At smartShift we have extensive experience in automating HANA upgrades of the world’s most complex SAP customizations as well as containerizing and re-deploying legacy systems as cloud-based micro-services.  We consistently deliver these programs in single-digit months as opposed to custom development programs that span years.   

Approaching the S/4HANA move with this framework provides SAP customers a progressive approach that is consistent with a future vision of cloud native software, is actionable and has no significant barriers to entry.  This approach also allows key resources and investments to be directed at the SAP digital core with customizations efficiently modularized and sequestered for future phase-out.  Finally, this approach combines the upside of conventional ‘Greenfield’ and ‘Brownfield’ approaches into a hybrid allowing SAP users to move forward immediately on SAP’s roadmap.