Over at her column2 blog, independent BPM consultant (and ace blogger) Sandy Kemsley stirred up some interesting debate with a post about Software AG’s AlignSpace community (which I also blogged about here btw).
The debate on Sandy’s blog centres around the value of “collaborative BPM” or “social BPM” – that is, the use of software environments with collaborative/social features to improve the quality of BPM outcomes. Today these environments (obvious examples are IBM’s BPM BlueWorks, the aforementioned AlignSpace, and Lombardi’s Blueprint) are primarily focused on process discovery and requirements analysis, and they help to enable a more open approach – where potentially large numbers of individuals have the opportunity to participate in analysing business and process problems or opportunities, and exploring potential solutions.
Terry Schurter (formerly of Bloor Research and the BPM Group, now Director of Product Strategy at Global 360) contends in his comments that
Creating open, collaborative process discussions, particularly in the unstructured environment of social networking is plain and simple a recipe for disaster.
Scott Francis of BP3 replied on this topic on his own blog, contending that
There is a technique for adapting to larger groups of stakeholders and still driving progress – and two of the key ingredients are having a clear decision maker, and having an outside consultant or facilitator (someone who can’t be tarred with any particular internal politics or biases).
I agree with Scott (and Mike). Just because these tools enable many people to potentially get involved, doesn’t mean they *have* to be. Just because a collaborative process discovery/modelling environment can be potentially accessed by many people, doesn’t mean you have to submit to some kind of anarchic “lowest common denominator”, completely open, woolly “conversation”. To make this assumption conflates the ideas of tools and process.
There are multiple aspects to the value on offer with collaborative BPM environments in fact, if we do things right:
- For a small group of expert participants with a lot of knowledge to contribute – and in large companies they may be geographically distributed – they can all play a significant role in mapping out problems and solutions – perhaps marshalled and guided by one or two nominated moderators. For these participants, they can contribute when it’s convenient – they don’t have to sit all together in a dark room for X days “until it’s done”.
- For a larger number of other participants who may have domain expertise that’s valuable in helping to explore perhaps one or two key activities or a subprocess, they can be invited to share their feedback.
- For other stakeholders (project sponsors, etc) – any experienced BPM practitioner knows that one of the big challenges to success is maintaining buy-in and involvement from the business as the project or programme unfolds. Giving them access to an environment where they can see how things are progressing, represented through high-level diagrams and conversations that aren’t technical, is a great tool to help maintain that involvement.
Yes, of course with any collaborative environment there’s *potential* for chaos – but only if you let the tool rule. And that’s never a good idea. So please let’s not confuse collaborative BPM with completely open, unstructured conversation.
good summary of the discussion, as usual from MWD
What I think is another potential benefit of opening up collaboration in process discovery and design is that inputs can be collected over several months – process users particularly can add their insight/inputs/suggestions as and when they encounter issues even as they participate in a currently running process – it doesnt have to be a one-time event.