Organizations deploying SAP S/4HANA in their business will benefit from keeping the solution as close to standard as possible, which allows for faster adoption of innovations that SAP delivers both for cloud and on-premise systems.
SAP experts often refer to this as a cloud mindset or keeping the core clean. To help customers execute this approach, SAP Activate includes guidance and governance for application of the so-called golden rules for implementing SAP S/4HANA. In this post, we will review the approach and rules in more detail.
SAP S/4HANA offers a high level of flexibility and extensibility options that are embedded in the solution and enabled with the full ABAP development environment. Some choices that the implementation team makes during the project could lead to increased total cost of ownership during the regular operations and upgrades of the environment later. As you implement the solution, SAP recommends project teams to stay close to the standard functionality and limit the use of some extensibility and custom coding techniques to absolutely critical cases where the solution needs to be adapted to support the business objectives.
SAP has published five golden rules for implementing SAP S/4HANA that provide project teams, architects, technical and functional consultants, and key users with guidelines to implement the solution in a way to make it easier to upgrade and continuously enhance.
We’ll walk through each of the golden rules in the following sections and explain how to apply it in your SAP S/4HANA project. First, let’s look at the rules at a high level and discuss their business benefits.
Rules and Benefits
Let’s begin with a high-level overview of the five golden rules and consider their business benefits. The five golden rules are as follows.
1 Foster a Cloud Mindset by Adhering to Fit-to-Standard and Agile Deployment, As Detailed in SAP Activate
The following activities fall under this rule:
- Leverage SAP standard processes where possible.
- Deploy your solution incrementally with short releases and sprints.
2 Use Preconfigured Solutions with Predefined Processes and Leverage the SAP Fiori UX
The preconfigured solution options are as follows:
- SAP Best Practices for SAP S/4HANA Cloud and SAP S/4HANA (on-premise)
- Enterprise management layer for SAP S/4HANA
- SAP-qualified partner package
- Modern SAP Fiori UX
3 Ensure the Use of Modern Integration Technologies
To use modern integration technologies, follow these guidelines:
- Use public APIs (also known as allow-listed APIs).
- Provide no native access to APIs that aren’t public.
- Follow the given SAP Activate guidance for integration.
- Use SAP Business Technology Platform (SAP BTP) functionality for cloud integration.
4 Ensure Use of Modern Extensibility Technologies
To use modern extensibility technologies, follow these guidelines:
- Develop company extensions in a side-by-side approach using SAP BTP.
- Leverage key user extensibility for no-code extensions.
- Use developer extensibility to create custom code where needed.
- Avoid backend enhancements.
- Don’t modify SAP source code.
5 Ensure Transparency on Deviations
You can ensure transparency via the following methods:
- Clearly document any deviations as part of the implementation; this will help the company replace these with standard capabilities if they are offered in the future.
- Use the standard capabilities of ALM tools like SAP Solution Manager or SAP Cloud ALM to document the solution.
Companies that adhere to these rules realize the following benefits.
Adopting standard processes reduces the number of decisions and effort to configure, tailor, and test the solution, thus resulting in faster time and lower effort for implementation. This approach also allows for tailoring the solution when an organization will gain value from using a customized solution rather than the standard. In many ways, this is a balancing act of implementing the solution close to standard and maximizing the benefits the organization can extract from the solution.
Reducing the number of changes in the solution leads to cleaner software that is easier to upgrade and continuously enhance, thus leading to lower overall cost of initial implementation and ongoing upgrades.
A clean core allows your organization to innovate at a faster rate as you’re ready to leverage the regular innovations SAP delivers in your system.
Adopting standard software exposes your organization to less risk that could be introduced in custom code during the project, including potential security gaps.
Rule 5 stipulates the need to document the key configuration decisions and any deviation from the golden rules. Having clear documentation of the decisions used to design the solution allows organizations to be less dependent on one system integrator and provides them with choice in the market.
Using modern technologies, such as open APIs for extensibility and integration, sets up the system for the future and allows organizations to benefit from the well-designed system longer as the technologies evolve. Using old technology will lead to them becoming obsolete, and organizations will need to invest in redesigning and rebuilding specific parts of the system that use old technology after they become obsolete or get phased out.
Rule 1: Foster a Cloud Mindset
One of the key principles in implementation of the cloud solutions is to stay close to standard capabilities of the software and to either fully avoid or at least minimize customization of the software. The fit-to-standard approach in your project will help you structure workshops around reviewing the standard functionality delivered in SAP software, whether you’re building your solution around SAP Best Practices, the enterprise management layer for SAP S/4HANA, or an SAP-qualified partner package. With all these packages, the project team starts with a set of predelivered processes that are shown to the business users to secure buy-in and to define delta requirements for capabilities that need to be configured or created during the implementation of the software.
The figure below shows the application of the fit-to-standard approach in the flow of the project from the prepare phase through the explore phase.
The key steps in each phase that pertain to the rules are referenced with the rule number in the circle. While the focus is on the first two rules in the figure above, all five rules work in conjunction and build on each other. You can see that in cases where the box referencing an activity is linked to multiple rules. For example, the Prepare Landscape and Technical Setup activity links to both rule 2 and rule 3 as integrations are a key part of the technical setup.
The second part of the first golden rule is to apply agile techniques in deployment of the software, which enables your organization to clearly set the focus on the most valuable capabilities first and deliver the software to the business via incremental deployments to maximize the value you’re getting from the solution.
Rule 2: Use Preconfigured Solutions and Leverage SAP Fiori
This second golden rule goes hand in hand with the first one that we discussed in the previous section. The principle we discuss here is to use preconfigured and ready-to-use standard business processes and thus adopt the standard functionality where these processes are a good fit for your business. In many cases, this will require driving strong change management to the organization to adopt the new standard instead of tailoring the predelivered processes. This is especially the case with business processes that don’t bring differentiation to your business but are necessary to run your organization. In this case, it makes sense to adopt standard processes and rely on SAP for delivery of innovation. Some examples of these processes are as follows:
- Accounting and financial close
- Asset accounting
- Purchase order accruals
- Preventive maintenance
- Emergency maintenance
Even processes for which you adopt the standard may bring significant innovation into your organization through an ability to use innovation technologies like machine learning, artificial intelligence (AI), and robotic processing automation (RPA).
The second part of the rule refers to leveraging the SAP Fiori UX to take advantage of the innovation SAP is building into the software with a new UX that helps process business transactions more efficiently by exposing business information to the user in new way. SAP Fiori can expose both the analytical data and transactional data in one screen, thus allowing you to analyze the situation and take action.
The following figure shows the Sales Order Fulfillment Issues screen designed in SAP Fiori, which provides a combined set of information with the analytical view at the top of the screen and the individual sales documents in the bottom part of the screen. With this UI, you can quickly zoom in and act on the orders that need attention. Many SAP Fiori screens also include additional intelligent technologies that help you identify and perform the action based on analysis of previous situations using machine learning and AI.
Rule 3: Use Modern Integration Technologies
SAP provides several predefined integrations for SAP-to-SAP integration scenarios as the recommended ways to integrate your SAP S/4HANA solution with other SAP software in your landscape—for example, SAP SuccessFactors Employee Central or SAP Ariba. For such situations, we recommend using the predelivered integration scenarios you can find in SAP Best Practices Explorer.
For integration of homegrown systems or systems from other vendors, SAP recommends using SAP’s Cloud Integration capability, available with SAP Integration Suite. This applies to both cloud-to-cloud and cloud-to-on-premise integration scenarios.
SAP Activate provides specific steps for project teams to follow during the design of integrations. The tasks guide project teams to identify the integration needs, define the integration scenario, and create detailed functional and technical designs for integrations that aren’t delivered out of the box. Then in the realize phase, you can implement the integration using available APIs on SAP API Business Hub (you can learn more at http://api.sap.com).
Below shows the flow of these steps in SAP Activate. At the top, you can see items from the integration scenario and interface list, which is used to collect a list of integrations. The steps below that show the flow of activities driving the definition and design of integrations. The integration scenario and interface list accelerator are used to detail the functional and technical aspects of the integration, including the API and details of the data the interface uses (including information such as data type and field length that are important for technical realization).
Rule 4: Use Modern Extensibility Technologies
SAP S/4HANA supports a wide range of extensibility options that allow businesses to tailor solutions to their needs. The following extensibility options are recommended:
Key User Extensibility
This allows users to adapt standard functionality to meet their requirements without the need for any external tools. It can be used both for applying small changes, such as hiding standard fields for specific user groups, or for including additional business logic. SAP S/4HANA Cloud offers tools that cover diverse extensibility needs. The following is a list of in-app extensibility actions:
- Change and adapt the UI layout and context
- Create a new custom UI
- Create custom fields
- Create custom business objects
- Create and extend forms and email templates
- Create custom-specific CDS views
- Enhance the current business process by creating custom business logic
Developer Extensibility
This type of extensibility is possible through the integrated development tools in SAP S/4HANA Cloud and SAP S/4HANA, like the full ABAP development environment in SAP S/4HANA Cloud, private edition or the ABAP environment for SAP S/4HANA Cloud (note that at the time of writing, this capability was in early adopter stage with select customers).
Managed Extensibility Using SAP BTP
This extensibility approach uses SAP BTP (a platform as a service [PaaS]) to extend the application by using the capabilities exposed via services on SAP BTP. The applications built on the platform are then integrated with SAP S/4HANA Cloud and SAP S/4HANA and extend the standard functionality in one of many areas. You can develop applications such as the following:
- Proxy applications
- Convenience applications
- Substitute applications
- Preprocessing applications
- Postprocessing applications
- Analytical applications
The applications developed on SAP BTP use the following integration contexts to integrate the application with SAP S/4HANA Cloud and SAP S/4HANA:
- UI integration
- User integration
- Rules and workflow integration
- Process integration
- Events integration
- Data integration
The next figure shows the flow of steps in the context of a project, where the project team needs to identify the need for extensibility, capture the requirements, detail the design for specific extensibility, and develop and test the extensibility. It depicts the key sources of information that help you work on extensibility, such as SAP Extensibility Explorer and business process flows from standard SAP Best Practices processes used to indicate the extensibility requirements. In the lower portion of the figure, you can see the process steps that project team experts follow to define and design extensions in the system. The numbers above the boxes indicate the golden rule(s) applicable in each box.
If you’re interested in extensibility, review the details provided via SAP Extensibility Explorer at http://s-prs.co/v502725 and review the example extensibility samples provided there.
Rule 5: Ensure Transparency on Deviations
The fifth rule is aimed at ensuring that any deviations from rules 1–4 are clearly documented so they can be accessible to the company during future solution upgrades or application of system patches by the service center. This rule has several purposes, the main one being the ability to understand the design decisions that were made during the implementation of the software.
This is especially important during upgrades that may introduce new capabilities requiring reconfiguration of the existing features to work with new software. For example, new functionality introduced in release X+1 may change the way the application runs and may require new configuration. In such cases, access to comprehensive documentation and decision rationales is important. This applies not only to configuration but also to integrations and extensions that have been introduced in the system.
SAP recommends that companies use ALM tools such as SAP Solution Manager or SAP Cloud ALM to keep track of key design decisions for configuration, extensions, and integrations. The ALM tools provide capabilities to document the process flow decisions, document the design rationale, and capture the key design decisions for the future. It’s also important to keep this documentation up to date in the release upgrades as the system gets new release functionality and the design is updated.
Governance to Keep the Core Clean
As we stated at the beginning of this section, the goal of these five golden rules is to help the customer project team keep the core clean and maximize the reuse of standard functionality instead of customizing the system functionality to cater to every single requirement raised by the business users. While this may sound counterintuitive, the experience in many projects has been that a large number of the requirements raised during the project are not in use either from the beginning of productive use of the system or shortly after use. SAP Activate recommends applying the lens of value to the business during the approval process before a requirement is added to the backlog.
To implement such governance, the SAP Activate team has added the Solution Standardization Board (SSB) to the prepare phase. The next figure shows the Establish Solution Standardization Board task as part of the activities in the prepare phase, related to project initiation and governance (see the starred task in the expanded deliverable).
It also points to the self-enablement activities (see the star next to Customer Team Self-Enablement) that all project teams implementing SAP S/4HANA Cloud should go through (note that this also applies to project teams implementing on-premise SAP S/4HANA that aim to keep the ERP core clean). The key self-enablement activities prior to fit-to-standard workshops should focus on understanding the cloud mindset and learning the principles of the fit-to-standard approach. There are additional self-enablement activities done during the prepare phase, but the absolute minimum for the business users and project team members participating in the fit-to-standard workshops is to understand the cloud mindset, fit-to-standard, and the product capabilities in their area of responsibility.
Let’s now talk about the role and scope of work of the SSB. The project team establishes this governance function very early in the implementation project and its role is to ensure that the project standardizes business processes and complies with the five golden rules. This means that the SSB evaluates, reviews, approves, or rejects the following requirements and requests from the individual functional project work streams:
- Delta requirements addressed through in-app and side-by-side extensions, especially ones in amber and red categories per the extensibility guide for SAP S/4HANA Cloud
- Required integrations with emphasis on use of allow-listed APIs and compliance with golden rules
- Architectural and cross team design decisions that deviate from the golden rules
Essentially, the SSB functions as the gatekeeper to keep the project team and solution design in line with the five golden rules and guidance in the extensibility guide. The role of the SSB is to review all the noncompliant requests and decide whether they are going to be implemented. The board meets weekly to review all the submitted requests and make a decision on each. If a request is rejected and the project workstream wants to escalate this decision, they can trigger escalation to the project steering group, as shown below. Note that it depicts one page from the SAP Activate SSB template that you can download from the accelerator list in the task shown earlier.
The SSB includes representatives from the company and the system integrator. On specific occasions, it also may include additional participants from project workstreams requesting the change or workstreams that are impacted by the request. The standing participants are as follows:
- SSB chair from the company and system integrator
- Company and system integration project managers
- Chief SAP solution architect (system integrator)
- Lead SAP technical architect (system integrator)
- Company enterprise IT architect
- Development leads responsible for SAP development (company and system integrator)
The role of the SSB is important during the implementation project, but it should not cease to exist after the first go-live. It is important to transition the function of the SSB into a permanent role in the IT organization to continue supporting future projects and point enhancements of the implemented system. The final figure shows the recommended steps for using SSB during the project and transition of the function into a permanent role after the initial go-live.
The role and importance of SSB continues after the initial go-live to ensure continuous focus on implementing the new functionality in a manner compliant with the golden rules and a cloud mindset. Companies with multiple ERP projects could consider establishing an SSB function on the corporate IT level to provide oversight across all projects to monitor compliance with golden rules.
Editor’s note: This post has been adapted from a section of the book SAP Activate: Project Management for SAP S/4HANA and SAP S/4HANA Cloud by Sven Denecken, Jan Musil, and Srivatsan Santhanam.
Comments