BPM (Business Process Management) projects have been initiated in many of the organizations I talk to – it’s a hot topic. Vendors and consultants will be making all sorts of promises and bold claims – so I thought I’d document some of the things NOT TO DO. Jeepers I wish I had this info only a few months ago! These are useful to anyone about to start on the BPM highway – if thats you – You Must Read This Post!
I came up with this list after suffering a painful BPM program myself, but also after interviewing a number of CIOs and IT leaders currently going through, or have completed, a BPM program.
- Starting without Executive Business Sponsorship . If you don’t get the senior levels of your organization bought in from the offset, you’ll find making the necessary changes extremely difficult as you go along. In several cases I’ve heard that this is the biggest gaffe of programs.
- Thinking it can be implemented without expertise . If you think you can implement a BPMS (Business Process Management System) yourself without securing the necessary expertise, you can kiss the whole program goodbye. Every instance of home-brewed implementations I’ve discussed have failed.
- Running before you can walk. There’s loads of promise and potential with BPM, but don’t try and do too much, too soon. One program I saw fail with my own eyes started small but got too ambitious and eventually was canned due to continued failures and spiraling costs. You should use the early stages to learn from the experience, test users acceptance, decide on what Management Information you’ll need and moreover ensuring your methodology is fit for purpose.
- Don’t do it just to reduce headcount. This will fail – guaranteed. BPM is about Business Transformation and Continual Improvement – headcount reduction is a secondary benefit. If you’re doing a BPM initiative just to reduce headcount, you’ll find the user community retreats and you will discover it becomes impossible to encourage adoption or knowledge transfer.
- Don’t look at BPM functionally. BPM cuts across your organization is a cross-organization solution. If you think in stovepipes, you won’t get the benefits BPM promises. You should be process-centric and ignore functional boundaries, at least until you’re ready to talk about incentives and controls with functional owners. Processes belong to Process Owners, not Function Owners .
- Making irrational decisions . There comes a point in a BPM initiative where it feels ‘easy’, and changes are quite straightforward to implement. Avoid falling into the trap of over-confidence and not making decisions with all the facts and with the involvement of stakeholders. Small decisions in BPM can have long-term consequences.
- Choosing technology first . A number of failed initiatives I’ve discussed were because the technology was chosen first before the business really knew what they wanted. Vendors will always come knocking, and they’ll have reams of case-studies on how successful their product is. Avoid this! Be sure what BPM means to your organization first, then look at the processes, then the technology.
- Ignore your end users . Your end users are your customers and your most powerful arbiters! Your end users will make or break your BPM initiative by their choice to embrace it or ignore it. As process participants, your users are key to overall productivity, so make BPM about them and their job rather than about technology.
- Not giving your users adequate support . BPM often goes hand in hand with productivity initiatives. In these situations your user community is under pressure and I’d say quite nervous about BPM and its impact on their work. Make sure you provide all the support for end users so that they’re concerned with getting their job done rather than worrying about incentives and policies.
- Automating what shouldn’t be automated . If you automate processes that don’t work as you want them to, you’ll just be making what doesn’t work happen faster. You should be automating only what works for you! The principle should be to only automate a process once it is performing optimally (this isn’t the same as not automating activities that can be automated.)
- Building point solutions . BPM should be an organizational capability, not just a solution to a current problem or opportunity. Don’t forget, BPM is continual improvement. That should be your primary goal and therefore you should avoid…
- Close-coupled integration . BPM and SOA have gone hand in hand over the last years (although they started independently). Use sound SOA principles to avoid integrating your applications too tightly – otherwise you’ll have to change process logic everytime you change your core application, and vice-versa.
- Putting too much control into business users . One of the benefits of BPM is it puts more control back into the business, supported by IT. But don’t be fooled into thinking that the business can take on everything, as it isn’t that simple. Deep knowledge of the underlying IT services that enable your BPMS is needed to effectively deliver solutions.
- Not spending enough time building a common language . For many organizations, BPM is a new concept, a new technology and requires new skills and management practices. As you’d expect, these bring along a new language of terms. I think it is key that your organization gains a common understanding of the terms and that you build you own common language of terms before you get too far in the initiative. For example, it’s important that everyone knows the difference between a process and an activity .
- Not looking back and enjoying your success! BPM can be a long slog, and there will be casualties. So you should take each success as an opportunity to celebrate and enjoy the kudos.
