Proven practices for fit-to-standard for your SAP ...

NBrumbergs · ‎03-31-2021

The objective of this blog post is to introduce you to the fit-to-standard approach for use in implementation of SAP S/4HANA in the cloud or in on-premises. The concept of fit-to-standard is detailed out in the SAP Activate methodology and while we will provide a brief intro, we will not be going into a lot of detail as this topic has been previously covered by other blog posts which we will reference. Instead, we will focus on the key challenges and misconceptions we have observed in implementation projects. We will also provide recommendations on how to tackle these challenges in your own projects. These recommendations are based on hands on experience from large scale projects which use SAP Activate efficiently to drive their SAP S/4HANA implementation in their organization.

The authors of this blog post are the people listed below with a short outline of their current role and organization:

lisa.kouch – PO SAP Activate methodology for SAP S/4HANA Cloud, extended edition, SAP

jan.musil – CPO SAP Activate methodology, SAP

nbrumbergs – SVP Delivery, Applexus Technologies

What is Fit-to-Standard and why it is important?

The purpose of the fit-to-standard workshops is to discuss how the pre-delivered business processes fit with the customer processes and document required configuration, identify delta requirements, and requirements from the business which need further refinement from technical experts. A solution that is as close as possible to SAP standard pre-delivered processes will allow the customer to adopt new innovations and best practices for their industry at a much faster pace than otherwise. This in turn leads to faster realization of business benefits and a lower total cost of ownership while keeping the solution current. The cost savings resulting from adopting the standard on non-differentiator business processes can be focused on the things that really differentiates themselves from their competitors.

We do not plan to go into the details of fit-to-standard process in this blog post. If you are interested to explore this topic, you can find more details about the fit-to-standard process in Lauren Bettuzzi’s blog post here.

Key challenges observed during Fit-to-Standard

In this section, we will focus on the frequently observed behaviors or misconceptions related to fit-to-standard and the use of agile techniques in SAP projects.

Within the Prepare Phase of SAP Activate, the project is kicked off and the project guidelines are established. A key piece is to remind everyone that the approach is a fit-to-standard approach and the process by which any deviations will be handled. A governance model should be established to help keep the core clean by minimizing enhancements or deviations from standard.

No matter how much the team is prepared, there is usually a time during the fit-to-standard workshops where the realization becomes apparent that keeping to the standard of SAP will mean big changes to their daily lives. At this time, your implementation team may struggle to hold firm and may need help on how to handle a business uprising.

To help the team, you may want to do some SAP Activate refresher training and remind them that there are some common misconceptions about SAP Activate and a fit-to-standard approach. Some of these myths are:

Keeping standard requires zero changes – Yes, there are changes that may be forbidden depending on whether your deployment is on premise vs. any of the various cloud options. The team should know what changes cannot be done vs. what changes or enhancements will be allowed.

There is no need for design since we are using agile sprints – While the detailed design of the old-fashioned Blueprint is a thing of the past, SAP Activate provides documentation templates to capture any delta requirements as well as their resolution. Key design decisions that may take the project on radically different courses (e.g. Path A is 200 days while Path B is 10 days of effort) do need to be made during the Explore phase. However, many of the smaller decisions with minimal impact can and should be resolved during the agile sprints when more information is available, and the end solution is more in focus.

We don’t need documentation because we are agile - Oh, how many practitioners wish this were true! You are still building a Solution Set that requires training and maintenance. SAP Activate provides templates that document the requirements with User Stories, the processes and much more. Functional Specs are still required to provide direction to the technical development team, but they are no longer the 300-page documents from 10 years ago. SAP Activate FS templates have made a much leaner documentation of the desired RICEF from a functional viewpoint. The best practice is to document the Technical Spec after development to ensure your Run/Support team understands the code and why it was built that way.

So, here you are. The business is pushing back on standard. What are the proven processes to manage these key challenges?

Proven practices to manage the key challenges

When your functional team faces these challenges, strong practices in three other parts of your project organization can help manage the impact. Your Governance structure can help limit the variations from standard, your Change Management can facilitate the user adoption of the changes from their current solution and strong technology practices can mitigate the risks of varying from standard. Here is a little more on proven practices in each of these.

During the fit-to-standard workshops, one of the key recommendations is to stay as close to standard as possible; however, SAP understands the need to adapt as necessary for your business. Prior to finalizing the decision to go non-standard, the project should ask three key questions:

Is it strategic to the business?

Does it provide a unique competitive advantage?

Does it impact branding to the customer?

The project team should discuss different options during the fit-to-standard workshops and then develop a business case to determine if any proposed modification is strategic to the business. The business case should identify the problem, propose, and recommend a solution, and propose an implementation approach.

Another area to consider is whether the solution provides a unique competitive advantage. While developing the business case, the project should properly document how the change will help distinguish itself from competitors. The customer should consider Artificial Intelligence (AI) technology to automate various business processes. SAP offers several Machine Learning and Robotic Process Automation services that should be reviewed during the fit-to-standard workshops. More details about AI availability can be found in the SAP Activate Methodology.

One final topic to consider is if the change will impact branding to the customer. For example, if the customer is well known for providing certain information during the sales cycle and this information would not be standard, then the project team should be sure to evaluate the cost of the modification vs. the impact of this change to the customer’s brand. Addressing all these areas during the fit-to-standard workshops will usually make customers rethink the delta requirement. If they proceed, then a business case will help the project sponsor and key decision makers evaluate the impact of benefits, disadvantages, etc. while making any decisions.

Managing and controlling custom code and objects

SAP Activate introduced the 5 Golden Rules for implementation of SAP S/4HANA a few years ago as a guidance for keeping the core clean through a set of five rules that govern the assessment of any delta requirement coming out of the fit-to-standard workshops. This applies especially to requirements that lead to extensions and custom development in amber or red classification per the SAP S/4HANA Cloud extensibility guide.

The 5 Golden Rules are enforced in your project through a formal in-project governance called the Solution Standardization Board (SSB). The SSB provides process, structures, and escalation paths for assessing the impact of the planned extensions, review of their impact and value before they are approved/rejected based on the organization’s needs and objectives. It also requires all approved objects and code to be properly documented per golden rule #5.

Implementation of SSB in your project can lead to significant decrease in scope of new custom code introduced into the system that both accelerates time to value (less coding, testing and integration needs to be done) and reduces the overall cost of ownership of the solution over its life. Consider that the cost of any custom code/object needs to be assessed not only from the immediate perspective of cost to the project, but also reviewed from perspective of on-going code maintenance, which can be sizably larger than the initial investment. SSB provides a mechanism to govern and control the custom code in your project and keep the core clean. You can learn more about the SSB in Jan’s earlier blog post here .

An optional layer of your project governance structure is the Operating Committee. This group is usually made up of business directors or senior management below the executive Steering Committee. If you are having problems with acceptance of fit-to-standard, this layer of your governance structure should be established. Typically, their primary focus is to make timely decisions, mitigate risks and remove obstacles. Tasks that are critical to achieve the speed expected from an SAP Activate project. In addition, this group can be a frequent check on requirements that would result in non-standard changes that manage to get past the SSB and ensure those extensions are properly justified before they get presented to the Steering Committee.

Role of the Project Sponsor

A very effective approach to enforcing fit-to-standard is the role of the Project Sponsor. A very active Project Sponsor can participate in bi-weekly sessions where the project team members from the business present the case for why they need something that is non-standard. This approach puts a significant burden on the business to convince their executive sponsor as to why they want to spend more of the company’s money to approve a non-standard requirement.

The project sponsor will remain involved throughout the project lifecycle in the Solution Standardization Board (SSB). Their involvement is key as the SSB will help govern and control the custom code in your project.

Change Management

To ensure a successful implementation, the project and customer organization should establish a strong Change Management team at the start of the implementation project. Establishing and defining the team at the start of the Prepare phase will help ensure proper channels are established and the solution adoption process is addressed throughout the complete project lifecycle. In addition, the Change Management team will ensure Executive and Key Stakeholders (including business users) receive the proper communications which keeps all parties informed and helps define the need for the change. This establishes a good working relationship with decision makers and impacted users as they feel informed and positive about the change.

During the Explore phase fit-to-standard workshops, the Change Management team should make certain to capture any significant user experience changes. This will help define a proper training plan. A good training plan will ensure adequate training is delivered throughout the entire cycle for both project team members and end users.

Technology

Sometimes, no matter how much you try, enhancements to SAP are required to meet critical business requirements. The first thing to do is to try to isolate the enhancement to the User Experience (UX) layer. Today, Fiori is the tool of choice to customize the screens the users will use to interact with the solution. Wireframes can be used to design the screens and gain agreement that they resolve the unique requirements.

As you enhance the UX, keep the underlying processes in SAP standard. This is where many enhancements go astray as they create unintended downstream consequences that unravel further along the process or when process variants come into play.

Finally, make sure your extensions are written in a side-by-side approach using the SAP Business Technology Platform (SAP BTP, formerly SCP). SAP provides the SAP S/4HANA Cloud Extensibility Guide to provide clear guidance on how to create enhancements in SAP S/4HANA to cover specific business requirements beyond what is covered by SAP standard processes and functionality. The SAP BTP makes it easier to manage your application interfaces (API), extensions, etc. and isolates them when your core SAP S/4HANA environment is upgraded.

Where you can find more…

The practices discussed in this blog are based on practical experience from applying SAP Activate methodology in a wide range of projects. We have covered topics that are encoded in SAP Activate, like the project governance, 5 Golden Rules, Solution Standardization Board and practices that project managers and team leads use to navigate the challenges of fit-to-standard in their project while keeping an eye on the scope, risks and outcomes. We invite you to share your experiences and comments here or in the SAP Activate Jam Community (register here if you are not a member yet).

You should also bookmark access link to SAP Activate Roadmap Viewer, where you can find all the mentioned assets and guidance in SAP Activate - https://go.support.sap.com/roadmapviewer/.You can always find more information about the fit-to-standard workshops, governance model and execution guidance there. Please share your feedback and thoughts in the comments to this blog post. We encourage you to join SAP Activate experts in the SAP Activate Jam (for invite use this link).

Follow us on Twitter and this community via @Sap and #S4HANA, or the authors via our community profiles - lisa.kouch, jan.musil and nbrumbergs.