After a number of engagements with clients who are in the middle of BPM projects I’m developing a growing collection of “lessons learned”. Four of these lessons come up time and time again when I’m called in to support a BPM initiative, often when it is already going off the rails.
Don’t even start the project without having a clear business outcome in mind
One of the most depressing things a consultant can encounter is a fully resourced project that doesn’t have a clear or measurable objective.
How on earth can you demonstrate the success of your project if no-one has agreed what “success” looks like? It isn’t good enough to justify a BPM initiative by saying “we’ll be more flexible” or “we will improve efficiency” – You need to be able to describe and specify a clear business outcome that addresses a clear business issue. When I was the CIO of a sporting organisation I would regularly ask “How is this going to enable us to bring more people into the sport of sailing?” – Whatever your mission is, you have to ask a question very much like this. Whether your organisation sells financial services, cars or fridges there is no point in commencing a BPM initiative unless you can clearly explain how it will help you sell more of them, more effectively.
Next comes the really tough double-barrelled question; “How much will it cost, and how much will we benefit?”.
This question strikes to the heart of the “business-IT alignment” debate which has bubbled about in the background ever since the first mainframe was switched on. Business-IT alignment isn’t a complex problem – The business cannot see clearly how much it benefits from IT and this is largely down to the fact that IT professionals are often either afraid or unable to specify the benefits, and make a professional commitment to delivering them.
The downside, of course, is that there are negative consequences associated with failing to deliver promised business outcomes, the upside – however – is the kudos IT can get when it exceeds expectations.
Do not start a BPM project, or any project for that matter, without a set of clear and unambiguous goals.
Don’t try to model the world
Throughout the history of computing IT has been subjected to a certain degree of “modelling madness” – A desire to use the latest modelling technique to describe the world in a machine readable way.
During the 1980’s corporate data modelling was the vogue – teams of analysts struggled to create complete and definitive models that described all of the data within the organisation. While this is achievable within very small systems, within large organisations these exercises become a never ending cycle of analysis, amendment, and yet more analysis as old ground needs to be covered again.
The same is true for business processes – If you attempt to model every single process and process step, you’ll find yourself drifting into madness, as you constantly struggle to keep the models you’ve created up-to-date as you continue the task of recording the processes you’ve not yet added to the repository.
If you did model every single process step within your organisation, what will you do then? Process management technology isn’t meant to be a replacement for application software, and BPM tools shouldn’t be used as if they were a new kind of fourth generation language.
Focus, instead, on the processes that matter – More importantly don’t focus on the processes that matter to you, focus on the processes that matter to the business (these will usually be the processes that matter to your customers too).
Take a portfolio approach to your business processes
Much as I hate to add a new acronym to the already confusing mix of three letter combinations, if your BPM initiative is to be successful, you have to think in terms of PPM (Process Portfolio Management).
The essence of PPM is that your first task is to establish at a high level, which processes matter most to your business – In terms of its ability to differentiate in terms of product or service.
We advise clients to classify high-level processes according to three categories – Utility, Assembly and Delivery. Utility processes are those that need to be fulfilled, but which do not differentiate your business from any other in the same marketplace. These are vital processes – but they’re only differentiating when they fail. These processes are typically fairly stable and are often good candidates for outsourcing.
Assembly processes relate to how you combine and compose utility processes and your unique business rules to create (or assemble) the goods or services that you sell. These processes define the way your “offer” to the market is different from the competition. Typically this class of process needs to be adaptable in the face of competitive pressures but doesn’t need to be completely transformed – It’s unlikely that a bank is going to suddenly get into the “grocery selling business” (although this comes with the caveat that in the UK a chain of grocers (Tescos) has entered the financial services market). The third class of process – “Delivery” lies at the edge of your business – it defines how you interact with the outside world. These processes are often highly differentiating and highly dynamic.
Having done this triage – it’s then much easier to focus your efforts by prioritising those processes that differentiate your business the most and which must be capable of change.
This exercise also forces everyone in the business think about processes in terms of their real value to the business. Even if you take this exercise no further, simply knowing what it is about your business that makes it different is likely to put you well ahead of many of your competitors.
Business processes belong to the business – and responsibility for defining them should as well
The history of computing is littered with examples where a well-intentioned IT group has attempted to define business processes in the absence of clear direction from the business. This has to stop – Not least because we’ve shown time and time again that we’re not very good at reading the minds of our line of business colleagues.
They’re “business” processes – they should be owned and defined by the business. It the business is unable or unwilling to take this on, then it is likely that they, and you are going to be disappointed with the outcome of your BPM project.
