Some Lessons from History
I'll never forget the first time I tried to tune an engine. I replaced the spark plugs all right and the points, but when I started the engine up, it ran.. badly. It turns out that I also needed to adjust the "timing," which I hadn't done.
The "timing" refers to the coordination between the sparking of the spark plug and the pistons. When the timing is right, the explosion in the cylinder gives the piston the maximum push. Get the timing wrong, and the explosion may actually slow the engine down.
I think about this, sometimes, when I look at the way a lot of automation applications are actually implemented. Their (metaphorical) timing is wrong, so Instead of saving work, they actually impede people's progress.
In the last two pieces, I've talked about some reasons why this happens. Sometimes, purchases are made without enough information. Other times, the disciplines required to keep the product running properly just haven't been put in place.
But there's another reason, and I think it's the most common. Too often, apparently intelligent people decide to throw a technology at a problem, when it is impossible for that technology to address the problem in the way that is envisioned.
The result, inevitably, is an organizational engine that coughs, chokes, and sputters.
In this piece, I'd like to tell a story about one such decision. It's a decision that I happen to have been intimately involved with, one that involved more than one company, a flawed decision whose flaws were almost invisible at the time, but quite clear now.
Looking back on this decision, I think we can learn something from it.
CFAR
Some eight years ago, I participated in the development of what became the first B2B collaboration standard.
I was a member of a working group consisting of
representatives from Wal*Mart, Warner-Lambert, SAP, Manugistics, and my old
employer. The mission of the working group was to figure out
a solution to a problem that Wal*Mart was finding intractable: store level
stockouts. (A "stockout" occurs when a customer goes to a store looking for
a specific item and discovers that it's not on the shelves.)
Wal*Mart felt (correctly) that it was losing a boodle on stockouts,
and had come (incorrectly) to
the conclusion that the problem couldn't really be
addressed without more cooperation from their
suppliers. So it "convened" the working group. (Actually, it invited all the other participants to sponsor the working group and consented to attend.)
My company assigned me (along with several others) to go to the meetings.
Personally, I was suspicious. I thought
Wal*Mart was one of those companies with their own lexicon, in
which "cooperation with" and "control over" are synonymous and
"win-win" is a contradiction in terms.
But the meetings weren't like that. Wal*Mart was serious. Like some governments,
they had been trying force, found it didn't work,
and now were falling back on negotiation.
The group worked hard and relatively fast. There were some good supply chain minds there,
and
the solution we came up with was elegant.
The supplier and Wal*Mart would share their
forecasts of demand for the product and where there
were substantial differences, they would agree on
the number that both would use. This would improve
forecast accuracy (because the better of two forecasts
would be used) and thus improve deliveries.
We'd use what was then a new technology, called the Internet,
to do the sharing.
Part of what we came up with was a technology standard
for managing the sharing messages over the Internet, but much of it consisted of agreements about the process
for collecting, sharing, judging, and acting on the shared data.
The standard (process and technology) was called CFAR (Collaborative Forecasting
And Replenishment). When it was released,
it was adopted by an inter-industry
standards committee, renamed CPFR, and proclaimed an official
standard.
But...
From the first, there was a lot of questioning
in the industry about this notion of collaboration.
Would companies really trade high-quality information?
Would they act on it? The standard stood or fell
with the idea that both organizations would agree to
be incented by the same measures of forecast accuracy.
Would that really work?
It's been eight years, and the answer seems to be, "No."
Yes, Wal*Mart, again using
quasi-governmental tactics, did proclaim victory and cite
the hundreds of millions of dollars of benefits that accrued. But in
my view they're
using that special Wal*Mart lexicon. Most of the
benefits appear to have come from programs that were
already in place.
Certain it is that there was never the wholesale
adoption that was envisioned by all the participants. Collaboration
is accepted as an ideal, now, in the CPG and retail industires, but it is rare to find a company that does it in
any form whatsoever.
Oh, well, many people have said, it's capitalism, red in tooth and
claw; you can't expect these companies to cooperate.
Wrong. There's a much simpler reason why the technology and
processes didn't work. There was no fit between
what they actually did, and the problem they were designed to solve.
Here's What Happened
A widely accepted
study sponsored by P&G and done at the
University of St Gallen in Switzerland has looked
very carefully at the causes of stockouts.
(You can find the PowerPoint version of the study
results at the GMA (Grocery Manufacturers Association) web site; it's called outofstocks.pdf.)
According to Daniel Corsten, the lead investigator, the primary
causes of stockouts (70-75%) lie in store operations. All upstream
(supplier, warehouse, and store delivery) causes account for
only 25-30% of stockouts. In this 25-30%, one has to include
delivery failures from the warehouse, miscounts or mispicks at the warehouse,
as well as delivery failures by the supplier.
So, let's say that CFAR worked perfectly with all suppliers,
and all other supplier-related causes of delivery failure (e.g., tornados,
hurricanes, strikes) were
eliminated. Only about 10% of the stockouts would be eliminated.
Very subtly, almost without noticing it,
we had decided to throw technology at the wrong thing.
If we had wanted to reduce stockouts--and that's why we were there--
we should have tried to improve store-level operations, such as store ordering
and forecasting. If collaboration HAD to be involved, we should
have insisted that the collaboration work at the
store level, not the warehouse level.
Pretty dumb, huh.
But it wasn't just us. After we made our report,
an industry got together and agreed with us, adopted
the standard, demanded that software vendors create
the technology, etc., etc., etc. Hundreds of millions
of dollars were spent on it, and it became an accepted
way of doing business. Even though, even if it worked
perfectly, the effect of what we did would be entirely
dissipated by stuff that happened farther down the line
80-85% of the time.
Why did all these smart supply chain minds from so many companies make this mistake? Well, it was subtle. To a large extent, I think, we were seduced by the technology and the notion that we were promoting something virtuous, i.e., collaboraiton.
More important, I think, was our desire to be practical. We had this technology, and we wanted to do something with it. But the Internet was new; most companies did not deliver to stores directly; and, in any case, Wal*Mart did not want suppliers to be "restocking the shelves," because Wal*Mart thought that its core competency was merchandising.
So we chose to have the technology do something that it could do. Yes, it's a bit like the guy who looks for the lost key under the street light, because that's where the light is, but we kind of forgot that.
Correcting CPFR
In eight years, mind you, there have been plenty of opportunities for
course correction. Wal*Mart itself is now asking key manufacturers to
collaborate on store level replenishment--not just sharing numbers,
but asking them to pre-pack the store-level shipments when they
put together the Wal*Mart order at the factory. The same inter-industry
committee that proclaimed the CFAR standard has put together a committee
on out-of-stocks whose first meeting is in September.
I talked to one of the members of that committee, and as far as
he's concerned, there's nothing to regret about all this. It took us
eight years to figure out what was wrong, he says, and that's
how it is.
In his view, the idea of technology and collaboration was right; and eventually, the
right version of the technology will eventually
be an integral part of the solution for stockouts.
He is thinking, for instance, about a collaborative out-of-stock finder. One cause of
stockouts, he says, is that inventory records at a store are wrong. So he wants
the store and the manufacturer to share data on inventory and have the manufacturer
collaborate with the retailer on finding the records that are wrong.
Nothing wrong with that. Who knows, maybe it will work. But he, of course,
works for a technology company and wants a technology solution to the problem
of out-of-stocks.
But I wonder whether shareholders would feel the same way. Wouldn't they pretty
irked to find out that the 8 years of time, money, and effort spent on collaboration
hasn't done much so far, but would eventually bear fruit some day?
Isn't the lesson from history something different, that you shouldn't throw a neat technological idea at a problem until you understand the problem well enough to be sure that the technology will sove the problem?
The Win-Win
I think so, but c ertainly, that isn't the lesson that Wal*Mart is taking away. Wal*Mart is already on to the next technological solution, one that
isn't "collaborative," except as defined in that special lexicon.
Wal*Mart now thinks that if you could just drive a little cart down the aisles
and get an accurate shelf-level count of every product on the aisle, you'd solve
roughly 50% of the problem of out-of-stocks. What would allow you to do that?
Well, if you just had a little tag on every item that broadcasts what the item is....
Of course, that, too, is undergoing the same subtle shift. What had been
an idea about individual products and shelf-level counts is being
transmuted into an idea about pallets and cartons that are received at
a warehouse.
Plus ça change, plus c'est la même chose.
Getting the Fit Right
One question remains. How can you be sure that an automation technology will solve the problem you're interested in?
In my experience, it's very difficult indeed. You have to understand exactly how the technology works and exactly how the processes will be affected by the technology. If you don't, once you set it going, your automation engine are likely to cough and choke. It's just like me replacing the spark plugs. I didn't know enough, and so I made things worse.
If there's any lesson to be taken from my experience, it is that very good, smart people make that mistake. They don't have the imagination or time or flair to figure out in advance that the technology won't work. The best they can do is start it up, see that it isn't working as planned, and try to figure out what went wrong.
It's a pretty expensive, risky way of doing things, but these days, that's apparently the best that we can do.
To see other recent Short
Takes, click here for a listing.
|
