I have had a number of discussions with Jean-Jacques Dubray about the nature of work, and particularly whether unpredictable work exists. Jean-Jacques is a luminary in the field, so I figured he has probably a well considered opinion on the subject, and I really wanted to understand what he meant. So I invited him to discuss this.
Keith
Lets start with the basic question: “Do Unpredictable Processes Exist”, what would your answer be? Why?
Jean-Jacques
To be clear, the answer is “no” processes are not “unpredictable”, they appear “unpredictable” because you are not relating the activities of the processes to the lifecycles of the underlying business objects. Business entities can have a very complex lifecycle, even made of composite states (the entity is in more than one state at a time). Activities are performed to transition business entities from one state to another. As I mention processes works like a “map”, you want to go from point A to point B, there are many “activities” (i.e. segments of roads on a map) that you can perform to go from point A to point B. At any given point during the journey, you have only a small number of segments you can take. This is the same for a process. At any given time, the business entities are in a state and there are only a certain number of activities that can be “enabled”.
Generally, you cannot easily express a “map” (i.e. all the possible activities and the sequence in which they can happen) for a given process. BPMN is useful, it can help document the “happy” path, the most commonly taken path,… but rarely it can reflect all the possibilities that can arise if you associate activities to transitions between states of business entities. So, if you never look at the business entity lifecycles, it is normal that activities sometimes happen in an unpredictable manner. Unfortunately, states are not “unpredictable”. You can define states as the process goes (for instance this is often what happens in “project management”, as the project advances, the PM defines the states he/she wants to reach and the activities to get there). He/she may never be consciously defining the states, the activities might be enough, but in the end activities advances the state(s) of the project.
So I completely disagree with the statement “processes are sometimes unpredictable”. The entire universe has well defined states. Nothing at all, be it a physical entity or an information entity, does not have well defined states. Only artists work of the path of processes and states (and even then some art has well defined states: dried, bakes, varnished… that the artist has to compose with). Even if you say/believe the statement is true, please specify what is unpredictable about a process: outcomes, goals, activities…?
The only reason things seem “unpredictable” is simply because:
a) multiple states are enabled at the same time (for many entities and for the same entity)
b) (often) several activities can transition from one state to another
For an observer unaware of the states and their transition, he/she cannot find any logic until all the paths have been explored, until then, he/she will discover new paths from time to time.
Keith
I am still somewhat confused by your response. When you say that the entire universe has well defined states, I might think you are saying that there is always a cause for every effect. But I don’t see the connection to business processes. A business process is written down in order to guide people in the performance of their work. It describes what should be done, in the hopes that it actually will be done. Clearly, if I am omniscient, then there are no unpredictable processes — but that is a tautology. But we are not omniscient; can a person always write down a meaningful work process that describes all the possible future activities necessary to achieve the goal?
You seem to be saying that the work process exists, but the people may not know the process. If the process is not knowable, that is the same, in my mind, as unpredictable. You say that you can not easily express a map for a given process. I think it is because the exact work process can not be known. That is exactly what I mean by saying it is unpredictable. A person in not able to predict it. Am I misunderstanding your position?
Jean-Jacques
No, what I am saying is that the result of an activity is to transition resources (of the process) from one state to another. One a resource (or a set of resource) is in a given state (or set of states), there are only a certain number of activities that are possible. There is nothing you can do, it is inherent to the resources. The problem is that BPM gurus have always ignored the resource level to focus on the activity level. It is does not mean that there are no relationships between the two. You have to take into account that the BPM field has been wrong, you cannot assume omnisciently that you are always right. Thinking that activities can be defined and sequenced without taking into account the states of the resources is pure fantasy. I hope we can agree on that.
I think, yes, there is a big misunderstanding. Again, the day “BPM” people will finally understand the relationships between resource lifecycles and activity flows we will have made a huge step forward. Until then, I don’t see the point of discussing it further. The burden of proof is on your side because clearly the types of activities that can be performed are a function of the state of the resources, yet none of the Business Process Definition express this relationship in anyway. It is left to the designer of the process definition to figure it out.
Keith
We probably should write a few definitions, because I get the feeling that we are simply missing each other.
- What is the meaning of “unpredictable”?
- What is a “business process”?
- What is an “unpredictable business process”?
We need to have agreement on these, or the rest of this conversation is of no use.
To me, a “business process model” is a construct meant to represent the agreement between a set of people about what should happen. If you don’t see it this way, do you have a different definition?
Jean-Jacques
For me a process is the set of activities that are performed on the resources of the enterprise to achieve a particular goal. Examples of goals include: make a widget, sell a widget… As a consequence of that definition, the set of activities become an agreement, not the other way.
Unpredictability means that the set of activities and their sequencing rules cannot be fully known. That is clearly untrue. As you can see we can predict today the weather with quite a remarkable accuracy. Despite the fact thst we don’t track the movement of every butterfly. This is achieved by a better understanding of the causes ( measurements) and their effects. There is absolutely nothing unpredictable about business processes.
Keith
As I suspected, we are at cross purposes due to differing definitions. Lets not argue about which definition is right, but talk instead about predictability of each case.
JJ-Process is: “the set of activities that are performed on the resources of the enterprise to achieve a particular goal.”
K-Process is: “the set of activities that are performed by people to achieve a business goal”. I have purposefully tried to match the same form as your definition.
JJ-unpredictable: Unpredictable means that the set of activities and their sequencing rules cannot be fully known.
K-unpredictable: Unpredictable means that the set of activities and their sequencing rules are not known by the person starting the process at the time that the business process is started.
Not so far apart, but I am making it clear that it is of no use to me to predict thing in the past, I need to predict future activities, and I have go ahead and launch into work whether those activities are known or not. Furthermore, it does no do any good if there is a person who can predict the activities, but they are unavailable.
Let consider then, the case of a hospital accepting a patient for care who has been in a car accident as a Type-1 process. The accident has caused a blood clot in the brain, ultimately requiring surgery. But there is no way that the staff accepting the patient to know this.
You seem to be holding the position that: the patient is a body that is in the state of having a clot in the brain, even though it is not apparent. That clot will ultimately be detected by the staff, and that will lead appropriately to surgery on the brain. Therefor, the process is predictable, because it all depends on the state of the body. Is that right?
My position is that the accepting staff can not predict the process at the time of admission because they have no way of knowing about the clot. It is not until the time of the diagnosis of the clot that the prediction can be made that there will be surgery. The process “unfolds” as new information is found. The discovery of the clot causes the surgery to be added to the process.
Does this seem like a reasonable summary of our positions?
Jean-Jacques
In your patient example, it does not matter whether you know the state of the patient a priori or not. As the physician uncovers the state the patient is in, (let’s assume he has perfect knowledge of the activities he can perform for a given state), he makes decisions about what activity to perform. Business Process Engine have the responsibility to identify and keep track of the state of resources and offer to the participants a set of corresponding activities. In that case, you don’t even need to define “the process”. All you care are the states, the transitions and the set of activities that allow you to transition from one state to another. You can document “processes” as being the “most common path”, the “most efficient path”, the “cheapest path”, … just like in a set of roads you may take different paths to go from A to B. Now you could form an “agreement” the participants have to perform the activities that matches the cheapest path. However, it is not preemptive to the fact that the activities are bound to the states and transitions of the resources.
Even though our definitions are unpredictable different we (seem to) agree that there is not a situation where “the set of activities and their sequencing rules cannot be fully known”. We always assume that the set of activities is fully known, what may not be know is the state(s) some of the resources manipulated by the process. Obviously, there are cases with the states, and activities are unknown ahead of time (after all we are inventing new surgery procedures all the time) but hopefully this is out of scope for BPM (at least for now).
Keith
You anticipated the clearest example of unpredictability: when a new surgical procedure is invented. The doctor has an “Ah Ha!” moment, and decides to do something that has never been done before. This situation will most likely happen after the patient is admitted (the invention would not have happened without the patient being there) it is therefor clear, I believe, in this case, that is it impossible to predict this procedure at the time that the patient is admitted. This is not out of scope at all – but a real life situation that doctors and hospitals must deal with on the regular basis. I will however broaden my claim to include cases where the knowledge was known outside the organization, but was a completely new procedure to that hospital, and would not be anticipated by them. Finally there are cases where there is no firm agreement on the proper procedure, and so the actual process will depend upon something as arbitrary as who happens to be on duty at the time.
Setting. Just to be clear, I am expecting that the BPM approach is that the patient arrives at the hospital, and that “admitting” the patient mean that a “process” is started for them. BPM is process centric, so a process definition is the organizing principle around which all care will be provided. In order to start a process with BPM, a process definition must exist. That process definition is specified by process specialists: people with special skills and are trained in the art of composing a process definition. In reality there will be many people with varying skill who will collaborate to make the final process definition. It does not matter how the process definition is put together, the only thing that matters for my argument is that (1) it is NOT created on the fly by whoever happens to be standing there, instead (2) it must be created in advance using skill unavailable to the average bystander.
Jean-Jacques
No, this is incorrect. It is like saying, to start a journey, a path must be chosen. All you need is a map, maybe even a compass would do.
Keith
I agree a process model is a like a map, and there are choices along the way. I don’t mean to imply that a process model restricts you exactly one course. There are choices along the way. But when I say some processes are not predictable, I mean that the map is not able to be known in advance. The doctor that invents a new procedure is putting a new thing on the map that was not there before because nobody knew about it, and nobody could have predicted that the doctor
The map for a particular hospital might be something like:
1. Have Dr. Jones inspect the patient and determine if there is (a) bleeding, (b) broken bones, (c) head trauma, (d) internal organ trauma, ….
2. if there is bleeding, then have Dr Wilson look at the bleeding and determine (a) is it life threatening? (b) Is it in a place that can be easily bandaged? (c) is there any indication of hemophilia? (d) ….
3. if it life threatening bleeding, then move the patient to ICU, assign more staff, etc.
This will branch a lot, and there are thousands of possible tests as well as thousands of possible treatments. By predictable process, I mean that there is a predefined (branching) sequence of tests and specific treatments. But, I claim that the process model (the map, or state model in your case) for the patient will have to be modified after it is started in a significant number of cases.
Some of the difference in our positions seems to be the difference between “knowable” and “known”. You say: “there is not a situation where the set of activities and their sequencing rules cannot be fully known”. Do you mean theoretically known, or actually known? All we need to do, is to make the state model of a patient: and then we would not need any doctors, or really any nurses either. A complete state model for the patient would tell anyone exactly what to do in any situation. Why doesn’t such a state model exist? Two reasons.
(1) The first is that it is a huge task to gather all that knowledge in one place and to externalize it. A doctor through experience will learn that a certain kind of red splotch in a X rash, while a slightly different one is a Y rash. It is almost impossible to externalize this kind of knowledge. A specialist in a particular disease will be able to look at a patient and draw some conclusions immediately, but it is almost impossible to externalize even just the rules about when to do what.
(2) The second is about agreement: If you were to attempt to codify the procedures, you would end up in arguments about what the right procedure is. I am sure you have had the experience where one doctor says do one thing, and another says do the opposite. A single state-model would require agreement at a very detailed level — and that simply does not exist. Different doctors have different theories but that is not because they are incompetent: each doctor is applying knowledge and learning more about their specialization, in the context where they work. A doctor in Cincinnati may find that a particular treatment works there, but a doctor in Atlanta may find something different. There is no central authority to settle the dispute: and arbitrarily picking one doctor’s approach may be an inappropriate simplification. The reason that there are not strict rules on what doctors do, is that a doctor really does need this kind of discretion to DECIDE the course of treatment, potentially for each different case.
Instead, I see doctors in a continuous state of learning: trying out new treatments, seeing which ones work, attempting to understand the underlying rules. And it is happening in parallel across 10,000 doctors all at the same time. It is constantly changing and evolving, with the introduction of new drugs, new procedures, and new findings about what does and does not work. The course of treatment will depend upon the doctor as well as what the doctor happens to know at that time.
For this reason, I say it is impossible to actually write that state model for the patient. Not only would it be prohibitively expensive to make that model, but by the time you made it, it would be out of date. This is knowledge work, and knowledge is always changing. Thus I say the process is unpredictable.
Mostly, I am worried about the “practical” problems with predicting the process (the people involved don’t know, and it is simply too expensive to collect the knowledge) but the agreement problem even eliminates the theoretical possibility of an accurate state model.
Did I understand your resource state-model correctly?
Jean-Jacques
Keith, when I drive, I don’t stop on the side of the road and start digging a new path. Some people do that. The beauty of the lifecycle model is that you can add states an transitions at any time, anywhere, you can add a resource in an assembly at any time, it all works. There is no “start” there is no “end”, only states and transitions. So again, you can keep ignoring the obvious, but I don’t see a single reason in our entire discussion to ignore the resource lifecyles: agreements don’t work, business process orchestration doesn’t work, BPM as it has been defined for 15 years doesn’t work. There is nothing clearer today. Don’t you think it is time to explore “routes that are not on the map”? It is long overdue if you ask me.
Keith
You say “The beauty of the lifecycle model is that you can add states an transitions at any time”. This actually is precisely the point I am trying to make. My approach has always allowed people to add states / transitions / activities at any time. I am wondering if you somehow assume that a “process” can not be adapted in this way, and this is then leading you to believe that it need not be. If work processes as you say are always entirely predictable, if a process is fixed ahead of time and never needs to change, then why is the ability to change it such a beauty?
You also say “Worse, most “applications” that are written are written with hard coded processes.” This too is exactly my point: BPM has promoted the idea that processes should be fixed, and I am trying to argue that the reason hard coded processes don’t work, is because the underlying work is not predictable. Many times you have expounded the virtue of being able to add states and transitions on the fly, but have never taken the step to say that the reason you need to add such states and steps is because it is not possible to define all the states and transitions ahead of the situation. Predictability is a requirement for hard coded state-and-transition models to work.
It is worth exploring routes that are not on the map. But to stay on subject, this discussion is about “why aren’t those routes on the map?” The map contains all the predicted routes. The routes on the map are not predicted. There are types of work for which it is not possible to put all the routes on the map. That kind of work is “unpredictable”, and maps need to be malleable in order to support it.
Epilogue
I collected this from a much larger email stream. I never did get him to agree that there unpredictable work existed. He kept launching into a discussion on how a resource/state model was superior to a process model. Actually, he has some very good points on this, and I have no reason to believe that it is not superior. I hope to explore this in detail some day. But to keep this discussion bounded, I simply wanted to discuss why he felt that unpredictable work does not exist, and (the converse) why he felt that all work was predictable. I am afraid I remain unconvinced that all work is predictable, so we must simply agree to disagree upon this point.
Comments, anyone?
Thinking Matters 
Interesting discussion indeed Keith. I think the key point that Jean-Jacques makes is “It is like saying, to start a journey, a path must be chosen. All you need is a map, maybe even a compass would do.”
Forgetting the difference in definition of unpredictable, it seems as if the point is that the end path is not always known ahead of time, which is they key tenet of adaptive case management.
I think maybe the critical distinction is that while you could define all the possible permutations of some processes, it’s simply not practical or useful, which is how I think of unpredictable work happening.
I see three levels of this:
level 1: maps that are not filled in because it is not practical (cost of filling in the map is greater than the utility).
Level 2: where nobody knows what to put on the map because there is disagreement as to the right approach, and picking one arbitrarily would be the wrong thing to do.
Level 3: Cases where a particular activity has not been invented yet by anyone, literally it has never occurred to anyone.
Levels 2 and 3 are more common than a reductionist might think, because the world is not a simple state, but rather a combination of astronomical number of states. Every hospital every day faces a patient with a combination of conditions that has never been seen before. Thus, new creative treatments are invented every day.
A close friend has a well known, but very rare condition — it effects about 1 in 30,000 people. Most doctors go their entire career without ever facing such a person, and probably many hospitals never encounter them. As you can imagine, every time she meets with a new doctor, there is a period where she has to educate the doctor about the basics. She tracks a particular user group which shares information. New procedures and treatments are invented every year, but it takes years for those ideas to actually filter out through the medical community. Her solution was to find the one doctor in the western United States who has made a specialty of treating this disease. This doctor, however, is constantly experimenting to try to find better ways of treating it. Also, every person exhibits slightly different symptoms.
If someone were to make the map for a typical hospital, you can bet that the map probably would not have the first thing for this disease (Cystinuria). If it did have a map, it is unlikely to have anything invented in the past few years, and most certainly would not have the creative steps that this specialist invokes.
It probably does not matter if it is impossible, or merely impractical, but I believe it is actually impossible. Take the game of chess. Someone has estimates that there might be 10^120 possible games. Keep in mind there are less than 10^80 atoms in the known universe. It is literally impossible to map out all the possible games. Business processes *just might* be more complex than a game of chess. 🙂
Keith,
thank you for publishing our discussion. I think this is helpful. I would like to add that there are multiple types of paths:
a) I want to go from A to B (where B is well defined) – I don’t drop my children at any school,
b) I want to go from A to a type of B (I want to go to a park)
c) I wanted a) or b) but I ended up in C
Each type can have different terrain and incidents (well defined roads, jungle, mountain…)
There are many ways to prepare for each type a), b) and c) but the approach is always the same, you scout the terrain one way or another (map, visually, …) i.e. you discover the states and them you move accordingly.
Pingback: uberVU - social comments
Could we boil this down to: “there is work that people perceive to be either unpredictable or unplannable, and yet we need to build software to support these types of work to help, as best we can, improve the efficiency and results of this work.” and then the discussion moves to, “what are the best ways to tackle writing software for these kinds of work? the best ways to model, represent, interact, etc.?”…
In some sense, it doesn’t matter if the work IS unpredictable so long as the people participating in it and responsible for it perceive it to BE unpredictable. ie, we want to make these approaches accessible to people who do not have the intellect and background of a Keith or JJ…
scott
ps – sure, only 10^80 atoms… but how many electrons? We can theoretically store potentially more than 10^80 bits of information, no? 🙂 plus, the combination of states let’s us represent more information than the actual number of “things” we are using to represent those states… (picture those exponential connectivity graph connections… (n-1)! connections i think?)
Thanks for posting this provocative exchange between you and Jean-Jacques Dubray. It’s an important discussion at a moment when people are exploring the future of business process.
Does unpredictable work exist? Certainly. Accepting that we are not omniscient, the question becomes which technology artifact, flowcharts or resources, provides the most flexibility (least constraints) at run-time to accommodate real-world operations. I’m not sure this is much of a contest, its resources by a long shot.
BPMN flowcharts are a contrivance that imposes constraints for ‘usability’, while resources are a development artifact, a fundamental unit of work, root things. Working with resources provides for greater diversity of outcomes than BPMN flowcharts (diversity = variance = adaptability). Resource state management can build processes, can be represented in flowcharts, and provide all the creature comforts BPMN can provide, but the reverse is not true.
BPMN does not scale with complexity, its rigid in execution, but worst of all, it limits the range of the possible, the next step is always a foregone conclusion, and it will be the same for every instance of the process.
You don’t have that with resource oriented processes. Each step could result, conceptually, in one of a million next steps (not that it always will, but it scales with complexity). Moreover, each step could pause to factor context in determining next steps.
A resource oriented process can be as short sighted and poorly designed as a flowchart, both are made by humans, but the recovery is much better for a resource oriented process.
It’s hard to manipulate an individual running instance of a flowchart (beyond kludgey insert ‘invoke and wait’ subprocesses – is that the best dynamic BPM gets?), it’s easy to modify a single running instance of a resource oriented process because resources are always managed as representations. Moreover, each resource can have full versioning and audit history. Better still, the resource oriented process was never wedded to the fixed map in the first place, it can actually factor interaction-level context to derive a next step, which can be one of a variety of contingency steps.
We should be shifting to resource oriented processes, for the same engineering reasons that drove material scientists to nano-technology, medicine to gene therapy, and graphic design to pixel-level editing – flexibility, efficiency, and because we can.
There is a reason why business leaders are suddenly have wandering eyes, they don’t think BPMN is the vehicle for the component-based distributed future.
Knowledge workers of the world unite!
Pingback: Process for the Enterprise » Blog Archive » BPM and BPMN Under Fire
Dave- I have to admit I don’t follow how a post about whether unpredictable work exists leads to a diatribe against BPMN. I’m curious which BPMN tooling you’ve used because your experiences don’t match my own experiences with BPMN-based BPM software packages. And which “resource-oriented” process tooling do you recommend if it is the silver bullet you say it is?
Dave:
thank you for this comment, I must admit that having had your point of view for as far back as 2002, I feel very lonely. I agree with your statements but I would not go as far as trashing BPMN. Yes I agree it does not scale, it does not reflect the reality of information system and making BPMN executable is one more time one of these dead end that our industry loves to take (and milk). BPMN has merit and value, it helps defining interesting (but not necessarily complete) trajectories in the millions of millions of possible path. So I am one of those who believe that BPMN should return to its sources (and it is often used that way), as a visualisation tool, as a tool that helps you reason about a problem and communicate your approach, but, please guys let’s stop the fallacy that BPMN is the way to BPM or business proces execution. It is only one (important) element.
We could all live happy, with BPMN, BPEL, lifecycles and assemblies. All the technologies are here to make BPM finally possible. We don’t have to change anything, just change the articulation between these technologies.
Keith,
Interesting, but very academic discussion. I agree with you, in the course of business there are very many unpredictable processes that people deal with everyday – in many cases not because there isn’t a general guideline – but because between each execution of the process things have changed enough that things are handled differently. So you can provide a map and compass, but the directions can’t be too detailed – just think if you had directions that said “turn left at the anthill” – what happens when the ants move? (BTW, even though we call it a map, BPMN is used to provide directions – not a map – maybe we need something to actually provide a map – but that is another discussion).
So you need to give directions at a different level – but no matter what, in the end everything changes – it is just a matter of how quickly. In business, for many processes – they change very quickly (and are very dependent on the exact circumstances) – and it is up to the participants to fill in the details and get the job done.
I have never heard a business person try to counter this – and if they do usually the statement – “OK, so we could create a model and program to do your job” settles the issue. For example – your email exchange is a business process. The best I could do to model it would be “send email”, “respond to email” a valid but not a useful model. So how would BPM help manage this business process?
@JJ – regarding your last comment, well-said:
“We could all live happy, with BPMN, BPEL, lifecycles and assemblies. All the technologies are here to make BPM finally possible. We don’t have to change anything, just change the articulation between these technologies.”
Pingback: The difference between Modeling, Mapping and Directions | ActionBase Blog - Thoughts on Collaboration Process Management Unstructured Compliance and Audit
@Jacob:
to be clear, the map are the states and transitions, BPMN is the directions to achieve a particular path, just as you said, if the lifecycle of a resource changes (that never happens right?), then your directions become stale.
I guess you made my point very eloquently. BPMN is great, you just don’t want to give a map to people if thousands of people need to go the same way, but when the map has changed, the directions need to be updated. This is what BPMN cannot do because it completely and thoroughly ignores the obvious, the terrain to which the directions apply.
@scott:
so when are you starting to use a different articulation or, is your articulation still BPMN and nothing else? Please not that I am advocating that BPM needs all of the above, with a specific articulation between them, I am not arguing to create a BPMN camp, a BPEL camp, a State Machine camp. The solution needs to be comprehensive and all encompassing.
@jj – while I’ve been a defender of BPMN as useful for what we do in BPM, I’ve never claimed it was the exclusive tool in the tool-belt. I’ll defend BPMN against those who say it is useless, or pointless – because my experience tells me otherwise. But that isn’t the same thing as saying BPMN is the exclusive tool of BPM practitioners.
In fact, “BPMN” is a term that rarely, if ever, comes up with out clients. We use it as we model a process, but we don’t have to sell BPMN as the tool – we also use higher level tools like value stream mapping and more six-sigma oriented process-maps to understand measurable outputs. But we also spend time mapping out the lifecycle of enterprise data we’re interacting with to understand what events (transitions) we need to listen for, or what events we need trigger based on moving through the process, among other things. Usually starts with a brainstorming tool and then gets into data modeling as well (maybe not all of the information on an order is interesting to my process, but some of it is VERY interesting to my process as it affects states that affect process, and I want to make sure we think it through). It is all about getting the job done and the buzzwords are just that… Its the practitioners that have to make them work.
(I wouldn’t argue to create all these camps either)
Pingback: Tweets that mention Does Unpredictable Work Exist? « Thoughts on Collaborative Planning -- Topsy.com
Keith,
Great discussion – thanks for surfacing it. It’s only once I got to the comments that I think I really figured out what the discussion was about!
When I look at Windows Workflow Foundation, Pega SmartBPM, WebSphere Process Server etc I see the ability to manage the flow of work through a priori structured maps (possibly originated using BPMN) but also the ability to structure the flow of work through a Finite State Machine model of some kind – fundamentally (I think) what we resolve to when following JJ and Dave’s lines of argument.
In my mind both approaches are very valid and indeed can be complementary – or (gasp) could be blended. The challenge, as far as I can see it today, is that many of the tools that support state-based work management approaches don’t have terribly good tools in place to help people do the modelling, and certainly tools to help bring design models forward into the monitoring/optimisation environment to provide context for improvement.
For better or worse this is where BPMN has started to make real inroads. I’d like to see a similar degree of industry work to define a modelling language that has a more resource/state based foundation and is also, to an extent, business-friendly.
As an aside – interestingly, I guess, one could argue (though it might be a little bit stretching the original purpose) that some of the new diagramming concepts in BPMN 2.0 could be used to define state machines, at least partly…
One day, Keith, it would be nice to talk directly to you about what you’re doing in more detail!
Loved this discussion – thanks for sharing.
I had a few (underdeveloped) thoughts in response : http://bigmenoncontent.com/2010/03/31/mandelbrot-and-bpm/
http://www.ebpml.org/blog2/index.php/2010/03/30/bpm-discussion-with-keith-swenson
Pingback: links for 2010-03-31 « On IT-business alignment and related things
Scott – In the last few weeks alone there have been dozens of posts on the topic of adaptive case management. Thoughtful people like Keith are sparking discussions on how processes might be engineered to support the most difficult real-world requirements – I think my comment about wandering eyes was fair.
In my earlier post I pointed out that the exchange between Keith and Jean-Jacques was less about predictability and more about two separate programming approaches for dealing with unanticipated events. My dismissal of BPMN was in the context of the particularly complex use-case Keith outlined.
My position is that for run-time adaptive case management it’s better to build processes dynamically with resources from the ground up than to impose fixed flowcharts from the top down. This is a focus on technology as an enabler of what business needs. It is not dependent on flowcharts for modeling or views, but it can exploit them.
I welcome a spirited debate, but all I got out of your rebuttal was the fact that Bruce Silver’s BPMN training and book sales are up – this only proves that BPMN is profitable for BPMN consultants.
Neil – Adaptive Case Management does seem to be battleground for the convergence you seek.
BPMN will expand its semantics to support the more complex use cases (shifting ever closer to code), and resource-oriented solutions will exploit interactive views to provide business-friendly user-experience (shifting ever closer to visual programming).
I haven’t seen anything resembling Adaptive Case Management from the BPMN community, but we can do this today with our resource-oriented approach.
@Dave – the wandering eyes are vendors and analysts that this point – those posts are being written by the vendors, not the business leaders (about adaptive case management and other approaches). So the same criticism you would make of BPMN being profitable for consultants is applicable to the other tech approaches as well. My point was simply, these discussions we’re having are mostly between analysts, experts, and consultants and vendors of various flavors, not the kind of discussion the business is having (they’re not arguing the merits of BPMN for the most part, nor talking about distributed component based futures).
There’s no need to separate the “BPMN” community from the “Adaptive Case Management” community. Those of us deploying BP / BPM solutions will use all of these things when appropriate to the business process (or problem, or opportunity). To the extent that there’s any separation at all between them is an artifact of software vendor boundaries.
I think you have greatly under-estimated what can be done with a good BPM suite (that includes BPMN), and the fact that it is complementary not competitive with case management approaches. The only thing holding back more collaboration in these approaches, at times, is limited software licensing budgets – not all customers have license to both kinds of tech at their disposal.
I read this comment as far more general than your last response implies:
“BPMN does not scale with complexity, its rigid in execution, but worst of all, it limits the range of the possible, the next step is always a foregone conclusion, and it will be the same for every instance of the process.”
Well, BPMN is an abstraction, and if you use it to represent complexity as you are thinking of it, you are probably thinking of it too much like a substitute for a programming language, which is understandable, but not necessarily best practice. The next step is *not* always a foregone conclusion, the step itself could be defined to be nearly anything, including adaptive case management or another process (which is the beauty of abstraction). If I misread your comments I apologize, but it sure read to me like a general bashing of BPMN, rather than just a critique for this kind of problem (unpredictable work).
@Neil:
as Dave pointed out, the key here is “resource”. When you say: “but also the ability to structure the flow of work through a Finite State Machine model of some kind…”, I am not sure you imply “resource lifecycle” when you state machine. FSM can be applied in many contexts, including in describing “resource lifecycles” (FSMs need some extensions to model RLs). It is not so important that you can transform a BPMN definition in a FSM view like WebSphere Process Server does, it is far more important -it is essential- to understand that the constraints of a process definition come from the underlying resource lifecycles. This is what is critically missing in BPMN. Defining a process in BPMN is like giving directions without the knowledge of the roads.
Every customer that gave me an hour or two and a sample process was converted to the importance of Resource Lifecycles.
I challenge anyone to email me a process (Keith and Scott have refused so far, in prior discussions) and I will do the resource lifecycle decomposition to show the benefits of such an approach and more importantly the articulation between BPMN, BPEL and FSM(as RLs). My email is jdubray@gmail.com
@Scott:
“But we also spend time mapping out the lifecycle of enterprise data we’re interacting with to understand what events (transitions) we need to listen for”
so, I don’t understand, you use RL, you even seem to think they have value, yet you seem to argue constantly against them. Not sure I understand your position in the end. Is that new?
I’m not arguing against using RL, i’m arguing against the (in my opinion) misplaced arguments that BPMN isn’t useful (it is), and when people say business leaders are talking about RL – for good or ill, it isn’t really what business leaders are talking about. so let’s not use false arguments to make our cases, let’s use real data and reasonable arguments rather than assuming that in order for anyone to use RL they have to dump all other approaches. (or vice versa).
I’m not against RL – but using RL doesn’t make me anti-BPMN – I’m not sure why it seems to have that effect on others 🙂
>> I’m not against RL – but using RL doesn’t make me anti-BPMN –
To be clear and I repeat, I am not anti-BPMN, I have expressed its value many times and how I use it. However, I am against the proposition that seem to be the vast consensus of our industry that “all you need is BPMN from modeling to execution”, as a corollary, that makes me against executable-BPMN and attempting to compile BPMN into BPEL.
So when are we starting to work on RLMN? it relationship to BPEL and BPMN
@JJ – it took us many back and forths (previous discussions) before I understood your position better (vis-a-vis BPMN in particular), because I hadn’t read enough of your writing before our initial discussions (not enough context and I jumped to conclusions). I can understand your frustration with “all you need is bpmn” 🙂 (Give someone a hammer…) And, I should say, I didn’t interpret your arguments in this post as trashing BPMN. I am puzzled how BPMN got pulled into the fray at all in the comment stream.
Hm. RLMN doesn’t have a great ring to it but it sure beats some others I’ve heard. And it sounds interesting 🙂
Scott – I agree that this is a semantic discussion amongst a community of interest, but I don’t believe it to be purely academic. Adaptive Case Management is becoming a hot button issue exactly because it describes a real world requirement that business folks are struggling to manage. If BPMN supported ACM intrinsically we wouldn’t be having these discussions. (Is this a false argument?). Please note that Adaptive Case Management is one of the tags that Keith put on his post, so he thought that was the subject too.
In this thread and in others Keith has invited or explored other ideas, that’s healthy. (right?)
You are correct, I’m not critiquing unpredictable work, I’m contrasting two approaches to unpredictable work, and I have a perspective/bias, just like you. Besides pointing out that BPMN consulting sales are up and noting that I am underestimating BPMN you still haven’t responded with much that contradicts my thesis.
I never said BPMN was good for nothing, though that seems to be the chip on your shoulder. I made a few pointed remarks re: BPMN weaknesses (not yet refuted), which underscore its weakness for direct support of Adaptive Case Management.
You seemed to have agreed with me in your last missive when you said BPMN “… is complementary not competitive with case management approaches. The only thing holding back more collaboration in these approaches, at times, is limited software licensing budgets – not all customers have license to both kinds of tech at their disposal.” If I’m quoting you properly, we don’t have an argument, as you are clearly saying BPMN in and of itself, doesn’t do ACM (otherwise why would it require separate licensing?), but it can work with ACM. Fine, I never said it couldn’t be part of ACM, I just said it wouldn’t be the best foundation relative to a resource oriented solution.
However, if you are still upset about my BPMN blasphemy, let’s just agree to disagree. If you still want to debate me, I’m happy to oblige and even do a comparative demonstration, but let’s find a more appropriate forum. : )
@Dave- i’m not upset 🙂
And I wasn’t engaging you on a point-by-point debate from the get-go, just pointing out that you implied bpmn isn’t useful and that business folks are giving up on it (my paraphrasing) and I simply disagree with that and there are a lot of data points to refute that. I don’t have to disagree with everything you say just to disagree with two basic points. And not disagreeing with other things you say, doesn’t make the points I took issue with more credible, nor does my lack of arguing something make it unrefutable, it only makes it unrefuted – there’s a difference 🙂
Jean-Jacques – Thanks for raising the profile of resource-oriented approaches to more complex process use-cases. There are clearly reactionary forces that make these sound technological points difficult to surface.
“Reactionary forces” – nothing like a bit of constructive debate eh! 🙂 Looks like you’ve sparked some immune reactions here Keith…
Coming late to the party…
I think we all agree that getting from Requirements to an Implementation is the goal… and anything that helps us map Requirements to Implementation is a good thing.
I use Teamworks, and it’s use of BPMN allows me to navigate from a process diagram to the code, screens, data structures, etc that are used to implement the requirements.
Not the only way to accomplish Requirements to Implementation mapping, but a good way.
@Neil and @Dave,
>> reactionary forces
I don’t know how else to describe someone on the path to progress.
To be clear, the two propositions on the table is a) the ability to perform a given activity is constrained by the state of the resources involved in the performance of the activity
b) a business process is the mere observation of the sequence of activities performed on a given set of resources (created, modified or destroyed by the activities performs)
If someone disagree with these two propositions, could they explain what is constraining the activities of a business process. If I understood Keith properly, he defines a business process as an agreement between roles to perform a certain number of activities in a certain sequence. The constraints are then defined by the agreement.
Does an agreement make a business process?
I’d be interested to hear people’s position.
Pingback: BPMN Quotes of the week « Adam Deane
Interesting discussion. If you apply this discussion to customer support, Keith seems to be describing the Zappos model and JJ seems to be describing the Dell model. In my experience, organizations perform better when they focus on goals and metrics and not the steps.
Great dialog and comments. An integration of activity oriented and resource oriented perspectives on business processes is definitely a way forward towards more adaptive processes.
I’d like to see more precision when it comes to the ‘resource’ concept. We recognize that processes are in part
– procedural
– product driven, e.g. in design and engineering
– data driven, e.g. in case management
– organization driven, e.g. reporting, allocation, progress depending on availability of competence etc.
– IT application driven, e.g. in SOA
– infrastructure driven, e.g. operations, maintenance and modifications
– etc.
Processes dominated by resources-as-product is unpredictable and adaptive in different ways than those primarily dealing with resources-as-data or resources-as-infrastructure.
Process models need to balance and integrate these aspects. By asking which dependencies are most critical for the coordination of a given process, we can identify the most suitable modeling approach and work breakdown structure partitioning principle. We have for instance seen cases where the relationships between product systems and components are far more critical than anything captured in the business process diagram.
Often the central aspect will change as we move down to lower levels of abstraction. Seeing resources as more fine-grained than activities, as some do in the comments above, is only one aspect of this. Swimlanes in BPMN can reflect the opposite arrangement, with resource swimlanes above activities.
Pingback: ‘Warning! BPM is not accurate. Switch on your brain!’ « Welcome to the Real (IT) World!
Pingback: Process for the Enterprise » Blog Archive » BPM is Doing Just Fine, Thankyou
Pingback: Process, Improved » Predictability, Practicality and Passion
Pingback: Frank Michael Kraft's Blog » Does unpredictable work exist? – My opinion
Pingback: Frank Michael Kraft's Blog » Does Unpredictable Work Exist – continued