Monthly Archives: October 2012

Supply Chain Visibility – Impossible Dreams (Part 3)

“Like a lot of technologies, supply-chain visibility didn’t live up to the early hype.  But just like the Internet, where and Webvan failed, we can’t write off the whole concept of supply chain visibility due to some disappointments.”

Last time I wrote about some of the early work in area of supply chain visibility systems and why those systems didn’t match the early hype.  So given the fact that supply-chain visibility systems haven’t evolved into all-seeing, all-knowing, supply chain monitors and controllers, are they worth bothering with?  Sure.  These tools still provide a lot of utility (just not everything that’s been promised over the years):

1)      Source of data for metrics monitoring, and continuous improvements – If you can achieve a certain critical mass of data completeness and accuracy, supply-chain visibility tools provide you with a great data source for measuring key supply chain metrics such as on-time delivery to the customer, and the performance of your supply-chain vendors.  Once you have a measure of where you are now, you can determine root causes of why you’re not achieving your goals, and figure out how to improve.  A lot of companies still rely on their transportation providers to tell them what their on-time performance was.  Those providers will tell you their interpretation of those metrics, but even assuming they are being “honest”, that’s still a very incomplete picture of your supply-chain performance.  Your trucking firm may say an order was delivered on time, but if you can’t match that up to the problem in manufacturing or in your warehouse that prevented you from handing it to the carrier as planned, then you really can’t determine the root causes of your problems or understand your true customer service level.  If you look at companies like IBM and Oracle’s marketing messages on the supply-chain, and “big data” and “smarter planets”, it’s a bit vague what they are talking about, but what comes across to me is the idea that there are new technologies for analyzing mass quantities of data that have, thus far, not provided many useful insights.  So the data gathered by a supply-chain visibility tool is ideal for this “big data” approach—lots of data that’s being under-utilized, and which probably has a lot of stories to tell.

2)      Tools for customer self-service – Customers today have an expectation that they can look up the status of their orders, as if your company was Amazon or Fedex.  Never mind that you don’t have the IT budget that Amazon has, and that Amazon, for the most part, uses only 3 transportation carriers, and you use tens or hundreds.  Or that you don’t own your logistics assets like Fedex does.  Your customers don’t care—Amazon and Fedex are training them to expect this level of service.  What you provide won’t be as complete as what Fedex provides, but the good news is that it’s still possible to impress customers and outdo your competitors here.

3)      Tools for pro-active monitoring of critical supply-chain steps, with human follow-up – While I’m a skeptic of the idea that visibility systems will soon use all-knowing, Artificial Intelligence-like capabilities, and automatically take actions to save your butt, I’ve helped companies to pro-actively utilize visibility system data to monitor critical steps in their supply chains.  And anyway, as I said in my last post, trying to use automation to solve this problem is probably overkill.  Managing exceptions is actually something people are good at.  So automate routine processes and let people manage the exceptions.  They key here is to focus on a couple of error prone points in your supply chain.  Work at getting better, more granular, and more accurate data for these steps into the visibility tool.  Don’t worry too much about other, less issue-prone steps.

Like a lot of technologies, supply-chain visibility didn’t live up to the early hype.  And a lot of money was wasted based on some science fiction notions of what the supply chain systems of the future might look like.  But just like the Internet, where and Webvan failed, we can’t write off the whole concept of supply chain visibility due to some disappointments.  There’s a kernel of value there, and there are still plenty of opportunities to outdo your competitors by improving your supply-chain processes and your service to customers using these systems.


Supply Chain Visibility – Impossible Dreams (Part 2)

“Despite hundreds of millions of dollars invested in supply-chain visibility systems in the 90’s and the 00’s, we’re still far from having systems that can automatically diagnose the state of your supply chain on a given day, and take operational actions to save your butt.”

Last post, I talked a bit about the history of supply chain visibility systems, and about how much of the money invested in creating such systems was flushed down the toilet.  So why are some of these supply chain visibility dreams—the dream of having a system that can somehow foretell your supply-chain future and intelligently and automatically take action, given the occurrence of some supply chain event—so far from being realized?

1)      The systems don’t solve “black swan” supply chain problems – The supply chain issues that cause executives to really lose sleep are the black swans that they haven’t thought of yet, and could never have imagined if they tried.  They aren’t losing sleep about what will happen if one shipment is late, which tends to be the problem that many supply-chain visibility systems are designed to solve.  They are worrying about huge events that could cause serious supply-chain disruptions.  A nuclear accident and tsunami in Japan.  A flood in Thailand.  The only problem is that we all have no clue what the next massively disruptive event will be.  And if fact, as the geniuses on Wall street learned when their models failed to predict the sub-prime melt down, your systems might blind you to the existence of these black swans and make you overconfident of your ability to avoid them, because by definition your systems model the known world, not the unknown events that we have trouble even envisioning.   If you’re most concerned about these colossal supply-chain interruptions, most supply-chain visibility systems aren’t going to be much help.

2)      Inability to model the supply chain sufficiently well – In order to create some kind of supply-chain monitoring system that can actually detect problems and take actions, you need to have a model of your supply chain.  Let’s leave black swan events aside, for the moment.  Even then, our supply chain model needs to be mostly correct, and it needs to then be implemented in a piece of software.  We are far from understanding our supply chains in enough depth to be able to do this.  E.g., if a truck shipment misses a connection with an ocean container vessel, you might want your system to discover this and rebook the shipment on another ocean vessel.  Or even better, you might like the system might be able to expedite the shipment somehow and get it to the port on time for the original vessel sailing.  At least, that was the theory.  Anybody who’s ever been operationally involved in logistics will roll their eyes about the possibility of achieving these things through some automated system.  It’s hard enough to do in the real world, much less automate this through software.  At best, you might get an email telling you that there’s a problem, in most cases hours after the fact.  But if your freight forwarder is any good, they would know about the issue long before you got that email from a supply chain visibility system.

3)      Data – Supply chain visibility is a big B2B integration problem.  You need to gather timely and accurate data from multiple other parties in the supply chain, pull that data into one system, and make some sense out of it.  The technology required to receive and transform this data exists and is getting better every year.  You can do it with your own in-house TMS or ERP system, or with a cloud based supply-chain visibility system, or you can get a 3PL or 4PL to help you.  The problem remains, though, that the data still isn’t as timely and as accurate as it needs to be.  If you look at typical EDI in-transit status messaging from US-based trucking firms, these are sent hours (and in some cases days) after the events that they describe occurred.  People imagine that these messages might have the accuracy of Fedex and UPS package delivery status messages.  Sorry.  Most trucking firms can’t do that.  They may have cab-based systems for tracking trucks, but they aren’t oriented towards providing data to their customers–their purpose is to provide operating data for the carrier.  I’ve implemented in-transit visibility systems in Europe and Asia and the data is much worse there.  Whereas in North America, where in-transit tracking data is merely shitty and late, in Europe and Asia (apart from giants like DHL), you find yourself in a discussion with the carriers that makes you feel like you are inventing in-transit messaging from first principles.  (OK, and now try doing that with a carrier in Japan, when the meetings are held in Japanese, with a translator!)   The technology exists to vastly improve on this–satellite tags, RFID.  And there are pockets of the supply chain where these technologies have been implemented.  But deployment in the “real economy” has been slow.

4)      People are the best “tools” for managing exceptions—Reacting to exceptions is exactly when you want humans involved.  Do you really want a machine to authorize chartering a plane to get a shipment there on time just because your visibility system discovered that the trucking carrier dropped the ball on it?   A good human being is going to be able to think creatively about the problem and take action.  A machine?  Maybe one day.  Machines are great at automating routine tasks.  But humans are still the best exception management tools invented.  So your best bet is to present the information from your supply-chain visibility system to a human being, and let them handle the exceptions, rather than try to automate this.

OK so now that I’ve depressed you about the inability of supply-chain systems to automatically diagnose the state of your supply chain on a given day, and take operational actions to save your butt, next time we’ll talk about some reasonable goals for supply-chain visibility systems and how they can help your business.

Supply Chain Visibility – Impossible Dreams (Part I)

“Often, it’s better to go with simple solutions that require teamwork and individual accountability rather than trying to automate the hell out of something.”

When I was in graduate school I studied with Prof. Dick Conway, who is considered one of the “fathers of scheduling” for his early work on production scheduling.  In one class, we formed small teams and were given the challenge of designing a manufacturing system for an electronic product.  I can’t remember what the product was, exactly, but it was roughly as complex as, say, an office copier.  My team, and most others, envisioned a highly automated production line, run by software that would provide a sort of electronic Kanban system that would send signals down the production line to the various work stations.  This (overly) complex software system was supposed to balance the production steps so that work-in-process inventory could be kept to a minimum.  In retrospect, it was a kind of sci-fi solution that would have never worked well, especially given the sophistication of supply-chain systems at that time (the early 1990’s), and given the amount of processing power you could buy on a typical CPU at the time.  But apart from those limitations, Prof. Conway showed us that the complexity of our solutions was both detrimental, and unnecessary.

It turned out that the best solution was not to use an automated production line at all.  Instead, it was better to use small teams of workers that built a unit, essentially from start to finish, testing the unit after each step in the manufacturing process.  Part of our course of study was to drive around the Northeast in a couple of vans with the Professor, and tour various manufacturing facilities and discuss what we saw.  During one of those trips, sure enough, we visited a factory that was building their products exactly like this—with small teams of workers taking ownership of their work–with good results.  This approach had many benefits vs. the fancy approach that we (the grad students) proposed: assuring that defects were caught promptly and fixed before they started piling up at the next step in the production process, minimizing work in process inventory, and allowing the team to take ownership over the quality of their work and productivity.  Maybe my team’s fancy, automated approach could have worked, but it probably would have failed, and it wasn’t the best approach to solving the problem anyway.  Often, it’s better to go with simple solutions that require teamwork and individual accountability rather than trying to automate the hell out of something.

I’m reminded of this story when people talk about other attempts to apply computers to solve problems that are best solved with less elaborate approaches.  In this case I’m talking about supply-chain systems.  Or at least the idea that supply-chain systems will one day have all seeing, all knowing “visibility” into the supply-chain, and an ability to respond to supply-chain events with automated, intelligent actions.  Maybe these systems will come along one day, but I don’t think that day is close at hand.  Over a decade ago, I was the head of product management at RELY Software, which was a logistics software vendor that was one of the early companies that built a web-based supply-chain visibility solution.  I think the product we built at RELY was ahead of its time—it was a genuine SaaS product built in the early 2000’s, with all customers supported on a single hosted instance of the software (a so-called multi-tenant system).  There were other software startups around with similar ideas and products (Celarix was one that had a lot of funding and that people seem to remember).  There were some companies involved in supply-chain visibility that came at the problem from the ocean transportation side of logistics (e.g., GT Nexus).  And there were some companies that came at the supply-chain visibility problem from the perspective of the railroad business, such as Transentric.  The Enterprise Application Integration (EAI) vendors like WebMethods framed the supply chain visibility problem as a B2B integration problem, and proposed their own solutions based on their strengths (and now that I think about it, to an extent they were correct–more next time).  And most of the Transportation Management System (TMS) vendors, such as GLog (now Oracle TM) and i2 (now JDA), developed modules that could gather logistics events from the supply chain, and show you the status of a shipment.   They could also apply rules to the data they were gathering and alert you if certain conditions occurred, or didn’t occur, just like the system we built at RELY Software could.

If you add up the venture money invested in these (and similar) companies it comes to hundreds of millions of dollars.  Seriously.  It seems strange to say this now, but E-Logistics (as people called it at the time) was once a hot investment area.  I don’t want to say that it all came to nothing, but there sure was a lot of money wasted.  At the time there was an idea that supply-chain visibility systems could somehow foretell the future or be used to intelligently and automatically re-route a shipment, given the occurrence of some supply chain event.  I still hear people say things like this, sometimes, but this possibility remains far in the future.   Why?   I’ll tell you next time.

Tagged ,