Supply Learner

Just getting started with a few links in my blogroll. I trust the tech and business ones. I'm not yet sure about the Supply Chain ones. Frankly they look too much like old-school brochureware to me and not enough like content. But we'll see. I may be wrong.

Really, I know nothing about Supply Chain Management or its software. But I've always liked this talk from John Seely Brown about the evolving process networks in Asia.

Here are some of the highlights of that talk (for me)

Toyota assesses suppliers on their costs not prices. (Which they are skilled at estimating.) They don't chase the lowest (often misleading) price.

Toyota also accept suggestions from their suppliers.

When a fault occurs at Toyota, any employee can stop the process immedietely to "freeze the context" so it can be analyzed and the fault can be identified and fixed.

Motorcycle manufacture in China is based on a new ecosystem which is organized around a standard design for a motorcycle. Because everyone has this target very explicitly in mind, individual component suppliers can negotiate variation in details between themselves. Presumably as long as the wider expectations aren't violated.

From a software perspective I see an analogy with loosely coupled modules that are hiding their implementational details. As long as each pairwise variation doesn't break the expectations, the system holds up. But reading between the lines, this hasn't been achieved by a very formal specification of interfaces, but by a generally shared knowledge of the final target and (what's essentially) duck typing.

Maybe you can see an analogy between the known design as shared goal and Pierre Lévy's notion of a Circulating Object Link

This ecosystem now makes 50% of all motorcycles in the world.

Taiwanese ODMs do a surprisingly large part of the design work for many global brands. Another example of loose coupling and trusting suppliers to make decisions.

Asia's most succesful garment manufacturer manages a web of thousands of suppliers, and knows how to get them talking to and teaching each other. But never allows itself to become over-dependent on any one.

After giving these illustrations. JSB talks about the role of software and social software. Social software (he suggests) should be wrapped around the supply chain management software to help with the exception handling. That's what time and money is spent on, handling the unusual and unexpected. Informal, personal communication software can smooth those communications. But beyond this, the software ought to be able to freeze the state of the supply chain and associated communication so that it can be analyzed to help explain and fix errors that occur.

Finally JSB offers another paradox. These succesful supply networks are based both on flexibility and trust. You want to learn from your suppliers and customers. But you won't if they're too insecure to tell you things. If your network of connections is based too much on formalized transactions which carry no implied commitment, you can't expect partners to make an investment in ideas which you may then give to their rivals.