Does Social Media play a role in BPM? Can you integrate Social Media in the development and maintenance of business processes? These are questions I have been thinking about. It goes without saying that social media has changed the way people communicate. It has also changed how we get news, some information and the way consumers interact with the enterprise.
However social media (SM), from where I am standing; does not appear to have changed much within an enterprise. I am sure if you work for a social media company you would vehemently disagree with that statement. However the companies I have worked with, generally use SM for outward facing communication, not always internal communication. Some internal areas where I have seen it used is by IT to inform user groups of system status changes, and by executives for quick, internal staff messages. I generally see a preference for F2F (physical or virtual) meetings, enterprise intranet portals and email for internal communication. So the question to explore is, could SM be useful in BPM?
Caveat: I do not have direct experience in applying SM to BPM so the following thoughts are untested. However if I was asked to integrate the two, the following avenues are the ones I would approach first to learn from and then adapt based on the outcome.
1) BP Design
BP design is the heart of BPM. I do not see how SM could enhance the real-time interactive nature of the design process. Video conferencing was an enabling technology for having a broader audience present during the design phase. This resulted in better designs, socialized over a wider enterprise audience, hopefully making acceptance and adoption of the process easier.
Although I do not think SM can help during the initial design of the process, I do believe it can play a role in vetting the design outcome. Using SM for individuals to provide feedback and comments to the BPM team can help ensure that everyone in the group can see and monitor comments in timely manner. Participants also have an easy mechanism to publish their views and thoughts to the group. The BPM team benefits by having all of the feedback in a single, easy to access application. More pedantic uses of SM could be to notify interested parties when the latest version of the BP is available for review, etc. So as a communication tool, I see certain benefits of SM over say email, where not everyone may have access to comments because they were not included in a response thread.
2) BP Improvement
Once the BP has been finalized and changes to the system(s) made, it is adopted and used by people. After these people use the process, they may see improvements that could be made to increase process effectiveness or efficiency. Who do they tell? Where do they go to make the suggestion? I see SM playing a role here. I also see this usage as having the most potential for controversy.
The people who use the process are not always aware of why it was designed in a particular manner. Lacking that information, to them what seems inefficient could actually be a critical step that provides benefits in subsequent activities. Without complete information, the users may find it difficult to make suggestions to a BPM community. This is especially true if the users have experienced harsh criticism from the community in the past, or felt the idea was ignored due to lack of feedback.
This is where a mature SM culture should exist in the organization before taking this step. Criticism, right or wrong, is always going to happen. It is in the way that criticism is delivered that makes it palatable for most people. If the SM culture is one of an open and honest exchange of ideas, then this should work. People who use the process everyday should have good insights for potential improvement. So being able to capture those suggestions for evaluation should result in better processes.
The other end of this conversation is around user expectations. The length of time between when an idea for change is put forward and when it is delivered in the system can be long. Changes to a system, once productive, are generally slower than when the system is being implemented. The expectations of the people making the suggestions will need to be managed under these circumstances. The volume of suggestions may also dramatically increase putting more pressure on the BPM team to turn around their evaluation of the proposed changes. All of these should be thought about before opening up the SM floodgates. (Almost sounds like the BPM team may need to define a BP for this type of activity 🙂 )
3) End User Training
The last area that could benefit from this is not a BPM responsibility, however they do share a consultative role here. By harvesting and analyzing process feedback, a need for training may be identified. If people using a process make requests for changes due to a misunderstanding, it could point to the need for additional training. Although it would not be the responsibility of the BPM Team to deliver this, they could be used to identify specific areas where increased training or change communication is needed. The appropriate group could then take action to resolve the issue.
So overall I do not see a revolutionary role for SM in BPM. SM may be able to increase the speed of BP development, improve stakeholder communication and provide insight into how the enterprise is adopting new processes. The enterprise should also have experience in, and established some level of cultural norms for using SM, before applying it to BPM. In my opinion, BPM should not be the leading wave for enterprise SM adoption.