What is the role of two-dimensional process graphing for knowledge workers in Adaptive Case Management (ACM)? It is a given that an ACM system must support some form of process plan. This post explores how a knowledge worker might specify a process plan, what are the requirements on that means of specifying, and what technical training requirements exist for the workers who specify the processes.
Note: this is an excerpt from a position paper I submitted to the First International Workshop on ACM in Tallinn Estonia on Sept 4, 2012 in conjunction with the BPM 2012 Conference.
Within our current technology setting, essentially all discussions of business process make the implicit assumption that Business Process Modeling Notation (BPMN) will be the graphical language for expressing the business process. For the purpose of discussion, consider this decidedly radical proposition: “Any work support system that depends upon processes designed with BPMN (or BPMN-like languages) cannot be considered an ACM system.”
This statement is intentionally bold in order to question our basic assumptions about process modeling. Is it reasonable to expect case managers to ever have the skills to use a two dimensional BPMN-like process language? If not, does this lack of skill in itself become a barrier to effective use? The question is not how BPMN might have to be changed to suit case workers. What this is proposing is that whenever a system depends upon a two-dimensional design format for describing the processes, that dependence itself makes it unsuited for use as an ACM System (ACMS). The proposition is that an ACMS absolutely must not have BPMN, in order to be considered an ACMS.
Please note: this discussion is about the case manager’s use of BPMN for planning. The underlying system might be implemented in any technology: C++, Java, PHP, SQL, or even BPMN if your choose. This discussion is about the representation of the processes that the case manager must deal with. The case manager is a knowledge worker, like a doctor, a police detective, or a judge. A central assumption with ACM is that the processes are unpredictable, and MUST be viewed and modified directly by the case manager. We discuss those things viewed and manipulated by the case manager, and whether BPMN is appropriate for that purpose.
Definitions of Terms
Task – A task is the finest grained unit of activity. It is simultaneously, the finest grained unit of goal. Case managers define tasks/goals, and then break those into subtasks/subgoals. Eventually one gets to a level where the piece of work is assigned directly to someone. In this discussion we need make no distinction between the concept of a goal, a task, or an activity.
Process – A process is defined as a sequencing of tasks/goals. It is more than simply a collection of activities; in many cases tasks/goals must be sequenced in a particular order. Task A is anticipated to be and might be required to be performed before task B. The case manager needs some way to express this. There are higher order patterns like branches and parallel paths which might also be part of the logic of a process.
BPMN: This formally means the Business Process Modeling Notation standard developed by the OMG. At the time of writing, BPMN has gained such predominance that more than 95% of typical process professionals assume BPMN is the graphical language of choice for describing a business process.
BPMN-like: for the purpose of discussion, this term is used to describe any graphical 2 dimensional flowchart-like language. The broader question we hope to ask is not whether BPMN has exactly the right constructs, or what additional expressibility might be needed, but rather whether any 2-dimensional formalism can possibly be useful for ACM.
Business user: a person who uses the system who is not trained as an Information Technology (IT) specialist. All office work involves computer use at some level. Most users are not programmers. They have no specific training in design or management of IT system. When we talk about business user, we mean those people in the office without training in IT.
Developer: a person trained in IT and in this discussion is used synonymously with system administrator or other technical roles.
Case Manager: a business user who is responsible for a case in an ACMS.
In the early days of business processes management – we called it business process reengineering back then – I published a number of papers about graphical business process definition languages which were designed to be used by business people directly[1,2]. This visual language is surprisingly similar to BPMN with some superficial differences. The main elements were tasks, represented as ellipses instead of the rounded rectangles that BPMN uses today. Transitions between activities were arrows. There were specific nodes for branching and joining either parallel or alternative flow. Start and end nodes were hexagons instead of circles in BPMN. Most notably, events were represented as small circle on the edge of an activity. The diagrams that I drew as examples back then can be isomorphically translated into a BPMN diagram today, and the readability / expressibility is essentially the same.
I call these 2-dimensional languages because they are graph-like. An alternative is a simple list of tasks which does not have any X & Y position information, just a linear order. I have not seriously considered 3-dimensional languages. If you know of any 3-D language that show promise in being easier to use by business users, please comment and let me know.
At that time at Fujitsu, I was able to produce a system that supported the graphical definition of business processes, and the enactment of them. The most important aspect of that system was the ability to change the process at any time by anybody. An application would allow any business user of the system to retrieve and edit a business process at any point in time. In the later 1990’s this was all recoded in Java as an applet that ran in a browser so that any business user of the system could edit processes at any time without having requiring software installation. Simply point the browser at the server, to retrieve your task list, and you can also edit any process as well.
After 10 to 15 years of experience with customers using this system, my observation is that the business users essentially never design a graphical business process. Processes are always designed by either developers, or a specially trained business analyst. By “specially trained” I don’t mean to say that this is exclusive and esoteric. There are process enthusiasts who train themselves on process technology using freely available information. Those enthusiasts do not represent the typical knowledge worker. Even managers who design detailed interaction patterns for their team, will rarely actually draw a picture of the process themselves. Those innovative managers will hire process specialists who will draw the diagrams for them. Even office workers who are comfortable reading a process diagrams and who use them for training about a given process will rarely actually draw the process.
My conclusions (given here without any evidence) are that:
- Drawing a diagram requires a kind of abstract thinking about the process that a business user is not comfortable with. Instead, they want to define activities in terms of responsibilities on people, and not in terms of a flow of a token through a series of tasks.
- Drawing a diagram actually involves some programmer-like skills. For example, a branch node requires variables, which need to be set up in advance so that the branch condition can test those values. Separating the information into discrete units in a format that can be tested is a developer skill unfamiliar to business users.
- Modifying someone else’s diagram is particularly difficult because all of the assumptions that went into drawing the diagram are not present in the diagram. A simple example is that one node may initialize a variable, and another may use that variable, so switching the order of these nodes would break the functioning of the diagram. There is no way to indicate in the diagram might or might not be safe. Like most programming languages, it is designed to embody a set of assumptions, and not to necessarily express those assumptions. We can say that the original rules and assumptions are hidden by the resulting process diagram.
Relevance to ACM
A graphical process definition plays different roles in different styles of process technology. For example, in Process Driven Server Integration (PDSI) – a name for the kind of BPM which is commonly associated with a Service Oriented Architecture (SOA) environment – the process diagram is part of the programming process, or it may simply be in the design spec and completely replaced by the implementation. This programming and designing of the server integration is done by programmers, and not business users, so use of BPMN is not impeded.
For Human Process Management (HPM) – a type of BPM targeted at modeling routine human activities – it is a process specialist, or possibly a programmer, who designs a process which is used by the process participants. Typically in HPM the end user does not have to design processes.
The same is true for Production Case Management (PCM) where once again you have specialists who define the interaction patterns, which are developed and deployed as a finished application to the production users.
ACM however is different from these all of these because there is no distinct design phase. Designing and performing the work are done at the same time. There is no distinction between the users of the system, and the designers of the system. The knowledge workers (i.e. business users) themselves must design the process. Even if templates are supplied by process professionals, the case managers must be able to modify the process to fit their specific need, and so must be aware of all the assumptions built into the process diagrams. The essence of adaptive case management is that the processes are modified by the case managers, and are exchanged between people, in order that the workers can find the best solution for their particular field and situation.
Use of the Language
BPMN-like languages were originally designed for a completely different purpose and mode of use from ACM. Like many formal languages, the idea is that an expert will use the language to express something very precisely. The expression will take into account many understood rules, but may not express those rules directly. Using all this successfully requires programming skill along with an investment of time.
The value proposition is that the up-front cost of developing a process will be compensated by the increased efficiency later of the process. Thus, if you have many identical executions of a process, it is possible that a small increase in per-instance efficiency can counter balance a large up front development cost. Thus in most styles of process technology (PDSI, HPM, PCM) an investment up front is not a particular problem.
For ACM the process is designed by the case manager as they do the work, and usually just for the benefit of that one case. If things work out well, that process may become a template and reused many times, but each case manager must justify the effort of creating the diagram in terms of the case they are currently working on. From this see criteria 1:
- Ability to design a basic process quickly with very little investment by the user is far more important than the ability to define a precise process which uses more time an attention from the business user.
In ACM, process change is an everyday activity. If the ACMS were to require skill in BPMN to change the process, then the case managers without that skill will be prevented from using ACMS as intended. This brings us to design criteria 2:
- Process design must not require a skill beyond what business users possess.
Even if the business user is an expert in BPMN, they still may find it difficult to change the process because of the hidden assumptions problem. BPMN-like languages are designed to express a final process, and not all the steps and decisions along the way to develop the process. This brings us to the design criteria 3:
- For a process definition to be modified by business users, there must be no hidden assumptions.
A Process Language Designed for Change
The third criteria deserves a lot of discussion. It either means that a tremendous amount of additional information needs to be supplied with the program to express all the decisions behind the way the process is designed, or it means that there is a severe limitation on how complicated you process can be. I tend to believe the latter.
A case manager needs to be able to change a process quickly and effectively every time without error. This means that all possible changes need to be valid changes. If the case manager needs to switch the order of two activities for a good reason, there should be no possibility that such a switch can cause a failure of the process to execute. A language that is designed for change will allow (almost) any change,and will walk you through the resolution of any problems that arise because of the change.
It may not be possible for a programmer to express all of the reasons for designing a process in a particular way: why a particular structure, why a particular sequence, why a particular variable name, etc. It is not a matter of simply coming up with a reason for a particular approach, but these assumptions have to be expressed in such a way that they remain meaningful after the process has been rearranged. Writing all the rules behind what possible future process recombinations might be valid strikes me as being similar to proving the correctness of a program, something Gödel proved impossible. Even if it is possible, we can be certain that it is far beyond the skills and patience of a busy business user.
For this reason, I think that the right process definition language for ACM will be one that appears, compared to BPMN, to be very simple. It will appear to be very loose, flexible, and unstructured. However, it will be such that every business user can read and understand without special skills, and it will be one that can be changed in any way, without causing inconsistency. Some will question the utility of such an approach, but this is a case of “less is more”.
Frank Michael Kraft made a post called Adaptive Processes and BPMN where he asks the same questions. He points out that there are different styles of using BPMN. Different styles mean that two business users might use BPMN in different ways, and this is a problem if one tries to copy and modify the other’s process. It seems that this implies another criterion: the language must not dialects or specializations of usage that might differ across users.
He goes on to say that there might be an “Adaptive Style” of BPMN. If this style was enforced in order to be universal, it might be possible to avoid his dialect problem. It might even be possible to limit the power such that there are no hidden assumptions. I would have to see the details of “Adaptive Style.”
The litmus test will be: I can copy a task from one process, past it into another process, and it works. I can take a task at the end of a process, and move it to the front of the process, and it works. I can take a task, and duplicate it at some other point in the process, and it works. There are many ways to achieve this. One is to automatically “fix up” any syntax problems that arise. Thus, if the activity requires certain inputs from the process, the act of pasting it automatically adds to the process whatever is needed to provide those inputs. There are some simple cases that can be automatically handled this way, but you should also realize that there are some difficult cases that will be impossible to handle. One can attempt to express within the activity all of the external requirements — but this is extremely tedious, if possible at all. Thus the ability to patch things up is questionable at the basic level.
Max Pucher talks about “self healing” processes, but shows that it difficult or impossible to achieve in a post called Flowcharts and Goal-Orientation. He says “A process flowchart assumes all-out predictability” and goes on to say “Flowcharts Can’t Model Goal-orientation.” He has been openly opposed to the idea of using flowchart style languages for ACM, and this is well covered in a post “The Problem with BPM Flowcharts“. He says “BPMN 2.0 and flowchart models cannot represent real business processes, because a large business clearly is a complex adaptive system that consists of individual acting agents with its employees and customers. Trying to simplify a complex business into a ‘complicated’ one by decomposition into small steps, makes the model unable to adapt to the customer agents or to other environmental changes. Agent interaction is emergent and not designed.”
Peter Schoof hosted a discussion topic: Do we need a new modeling language for more adaptive processes? It is interesting to note how many of the commentators hold the assumption that BPMN is the language for ACM processes. This is some indication of a general misunderstanding of the distinction of ACM and other forms of BP technology. But mainly there is a feeling of backlash that there are too many standards today. I think we all feel this way: fewer standard proposals would make our lives easier. Wishful thinking, but the business world is a complex place: we should not expect simple solutions. I reject outright the accusation that this is just a ploy to sell books. However, we should do a thorough search of existing languages, to see if something might already exist that is not a flow-chart like language, and better meets the needs of the knowledge worker.
This is also a topic I have touched on before in “BPMN 2.0: no longer for Business Professionals” and followed up with “BPMN vs. professionals, 2.0“. These posts were discussing BPM, but clearly reflecting the realization that BPMN has become a developer oriented language. Please don’t misquote me as being “anti-BPMN”. I am a huge supporter of BPMN and have been for many years when it is used for the appropriate things. I am not against BPMN, I am just against the notion that it is the perfect answer for all questions.
The goal here is not to state any conclusions in this paper, only to raise questions for discussion. I hope that the results of the discussion can produce a set of actions items that can resolve the issue. What experiment or measurement is necessary to determine if flowcharts can be effectively used by business users? What experiment would show that checklists function more effectively? How can we determine the likelihood that business users will learn enough formal process modeling skills to be effective at ACM?
If you are able to attend the workshop, please come and join in on this discussion. Or comment below.
1. Keith D Swenson, A Visual Language to Describe Collaborative Work, Proceedings of the International Workshop for Visual Languages, Bergen, Norway, Aug 1993, see http://kswenson.workcast.org/1993/199308_VL93/VL93.pdf
2. Keith D Swenson, Visual Support for Reengineering Work Processes, Proceedings of the Conference on Organizational Computing Systems (COOCS ‘93) November 1993, See http://kswenson.workcast.org/1993/199309_COOCS/Coocs93.pdf
3. Keith D Swenson, et. al., A business process environment supporting collaborative planning, Journal of Collaborative Computing 1 (1), Chapman & Hall, 1994, see http://kswenson.workcast.org/1994/199405_Journal CC/1994_JCollabComputing.pdf
Keith D Swenson, Workflow for the Information Worker, Workflow Handbook 2001, Layna Fisher (ed), Future Strategies, 2001, see http://kswenson.workcast.org/2001/Workflow for the Information Worker.pdf