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.
All Things D
ARS Technica
Engadget
GigaOM
Mashable
TechCrunch
The Verge
Venture Beat
Wired
Chris Brogan
Brian Solis
Chris Dixon
Clay Shirky Blog
HBR Blog
IT Redux
Jeremiah Owyang
Radar O'Reilly
Seth Godin Blog
SocialMedia Today
Solve for Interesting
The TIBCO Blog
Lifehacker
Rightly quoted the industry’s present Vibe. It is quite general that the firms going for BPM request M-consultancy firms for strategic planning, while defining the scope and requirements are carried out in-house or given to a IT service firm. Finally, the development and deployment is carried out by a vendor selling the BPM suite.
There should be a tight connect and thought flow during planning, scoping, process analysis and design which ensures that the goal view is not lost.
Absolutely.
Couldn’t agree more with the sentiments expressed here. I would take it a step further — IT-enable the As-Is process (i.e. put it on a BPMS platform). Why? Because most process owners don’t believe that a BPMS is either worthwhile or agile. They’re conditioned to think six to thirty-six month delivery times when any IT is involved. And having to somehow manage the resulting change (and push back). Enabling the As-Is doesn’t change the process (by definition) but it gives them all of the process intelligence the BPMS platform can deliver as well as by-product data for doing the various LSS kinds of analyses. And, they can see, by example and by doing, how quickly minor (and major) changes can be put in place. This, in turn, allows for incremental, unit-led improvements at the speed of accommodation. Of course, there are always “yeah buts” (e.g. but our process has to interact with XYZ computer-based application) but most of this can be dealt with in the short-run by “servitizing” these, even if those services have to be done manually, or screen-scraped.
Very valid points. I especially liked the ‘yeah buts’. And that takes us then to another topic - that of setting and managing expectations, resistance, perception, managing change…. Thanks for your thoughts Richard.
To me, the major reason for implementing an As-Is (aside from providing the process owner with process visibility in terms of instance progress and overall metrics) is that any subsequent changes on the path to a To-Be can (and should) be engendered and proposed by the process stakeholders. Then change push (and resistance) becomes change pull (and ownership). Change management, as some organizational pundits note, is an oxymoron … better to set the conditions for emergent change, than to try to manage its consequences.