Business Process Management’s Lost Decade

What did we achieve in Business Process Management (BPM) in the last decade? Frankly, not nearly enough. And there has been enormous waste.

Arguably the single most important root cause has been confusion. We’ve been lacking a common vision and vocabulary, which may sound ethereal but has had significant real-world impact. So let me start by nailing my colours to the mast with a definition of BPM in the simplest possible terms.

If all work is process (an assertion which was the startpoint for the APQC’s ground-breaking 2004 report on Business Process Management and remains essentially true), then business process management is about enabling the organization to deliver effectively and efficiently, and to continuously improve its performance. It’s about what we do, how we do it, who’s responsible and how we can do it better.

It’s true that variants on this definition have been endorsed, to varying degrees, by analysts, commentators and standards bodies. The confusion that has cost us so dearly is in the detail.

A decade ago, BPM was hot. There was huge excitement. The Global Business Process Forum event in London in the summer of 2004 had a triumphant tone.  Howard Smith and Peter Fingar had just published BPM: The Third Wave (with a strap line “Don’t bridge the business-IT divide. Obliterate it!”) and set a course to a new way of doing business.

Smith and Fingar had made the right noises:

“While automation can be readily achieved with a raft of existing technologies, BPM has a wider meaning… Processes are the main intellectual property and competitive differentiator manifest in all business activity, and companies must treat them with a great degree of skill and care.”

“..there is only one solution, an agreed-upon universal language that unambiguously describes ‘what we do and how we do it’, and to which all can subscribe.”

The trouble was that all hopes were pinned on the success of the BPMN process notation (V1.0 of which was published by the OMG in 2004) as the enabler of a world of enterprise collaboration where modelling and execution were one (in the jargon of that time ‘the model is the process’).

It was a wrong turn.  You don’t need to read much of its 516-page spec to realize that BPMN could never have been a universal language. Business people, at least for a couple of generations, are not going to easily surrender to the complexity of BPMN’s swimlanes and pools, events and gateways.

BPMN has not delivered in practice because it can’t enable business engagement. Despite substantial spending,  ‘BPM projects’ have often delivered lacklustre returns re-igniting debates about whether ‘BPM is dead’. BPM veterans talk of the failure of the ‘model-driven panacea’.

But BPMN was flawed too in a more subtle way. Its perspective is that virtually all work can be automated; that it is simply a question of understanding the process and the rules. Which may be essentially true in the very long run but it’s a long way from where we are now. It was a perspective though that suited software vendors perfectly, enabling them to co-opt – others might say hi-jack – BPM as a cover to market smarter automation products.

Analysts and commentators struggled to coalesce these disparate threads into a common vision and understanding. Gartner tried from time to time to re-assert the idea that BPM is far more than simply automation. But progress in aligning perspectives has been limited and painfully slow.  Even Gartner’s iBPM (Intelligent BPM) concept launched last year is widely seen as just the expansion of automation to include analytics.

In short, we lost the idea that BPM provides an holistic framework for performance management. It became an IT thing, an automation initiative.

Does that matter? Yes, and in ways that count.

Let’s start with the humdrum waste. What today is considered ‘normal’ is in fact a hidden overhead of huge proportions.

Most process mapping is low value and oftentimes a completely wasted effort. And what we’re talking about here is a global industry. In London alone, I can show you floors of sharp-suited consultants busy creating process diagrams for clients who have no idea what they really need.  Even where those process models stop this side of fantasy, they are, in a fast-moving world, more perishable than sushi on a summer’s day. Sometimes barely a year passes before the next team of consultants is back in, re-doing essentially the same exercise. It’s an ATM for the Big 4.

It’s not fair simply to cast consultants as villains. Even organizations that eschew consultants struggle.  Typically they have a myriad departmental snapshots of some part of their processes, often overlapping or with barely concealed gaps, and rarely synchronized. Teams define ‘their’ processes in a variety of formats and tools. Governance is an afterthought but that doesn’t matter because no-one reads them anyway. And even where there is an enterprise-wide integrated and governed process architecture in place, it’s almost invariably in a technical language that meets the needs of only an Enterprise Architecture cognoscenti within IT.

It’s not just the waste. This dysfunctional mash up has other, far more serious, consequences for the bottom-line. Look into the root causes of IT failures, of compliance failures, of failed cost saving programmes, of outsourcing debacles, of unsustainable Lean Sigma initiatives – and you’ll find a process failure.

Even worse though, this confusion encouraged other groups to dissociate themselves from BPM almost entirely:

It allowed Six Sigma and Lean practitioners, for instance, to feel justified in remaining aloof, in denial that their initiatives are always going to be more successful and more sustainable in operating environments where processes are being managed effectively.

Operational Risk and Compliance teams might bow the knee before the idea of a universal approach to business process management, but have invested instead in GRC platform solutions which only tenuously connect risks and controls with live end-to-end operational processes.

Business Architecture and Enterprise Architecture groups have happily invested enormous sums in mapping and modelling processes in ways that were only loosely linked – if at all – to live end-to-end operational processes.

Business Transformation teams have defined Target Operating Models that are strangely disconnected from operational realities.

In the recent words of a client, whose experience is typical: “In our organization, responsibility for process excellence has no home. It bounces around between the SAP team, the Shared Services organization, the Automation team and Compliance.”

In short, we have progressed. There is mainstream recognition that process ‘matters’ in some vague  way. Process thinking is slowly becoming part of our everyday reality. But we absolutely haven’t covered ourselves in glory. We may talk about process as enterprise DNA but we treat it in an amazingly casual way.

iStock_000000552191SmallI’m optimistic though that we’re in a pupa stage (when the caterpillar turns to goo). Many cells die but the few remaining cells – the imaginal cells – build a completely new and totally different body.

I think we can embed process perspectives in organizational cultures in ways that will transform enterprise capabilities.  There’s a BPM butterfly going to emerge out of this chrysalis.

But if we want to accelerate its progress, then a clearer vision and a common vocabulary must be a sine qua non. After a decade of debilitating confusion, we need a fresh start, linguistically speaking.

I can see that there’s a strong case for writing off the term ‘BPM’ as beyond redemption, leaving it behind as our caterpillar phase.

My preference though is that we should retain ‘BPM’, confined to the spirit of its original holistic definition. In this sense…

BPM uses the language of process to enable the organization to deliver effectively and efficiently, and to continuously improve its performance.

BPM leverages process visualization to create a space where everyone across the enterprise – operations, compliance, IT, sourcing, risk management, finance – collaborates to deliver for customers and to continuously improve.

BPM makes crystal clear what we do, how we do it and who’s responsible.

BPM’s goal is to build a platform that enables effective collaboration across the enterprise.

Done well, the BPM platform is personalized, intuitive and engaging – and branded, perhaps as the ‘Business Operating System’ or the ‘Business Management System’.

It’s like the BPM platform is the double helix, upon which is written the precise genetic code of the entire enterprise, its Business Management System.

All of which is a long way from automation.

It’s true that there are some relatively simple and highly-automated businesses – some boutique outsourcers or monoline insurers, for example – where a BPMS (a workflow automation platform) can put its arms around virtually every task undertaken in the enterprise.  In these cases, perhaps, the model is the process.  Whatever – these cases do illustrate the convergence of BPM and automation.

The point is that these are rare exceptions. An IBM survey in 2010 reported that 75% of all activities in the enterprise are manual tasks. For most organizations, and for a long time to come, BPM and automation can usefully mean different things.

However we define things (and it really doesn’t matter as long as it’s clear and gains widespread acceptance), clarity matters now more than ever. As we’ll see, there is a confluence of forces that are set to drive process excellence up the strategic agenda for the next decade.

BPM And The Language Of Process

iStock_000023250571SmallThere’s a ferment of ideas about the meaning and future – even the very existence – of Business Process Management (BPM).

Side-stepping those impassioned debates, I want to offer what seem to me to be some simple truths.

Every successful organization – every sustainable success – is built upon effective collaboration.  That may sound fluffy. But we can see all around us the failed projects, the waste and the missed opportunities whose root cause is ineffective collaboration.  And its consequences will escalate in a future that is faster-paced, more loosely structured and multisourced, more intricately automated – and more regulated.

Effective collaboration requires many things – vision, teamwork, leadership and so on. But it’s also true that any rich and productive dialogue – any effective collaboration – depends upon a common language. Process is that common language.

It’s the language of process that best enables effective collaboration between all the stakeholders, across functional silos, cultures and organizational boundaries.

But which process language?

The vision of the BPM pioneers was that BPMN could be the universal process language. “Don’t bridge the business-IT divide. Obliterate it!” was the rallying cry. In the long run, it’s the right direction. Re-reading ‘The Third Wave’ ten years on, it’s visionary but still essentially sound.

But BPMN hasn’t worked out in practice. It’s a stretch too far for most business people. For the foreseeable future, there’s no single process language that can fully reconcile the vital need of the business for a common collaborative language with the equally vital IT need for the rigour required to build applications.

BPMN looks set to progress – it’s a valuable standard from the IT perspective – but it has to be a generation at least before it could hope to realize its vision and become the universal process language.

If not BPMN, then what?  It seems to me that are three sets of questions to ask in defining the process language that best enables effective collaboration:

Is it visual and intuitive? Does it fully harness the power of visualization? In a hundredth of a second, we can scan an image and understand what it would have taken a hundred words to communicate.

Does it support real work? Languages die out if they are not useful.  It has to be rich, engaging and valuable. It must enrich understanding at every level, from the operating model down to the factory line or call centre, from Finance to IT and Logistics.

Does it enable sustainable innovation? Is it easy for users to feed back improvement ideas to process owners? Is it easy for process owners and stakeholders to collaborate on the design and implementation of change?

Note that IT is not left out in the cold here. IT may use BPMN for systems development but a universal process language that delivers in these three ways has huge benefits to IT as well.  It’s the business engagement that every CIO craves and the perfect framework for requirements capture.

Effective collaboration matters, and it requires a rich common language. Process is that language. Its force multiplier is something I’ll have to pick up next time.

Related Posts

25 Feb 2013    The Hidden Costs Of ‘Normal’ Process Management

28 Aug 2012    The ROI On Process Visualization

© Text Michael Gammage 2013