Intro
Although up until now I have kept all the intros in my articles very light-hearted to preface the rest of the sections with that same sense of fun, this intro might have a more stern tone in comparison, in order to create awareness that the topic of effective decision making should not be taken so lightly as it is important ❗ and one that impacts the profitability💰 of organizations.
So I will begin by pointing to relevant research performed by the folks that know their stuff (links to their whitepapers in the footnotes) :
Trusting that you will find both articles very relevant and insightful, I will add some of my pointers regarding process modeling.
Here I go! 😅
Process Modeling and the standards BPMN 2.0 and DMN 1.2 are not just documentation techniques
Many business transformation projects are budgeted and approved because there is a need to improve the bottom line.
There is a consensus that current ways of working and systems are outdated and a new state needs to be designed, enabled and monitored for continuous improvement.
Business and process analysis are capabilities that support in understanding the “Current State or As-Is”
The results from elicitation in "Discover" phases of a business transformation more often than not, provide evidence that processes and ways of working that were thought of being fairly standardized are in reality quite disparate; country variations are not uncommon and in some cases significant differences between offices/sites in the same country.
When we are not clear as to how we execute our tasks and make decisions “now” and agree on that; being able to determine what works and what needs to be re-looked at, becomes a challenge.
Leveraging process modeling that adheres to the well-known and yet at times not understood standards of BPMN 2.0 and DMN 1.2 is in actuality, the “capability” that has been there all along, waiting for us to notice and in addition, waiting for applications designed to bring the “fun” into it and awareness that it is a foundation for process intelligence, process mining and ultimately timely and effective business transformation.
Below is an infographic to communicate awarness on why diligent process analysis elicitaton is important
With this article I try to present how BPM and the DMN 1.2 standard can support an organization in taking decisions ensuring relevant business rules are designed and followed in SAP Signavio Process Manager and Process Collaboration Hub
Let's get cracking with the hands-on stuff: Value Chains, BPMN and DMN in SAP Signavio Process Manager!
What is Decision Model and Notation (DMN) and why should we care about it?
DMN is a standard from the Object Management Group (OMG) for precise specification of business decisions and business rules. You can check out their website: omg.org
For the purposes of this article I will try to answer the above question by presenting a sample and fictitious business scenario, and a general approach one would take in SAP Signavio Process Manager and SAP Process Collaboration Hub.
This is the scenario:
Sample Organization has had a period of not achieving KPIs related to collaboration with Sales Partners:
Cause: processes related to managing a sales partner are suboptimal
Current Process State:
Actions taken:
Future State:
Current State (As-Is)
AS-IS Process Model in PowerPoint
Process Name: Manage Sales Partner
Process hierarchies did not exist, all processes, including this one were managed separatly in sharepoint.
Below is the process model that, done in PowerPoint. It had not been updated for a few years and feedback provided by stakeholders that were around that time, communicated that it was modeled during a departmental meeting related to new ways of working and that a process owner was never formally assigned.
No other process or decision-making declarative or procedural knowledge was found. The knowledge regarding the processes and decisions was mostly tacit, and Sales Partners managed depending on the personal relationships existing in the specific periods of review.
For the purposes of this article, let us assume that we have already done al thel elicitation with all required stakeholders and we are aware of the gaps needed to be closed to have a stronger Decision Making process, and all that fun work produced the future state.
Future State
To Be Processes in SAP Signavio Process Manager and Collaboration Hub
1.- Process Hierarchy Identification for Sample Organization
Sample Organization decided that benchmarking APQCs PCF Cross Industry v.7.3.1 was relevant. (for more info on APQC go to APQC.Org )
The Process Category that deals with the management of sales partners and alliances is: 3.0 Market and Sell Products and Services (Figure 1)
Figure 1
Used with permission from APQC
Note: The APQC Hierarchy was created from L1 all the way down to Business Rule for this scenario
In SAP Signavio Process Manager the Value Chain diagrams were used to create the hierarchy for 3.0 Market and Sell Products and Services
Figure 2
The highlighted processes in green are the ones related to lower level oness that were designed to improve the decision making process.
They are at level 2:
3.4 Develop Sales Strategy
3.5 Develop Sales Plan
Lets continue to review the decomposition.
Within 3.4 there is a drill down to level 3 and then to a level 4 process that produces data relevant for the business rules:
3.4.2 Develop sales partner / alliance relationship (Figure 3)
> 3.4.2.8 Establish partner and alliance management goals (Produces Data) (Figure 4)
Figure 3
Figure 4
Within 3.5, we have 3 more related processes, each at their respective level:
3.5.5 Manage sales partners and alliances
> 3.5.5.3 Monitor and Evaluate partner/alliance results ( produces data) (Figure 5)
> 3.5.5.4 Extend or change sales partner/alliance relationships ( uses data ) (Figure 6)
Figure 5
Figure 6
We have now identified 👍 the 3 processes (Level 4) that are related to the new and improved Decision table, two produce and provide data that is necessary for the business rules, which feed into the third process where the decision takes place .
Figure 7
2.- BPMN 2.0 process model and DNM 1.2 model (Business Rules, Decision Tables)
Note: For the purposes of this article we are going to focus on process 3.5.5.4. The other 2 processes have also been designed, all tasks approved by process owner and defined data for the Business Rules, thus we have the input needed for 3.5.5.4.
The BPMN model was created in Process Manager. Note that Task 5 has a different attribute than the rest.
Figure 8 (this is a view in Process Manager)
Figure 8a (this is a view in Process Collaboration Hub. Since all diagrams were properly linked, it is easy to navigate up and down the hierarchy decomposition 😀)
Task 5: Determine actions for sales partner review was modeled as type “Business Rule” thus it displays the appropriate type symbol on the upper left corner.
Figure 9
The BPMN 2.0 diagram communicates that 4 Inputs are required for this task in order to make an educated decision. Based on the value combination of the Business Rules the potential decisions for this scenario are:
1 – Exit the relationship with a sales partner
2 – Extend the relationship with no changes to current contracts, agreements and penalties, or changes to the forecasted increments in sales targets in the time series.
3 - Extend the relationship with changes to current contract, agreements and penalties ir changes to the forecasted increments in sales targets in the time series.
Figure 10
A DMN diagram, where all business rules are maintained has also been linked to Task 5, this is also visible in Process Collaboration Hub (Note that the screen shot already shows the Option to “Run Decision” in collaboration hub, because all rules have already been configured in Process Manager)
The above DMN 1.2 model was created in Process Manager initally and the required business rules populated in the Decision Table. 🤝
Figure 11
The preceding processes and discussions with stakeholders defined that in order to improve all the KPIs that had been underperforming for a few years, management would need a set of business rules that would ensure the approproate action to handle a Sales Partner.
During the As-Is elicitation and the documented gaps, it became evident that underperforming Sales Partners had not been handled in an effective manner and that profits were impacted.
4 Inputs feed the decision table, coming from the predecing processes. (remember 😅)
Figure 12
Note: In this article I will not go into detail into all the different hit policies that can be used in a Decision Table. That is not the purpose of this articule, but you can read and learn either in SAP Help Portal (link) and in the Signavio training in learning.sap.com (link)
The summary I will provide is that the Decision table in the context of this scenario was designed with high targets to be met in order to keep a relationship with a Sales Partner in order to improve the business.
Executive management wanted to enforce that due diligence was implemented in order to correct the situation.
There are 4 inputs considered in the decision table:
These targets type are also made up for the purpose to display functionality of the decision table.
3.- Configuring the Decision Table
The table below was configured Hit Policy F - Single First (go to SAP Help Portal to understand all Hit Policies)
The table was designed with 10 rules (Note: A table can at times be designed with less rule lines depending on hit policy, the operators and interval types and provide same service or even sub-decisions (Depends on the skill. It is recommended that when there is a need for Human interaction with a decision table some rules are very explicit to indicate purpose and mandate)
Figure 13
Lets review a couple of rules:
Rule 1 is set to used by the decision simulator to provide the output "Exit" relationship if the business analyst presented data indicated the the Brand of Sample Organization is being eroded, even if sales are equal to or higher than 70% of the Volume.
Why such a tough rule? in this scenario, Sample Organization's profit has sharply declined due to brand erosion casued by underperforming sales partners in the last 24 months, thus the business rules became stricter.
Lets take a look at the Decision simulator that would be used in a meeting between the Sales Business Analyst, Sales Director and Manager of Sales Partners/Alliances.
Figure 14 -
The fields for inputs are empty the simulator is opened, and all three outputs are displayed
Figure 15
The user, in this case the business analyst helping in faciliate the meeting, would enter the required results, entering the results for the Sales Partner in review of achieving 83% of sales targets.
The progress changes to yellow, indicating that more inputs are needed. Note that the output section still shows 3 options for the actions to take.
Figure 16
The business analyst would then prepare the back up material to discuss, related to the next input, Brand KPI, which for this sales partner demonstrated that it had been eroding the brand consistently for 12 months.
The policy and the rule used in the configuration would produce the output: Exit
Notice that the progress bar is green, indicating that no other input is needed as the Eroding rule, does not need anything else, it trumps evertying else, based on the agreed business rules.
Lets take look at another rule
Rule 4 is set to provide outpur of Extend the relationship, however, the detail data provided by the business analyst would have to be discussed, because changes would be needed, perhaps in order to improve some of the KPIs, and to send a message to the Sales Partner that they need to improve.
Take a look at the inputs and the output.
Figure 17
What if the there was another sales partner with the same exact inputs, except a CSAT of 69% achieved?
Then Rule 4 would not apply, but Rule 7 would take care of the Action to take:
Figure 18
Providing the below output in the Decision Simulation, to Exit the relationship with the Sales Partner
Figure 19
For the purposes of this article I will not showcase the outputs of many other Input combinations.
The functionality of the Decision simulation input entry would provide the outputs matching the configuration of the decision table.
Note: The nature of this article is to display SAP Signavio Process Manager Capabilities. The business scenario used although based on plausible circumstances, is fictitious, thus its business rules might trigger interesting business questions as to their aplicability, or the types of discussions that could occur amongst the Business Analyst, Sales Director and Manager of Sales Partners/Alliances to handle the outputs.
Summary
The business scenario presented, and how it was handled following BPM best practices, BPMN2.0, DMN 1.2 and Decision Tables configuration standards in SAP Signavio Process Manager, convey the message of how powerful this application can be in supporting Lines of Business in any organization, in creating a culture/practice of Critical Decision Making based on business rules.
To touch on the pointers from the introduction; business transformations have as one of their objectives to improve the KPIs of an organizaiton. Profitability is impacted by decision making and thus, leveraging applications designed to improve decision making can only be of benefit in achieveing such targets.
Links to References:
About the Author
JD Wong-Loera is a Stockholm/Toronto based Project Manager, Business Architect and Process Management consultant who enjoys supporting others in understanding the Businesss Architecture and Business Process Management Capabilities. In his free time he enjoys camping, reading and boxing.
Check out my other blogs at: About JD_WongLoera - SAP Community
Gotland, Sweden
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
11 | |
10 | |
9 | |
8 | |
7 | |
6 | |
6 | |
5 | |
5 |