Home

As I work to prepare the agendas for the fall schedule of the Denver chapter of the Association of BPM Professionals (ABPMP), I thought it would be timely to step back and define BPM.

First, let’s get the acronym expanded correctly. I still hear some say BPM is Business Process Modeling or Business Performance Management. No, to me at least, BPM is Business Process Management. Perhaps this is the simplest definition we will all agree to. As I went searching for more definition, I found that there is less agreement than I expected and perhaps even a rift in those trying to define BPM from a technology vs. a more pure process perspective.

First stop (as usual for me) was Wikipedia.  They start with:

Business process management (BPM) is a management approach focused on aligning all aspects of an organization with the wants and needs of clients. It is a holistic management approach that promotes business effectiveness and efficiency while striving for innovation, flexibility, and integration with technology. Business process management attempts to improve processes continuously. It could therefore be described as a “process optimization process.” It is argued that BPM enables organizations to be more efficient, more effective and more capable of change than a functionally focused, traditional hierarchical management approach.

I found this good in that it starts with the idea that BPM is a management approach focused on clients (I prefer customers, but good so far.) I like that the stated goals are both effectiveness (doing the right things) and efficiency (doing those things better) and that it works to create innovation, flexibility (agility) and continuous improvement. The rest was less than totally satisfying. It fails to explore the enterprise nature of BPM. In its overview, it acknowledges that BPM involves people and technology, but seems to focus on technology. It mentions  that “in the IT community, the term ‘business process’ is often used as synonymous of management of middleware processes; or integrating application software task,” and thankfully, stops short of equating BPM to SOA (Service Oriented Architecture.) The remainder of the article discusses the Design, Modeling, Execution, Monitoring and Optimization cycle and the technology supporting that cycle.

I next found more Eccentric Definitions of BPM from BPM.com. Wow, I had no idea there was so much confusion. In this article, Keith Swenson concludes that:

Overall, about half of the definitions I encountered were ones that talked about BPM being a management practice.  Most vendors carefully state that BPM is an initiative to improve the business, but often they tie this to IT with the reasonable idea that if you are going to improve your IT system, you should start with ideas that come from a BPM initiative.   These statements don’t actually equate BPM with system architecture, but I feel that many people reading this see the association so many times that they come to think of them as the same thing. There is an “IT community” which talks about BPM as being equal to/converged with/part of system architecture/SOA/EA.  There is another “business community” that represents the non-IT management side and sees no connection to system architecture at all.

More on this line of thinking from Ashish Bhagwat of the Redux blog:

It’s time SOA-wrapped-BPM gave way. We are already talking about moving on to social, collaborative and adaptive favors of BPM.

BPM is not about integrating your systems and making them work together. Workflow, as promoted by platform vendors and integration centric vendors may look like that, but integrating with systems is an approach, not objective. Process visibility/monitoring are not a post-implementation by-product. Those are one of the drivers for BPM.

The question should be – what are my operational issues, what are the tools available to me to get a solution for them?

Yes, it is time SOA-or-other-IT-wrapped-BPM gave way! BPM starts with Business for a reason. It presumes that business processes are key assets and should be managed with as much rigor as other assets (I’d argue more.) The enterprise processes of a business start with the customer and a process Design that understands what customers value and ensures that value is delivered. Modeling helps verify that the process design is innovative, effective, efficient and flexible and identifies where improvements can be made. Applying six sigma, lean, business process improvement, UCD, STP,  agile applications, organizational design and other improvement techniques all may help generate improvement. Until the new designs and their associated improvements are Executed so that the business uses them, no improvement will result. Execution will likely require good project management, change management and IT development. Until processes are Monitored, no continuous improvement and ongoing Optimization can result. This monitoring must allow both tactical adjustments to processes as well as strategic guidance of the business based on environment and customer changes.

Yes, I support the Design, Model, Execute, Monitor, Optimize cycle. But, it is not just tactically focused. Does it require a BPMS, SOA or other IT?  Maybe, eventually. But possibly not to reap benefits from many of the BPM improvements that can be made. Technology is an important tool that helps to deliver benefits. It is not necessarily the starting point for BPM.