With all the talk about “Human Facilitator Processes“; what actually does a real one look like? The best documented example of a human process is provided by the OMG known as the “Trouble Ticket” scenario.
This is a process to allow a software company to handle a customer support issue. This issue might be handled by the customer support team directly. If not, it is forwarded to the QA team for validation/verification and possibly handling the issue there. If it is a real problem in the product, it is referred to the development team for a fix. Before the process is complete, there are steps to assure that the customer who reported the problem gets the final resolution.
This is not a toy process like most of the example processes used in the various specifications. It is a real process that provides a complete important business function. While it is a simple process performed by people, it is important to support this with a process system because a business can not afford to lose track of customer issues.
If we follow the methodology for a human process, we start by identifying all the of the activities that are performed at points in the process. Please use the above specification for a detailed description of the process, but let me include below a summary of the activities involved:
Activity 1: Recording the Problem. Someone takes responsibility for making sure that no matter how the customer reports the problem (telephone, email, tin-can-and-string) the problem gets entered into the system.
Activity 2: Reproduce the Problem. A second person takes the description given and makes sure that the description is complete.
Activity 3: Correcting the Report. If the description was not complete, it goes back to the person who entered it to fill in the missing details. This is a sort of quality-loop on the report itself.
Activity 4: Identifying the Problem and Resolution. Development gets involved here to clarify what is happening, why it is happening, if it is a bug or not. If a fix is needed, then a new build may have to be produced.
Activity 5: Verifying the Resolution. QA gets involved again to second check that that the described problems was actually fixed.
Activity 6: Communicate Results. Regardless of how the issue was resolved, it needs to be communicated back to the customer in a way comfortable to them.
Activity 7: Audit and Record. This is a summary step in the process that allows the company to keep track of how things are going and possibly identify troublesome trends. (It is true that many good products today automatically capture this, but this process was created 10 years ago, and I prefer to keep to that documented process, than to deviate and have to document the process again.) Activity 6 and 7 are started in parallel because it does not matter which order they are performed in.
There are three main roles:
Customer Support: most likely a person who answers the phone when the customer calls, but they receive the communications by email or other means. In some cases there will be a specific support person assigned to each customer. Customer support performes activities 1, 3, and 6.
QA: The Quality Assurance team is providing two functions. Being relatively expert in the particular product, they are acting to resolve issues quickly without involving development when the problem is a known problem. If a fix is required, then the fixed version is tested to assure that it solves the exact problem that the customer reported. QA performs activities 2, 5 and 7.
Development: The people involved in the design and maintenance of the product, and the most expert on the product itself. While Customer Support and QA try to shield the developers from customer issues, ultimately the issues will come to development if not solved otherwise. Developers perform activity 4.
We can draw up the process and all the dependencies between activities in a BPM diagram using swimlanes to organize the activities for a particular role:
Click on the diagram to see a bigger version. The colors and shading is not strictly standard BPMN, so some of you may be interested in the BPMN classic view of the same process:
The first thing you might notice is that there are lots of branches, but very few branch gateway nodes. Instead, the activity is provided with multiple outbound arrows. Each arrow corresponds to a way that the activity can be concluded. This is, quite literally, the choice of the person performing the activity. Take a look at “Reproduce Problem”. You can see quite clearly that the performer of this activity must identify one of four significant conclusions: “Reproduced”, “Cannot Reproduce”, “Known Solution”, or “Duplicate”. It is very easy to see where the process goes depending upon which choice is made. The process designer can draw this directly on the process, without having to write scripts and conditional statements that test variables and branch depending upon values that have been stored in the variables. I have more on this in the “Multiple Conclusion Controversy” below.
Second, you might noice that there are a lot of implied loops. The “Reproduce Problem” step may determine that the problem is not reproducible, so the activity for “Correct Report” is activiated. The customer support person will add additional details and then send it back to QA to “Reproduce Problem” again. If QA still can not reproduce the problem they might again send it to the “Correct Report” problem. It could be passed back and forth between these people any number of times. In reality of course these are people performing the activities, so if it goes too many times they are likely to take steps to find out why it is taking so many step, or possibly to escalate to management. A similar loop exists between QA and Development when they don’t actually fix the right problem. Each of these loops represent a kind of “Quality Circle” where people are performing checks, and sending it back if not found acceptable. It is an easy way to model this fairly natural interaction between people.
Every activity is a facilitated human activity. This diagram is useful to explain to a customer support person, what other people will be doing in response to a customer issue. This diagram help people understand who else will be involved in response to particular decisions, such as whether the problem is reproducible or not. We can assume that there are also other automated computations, calculations, service requests, etc. involved in the process, but displaying them on this chart would make it more cluttered and harder to read, and therefor less useful for training people for how they are going to interact. Some people, though, will point out that this process is not “complete” because it does not include all the automated activities.
Multiple Conclusion Controversy
Let me address a comment that I often hear from people about BPMN processes who feel that “If a process has a branch, it should use an XOR gateway. It should not use two arrows coming out of an activity to branch.” This argument is based on the idea that activity nodes should be exclusively about performing actions, and gateways should be exclusively about the flow through a process.
The above Trouble Ticket process can be redrawn to use only XOR condition nodes to branch the process. It would look like this:
Compare this one (full size) with the original. There are three reasons why this is less satisfactory.
1. The diagram is more cluttered. Remember this is a simple process with only seven human activities. There are many business processes with many times this amount. The more nodes on the screen, the more visually cluttered it is, the harder to glance at and discern the meaning. The real question though is whether the addition of the XOR gateways actually makes the diagram more meaningful. Or the converse, if I remove the XOR gatways, how is the diagram less meaningful? The addition of the node (in my opinion) adds no extra value to the diagram
2. With the branch separated from the activity, it is far less clear why the process branches at this point. It could be because the human choice, or it could be anything else. You won’t know until you inspect the hidden metadata about the branch. Some branch nodes will the “data based” and some branch nodes will be “choice based” but that is not clear from the diagram. The “data based” branches must remain XOR gateways, but making the lines come straight from the activity make it entirely clear that the branch is because of the choice of the person performing the activity.
3. Part of the activity is to classify the result of the activity into a distinct number of “conclusions”. With the branch separated from the activity, it is less clear what choices the person has at that activity. You would be required to follow the lines out a ways. Consider the “Reproduce Problem” activity. If the lines instead come directly from the activity, it is clear that there that activity involves exactly four choices.
In conclusion, a simple rule that all process branching should occur at gateway nodes, causes diagrams that are lower quality and harder to read when it comes to human processes. When someone is trying to “automate” a process, the actions tend to be separate from the branches, but when someone is trying to “facilitate” a human process, it is more natural to remember that people often both do an activity and make a decision at the same time. For human processes, there is a huge advantage to incorporating the decision (choice) directly into the activity beacuse the process designer can simply draw the choice, and let the system deal with the details of capturing this choice from the user. This is again another difference between process automators and human process facilitators.
Find more on the trouble ticket process at:
We need to start using a real human process fo revaluation of whether the existing BPM standards make sense. This standard process is documented and published. The diagram that I used in this article was created in TIBCO’s studio process designer, exported to XPDL, and then imported into Fujitsu’sInterstage BPM process designer, and an example of the kind of interoperability that you can expect today. The XPDL is linked to the page above, if you are interested.