Business process management can offer organisations the opportunity to stimulate, design and deliver business transformation on an ongoing, repeatable basis. Since business process management (BPM) typically makes an impact on the whole organisation, as well as challenging the organisational structure itself, BPM projects are very complex and offer significant management challenges.
Because of this, many suffer delays or don't deliver their expected benefits. What follows is a list of 15 things to consider when beginning a BPM initiative:
- Executive business sponsorship
- Implementation without expertise
- Running before you can walk
- Reducing headcount
- BPM functionally
- Irrational decisions
- Choosing technology
- Adequate support
- Building point solutions
- Close-coupled integration
- Too much control
- Building a common language
- Enjoy your success
If you don't have senior level backing for your BPM initiative, you'll find making the necessary organisational and process changes extremely difficult.
Implementation without expertise
If you think you can implement a business process management system (BPMS) yourself without securing the necessary expertise, the program will fail.
Running before you can walk
There is a lot of promise and potential with BPM, but don't try to do too much, too soon. Use the early stages to learn from experience, decide on what management information you'll need and ensure your methodology is fit for purpose.
BPM is about business transformation and continual improvement. Headcount reduction is a secondary benefit. If you're using BPM just to reduce headcount, you'll find the user community retreats and it becomes impossible to encourage adoption.
BPM cuts across your organisation and it is a cross-organisation solution. You should be process-centric and ignore functional boundaries, at least until you're ready to talk about incentives and controls with functional owners.
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.
Vendors will always come knocking with reams of case-studies on how successful their product is. Avoid them. Be sure what BPM means to your organisation first, and then look at the processes and technology.
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.
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. Only automate a process once it is performing optimally.
BPM and SOA have gone hand in hand over recent years. Use sound SOA principles to avoid integrating your applications too tightly - otherwise you'll have to change process logic every time you change your core application, and vice-versa.
Too much control
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. Deep knowledge of the underlying IT services that enable your BPMS is needed to effectively deliver solutions.
Building a common language
For many organisations, BPM is a new concept and requires new skills and management practices and these bring along a new language of terms. Your organisation, therefore, needs to gain a common understanding of the terms before you get too far in the initiative.