Considering the different perspectives and interpretations of the Social BPM term that I came across in these months, I decided that time had come to make some clarification in this domain. I tried to come out with a shared definition and a common understanding on it, but I finally gave up because of the extremely diverse interpretations I found.
Instead, I ended up splitting the domain into several levels of adoption, which in my opinion represent pretty well the current state of the discussion. All the interpretations I found, and also the existing implementations of the approach, fall into one or the other level. I think that having a clear definition of a spectrum of possibilities let people and tools position themselves properly and avoid misunderstandings in thediscussions, hence I consider it a valuable contribution per se.
The continuum of Social BPM adoption I propose is the following:
At the top of the spectrum, Closed BPM denotes the traditional approach supported by state-of-the-practice BPM suites. The schema of the process is decided centrally and deployed to an execution platform (e.g., a BPEL engine or a proprietary runtime). Tasks are defined rigidly, the process actors are preregistered, and allocation of actors to task follows statically defined assignment and escalation rules. The communication among the actors is channeled through the task execution interfaces, with the exception of notifications, which can be delivered through informal channels, like email and SMS.
At the next level Participatory Design opens the process design to multiple actors. Either the stakeholders can actually participate to the definition of the process model or multiple process versions are fused into one shared process model. The latter technique is relevant, for example, after merger and acquisition, when companies have to align different versions of the same process.
Participatory enactment shifts the focus of socialization from design to enactment. Although actors are fixed, as in closed BPM, the communication is not restricted to the input and output of activities but typical functions of social tools are integrated into the process enactment application to support collateral communications, like following up the status of tasks, commenting on the result of task execution, voting on quality of service, etc.
Social enactment entails opening the process execution (at least in part) to actors that are not known at process deployment time and allowing the collective execution of a task. Social task execution can take a variety of forms: from the most structured, like the use of crowd-sourcing platforms for microtasks execution, to less controlled forms, like community-based product and content rating, cooperative software development and testing, etc. The common denominator of social task execution is the capability to launch a task to be executed by an open-ended community of performers and to monitor its progress until completion.
Finally, Process Mining is the less structured approach, where activities are executed freely and the process constraints are recovered a posteriori, by observing the behavior of the actors, e.g., inspecting execution traces.
While the latter is not really social BPM (I would say it’s process discovery), I think that the other levels clarify the possible different understandings that are currently discussed in the BPM community. What do you think of this classification?
Our book chapter on the Social BPM Handbook expands this discussion and presents a model-driven approach to the problem.
To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).
Like this:
Like Loading...
Marco Brambilla 