Put the ‘BPM as a Concept’ aside for a bit and look at BPMs tech-related benefits. One of the things at the top of your list is likely to be how it is a Rapid Application Development platform and how it helps you quickly put together process based solutions with much less development effort than a conventional ground-up ‘build’ would let you.
And yet, that has really not been among the top things to write home about. Especially when you see BPM projects taking more time to go live than it seems acceptable. There are several reasons behind this and all these factors contribute to varying degrees to the success or failure of a BPM implementation.
Unlocking the advantages of BPM – both as a management concept as well as a technology platform has been one of the most fascinating topics related to BPM for me. I have mulled over this quite a bit here on SuccessfulWorkPlace.com as well as on my own blog and elsewhere.
Don’t slice and dice
Of late, I am beginning to believe more and more strongly that one of the most significant factors that influence the success of BPM initiatives could well be the way many firms seem to be going about the whole thing. A typical BPM project starts with strategic planning and process improvement, process and solution design, then development and finally delivery, and many firms seem to be dismantling the entire initiative into these (or more) separate streams of activities and assigning them to different teams and different vendors.
Slicing apart a project in such a way can lead to execution silos each likely involving different vendors, different resources and different skills. Each team is bound to have its own interpretation of the needs definition, their own understanding of BPM objectives, and target outcomes. This causes a serious lack of synergy and ultimately results in the loss of a huge opportunity to unlock value from an implementation.
While you might think that this can be true about almost any software implementation, in a BPM implementation these pockets of disconnected silos exacerbate chances of failure even more, and render these implementations more operational in nature. This could well be the reason why the great BPM promise has a smaller chance to see the light of the day. This is probably how all those jaw-dropping benefits slip through the fingers.
There are of course several reasons why this slicing up into silos is done – all backed by sound rational, of course. Vendors typically have different specialties to offer that align better to these different silos and it certainly is in the best interest of a firm to leverage the right vendor for the right set of competencies.
Yet, in this quest, the crying need for that essential degree of continuity is often overlooked.
Maintain the context
If you truly want to unlock the benefits of BPM – both as a concept and as a technology platform, it is important to ensure there is continuity of context as you move across the different stages of implementation. The ‘context’ of course needs to be constant, consistent and must equally influence all stages of the entire journey – from strategy, to design, through to development and delivery.
When you have this ensured, and get all teams aligned to the big picture, with all skills orchestrated suitably to contribute from their own unique areas of strength towards delivering the same outcomes, you create a winning approach. It then becomes hard to imagine how BPM can’t be exploited, for example, as a Rapid Application Development Platform.
Killing Silos is one big advantage of BPM. If you want to achieve that, let there be no silos in your approach to BPM implementation. Tie everything up end-to-end to be sure you get to the end you had in mind at the start.