BPM vs. BPMS: How To Think Big and Act Small

Before I get into the actual HOW-TO part, let me reiterate another perspective as to why current BPM approaches and/or BPMS are so lacking. Rather than being upset about my critical observations, the BPM community should use the opportunity for discussion (TED: Dare to Disagree) and try to validate and prove BPM theory. Therefore I do not understand the lack of response after I provided a simple formula two years ago as to why flow-charted processes won’t deliver BPM benefits in a larger business. Not a single expert or vendor has brought forward a single counter-statement. Does that not make you wonder?

There is on the other hand a huge library of books, white papers, blogs and seminar programs of how to implement BPM in large corporations. They all boil down to a few key messages that are repeated over and over again with no more than anecdotal proof that any of this works. I am referring primarily to BPM methodology, but also to its eventual implementation via a BPMS of some kind. BPM should always be an enterprise effort, while BPMS are mostly localized projects. One can say that BPMS are managed by BPM governance.

Even with the best-of-breed BPMS, most large businesses struggle to identify current processes and model them towards some desired end-state. Users perceive BPMS to be restrictive and the offered participation in the governance as a smoke screen to hide that the ROI is mostly achieved through manpower reductions. Ultimately, vendors propose that the savings of small, local BPMS projects can simply be applied to the larger business.

To implement BPM successfully supposedly requires …

• … an executive sponsor who will enforce the use of BPM.
• … governance to avoid scope creep and increase business agility.
• … first a culture change within the organization.
• … to prove its return on investment in a short time.
• … that BPM methodology is more important than BPM software.
• … the ability for business endusers and stakeholders to create processes.
• … BPM software that matches corporate needs and maturity level.
• … stages of analyze as-is, model to-be, implement, monitor and improve.
• … tools for: business strategy, process analysis and design or mining,
• … flow-execution, rules, analytics, monitoring, content, and security.
• … the integration with systems of record, Social, Mobile and Cloud.

Most people involved in BPM will not dispute those above requirements. They seem to be a common consensus. If all of them would be easily achievable I would have not much of an issue with them in principle. But that is not my main point. I propose that in the real world they are actually contradictory, because BPM and BPMS mean very different things. But then there is no way to sensibly do BPM without a BPMS …

The NINE Contradictions in BPM Implementation Principles.

• If BPM would be capable of being business-driven then there is no need for executive enforcement.
• If the implementation of processes would really happen through users there is no need for governance.
• As business users can maybe draw a flow-diagram but can’t make it executable, the BPM stages are all performed by experts, actually reducing agility.
• Both BPM methodology and BPMS ignore that users understand processes in terms of content and context and not in flow-diagrams.
• To change business culture is a long term prospect and collides with short ROI time frames.
• What kind of culture change should be necessary to motivate people to follow flow-diagrams all day.
• To reduce scope creep and ensure ROI, governance limits end-user requirements and achievable quality.
• A holistic BPM methodology is fragmented over different software products (BPMS, rules, events, content, integration) for implementation.
• As the fragmentation requires governance, any change requires long-term planning and therefore reduces actual business agility.
• If a BPMS is chosen to match current needs and maturity level then it has to be replaced frequently as the business matures.

I could go into a long explanation of why I see each of those contradictions, but for once I will try to keep my posts shorter and less philosophical. If you know how business and IT really works then you know that these contradictions are correct. But how come that no one has yet pointed those contradictions out? You will find ‘experts’ that speak about the ‘Triple Crown’ of BPM implementations, when they increase revenue, increase quality AND reduce costs, all at the same time!

Supposedly BPM – simply by following the methodology – is able to balance organizational assets and resources to provide differentiating services to the customer, ensuring maximum value at the lowest cost throughout the value chain. I want to evaluate that claim. Differentiation and individualization can increase perceived value, but cost money and need manpower to increase revenue and improve the bottom line. BPM is an investment in the future and ROI can only be long-term. But during implementation, BPM standardization freezes processes into average happy paths that then are very difficult to change because of the software fragmentation I pointed out above. There is actually no differentiation and individualization possible and it becomes much harder to do as it has to go through the governance cycle.

How To Think Big and Act Small in BPM

BPM methodology and BPMS implementation must go hand-in-hand or at least have the opportunity to do so. Adequate technology must support the BPM enterprise effort, even if it might only be used locally at first. BPM must think big, but BPMS must allow small scale perspectives on the business user level. Considering them separately is a huge mistake. While the adage of ‘Small is Beautiful’ has lost its luster it is still as valid. Even in Taichi Ohno’s Toyota Production System (the grandfather of LEAN) it was the worker cell on the factory floor that was responsible for quality and outcome and not the business strategy or a monitoring software. Methodology does not change your business; only people do.

Once the BPMS has been setup there must be no further process implementation stages. They alone kill the promised agility. Install it and let the business have a go. If they struggle, don’t enforce a useless standard but figure out with them what UI functions they will need to describe their processes intuitively by picking resources from library menus. Different business units will have different ideas about that. Forget process or UI standardization if you really want to empower the business. Standardization is only needed because implementing processes in flow-diagram BPMS is so expensive and the BPM governance is so slow.

I propose that the key aspects of implementing BPM successfully are quite different once someone understands the issues of social complexity, workplace psychology and people motivation. These define what weapons to choose and not revenue, quality and cost. They are consequences and outcomes, driven by people and can’t be enforced as immediate targets. Henry Ford said: “A business absolutely devoted to service will have only one worry about profits. They will be embarrassingly large.”

But how can one bring the larger organization together to work for commonly understood objectives, targets and goals and ensure that the customer perceived value is truly delivered? BPM methodologists tell me all the time that it really isn’t about flow-diagrams.

I propose that the following is needed to make BPM work:

• Chose (buy, build or integrate) a homogeneous ‘System of Engagement’.
• Create Top-Down transparency through a business-architectured value stream visible in the software.
• Define budget responsible process owners and their outcomes and/or handovers. (Authority, goals and means)
• Define with IT the ‘Language of Business (Process)’ that non-technical users can use to create processes.
• Link with ‘Systems of Record’ and refine UI’s until the business units really want to use the system.
• Define with process owners the targets for ‘bottom-up transparency’ that enables management reporting.
• Let business units define how to execute and achieve the defined process goals and outcomes.
• Business users collaborate freely to assemble resources (data, content, rules, forms, tasks) into goals. (NO UPFRONT DESIGN)
• Successful goal-achieving work can be stored as templates and reused and still be modified for each execution. (=ADAPTIVE)
• Motivate business users through autonomy, job security and recognition and forget monetary rewards.
• Enable users and customers to vote and rate each aspect of the process in real-time.
• Continuous improvement is enabled by user empowerment and the embedded project and program management.

Now clearly, I do not have any proof that this works as a BPM theory in itself. But the above (and thus concepts of ACM) is based on a broad set of accepted scientific knowledge about systems theory, complex adaptive systems, and behavorial economics. BPM/BPMS as currently promoted by huge advertizing budgets have NO scientific basis at all!

In the ‘Age of Complexity’, BPM methodology and ‘governance’ must be embedded in technology. The resilience required in this dynamic age can’t be achieved through a command and control attitude. Executives have to provide the perspectives and principles of the ‘Big’ while the people who actually do it, utilize their experience to execute and innovate in the ‘Small’.

The experiences of Mobile and social networks prove that technology is the enabler of change that brings them together.

About Max J. Pucher

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

‹ Sapere Aude – An Age of Enlightenment for Business?

Naive Intervention – Part 1: From Antifragile to Models Behaving Badly ›

Posted in Adaptive Case Management, BPM, Business Architecture, Business Strategy, Executives