Review: The Process Improvement Handbook

Don’t be misled by the modest title. In ‘The Process Improvement Handbook’, Tristan Boutros and Tim Purdie  are attempting something very ambitious. They want to found the Process Improvement discipline.

From their Process Improvement manifesto to the detail of their Process Improvement methodology, they attempt to rise above the ideological fray, to transcend the conflicting orthodoxies and to propose a new framework and an ‘all-encompassing guide’ for Process Improvement professionals.

Lamenting the manifold ways in which Process Improvement typically underperforms, or outright fails, they set out to re-cast Process Improvement so that it is ‘an enabler and not a hindrance’:

“With the huge growth in spending on Process Improvement by enterprises and the strong evidence that significant investment in this domain can lead to costs savings and better business decision-making, the time has come to make the Process Improvement discipline professional.”

You might ask whether the world needs another Process Improvement (PI) methodology. Continue reading

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.