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.
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.
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!
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.
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.
- 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.