by Neil Ward-Dutton

As BPM goes mainstream, so the bazaar overtakes the cathedral

Feature
Apr 11, 2010
IT LeadershipIT StrategyTelecommunications Industry

Process improvement has been part of the business landscape for many decades. For the vast majority of that time, improvement techniques were focused on processes which took big investments to get started or to change: manufacturing processes were at the heart of the picture. Not surprisingly, the people driving the process improvements took a very deliberate, scientific approach to recommending and making changes. Such an approach is essential in situations where there’s a lot at stake, and in physical processes like those found in manufacturing, the costs and risks associated with suboptimal processes can be huge. The Six Sigma and Lean movements were both spawned from this environment. Over the past couple of years, though, process management thinking and tools have now well and truly broken out of the domain of physical, capital-intensive processes to be applied to the worlds of knowledge work and service improvement. Here, the challenge associated with improvement and change is different. If you’re looking to improve a customer service process, the cost and risk of a suboptimal change is much lower than if you’re changing a manufacturing plant layout – for one thing, you can probably make further changes to tweak things relatively straightforwardly. What’s more, many customer service processes are so poorly understood that even a suboptimal improvement – a kind of “good enough for now” change – can yield massive results. In these kinds of processes, business agility tends to be much more of a key consideration than the cost or risk of making suboptimal changes. So – do these methods and tools work as well in the ‘new world’ of process management? The challenge with scientific process improvement and management methods is that they tend to create “cathedrals” [1] – closed environments where access to the tools of change is closely controlled. Now students of Lean techniques will say that lean thinking relies on empowering workers to drive continuous process improvement – but my contention is that in practice, in a great many organisations which consider themselves Lean thinkers, access to the tools of change is closely controlled by a select group. This is precisely what you want where the cost or risk of cocking up is considerable – but as I’ve already outlined, in looking at improving knowledge work this might not necessarily the case. Where business agility is the number one concern, it pays to look at how to drive change without relying on a cathedral to house your priests. The ‘bazaar’ model (to once again refer to Eric Raymond) – which explicitly aims to throw open access to tools and information to a broad audience of interested parties and contributors – is very interesting here, because (with the right nurturing) it can create an environment where acceptance of process change is a natural by-product of the process improvement work. Every good project manager knows that if you can involve people in a business change project right from the very start, and demonstrate that you’re taking their ideas and concerns into account, you stand a good chance of the changes you’re making being accepted by those who are impacted. If you send some business analysts out to gather requirements and then have a project team lock themselves away for six months while they implement a new system, getting ‘user acceptance’ can be a real bitch. Where so many change project managers have struggled in the past is that the tools to really support the ‘bazaar philosophy’ of open involvement in system or business process change haven’t existed in a form that makes information really accessible to disparate groups of people with varying skill and experience levels. Now, though, with today’s BPM technologies, we’re finally getting there.

Now you may think that I’m way behind the curve here. After all BPM Suite (BPMS) technology, which some promised would usher in a “third wave” of process improvement which allowed business people to drive system change without active IT involvement [2], has been with us since the late 1990s. However the truth is that the initial wave of BPMS technology really only started to show us a glimpse of what might be possible. The marketing rhetoric of the BPMS vendors in the early days was very compelling, but the technical truth lagged somewhat behind. Early BPMSs were very good at providing declarative, model-driven environments for building process applications; but they tended to be closed islands of technology that still failed to deliver what was needed to truly engage non-technical business people or to truly engage technical software developers and integrators (who, not surprisingly, were still needed after all). Now, though, we’re seeing specialised BPM technology developed in a couple of ways that starts to see the initial BPMS promise of enablement of inclusive, agile business process change projects fulfilled. Specifically: • Hosted versions of BPMS technologies from established companies like Appian, Cordys and Pegasystems and from start-ups like RunMyProcess and ProcessMaker are enabling companies to get on board with the technology quickly and cheaply. Not everyone is deploying their processes operationally on to these hosted platforms, but a growing number are. And even where they are not deploying live processes, they are using these hosted platforms – and other hosted tools that focus more on process discovery and analysis (like Lombardi’s Blueprint, IBM’s BPM BlueWorks and Software AG’s ARISalign) to explore the potential of the technology much more quickly and cheaply than they could have done before. Hosted platforms make building a business case for BPMS implementation a whole lot easier. • Companies like Active Endpoints and Bonitasoft are putting model-based process design and development tools into the hands of “traditional” software development teams. These tools don’t currently offer the same level of end-to-end functional completeness as the tools from the BPM specialists, but they do provide most of the key capabilities that enable developers to keep engaging non-technical business stakeholders in process change and implementation projects as they progress. • A range of BPM technology vendors -including Appian, Pegasystems, Software AG, IBM, and Oracle -are weaving social software features (discussion forums, collaborative editing environments, tagging, annotation, instant messaging, team profiles, and so on) into their technology platforms and tools. These features make it easier for distributed teams of interested parties with widely varying skill levels to stay in touch, track progress, make comments, and approve changes – with all the dialogue being recorded for quality and auditing purposes. None of this is to say that scientific methods and approaches to process improvement are worthless or that they have lost their relevance. There are many situations where a highly structured approach to process improvement, driven by highly trained specialists, will continue to be the best approach. But the BPM market in 2010 is a market that’s increasingly dominated by tools, technologies and approaches that lean much more towards the philosophy of the bazaar rather than of the cathedral. To me, the biggest value of the former philosophy over the latter is the way that where a cathedral-like approach to process change tends to focus everyone’s minds on the quality of the design of an improvement, the natural outcome of a bazaar-like philosophy is improved quality of the ultimate outcome – that is, the acceptance of the change or improvement by those people it impacts on a day-to-day basis. A beautifully-designed process improvement is one thing, but if it’s not accepted then you’re screwed. And in knowledge work and service improvement scenarios, where people are the product, acceptance is all. [1] The Cathedral and the Bazaar, Eric S. Raymond, 2000 – http://www.catb.org/~esr/writings/homesteading/cathedral-bazaar/ [2] BPM: The Third Wave, Howard Smith and Peter Fingar, 2003