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.
98-02-09_original_scenario.pdf, also see 98-03-10-TroubleTicket_Nortel.pdf, and 98-07-13-TroubleTicket_Hitachi.pdf
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.
Conclusion
Find more on the trouble ticket process at:
http://www.xpdl.org/nugen/p/troubleticketscenario/public.htm
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.
Thinking Matters 
Pingback: the “trouble ticket” process « processi
I feel there are some missing items or oversights to this trouble ticket
1) At customer support: The reported issue can be a known issue already. A known issue can be broken into: 1) Known issue with no current solution 2) Known issue with work-around/solution 3) Known issue – Third Party Issue These would immediately go to the Communicate Results box.
2) This Trouble Ticket process does not seem to account for urgency and severity ; not all issues are created equal. There are severity levels (how bad of an issue) and priority levels (urgency/how much resources to apply).
Certainly these are good points for discussion.
1) You give three variants of the known issue arrow and I agree that these three cases exist, these could be drawn as three separate arrows on the diagram, but is this necessary? You are suggesting that all three arrows would go the same place, meaning that from a “who does something next” they are all equivalent. Regardless of which of these three reasons for being a known issue, the baton is passed from the QA to the Customer support, and the task is the same: communicate the result. So as a diagram of “who does what when” I would claim it is not necessary to draw these three as separate arrows, but let me also say that in some organizational cultures the distinction of these three may be so significant that is it important make each explicit. If this is true in your culture, then by all means, draw the line explicitly.
2) There are data values behind this which represent both severity and priority (read the PDF, they are mentioned) Those are not visible in the diagram. Priority and severity should effect the order that participants respond to multiple simultaneous workitems. It also might effect role resolution (who actually gets assigned to the role). But as you accurately point out, in this diagram the priority and severity do not effect the fundamental pattern of activities: do you think they should?
Pingback: bxModeller Initial Review « Go Flow
I agree with your arguments in the “Multiple Conclusion Controversy” section of this article. Unfortunately, BPMN semantics say that the conditional flows coming directly out of activities are inclusive — i.e. more than one could occur. A BPM would present the task to the user with something like checkboxes (where more than one can be checked) rather than as a radio button or drop-down. XPDL has a way to say that the outgoing flows are exclusive (), but BPMN doesn’t. 😦
You are right, there is no way to indicate exclusive outbound arrows from an activity. See discussion of this. But we did come up with a way that means almost the same thing. If you put event circles on the edges of the activity, and use an event to signal the end of the activity, then only on of the events can be triggered. It is exclusive by definition.
Pingback: BPM: BPMN? BPEL? Both? What's right for a process execution standard? | VOSibilities
Pingback: Representing Choice in a Process Diagram « Go Flow
I understand this is a late comment.
This is like a state diagram with swimlanes.
I’ve found myself creating state diagrams in conjunction with developing BPMN diagrams.
It seems that OMG has rearranged their site. I am looking to see if I can find this document anyplace else, because it appears to no longer be available on the OMG site. … but I found some copies and fixed the links.