Social Computing Case Studies

In the last post I asked a (rhetorical) question about case studies for social computing software. I had a quick look around to answer my own question, and in fact I found quite a few of them. Most case studies are from knowledge-heavy industries/functions, but you can get a decent view on which functions you can get business benefit in:

  • Idea management (collecting ideas on process innovation, product innovation)
  • Idea crowdsourcing (Dell)
  • Customer forums
  • Knowledge sharing / management: Rio Tinto,
  • Collaborative planning, forecasting & replenishment: Aerochain
  • Customer outreach
  • Customer communities - Nike, Avon
  • Understanding customers (social networking analytics)
  • Viral marketing: Quicksilver

An important point is that these tools need to be used in to enrich/enhance/change existing business processes rather than as a standalone technical solution. As Sameer Patel puts it, “… data, and intelligence normally buried in closed process centric activity and systems were pushed into people centric social realms for improvement, only then to be put back into process systems in their newer highly optimized forms.” A brilliant example of how this could work is German Fidor Bank.

Sources: Beyond enthusiasm, CIMA Report on e2.0, Sameer Patel: Why Process Barfs on Social, Rio Tinto videos on Communities of Practice and Denis Howlett’s Glimpse to the Future.

I need to re-learn to write shorter and more frequent posts, so here comes a shorter piece, while I am working on the continuation of my post on Lean.

I spent two years working for a extremely cost-sensitive customer, followed by a year in business development, so I am now rather sensitised to the whole cost/value discussion. Considering I am interested in the practical applications of social computing, I find the ongoing discussion about business value of e2.0 rather interesting and almost personal subject. Today I came across  Aral, Brynjolfsson & Van Alstyne’s paper called Information, Technology and Information Worker Productivity that is interesting by a virtue of being one of the few fact-based contributions to the discussion.

One of the key conclusion of the paper is that “the structure and size of workers’ communication networks are highly correlated with performance.” This seems to be a proof of the ultimate impact of one’s social network on company performance (in hard numbers sense, rather than in woolly e2.0 will make you more in tune with the universe, which must lead to better business value sense).

The only thing that makes me wary is the fact that the research was done using data from a recruitment agency. I  be still careful about generalising this conclusion beyond the knowledge-heavy services industries / functions. We now seem to know how w2.0 fits into a broader enterprise technology landscape and there seems to be case studies from knowledge heavy industries. The question is, do we have any from process-focused and less knowledge-heavy functions?

Apologies for slacking off from blogging, but there has been too many things to do. On the positive side, I had plenty of time to think about, think through and then re-think some of the ideas I started earlier this year. Now getting back to the subject  I started on before I took my writer’s break.

Starting Point
Lean is more of an operations philosophy rather than set of techniques and that’s why it requires looking first at its principles before dwelling on techniques. Let’s start with the principles set by Womack & Jones’ in the book that started it all:

  • Specify value (or know what your customers want & need);
  • Identify the value stream (or understand the sequence of steps leading to delivery of the end result within and without your organisation);
  • Flow (make sure there are no stop-gaps in the process);
  • Pull (reconfigure the process to be driven by customer demand as much as possible);
  • Perfection (which seems to me very similar to continuous improvement).

Process Improvement & Its Costs

A quick search will show that the core of the techniques originating in Lean, that are actually used, focus on process improvement (principles 2,3).  It is hard to argue against process improvement, but the way that it is supposed to be applied to IT as part of Lean poses some interesting challenges.

Identification of the value stream is something popular and achievable even if it is not not exactly easy. Unless your operation is CMMI level 3 or above, your existing process are probably blurry or missing in places. To sort out the holes or blurry patches mean formalising, rationalising and agreeing the end-to-end process:

  • This is possible for repetitive activities, such as live service support. ITIL gives a reasonable reference process framework to start with this. It is not the easiest process but certainly can be done;
  • Solution delivery processes are harder as they fall largely into the Barely Repeatable Processes category. Firstly, projects are rather varied when seen from the viewpoint of an enterprise Process to design a new website is rather different from a process to decide how to upgrade your desktop, which is different from a process to improve your data quality). Secondly, big projects are not repeated that frequently. Considering large projects of each type happen perhaps once every 5 years, what benefit does a detailed process definition gives;
  • Front-end process activities are also hard. For tasks such as identification of potential projects or initial project scoping, lack of detailed process is a benefit rather than drawback as it enables creativity and innovation.

If mapping the value stream is not easy, reconfiguring it for flow is even harder:

  • Firstly, making IT requires more than just agile process (that is the boilerplate answer from Lean proponents in IT). There is a number of other things that you don’t need to care about as a developer, but that are really important from a management perspective, e.g. how capacity management is,  staff cross-training, how much spare staff do you want to pay whilst they aren’t doing anything useful and others;
  • Secondly,  some of the biggest issues IT faces are upstream - facing off to the customer - rather than downstream. Making the upstream process flow hints on business-IT alignment, which is a subject that has been one of the consultants and academics’ favourite for almost 20 years, but still remains a problem.
  • Thirdly, I would claim that as long as the IT organisation provides a good service to its customers (e.g. does not discourage them), it will be facing demand that is much less predictable and homogeneous that that of manufacturers. Under certain conditions, loss of flexibility due to over-optimisation may become a bigger issue than the perceived waste in the process.

Questioning the Benefit

Let’s now move to benefit side of the equation, starting with Womack & Jones explanation of the implications of the Flow principle:

when we start thinking about ways to line up all of the essential steps needed to get the job done into a steady, continuous, flow with no wasted motions, no interuptions, no batches and no queues, it changes everything: how we work together, the kind of tools we devise to help with our work, the organisations we create to facilitate the flow, the kinds of carreers we pursue, the nature of business firms (including non profit service providers) and their linkages to each other and society.

From the quote it is clear that the expected business benefit of Lean comes from eliminating waste. The problem is that waste in IT is much harder to identify and quantify, especially when compared to manufacturing which has a pretty large, single and visible source of waste called inventory. The people who interpreted Lean into IT  domain will tell you that IT process waste consists of unfinished, unneeded functionality, processes, multi-tasking, delays and handoffs etc. The issue with this list is that is rather long, full of small and often hard to quantify inefficiencies, rather than a large, single and visible one, which makes reducing IT process waste harder and its payoff smaller.

Considering the level of disruption when adopting Lean, lack of a single large category of benefit greatly erodes the benefit case and the support you can expect from the CIO or the board for an enterprise scope implementation.

In Summary

The implementation challenges combined with difficulty of developing a robust enterprise-wide benefits case, means Lean is not as groundbreaking as some of its advocate think. It still makes useful operational improvement approach that can deliver a reasonable business benefit. When take and go with it, it is important to consider the type of operation you want to apply it to and start where the cost/benefit ratio is the best. If you have a good relationship with business,  it may be worth addressing  your business architecture and portfolio management as  enablers of a wider application of Lean in IT delivery.

There are few more implications that I won’t go into here as I’m running out of space & time, so you can look forward for one more post on the subject.

« Prev - Next »