Yes, business and IT often have completely different understanding and expectations about BPM. I love Theo's Mars/Venus analogy, as well as Eli's tug of war artwork. It doesn't stop there; I have cataloged dozens of different interpretations of BPM. That is why we spent so much time last month isolating the one common definition for BPM
Business Process Management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.
In my experience the business side is more aligned in general with this, and the IT side tends to have the widest divergence
from this. I have attended SOA oriented conferences where a sequence of speakers consistently insisted that BPM was a programming language/method. Please visit the definition page because each word has multiple meanings, and it is possible to read this definition with the wrong word meanings and get the wrong idea.
Lets assume though that in a good organization, the IT and business sides both agree on the above definition. The referenced article still has some sage advice for us. Any time you are building a large, complex product, whether it is agile software development, or a BPM project, there are design choices made along the way that will be heart wrenching
. Often this is a choice between giving the customer what they ask for, and giving them something that will be easier to maintain in the future. You might choose to offer a very intuitive way to manipulate some control by leveraging a cool browser-specific function, but then you get locked into an incredible amount of extra work getting the same thing to work across all browsers. In the end, this one feature displaces many other features because it distorted the architecture of the system.
I see the same thing in organizations all the time: you sit around a table talking about the process, and someone says: "when the X is below the value of Y, I want person 1, 2, and 3 involved, except in on the occasion of Z." This happens to be the case they handled that morning, and "availability bias" makes one over-estimate the likelihood and importance. Many times, to retain a viable project, someone needs to say "NO" to these requests -- even though they come from the customer.
How can this be? The customer asks for something, but to better satisfy the customer you have to refuse to do something? The best answer is that you do it for "architecture". In order to handle future advanced, the system has to have a logical consistency. The designer of a system must assure that consistency. The customer is not the expert in how to build the system. The architect must be responsible for that, and refuse things that would make the architecture unwieldy. The surprising conclusion: you can not simply let the customer prioritize the work tasks. Architecture is a strategic effort that will, in the long term satisfy more customer requirements, even if it means foregoing specific requests today. That is why I call it heart-wrenching