In a post titled “Business Etiquette Modeling” I made a plea for modeling business processes such that they naturally deform themselves as needed to accommodate changes.  If we model a fixed process diagram, it is too fragile, and can be costly to manually maintain.  While I was at the EDOC conference and the BPM conference, I saw three papers that introduce innovations which are not completely defined solutions, they represent solid research on steps in the right direction.  Here is a quick summary of each.

(1) Implementation Framework for Production Case
Management: Modeling and Execution

(Andreas Meyer, Nico Herzberg, Mathias Weske of the Hasso Plattner Institute and Frank Puhlmann of Bosch, EDOC 2014 pages 190-199)

This approach is aimed specifically at production case management which means that it is to support a knowledge worker, who has to decide in real time what to do, however the kinds of things that such a worker might do are well known in advance.  The example used is that of a travel agent:  we can identify all the various things that a travel agent might be able to do, but they might combine these actions in an unlimited variety of ways.  If we draw a fixed diagram, we end up restricting the travel agent unnecessarily.  Think about it: a travel agent might book one hotel one day, book flights the next, book another hotel, then change the flights, then cancel one of the hotel bookings — it is simply not possible to say that there is a single, simple process that a travel agent will always follow.

Instead of drawing a single diagram, the approach suggested is to draw separate little process snippets of all the things that a travel agent might do.  Here is the interesting part: the same activity might appear in multiple snippets.  At run time the system combines the snippets dynamically based on conditions.  Each task in each snippet is linked to things that are required before that task would be triggers, so based on the current case instance information, a particular task might or might not appear as needed.  Dynamic instance data determines how the current process is constructed.  Activities have required inputs and produce outputs which is part of the conditions on whether they are included in a particular instance.

Above are some examples of the process snippets that might be used for a travel agent.   Note that “Create Offer” and “Validate Offer” appear in two different snippet with slightly different conditions.  The ultimate process would be assembled at run time in a way that depends upon the details of the case.  I would have to refer you to the paper for the full details on how this works, but I was impressed by Andreas’ presentation.  I am not sure this is exactly the right approach, but I am sure that we need this kind of research in this direction.

(2) Informal Process Essentials

(C. Timurhan Sungur, Tobias Binz, Uwe Breitenbücher, Frank Leymann, Universtity of Stuttgart, EDOC 2014 page 200-209)

They describe the need to support “informal processes” which is not exactly what I am looking for.  Informal means “having a relaxed, friendly, or unofficial style, manner, or nature; a style of writing or conversational speech characterized by simple grammatical structures.”  What I am looking for are processes that are well crafted, official, meaningful, accurate, and at the same time responsive to external changes.   Formal/informal is not the same relationship as fixed/adaptive.  However, they do cover some interesting ideas that are relevant.  They specify four properties:

1. Implicit Business Logic – the logic is not explicit until run time
2. Different Relationships Among Resources – interrelated sets of individuals are used to accomplish more complex goals
3. Resource Participation in Multiple Processes – people are not dedicated to a single project.
4. Changing Resources – dynamic teams assembled as needed.

These properties look a lot like innovative knowledge worker pattern, and so this research is likely to be relevant.  They find the following requirements to be able to meet the need:

1. Enactable Informal Process Representation
2. Resource Relationships Definition
3. Resource Visibility Definition
4. Support for Dynamically Changing Resources

It seems that these approaches need to focus more on resources, roles, and relationships, and less on the specific sequences of activities.  Then from that, one should be able to generate the actual process needed for a particular instance.

The tricky part is how to find an expert who can model this.  Once of the reasons for drawing a BP diagram is that it is that drawing a diagram simplifies the job of creating the process automation.   Getting to the underlying relationships might be more accurate and adaptive, it is not simpler.

(3) oBPM – An Opportunistic Approach to Business Process Modeling and Execution

(David Grünert, Elke Brucker-Kley and Thomas Keller, Institute for Business Information Management, Winterthur, Switzerland, BPMS2 Workshop at BPM 2014)

This paper comes the closest to Business Etiquette Modeling, because it is specifically about the problem of creating a business with a strict sequence of user tasks.  This top-down approach tends to be over-constrained.  Since this is the BPM and Social Software Workshop, the paper tries to find a ways to be more connected to social technology, and to take a more bottom up approach.  They call it “opportunistic” BPM because the idea is that the actual process flow can be generated after the details of the situation are known.  Such a process can take advantage of the opportunities automatically, without needing a process designer to tweak the process every time.

The research has centered on modeling roles, the activities that those roles typically so, and also associating with the artifacts that are either generated or consumed.  They leverage an extension of the UML use case modeling notation, and it might look a little like this:

The artifacts (documents, etc) have a state themselves.  When a particular document enters a particular state, it enables a particular activity for a particular role.  To me this shows a lot of promise.  Upon examination, there are weaknesses to this approach: modeling the state diagram for a document would seem to be a challenge because the states that a document can be in are too intricately tied to the process you want to perform.  It might be that our preconception of the process might overly restrict the state chart, which in turn limits what processes could be generated.   Also, there is a data model that Grünert admitted would have to be modeled by a data model expert, but perhaps there are a limited number of data models, and maybe they don’t change that often.  Somehow, all of this would have to be discoverable automatically from the working of the knowledge workers in order to eliminate the huge up front cost of having to model all this explicitly.  Again, I refer you to the actual paper for the details.

Net-Net

What this shows is that there is research being done to take process to the next level.  Perhaps a combination of these approaches might leave us with the ultimate solution: a system that can generate process maps on demand that are appropriate for a specific situation.  This would be exactly like your GPS unit which can generate a route from point A to point B give the underlying map of what is possible.  That is what we are looking for, is a way to map what the underlying role interactions could possibly be, along with a set of rules about what might be appropriate when.  Like in a GPS when you add a new highway, you might add a new rule, and all the existing business processes would automatically change if that new rule applies to that case.  We are not there yet, but this research shows promise.