Many organizations are currently struggling with the question what to do with S/4HANA. Should we migrate now, or is it better to wait and realize other initiatives first? And how does this relate to our ambitions on digital transformation and possible improvements on business and IT? There are many aspects to this topic and we therefore believe a structured approach to cover all relevant aspects will highly contribute to the successful realization of your transformation. In this article we will provide guidance on defining your S/4HANA Strategy & Roadmap.
Digital transformation has an increasing impact on all of us. Driven by technologies such as Big Data, Internet of Things, Cloud, mobile, robotics, artificial intelligence and machine learning there is an increasing connectivity between people, organizations and devices. Business processes will be further automated and new potential data flows will emerge, which can be used to get better insights for improved decision-making and business innovation.
Within this digital environment SAP is positioning their S/4HANA solution as the ‘digital core’ for the ‘digital organization’ or ‘Intelligent Enterprise’ and many organizations are currently facing the question when they should make the move to S/4HANA. Do it now or wait? And when the decision is taken to migrate, what is the scope and how can the migration be performed best? Answering these questions for your organization in a structured way, taking into account both a business and IT perspective, will highly influence the success of your migration to S/4HANA and the value it brings to your organization.
In this article we provide guidance on how to define your S/4HANA strategy including tooling that can be used along the way.
S/4HANA in a nutshell
Before diving into the S/4HANA Strategy methodology, let’s have a quick look at S/4HANA. Application vendors, such as SAP, have recognized that new technology was needed to better support organizations in a digital world. SAP’s answer to this is SAP HANA, a technology based on using an in-memory database and the possibilities this technology offers for a different method of storing, processing and using data in transactions and reports (OLTP and OLAP). The starting point is that data is handled much faster which benefits transactional processing (e.g. faster MRP) but also provides better insights (e.g. real-time reporting) and innovation (e.g. using IoT, machine learning). HANA was initially released in 2012 with a capability to accelerate reporting, but since then it has grown into an overall platform for the digital company including key components such SAP Fiori (new user interface), SAP Leonardo (digital innovation and business insights), S/4HANA (support for core ERP business processes) and other SAP products (integration with additional non-core processes). See Figure 1.
Figure 1. S/4HANA as the digital core for your digital enterprise (source: SAP). [Click on the image for a larger image]
S/4HANA can be seen as the successor to SAP ECC and provides the so-called ‘digital core’ to support your business processes. This core ERP functionality can be used in combination with other cloud-based applications for interaction and integration with external parties such as customers (such as C/4HANA) and suppliers (such as Ariba). S/4HANA is also available in a Cloud version (latest version 1902) next to the on-premise version (latest version 1809). Functionality is added in periodic releases.
Although many of the current SAP Business Suite functionalities are now available in S/4HANA (either optimized for HANA or made compatible with HANA), it is also possible to run the SAP Business Suite on HANA. In this way you can already get the first benefits of the HANA technology but plan the migration to S/4HANA (and related business improvements) at a later stage. It all depends on the specific business and IT context of your organization what strategy and roadmap to follow and what possible benefits you expect from a move to S/4HANA.
The need for an S/4HANA strategy
Defining your S/4HANA strategy is about focusing on the realization of value through S/4HANA given the context of your own business and IT environment. This means that you do not simply start with the actual migration and deployment and see what happens. It means that you take time to understand the current situation, set a clear vision how S/4HANA and related business improvements can add value and clearly define what activities need to be done related to design and preparation before actual migration will take place. Also taking into account that the decision to migrate to S/4HANA is typically taken against a background of cost reduction and keeping an existing (complex) SAP environment running.
In our view, one of the key enablers to create value through digital transformation and S/4HANA is the realization of a solid backbone with a standardized (OneCompany) and simplified business process landscape and application landscape. For successful delivery you need an end-2-end methodology with a clear focus on value, business improvement and technology realization supported by strong project- and change management. This end-2-end view starts with a clear S/4HANA strategy and roadmap. This is visualized in Figure 2.
Figure 2. End-2-end S/4HANA approach for value delivery through business improvement and technology realization. [Click on the image for a larger image]
It is key to create a solid foundation for your future process landscape and S/4HANA application landscape. In this way you are able to make the right choices based on a clear vision and define the steps needed to realize the expected value.
The rationale behind OneCompany ([Koot14]) is that you aim to increase value from your process landscape and application landscape by increasing the level of standardization and simplification across organizational entities: “we run as one”. From a process perspective this typically means the use of a common process template and from a technology perspective the use of a common S/4HANA system. Obviously not each organization will necessarily apply a full OneCompany approach. It may be that a common process template is used, but instead of running one single S/4HANA system for all entities (referred to as ‘shared’ scenario) each organizational entity is running the template in their own system (referred to as ‘replicated’ scenario). Also, a process template may be defined but only for a specific process scope (e.g. back- and mid-office processes). The extent to which OneCompany will be applied is a key part of defining your S/4HANA strategy and touches both upon the business and technology perspective.
A closer look at the S/4HANA strategy methodology
Let us zoom in on the Strategy & Roadmap part of the end-2-end S/4HANA methodology and show the key steps to perform to enable you to define your strategy. This is visualized in Figure 3. Obviously each step shown has a number of detailed activities embedded, for the sake of overview these are not shown in this article.
Figure 3. A closer look at the S/4HANA Strategy & Roadmap phase. [Click on the image for a larger image]
Key in this approach is that it shows the necessary activities from various perspectives that all play their role to define your S/4HANA strategy. These perspectives are as follows.
Value is at the heart of the methodology and these activities ensure that all decisions taken (related to your process and application landscape) are made from the starting point that it will add value; whatever this may be for your specific context. The key component is to understand the value drivers and define a clear business case that is updated each time you get new information during the strategy & roadmap phases. The business case is also used as part of stakeholder management and to get approval for the following steps. Value drivers can relate to financial benefits, including (IT) cost reductions, but also to less tangible benefits, such as lowering risk (e.g. by replacing legacy SAP) and increasing compliance. Where possible value drivers are quantified using data analytics. Typically tooling is used to support the analysis and quantify the benefits and costs.
Although an S/4HANA migration consists of many IT-related activities, it is in essence still about the best way to support your business processes and therefore not just an IT project. The key component of the business view is to understand what improvements can (and should) be made to your process landscape (standardization, harmonization and simplification) and how S/4HANA can contribute to this. These improvements are not necessarily done during an S/4HANA migration, but can also be done before the migration (as a preparation project) or after the migration (as an improvement project). Timing is part of your S/4HANA strategy and highly relates to the preferred migration approach (e.g. greenfield or brownfield). Note that when we refer to ‘process landscape’ this is not just the process flow itself but a broader definition also covering elements such as organization, people, (master) data, management information, reporting and security & controls.
There is a large technical component to each S/4HANA migration. Related to the application itself (e.g. functionality) but also to the architecture (e.g. integration, Cloud vs. On Premises) and infrastructure (e.g. sizing). Key component is to define what your future application landscape will look like. What S/4HANA modules (and related Cloud applications such as Ariba, C/4HANA or non-SAP) can be used to support each business process and how do these modules integrate. There is time needed to perform an SAP readiness check, especially when using a system conversion scenario (brownfield) which means the existing system is updated to S/4HANA. The SAP readiness check covers topics such as the simplification list (delta functionality between ECC and S/4) and the custom code analysis. This can be quite a lot of work, but these analyses are typically supported by tooling, such as SAP Solution Manager tooling.
Determining the strategy is about making choices that will have a long-term impact. Choices that do not only affect IT but also have an impact on your business. Managing this change is not only a key factor for the successful realization of the S/4HANA migration but also commitment for the strategy itself. The end-2-end methodology provides a framework for managing these changes in a structured manner.
Because of the long-term impact and various issues that need to be addressed when determining the strategy it is best to perform these activities in a structured, project-based manner with a specific team, planning and budget. Clear documentation makes it easier to integrate the results into any other possible initiatives in your organization and it provides a solid basis for the next phases.
As mentioned, these various perspectives are closely related and will be handled simultaneously. For example, when analyzing the possible business improvements on the fly you will also check the possible use of new S/4HANA functionality.
In addition to the various perspectives we also see a number of phases (see Figure 3). On a high level these phases indicate a certain chronological order that needs to be followed to ensure a structured way of decision making. However it is important to note that on a more detailed level activities are not that strictly separated and can be run in parallel both within a phase as between phases.
Current state and vision
This phase is focused on starting to build a case for change by obtaining a clear view on business strategy, value drivers and key requirements and the way the current business and IT landscape contributes to this. What is working well but also what is not and why. The goal is to get an initial idea of the possible benefits of starting an S/4HANA migration and a first indication of the preferred migration scenario (e.g. greenfield or brownfield). Note that this analysis is not only focused on the current situation but also takes into account expected business developments in and around your organization to ensure these are taken into account when defining the future process and application landscape.
This phase is focused on exploring S/4HANA in your own business and IT context. From a value perspective you analyze the possible benefits of migration to S/4HANA and identify clear use cases (where possible with quantifiable benefits using data-analytics). If needed specific use cases can be further explored in a proof of concept or trial. The value analysis is translated to an initial business case showing the benefits and cost of migrating to S/4HANA. The business and technology view are used to ensure that an initial understanding is obtained of the better practices and how S/4HANA can support the business processes and related requirements. This also includes a good view on the ‘On Premise vs. Cloud’ scope and a high-level fit/gap analysis. From a technical perspective, an initial assessment needs to be performed (SAP Readiness check) to understand compatibility with the new S/4HANA solution (e.g. simplification list, sizing, custom code analysis, etc.).
Future state architecture
Taking into account the knowledge obtained during the previous phases, the future process and application landscape is designed including a clear alignment on design principles. This is not yet the detailed design, but detailed enough to facilitate decision-making on the process and application landscape. If needed, multiple scenarios can be drafted after which the preferred scenario is selected. This also includes the analysis on the ‘OneCompany’ approach. The architecture phase also includes having a good picture of the required infrastructure. Based on the future state design the business case is fine-tuned. Obviously the future state architecture phase takes into account the expected value of increasing standardization, harmonization and simplification of the process and application landscape.
Migration and Roadmap
Where the ‘future state architecture’ phase defines the end state the ‘migration and roadmap’ phase defines the way to get there. This phase identifies, evaluates and selects the best migration scenario and strategy based on all relevant business roadmaps, legacy systems and target systems. An implementation roadmap is defined to show the migration steps as input for the implementation planning. From a business point of view this also takes into account defining the entities that migrate first. This is especially important when you have various business entities that are currently in separate systems and will migrate to a single S/4HANA system. Also a first draft is made of the data migration strategy. Based on the roadmap results the business case is finalized.
Before running the actual S/4HANA migration and deployment a number of preparation and design activities need to be done first. Design activities include the detailed process blueprint and solution design. Preparation activities do include related projects that need to be executed before the migration can start. For example, this could be the definition of a central chart of account, the cleansing of data, the implementation of a new functionality, the decommissioning of specific legacy systems, removal of custom code, etc. The following steps are planned by defining the relevant projects (and program), including a high-level project approach, plan and investment proposal. After approval, the project is handed over to the next phase. A value-tracking plan is provided to monitor value.
As mentioned, the streams and phases are used as a structure to ensure all required activities are performed from all relevant perspectives. However, activities are not strictly separated and are often run simultaneously both within phases as well as in between phases. Obviously, specific activities will also become more (or less) relevant depending on the direction your strategy is heading, such as a greenfield or brownfield approach. The detailed approach is aligned when setting up your S/4 Strategy project phase.
There are generally two main types of migration scenarios when moving to S/4HANA: converting your current SAP system to S/4HANA (“brownfield”) or starting a new implementation followed by data-migration (”greenfield”). Note that the option where you use a greenfield approach, but copy part of the design and setup of your current system (as you consider that part a better practice) is often referred to as a bluefield scenario.
Defining the right scenario is a key part of your S/4HANA strategy and highly depends on the current quality of your process- and application setup. For example, a high level of (unnecessary) business and SAP complexity, such as many process variations and a lot of custom coding, typically leads to the decision to use a greenfield approach. SAP also defined a list of guiding questions to support in the trade-off between greenfield and conversion.
If you have multiple legacy systems and you want to consolidate these into one S/4HANA system (see ‘OneCompany’) there is a third scenario called Landscape Transformation. Note that for the initial S/4HANA system that will be used for consolidation the same ‘greenfield or brownfield’ question applies as before. Once the S/4HANA system is available, the relevant legacy systems are added either with full or selective consolidation.
If you do not want to consolidate your legacy systems (e.g. when using a ‘replicated’ scenario) you can decide to migrate each system separately to S/4HANA (either greenfield or brownfield) and opt to use the Central Finance solution. The transactional, financial data from each linked system are transferred in real-time to the Central Finance system where reports can be run in real time including drilldown to original systems.
The use of tooling and accelerators
It will not surprise anyone that the actual S/4HANA migration is highly supported by tooling because it involves quite some technical activities. However, also during the S/4HANA Strategy & Roadmap phase, various tools and accelerators can (and should) be used to ensure proper decision support and ensure efficient analysis. Below are key examples.
SAP Solution Manager 7.2
This is a key application to support any end-2-end S/4HANA migration and although not yet mandatory in the strategy phase it is recommended to do so. The SAP Readiness Check dashboard (using statistics and transactional data from your current system) provides valuable input for your current business performance (e.g. KPI), S/4HANA compatibility (e.g. custom code analysis, simplification list) and infrastructure (e.g. sizing). Also, you have the option to download the SAP process better practices in Solution Manager as a starting point for your business process improvements). The sooner Solution Manager 7.2 is deployed the more data can be collected to support analysis during the Strategy phase. In relation to Solution Manager 7.2 SAP is now also starting to offer SAP Cloud ALM to support the full lifecycle of SAP (Cloud) S/4HANA environments.
KPMG Powered Enterprise
This is a comprehensive integrated set of better practices to accelerate the definition of your future operating model including the SAP application component. KPMG Powered Enterprise not only consists of process flows and predefined configuration, but also of all other relevant components of your operating model such as roles & responsibilities, risk & controls, performance indicators, authorization roles, etc. including all related documentation. The input from Powered Enterprise in the Strategy phase is primarily used to drive and accelerate the business improvement component.
SAP Value Lifecycle Manager (VLM)
An online questionnaire from SAP to provide input for your business case as part of the Value Delivery stream. Using benchmark data for similar organizations and migrations VLM provides an overview of potential benefits of moving to S/4HANA based on your questionnaire answers. The added value lies in the correct entry of the questionnaire and the interpretation of the results.
SAP Readiness Check
Tooling from SAP (e.g. SAP Maintenance Planner) to check compatibly with S/4HANA (such as the custom code check, pre-checks, simplification list and sizing). This is mainly used in the technology layer and typically executed using Solution Manager 7.2, see above.
Our digital transformation platform to obtain genuine business insights and identify and tackle specific business problems using a set of pre-configured apps filled with years of KPMG experience and better practices. As with Solution Manager the SOFY platform is typically used throughout the full end-2-end S/4HANA transformation and after go-live. During the Strategy phase it is mainly used to measure current business performance and identify possible business improvements using (predefined) analysis and dashboards.
Business Scenario Recommendation (BSR) report
A predefined report from SAP where an extract of statistics data of your current SAP system is used to provide an overview of possible improvements through the use of S/4HANA. The BSR is a standard report filled based on predefined content where the added value comes from the interpretation of the results.
A self-service tool offered by SAP that automatically generates a set of roadmap & integration guides based on predefined content. It contains a business guide, technical guide and transformation guide. Due to the nature of these guides, they are not yet sufficient to serve as your S/4HANA Strategy. The added value lies within the use and interpretation of the results to define your S/4HANA Strategy.
A process-mining tool to measure the process performance and the current level of process standardization. Using specific transactional events from your current SAP system, Celonis can drill down and analyze what end-2-end process was actually followed by the end users and where deviations occur from the agreed (if any) process. Although in practice it can be difficult to do detailed analysis and interpret results, the added value lies in getting a fact-based initial impression of the current level of standardization and process usage. It is typically used in Value Delivery and Business Improvement.
KPMG Complexity Scan
A data-analytics solution to identify the areas of unnecessary complexity in your current SAP environment. This provides input for potential improvements as well as a guide for the migration scenario. The higher the current complexity the more likely a greenfield approach will be.
The above overview provided an indication of the tooling and accelerators used when defining your S/4HANA Strategy. In practice not all tooling is needed at the same time and applying a specific set of tooling depends on each specific situation. For example, the level of detail needed for your business case. When you start to define your S/4HANA Strategy the detailed approach and use of tooling is further aligned.
Points of attention
This article shows both the need for S/4HANA Strategy as well as high-level guidance on how to define it. With this in mind it might be of interest to already share some key points of attention that will help you throughout the strategy phase. These are not necessarily linked to a specific phase.
- Do not underestimate stakeholder management: in essence, the entire strategy phase is about defining a ‘case for change’, because a migration to S/4HANA (like with any change of ERP and related processes) may encounter a lot of resistance. In practice, we frequently see S/4HANA projects not being initiated because relevant stakeholders are not involved in a timely manner. This is even more important in multi-company organizations where the aim is to implement a single S/4HANA system using one common process template.
- Understand the business and IT context: no improvement will be achieved unless you have a good understanding of the current situation. Understand what works well, but also what not and why. Analyzing these causes often already provides concrete ideas to initiate improvements and shows issues where S/4HANA could add value. Also note that changing your SAP landscape is something you do for the long term. Therefore, do not forget to look for future developments that may impact the choices you make.
- Identify unnecessary complexity: in everyday practice we see much of the potential value of ERP being lost due to unnecessary complexity. This often starts with too much business complexity (e.g. too many process variants) and results in unnecessary complexity in your SAP system (e.g. level of customization). As a result, processes become less efficient, management information less reliable and SAP systems more difficult to manage. The level of complexity not only shows where to find improvement potential, but is also a starting point to choose between a greenfield or brownfield scenario. The KPMG Complexity Scan is a good tool to support you identifying unnecessary complexity.
- Focus on management information and analytics: besides considering an efficient setup and the execution of transactional processes, focus on obtaining management information and using data analytics in a timely manner. Do you receive the information you need and is that information timely available and accurate? Supplying better and faster information and insights is one of the key benefits of (S/4)HANA.
- Make it concrete: the intended benefits of S/4HANA seem numerous but they only add value when they contribute to your specific business and IT context. Do not just look at everything that is possible, but also at what is needed based on your value drivers and improvement potential. When defining a business case or analyzing as-is, make it specific and fact-based (e.g. using tooling). The business and IT assessment should be input for this.
- Understand the S/4HANA status: although S/4HANA has been around for a while, in certain areas it remains a product under development, meaning not all functional domains are fully optimized for S/4HANA yet and the same applies to industry solutions. The SAP roadmaps may be useful input to understand the status. Also realize that not everything should be supported by S/4HANA, maybe parts can be covered by connected (best-of-breed) systems.
- Use better practices: do no try to reinvent the wheel when improving your process and application landscape. The use of better practices can highly accelerate this by using these as a starting point. Key sources for this can be SAP explorers and KPMG Powered Enterprise.
- Agree on scope and principles: defining a clear scope makes the S/4HANA initiatives manageable and organized. The design principles have to ensure the strategy is aligned and stays consistent along the way. What is your view on the level of standardization (versus customization), what is your view on using Cloud versus on-premise, are we typically pioneering with the latest technologies or do we stick to proven solutions, etc.
- Provide multiple options: if at any point during the strategy phase there is not one clear path forward (e.g. when defining the end-state architecture or migration scenario to use) it helps to perform a scenario analysis. This will help understand the various options and guide you towards the preferred solution using agreed criteria to score the options.
With this article we aimed to show you the importance of an S/4HANA strategy and roadmap as well as the steps to take to define it.
Your S/4HANA Strategy & Roadmap is key to set a solid foundation for your future process landscape and S/4HANA application landscape. It supports you to make the right choices based on a clear vision and it helps to define the steps needed to really make it happen. And just as important; it helps you to focus on value delivery and the necessary commitment to go ahead with the actual migration.
The strategy methodology consists of a number of clear perspectives and phases (see Figure 3 with deliverables and tooling) that provide structure to the activities that need to be performed. The key phases are to understand the current situation, to explore the potential of S/4HANA to improve this situation, to define the future process and application landscape and to define the roadmap to achieve this future landscape. And finally, to define a clear project plan for actual realization.
When your organization is facing the question when and how to move to S/4HANA, this methodology can be used as a starting point to provide structure. Use the methodology as reference list and take into account your own business and IT context to fine-tune the level of detail for each activity (e.g. how detailed should the business case be, how big is the need for process redesign, what do I already know about S/4HANA in relation to my business needs, etc.), and use supporting tooling where possible.
Working on your S/4HANA strategy in this structured way will highly contribute to the success of the actual transformation.
[Koot14]W.J.D. Koot and J. Pasman, ‘One IT’ volgt ‘One Company’ en niet andersom, Compact 2014/2, https://www.compact.nl/articles/one-it-volgt-one-company-en-niet-andersom/, 2014.