Decisions vs. Business Decisions in a Process

I spoke at the e-gov Enterprise Architecture Conference in Washington in September and was asked an intriguing question by a visitor.  We were talking about the relevance of BPMN, as well as quality of support for BPMN.  What distinguishes human work from what can be automated?  As a reference, I used a very simple two step process which I often use in my presentations – Account Application – which is essentially a two step process once you remove the automated activities.  The second step is a “Decide whether to Create Account”.  His response:  “Would that be represented by a decision node?”

I was stopped in my tracks.  In this case it is NOT a decision node, but why not?  Sometime a conditional branch gateway is called a “decision node” since the server “decides” whether to go one way or another.  In reality, those nodes don’t actually make decisions.  The real decisions are made long before you get to this gateway.  Why then do we call them decision nodes?

Determining whether to create an account is a real decision.  If it is important to select the people who hold accounts, if there is a reason that some people would not be suitable to hold an account, then you must have some sort of process to clear applicants, and someone must decide whether to give out the account or not.  The decision, in the extreme case is easy: a well known wealthy local resident is an easy decision; a criminal convicted multiple times for monetary fraud is another easy decision.  The easy decisions might be coded into rules, but the rules will not cover 100% of all cases.  So therefore ultimately there must be a person to fall back on to make the tough borderline decisions.

The node he was speaking of is also called a branch point gateway.  The process branches to one of a number of possible directions at that point based on information available.  The branch might depend upon rules, but is any real decision being “made” at this point?  Wasn’t the “decision” made long ago?  Consider an example like: “An applicant with credit ratings below a certain value will not be eligible for loans over a certain magnitude.”  Without getting deeply philosophical about it, wouldn’t you say the “decision” is made at the time that this rule is drawn up?  After that time, the execution of the rule simply branches the process based on that former parameterized decision in a completely mechanized way.  This calls into question the real meaning of “decide”.

Do we call them decision nodes because we anthropomorphize the computer system that is executing the process?   You can imagine the server playing a role in the process, and doing things on our behalf.  After all, when we get to that step that says to email all the participant, WHO is it that is doing the emailing?  It is the server doing the emailing, right?  Therefore the server is playing a role in the process as an actor, as if it were a stand-in for a human.  I would agree that it is carrying out tasks that it is instructed to do, but is it really making decisions for us?

I one heard someone make the point that military personnel are trained to understand their responsibility in making the decision to launch weapons.  The radar may say clearly that there is an enemy plane flying a dangerous route, but it is the commander who decides to strike.  There may be rules that identification of a particular threat dictates a particular response, and sensory equipment may indicate the presence of  such a threat, it still it is still the responsibility of a person to interpret that sensory data, and take action.  Business decisions, while never quite as final as some military combat decisions, are and should be the same way.

A real decision is the kind that is not easy to make.  A collection of information will be presented to a person who is responsible for the success of the business, and a decision is made based on many factors that are difficult to quantize.  In some cases, there may be a gut feel.  Malcom Gladwell wrote a great book titled “Blink” which talks about the “native intelligence” which can tap into so much additional information in parallel, and which our conscious stream of thought does not have time to be aware of.  An experienced account manager will be able to sum up a case relatively quickly, and decide whether it is worth risking extending an account to this person.  (Interestingly, this same person may then come up with an explanation for why they made the decision, but that explanation might or might not actually be the real reason, but I digress to far….)

Let’s wave the magic wand for a moment, and imagine what it would be like if we could reduce all decision making to rules.  Then we might have the “one button office”.  This is the idea that you go to work every day, and in the middle of your desk is a single button, and you press it, and the system does all your work for you.  This was the goal of the office automation movement in the late 70’s and early 80’s.  The problem is that as soon as you isolate all the rules, there is someone who figures out how to play those rules, and you have to go and adapt the rules for this change in the environment.  While rules are very important in relieving us from the tedium of routine case assessments, there will never at time in the future be a point where we can stop adjusting and modifying the rules, and there will always be edge cases for which it will be quicker and more efficient to have a person simply “decide”.

A great example of a task that will never be automated is that of deciding which advertisement to run in the next promotion series.  More examples of non-automatable tasks include: the decision to merge two different companies together; the choice of which campaign slogan to use; the decision to hire or fire a team member; whether to run an article in a newspaper.  Let’s call these for a “Business Decisions” because they are the kind of real decisions that must be gotten right in order for the business or an organization to thrive.  Often business decisions depend upon a complex web of current events, legal and ethical constraints, as well as imperfectly known evidence.

Business Decisions are made at nodes which are activities which are assigned to humans.  A person need to perform the task of making this decision.  Those are the true decision nodes, not the branch gateways.

Let me take this a bit further: we know that there are at least two distinct “camps” in the BPM field: those that want to support human work (“Facilitators”), and those that want to automate work that was previously done by humans (“Automators”).  The Automators are always looking for example that can be completely automated.  For example, 30 years ago if I wanted to know my bank account balance, I would have gone to visit the bank and asked an attendant.  Now, of course, I access a web site, and it is 100% automated.  In that situation, all of the “decisions” that had been done by the attendant can be reduced to branch gateways, and you can think of gateway taking the place of the decision that the person used to do.  Facilitators, on the other hand, are looking for example processes which include tasks that can never be fully automated.  For example, a hiring process which includes deciding whether a particular person makes a good fit for the team.  The hiring decision is made by a person at an activity node, and this controls the flow later in the process.

The BPMN specification does in fact call branch gateways “decisions” and this term is in widespread use.   This shows that the BPMN is strongly grounded in the ideas of the Automators.  Facilitators will also use the term “decision” when talking about a conditional branch gateway, but a Facilitator will know that real Business Decisions are not actually made there.  At best, the conditional branch gateway is directing the flow of the process in response to a Business Decision made by a person in a previous step.  Perhaps there is clarity if the Facilitators would talk about a “Business Decision Activity” where a person is given the task of making a decision.  This also reflects on of the fundamental difference: Automators like to draw processes which describe what the computer will be doing, and Facilitators like to draw processes that describe what the people will be doing.  Both can be drawn with BPMN, but many of the current disagreements come from these different interpretations of the same symbols.

I will leave you today with a great quote from a presentation at the Gartner BPM conference by the Futurist Watts Walker:

Good decisions come from experience … and experience comes from bad decisions.

6 thoughts on “Decisions vs. Business Decisions in a Process

  1. Keith,

    I enjoyed this posting, and my response will be a very brief reply. As a Facilitator, and not an Automater, I have for the last past years always sticked to the heuristic that decisions are made by people; hence covered by BPMN human tasks / sub-processes, while the gateway is a kind of “passive construct” which routes flow according to the human-made decision.

    Too bad, also, that BPMN’s default task type is “service” and not “human”, but that is another (related) question.

    Steinar Carlsen

  2. Keith,

    From the perspective of an Automator that realizes that some decision will need human interaction from time to time, would it not be beneficial to use business rules to ‘help’ make the decision.

    You mention that the “decision is made at the time that this rule is drawn up”, this does not have to be true. If you write permissions statements in the form of business rules, you can allow facilitators to make the “final” decision.

    Eg. “An applicant with credit ratings below a certain value will not be eligible for loans over a certain magnitude.” However the applicant has just won the lottery and has a substantial amount of money in the bank, which could theoretically mitigate the risk of the poor credit rating. A permission statement would allow the human facilitator to overwrite the original credit rating rule after the consideration of the applicant’s bank account statement.


  3. Grant,

    That is right, there is the 100% rule case, the 100% manual case, and there is a grey zone where the rules would recommend one course, but it is so close to the border, that you want to get human input. In this case you display the “recommendation” from the rules (along with, hopefully, the reasons that the rules reached this conclusion) but this is a human activity that allows the person to make the final choice.


  4. Pingback: Human “Facilitator” Processes « Go Flow

Leave a Reply to aguda rasheed Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s