When the idea of BPM as we understand it today first began to gain currency (when Smith and Fingar published their book 'Business Process Management: The Third Wave' in 2003), the distinction that was clearly made between BPM and its predecessor, Business Process Reengineering, was that BPM explicitly recognises that business processes change over time, and seeks to help organisations enable and drive continuous change through the lifecycles of processes.

So by definition, then if you’re serious about implementing a BPM initiative, your ability to manage process change should be your central consideration.

If you have analysed the business domain(s) that your BPM initiative is going to impact, and it’s clear that ‘change enablement’ is a key concern for the process(es) under consideration, the next step is to think about the different activities involved in managing change and how they will likely apply in a BPM initiative, and put plans in place to explicitly address the needs of those activities.

I can’t emphasise enough how important it is to start thinking about this right from the beginning of your initiative. It’s vital to get the ball rolling soon after the project commences, because that’s typically when the overall energy and momentum in a team are at their highest levels. Where organisations only start thinking about how to support continuous process change after an initial system has gone live, it’s very often too late.

Process change management goals and enablers
Software tools vendors might try and convince us all that change management is all about having the right functionality available in the tools that you use - but the truth is that although tools are an important enabler, successful change management - in BPM, just as in other areas - is primarily a question of who’s able to make what kinds of decisions, how, where and when.

There are three goals you need to aim for if you want to create the optimal environment for successfully managing process change. First, get people involved; second, keep track of process assets; and third, link the entire process improvement lifecycle from end to end. Let’s look at each of these in turn:

• Get people involved. The processes that BPM initiatives typically address span multiple business teams and departments; and in order to successfully prosecute process improvement beyond simply documenting a process, personnel from both business and IT teams have to play key roles as an initiative involves. Your organisation has to be tuned to encourage involvement from all necessary parties, and your tools have to be able to make models and other BPM assets comprehensible to all parties (not just software developers).
  
  
• Keep control of your assets. If you don’t have a handle on the assets (documents, models, software designs, etc) that you create as part of your BPM initiative and if you can’t isolate them from each other effectively in order to make sure that changes to them are consistent, then you will have a very hard time indeed scaling up any change effort beyond one or two processes and a handful of contributors/reviewers.
  
  
• Link the entire lifecycle end-to-end. Process change can only be effectively driven with the right metrics to hand - if you don’t have independent and trustworthy verification of the details of the current situation (how well the process is performing today; frequent problems; and so on) then the best you can do is make changes based on individuals’ own perceptions - and those are often coloured by personal/political motives, lack of information, and so on. Getting hold of the right metrics means you have to have a system in place that enables you to clearly and consistently 'join up' the models and assets that play roles within process discovery, design, deployment and monitoring. Without that ability to join up the different stages of the process improvement lifecycle, there can be no reliable feedback loop driving continuous optimisation.

Given these three goals, what are the key enablers for driving effective continuous process change? As we’ve intimated above, having the right technology tools is only one part of the story. It’s all very well to have tools in place that can put power in the hands of business analysts (or even business managers or individual process participants) to drive change - but by itself that’s a recipe for disaster. To drive sustainable change that doesn’t degrade your processes into chaotic, undocumented, unmaintainable messes, you need to balance the 'change enablement' capabilities of the right tools with a well-thought-out approach to process governance.

There are three key elements of process governance you need to consider early on in your implementation:

• Senior business sponsorship. Any serious organisational change requires a dedicated senior business sponsor: without such a sponsor it’s very difficult to drive through changes to working habits. This is particularly true of BPM initiatives, because typically the changes in question require acceptance from multiple business teams that may not make sense to individual departments in isolation - it’s only by seeing the 'big picture' of the change that the benefits become clear. Senior business sponsorship comes with a wrinkle in the context of BPM, however: getting senior business sponsors to commit to involvement over long periods (longer than 6-12 months) can be very difficult, not least because in many organisations, senior business sponsors can change roles yearly. However it’s vital that there’s some kind of senior business representation/sponsorship in place even once an initial BPM implementation goes live; without it, further process optimisations and changes will become ever harder to drive through. Consequently, 'sponsor succession planning' is an important consideration - even early on in your initiative.
  
  
• Clear lines of accountability. We’ve conducted a number of best practice BPM studies, and one thing that arises consistently as a critical BPM success factor is the clarity of accountability. The more opaque the webs of responsibility regarding processes, process change and IT assets are, the less likely it is that you’ll be able to succeed in the long term. Successful process change requires an up-front, clear analysis of who is accountable and responsible for the business processes being changed; who’s responsible for sponsoring the change; who’s responsible for owning and changing any IT systems that might be affected by the change; and who’s responsible for managing any human resources / working practices that might be affected by the change. You need to map these stakeholders, and work consistently to make sure that the impact of changes on these people and their charges are clearly communicated so you can maintain buy-in.
  
  
• Assigned authority to review, prioritise and audit change. In order to manage process change consistently, particularly at scale, there must be a clearly-defined authority which has the power to review all proposed changes and audit changes. The presence of this authority may be mandated by industry or government regulation; but even where it isn’t, its presence will likely be a critical success factor if you have multiple business processes under change management. Of course, the authority to review and prioritise change doesn’t mean that that authority is always discharged in every case: but in an environment where resources (certainly IT resources, and perhaps business resources, too) are constrained it’s important that such constraints can be proactively considered as part of the mix when exploring the potential benefits of changes.

These goals and enablers together form should provide a set of inputs that you can use to create your own governance framework for managing process change. Such a framework won’t guarantee success; but particularly if you’re going to be managing change at scale, a working governance framework will be absolutely necessary. The sooner you start putting one in place, the greater your chances of success.

Neil is an accomplished IT industry analyst with over 17 years’ industry experience. Neil is a co-author of 'The Technology Garden: Cultivating Sustainable IT-Business Alignment' (Wiley, 2007) and is a regular speaker at conferences throughout Europe