The AdaptiveCM 2014 workshop this past Monday provided a very interesting discussion of the state of the art in adaptive case management and other non-workflow oriented ways for supporting knowledge work. While there I presented, and we discussed, an intriguing new way to think about processes which I call “Business Etiquette Modelling”

Processes Emerge from Individual Interaction

The key to this approach is to treat a business process as an epiphenomenon that is a secondary effect that results from business interactions, but is not primary to business interactions.  The primary thing that is happening is interactions between people.  If those interactions are tuned properly, business results.

I have found the following video to be helpful in to giving a concrete idea of emergent behavior that we can discussion.  Watch the video, particularly between 0:30 and 1:30.  The behavior of the flock of birds, called murmurating, is the way that the groups of birds appears to bunch, expand, and swirl.  The birds themselves have no idea they are doing this.  Take a look (click this link to access the video – strange problem with WordPress at the moment):

The behavior of the flock is analogous to the business that an organization is engaged in.  With regular top-down or outside-in processes, you start with the emergent business behavior that you want to support, and model that directly.  To refer to the analogy, you draw descriptions of the bunching, flowing, and swirling of the flock, and from that you would come up with specific flight paths that individual birds would need to follow to get that overall behavior.  However, that is not how the birds actually do it!

You can simulate this murmuration behavior by endowing individual birds with a few simple rules:  match speed with nearby other birds, try to stay near the group of birds, and leave enough space to avoid hitting other birds.  Computer simulation using these rules produces flock behavior very similar to starlings shown in the video.

On the left you see the emergent flock behavior, and on the right the rules that produce that, but there is no known way to derive the rules from the flock behavior.  (These rules were found by trial & error experimentation in the simulator.)

The behavior of the birds in a flock emerges from the behaviors of the individual bird interactions — there is no guidance at the flock level.  This is very much like business:  an organization has many individual people interacting, and the business emerges as a result.  Obviously the interaction of people is far more complex than the birds, and business equally more complex than flock behavior, but the analogy holds: business can be modified indirectly by changing the rules of behavior of individuals.

Top-Down Design Runs Into Trouble

Consider the bird flock again, and approach trying to reproduce this the way that we do with a typical BPM approach.  In BPM we would define the overall process that is desired, and then we would determine the steps of everyone along the way to make that happen.  For the bird flock, that would be like outlining the shape of the flock, stating that the goal is a particular shape, and a particular swooping, and then calculate the flight paths of each of the birds in order to get the desired output.  That might seem like a daunting task for so many birds, but it is doable.  The result is that you will have a precisely defined flock flying pattern.

This pattern would be very fragile.  If you tried to fly where a tree was in the way, some of the pre-calculated bird trajectories would hit the tree.  If there was a hawk in the region, some of the birds would quite likely be captured, because the path is fixed.  To fix this, you would have to go back to the overall flock design, come with a shape that avoids the specific tree, or makes a hole for the predator, and then calculate all the bird trajectories again.  The bird flock behavior has become fragile because any small perturbation in the context requires manually revisiting, and modifying, the overall plan.

With the bottom-up approach, these situations are cleanly handled by adding a couple more rules: avoid trees and other stationary things, and to always keep a certain distance from a predator.  By adding those rules in, the behavior of the flock becomes stable in the face of those perturbations.  If we design the rules properly, the birds are able to determine their own flight paths.  They do so as they fly, and automatically take into account any need to change the overall flock structure.  Flock automatically avoid trees, and they automatically make a hole where a predator flies.  Note of course that we can not be 100% sure of what the flock will exactly look like when it is flying, but we do know that it will have the swooping behavior, as well as avoiding trees and predators.

The problem with modeling the high level epiphenomenon directly is that once you specify the exact flight paths of the birds, the result is very fragile.  Yes, you get a precise overall behavior, but you get only that exact behavior.  When the conditions change, you are stuck, and it is hard to change.  If however you model the micro-level rules, the resulting macro level behavior automatically adapts without any additional work to the new, unanticipated situation.

What is an Etiquette Model?

Etiquette is a term that refers to the rules of interactions between individuals.  Each individual follows their own rules, and if these rules are defined well enough, proper business behavior will emerge.  We can’t call this “Business Rule Modeling” because that already exists, and means something quite different. The term ‘etiquette’ implies that the rules are specifically for guiding the behavior individuals at the interpersonal level.

The etiquette model defines explicitly how individuals in particular roles interact with others.  There would be a set of tasks that might be performed as well as conditions of when to perform that task structured as a kind of heuristic that can be used as needed. Seletion criteris might include specific goals that an individual might have (such as “John is responsible for customer X.”) as well as global utilities, (such as “try to minimize costs” or “assure that the customer goes away satisfied.”)   The set of heuristics are over-constrained, meaning that the individual does not simply follow all the rules, but would have to weigh the options and choose the best guess for the specific situation.

For example, a role like “Purchasing Agent” would be fully defined by all the actions that a purchasing agent might make, and the conditions that would be necessary for such a role player to take action.   They might purchase something only when the requesting party presents a properly formed “purchase request” document, and which carries the proper number of approvals from the right people in the organization.  Defined this way, any number of different business processes might have a “purchase by purchaser” within it, and the rules for purchasing would be consistent across all of them.  If there is a need to make a change to the behavior of the purchaser, those ‘etiquette’ rules could be changed, and as a result all of the processes that involve purchasing would be automatically modified in a consistent way.

Isn’t this the Functional Orientation that BPM avoids?

The answer is yes and no.   Yes, it is modeling very fine grained behavior with a set of heuristics that tell what one individual will do to the exclusion of all others.  There is a real danger that the rules for one role might be defined in such a way as to throw a tremendous burden on everyone else in the organization.  This could decreasing the overall efficiency of the organization.  We can not optimize one role’s etiquette rules in exclusion of all other roles — we need to consider how the resulting end-to-end business process appears.

Given the heuristics and guidelines for all the individuals that will be involved in a process, it is possible to simulate what the resulting business processes will be.  Using predictive analytics, we can estimate the efficiency of that process, and particular waste points can be identified.  This can be used to modify the etiquette of the individual participants so that overloaded individuals do slightly fewer things, and underloaded individuals do a bit more, and so that the overall end-to-end process is optimized.

The result is that you achieve the goals of BPM: you are engaged in a practice of continually improving your business processes.  But you do so without directly dictating the form of the process!  You dictate how individuals interact, and the business process naturally emerges from that.

Is this Worth the Trouble?

The amazing result of this approach is that the resulting business process is anti-fragile!   When a perturbation appears in the organization, the business processes can automatically, and instantly, change to adapt to the situation.  A simple example is a heuristic for one role to pick up some tasks from another role, if that other role is overloaded.  Normally it is more efficient for Role X to do that task, but if because of an accident, several of the people who normally play Role X end up in the hospital for a few weeks, the business process automatically, and instantly, adjusts to the new configuration, without any involvement of a process designer or anyone.

Consider a sales example.  There can be multiple heuristics for closing a deal: one that explores all possible product configurations to identify the ideal match with the customer and maximizes revenue for the company, and another heuristic that gets things approximately right but closes very quickly.  As you get closer to the end of the month, the priority to close business in the month might shift from the more accurate heuristic, to the quick-and-dirty heuristic in order to get business into that month’s accounting results.  These kinds of adaptations are incredibly hard to model using the standard workflow diagram type approach.

The Amazon Example

Wil van der Aalst in his keynote at EDOC 2014 reminded me of a situation that happened to me recently with some orders from Amazon.  On one day I ordered two books and one window sticker from Amazon.  On the next day, I remembered about another book, and ordered that.  The result was that a few days later I received all three books in a single shipment, and the window sticker came a week after that separately.  The first order was broken into two parts for shipping, and then the second order was combined together with part of the first order.

This is actually very hard to model using BPMN.  You can make a BPMN process of a particular item, such as a book, which starts by being ordered and ultimately shipped, but the treatment of the order, by splitting when necessary, and combining when necessary will not appear in the BPMN diagram.  It is hard (or impossible) to include the idea to “optimize shipping costs” into a process that represent the behavior of only a single item of the purchase.

When you model the Business Etiquette of the particular roles, it is very easy to include a heuristic to split an order into parts when the parts are coming from different vendors.  Not every order is split up.  There are guidelines for when to use this heuristic that dictate when it should and should not be done.   Same for the shipper, who might have a heuristic to combine shipments if they are close enough together, and then shipping costs can be reduced.

This approach allows for supporting things like the Kanban method which constrains the number of instances that can be in a particular step at a time.  BPMN has no way to express these kinds of constraints that cross multiple processes.

Summary

Let’s discuss this approach.  My rather cursory search did not turn up any research on this approach to representing business process by representing the interactions between individual roles in the organization, although on Monday at the BPM conference I saw a good paper called “Opportunistic Business Process Modeling” which was a start in this direction.  I will make links to research projects if I find some.

This approach also works well for adaptive case management.  The heuristics and guidelines can be used within a case to guide the behavior of the case manger and other participants.  If this is done, then even though you can not predict the course of a single instance, you can use predictive analytics to approximate the handling of future cases.  This technique might be a new tool in the BPM toolkit.