Go Flow

In earlier posts I write about Human “Facilitator” Processes and BPMN & Methodology Agnosticism where I make the point that how you draw a process diagram depends largely on the methodology you use to define the process, as well as the underlying technology that you are going to use to implement the process. That begs the question then: what is the methodology for human processes?

What is a Human Activity?

Before we talk about a method for drawing up human processes, we need to be clear about what a human activity is. Clearly it is work that is done by a human. This is not work that is done by a computer on behalf of a user. In order to focus on the human activity, we have to ignore all of the things that are done to facilitate that work. Or rather, we need to consider those things that facilitate the work, as part of the task itself.

Before anyone will perform a task, they certainly must be (a) informed that the task needs to be done, (b) given the details of the particular case, and (c) have a way to record the results of the activity. These are part of any human activity. When modeling human activity, we focus on the work to be done: wash the dishes, feed the dog, write the blog entry, decide the menu for dinner. Naturally, for a group of people to coordinate on these tasks, there must be communications between them, but we don’t model the communications. If I want my son to wash the car, clearly I have to tell him that I want him to wash the car, but I don’t think of that as a separate activity in itself. Instead, it is part of getting the car washed.

It should not come as a surprise that systems designed for supporting human activities allow you to model the work that is to be done at every step in a process, without worrying about how you will tell that person to do the work, or how the results are collected. Such systems often include customizable ways that each user can decide how they wish to be informed: some users prefer email, others like to receive an SMS message on their phone, etc. As a process designer, I want to focus on the task to be done (e.g. review this document) and should let the system take care of how that user is informed about the work to be done. Similarly, I know that an activity may be concluded with a decision (e.g. to either “accept” or “reject” the document), and that may effect the path that the process takes, but I do not want to be too concerned at the high level of how the system collected that response.

Besides the three required aspects of a human activity above, many human facilitation systems include the concept of a (d) deadline date for an activity, as well as (e) reminders about the activity and warnings that a deadline is approaching. These are convenient built-in capabilities to help manage the work.

So keep in mind that a human activity is a description of actual human work to be done, and that each activity is assumed to have (a) notification, (b) information, (c) conclusion, (d) deadline, and (e) reminders built-in. The following 9 step method can be used to create a model of a human process:

Step 1: Identify Human Work

Start by enumerating the tasks that must be done by people. Ignore for the moment the paper form, the data on the form, or how that form is passed around. Those who expect this to be a programming exercise may be tripped up by this because of the tendency to focus on the artifacts that help people coordinate their work. We need at this point to look at work itself. These are tasks that depend upon a human skill to do.

There are three reasons why an activity must be performed by a human:

1. In some cases there are decisions to be made that can not be automated and must be made by a person. For example, the determination of whether an article is fit for publication is a task that depends upon recent current events, suitability of the writing style, and the editorial preferences of a particular publication. Another example, the decision of which candidate is the best fit for an open position is a task that depends upon personalities of the the candidate and the team they would join, as well as an assessment of skills and ability to perform the job. These decisions must be performed by a person because the most relevant attributes may not be able to be expressed in a quantitative way, like political correctness or personality. The rule behind what constitutes acceptable quantities of these are tacit and are not consciously known by the people who evaluate such rules. But indeed there are people who are very good at making such decisions. This is work that will never be automated.
2. The second category of tasks are those which might one day be automated, but to do so would require additional prep work which has not been done. For example, you might need someone to enter figures from a financial report which is received either on paper or in an electronic format that is not easily consumable. For the time being, it is simply less expensive to pay someone to do this than it is to pay a programmer to write the code that automatically converts the information. Eventually, these will be automated.
3. The third category consists of physical tasks that must be done outside an information system. For example driving a forklift to load goods from a truck into a place in a ware house. Or to perform maintenance on a piece of equipment. It might be possible in the far future to automate these tasks with robots, but there are significant barriers to automation due to the physicality of the task. For the time being, we must treat these as human work.

These human tasks are made explicit so that people with the right skills can be identified, or so that people can be trained to do those tasks. Everyone involved in the process needs to know what they do — not just those performing the task — so that everyone gains an understanding of how the tasks they do fits in with what the others are doing. The human tasks need to be described in a way that the people themselves will understand using the specific vocabulary that the people in that organization use. There will normally need to be additional documentation associated that contains detailed information that is useful for training or skills identification.

Avoid including activities which do not involve humans. For example, running query on a database is something that might be need at some point in order to support a human task. At this point in the method you simply assume that the right information is available. There is a later step that defines what information must be available, and a final step that defines how that information is retrieved, but those should be defined at the right point, which is much later in the method.

Step 2: Determine Activity Conclusions

Human tasks can be concluded in more than one way. For example, the decision of whether to “accept” or “reject” an article for publication will be concluded in two ways: “accept” or “reject”. The conclusion of an activity is an explicit part of the activity itself. In many situations, there may be a third conclusion to this example activity which is something that means more or less “I am not qualified to make this decision”. That is a possible way that an activity might be concluded. Some activities will have acceptable time limits, and may be concluded simply by the passing of time. Each conclusion is given a name.

Conclusions are important communication events. When you model a human process, you are modeling thing that need to be communicated to the people involved in the process. Take for example the process of writing a book where many people are involved in various roles such as writer, reviewer, editor, etc. The writer will at some point declare that the book (a particular draft) is ready for review. While this concludes one phase of writing, more importantly it tells others that they may start their activities of reviewing and editing the current copy. The conclusion of a human activity is most often a speech act known as a “declaration”. A declaration is a statement that in the act of uttering it, changes the state of a group of people. Declarations often redefine what many people are expected to be doing. So it is with a modeled human process: the completion of one activity redefines what other people in the process are expected to do.

A conclusion should be considered a distinct conclusion only if it matters to the group. Take for example a task “Answer Question”. You might think of the answer to the question, as being the conclusion of the activity, and there are approximately and there is one (or more) answers to every possible question that might be placed. Clearly it is non-sense to consider every possible answer as a possible conclusion of the activity. Conclusions are grouped into sets which will effect the flow of the process further on. To be specific, if the flow of the process does not depend at all on whether the task is completed or not, then it is sufficient to say that there is only one conclusion: “done”. The president is given the choice to “sign” or “veto” a piece of legislation, and the process continues in different directions depending upon how this task is concluded. However, there is a time limit, and if congress dismisses before the bill is signed, then this situation is called a “pocket veto”. A “pocket veto” is considered to be completely identical to a “veto” as far as the process is concerned, so we would not need a separate conclusion for pocket veto: the timeout rule would simply be another way to conclude the activity as a normal “veto”.

Step 3: Put the Tasks into Order

The work and conclusions should be identified without getting overly involved in the sequence of activities. In many cases it is clear that a particular task needs to be done before or after another related task. There will also be branches, and certain tasks that are done only on certain conditions. This is where a diagramming tool becomes useful, but only if it can describe activities at the human level. If one activity must be completed before another, and that other activity can start as soon as the first is completed, then an arrow is drawn between them.

If an activity can be concluded in more than one way, and if each conclusion would cause the process to proceed in a different direction, then there can be an arrow coming out of that activity for each possible conclusion. Clearly, if the point of an activity is to “accept” or “reject” an article for publication, the process that continues after that point will be very different. Because this decision is the very point of the activity, the process becomes easier to read if there is a direct connection between the activity and the direction that the process goes. Some engines can not represent this in this way, and instead save the conclusion into a variable which is then tested at a following branch gateway. This is an accepted and common practice, but because the branch is removed from the human task, it is harder to see the direct causal link.

The result is a network diagram of the human activities that must be performed properly set in a process which indicates the conditions and order of the activities.

Step 4: Determine Performers

After the tasks and order are identified, one needs to determine who should do the tasks. This is highly dependent upon a particular organization. It is also changes from case to case. In some cases, there will be a pool of people who would be qualified to do the task, and anyone from that pool might be picked. What must be determined at this point is what set of rules will be used to determine who should do a particular job. It might be that a person with a particular skill is needed, and if a directory exists that lists all the people with that skill, then the rule is to find those people and pick one. More often the requirement will be that a particular person is chosen because of their responsibility in a particular part of the organization. For example, there may be a person designated to handle requests from a particular customer. Of there may be a person who is designated as handling all the purchase requests for a particular department.

Unfortunately such a rule can not be specified without specific consideration of the organization that will be using the process. Each organization will have unique organizing principles, some of which are based on historical accidents. Even across a single organization, the rules to determine who does a particular activity may not be consistent. Any organization that grew by mergers of other organizations will have some “special” parts of the organization that are not like other parts. There also needs to be consideration about the specific representation of the organization in an organizational directory. If skills are not tracked, then that can not be used to determine the person to perform the activity.

There generally will need to be an expression of some sort which can be evaluated in the context of the organization structure that resolves the assignee of a particular task. This expression will usually make use of pre-existing groups and/or job titles in the organizational directory. It may require new groups or job titles. There may need to be multiple levels of groups which includes groups which include groups. In some cases it may not be possible to determine a priori who will be performing a particular task. In some cases the assignee expression will narrow it down to a group of people, but immediate circumstances (who is available) may be necessary select the final assignee. It might be necessary for the users to self-select for a particular job. There may need to be case by case adjustments, since it is not possible to know everything in advance.

Step 5: Determine the Information to be Carried.

Here you specify a schema or a set of schemas which carry the information context within which all the activities take place. If the process is for a customer to open a bank account, then there is specific information that needs to be carried for that process, such as the customer name, address, and references to other accounts or credit history. The context schema needs to be a superset of all information needed for every activity. For example, if there is an activity to assess the property value of a house, then clearly the details about the home address, prior sales information, and various reports about the locale are necessary to perform this activity. If one activity produces a result which is necessary in a later activity, such as the assessed value of a house, then there much be a variable that will hold that information between activities. By considering the information requirements of every activity in the process, you can compile a complete context schema required by the process.

The information content will be modeled differently by different implementation engines. For some there is a single schema for the context that is shared by all activities (effectively a union of all schemas required by the individual activities). Others have a collection of schemas which are transformed back and forth through the process. Either way, the idea at this point is to identify the information requirements of the entire process.

Step 6: Define Access to Information at each Activity

At some points in the process, certain parts (variables) within the shared context can be read and updated. At other points that information can be read, but not updated. There are also point in the process where information is completely hidden because it is either not yet specified at that point in the process, or not relevant to that particular activity.

Step 7: Determine Timouts

An activity may have a requirement to be performed in a particular time period. What happens when that time period is exceeded? Does the process continue without the activity being complete, or does the process “fail” and go down a different path. There may be reminders that are additional notifications to the user that the task has not yet been completed. There may also be escalation to other people or management if the task is nearing the deadline without being completed. At this point for each activity, all time-dependent behaviors should be considered. Some tasks may have no time dependency at all, and may be allowed to remain uncompleted indefinitely.

We know that time equals money; so it is worth considering at this point the cost of every activity, as well as the cost to the organization of either delaying the activity, or not performing that activity. If you are simulating the execution of the process, these costs entered into the model can be acumulated across a simulation run in order to guide the further design of the process.

Step 8: Design the Presentation of the Information.

This puts a face on the context information, mapping the schema to a visual presentation. This presentation might be specific to a given activity, or might be the same presentation over the entire process.

Humans don’t read XML directly. Instead, the information has to be displayed in a way that is meaningful to the user. To be effective, the display should be organized for ease of use. Some of the information may be keys or links to other information, and the display should provide an easy way to access those external sources of information.

Technology to present the information is often described as “forms” in the BPM community, but you should keep in mind that any technology that can take data and generate a user interface can be used. The choice will depend on many factors outside the BPM system. Some organizations will choose Visual Basic or Java Swing because they have programmers experienced in these areas. Some might choose PHP or other web technique. They might have a powerful forms software designed specifically for this purpose. The process definition method should not get bogged down at this point in the specific requirements of the technology to be used. Instead, this step should focus on the look and feel of the displayed information.

Step 9: Integrate to Information Services

This is where the information needed in a process can be picked up from various sources and sent to various destinations. I use the term “service” in the generic sense of a “Service Oriented Architecture” (SOA). This might be through “web service” calls or any other means to access other service types. The point simply is that there is a human activity that needs a particular piece of information, and so this is where you specify how that information will be retrieved for that human user.

It is this step where you finally consider how data is sent and received between computers. Many process designers start by considering how data is transferred through the system, and it leads them to a communications centric view of the work. It can lead to activities that are optimized for computer communications, instead of being optimized for human work. Since the human costs far outweigh the compute resource costs in most business processes, it is important to start with the human tasks, and then work down to the integration tasks.

To access information from a web service, some of the process context information will need to be transformed appropriately into XML that is needed as input to a web service. The resulting XML may need to be similarly transformed to be put back into the process context. For example, if a in an account application, the process may need to access a “credit rating” service to retrieve the applicants credit rating for consideration in the application process.

Services are used not only for retrieval of information; it is also the point where you consider how the results of the human tasks will be sent out to destinations outside of the people directly involved in the process. For example if the decision is made to approve a loan of a particular amount to a customer, then there are various parties that may need to be informed about this decision (e.g. by email) and there would also be calls to services to actually set up the account and initiate the sending of a contract to the parties involved.

Summary
There it is; nine steps which lead to a model of a human process. Not a complete methodology by any means, but still useful. The steps are repeated iteratively, with reviews at various points. Usually after each step there is some segment of the organization that are interested in reviewing the progress. It is also true that later steps will turn up details which were left out of earlier steps, and so there is some iteration through the method multiple times. A good system will allow simplistic execution of the process before you are complete, so that you can try out the process along the way. After step 3 you should be able to run simulations of the process in order to gain confidence on the correctness of the process. After the process is implemented and deployed, you can collect statistics on how well it is running and cycle back through this to improve things. We call it “Business Process Management” because you are never completely finished designing the process. This method is repeated as long as the process can be improved, and there are always new ideas on how to improve the process or to respond to external changes.

At the last Gartner BPM Summit I gave an overview presentation on BPMN, XPDL, BPEL, and Wf-XML. Due to the positive response from the presentation, I was asked to record it so it could be accessed from the web. This is available and can be accessed by clicking on the link below. There are a few slides from my employer up front, please understand they support all my time and effort to make this information available to everyone for free, so after a few slides on the Fujitsu Interstage product, you will get to a fairly succinct overview of these four important standards.

Presentation Link

It runs about 30 minutes total. Enjoy.

Stephen White made a comment on my Human “Facilitator” Processes post that deserves highlighting.  You probably know the Stephen was the chairman of the working group that developed BPMN.

The discussion of the different diagrams shown in the post really have nothing to do with BPMN per se, but with the methodologies that would be used to model with BPMN. BPMN is generally methodology agnostic. The way that a process is modeled, to what level of detail, and what information should be captured, is really up to the methodology and the purpose for creating the process model.

He is completely right, and this is really really important.  I have discussed this with Stephen before, but this is something that very few of the experts seem to understand.  What he is saying is that the way you draw something with BPMN depends upon your methodology you use.  Given one method for one purpose (e.g. Automators) it would be right and correct to draw one way, but with a different method and different purpose (e.g. Facilitators) it would be right and correct to draw a different way.

This makes those who want ONE TRUE WAY to draw process diagrams extremely uncomfortable.  This was never the goal of BPMN.  BPMN instead had the goal to define a set of common elements that could be used for multiple different specific diagramming needs.  I might even venture that this is why BPMN did not have a meta-model to begin with.  I might also venture that BPMN success is precisely because it was flexible to be adopted in slightly different ways. Had it been overly rigid, it might have been rejected.

I would have said it slightly differently: that differences in the diagrams come from differences in the capabilities of the underlying system that will enact the processes.  This amounts to the same thing since tools are created with a particular methodology in mind, and that use of a particular methodology draws you to particuar tools.  What you are allowed to draw, and how you draw it, depends on things outside the BPMN standard.

What does this really mean?  It means that using one methodology one might draw a given process one way, while using another methodology one might draw it a different way.  Those who want a single diagramming approach, want a single methodology, as well as single set of underlying capabilities.  That would make life easier, in the sense that having a single flavor of wine would make life easier.  The world is not so simple, and some of those differences have great value and utility.

I have been arguing for years that disabled (greyed-out) menu items and buttons are in general a bad idea because it is impossible for users to know why the associated function is not enabled at the. It is quite frustrating: the user sees a menu command that looks like it might be what is needed, but it is disabled, and there is not at all obvious why it is disabled. I wrote a blog entry about this last year: “Please Don’t Disable My Menu Options!” and includes some references to noted UI experts on the issue.

Today a colleague pointed out to me a small advance in the area: the new UI guidelines for Vista include this recommendation:

Reconsider disabled controls. Disabled controls can be hard to use because users literally have to deduce why they are disabled. Disable a control when users expect it to apply and they can easily deduce why the control is disabled. Remove the control when there is no way for users to enable it or they don’t expect it to apply, or leave it enabled, but give an error message when it is used incorrectly.

• Tip: If you aren’t sure whether you should disable a control or give an error message, start by composing the error message that you might give. If the error message contains helpful information that target users aren’t likely to quickly deduce, leave the control enabled and give the error. Otherwise, disable the control.

Thank you, Microsoft. You have reaffirmed my faith that some day, user interfaces will be advanced beyond the “simple rules and superstition” that we have today. It is a SMALL step, to be sure, and still leaves plenty of room for misapplication. My experience is that programmers usually make the mistake of thinking that a user will find something obvious, because the programmer’s knowledge of the system makes it hard to understand the viewpoint of someone who does not understand the system. Consequently, we will see whether programmers will correctly estimate whether users “can easily deduce” why something is disabled. Even if the reason is obvious, why not go ahead and display a message spelling it out. Leaving it disabled is a lot like a taunt; e.g. “if you can’t figure out why this control is disabled, then you shouldn’t be using this product“. I have been taught that when a person asks a question, no matter how obvious the answer, it is most polite to simply answer the question. A small step in the right direction is better than none.

In my last post, I introduced the concept that there are two predominant views of BPM. One view is that of the Automators, who are creating business processes which replace humans by doing the same things that had traditionally been done manually. The other view is that of the Facilitators, who are creating BPM processes to involve actual people in processes can not and probably never will be fully automated. Both groups see themselves as making “human processes”, both groups create BPMN diagrams filled activities and gateways.

To illustrate the differences, consider a very simple process that represents a writer writing an article for a reputable publication, and an editor which must reviewing that article to make a decision on whether the article is suitable for publication or not. This is not a pretend process, this is a real process which when used in a real organization provides real value. A Facilitator would draw it like this:

That is all you need at a human activity level. In order to explain this process to a person who was to participate in this, the two nodes would be enough: Betty will write the document, and when completed, George with review the document. Both Betty and George understand their role in the process, and can go about their work.

An Automator is likely to look at this process and say it is ridiculously simple. People are not just sitting around like servers handling requests like “Write Article”. Automators are looking specifically at what the server must do, to enable the process. For example, the server does not write the document, but people do. What the server does is

• determine who should be the writer this time
• put the task on a task list that the user can browse
• some users also want an email message prompting them
• receive the email message back with the document in it
• remove from task list
• determine who should be the editor this kind of article
• put the task on a task list that the editor can browse
• some users also want an email message prompting them
• receive the email message back with the decision in it
• remove from task list

It gets more complex when you include features which are commonly included in a human BPM system. First of all, it is not always possible to know (with the data available to the system) who the write editor is. It might on the surface be an article about vacation travel, slated for the Travel section, but it actually is a news story about smugglers pretending to be on vacation. Many good human BPM systems give you the ability to reassign the activity to another person. So you need to add that there are two possible emails that might come back: one with the results, and the other saying “Joe should review this document”.

Second area of flexibility is the initial assignment of the writer. A good human BPM system will have a way to offer a task to a group of people, and people can accept the task, and bring it to them, informing the others that the task has been taken. This now makes the task list more like:

• send an email offering the chance to write an article
• receive email from first person responding that they will take the task
• send email to all the original group informing them that the task has been taken
• put the task on a task list that the user can browse
• send an email (some users)prompting for the actual writing
• receive the email message back with the document in it
• remove from task list
• determine who should be the editor this kind of article
• put the task on a task list that the editor can browse
• some users also want an email message prompting them
  • receive the email message back with the decision in it
  • OR receive an email sayting to reallocate to a different person, loop back a couple steps.

  remove from task list

Most good human workflow systems have a way to remind the users that they are approaching a deadline. A typical two step reminder is that the first reminder is to the person performing the task, and if that does not work, then an “escalation” reminder which goes not only to the performer, but also to a group of others who will look into the problem and see why it is no progressing. This adds a few more steps:

• send an email offering the chance to write an article
• receive email from first person responding that they will take the task (presumably you ignore any later email message to this effect, and drop them on the floor)
• send email to all the original group informing them that the task has been taken
• put the task on a task list that the user can browse
• send an email (some users)prompting for the actual writing
  • send reminder email to performer
  • send escalation email to wider group of people
• receive the email message back with the document in it
• remove from task list
• remove from task list
• determine who should be the editor this kind of article
• put the task on a task list that the editor can browse
• some users also want an email message prompting them
  • send reminder email to performer
  • send escalation email to wider group of people
• receive the email message back with the decision in it
  • OR receive an email sayting to reallocate to a different person, loop back a couple steps.
• remove from task list

Such a process might be diagrammed a bit like this:

I am sure there are MANY problems with the above diagram. If you would like to draw this process correctly, please do so and attach it to a comment (or email it and I will attach). I am not sure that a complex condition node can “loop back” to a previous task (that is what I want to do but it might not be allowed by BPMN guidelines) I am not sure how to have one timer go, and then a later time, and still allow that if the response comes before one or the other the process continues. I think I need to use a subprocess box to get that to work correctly. in any case, the exact way that one would draw this depends upon details of the system you are implementing on. For example, how did you recognize that the email was a completion email, or a request for reassignment. And what is missing from this is the requests that the user makes to the system to retrieve the current worklist. But this diagram is good enough for me to make a point.

The Automator is happy, because this diagram represent a more “truthful” description of what the system has to do. It makes explicit the various email messages that must be sent and received. What we have done here is to move away from the representation of what people do, and moved instead to a representation of what bits and bytes need to be sent and received by the system. The activities describe what the system does, not what the people do. That is great, if you are a programmer.

The detailed diagram has lost the representation of the fact that there are actually only two human activities being performed. You can’t really see what the people are doing, without getting lost in the details of what the system has to do to communicate to the people. The diagram could be simplified by hiding a lot of the detail in subprocesses, so you have only the two nodes at the top level and drill down to see the detail.

The point is not that “Automator” processes are more complex. My point is that with a human BPM system, the “Facilitator” gets a lot of capability built in “for free”. Simply draw an activity, and assign it to a person, and the human BPM system at that point does multiple things to inform that person that they have something to do. There can be built in mechanisms to negotiating who does that activity. There can be built in mechanisms for reassigning the activity. There can be built in mechanisms for reminder messages. And finally there is a built in mechanism to recognize when the person declares that they are done. All of these capabilities are common across any task you wish to give to a human. Why should you have to re-invent how to notify the user for every process? The Facilitator wants to focus on the human tasks, not the bits and bytes that the system sends and receives. The Facilitator learns that all these capabilities are built into an activity node.

But what to do? BPMN does not have the concept of assigning a person to an activity. BPMN was designed primarily (but not exclusively) by people with the Automator viewpoint. Much time was spent on how to translate to BPEL, which is exclusively Automator viewpoint. The BPMN group kept their options open, to allow for a Facilitator view implementation, but there are contradictions if you follow this path. This causes people to look at an implementation of BPMN, and way “that is not standard”. Indeed it is not: a Facilitator diagram does not look like an Automator diagram.

WfMC experts are again presenting the standards tutorials at two venues in Europe.

1. Poznań Poland.  Due to a big upsurge in BPM use in Poland in the past couple of years, we were invited to present a day and a half on Oct 8 and 9.  Here are links for overview and registration.

2. Paris La Défense, France.  We have long had membership in the coalition in France, it is nice to finally hold an event there on Oct 10.  Here is a links for  registration (in French).

WfMC members take note:  will be holding the fall meeting of the WfMC in Paris, hosted by TIBCO, on Oct 11 and 12.

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.

There has been a flurry of discussion on the Business Modeling and Integration Domain Task Force (BMI-DTF) at the OMG over the direction of development of the new versions of their specifications. Whether BPMN should have choreography capability or not. When BPMN should be linked to BPDM the meta-model and file format behind the notation standard. BPDM has essentially no adoption at this point, but it is still very new so this by itself is not indicative of anything. Yet some of the committee believe that putting BPDM into the BPMN spec will force adoption of this file format. Other feel that the combination will be too complex and possibly will inhibit adoption of the notation part. There have been several comparison between BPDM and XPDL. XPDL is in widespread use, and it appears the commitee members would like BPDM to do everything that XPDL does and more, in a much cleaner way.

The conversation often drifts to “marketing” and “adoption by end-user and vendor communities”. They talk about strategies and air play of their standards. It is as if marketing is some sort of genie that will step in and magically make their work adopted across the marketplace by fiat. To this, I have some suggestions.

Before diving into suggestions, I want to remind everyone that the standards process is driven forward by the huge efforts of a small number of very dedicated people. Most of these people truely want to build something that will be of lasting value to the high tech world. There are always, in any standards committee, a few who attend purely for self interest of promoting their own particular approach to become the recognized standards and then to capitalize on that. Such sheer self interest is ultimately detremental to the success of a standard, and so most successful standards committees tend to weed those people out when discovered. However, let’s assume for this discussion that the vast majority of those in the BMI task force are honestly motivated to develop something that solves a real problem, and such a solution would present a real value to the marketplace. In this case, I would recommend:

• Remember that no amount of “force” will cause a file format to become a standard. A standard must work and must provide a value. If it does not, it will not be used, regardless of how superior the design. Simply linking the file format with the notation in order to force its use will not fool anyone. Combining make sense only if BPDM can stand on its own merit.
• Remain focused on immediate real concerns. One of the more alarming comments was: “BPDM is designed to meet a business need that may not yet be fully appreciated by vendors or customers (who are distracted by proprietary marketing interests).” I would recommend focusing on needs that are appreciated today, or you may not have a chance to tackle the needs of tomorrow.
• Prove that BPDM works in many domains. There is a large body of real processes which are used for real business uses. The standards seem repleat with “toy” processes, such as the example of process between the patient and the doctor’s receptionist. While these are useful to as teaching tools to explain basic concepts, they fall short of actually proving that a meta-model is complete enough to represent the full range of semantics that are required for a real process. To do so, you need a broad coverage of a wide range of different engine types.
• Prove that BPDM is a superset of XPDL. Since XPDL is an XML based language, it is trivial to write a parser, and should not be difficult to write a converter. The exercise of writing this converter will assure everyone that all semantics contained in XPDL have a clear and unambiguous representation in BPDM. You should be able to demonstrate round-trip: from XPDL to BPDM and back, and the resulting file is not degraded from the original. This is in fact a goal for some committee members, but apparently not enough, because not even the specification for such a converter is available today.

My primary concern, without really knowing, is that BPDM is not complete (yet). The internals of XPDL are messy, and that is because real world processes are complex. I can’t count the number of times I have seen committees of people “reject” a defacto standard, in order to provide a far more elegant one, only to find themselves in the end proposing something just as messy as the original. These “new” approaches are often useful in some special case scenario, but are not necessarily able to handle a wide variety of cases. The BMI task force routinely claims that XPDL is a poor approach, but usually without any supporting evidence. It turns out that support for human processes is a very complex and subtle area. There are many different opinions on how to approach this, and those opinions come from different business cultures and customs. It is conceivable that the committee that designed BPDM are aware of only a subset of these approaches. This would be natural and will be resolved only through actual trial in the real world. Showing that one engine can use BPDM proves nothing, except that that particular engine is at least as limited at the standard. We won’t know that the language is complete until it can be demonstrated in use with a wide variety of existing engines.

All concerns would be eliminated with simply providing a BPDM/XPDL round trip converter. A small history lession: JPG raster image format became popular to a large extent because the JPG standard group provided a free tool for displaying and converting images to and from JPG format. Providing such a converter would make BPDM immediately accessible to more than 60 products on the market today. Allowing that converter to be freely embedded into vendor products will allow many products to claim BPDM support very quickly. This is, after all, the goal of the task force: to provide something of value that is adopted by the user and vendor communities.

To those of us wondering whether or not to bet on BPDM: we will know if the committee is serious as soon as they have made available a program that can convert an XPDL file into BPDM, and back again without loss. On the other hand failing to provide such a converter will give every indication to the market of being satisfied to remain an isolated and possibly esoteric file format. My humble suggestion to the BMI DTF is that they make this a top priority because this might be their best “marketing strategy”.

I have not written much about BPDM, the new metamodel specification from the OMG. It is a long spec, and it appears that lots of very good work has gone into it. Making a general metamodel to allow for interchange of all of the various types of process definitions that exist is both very important and also a very big challenge. So this effort deserves a lot of support.

One design choice though surprised me enough that I think it is worth a comment here. The BPDM 1.0 specification is designed to store process definitions in an XML file, but the layout of the process definition is not included at the current time. The “model” is stored (the nodes and relationships) but the positions of the nodes and the geometry of the lines connecting them are not stored at this time.

This is important. I have mentioned in the past that one of the goals of XPDL is to represent the diagram of the process so that these process diagrams can be exchanged between tools that people use in what we call the process design ecosystem. I have an example that may help illustrate the importance of preserving the layout.

Imagine that you want to travel on a subway train from station A to station B. In order to find your way, you need a subway map, which is a model of the subway system. At the very least, the model would need to include a representation of each station, and the trains that connect it to other stations. It is true, that this is all you need in order to calculate how to get from station A to station B. But imagine that you, as a person, look at the map, and every time you do, the stations are in displayed in different locations on the page! Such a map would be almost unusable because every time you would need to read the entire map. A lot of effort goes to making a subway map pleasing and easy to remember. As humans, we need things to appear in the same place every time. The layout of the map is a very important aspect of such a map.

I addressed a similar issue in a past post called “Thow Out The Diagram?” where I was surprised by discussions with people who felt it was right and proper to remove the layout information. Several people from the OMG working group assured me that this was not the case with them, and that layout information is simply delayed until the BPMN 2.0 spec (where BPMN and BPDM will be combined into a single spec) which is anticipated at the end of 2008. The reason is that there is already a proposal for including layout into an XMI format file, and that proposal was not mature enough to include at this time, but it is anticipated that OMG will be able to offer storage of layout in the near future. Nevertheless, and I can’t help feeling that this is a major limitation. If I use BPDM to convert my XPDL file to another format, it will lose a very important aspect of the process diagram.

So in summary, XPDL is still the choice for sharing process diagrams within a process ecosystem with over 60 process tools supporting the standard today.

Why is there all this concern about a single process standard? I was reminded of this while reading a recent article in “Viticulture Obscurant” about a similar situation in Elbonia with standardization of the broad range of wines, which I reproduce in full below:

——-

Elbonia - July 16, 2007 - Citizens and government officials of the republic of Elbonia have been up at arms, almost literally, about the bewilderingly large number of varieties of wine that are now available on the market. There is a growing movement to limit the number of varietals that can be sold in order to simplify the act of ordering dinner at the local restaurants. The diners’ complaint is that it is tremendously difficult to match the right wine with the right dinner because there is simply so many choices.

“The wine list at my favorite place has Cabernet Sauvignon, Merlot, Pinot Noir, Cabernet Franc, Grenache, Malbec, Montepulciano, Shiraz, Zinfandel, Petit Syrah, Sangiovese, Lambrusco, Dornfelder, Bovale Sardo, Schwarzriesling, Ruby Cabernet, Tinta Barroca, and Preto de Mortágua and that is just on the red list.” says the town Mayor Harrison. “It is difficult enough to pick from all these in the first place, but it gets worse when you consider vintages. You have to keep track of which years are good for which regions. What we need is a single wine that everyone can have for every occasion.”

This sentiment is reflected in a new standardization efforts on multiple fronts. One such group produced the Border Practice Multi-Index to define the way that a wine should look, smell, and taste, even though this group does not actually produce any wine. A representative commented: “We did not want to show favoritism to any particular variety so we took the best qualities of all wines, and came up with standardized descriptions. So when someone says that the wine has a ‘musty nose’ or that the ‘bouquet includes blackcurrants, eucalyptus, chocolate, tobacco’ we will all know exactly what they mean.”

The index however has been criticized because it still allows multiple varieties of wine to exist. One restaurant critic complained, “I thought the index was supposed to define the qualities of the perfect wine. A vineyard would then simply create a wine with all the correct qualities and you would have a wine for all occasions. If a vineyard produced a wine with some of the qualities, and not others, consumers could simply boycott that wine until it got the required components. That way all wine would be perfect for any occasion.” There is disagreement about whether this was the goal of the index in the first place.

A different group represented by the two largest grape growing regions got together to form the Basque Puncheon Evaluation League and decided that “Chardonnay” would be the single official wine in the industry. “I have had many many good meals with Chardonnay, and they all have turned out great! I really have never had any reason to drink any other wine. Besides, all those other flavors really confuse me and I find it easier to stick with a wine I know.”

Since that time, an entire sub industry has grown up offering “Chardonnay-only” wines, and producing recipe books that feature the varietal in cooking and serving of all kinds of cuisines. Wine masters have written well-received books saying that ‘the perfect meal starts with a layer of Chardonnay as the foundation.’ It seems almost as if nothing can go wrong as long as it has Chardonnay in it. When local diners ask their sommelier why Chardonnay was the chosen varietal, the answer given, after a brief look of vague hopelessness, is “because the two largest grape growing regions chose it, so we know it is going to be successful.”

While clearly simplifying the wine lists, this move is not without its detractors. One buvionist, speaking under conditions of anonymity said “The problem is that even though all these wines say they are Chardonnay, the don’t taste the same! Each vintner makes the wine in a different way, putting their own special enhancements to it, and the result is that each Chardonnay has a distinct taste. The original point was to have a single wine for all occasions. How is this achieved if they are all different?”

Sceptical of Chardonnay’s ability to meet the needs of every meal, an irrepressable band of vintners continue to produce red wines in the traditional ways. In spite of the desire for a single wine for all occasions, people have continued to enjoy red wines as well as other varieties of white wines. This has not gone completely unnoticed, and in a surprising move a number of Chardonnay vendors have acquired significant holdings in red-grape vinyards, clearly with the intent to enhance their line to include both white and red wines.

Even more suprising is the announcement from a group known as Winesap Blue for People who have announced a new varietal called “Chardonnay Dark” which is based on Chardonnay (and therefore the perfect ingredient for any meal) but includes many of the features of a fine red wine. The acolytes praise this move to finally provide a single wine that is good for all occasions. A prominent Elbonian wine enthusiast had this to say: “I tried the new Chardonnay Dark, and I really liked it. In the bouquet I detected hints of blackcurrants, eucalyptus, chocolate, and, yes, even tobacco! I expect to be drinking this with every meal in the future.” Unfortunately the wine will not be available for a few more years.

At the same time, and probably unrelated, is a new development called the “Omni-grape” from the Borg Province Dept of Metamagic. The omni-grape is a variety of grape that contains all flavors of all possible grapes. “With a vinyard full of these grape vines, you can decide at harvest time what kind of wine you want.” The technical literature about the grape only includes instructions for making Chardonnay, but we have been assured that all other wines can be readily produced, as soon as representative of those other varietals get around to defining the mappings. While this is clearly an important development, it has been criticized for not actually simplifying the final wine list.

So the situation is far from resolved. Every evening, Elbonians continue to face a daunting task to determine their libation. While some restaurants now offer the simplified Chardonnay-only list, it does not seem to have the overall effect that was promised. However there is hope that new standardization efforts are continuing so that one day, in the not too distant future, diners will be able to sit down to a satisfying meal without ever looking at a wine list.

—————–

It struck me that there are some surprising parallels between this situation and the one we find ourselves in the area of Business Process Management. By drawing this parallel, I do not mean to say that there should be as many process languages as there are varieties of wine. But I do mean to draw attention to how questionable it is to be hunting for a single process language for all situations. Different process languages are fit for different purposes. Work in an office space is complex. There are no simple solutions for that complexity, but still people yearn for a simple solution. We should instead focus how well a particular language worked in a particular situation.

Going to be at BPM Think Tank? I will. Maybe we can discuss this over a glass of something-that-is-not-Chardonnay.