Why is the idea that cases don't have processes the point that everyone must agree with to satisfy you? this is something you always come back to but I'm not sure it is nearly as important as you say. Again, an email is neither a case nor a process, but I can build a process that involves email. Or a case that involves email. Why can't processes involve cases and vice versa? It just isn't logically complete.

In math, the lack of something is zero. and yet math leverages the absence of something just fine. So yes, a process can include the concept of something that has no process. That doesn't tie me in knots, projects deal with this all the time.

I like the fact that Yokelson points out the different design goal. That is good. But he has completely missed the point that some cases simply don't have processes. But this depends upon your definition of a “process”. If a process can include the concept of “no process”, then we just go round and round.

I responded on the thread that you linked. I have provided a definition of BPM, I hope you will too.

There's also certain blindness we get when excited about a shiny new bauble. We should still get excited about this bauble, but we shouldn't lose sight of perspective, and reality, in the process. Our tools aren't as simple as hammers and screwdrivers. I think the framework of optimizing outcomes over many instances, versus the framework of optimizing specific outcomes for specific instances, does a nice job of helping figure out which approaches will give you the most bang for your buck depending on where your problem is in the spectrum. But you prefer to define things in terms of can and can't, black and white, and I don't find that as useful and I don't feel that I need to comply with being binary in my arguments.

Here is the previous thread in which we discussed the same complaint from you that I need to describe what is not BPM.

http://www.bp-3.com/blogs/2010/05/max-j-pucher-…

If you want to jump to the relevant comment and my response:

http://www.bp-3.com/blogs/2010/05/max-j-pucher-…

I think three weeks have passed- we've been busy. If posts like this and the previous one don't do it justice for you let me know. I think its clear, and I could give 4-5 more examples but I think the point has already been made and so the # of examples aren't going to increase clarity. I even used your framework (the doctor patient experience) to explain myself.

I even borrowed your favorite medical analogy.

Keith, music is great. I, too, have heard Wynton Marsalis in concert. His brother as well. He's fantastic, and the experience of hearing him was amazing. I've heard many other musical acts, I even have some musical skill myself. It just has no bearing on BPM or ACM software. ACM wouldn't help Marsalis any more than BPM. Its an analogy without teeth because it doesn't inform how we actually work.

And yes, all music can be written after the fact. But not all music can be written ahead of time (improvisation).

I know you don't believe this, but there are work patterns that simply can not be described as a process.

Just as there are types of music that can not be written down. Do you believe that? Can all music be written? If so, why do improvisational solos exist? Is a world view that all music can be written down, there should be no need for improvisation.

http://kswenson.wordpress.com/2010/05/25/improv…

Scott, on many occasions I have suggested that when you speak of BPM, you use BPM in a way that suggests that BPM is “all automated work”. All work is composed of activities, and all collections of activities are processes, and therefor all work is supported by BPM. Given this world view, ACM would be a part of BPM.

In order to clarify whether you really mean this or not, I have asked you to give an example of automated work that is NOT BPM in your world view. Forgive me if I missed it, but don't remember seeing any such examples from you.

There is a certain blindness that we are afflicted with once we adopt a mindset for viewing the world. It is inevitable that we adopt mindsets, but be should at the same time explore the limitations of particularly mindsets. As I have said before, if you have a hammer, you tend to view all problems as nails. More importantly, if a problem does not look like a nail, it ceases to be a problem, and becomes a non-problem. There is, of course, a large gray area of things that look sort-of like a nail. I would like you to identify some problems that do NOT look like nails, and then we can talk about those cases.

However, if when you say “hammer” you really mean “tool” , then your term is all inclusive term over all possible tools, and when I argue that a screwdriver it not a hammer, we end up in a useless argument because I mean a specific tool for a specific purpose, and you mean an all inclusive tool.

I use BPM to mean a specific technique where you define a process, analyze it, measure it's “quality” across a large number of typical cases, with the purpose of making a process that will be run many times in the future. That is what I understand BPM to be, NOT simply a term that means all possible work automation. It is a specific kind of work automation.

There is no point in arguing, if instead you believe (as many do) that BPM is simply a term that means all kinds of work automation.