Scott, this is precisely my point, it is just like when building an airplane you can neither ignore gravity nor fluid mechanics. The problem I see, for a decade now, is that people conveniently pretend that processes can be designed in complete abstraction of business entity lifecycles. Few people would argue the other way around, but it would be just as bad.

Could we now make progress and all work towards advancing the state of BPM?

Scott, this is precisely my point, it is just like when building an airplane you can neither ignore gravity nor fluid mechanics. The problem I see, for a decade now, is that people conveniently pretend that processes can be designed in complete abstraction of business entity lifecycles. Few people would argue the other way around, but it would be just as bad.

Could we now make progress and all work towards advancing the state of BPM?

Look, Google was willing to sell to yahoo at one point and yahoo passed. Does that makes search suddenly not interesting of Google had sold instead? Lots of search companies came before Google and didn’t survive independently (altavista anyone?) – in fact, by the time Google came along everyone thought Search was kind of a waste of time for a commercial enterprise…

And then there is technology that has no successful commercial outcome – like browsers. Mozilla makes less than the biggest BPM players, and all that revenue is from ads, not selling browsers. Netscape is toast. Opera is vanishingly small. So, are browsers a failure or a success? How about HTML? Is there a firm that represents the success of HTML? Would it be a bad thing if BPM concepts became as ubiquitous as browsers? :)

The way I measure success is different than the way you measure it. I measure success by whether what we’re doing has value for the customer – real ROI. If we can produce it , then we’re successful. I know from previous discussion that you dislike this bottom-up thinking, but really it doesn’t make too much sense to lose sleep over things that are outside your zones of control or influence, and to focus your energies on what you can affect.

Moreover, I’ve seen focus on entity lifecycles to the exclusion of process run amok (as well as exclusive focus on process ignoring entities gone wrong). To the point that you lose sight of the fact that all this state / entity management is really to serve a purpose – fulfilling a customer request or order – and the measurements of success need to be around THAT and not around how fast you can update state or get a task completed. There’s no holy grail, there are only tools and brains to use it.

The military has an expression – equip the man, don’t man the equipment – and I think that is exactly the right mindset for producing value in an organization. Depending on the situation, you use a combination of tools to solve the problem.

I’ll leave the discussion of the unpredictable processes to you and keith :)

Look, Google was willing to sell to yahoo at one point and yahoo passed. Does that makes search suddenly not interesting of Google had sold instead? Lots of search companies came before Google and didn’t survive independently (altavista anyone?) – in fact, by the time Google came along everyone thought Search was kind of a waste of time for a commercial enterprise…

And then there is technology that has no successful commercial outcome – like browsers. Mozilla makes less than the biggest BPM players, and all that revenue is from ads, not selling browsers. Netscape is toast. Opera is vanishingly small. So, are browsers a failure or a success? How about HTML? Is there a firm that represents the success of HTML? Would it be a bad thing if BPM concepts became as ubiquitous as browsers? :)

The way I measure success is different than the way you measure it. I measure success by whether what we’re doing has value for the customer – real ROI. If we can produce it , then we’re successful. I know from previous discussion that you dislike this bottom-up thinking, but really it doesn’t make too much sense to lose sleep over things that are outside your zones of control or influence, and to focus your energies on what you can affect.

Moreover, I’ve seen focus on entity lifecycles to the exclusion of process run amok (as well as exclusive focus on process ignoring entities gone wrong). To the point that you lose sight of the fact that all this state / entity management is really to serve a purpose – fulfilling a customer request or order – and the measurements of success need to be around THAT and not around how fast you can update state or get a task completed. There’s no holy grail, there are only tools and brains to use it.

The military has an expression – equip the man, don’t man the equipment – and I think that is exactly the right mindset for producing value in an organization. Depending on the situation, you use a combination of tools to solve the problem.

I’ll leave the discussion of the unpredictable processes to you and keith :)

thanks for your answers. There are many companies that grew out of nothing when the market is big enough: Microsoft, Google, SalesForce,… We would know by now if only 50+ year old companies were the only one that can succeed. So I’ll stand on my argument that this vision of BPM has failed and the current acquisitions simply puts an end to that vision. IBM and Progress with use a couple of things from their acquisition, keep the good engineers and milk the customer base (upsell they say). Let’s stop pretending that BPM has succeeded in any way, because it has not. Keeping pretending that only delays the day where BPM will be successful.

Keith, I am glad you want to continue the discussion. I do think this is very important and it can finally unlock the value of BPM. You are basically making my point. When you say:

1) assess the situation
2) decide what to do
3) do it
4) repeat ad-infinitum.

You really mean:
1) figure out which state(s) the entities participating the process are in
2) look up the activities that are enabled in these states
3) pick one (or more)
4) go back to 1)

>> It communicates nothing about what is really going to be done.
we agree on that, but I think, what you don’t realize is that this is effectively what is happening -ALL- the time in a process of any kind. Some process involves fixed resources (say a bank loan) or the context of the process can be more dynamic and accept or eliminate resources. For instance, a prescription can be dynamically added to the on going interaction between the patient and its physician. You can even have prescription interacting with each other. The patient itself is a composite state machine (heart, blood, other organs… all have well defined states, including the one based on measurements -HDL too high, …).

I think what you don’ t see is that the actions of the physician are totally controlled by the states of the patient. It is possible that the physician does not assess the states properly, but all its actions (translated into prescriptions) are bounded by the state of the patient.

What’s a bit unusual here, is that you don’t really have a system (yet) surrounding the patient preventing incorrect activities to happen and states are not known with a great precision (specially in the US), but the exact same mechanisms as the one involved in processing a purchase order are at play. This is actually how the entire universe works … If an electron is in a particular state on an atom, there are only so many actions that can change its state. If a molecule is in a certain state (attached to a catalyst, above a certain critical temperature, pressure…) then only specific actions can be performed.

This is why you can’t define all the processes in the universe (or the enterprise for that matter). It is far easier to specify the lifecycle of the (business) entities and observe which processes can happen (using BPMN to document these processes is perfectly ok). But thinking that you are “in control” because you write a BPMN definition and you somehow can “execute” it, does not reflect at all the reality in the enterprise, in biology, physics or any system, whatever it is. This is the fallacy that has prevented BPM to thrive in the past 10 years. Industrial Process Control (the world where I come from) on the other hand has been building state based formalisms since the 70s (at least) and there has never been any problem there. Manufacturing automation is a huge market compared to BPM…

But what do I know?

Again, I would prefer a BPMN example from one of you, or somebody else, something real, if possible.

thanks for your answers. There are many companies that grew out of nothing when the market is big enough: Microsoft, Google, SalesForce,… We would know by now if only 50+ year old companies were the only one that can succeed. So I’ll stand on my argument that this vision of BPM has failed and the current acquisitions simply puts an end to that vision. IBM and Progress with use a couple of things from their acquisition, keep the good engineers and milk the customer base (upsell they say). Let’s stop pretending that BPM has succeeded in any way, because it has not. Keeping pretending that only delays the day where BPM will be successful.

Keith, I am glad you want to continue the discussion. I do think this is very important and it can finally unlock the value of BPM. You are basically making my point. When you say:

1) assess the situation
2) decide what to do
3) do it
4) repeat ad-infinitum.

You really mean:
1) figure out which state(s) the entities participating the process are in
2) look up the activities that are enabled in these states
3) pick one (or more)
4) go back to 1)

>> It communicates nothing about what is really going to be done.
we agree on that, but I think, what you don’t realize is that this is effectively what is happening -ALL- the time in a process of any kind. Some process involves fixed resources (say a bank loan) or the context of the process can be more dynamic and accept or eliminate resources. For instance, a prescription can be dynamically added to the on going interaction between the patient and its physician. You can even have prescription interacting with each other. The patient itself is a composite state machine (heart, blood, other organs… all have well defined states, including the one based on measurements -HDL too high, …).

I think what you don’ t see is that the actions of the physician are totally controlled by the states of the patient. It is possible that the physician does not assess the states properly, but all its actions (translated into prescriptions) are bounded by the state of the patient.

What’s a bit unusual here, is that you don’t really have a system (yet) surrounding the patient preventing incorrect activities to happen and states are not known with a great precision (specially in the US), but the exact same mechanisms as the one involved in processing a purchase order are at play. This is actually how the entire universe works … If an electron is in a particular state on an atom, there are only so many actions that can change its state. If a molecule is in a certain state (attached to a catalyst, above a certain critical temperature, pressure…) then only specific actions can be performed.

This is why you can’t define all the processes in the universe (or the enterprise for that matter). It is far easier to specify the lifecycle of the (business) entities and observe which processes can happen (using BPMN to document these processes is perfectly ok). But thinking that you are “in control” because you write a BPMN definition and you somehow can “execute” it, does not reflect at all the reality in the enterprise, in biology, physics or any system, whatever it is. This is the fallacy that has prevented BPM to thrive in the past 10 years. Industrial Process Control (the world where I come from) on the other hand has been building state based formalisms since the 70s (at least) and there has never been any problem there. Manufacturing automation is a huge market compared to BPM…

But what do I know?

Again, I would prefer a BPMN example from one of you, or somebody else, something real, if possible.

It is true …. you can always model anything as the following process:

1) assess the situation
2) decide what to do
3) do it
4) repeat ad-infinitum.

I am sure there are many variants of this. This model is not useful for any purpose as a model. It is a reasonable strategy if you have nothing else to go on, but it really is pointless as a model. It communicates nothing about what is really going to be done. There is nothing that anyone else can gain from this that tells them how to prepare for what is coming. You can’t make any predictions from this.

The generic doctor process might be only slightly different from this. You could, of course, have a process branch for all known treatments, and a big branch node before that, but then you get into a problem: my scenario includes the situation where a treatment was never known before (to the doctor or the hospital). There again, you could have the “do treatment not previously known” step in the process.

Scott touched on “useful level of abstraction”. For a model to be useful, it needs to include a certain level of detail. That detail is necessary for it to (1) provide a benefit in guiding people, (2) allow others to anticipate what is going to happen and coordinate to that, (3) …? What is a model good for? We need enough detail for effective coordination.

Note: when I say a process is unpredictable, I do not mean that it is entirely ad-hoc and unstructured. The structure will appear, it just can’t be known ahead of time. As work continues, fragments of the process may be brought in which are well formed. Thus the doctor says “do a liver biopsy” then there is a set process fragment that is well known for doing that, which yields a result. But the process beyond that is unknown until the result of the biopsy are received.

The entire process does not remain unpredictable over the entire life of the process. There is an “unfolding” of events that becomes clear as you go along. So when I say “unpredictable” I mean it is so at the time that the process is started.

As for your challenge: I stick with my patient/hospital example. There are thousands of new treatments being invented every day. Illnesses can be combined in rare patterns, making the typical treatment unusable. New drugs are invented, and old drugs are used in new ways. A doctor will specialize in a particular field, and be knowledgeable about only a fraction of what is known in a field. Different communities of patients have different patterns of illness, driving doctors to specialize in their community as well. Patients themselves will do research on their condition and ask their doctor to try something.

If all you are saying is that this can be approached with the assess-decide-do process, then we are in agreement. But as a model, I would say that process is not useful for anything.

The reason I am arguing that unpredictable processes exist, is that Scientific Management leads us to believe that all processes could be defined and that the workplace could be a huge factory where all the processes are known in advance. We simply need to do the work to write down the process in detail. My point is that that approach will not work for unpredictable processes, and is also will not work for predictable processes which are so rare that the cost of recording the process is more than the benefit. Thus a different approach is needed.