How to write your first “Hello World” S/4HANA business case – Part II

*This blog post is part of the “How to Build the S/4HANA business case blog series”. Check out the other blog posts here: Part I and Part III.

In part I of this blog series, I detailed how you can create a business case for SAP S/4HANA focusing on quantitative and financial drivers. Recognizing that integrating qualitative elements into the business case is just as important, in this blog I will go over how to complement your quantitative business case with qualitative business relevant insights.

Throughout the blog I made sure to share some real world experiences and lessons learned from a recent customer engagement working with a multi-billion dollar B2B global manufacturer to help them identify value opportunities from a move towards S/4HANA. To maintain customer confidentiality, I’ve removed all customer-specific information.

Although some aspects of a business may not be analyzed with numbers and calculations, they cannot be ignored. By aligning your quantitative business case with your organization’s strategic goals and objectives, you can provide a better view of existing business pain points and limitations.

Here’s a step-by-step overview of how you can get started with the qualitative component of the business case.

Step 1: Pick the right stakeholders

Building a business case for a core backbone technology, such as SAP S/4HANA, should not be a one-man nor one-team effort. The business case must take into consideration input from all functions of the company. As a first step, it’s critical to identify who needs to be involved in this exercise and how much time you should allocate to the various stakeholders.

This part of the exercise was challenging for one of my recent clients, a large multibillion-dollar organization that had in the past undergone a merger / acquisition. At the time, four of its divisions and product lines were working independently from each other and used separate enterprise software applications and business systems.

What started out as a plan to meet with 10 teams representing various lines of business in the organization quickly mushroomed into a request to meet with 40 different teams. Every division had its own processes and wanted to have its own workshop and conversation around requirements and business needs. Prioritizing these various teams and consolidating workshops consumed a lot of time during the preparation phase, but was a critical factor in the success of the exercise at the end.

When identifying the business case stakeholders avoid falling into the trap of spreading your resources too thin by including everyone in the project and dedicating equal time to all stakeholders. Instead, take a strategic view of the organization to identify which divisions and product lines generate the most revenue, which ones contribute the most profit margin, and which product lines are growing the fastest. In other words, separate the “cash cows” from the “rising stars” to clarify where to focus your attention and resources to build the business case.

 

Figure 1: Stakeholder Matrix

 

Step 2: Engage with business executives 

Once you know which business units and divisions you want to engage, the second step in the process is to set up meetings with your leadership team. Each discussion should help you reach an objective view of their mid- and long-term strategies and how your current enterprise technology landscape supports or hinders their business goals. Providing as much context as possible to the executives before the meetings can help gain their attention and commitment to the project. Make sure all attendees know what you are trying to accomplish during each meeting and how the outcome of the meeting will be leveraged in the business case.

You might find that some executives are unsure of why you want to speak with them in the first place, especially if IT hasn’t engaged with them in a long time. They might respond by saying they don’t personally use the current ERP system or recommend that you speak to one of their ERP power users. However, it is vital to be persistent as the executives provide a valuable perspective that is critical to the success of the project.

During the aforementioned client engagement, one executive brought in their ERP power user to the meeting. The user was prepared with a long list of every ERP transaction z-code used by the division, thinking ERP z-codes was the topic of conversation. However, once we explained that the purpose of the meeting is to understand the strategic business objectives of the division, the executive opened a treasure trove of insights that were extremely relevant to the project.

For example, one of the executives expressed extreme concern about his division’s ability to respond on time to customer Request-for-Quotations (RFQ). For decades, the company relied on a manual process, where the engineering team reviewed every RFQ to choose the right design, generate the bill of materials, and create a quote. This approach had worked very well in the past, but the executives saw a need for an “Amazon-like” selling experience that offers customers an online self-service experience for configuring and generating a quote on demand. Given the complexity of the industry requirements and the products that the company manufacturers, this vision was so transformational and radical that the team couldn’t possibly uncover it if the discussion stayed at the SAP z-code transactional level.

 

 

Figure 2: Sample Output from an Executive Interview

 

 Step 3: Set up workshops

Although executives are ideal communicators of the strategic and long-term vision, they most likely cannot bring attention to the immediate tactical pain points and capability gaps that are negatively impacting revenue and profit margins. Instead, business process experts are best suited for this job because they experience the daily inner workings of owning and executing activities such as financial close, warehouse put-away, resource scheduling, and demand planning. These specialists will also spend more time with you because they view process improvement as an opportunity to simplify their day-to-day lives.

To capture all of this knowledge, you will want to break down these workshops by line of business. Lay out the end-to-end process and engage a conversation about each building block of a process. Make sure you use the same terminology and vocabulary that the business uses to describe the processes. For example, what an SAP product considers as part of the scope of sales and operations planning, inventory management, or order to cash process might have a different name or definition in your organization. By using relevant process names, you can help ensure that the right people are invited and come to the right workshops.

During one of our supply chain workshops, our customer intended to discuss the post Master Planning Schedule (MPS) activities we came across a couple of meeting attendees who had confused the workshop for a  sales and operations planning session, which was more focused on demand planning and forecasting activities. We found that renaming the workshop from “sales and operations planning” to “planning and scheduling” to align with the customer’s terminology helped eliminate that confusion.

During these workshops, it can be all too tempting to build out a long wish list of capabilities that the business needs. Instead, focus the conversation on how the company is using the technology available today, what pain points may emerge, and where these pain points will impact the business.

Figure 3 provides an example of how we broke down the warehousing process in our customer’s project and captured pain points around each component.

 

 

Figure 3: Sample Output from a Warehouse and Inventory Workshop

 

Step 4: Synthesize your findings

Once the workshops are complete, you may start experiencing a few “aha moments” as you connect the dots between a variety of qualitative pain points and your previous quantitative business case work. Each of these findings should be captured and documented as validation points to support your quantitative analysis.

For example, during one of our client’s workshops, we analyzed the relationship between the monetary value of unaccounted warehouse inventory in a particular region and the need for a straightforward, intuitive, and Web-based user experience for SAP S/4HANA. The warehouses in the defined area had undergone a sudden wave of hiring, almost doubling in size. Despite hours of training, the new hires struggled to understand how to use, and, more importantly, how to resolve issues in the old ERP warehouse management GUI interface which lead to inability to locate items in the warehouse using the system.

 

 Figure 4: Sample Output of the Synthesis Phase

 

Step 5: Prioritize your analysis

The next step is to look at everything you learned from the executive interviews and the business workshops and prioritize each finding based on business impact and match it with the relevant capability enabled by SAP S/4HANA. This prioritization will be useful when designing a value-based road map.

You might conclude that not all business gaps will be addressed by SAP S/4HANA. Some capability gaps might require additional complementary solutions. For this reason, it is essential to have a clear description and expectation of which gaps SAP S/4HANA will address and which ones it will not.

For example, during the client engagement what started out as a pure S/4HANA conversation ended up expanding to include other cloud solutions around service management with Hybris and collaborative sourcing with Ariba. The customers requirements in these areas where beyond the scope of what S/4HANA could cover and required additional complementary solutions. We used the following 4 panel approach to steer the capability requirements.

 

 Figure 5: Example of a Prioritization and Scope Matrix for Service Management

 

Step 6: Put it all together

Now, you are ready to consolidate your qualitative assessment and use them to support your quantitative business case. If you’re working across many lines of business and a lot of divisions within your organization, you might consider summarizing your findings into an executive summary slide, which is quick and easy for your board-level audience to consume.

During the engagement, we used the template shown in Figure 6 to summarize more than 30 qualitative slides and to bring together qualitative and quantitative aspects of the business case. (This slide had a lot of customer specific information that could have reveled customer’s identify so I’m share the template with dummy text for demonstration purposes only). 

 

Figure 6: Executive Summary Template

 

Share your experiences

Are you currently building a business case for SAP S/4HANA or created one in the past? If so, what have you done – or wish you had done – differently? Do you think your organization requires a different approach due to its size, industry, or region?

I would love to hear from you! Please share your thoughts and experiences in the comment area below.

Source: https://blogs.sap.com/2018/02/27/how-to-write-your-first-hello-world-s4hana-business-case-part-2/