Ask my wife - I`m not your average dissident. Show me a rule and I`ll want to stay this side of it. So it`s not in my nature to be standing in front of the BPMN steamroller. But there is something disturbing about the way in which BPMN is heading for a landslide victory.
BPMN V2.0 is set for release next month. The big vendors are training their consultant cohorts in BPMN (and thereby able to re-brand their plain old `application consultants` as `business improvement consultants`). The large SIs are investing in BPMN practices. Industry commentators are joining in to trumpet the praises of BPMN. It`s a gold rush.
My earlier posts on BPMN drew a lot of fire. Why am I staring down the barrel again? What could possibly be the problem? Isn`t this the answer we`ve been seeking for so long? After all, one of the key stated aims of the OMG, the creators of BPMN, is to bridge the IT-business divide:
"... to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes."
I think we are drifting towards a consensus about BPMN that will surely take us backwards. And CIOs have an absolutely critical role to play in navigating this.
Vendors and consultants are heavily invested in BPMN. For many, who are tech-savvy, it`s what they understand. It`s robust, it`s integrated, it`s a bit academic - it presses all their buttons.
But the idea that BPMN can be a common language for business and IT is a delusion.
BPMN is the language of IT. The BPMN V2.0 spec is 496 pages. It`s complex - and needs to be because its eventual purpose is to create executable code. It has 63 Event symbols and eight Gateway symbols. It has not just swim-lanes, but pools as well, and even the concept of a collapsed pool. And in BPMN, tiny variations in the way something is drawn can fundamentally change its meaning. No way is this a language for the business.
To be fair:
* Authors like Bruce Silver have tried to translate BPMN V2.0 into something that might work in practice. But even his reduced palette of BPMN symbols - `Descriptive BPMN` - is imho [in my humble opinion] far too rigorous for business process stakeholders, and totally implausible as a means of reaching process end-users.
* Many commentators and consultants embrace BPMN, but recognise its flaws as a language for the business, and so feel free to be `flexible` in how they use it - simplifying and adding new symbols if necessary to make it work.
But these attempts to make BPMN work in the world of business reality surely just demonstrate its limitations. If BPMN is actually the language that can bridge the IT-business divide, it shouldn`t need this. At some point it must become so simplified and `flexible` that it`s not a useful language for anyone. It won`t be intuitive enough for the process stakeholder and end-user, or rigorous enough for the business analyst.
Separately but equally important, BPMN is `governance lite`. It was never designed to couple end-to-end business processes with risk management and business controls, within an operational governance framework. And it`s hardly built with continuous improvement in mind either.
We`re down to the wisdom of CIOs. They are being prompted by vendors, consultants and their own people to get on the BPMN bandwagon and declare a commitment. They have C-Level peers asking `What is our BPMN strategy?` They are under pressure to buy the dream and have an ambitious BPMN strategy.
But the best CIOs know that effective communication is the biggest single issue, and a fundamental cause of IT failures. The question that they will be asking of this new notation is this:
Will BPMN help me collaborate with the business?
And the answer must surely always be `no`.
BPMN has value within IT, maybe even high value. BPMN may be good for compositional work at the design stage. It is a natural language for reference models in the enterprise architecture domain. It may make sense to develop a hybrid process model of the enterprise with the lowest levels of the model, unseen by stakeholders and end-users, in BPMN.
But any organisation looking to adopt BPMN as a universal language that can bridge the IT-business divide is riding for a fall. And I`ll offer two data points to support this:
* A global manufacturer and Nimbus client ran an exhaustive evaluation of tools to support its global BPM strategy. At that time, they saw BPMN as hugely important. It was central to both their RFP and the subsequent proof of concept. But, as they investigated further, their thinking shifted. Now, 18 months after that evaluation and selection (and despite the fact that it is supported in Nimbus Control), BPMN has never in fact been used, nor are there any plans to do so.
* As a colleague put it: if BPMN is the answer now, then how come, after many years when ARIS has been the dominant market player, the ARIS EPC notation has never been embraced as a language that the business understands? After all, independent evaluations seem to confirm that EPC is a richer and more capable notation than BPMN - but, despite the prevalence of ARIS in the IT world for so long, the EPC notation still meets resistance from the business stakeholders, and mystifies process end users.
This is another example of where CIOs earn their salaries. Theirs it is to resist the easy option. They will want to cut through the BPMN hype, embrace what is valuable, and resist the waste of time and resources that will result from following the crowd. They know that business process is the right framework, and that further development of BPMN has value - but no way is BPMN the right language to engage and orchestrate the business.
Share
Editorial contacts