More on keeping decisions and processes separate

Copyright © 2009 James Taylor. Visit the original article at More on keeping decisions and processes separate.Syndicated from ebizQ
Neeli Basanth posted this in response to my post Here’s how decision management simplifies process management and asked an interesting question:
No doubt the diagram on the right looks much simpler and purely shows the flow. Although it […]

Copyright © 2009 James Taylor. Visit the original article at More on keeping decisions and processes separate.

Syndicated from ebizQ

Neeli Basanth posted this in response to my post Here’s how decision management simplifies process management and asked an interesting question:

No doubt the diagram on the right looks much simpler and purely shows the flow. Although it no longer tells the viewer on how the decisions were made.

And this is, at some level, true. In response I would make a couple of points:

• While the simple example shows the viewer how the decision is made this “benefit” wears off quickly as the number of branches multiplies. Take a look at this example from my friends at IDS Scheer and the fact that the decision logic is displayed in the diagram no longer seems like a benefit.
• Even in simpler examples, the business person who defines the decision rules may not be the person who defines the process steps – if risk assessment is part of the decision it could be handled by a risk group while the process itself was handled by a customer service group. In these circumstances a degree of opacity in the decision-making logic may actually help by separating the concerns of the two groups.
• The pace of change might be quite different between the process and the decision. For example a discount calculation decision might change all the time as different groups are targeted and as competitors respond. None of this changes the order to cash process itself so separating the two isolates change more completely.
• In a long running process it may be more effective not to commit to the decision making approach when the process is instantiated, instead invoking (say) a rules engine to make the decision when the process reaches the relevant point. Separating the decision logic out makes this easier.
• Branches are not a great way to display logic. If there were even 10 rules that contributed to the risk it might be easier to understand them if they were displayed as a ruleset in a rules environment rather than as branches. Even with the extra look-up step the developer of the process might reach understanding quicker.
• Separating the decision logic allows it to be reused. Perhaps this is not the only process that needs to know how high risk an applicant someone is. Embedding the logic for the decision in the process might make the process easier to read but it embeds the logic making reuse hard if not impossible.

At the end of the day the decision logic is not the same as process flow or even process logic and I believe it should be managed separately.

Link to original post