I believe that distinction is crucial and not yet properly understood. Traditional BPM vendors have everything to gain by keeping that separation blurry. In this post, I'll show that this separation is vital for understanding that IT people should drive the selection of BPM Systems, not business people.
The distinction between BPM as a management discipline and BPM Systems (BPMS) is an observation rarely pointed out by BPM vendors and therefor worth while highlighting. BPM vendors too often try to blur the distinction between the software product they offer and BPM as a business management discipline. Next they talk at length about the benefits of that combination to show that their software product brings all these benefits as a package that you can just buy off the shelf.
It's basically any manager's job to make an organization run more efficient. So basically any manager is managing business processes. BPM vendors are happy to offer this skill in a box. But that is a false promise. BPM software cannot replace the management skills necessary to manage business processes. Which are the important business processes in this organization? What are the steps that we should automate and what should be done by people? Which people should get involved when? What is essential for this organization and what is detail? It requires a manager with vision and analytical skills to perform the business process management discipline well.
A BPM software solution cannot replace that vision and analytical skills to optimize the performance of an organization. That remains the key responsibility of the business people. BPM software can never claim to take over that innovation and change management aspect.
But a BPM System can help in 2 key areas:
- Produce software to support business processes
- Facilitate collaboration
Business people should control and drive the optimization of business processes. BPM systems too often try to put non technical business people also in control of the software automation. That is I believe a common pitfall for BPM systems. Instead, IT should have a BPM System at their disposal to help them automate software support for those business processes faster.
Non technical business people should not focus on producing software. Instead they typically focus on requirements documents and process analysis diagrams. And the collaboration aspect of BPM Systems should allow for discussions between business and IT people about all the artifacts that matter in the collaboration. Generic social features around the artifacts that matter to both the business people and IT people is what the BPM System should offer for the collaboration aspect. That's not rocket science. It does not take special management skills to evaluate collaboration features.
The point here is that BPM Systems have a pure software development aspect and a social collaboration aspect. The pure software development aspects can only be properly evaluated by IT people. And while the social collaboration aspect matters to both the business and IT people, it doesn't take special management skills to evaluate those collaboration features. Hence the conclusion is that IT departments should drive the selection of BPM Systems, not the business managers.
