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.