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) :
In a Global survey from McKinsey in 2018, in which they analyzed companies from a larger range of industries, regions, company sizes, functional specialties and tenures; only 20 percent of the respondents say their organizations excel at decision-making.(1)
In the article from 1998 and updated in 2006, published by Harvard Business Review (HBR) titled “The hidden traps in decision-making” (2), John S. Hammond, Ralph L. Keeney and Howard Raiffa present the numerous factors that contribute to suboptimal business decisions: alternatives not well defined, data for analysis not collected or presented accurately, poor cost-benefit analysis and cognitive bias.
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 new state needs to be designed, enabled and monitored for continuous improvement.
Business and process analysis are capabilities that support in understanding the “Curren 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.
What is the baseline to consider for gap analysis?How to identify what is the most representative baseline of processes in relation to application usage?What will truly be process/application gaps and what gaps are a result of maverick process execution?
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 I created a few weeks back, 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
Lets 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:
Not hitting sales targets for partnersSuboptimal cross company collaborationSample Organization’s brand erosion associated with sales partners programsLower CSAT related to sales partner specific programs
Cause: processes related to managing a sales partner are suboptimal
Current Process State:
Process is represented in PPT format, overly simplified and not updated for a few yearsA critical decision in the process has never been executed in alignment with the Business Model and established strategy, analysis of past issues points towards cognitive bias from decision-making stakeholders.Lack of published business rules for decision-makingFormal meeting between the core stakeholders not in place
Actions taken:
AS-IS process elicitation done and process model agreed and reviewed with all stakeholders, and ready to be redesignedGaps analyzedMobilization of required stakeholders to design future state
Future State:
Process hierarchy established and Value chains created (SAP Signavio Process Manager)Design of TO-BE processes in BPMN 2.0, Business Rules for Decision defined, agreed and modeled in DMN 1.2, Decision tables created and tested. All directory entries created. (SAP Signavio Process Manager)All models published and Decision Simulation ready to be used (SAP Signavio Process Collaboration Hub)
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 separate in sharepoint.
Below is the process model that was modeled 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 the 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 processes 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 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 the right decision. Based on the value combination of the Business Rules the potential decisions 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 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 would need a diligent 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:
Brand KPIs: for this purposes, the business analyst in the “monitor and evaluate results” would perform analysis, and would consolidate all data regaring KPIs into 2 results: Brand enhancing – when the data indicates the relationship between Sample Org and Sales Partner enhances the Brand of Sample OrgBrand eroding – when the data indicates the relationship between Sample Org and Sales Partner erodes the Brand of Sample Org
CSAT scores and email feedback: the scores specific to customers specific to the Sales Partner, analysed and measured in percentage and defined as anything below 70% being non-conforming
People performance KPIs: resulting from analysing surveys on collaboration between Sample Org and Sales Partners; all data analysed finally producing 3 metric: High, Medium, Low
Sales Targets KPIs: Self explantory, achievement in % to the period target. Anything under 70% defined as non-conforming, but trumped by an Brand Eroding metric
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 has 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, depends on the skill.( It is recommended that when there is a need for Human interaction with a decision table some rules are 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 has lost millions of EUR due to brand erosion casued by underperforming sales partners in the last 24 months, thus the business rules were defined as such.
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 fictious, thus its business rules might trigger interesting business questions as to their aplicability, or 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:
https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/decision-making-in-the-age-of-urgencyhttps://hbr.org/2006/01/the-hidden-traps-in-decision-making
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
IntroAlthough 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) :In a Global survey from McKinsey in 2018, in which they analyzed companies from a larger range of industries, regions, company sizes, functional specialties and tenures; only 20 percent of the respondents say their organizations excel at decision-making.(1) In the article from 1998 and updated in 2006, published by Harvard Business Review (HBR) titled “The hidden traps in decision-making” (2), John S. Hammond, Ralph L. Keeney and Howard Raiffa present the numerous factors that contribute to suboptimal business decisions: alternatives not well defined, data for analysis not collected or presented accurately, poor cost-benefit analysis and cognitive bias.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 techniquesMany 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 new state needs to be designed, enabled and monitored for continuous improvement.Business and process analysis are capabilities that support in understanding the “Curren 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.What is the baseline to consider for gap analysis?How to identify what is the most representative baseline of processes in relation to application usage?What will truly be process/application gaps and what gaps are a result of maverick process execution?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 I created a few weeks back, to communicate awarness on why diligent process analysis elicitaton is importantWith 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 Lets 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.orgFor 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:Not hitting sales targets for partnersSuboptimal cross company collaborationSample Organization’s brand erosion associated with sales partners programsLower CSAT related to sales partner specific programsCause: processes related to managing a sales partner are suboptimalCurrent Process State:Process is represented in PPT format, overly simplified and not updated for a few yearsA critical decision in the process has never been executed in alignment with the Business Model and established strategy, analysis of past issues points towards cognitive bias from decision-making stakeholders.Lack of published business rules for decision-makingFormal meeting between the core stakeholders not in placeActions taken:AS-IS process elicitation done and process model agreed and reviewed with all stakeholders, and ready to be redesignedGaps analyzedMobilization of required stakeholders to design future stateFuture State:Process hierarchy established and Value chains created (SAP Signavio Process Manager)Design of TO-BE processes in BPMN 2.0, Business Rules for Decision defined, agreed and modeled in DMN 1.2, Decision tables created and tested. All directory entries created. (SAP Signavio Process Manager)All models published and Decision Simulation ready to be used (SAP Signavio Process Collaboration Hub) Current State (As-Is)AS-IS Process Model in PowerPointProcess Name: Manage Sales PartnerProcess hierarchies did not exist, all processes, including this one were managed separate in sharepoint.Below is the process model that was modeled 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 the 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 StateTo Be Processes in SAP Signavio Process Manager and Collaboration Hub1.- Process Hierarchy Identification for Sample OrganizationSample 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 1Used with permission from APQCNote: The APQC Hierarchy was created from L1 all the way down to Business Rule for this scenarioIn SAP Signavio Process Manager the Value Chain diagrams were used to create the hierarchy for 3.0 Market and Sell Products and ServicesFigure 2The highlighted processes in green are the ones related to lower level processes that were designed to improve the decision making process.They are at level 2:3.4 Develop Sales Strategy3.5 Develop Sales PlanLets 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 4Within 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 5Figure 6We 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 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 9The BPMN 2.0 diagram communicates that 4 Inputs are required for this task in order to make the right decision. Based on the value combination of the Business Rules the potential decisions are:1 – Exit the relationship with a sales partner2 – 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 10A DMN diagram, where all business rules are maintained has also been linked 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 11The preceding processes and discussions with stakeholders defined that in order to improve all the KPIs that had been underperforming for a few years would need a diligent 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:Brand KPIs: for this purposes, the business analyst in the “monitor and evaluate results” would perform analysis, and would consolidate all data regaring KPIs into 2 results: Brand enhancing – when the data indicates the relationship between Sample Org and Sales Partner enhances the Brand of Sample OrgBrand eroding – when the data indicates the relationship between Sample Org and Sales Partner erodes the Brand of Sample Org CSAT scores and email feedback: the scores specific to customers specific to the Sales Partner, analysed and measured in percentage and defined as anything below 70% being non-conforming People performance KPIs: resulting from analysing surveys on collaboration between Sample Org and Sales Partners; all data analysed finally producing 3 metric: High, Medium, Low Sales Targets KPIs: Self explantory, achievement in % to the period target. Anything under 70% defined as non-conforming, but trumped by an Brand Eroding metricThese targets type are also made up for the purpose to display functionality of the decision table. 3.- Configuring the Decision TableThe table below was configured Hit Policy F – Single First (go to SAP Help Portal to understand all Hit Policies)The table has 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, depends on the skill.( It is recommended that when there is a need for Human interaction with a decision table some rules are explicit to indicate purpose and mandate)Figure 13Lets 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 has lost millions of EUR due to brand erosion casued by underperforming sales partners in the last 24 months, thus the business rules were defined as such.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 displayedFigure 15The 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 16The 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: ExitNotice 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 ruleRule 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 PartnerFigure 19For 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 fictious, thus its business rules might trigger interesting business questions as to their aplicability, or types of discussions that could occur amongst the Business Analyst, Sales Director and Manager of Sales Partners/Alliances to handle the outputs. SummaryThe 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:https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/decision-making-in-the-age-of-urgencyhttps://hbr.org/2006/01/the-hidden-traps-in-decision-making About the AuthorJD 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 CommunityGotland, Sweden Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
