SAP Business Value Realization in 5 Steps:
Building Your Case for S/4 Hana
Step 1: Establishing Business Leadership for the Project
“You can design the perfect SAP solution but if your business-people don’t want it, it’s just not going to work.”
SAP implementation projects deal with a lot of complexity. There are challenges with data, integrations between applications, and complicated end-to-end business processes. But even if you get it right, the entire system can be rejected by your business users if they don’t buy-in. When asked how to solve this issue, Steve highlighted the importance of designating an Executive Business Sponsor.
“A business sponsor isn’t just a customer of the SAP project. They need to be the leader, and the Executive Team needs to trust them to deliver the targeted results.”
Implementing SAP is challenging, and it takes a major commitment from the organization. This needs to be continually reenforced from the top down. Without the high-level leadership of a Business Executive Sponsor, the project is likely to experience costly delays.
The Executive Sponsor’s first job is to set the targeted business benefits that the project plans to achieve. Once those business value drivers are established, the Business Sponsor needs to maintain focus on delivering those benefits. This involves making difficult decisions and allocating the needed resources to keep the project on track.
Step 2: Building a Solid Business Case for SAP Implementation
“I’ve never heard an SAP customer say that their strategy is to grow because of SAP. They usually say SAP is a critical enabler and that they can’t scale without it.”
Although SAP is usually an enabler, it’s not usually SAP that drives the business growth. For this reason, it can be challenging to build a business case to implement SAP. According to Okun, “any company running or planning to run SAP already has a plan on how they’re going to grow their business. They may say their business growth strategy is based on mobile, digitization, customer experience, or artificial intelligence. Those are things that drive a business.”
Part of the challenge, explains Okun, is that “Business Leaders have already signed up to very steep goals and they don’t want to add anything on top of it.” To solve this, Okun suggests that “the CIO can work with the business sponsors to lay out the key business value drivers, and then dig into how much each of those drivers is worth, financially.”
"The other thing I would suggest is to think about the cost of NOT making the change.”
Okun recommends considering the costs that can be avoided by retiring costly, redundant and difficult to maintain legacy systems. “You can remove capital hardware costs by moving to the Cloud, for example, using SAP RISE.” Although difficult to quantify, Okun also recommends outlining in your business case “the risk and the likelihood as well as the potential cost and impact of a serious production outage.”
Step 3: Gaining Business Buy-In for SAP Projects
“Get feedback from business users early. When it’s time to hand the system over, they’ve seen it not once, but three or four times. They may start as Skeptics, but as their needs are addressed, they’ll become project Advocates.”
Okun’s advice on how to gain business buy-in for SAP projects was simple. “Make them accountable,” he said. He warned against letting business stakeholders act as customers of the project. Instead, you need to assign business leaders ownership of key project deliverables, such as requirements, test scenarios, and test results. By making them accountable, he said, “it becomes their responsibility, so they’ll need to get involved.” The result, according to Okun is, “you’re going to get a much better result when you go live.”
"How to get business users involved? Make them accountable.”
The other advice offered was to get business users involved early. This starts in the Explore or design phase when the project team runs “playback sessions” to demonstrate the new design. These playback sessions are a way of testing the design, gaining user acceptance, and finding problems early.
In the early stages of testing, the business may play the role of observer. But in later stages, the business should play an active role, and should run the testing on their own during User Acceptance Testing. There is sometimes a desire to keep business users out of the system before it is ready, but this can be a mistake. By allowing business users to surface their concerns early, they will see progress and they’ll feel responsible for the improved results. According to Okun, this will help to convert business users from Skeptics into Advocates.
Step 4: Overcoming the Challenge of Changing Requirements
“The requirements become the contract for what the project team is going to deliver.”
SAP has evolved since the early days, and most companies can use the standard SAP processes. “Rather than designing a business process from scratch,” says Okun, “the project team should be asking the question ‘why won’t the standard SAP processes work here?’” Okun suggests that, “as part of your project methodology, you need to capture the requirements for each step in the process.” For this, you may need a specialized tool such as Cloud ALM, which is free for SAP Enterprise customers. According to Okun, “when you get to a certain scale, Excel isn’t going to cut it.” You should consider integrating Cloud ALM with tools that the business already uses, such as Jira and Azure DevOps.
But whatever tool you use, the requirements need to be documented. Okun describes the requirements as the contract for what the project team is going to deliver. In order to ensure you achieve the business benefits, you need to make sure you capture and validate all of your requirements.
“When it comes to changing requirements, you need a Governance process to make sure that you have the budget and time to absorb the impact of the change."
Another critical success factor, according to Okun, is establishing a Business-led Governance process to approve any changes to requirements and the process design. Changes often seem small at first, but given the complexity of the SAP business process, changes are usually the primary source of project delays and post go-live issues. According to Okun, Business Leaders need to oversee the Change Governance process ensuring that only critical changes are approved, and only if the impact to the budget and timeline are acceptable.
Step 5: The Role of Testing in SAP Project Success
“Often a QA Test Lead gets assigned the responsibility of owning the test scenarios. That’s a mistake. Don’t let that happen to you.”
Steve Okun warned not to assign ownership of the test scenarios to a QA Test Lead. “That’s a mistake,” according to Okun. It’s ok for the QA Test Lead to facilitate or lead the work to create the test scenarios. But the business needs to take ownership.
“If there’s a change in your business requirements or the business process, you’ll know which test cases you need to retest.”
Doug Kreinheder raised the importance of requirements traceability. This is achieved when each requirement is linked to the test case that validates the requirement. This is especially important, Kreinheder emphasized, for regulated industries such as those governed by the FDA.
Okun described two benefits from requirements traceability. First, it will help you to identify requirements that don’t have corresponding test cases. In order to achieve your targeted business benefits, you need to validate all your requirements. The second benefit, according to Okun, is that “if there’s a change in your business requirements or the business process, you’ll know which test cases you need to update or retest.”
SAP business transformations are expensive. Executive Business Leaders need to play an active role in leading those initiatives. Success comes when business stakeholders are made accountable for defining and validating the business requirements. This takes extra effort, but it significantly improves the return on investment. There are tools that make this easier to manage, such as Cloud ALM. Stay tuned for subsequent episodes explaining the step-by-step process for requirements management and validation.