Short link
This article is for the business process expert configuring workflows in SAP S/4HANA and also sets the stage for what you can do when you develop your own workflow scenario (topic for a future blog).
It will help you to understand why this concept plays such an important role for flexible workflow in S/4HANA, but if you are impatient then jump to the very last section (Modeling) to learn how the process expert configures the mitigation to process exceptions.
One of the major simplifications that flexible workflow has made to S/4HANA is to remove the need for a graphical editor and all the complexities that this brings with it. If you don't believe graphical workflows are complex, look at this production workflow from a typical customer which is still in use today in a Business Suite installation. I.e. pre S/4HANA.
Fig 1. Pre-S/4: A Business Suite workflow approval as it is currently modeled
It is daunting enough to read and interpret it, so we can well imagine the amount of work that went into implementing it in the first place. This is clearly a job for an experienced (and deservedly well-paid) workflow consultant from IT!
Contrast this with a process modeled in SAP S/4HANA - An example covering the release of a sales quotation.
Fig 2. Typical workflow approval in S/4HANA
This is straight-forward, easy to read and understand, and very easy to adapt to changing requirements, such as a three step approval or different triggering conditions. Clearly this can be modeled by a business process expert from sales. Consultants that I have spoken to who have supported S/4 customers with their process modeling agree that although the first time a process is modeled it may be worth doing this with a technical consultant who has experience of transport and workflow in general, the colleagues from the business department recognize that once the confidence threshold has been reached, the domain expert rather than an external IT consultant can do this themselves.
To answer this question we need to dig down into the modeled process in Business Suite. What is important here is not so much the theory, as what happens in practice. The approval workflow shown in figure 1 has been is use for fifteen years, running many, many, thousand times a year.
To get real insight we should look at what the workflow looked like when it was first released by inspecting the version log.
Fig 3. Pre-S/4: That same Business Suite workflow approval when it went live originally
The process definition originally was simpler, but nevertheless far from simple. I could see from the history log (not shown in this blog) that the workflow has been changed about 100 times since the go-live in the year 2004. So on average it has been changed once every two months. Even a conservative estimate, assuming some of the iterations are simply very minor corrections, suggests around 50 significant changes altogether or a change once every 4 months.
Comparing Fig 3 with Fig 1 we can see that originally the process was simpler. Perhaps even by a factor two. So why has the process become more complex over time? A cursory analysis confirms that it is the exception-handling that has become more sophisticated. As more exceptions are discovered, the mitigations are automated, and the process becomes more complex.
The next step is to analyze the nature of the steps in the workflow. This workflow contains about 350 steps, and of those only about 50 are human tasks, the rest being background tasks (automated routines), or routing activities such as branches, comparisons, loops, calculations. By looking at the logs of the process I can see that there are 50 possible human tasks in the process (tasks which a colleague has to perform at their pc - such as an approval). That does not mean there are 50 different human tasks executed for each document approval, but 50 places in the process where a human task is possible. Normally only one or two tasks are performed in order for the process to complete - the straight-through route. Many of these human tasks are only used to handle exceptions.
Fig 4. Pre-S/4: Shaded area representing an estimate amount of workflow used to handle technical exceptions
All credit to SAP Business Workflow for handling such processes robustly and that the tool has enough features to be able to model processes with such precision. But twenty five years on from when this workflow tool was first deployed by customers (and 15 years since this particular workflow was built), we have to ask whether such a tool is appropriate to today's business acumen - where speed, simplicity and cost-reduction play an ever more important role.
I hope you'll agree with the following conclusions, not just about this workflow, but what we learned from examining other workflows in Business Suite deployments.
Conclusion 1: Even business domains believing that their processes are constant and don't change, underestimate the amount of changes that are made to a process after it goes into production.
Conclusion 2: Unraveling the as-is status involves time and costs. And this is before even contemplating a change to the process. The more complex the process, the higher the chance of error.
Conclusion 3: Automating the mitigation of exceptions is a significant part of process automation, and ongoing. Exception-handling plays a major role in continuous improvement.
Conclusion 4: The straight-through path for this workflow process is straight-forward. It is the exception handling that makes the workflow graphically complex.
So the SAP S/4HANA simplification mantra is a very worthy cause when it comes to BPM and workflow.
Put your hand on your heart, which is easier, a) writing a short script to handle an exception, or b) creating background steps in a workflow? Sure, encapsulating code in object/class methods is a good way of ensuring re-use, but how much re-use is required for technical exception handlers? And is it worth the total overhead of costs, taking into account: the execution performance overhead; debugging complexity overhead; knowledge-transfer overhead; transparency of execution overhead? Look again at Fig 1 before disagreeing.
Comparing the initial workflow in 2004 with the current state of the workflow you can see that the structure of process is similar, but the exception-handling has increased significantly. This is also reflected by a comparison of the ratio of dialog (human) tasks to the background (system) steps in the workflow over time. It is the system tasks, not the dialog tasks that are proliferating.
The reason that the S/4HANA approval workflow is so much simpler is that the technical exception handling has been taken care of by using code provided by the applications around the workflow. So although I don't expect your S/4HANA workflows to increase in complexity from release to release, it is a fair bet that the code provided by the applications before, after and during the approval process is extensive and probably will increase in volume over time.
This is why, when I present workflow to customers I use the analogy of a boiled sweet with a soft center. The outer-case of the process is coded and relatively rigid with configuration settings sufficient to describe typical scenarios. But the flexible workflow (approval steps) is the soft-center, fully under the customer's control.
Fig 5: S/4HANA Flexible workflow abstraction
We have seen how the complexity of a workflow implodes dramatically when the technical exception handling is coded outside the workflow rather than as part of the process. That is good news. So let's now look at non-technical exceptions. These are any situations where the flexible workflow doesn't follow the linear straight-through path from start to end. Typically in an approval process this is when a rejection or request-for-rework occurs, which in a traditional workflow would loop back to a previous step or in some cases abort the workflow.
These are treated differently from technical exceptions because customers modeling the workflows will often have different requirements about what follows, so they need to modeled in the workflow itself rather than the application code taking care of this directly.
I hope you appreciate that the traditional way of handling this with loops and branches can quickly eclipse the straight-through path (look once again at Fig 1) so a radically different approach was taken in S/4HANA: You can model the process exceptions directly in the process, simply specifying a course of action to take to mitigate the situation before continuing (or aborting) the approval workflow.
The S/4HANA applications use best-practice based on experience to specify the behavior and it will vary from application to application which process exceptions are envisaged. So for some processes, the approver pressing the reject button always leads to the workflow being aborted and the document deleted, in other applications this typically may be just a small stumbling block, and the workflow can continue after mitigation has taken place. So what you see defined as process exceptions and the possible actions that can be performed will depend on the workflow scenario itself.
We have seen that in a typical "straight-through" approval process, where the positive outcome is "approved", there are two types of exceptions:
Dealing with a process exception in flexible workflow is a major source of complexity in graphically modeled processes but it is simple to manage in the Manage Workflow Fiori app.
Using the example of the Sales Quotation scenario, you will discover that there is no process exception for "Rejected", because the application automatically cancels the workflow and does not release the sales quotation.
However, the sales quotation scenario does expose the exception "rework required", which occurs when the approver makes this decision instead of approving the release of the sales quotation. It is up to the business process expert to model how to deal with this.
Fig 5: S/4HANA - A process exception modeled in a flexible workflow
You can see from the screenshot that the colleague modeling the workflow can specify two subsequent actions that follow each other. The first is usually application specific (rework the sales order in this case), and the second action almost always determines how the workflow should continue after this action has been performed. e.g.. restarting at the beginning, repeating the current step, or simply moving on to the next approval without the need to repeat the current approval..
The choices vary according to the scenario. Some scenarios may contain steps that have no process exceptions to select, whereas others may suggest several process exceptions, the mitigation of each of which can be modeled independently. But the pattern of If this (process exception), then do this (mitigation) then do this (to continue) is the modus operandi offered by flexible workflow in other S/4HANA scenarios.
Some steps may include process exceptions where mitigation is essential, whereas in others the process expert modeling the workflow can select "do nothing" so that it is ignored. This will vary from scenario to scenario based on what is appropriate for that particular workflow scenario.
That unobtrusive entry-field tucked away at the bottom of the Fiori Manage Worflow app is an awesome blessing when it comes to process simplification and manageability (video of Manage Workflow app). There's no reliance on your IT department for configuring how to handle process exceptions. Your business process expert in this domain can configure the behavior herself - keeping control of the process flow, but avoiding the spaghetti of mitigation seen in traditional workflow modeling tools, including SAP Business Workflow.
That is one heck of an improvement ?.
Blogs: Previous | Next
This article is for the business process expert configuring workflows in SAP S/4HANA and also sets the stage for what you can do when you develop your own workflow scenario (topic for a future blog).
It will help you to understand why this concept plays such an important role for flexible workflow in S/4HANA, but if you are impatient then jump to the very last section (Modeling) to learn how the process expert configures the mitigation to process exceptions.
A Historical Use-Case
One of the major simplifications that flexible workflow has made to S/4HANA is to remove the need for a graphical editor and all the complexities that this brings with it. If you don't believe graphical workflows are complex, look at this production workflow from a typical customer which is still in use today in a Business Suite installation. I.e. pre S/4HANA.
Fig 1. Pre-S/4: A Business Suite workflow approval as it is currently modeled
It is daunting enough to read and interpret it, so we can well imagine the amount of work that went into implementing it in the first place. This is clearly a job for an experienced (and deservedly well-paid) workflow consultant from IT!
Contrast this with a process modeled in SAP S/4HANA - An example covering the release of a sales quotation.
Fig 2. Typical workflow approval in S/4HANA
This is straight-forward, easy to read and understand, and very easy to adapt to changing requirements, such as a three step approval or different triggering conditions. Clearly this can be modeled by a business process expert from sales. Consultants that I have spoken to who have supported S/4 customers with their process modeling agree that although the first time a process is modeled it may be worth doing this with a technical consultant who has experience of transport and workflow in general, the colleagues from the business department recognize that once the confidence threshold has been reached, the domain expert rather than an external IT consultant can do this themselves.
Why Were the Business Suite Workflows so Complex?
To answer this question we need to dig down into the modeled process in Business Suite. What is important here is not so much the theory, as what happens in practice. The approval workflow shown in figure 1 has been is use for fifteen years, running many, many, thousand times a year.
To get real insight we should look at what the workflow looked like when it was first released by inspecting the version log.
Fig 3. Pre-S/4: That same Business Suite workflow approval when it went live originally
The process definition originally was simpler, but nevertheless far from simple. I could see from the history log (not shown in this blog) that the workflow has been changed about 100 times since the go-live in the year 2004. So on average it has been changed once every two months. Even a conservative estimate, assuming some of the iterations are simply very minor corrections, suggests around 50 significant changes altogether or a change once every 4 months.
Comparing Fig 3 with Fig 1 we can see that originally the process was simpler. Perhaps even by a factor two. So why has the process become more complex over time? A cursory analysis confirms that it is the exception-handling that has become more sophisticated. As more exceptions are discovered, the mitigations are automated, and the process becomes more complex.
The next step is to analyze the nature of the steps in the workflow. This workflow contains about 350 steps, and of those only about 50 are human tasks, the rest being background tasks (automated routines), or routing activities such as branches, comparisons, loops, calculations. By looking at the logs of the process I can see that there are 50 possible human tasks in the process (tasks which a colleague has to perform at their pc - such as an approval). That does not mean there are 50 different human tasks executed for each document approval, but 50 places in the process where a human task is possible. Normally only one or two tasks are performed in order for the process to complete - the straight-through route. Many of these human tasks are only used to handle exceptions.
Fig 4. Pre-S/4: Shaded area representing an estimate amount of workflow used to handle technical exceptions
All credit to SAP Business Workflow for handling such processes robustly and that the tool has enough features to be able to model processes with such precision. But twenty five years on from when this workflow tool was first deployed by customers (and 15 years since this particular workflow was built), we have to ask whether such a tool is appropriate to today's business acumen - where speed, simplicity and cost-reduction play an ever more important role.
I hope you'll agree with the following conclusions, not just about this workflow, but what we learned from examining other workflows in Business Suite deployments.
Conclusion 1: Even business domains believing that their processes are constant and don't change, underestimate the amount of changes that are made to a process after it goes into production.
Conclusion 2: Unraveling the as-is status involves time and costs. And this is before even contemplating a change to the process. The more complex the process, the higher the chance of error.
Conclusion 3: Automating the mitigation of exceptions is a significant part of process automation, and ongoing. Exception-handling plays a major role in continuous improvement.
Conclusion 4: The straight-through path for this workflow process is straight-forward. It is the exception handling that makes the workflow graphically complex.
So the SAP S/4HANA simplification mantra is a very worthy cause when it comes to BPM and workflow.
How Are the S/4HANA Processes Modeled so Simply?
Put your hand on your heart, which is easier, a) writing a short script to handle an exception, or b) creating background steps in a workflow? Sure, encapsulating code in object/class methods is a good way of ensuring re-use, but how much re-use is required for technical exception handlers? And is it worth the total overhead of costs, taking into account: the execution performance overhead; debugging complexity overhead; knowledge-transfer overhead; transparency of execution overhead? Look again at Fig 1 before disagreeing.
Comparing the initial workflow in 2004 with the current state of the workflow you can see that the structure of process is similar, but the exception-handling has increased significantly. This is also reflected by a comparison of the ratio of dialog (human) tasks to the background (system) steps in the workflow over time. It is the system tasks, not the dialog tasks that are proliferating.
The reason that the S/4HANA approval workflow is so much simpler is that the technical exception handling has been taken care of by using code provided by the applications around the workflow. So although I don't expect your S/4HANA workflows to increase in complexity from release to release, it is a fair bet that the code provided by the applications before, after and during the approval process is extensive and probably will increase in volume over time.
This is why, when I present workflow to customers I use the analogy of a boiled sweet with a soft center. The outer-case of the process is coded and relatively rigid with configuration settings sufficient to describe typical scenarios. But the flexible workflow (approval steps) is the soft-center, fully under the customer's control.
Fig 5: S/4HANA Flexible workflow abstraction
What are Process Exceptions?
We have seen how the complexity of a workflow implodes dramatically when the technical exception handling is coded outside the workflow rather than as part of the process. That is good news. So let's now look at non-technical exceptions. These are any situations where the flexible workflow doesn't follow the linear straight-through path from start to end. Typically in an approval process this is when a rejection or request-for-rework occurs, which in a traditional workflow would loop back to a previous step or in some cases abort the workflow.
These are treated differently from technical exceptions because customers modeling the workflows will often have different requirements about what follows, so they need to modeled in the workflow itself rather than the application code taking care of this directly.
I hope you appreciate that the traditional way of handling this with loops and branches can quickly eclipse the straight-through path (look once again at Fig 1) so a radically different approach was taken in S/4HANA: You can model the process exceptions directly in the process, simply specifying a course of action to take to mitigate the situation before continuing (or aborting) the approval workflow.
The S/4HANA applications use best-practice based on experience to specify the behavior and it will vary from application to application which process exceptions are envisaged. So for some processes, the approver pressing the reject button always leads to the workflow being aborted and the document deleted, in other applications this typically may be just a small stumbling block, and the workflow can continue after mitigation has taken place. So what you see defined as process exceptions and the possible actions that can be performed will depend on the workflow scenario itself.
Modeling Mitigations to Process Exceptions
We have seen that in a typical "straight-through" approval process, where the positive outcome is "approved", there are two types of exceptions:
- Technical exceptions - dealt with by the application code or Fiori Workflow Administration apps (e.g. Document locked)
- Process exceptions - Deviations from the approval path (e.g. reject or rework)
Dealing with a process exception in flexible workflow is a major source of complexity in graphically modeled processes but it is simple to manage in the Manage Workflow Fiori app.
Using the example of the Sales Quotation scenario, you will discover that there is no process exception for "Rejected", because the application automatically cancels the workflow and does not release the sales quotation.
However, the sales quotation scenario does expose the exception "rework required", which occurs when the approver makes this decision instead of approving the release of the sales quotation. It is up to the business process expert to model how to deal with this.
Fig 5: S/4HANA - A process exception modeled in a flexible workflow
You can see from the screenshot that the colleague modeling the workflow can specify two subsequent actions that follow each other. The first is usually application specific (rework the sales order in this case), and the second action almost always determines how the workflow should continue after this action has been performed. e.g.. restarting at the beginning, repeating the current step, or simply moving on to the next approval without the need to repeat the current approval..
The choices vary according to the scenario. Some scenarios may contain steps that have no process exceptions to select, whereas others may suggest several process exceptions, the mitigation of each of which can be modeled independently. But the pattern of If this (process exception), then do this (mitigation) then do this (to continue) is the modus operandi offered by flexible workflow in other S/4HANA scenarios.
Some steps may include process exceptions where mitigation is essential, whereas in others the process expert modeling the workflow can select "do nothing" so that it is ignored. This will vary from scenario to scenario based on what is appropriate for that particular workflow scenario.
Summary
That unobtrusive entry-field tucked away at the bottom of the Fiori Manage Worflow app is an awesome blessing when it comes to process simplification and manageability (video of Manage Workflow app). There's no reliance on your IT department for configuring how to handle process exceptions. Your business process expert in this domain can configure the behavior herself - keeping control of the process flow, but avoiding the spaghetti of mitigation seen in traditional workflow modeling tools, including SAP Business Workflow.
That is one heck of an improvement ?.
Blogs: Previous | Next
- SAP Managed Tags:
2 Comments
