There is a continual ongoing debate on how best to express how people plan to work together. Earlier posts make the case that two-dimensional graphical languages are inappropriate for knowledge workers. Many argued against this saying that these languages are still useful for process specialists. However, for unpredictable work, the knowledge worker must directly do the process planning. This post addresses the question of whether we might be able to use two languages in one system: one for the knowledge workers, and one for the business analysts.
Background
In order to help knowledge workers collaborate more effectively with their unpredictable work, we propose something called an Adaptive Case Management System (ACMS). Most office work technology has focused on the Taylorist view of predicting what has to be done, get an expert to define exactly the best way to perform a job, and then to codify that best process into software. That works fine for routine, predictable jobs. But, for unpredictable work it does not. Knowledge work requires autonomy.
Examples of the kind of knowledge work are:
- a doctor prescribing a treatment plan for a patient, and patients are unique.
- a lawyer persuing a court case, and court cases are unique
- a marketer launching a new film, and the circumstances of each release are unique
- a board member requiring corrective action, because each action is unique.
- a police detective following up on a crime, because crimes are unique
- an auditor investigating a possible infraction, and each situation is unique
- a manager running a political campaign, because every scandal is unique
In all of these cases, the plan must be made directly by the knowledge worker. Some will scribble on a piece of paper, some will type in an action item list, but there is broad agreement that a doctor will not draw a BPMN diagram. A police detective will not use a formal graphical language to describe the next step in the investigation.
The people defining standards such as BPMN and the new CMMN all agree that these graphical languages are for use by system designers — people who build systems. There is a category of person, known as a process analyst, who is not a traditional programmer (in the Java/C++ way), but instead help customize a system for a particular organization. The process analyst (sometimes called business analyst) is not a programmer but is still doing the job of designing the system for others. The process analyst spends most of their time working on process definitions, often helping others to do so. Since process representation is their primary job, learning a specialized language makes sense. Such graphical languages allow process analysts to be involved in developing/designing the system, without being a programmer.
Don’t get confused between a process analyst and the knowledge worker doing a profession. Most people agree that doctors, police detectives, executives, will not use BPMN or CMMN to express their process/plans. To the knowledge worker, the formal graphical language is a foreign language that they neither use nor care about.
Continual Improvement
One of the goals of such business technology is capturing and making work patterns better over time. The doctor may try a new treatment on a kind of patient, and finding that it works, desire to re-use that treatment in the future. Doctors are often working on the edge of what is known, as more becomes known of a particular disease or medicine, that treatment can become more routine.
The question is: how does something transition from unpredictable to routine?
Some envision the steady progression: doctors come up with and try out treatments using a simple check-list form. They list the things that the patient needs to do. Later, they find that a particular treatment is being used with some regularity. At that point, the system designers step in, and re-code the treatment plan into a formal language. There you have the best of both worlds: extreme flexibility for the knowledge worker while the process/plan is being invented, and yet rigor for the system designer when the process has matured.
At this point is looks like the two-language approach might work! One language for the knowledge worker (simple check list) and another for the system designers (graphical formal language).
Except for one little thing: knowledge workers do not invent plans whole-hog from scratch. They usually take an existing, approximate plan, and give a little tweak to it. A doctor does not invent a whole new plan for a diabetic patient showing signs of complications with one of the drugs. A policed detective does not invent a whole new plan of attack from scratch just because a new law made something a crime. Many of the patterns will be replicated from the past. The unpredictable part of work is not 100% unpredictable, but merely some small part of the overall work is different than it had been before. Nobody makes a completely new plan, but always starts with an existing plan and tweaks it.
Once the plan has be re-coded in the other language, a language that the knowledge worker does not know, then it is no longer able to be tweaked by the knowledge worker!
Adaptive
That is the problem with a two-langauge approach. Once a plan is moved out of the language of the knowledge worker, it becomes impossible for the knowledge worker to tweak. It becomes “un-tweakable”. What is needed is a “tweakable” representation of the plan.
Say that the doctors are a clinic develop a treatment plan (using check list formalism) for children with ADHD, and they successfully treat 100 patients with this plan, out of 200 patients over this time period. Since this is clearly a successful plan, the system designers decide to code this treatment plan using BPMN. What happens when patient #201 walks in the door? historically speaking, we can’t say for sure if the BPMN encoded plan is right for them. If the BPMN coded plan is invoked, and later the doctor discovers something unusual about the patient, they are stuck! Say that a particular procedure is not working, even though it worked for 100 patients, the doctor wants to remove that treatment, and substitute a different once. The doctor would have to cancel the current BPMN treatment plan, and start a new check-list oriented plan from the best available before conversion, and then make the modifications. Not only do you lose the benefit of the clinically enshrined process, you incur extra pain and cost on top.
Instead of re-coding the best plan as a formal “untweakable” graphical process, the clinic should take steps to authorize the best “tweakable” plan as a starting point for doctors. This way, the doctor can invoke the treatment without the worry of having to waste time if a change is needed later.
What is the advantage of bringing the process plan into the formal graphical notation? Advocates say it is because of accuracy of representation. A powerful language allows you to be very precise about what is done. Instead of a plan that needs to be tweeked half the time, you can make a powerful representation that has conditions and logic to cover more cases … maybe 80% or 90% of the cases. That works well when the process has to be fully automated and workers have no real responsibility. But, in the case of knowledge work, and unpredictable work, conversion to a foreign language only removes it from the reach of use by knowledge workers.
A smart doctor, then, ignores the BPMN coded process, and starts with older, tweakable plan. Half the time he is not going to need the ability to make a change, but those are the routine cases. The other half, however, is set up for instant improvement, whenever he needs to do it. That is the whole point of having a doctor involved in the first place.
A Prescription
The above argument convinces me that in the realm of unpredictable work, where creative knowledge workers need to have the option of tweaking a “best practice” template. “Tweakable” templates must be coded in the form friendly to the knowledge worker. They can not be coded in a formal graphical language for the process analyst or system designer, because we all know that knowledge workers like doctors and lawyers don’t use those languages.
This makes sense: the purpose of an ACMS is to support the knowledge worker: the doctor, the detective, the judge. The best-bractice plan templates MUST be coded in a form that is friendly to the knowledge worker! That is the purpose of an ACMS.
An ACMS that uses BPMN or CMMN for describing process plans will never be suitable for the very knowledge workers it is aiming to support. The idea that you can get a specialist (programmer or process analyst) to code up process plans for the knowledge workers falls apart when you realize that knowledge workers need to “tweak” the process plans. They can’t tweak something in a language they don’t understand. The two-language approach divides the workers from the processes they are working on.
When I started this journey years ago, this was not obvious to me either. It is not intuitive. One might expect a better language would alwasy make things better, even if used only for parts of the system. But, because of the adaptive, incremental nature of ACM, because of the way that knowledge workers needs to start with an approximation, and tweak it into appropriate shape, the conclusion is that the “best practice” example process plans need to be coded in less elegant — yet more accessible — form for the knowledge worker. Since to allow them to be tweakable none of the process plans can be in BPMN/CMMN, one must surely ask the question why these languages are needed at all in an ACMS?
Some have insisted that they want to use a BPMN based system to implement an ACMS. To the extent that BPMN is a programming language, it could be used to implement a system. Why would there be any advantage to doing this? Since the process plans that can be tweaked by the professionals can not be in that language, when then would you want to implement in that language? There are tasks in other programming languages that have noting to do with process plans. Java or C++ would be far more effective for all the things that are not process plans.
Summary
- Knowledge workers (doctors, detectives, etc) will not use a formal graphical language
- The descriptions of best practice process plans must be in a form that can be modified by the knowledge worker so they can be tweaked to the particular situation.
- Therefor, the best practice plans can not be in a graphical formal language.
- Instead, organizations should focus on collecting and sharing process plans in a non-graphical format.
- A single language is more effective and more efficient and a double language approach does not add any benefit.
Thinking Matters 
A good point that highlights that any language that can only be understood by the Developer will see persistence of the gap between IT and Business. BUT good news business logic never changes people and machines “doing something”. In reality there are very few such task objects generic to all business requirements. Express them as data inside a relational database and build takes place via graphical designer easy for business to follow. Use a declarative technique not a language to set up and that’s it! At work users only see their UI which is dynamically created for them at the right time and place. All far too simple for IT ……but it really does work supporting continuous change as no code change, generation or compiling.
That is a lot said in a short comment. The trick in making this all successful is in how it is represented to the people who use it. That representation, whether you call it a language or something else, must have the right affordances to let non-programmers make safe changes without having to know a lot of additional hidden details. We can store BPMN in a database, and we can even make it able to be changed on the fly, but that does not solve the problem. We need a representation that is designed for the kinds of changes that knowledge workers make on a daily basis.
You mention using a more declarative representation: there is lots of evidence that this is the right direction, but the proof is in getting a representation that actually works.
I think you are on the right track. Love to hear more about the details.
Pingback: BPM Quotes of the week « Adam Deane
Keith, good points and I am in agreement that BPMN or CMMN can’t be used for the performer.
But who says that one can’t have any kind of notation (using a model-preserving approach) in the background and hide it from the actual user. Clearly they won’t be able to use the expressiveness of that language or modeling notation but as you properly they don’t need it. As it happens, when these systems are put in place they are always put in place by some kind of process expert and they simply prefer to have some kind of notation, rather than just a DB with loosely assembled tasks.
If that’s all you have then the solution becomes very limited for anything that goes beyond loosely assembled tasks. And as it happens that is the reality. A lot of knowledge work happens in the context of other processes that are much more well defined. We allow users to add goals, subgoals, subprocesses, or tasks to a case and define simple dependencies or rules. Users can even add data or content through preconfigured servicetasks with or without data forms to the cases or goals. They never need to look at the BPMN flow that is created or modified as they do this. But when someone else wants to look at what they did or how a case was modified, we had unhappy users when we could not represent it as a model graph (we simply used state/event driven tasks before).
Yes, there is no code change or compiling to build a case from scratch. But there is a library of previously defined goal-oriented processes and tasks that the users can pick and chose from. And anyone who wants or needs to can look at the graph as well. For a pure case this just a set of task-frames inside a goal container. The graph doesn’t show anything more than a checklist. But if the users have defined task dependencies or constraints then the graph is a lot more informative than the pure list which would also show all information.
So I would propose that it is not as balck and white as your posts seems to suggest. There is no double language as it is just two different representations. The non-BPMN/CMMN approach to ACM is however a lot more limited in functionality and therefore cannot replace a BPM solution. That has been the crux of the ACM versus BPM discussion for years.
In this respect your post adds a lot of clarity to the positioning of the various ACM offerings which I tried to point out in this post: http://isismjpucher.wordpress.com/2011/12/11/adaptive-case-management-basic-full-or-strategic/
Any discussion of a complex topic is necessarily simplified, however I stick with my thesis on this topic. I never said you couldn’t use another language, I just mean that if you do, you lose the Adaptive aspect of the system. As I have pointed out in the past, BPM is a non-adaptive approach for routine processes. Production Case Management is a non-adaptive approach for some jobs requiring more choices by the workers. Both BPM, and PCM could be used by knowledge workers, but as they use them, they are unable to adapt them to their situations. A programmer can help modify them to improve them, you have a cycle of improving the process, and you might in a very loose way call this adaptive, but this kind of change is qualitatively different from what we expect knowledge workers to do in an adaptive system. Sticking with a clear definition of adaptive as being the ability of knowledge workers to change the process, my point is that two languages, one which is NOT understood by the knowledge worker, will prevent the system from being adaptive.
I have found that graphical depictions of the history of aggregated cases to be useful to knowledge workers. This should not be confused with a graphical programming language. I mention this because I agree that multiple visualizations can be useful. Charts and graphics of performance are more examples. But when it comes to planning, there needs to be a single consistent language used for one-off cases, and cases which have become standardized.