I am just now getting around to a post by Alxander Samarin called “Let us architect the use of existing technologies instead of blaming them for bringing complexity/inflexibility/etc. in enterprises.” This post starts with a well-reasoned overview of the situation, which is accurate and understandable. I highly recommend this post. However, while I don’t want to, I must disagree his conclusion.
Here are some things that he gets right:
- BPM is a management discipline, and we should not get this mixed up with the technology and/or tools
- His description of the difficulties of unpredictable work is accurate
- human-being’s knowledge, creativity and abilities are the critical success factor
- The word “automate” has to be clarified, and he does.
- case management shouldn’t try to replace a human, but assist him/her
- data capture / handling is an important part of this
- coordination is key, between individuals and groups, and involves patterns
- The aim is to provide an “actionable work execution coaching/guidance” for the business.
He understands the situation clearly, but how then can he come to the conclusion that “the BPM discipline is rather applicable for managing of cases“. There is a flaw in the logic that leads up to this, but it is not obvious.
He defines BPM: “to model, automate, execute, control, measure, and optimize the flow of business activities”. He refers to these as the 6 BPM functions. He says that there are many choices that you can make, and he outlines three example variations:
- one process definition (prepared in advance) for many instance (1-to-N)
- one process definition (prepared in advance) for each instance (1-to-1)
- No process definition in advance. (the zero case)
This gives you the feeling that there is a nice spread of possibilities over a range with no discontinuities, and therefor inclusive. But zero, is a very special case, not like the others.
BPM as a management discipline is based on Scientific Management. Central to this is the concept that the way of doing something, is separate from the doing of it. BPM is called “Business Process Management” and the word “process” within the title is not there by accident. BPM the discipline is based on the view that work (within an organization) is best thought of as a process. It is described as a process. The process is abstracted away from the workers, with the explicit understanding that one is trying to find the “best” process to use for all workers. But without a process, you don’t have BPM.
You can have parents with one child, parents with two children, parents with any number of children, but not zero. A couple with no children are not parents. Children are essential to the concept of parenthood.
The concept of a process is essential to BPM. Case management, on the other hand, might have a process, but it might not. Many cases have no process at all.
Example of case without process
I was challenged recently to give an example, so I have one: recently a group of us completed the “Mastering the Unpredictable” book project. I created a space to track this project: all of the initial concept documents were placed there, all the guidelines, the subject outline, the assignments of subjects to people, the rough drafts, and the final proof copies. I had never run a project like this before, so I had no process to run. Instead, when I needed to communicate I sent email to everyone (a capability of the system). The project space kept a history of everything that was done, and controlled access appropriately, but there was simply no process.
We had a goal to accomplish, and we coordinated work across three continents, but we had no predefined process, nor did we at any time engage in anything that might be construed as process modeling. In fact, given the 6 BPM functions, at no time did we model, automate, execute, control, measure, OR optimize the flow of business activities. A case management tool can support this kind of case. However, using the definition that Alexander supplied, we did not use not do the practice of BPM.
This is not a word trick
I am not playing a shallow game saying that since process is the “P”, if there is no process it can’t be BPM. The problem runs much deeper.
BPM is fundamentally about process. BPM practitioners views the world as a set of processes. Everything is a process, and we accomplish things by examining those processes, modeling processes, automating processes, executing processes, measuring processes, controlling process, and optimizing processes. The process is an abstraction of the way that work gets done, and the practice of BPM is to make it explicit. But case management does NOT have to do this.
I am sympathetic to the idea that a case manager is just a process designer who does the designing while doing the work — but this is a misleading concept. Thus, a doctor will design the treatment plan for a patient while the patient is being treated. A judge will design the course of action for a case while presiding over a court. An executive will design the action plan while running the board meeting. At a very abstract level, you could say that these are process modeling activities — but in reality these are done in a starkly different way that bears no resemblance to anything we know of as process modeling in BPM. It is not just a technical difference, but the people themselves do not approach the subject as anything like process modeling.
Dan Pink write long and eloquently in “A Whole New Mind” about how the world will be run in the future by “right brained” people. These are people who don’t view all activity as being composed of discrete processes, but in fact there are certain problems that are solved in a holistic way using native intellectual capabilities of intuition and understanding. Left brained thinking was very important since the industrial revolution, during the mass production of work, but it takes us just so far. Knowledge workers engage in a different form of work which is hard to describe in terms of a process.
Simply put: the practice of case management is not just BPM “done on the fly”. A case manager is not primarily concerned with modeling, automating, executing, controlling, measuring, and optimizing the flow of business activities. A case manager, instead, wants to get things done. Case management is concerned with representations of goals, and sub-goals (which looks like tasks so some, but are different), while in BPM the goals drive the design of the process, but are not made explicit. In in the practice of BPM, you want to perfect the processes to be repeatable thousands of times, but case management is not about mass production, but about making a one-off custom solution for this one situation that will probably never happen again, so extra effort o make the case repeatable is wasted. Case management is centered on business entities, not processes. These all may seem like small changes, but the whole adds up to enough difference that justifies a fresh re-design.
This requires a Whole New Technical Suite?
Not necessarily. The underlying capabilities between Adaptive Case Management (ACM) and BPM are very similar, and I think this is where Alexander was coming from. When you need process analytics, you probably can use the same analytics engine. When you do need data connections to retrieve from a web service, those connectors might be the same. If you need a stimulator, then the simulator might be the same. Many of the technologies you need are the same.
But don’t fall into the reductionist trap. Reductionists think that if you need capability X, Y, and Z, then any system with capabilities X, Y, and Z will do.
Let me argue by analogy: imagine a company that builds farm tractors. A customer comes to them and proposes that they build a race car. The critical components needed for a race car are: an engine, a transmission, four wheels, and a control system for the driver. Tractors have an engine, they have a transmission, they have four wheels, and they have a control system. Therefor, we can use a tractor as a race car.
Like all analogies this is stretched, but it is equivalently outrageous to say: “Case managers need a process modeler, and a BPM system has a process modeler, therefor a case manager can use a BPM system.” This suffers from the same reductionist fallacy.
I don’t mean to say that the tractor company can’t build a race car. To be sure, their knowledge of engine design, transmission design, etc. could be leveraged to build an appropriate race car engine, transmission, etc. Their experience is valuable. However, I don’t think it is fair to say that they would start with the design of a tractor and re-architect it to being a race car. The purpose of a tractor, and the purpose of a race car, are so different, that it requires taking a fresh approach. Leveraging their experience with the technology, they would start with a clean design aimed at the purpose of supporting the needs of a race car. Many of the technologies would be substantially similar to tractor, but the focus on meeting the special requirements of a race car would drive the entire design at all levels.
The same is true with ACM. Many of the technical components are similar to BPM. Many of the players who build BPM systems will probably come out with ACM systems. But do not assume that a system designed to support the practice of BPM, will be necessarily useful for the support of case management. Due to the dramatically different approaches of these two disciplines, one centered on process, and the other centered on business entities, it will take more than a simple re-architecting of the current BPM technology, in order to give us ACM technology. It will require a fresh approach.
Thinking Matters 
“Many of the [ACM] technical components are similar to BPM” – sure. Similarities can also be found with the project management, collaboration tools, incident tracking tools.
Will ACM survive in so densely populated space I wonder?
Another analogy I have used is the “Word Processor” and the “Spreadsheet”. There is a tremendous similarity between them: both handle fonts, word-wrap, spelling, table layout, calculations, graphics, pagination, embedded objects, etc. Many people, in the early 90’s predicted that these would disappear as distinct tools, and would be replaced by one tool that can do everything that either can do.
But today both the spreadsheet and the word processor survive as separate categories because there are different people who use them. The fact that there is >90% overlap between technical components of a spreadsheet and word processor is not as important as the separation of job that needs to be done.
That being said, there is a high probably that ACM and project management will merge …. into Collaborative Planning. (you saw that coming, didn’t you? 🙂
Project management tools are backed up with strong methodology, proven algorithms and specific reports – can ACM offer something of comparable value?
I don’t like the idea of merging in general, smooth integration of independent tools is more appealing. Gartner has proposed recently ECM as a part of BPMS offering – no, thanks.
Embedding Word into Excel and vice versa is a good example, just let’s do it internet style – think Google Wave. Collaboration probably should be the key stone while planning, projecting, tracking and processing are just the bricks of the arc.
Great post, Keith. I made the similar observation in my post today that a product that did not offer a flowchart designer was sofar not accepted to be a BPM tool. I don’t think that will change. I would just caution that we will be told that just because a certain ACM case might not have a process flow at all, one should not conclude that the related product can not be considered BPM.
Anatoly, you are right. ACM is a perfect environment for Consolidated Project Planning that does not only map the activities into Gantt charts (which Papyrus supports) but more than that handles all the contractual agreements and work assignments and status consolidations. It does a lot more than a typical PM tool. Finally, the planning might not happen manually with the secretary updating the PM tool for the purpose of the next status meeting only …
Pingback: links for 2010-04-29 « steinarcarlsen
Keith –
While you make some good points in this post, I would caution against over-reliance on the analogies. While they make for good thought models, software isn’t hardware (engines), and the definition of a “parent” as an example of how the zero case is so special isn’t really instructive except as a thought exercise.
Often “Case Management” occurs in the context of business processes – I don’t mean just as a subprocess – but the “case” is related to your overall customer service processes, or management of the case-load among your team, or feeds data into your analysis of your customer base (which may be a well-defined process).
Moreover, while writing your book is a good example for you, my father wrote seven books, and he had a very rigorous process for writing them. You can choose NOT to have a process. That doesn’t mean that you wouldn’t have had a better result with a process. Or that a process couldn’t have served you well.
Note, I never said you had to have a BPMN model 🙂 My father certainly didn’t when he wrote his books. But he could, to this day, explain his writing process in 5 minutes.
I think Max’s comment hits it on the head: “I made the similar observation in my post today that a product that did not offer a flowchart designer was sofar not accepted to be a BPM tool. I don’t think that will change. I would just caution that we will be told that just because a certain ACM case might not have a process flow at all, one should not conclude that the related product can not be considered BPM.”
In my admittedly limited experience I have found that Case Management tends to embed many distinct processes (with a little p) within the confines of a single Case (with a big C).
Process with a big P is about transformation from one “thing” to another (usually very different) “thing”.
Case Management also involve transformation – but it’s generally about the transformation of a single “thing” from one state to another.
Distinct processes (with a little p) are used to update the state of the Case… much like the methods of a Java object are used to update the state of the object.
Contrast updating a Clients records with Transforming an Application into a Policy… not quite the same beast.
Scott,
When I said that work on the book did not have a process I did not mean that there was no order to the activities we performed, not do I mean that no thought was given to the order of the activities. In fact, a very explicit (and aggressive) time line was specified. We had a conference call, and discussed the time line, and I got specific commitments from the contributors.
When I said there was no process, I meant that there was no process in the BPM sense of a process. Of course there was a process. As I type this comment now, there is a process of pressing the keys int he right order, and looking back to make sure that the spelling is correct. I a process is any intention of activities in a preconceived order, then of course there was a process.
What I meant is that we chose not to model the process with any kind of process modeler (like your father). We chose not to automate the process (like your father), we chose not to execute any model of any process in any kind of software system (like your father), We did not use any process control software, only phone calls, we chose not to use any software designed to measure the progress of the process, instead used the normal status reports, AND we chose not use any software or system to optimize the flow of business activities (like your father).
In the end, your father is an excellent example of being able to complete work without a BPM system, and without needing any of the capabilities of a BPM system.
You will, of course, argue that he would have done it better if he had had a BPM system. If he is still writing book, I urge you to install one and configure it for him to do this on a BPM system. You are very likely to run into one or more of the following problems:
(1) too much trouble. It might take you day or weeks of work to set up, model, automate, etc. The cost of this is simply not justified.
(2) the process isn’t actually that fixed. Here we run into the “narrative fallacy” that Nicholas Taleb writes about in the Black Swan. As long as the process is just in your head, it all seems quite clear. And when working according to an internal process, you naturally modify as needed for the situation, without even thinking about it. But if you make it explicit, you can spend more time modifying it than you spend actually writing the book.
Of course every set of activities in a intended order can be called a PROCESS, and theoretically every such process can be modeled, but it is the wrong thing to do in some cases.
Thank you Keith for your analysis of my post.
At first, I would like to be clear that it is possible to apply the BPM discipline without BPM suites (BPMS). A lot of ISO 9001 Quality Management Systems are good examples of this: “models” on paper, no automation, execution which relies on workers’ discipline, partial control, subjective measures and no optimization.
At the second, I would like to reiterate two important points from my post:
1) The meaning of the word “model” has to be clarified. It means to make known, to describe or to communicate a plan (or plan of work or process template) of how to carry out future actions to obtain a desired outcome.
And 2) my definition of the “zero case”: the template is built as needed within the process instance (or at runtime). Small process fragments are used. Some of them are predefined in a library of process patterns, some of them have to be created on demand. [so, your example about parenthood is not applicable]
It is normal that people plan a set of their intended activities/actions, carried them out, check the result and reflect how good the plan was. Nothing unusual, just a logical organization of work. The BPM discipline is applicable for these small steps within a “whole” work. How many activities to be planned within each step? How many steps? What are optimization criteria? All depends. So, process template fragments, or process template patterns are very useful, although they maybe implicit sometimes. I consider this as use of BPM discipline – I don’t know any “law” which mandates the BPM discipline to model in detail all steps of the “whole” work in advance.
Sure, it is possible to carry out the “whole” work without planning at all by selecting each time just a next activity. Sure that such a selection will be based on the collected case data. But any planning is always appreciated, e.g. to estimate consequences of a decision to be taken. The base of such a plan may be a set of goals and sub-goals. So, the BPM discipline can be used on the fly.
I consider that each “whole” work has an internal dynamic characteristic – a level of coordination. The level of coordination may be different for different parts of a “whole” work (some parts require more coordination and others require less coordination); it may change over time (a “whole” work which is “late” needs some extra coordination efforts to correct its execution); it may depend on the particular situation with a particular “whole” work case, etc. So, in the implementation of a “whole” work it is important
– to anticipate correctly the level of coordination required for that “whole” work,
– to implement this level using an appropriate coordination technique (different coordination techniques [from check-lists to BPMN diagrams] provide different levels of coordination) and
– to provide a simple way to switch from one coordination technique to another (similar to changing gear as a function of the driving conditions).
For some reasons you strongly associate the BPM discipline with BPM suites by often mentioning that people are forced to start from modeling of their work in process modeler. I don’t think that this is the requirement of the BPM discipline.
I agree with you about the need of a clean design when necessary, but my post was not about architecting TECHNICAL SUITES (I don’t produce and sell software). I was talking about architecting of enterprise business systems which use “fit for purpose” different technologies and tools WITHOUT being forced to buy an ACM suite (because existing BPM suites are not good anymore).
I don’t think that BPM and ACM are dramatically different. Not in the range of a farm tractor and a racing car, but like having a gear box in a normal car. Also about your differentiation based on processes vs business entities – they are both important parts of the knowledge to be used together.
If BPM and ACM are architectured around users’ needs then they are complimentary — ability to dynamically construct the “whole” work from smaller fragments will be great.
At the same time, it is possible to make BPM and ACM very different. That we had in the electronic publishing with wiki – each wiki implementation had its own markup, its own limited capabilities, etc. Later, step-by-step they converged and offered more-or-less common publishing and document management capabilities. For example, selecting of a common wiki markup took more than 10 years.
I consider that the current BPM market is vendor-centric and, it seems, that new ACM market is being created again by vendors. I think that both of them should become customer-centric markets and the expected fresh approach can be a good opportunity for this transition.
Thanks,
AS
Alexander, I find your points as valid as Keith’s. I guess it will be hard to impossible to convince people of ACM being different to BPM. I still see that your perspective very theoretical and shaped by not having to deliver a software solution that actually works. Yes, ACM and BPM can be complementary but why would someone want to switch products to take a process from predefined to dynamic to adaptive?
Architecting an enterprise business system that uses different ‘fit-for-purpose’ software pieces is a technology nightmare. The one thing such a system will not be is ADAPTIVE!
No one forces anyone to buy an ADAPTIVE suite. The term suite doesn’t even apply anymore. If we really take the business perspective then the last thing they need is ‘suites’ or ‘seven integrated software pieces’. The user/actor has one customer perspective only and he should be able to shape the work around that customers as rigid or dynamic as necessary at any point in time.
Yes, solutions are being created by vendors, but markets are created by analysts. We don’t create an ACM market. We discuss a business need. All we try to do is to break out of that rut and apply a business user perspective as you so rightly demand.
Thanks, Max
Thanks Max for providing the context.
To be clear with my perspective – it is not about development of software, it is about delivery of working solutions with right means (sometimes without classical programming – each time I have to prove that writing a new program is necessary). You may have a look at some examples http://www.slideshare.net/samarin/2010-03-09-omg
Let us return to our sheep: would the following text be a correct summary of this post “BPM as an approach for managing of an enterprise is OK, but it is currently misused in some business situation.”? I am happy to discuss a business need but without blaming speechless disciplines and technologies – I think it is more constructive to find the right scope for their use (which is often different from software functionality).
My experience shows that with a right architecting it is possible to have “fit for purpose” software pieces without technology nightmare and with the high level of adaptability of the whole enterprise system.
And I like your note about markets created by analysts.
Thanks,
AS
Pingback: Column 2 : links for 2010-05-25