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).
Hi Marco,
I believe your classification is one of the best explanation of the different flavors of Social BPM addressing both the design and execution phases and both the way actors are involved (a priori or a posteriori). Thank you very much for putting it together.
One question on the last category: isn't process mining very much what Adaptive Case Management talks about proposing a system that is able to automatically learn, to adapt and to let patterns emerge while users (not just designers but business users as well) simply do their work?
Looking forward to read the book and to meet you in Milan at the Social Business Forum!
Great Classification!
Currently thinking where my current project can be found in there. Probably on the PD Level, and what I'm trying to achieve in the moment can be well described by moving it towards PE. Although, the tools (in a technical sense) are firmly given by the work environment. The tools that need to be introduced/ changed are of the kind of the thinking tools or collaboration habits.
|=
Hello,
thanks MP. I agree with you that most of the impact is not related to the IT tools but to the organizational and attitude issues. IT tools can only support and empower such attitudes.
Thanks Emanuele for your comment, I also look forward to the Social Business Forum in Milan on June 8th.
About the last category, yes, you are right, it's definitely a border-line category with respect to Social BPM. Actually I see it closer to BP discovery (http://en.wikipedia.org/wiki/Business_process_discovery) than ACM, in this sense: given a flow of activities, I interpret Process Mining as the extraction of a structure from the execution. I think (but I'm not an expert on this) that ACM is more oriented to adaptive, flexible and case-based event management, although I see some similarities to this.
Hi Marco –
Great to meet you at the BPM/EA conference in London this past week.
Your framework for describing the continuum of Social BPM is extremely valuable. It gets us past the terminology (Social BPM, Adaptive Case Management, Collaborational Processes [as I've always called it], Knowledge-Intensive Business Processes, etc.) into the actual different flavours along the continuum. Terminology always cause such grief, it's a great contribution to get us past the labels and onto specifics.
I'm not sure about the last category, because Process Mining (often, I believe mistakenly, referred to as Process Discovery) is a technique that can be applied no matter where you are on the spectrum – it's simply looking at the record to determine what actually happened, and thereby deduce scenarios and patterns which are equally useful to Closed BPM, Social Enactment, and all points in between.
Thanks for the framework – I'll be able to use this, but I'll of course give you credit and point people to this post.
Cheers,
Alec
Dear Alec,
it was my pleasure both to meet and hear your great speech there.
I appreciate your comment. I actually found it strange that nobody never tried to put down some chart of the Social BPM space, so I tried to do something like that.
I see your point on Process mining; Maybe the wording I choose for this level is a little bit unfortunate, as actually you are right that Process mining may apply at any other levels of the spectrum.
What I meant here was something a little more radical than traditional process mining, in the sense that the assumption was to start from some sort of dashboard of activities from which people could start and perform their task with no constraints whatsoever, and then the constraints could be mined from scratch. I wanted to represent the maximum level of “unstructuredness” in which the people had the final word on the executions.
Marco,
Excellent classification of characteristics of social BPM! I would argue that even today (i.e. with “Closed BPM”) there is some flavor of Participatory Design. Participation of stakeholders and representatives of end-users is necessary to ensure eventual success of the undertaking. Perhaps it does not happen in a formalized manner and there is limited, if any, tool support for this.
You are perfectly right, there wouldn't be any BPM initiative without some kind of involvement of the user. Actually, this applies to any custom software project.
For the participatory design level, I was thinking to a deeper involvement of the stakeholders, that could become for instance the first editors or co-editors of the process models. This obviously implies either a simplified set of design tools or rather expert users, which is not always the case when dealing with customers. The point of social BPM in this case would be to tackle this gap.