Thoughts on a Strategy-Driven Execution of Enterprise 2.0


Following along the lines of my own post and also Mike Gotta’s comment, SAP’s Nenshad Bardoliwalla makes some great points here about placing enterprise social computing in the context of organisational processes, which might already be supported by a transactional system. From this he concludes:

my advice to both the zealots and naysayers of Enterprise 2.0 would be to take an existing, legitimate pain point, like offer creation, or product development, or customer service, and start by benchmarking your current metrics. If an Enterprise 2.0 tool can move those metrics in the right direction in a provable way, you will have real, hard ROI. If the tool doesn’t contribute to moving those process metrics in the way you hoped, then you might have a problem with your executive sponsor.

However, I think this is one approach, but not the only approach.

Moving from theory to actual implementation, we have to be careful about deploying social computing tools in a way that constrains them to a single process. This has implications for users, but might also be affected by assumptions about the systems and actors invol

ved in that process.

I also think for some people that this

approach still won’t be acceptable, as it points to demonstrating value after the fact. We may also still have trouble arguing the causal relationship between social software and improvements to the process in absolute hard undeniable fact (although not impossible, it will require rigour). Considering that challenge from a cost-benefit point of view, this is where the emergent properties of social computing kicks in – like water, provide the tools and let the users work out the optimal level for themselves.

The other thing I think this misses out on is the use of social software in the enterprise to change the transactional process into something that is inherently leaner. I agree with Bardoliwalla on the point that we don’t want to replace transactional systems, but on the other hand we can’t assume that the transactional system reflects the optimal process (either the process mapping has created an inefficient model or a social computing solution would manage some requirements more effectively). In some circumstances the cost and risk of implementing a formal transactional system are so high that some processes are never systematised anyway.

Finally, not every kind of organisational activity is a process. Some of it is loose and messy – decision making, planning, innovation, etc.

Hat tip to my colleagues at Headshift for this one.