Agree with Peter Hilton here:
The first we need to understand is: What are the collaborative aspects of a process? I assume meta stuff like:
The only thing you could "manage" now is make sure to put stuff in place that enables the collaboration and create some guidelines for the business to use it. Just to realize that - in the end - collabroation mainly comes down to culture again :-).
For most knowledge-worker oriented processes, collaboration cannot be an after-thought but rather needs to be an integral part of the process. The term "Social BPM" is an unfortunate moniker as BPM is not fundamentally about being Social (eg. broadcasting your status to your friends/followers etc.).
The question is what is the best underlying model for Collaborative aspects of a process. Several candidates present themselve, viz. document-centric, task-centric or conversation-centric models.
In my opinion the conversation-centric model is the most natural model for collaborative processes. The recent explosion in "conversational commerce" is an indicator of this. This is also why most collaborative "processes" are run in email today.
The biggest flaw with traditional conversational systems such as email and chat is that they are fundamentally stateless. i.e. the state of the discussion is only implicit. For example I might be having an email conversation regarding a Vacation Request. In this case, the state of the discussion, viz. the fields, documents, tasks, checklists of the Vacation Request are implicit.
The next generation of conversational BPM will make the state of the conversation explicit. Besides making it explicit, the state of the process will be synchronized with the conversation. And the ability to see how the state has changed with each comment in the conversation is also critical.
The other advantage of a conversational model is that processes emerge naturally (in the above example, the Vacation Request 'process' may start out with no state and over time as patterns emerge, state can be added as appropriate). This is a more natural way for knowledge workers to 'do processes' rather than up-front figure everything out.
The notion of seeing how the state has changed speaks to the larger philosophy of 'ask-for-forgiveness-rather-than-permission'. Highly permissioned workflows are both difficult for non-developers to design and tend to be overly prescriptive and brittle.
Agree with the comments but would emphasize that these Collaborative actions can be formal where all actions as data created are tracked with full audit trail, incuding emails. However there are points where what we call informal process are important and need to allow users freedom to think and act "outside the box". However in the work environment there is still a recognised outcome that needs to be recorded. It may be that time is the only guide in which case as say milestones in time reached but no action automatic reminders or escalations can be triggered. Could also involve external events that change the needs and this can be recognised informing the users as required. Always remember where new data/information is created does require the audit trail for compliance and or audit purposes i.e. who did what when.
The fundamental shift for businesses is that they need to recognise that far more aspects are now collaborative. So they need to redesign the business with tis in mind and enable the collaborative aspects to work better.
Our business is collaborative, therefore we need Chatter / Yammer / Jive / tbbr. This is way too simplistic a perspective. It is the easy (but wrong) opt out for execs and IT.
Recent Fortune article The Hard Evidence: Business Is Slowing Down, (see link)
Result of rise of technology & ‘collaboration’ tools…….” 60% of employees must consult with > 10 colleagues daily to get their jobs done. Half of that 60% need to engage more than 20 to do their work"
“Managing collaboration”—We BPM folks do love our guardrails, don't we?
Let's separate a couple of issues. Collaboration in the context of an application—for example, in the context of reviewing a submission for regulatory or financial approval—was never properly the focus of “social BPM”. In any event, BPM does a pretty good job of organizing this type of work without the need for “social” enhancement.
Then there is the matter of customer engagement through social media in the context of BPM-driven applications. Such capabilities have the power to truly transform the relationship between organizations and their markets; and yet, this use case also tends to be overlooked in discussions about“social BPM”.
Instead, what seems to have received the most attention is the idea of collaboration among insider stakeholders surrounding the creation and enhancement of process-driven applications. And it is on this battelfield that the idea of“managed collaboration” ultimately met its demise. Building and improving applications is fundamentally a creative endeavor—and creativity abhors management. Around my office, for example, the best ideas arise during chance hallway encounters or unexpectedly in the midst of a conversation on an entirely different subject. Furthermore, if I have to be concerned that my contributions are being captured for later audit, well... I'm gonna just stay quiet, thank you very much. I know I'm wrong ten times for each time I'm right, but that hardly means I want that fact attested to in the record.
Social BPM was a still birth as it was nothing else than lipstick on the BPM pig. I pointed this out five years ago.
Let me be blunt and to the point and not pussyfoot around the BPM pundits who don't recognize a business when they see one. A business is PURPOSEFUL COLLBORATION. The purpose is to service its customers better than the competition and that means as an individual by individuals. Hence it is always collaboration! No people, no service, no emotional connection, no loyalty, no business. We are not talking about manufacturing, ok? So not the 'collaborative aspects' are the outlier, but the artificially created processes are. A business never follows a process but it should collaborate to achieve goals, that can be seen as units of work. The completion of a flow diagram does not ensure the achievement of a goal. One can do BPM on a very high level that is far above automation and put into each task box a goal to be achieved. People then collaborate to achieve those goals. It is no longer BPM.
BPM in all its forms is either a kind of application development or dumbing down work to the point that cheap and replaceable staff can do the job. Yes, we will get back into whether this is also true for 'BPM - The Methodology'. BPM needs a methodology because it makes no sense otherwise. Why would a business kill its own capabilities, innovative powers and its workforce with BPM and SixSigma? Only when its management is inept and clueless and listens to consultants who have never run a business themselves.
At my banks, I hardly ever can get the answer to a question or the completion of a request from a single person. They often call 5 people until there is an agreement of what to do. And these things can't be encoded into a process because I am an individual in a special situation and so is everyone else. Dumbing that down makes the service the bank provides easily replacable and not competitive regardless of how cheap and correct it is in its limited ability.
All these things in the above we adress with ACM Adaptive Case Management. Users hardly ever need a process and when they do it is done by IT and it is really a simple application linked into the goal achievement pattern of the case. Users rather need to know which goals they are supposed to achieve in a particular customer service situation. They can call in anyone to collaborate on the goal achievement. THere will be a complete record of who did or recommended what and the whole things can take place online without physial contact, but phone and people contact can be part of it without breaking the process. There is no outlier in ACM. There is no bad process. Every goal achieved is a learning experience and reusable for the business.
Live streams, email, Twitter and Facebook are all 'open collaboration'. There is no underlying business purpose. But it is amazing how much I can achieve by using Whatsapp and the main problem is that I do not have a record of who communicated about what in regards to particular customer and goal. My focus is to create a business ontology that enables the description of goals and rules in a non-ambiguous way for the collaboration. That will increase the quality and not a dumbed down flow diagrams.
Social BPM saw the collaboration happening at process design when that is absolute nonsense. Achieving goals IS THE COLLABORATION and it will replace the silly notion of highly automated and error free processes at some point in time. Maybe I can write a similar post about that in another five years time when all the BPM hacks have retired.
My reply is based on the understanding that
1) Business process is explicitly defined coordination for guiding activity flows. This means that any business process is an agreed plan which may include some variants and may be adapted during its execution.
2) BPM is a process-based management discipline. In other words, a coherent set of rules for the better management (of the enterprise functioning in support of the enterprise goals) via business processes.
Coordination may be weak (crowd) or strong (army), imperative (working instruction) or declarative (a set of constrains), explicit (as state laws or directives) or implicit (tacit, social), etc. Collaboration is a form of coordination and various forms of coordination are supported by various coordination techniques (see ref1).
Thus the Best Way to Manage the Collaborative Aspects of a Process is to provide a coherent set of various coordination techniques in the same environment (i.e. a BPM-suite tool).