The Standard Process Model meets SolMan 7.2 Process Management

In this blog, I’m going to re-visit a blog I wrote last year about the folder structure in Solution Manager Process Management, and how it relates to the Standard Process Model. I feel have to go back to that blog, because (deep breath) I got it wrong – yes, I know. Incredible, isn’t it?

Well, I did preface my blog with a warning I was giving initial impressions, but still, some correction is in order. What I got wrong was trying to map the Standard Process Model illustrated below to what I thought was limited to seven folder levels (never confirmed that assumption there was such a limit) , and also how I related  variants to the folder structure in Solution Documentation.

The key insight I have now learnt is that the Standard Process Model is a conceptual representation of how processes, steps and activities are structured, and not literally how they are made into a hierarchical structure in transaction SOLDOC. Enough of the theory, what does a real-world implementation of the model look like?

Here’s a reminder of the Standard Process Model:

Source: https://wiki.scn.sap.com/wiki/display/ModHandbook/Process+Hierarchy

And this is how I’ve implemented it in Solution Documentation (minus the process steps):

Let’s go through each of the levels in turn.

Level 1 Business Area

Nothing controversial here, it’s pretty universal. It hangs of the Business Process folder, but it need not be the first folder after that one. There is scope to begin with a level that includes alongside E2E business processes project documentation in general.

Level 2 Process Group

Having broken the link between column position and model level, the first insight is that Level 2 need not be restricted to just one folder. Process grouping can be several nested folders as required to categorise the level 3 processes. And the route to process need not require the same number of folders. One Level 2 grouping can have subdivisions not required for another grouping. Thus the column that level 3 processes align to can vary.

Level 3 Business Process

The second insight was that Scenario is just a throwback to Solution Manager 7.1 projects. It need not be a marker for the last folder of a process grouping. In fact, it is best used as a marker for Level 3 Business Processes. This does seem to be the most contentious point, and confusing to end users for whom Scenario has a particular meaning aligned to E2E value chains. I’m willing to entertain I could be wrong again, but so far I can only see advantages with this approach.

For backwards compatibility after SAP Activate (I’m assuming that to be honest), a process must follow a scenario with no intermediate folder level allowed. That doesn’t mean however that the process icon level has to represent Level 3 Business Processes, because of the need to account for variants.

Level 4 Business Process Variants

A variant is a variation of a business process. One that has the same beginning and end points, but the sequence of steps is different and driven by the data. Nevertheless each variant is a process in it’s own right, and should be tested separately. The only place to represent a process is after a Scenario, therefore Level 4 must be implemented as real processes, from 1 to N (zero to N-1 variants).

So, there is some redundancy if no variants exists. A Scenario level will be required even if there are no variants, just the single process paired with a Scenario icon. An inefficient use of columns perhaps, but not without its advantages. The way around that would be to represent variants as different process diagrams, but that isn’t recommended (as it thwarts Test Suite I’m assuming, again). Also, HLD goes down to Level 3, so a quick measure when that has been completed is to see all folders tailed with a scenario.

Level 5 Steps

Process Steps as per normal. The whole area of of selection from the Process Step Library or executables is discussed in this blog.

Level 6 Activities

Executable assignments be they reports, transactions or Fiori apps.

So far so good with getting this approach adopted with business streams. We’ll see how well it pans out later in the project.