Mastering the art of business process decomposition is key to leading your company to process-oriented management. Using business process decomposition, you can describe your business as a process hierarchy. Understanding the key components of scenario, process, and step in the SAP Solution Manager business process hierarchy (BPH) can enable your organization break down functional silos and understand your enterprise from an end-to-end value chain perspective. This is the first step in improving transparency to change impacts, improving change agility, and driving costs out of your most important business processes.

When leveraging business process decomposition to describe your enterprise, terminology becomes absolutely crucial. I’ll start by explaining the important terminology you need to know for setting up the BPH in SAP Solution Manager, and then I’ll walk you through how to a set up the hierarchy in the SAP system using an example business.

Terminology 

If you’ve ever worked with business process modeling, you know that a common trap for companies is a lack of consistency when using the modeling objects to describe the business. The following terms help you avoid this trap when using SAP Solution Manager’s BPH to describe your solution scope.

• BPH: This is the logical grouping of business scenarios, processes, and steps that are implemented as part of the solution. SAP and non-SAP steps are included; the details for non-SAP steps drive the integration test scope.
• Scenario: A scenario shows a comprehensive business flow as a series of different individual processes that are linked sequentially and logically. To achieve business value, a scenario must have a clear beginning and end. The scenario is the representation of the business value chain. For example, the Order-to-Cash scenario would be the logical association of Order Processing, Delivery Processing, Invoicing, and Cash Application. Scenarios should be able to be tied to key performance indicators (KPIs).
• Process: Processes show in detail how individual business functions are logically and sequentially linked. A process has a clear beginning and end and supports the value chain of its assigned scenario. A process is a subset of a scenario. In an Order-to-Cash scenario, Order Processing represents a process within the scenario.
• Step: An elementary event in a process. It is a discrete event that supports the process. The step (e.g., Post Goods Issue) can appear in multiple different processes.

The definitions above are based on my experience in working with customers all over the world combined with commonly accepted definitions, examples provided by SAP, and those put forth by numerous standards organizations such as the American Productivity and Quality Center (APQC) and Object Management Group (OMG).  

Art vs. Science

Before going any further, it is important to emphasize the need to make sure that everyone associated with the business process decomposition effort has a common understanding of the key terms. I cannot overstate the importance of creating a consensus on the detailed meanings for these important terms for your project through workshops. Experiment with variations on the meanings and select examples for each so that everyone on your project understands the terms. I have personally witnessed (and led long painful workshops to reconcile) the enormous mess created in only a few short months when there is misalignment in the meaning of these important words.

This process involves a little bit of science and a little bit of art. As we proceed, I’ll point out where I am using science and where I’m using art. Science comes into play with the construction of specific BPH structure elements that represent the solution you’re delivering for your business. The art part comes in when you have to apply what I call controlled interpretation to how you’re describing the business. Being as precise as possible when defining the terminology to be used during your business process decomposition helps control how the terms are interpreted by the teams and helps minimize ambiguity.

The Art of Describing the Business

Agreeing on terminology is one thing — describing your business in these terms is another. Projects often struggle with this due to the nature of the different process areas of the company. For example, the Order-to-Cash scenario breaks down into a collection of processes such as:

• Inquiry Management
• Contract Management
• Customer Order Management
• Delivery Management
• Invoice Management
• Cash Application

This seems pretty straightforward, right? Well, it is until you look at all the departments this scenario crosses. Inquiries may be in a marketing and presales group while cash application may be done by a finance team. However, from a business continuity standpoint, it makes perfect sense to tie these together in an end-to-end scenario.

Other scenarios can be challenging because of the way they are viewed by the business: “My processes don’t have end-to-end scenarios because they support other processes.” This is one of my favorite frequently raised objections to doing end-to-end business process decomposition. Often, it is raised by the production scheduling team or the warehouse management team, because they feel their activities are all supporting functions and aren’t end-to-end processes.

When this happens, I encourage the business to think in terms of another company. Could you outsource the functions entirely? Could a collection of activities be grouped to become a shared service? For example, when I talk about production scheduling, I like to use the demand-to-plan scenario. The schedulers don’t really care whether the product demand comes from a sales forecast or the need to replenish a third-party warehouse. They just know there is a demand to be filled and they are to create a production schedule (or plan) to meet that demand — hence, the demand-to-plan scenario.

Moving from Conceptual Definitions to Business Process Decomposition

After the terminology has been explained and everyone is in agreement about what is a scenario, a process, and a process step, it’s time to build your initial BPH for the project. Surprisingly, based on my experience, the process of building the BPH requires both a top-down and a bottom-up approach to get to the end game.

My preferred method of building the initial BPH is to gather small groups of business owners around process areas. I try to establish the meeting based on common high-level, end-to-end concepts such as order-to-cash, financial management services, procure-to-pay, hire-to-retire, or demand-to-plan.

The number and type of these end-to-end representations vary based on the nature of the business model, the size of the project, and the organization of the company.

Top Down vs. Bottom Up

Business process decomposition can be performed from the top down — by going from the broadest definition of a business function to the narrowest — or by going bottom up — going from the description of very discrete business activities (or steps) and combining them into sets (or processes) that can be further combined to form scenarios.

Some people are more comfortable with top down, while others are more at home using a bottom-up analysis. I find that you need a combination of the two, however, to do a thorough job of decomposing the business.

Top Down

When you’re in the workshops with the groups described above, you start by having an open dialogue to try to logically break down the business from the high-level scenario (e.g., Order-to-Cash) to the processes that support it (e.g., Order Management).

Then you take each process and work together to break it down into the business process steps. Try to keep the steps relatively high level, such as Create Orders or Goods Issue. This allows you to better align your process steps to SAP transactions. Also, it provides for a common level when describing those business steps that occur outside of the SAP systems — either manually, by third parties, or in other enterprise systems such as materials movements performed in a manufacturing execution system or by a third-party logistics company.

Bottom Up

Once you’ve walked through this, it is beneficial to perform a bottom-up reconciliation within the process area to make sure that your different scenarios are decomposed consistently. Look at the process steps in different processes to make sure that the steps are similar in breadth of functionality across different processes and processes have similar breadth of functionality across scenarios. By that, I mean that you compare the scope of a process in one scenario to the scope of a process in another scenario. 

For example, one scenario may have a business process of Customer Order Management that breaks down into the steps associated with creating and managing customer orders only. You wouldn’t want another scenario in the same process area, such as Product Recall, to have a process that has the same steps, such as alerting the customers, booking the trucks, picking up the product, receiving it into quality management, providing replacement product, and doing cost reconciliation.

This is the type of redundancy that can create absolute chaos in writing end-to-end test scenarios, documenting training, doing change impact assessment, and providing end-user support. 

Imagine yourself as the support person answering a call for Customer Order Management and then one for Product Recall. The way you search for supporting documentation would vary radically and make your job much tougher because there would be more than one place to go to get the information you need to support the end user.

Now imagine yourself trying to do a change impact assessment. Both scenarios have processes and process steps, but in the Customer Order Management process you’re able to work in a defined boundary of a single business process of managing customer orders. This is a discrete business function. Trying to reconcile this against the myriad of business functions contained in the Product Recall process described above would result in an inappropriate comparison.

This is not to say that the Product Recall process described above isn’t a valid collection of business activities associated with performing a product recall. It just crosses too many functional areas to be reasonable as a single process.

Consistency Check and Process Integration

When the team-specific workshops are complete, I hold another workshop with all the teams to identify shared processes and integration points. This workshop also serves to provide all the teams the opportunity to check with each other that the terminology of scenario, process, and process step are being applied consistently across the solution design.

Some team members might challenge, “Why are we putting in all this effort to describe everything this way? Can’t we just get on with building the solution? We’re under a time crunch, you know.” I answer these concerns by pointing out that we’re not implementing SAP, we’re implementing an enterprise solution enabled by SAP. Modern organizations have grown by acquisition, suffered bizarre and frequent restructuring, and have had some very interesting growth patterns that result in leadership groups that aren’t always aligned with how the business operates.

The purpose of the BPH is to establish a collection of business processes that describes what the business does regardless of which department or leadership entity owns the business process. The BPH needs to be completely void of silos. It should reflect the end-to-end processes the business runs that deliver value to its customers and show how the enterprise interacts with the marketplace. It is imperative that everyone call a horse a horse; a process must have the same meaning regardless of whether you’re talking about building subassemblies for production execution or closing a hedge position in Treasury.

The Science of Building the BPH

The BPH is a structure in SAP Solution Manager that becomes the single point of truth for the design, build, testing, training, and support of your business solution. Figure 1 shows the structure maintenance view of transaction SOLAR01, in which you build the BPH for your project. It’s important to note that you can build the BPH totally from scratch by entering your scenarios, processes, and steps, but I encourage you to leverage content provided by SAP in the Business Process Repository.

Figure 1

Structure maintenance screen of the BPH in transaction SOLAR01

Since this article is focused on how to use the BPH for establishing a business process management culture, I won’t go into more detail here. For more instruction on building this part of the BPH you should read my previous SAPexperts article, “Use Business Blueprints to Their Highest Potential for a Successful Implementation.” 

The Science of Shared Processes

Often during my workshops describing the business in terms of scenario, process, and process step, the question of process ownership comes up. While there are numerous ways to identify process ownership in the BPH, one of the most powerful is the structure shortcut. It comes down to keeping the single point of truth, well, single. 

If you look at processes that deal with handling products, you run into many scenarios that have to perform the process step of Goods Issue. Warehouse Management, Procure-to-Pay, Order-to-Cash, Quality Inspection, and other processes all have to get products out of inventory through a Goods Issue event. As you can imagine, this could mean that you end up with Goods Issue appearing all over your BPH. This would defeat the point of having a single point of truth.

To resolve this, I strongly encourage choosing an owning scenario or owning team for the process. That scenario gets the original structure node for the process step and all the other processes that use the step shortcut back to it. This establishes only one place to store all the documentation, configuration, transaction codes, work instructions, test cases, and user roles for every variation of a goods issue, while still representing its use through the BPH. 

Putting It All Together in an Example 

When starting your BPH workshops it is all too easy to get caught up in thinking about how your business operates rather than understanding the concepts of scenario, process, and process step. For this reason, I like to use fictitious business models to teach these concepts so that you can truly focus on them before adding the complexities of the business to the mix. Child Management Services, Inc., is one of my favorite fictitious companies because it’s kind of fun, virtually everyone can relate to it, and it illustrates the concepts your team needs for a successful BPH build.

Business Background

• Child Management Services, Inc.
  • Providing quality summer day care for your children so you can go about your life

  • Providing outings and other healthy diversions to keep your children constructively occupied during the summer vacation

Business Scenario: Whine to Shine

• Scenario Whine to Shine (W2S): Child is upset and complaining, and the business value is to get the child back to happy
• Two scenario variations within the W2S scenario:
  • W2S — Ice cream (two variations: ice cream sundae and milkshake)

  • W2S — Entertaining diversion (two variations: movie and time at an amusement park)

Business Process Decomposition for Ice Cream Variation 1: Sundae 

• Processes
  • Receive awareness of upset child
    • Steps
      • Child exhibits long or frowny face
      • Child begins to whine
  • Determine ice cream resolution
    • Steps
      • Inquire about ice cream’s ability to bring child joy
      • Proceed to ice cream shop
  • Determine ice cream style
    • Steps
      • Offer choice: sundae or milkshake
      • Acquire chocolate sundae
  • Receive happy feedback from child and parent
    • Steps
      • Observe ice cream-smeared smile on child’s face
      • Revel in the fact that you’ll return the child happy to the parent
      • Return child to parent

      • Get paid

Business Process Decomposition for Ice Cream Variation 2: Milkshake 

• Processes
  • Receive awareness of upset child
    • Steps
      • Child exhibits long or frowny face
      • Child begins to whine
  • Determine ice cream resolution
    • Steps
      • Inquire about ice cream’s ability to bring child joy
      • Proceed to ice cream shop
  • Determine ice cream style
    • Steps
      • Offer choice: sundae or milkshake
      • Acquire milkshake for child
  • Receive happy feedback from child and parent
    • Steps
      • Revel in the fact that you’ll return the child happy to the parent
      • Return child to parent
      • Get paid

Note that in this example many processes and steps are the same in both variations. Now let’s look at what the BPH would look like in this example (Figure 2). As you can see, I’ve combined both variations of the process Determine Ice Cream Style by simply adding the process step of Acquire – Milkshake to the process step list.

Figure 2

Whine to shine: ice cream scenario variation

This enables you to keep the BPH structure as short as possible. Remember, the BPH should describe what the business does, not how the business does it. (You can learn more about how the business does it by reviewing process documentation in the General or Project Documentation tabs.) This simple structure allows you to show that the Determine Ice Cream Style process actually has two variations: one using a chocolate sundae and one using a milkshake. By having two process documents (or one with two variation sections), you can minimize the size of the BPH and avoid the risk of having documentation for the same process stored in multiple locations (i.e., the single in single point of truth).

BPH for W2S Entertaining Diversion — Two Variations: Movie and Amusement Park

The business process decomposition process illustrated above is repeated for the second scenario, W2S – Entertaining Diversion. The BPH for each scenario contains the union of all the business processes and the steps to support all process variations of the scenario (Figure 3).

Figure 3

Whine-to-shine BPH for Entertaining Diversion

Since some processes can be shared across the scenarios, you can begin using the BPH shortcuts (shown by the link image ) to reduce BPH complexity while preserving the end-to-end illustration of the scenario in the BPH tree structure.

The shortcuts in the BPH structure work just like a shortcut in Windows. When you create a document on your hard drive in a folder, you can create a reference to that document (called a shortcut) and store it on your desktop or other places on your computer. There is only one document stored, but you can get to it from multiple places. The same is true with the BPH shortcut. You create a BPH node in the owning scenario and create a shortcut in every scenario or process that shares the business activity.

Science Alert: How to Build Shortcuts in the BPH

While building your BPH, you can right-click a BPH node, select Copy, move to a new location, right-click again, and select Insert Shortcut. This copies any BPH node to a new location as a reference to the original node.

A shortcut must always be at the same level as the originating node. For example, you can’t copy a process and create a shortcut of the process as a process step and vice versa. Shortcuts are references to an originating node, and you cannot change the name of the node or make any other changes within the shortcut. Figure 4 shows what you see on the shortcut when you attempt to edit any of the tabs. Clicking the underlined name Receive awareness of upset child navigates you to the original node location in the BPH.

Figure 4

View of tabs on a shortcut

We’ve covered a lot here from both the art and science perspectives of performing business process decomposition. I encourage you to take some time to experiment with these concepts in a sandbox project in your SAP Solution Manager system. As in planning, developing the skills of building a good BPH that consistently uses the concepts of scenario, process, and process step will pay you back many times over as you move through your SAP adventure.

D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.

You may contact the author at solmanruss@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.