Decoupling Value Chain Participation

The last two posts have been about whether or not it's a good idea to decouple innovation (or adoption of innovation) from its application. Adventis published an article that advocated decoupling innovation from futures management -- the latter better handled by "systems" than by the innovators themselves. McKinsey published an article on IT leadership saying that management-by-system doesn't work when it comes to deciding which path of innovation adoption IT itself should follow.

This discussion is really about drawing the line across the value chain and saying how much chain you should take responsibility for. Too much and your costs are too high; too little and you don't add enough value. I closed yesterday by saying that knowing where to draw that line might be part of being a leader -- whether you assess adoption risk on the supply side of technology or the demand side.

Another take on this issue is provided by Innosight, one of whose consultants (Scott Anthony) co-wrote an article with Clayton Christensen and Chris Musso titled "Maximizing the Returns on Research." It basically says that whre you draw the line (the "decoupling point") is where the incremental value add of chain integration is less than the incremental value add of further chain participation (my paraphrase). At some point, as technology matures, tieing together the various stages of value creation has less worth than the value actually produced at those stages. The sweet spot is knowing when that's about to happen. The article gives four key indicators of when that might be for you.

You can actually adopt this model to either the problem discussed by Adventis or McKinsey. It's all about knowing the risk/reward of sticking your neck out a little bit more -- and sometimes more is actually less risky. You don't automatically do something because you know how (the Adventis arguement). Neither should you automatically not do something just because it doesn't fit standard operating procedure (the McKinsey argument). But what's really useful is knowing that there might be a sweet spot in between and even where it might be.