Most of the discussions around social BPM have been relatively academic. We've debated definitions, plausibility, and trends. Here is a view from the trenches.
One of the early definitions of social BPM had BPM projects using social and collaborative platforms as a mechanism for real time feedback. That feedback would be gathered during process design, prototyping and deployment. It was felt that the near real time feedback loop combined with the ability to collect information from a broad spectrum of participants would help accelerate the creation of a more precise application system.
This view was put to a test recently in a "lead to cash" project that used wikis, email, IM and social platforms as the feedback mechanism. The process involved multiple departments such as marketing, sales, finance, operations and product. The process included several subsystems such as CRM, finance, internal product management and billing. The implementation of social BPM was fairly close to the definition above, not because of the definition but because of the way the team wanted to manage the project. It was quickly apparent that the project did not anticipate two specific consequences of this approach:
1) Cadence: The project utilized Agile and SCRUM with two week sprints. But, the feedback came in much faster than two week intervals. At times the speed of the input was out of synch with the speed of the updates, which was quick compared to other methods. The team felt that two week sprints were very quick but minute by minute feedback piled up quickly. This put a premium on managing the backlog.
2) Governance: Each departmental view felt that they should own the entire process. Tactical changes to fit each and every individual's preferences were not consistent. The inside sales team claimed that they were first in the process and spent the most time staring at the screen. Their requirements should be first. Finance responded by saying that they required critical information that the other teams were not aware of and didn't care about, like credit rating. This put a premium on governance and adjudication putting a lot of pressure on the Product Owner. That is not unlike any other SCRUM or BPM project but the social aspect magnified the problem - more user input in a more public forum.
In this instance of social BPM the group had to adjust rapidly to facilitate the use of social in the BPM project. Very few of the issues that cropped up were technical in nature, if any. Did the exercise result in a better system that was deployed more rapidly? Hard to say as there was no control group for this type of an exercise. Did it result in greater adoption by the application user population? Possibly, due to the fact that all of the participants felt that their input was heard and evaluated even if it was not implemented.
Do you have experience with social BPM type projects? Did you encounter these issues? Was your result a success?
Next episode - the view from the social side and putting social to work.