Decision Points and Data Models

The "Holy Grail" of BPM is to provide tools that "real" business people can use to automate their own business processes. This is really hard to do, in part because the tools are created by programmers (like me) and programmers don't generally think the same way that "real" business people do.

Most BPM tools operate on the principal that "drawing" is easier than writing. Draw the "flow" of the process using symbols (BPMN) rather than create a written description of the process. In my experience, "drawing" the process is a big win. It's fairly easy to teach anyone the symbols and how to "read" a process diagram.

Process diagrams are pretty much flow charts... Draw a symbol for all the tasks that may be performed and connect them with "arrows" that indicate the sequence of the tasks. If the sequence is not "fixed", then add "decision points" to the diagram to steer the process flow to the appropriate tasks.

Using standard BPMN notation decision points are drawn as a diamond shape as is shown in the following diagram:

After Task 1 is completed, a decision is made whether to perform Task 2A or to perform Task 2B, or to perform both of the tasks at the same time.

Here's where we have to depart from our "draw the process" approach: We have to resort to a written description of how to make the decision... something like:

• "If the amount is greater than $50,000, then do Task 2A."
• "If the amount is less than $50,000, then do Task 2B"
• "If the amount is exactly $50,000, then do Task 2A and Task 2B"

Surprisingly (to a programmer) "real" business people can have a lot of problems coming up with these statements. Many seemingly simple decisions may involve a lot of variables, a lot of nuance, and a fair amount of "gut feel". Ambiguity is a reality for business people, but it drives programmers nuts.

Not surprisingly, this is the point where BPM tools begin to be difficult for "real" business people. Tools can help, but resolving ambiguity is never easy... and the process definitions must be precise.


Once the hurdle of ambiguity has been cleared, the next hurdle is to identify the specific process variables that impact the decision. Programmers who build the BPM tools are masters at this sort of thing, but it's not as easy for business people.


Programmers and business people see data differently. Programmers see data as structured arrangements of elements that can have hierarchical relationships to each other. We see types and lists and maps and transforms and a host of other constructs that allow us to efficiently sort and search and organize and store data. We separate data from it's presentation to the user... the "same" data can be displayed in many different ways.


Business people generally see data as unstructured and flat... just like a spreadsheet. Data is associated with "forms". Data is information that is written on a piece of paper (or a computer screen). There is no separation between "the form" that is filled out and the data fields on the form. If a value, perhaps a person's zip code, is needed on another form, then it is copied from one form to the other.


In a BPM tool, when the business person is asked to "write down" how a decision is made, they're usually forced to use the programmer's view of data, not their own.


For example, let's assume that a decision involves a process variable called "LoanApplication" that has a field named "Amount". In most BPM tools, the business person would be expected to "know" the data model:


Condition for executing Task2A: LoanApplication.Amount >= 50,000

Condition for executing Task2B: LoanApplication.Amount <= 50,000


This example is not too bad, since the data model is fairly flat... but what if we get a bit more complicated? Suppose the information is in a nested structure in a list. Suppose that we have multiple Applicants and each Applicant has multiple Loan Applications. Our relatively simple statements become something like the following:


Condition for executing Task2A: ApplicantList[i].LoanApplication[j].Amount >= 50,000

Condition for executing Task2B: ApplicantList[i].LoanApplication[j].Amount <= 50,000


I've had business clients go into brain-lock when I show them something like this... I know that's hard for those of you out there with programming backgrounds to believe this, but it's a very common reaction.


What's generally missing from Process Design tools is a "conversational" method for discovering what the process variables are. Many processes involve a large amount of data, but in most instances the flow of the process is determined by a very small subset of the data. It's a needle in a haystack problem... Out of that mound of information, what really effects the flow of the process?


When a business person is drawing a process and comes to a decision point, they have a general idea what "variables"are necessary to make the decision.

What's needed is a "map" between the business person's view of the variable, and the programmer's implementation of the variable.


The trick is to take the business person's general knowledge about the process variables and work backwards to find out where each "variable" actually originates. In which steps of the process could a variable be created? In which steps of the process could that variable be changed? If you can work back and figure out "where" in the process a specific variable came from, then you have a much better chance of presenting the variable to a business person in a recognizable manner.