Supply Chain News: Readers Respond - Finish Line's Distribution Disaster

Last Week's Column Generated Many Comments and Much Discussion; Here are Some Highlights

Well, it's been quite a week. Last Thursday I published a column on the major troubles athletic shoe and apparel retailer Finish Line had starting last September with a "go live" of a new Warehouse Management System (WMS) and Distributed Order Management (DOM) system that ultimately led to a loss of $32 million in revenue that quarter.

We know that because Finish Line called out the supply chain software problems at the very start of its earnings release for the quarter in early January - very unusual - as the primary cause of its disappointing sales and profit numbers. The CEO resigned in parallel with the news, and the chief supply chain officer - among we suspect others - was let go a few weeks later.

Gilmore Says.... Hume noted that by launching both DOM/WMS at once a company has to solve the order orchestration issues at the same time IT may need re-direct volume to the other fulfillment points due to WMS issues. What do you say? Click here to send us your comments

I went through all this in some detail, including some insider perspective on how the blame should be apportioned across Finish Line, the consultant and the software provider, and some lessons all of us might take away from the turmoil. You can find that column here: Lessons from Finish Line's Distribution Disaster

Well, I received a large number of phone calls and emails this week as a result of this piece. A number of readers from the retail sector emailed to simply say "thanks for shedding some light on this." Several consultancies said the piece had provoked intense interest and debate within their firms. Heard from a few others I hadn't communicated with in years but sent quick notes on the column.

Enough so that as I love to do, I am going to write the whole column this week based on highlights of this feedback. It's great when we get enough response on a topic to do this, which frankly isn't all that often, even though SCDigest clearly receives more feedback than any publication in the space. It's fun and easy for week me, and I have been told readers really enjoy these ‘"Readers Respond" columns too.

So here's an interesting way to start this off: a consultant on the Finish Line project posted some addition details on what actually happened. These comments were sent anonymously, and I have no way to validate their integrity, but I think you will agree they have the air of authenticity.

"I have been on the project as independent consultant for a number of months. I saw this coming long back in 2013," our anonymous source wrote. "Go live was pushed four times and delayed for over 1.5 years. The basic problem is that associates are too protective and so concerned about job security that they wouldn't even give access to the system to help them to run efficiently."

He or she continued: "The system was basically controlled by set of people who have no idea about the WMS and DOM they are implementing, and consultants were very frustrated working with them and obviously no one could stick for more than 4-5 months."

Now there is a lot we could say about these comments (consistent with the other insider observations we received initially from two people I spoke with that put much of the blame at Finish Line's feet). But most important to me is how they relate to what I wrote in last week's column: "The most important collective failure was simply this: the decision was made to turn the system on, and ramp up to full scale, when obviously the people, process and technology were not ready to do so, as is conclusively demonstrated by the results."

From our new insider though, we learn go-lives had been postponed four times previously. So it seems likely to me the pressure to finally go live after those previous delays simply pushed some people to pull the switch even though they might have known the system and the people still weren't ready. You know in your heart that's the case, but you hope for a miracle - or at least only a modest disaster because it seems worse than asking for another delay.

Finish Line got a major disaster instead. If that reader - or any other insider - wants to contact me to discuss other details on what happened in complete confidence, please send me an email here.

To some extent echoing the view of our good friend Mark Fralick of GetUSROI, whom as I quoted last week believes it is a big mistake to think of testing as a distinct phase of a WMS project, consultant David Schneider emailed us, commenting that "Testing is not an event, it is a continuous part of the process. Test often. You can't test too often. Test every day, perhaps every hour. You didn't do a test in the past day? Shame on you."

Schneider added that "Training is also not an event, it is a way of life. Train every day. Train so they can do it in their sleep. Train to where they can do it in their sleep and with their eyes closed. Don't. Stop. Training."

In a great email, Brent Ruth of Caterpillar wrote that "I personally have been involved in many WMS implementations and the key factors have been:

1. Always #1 is the business engagement. They must be fully committed (ham and eggs analogy) and not "wake me up when it's over."

2. Having internal center of excellence (COE) expertise that can translate the business requirements into "consultant speak."

3. Having internal COE expertise that understand the capabilities of the new system and can translate that back to the impacted business to drive point #1."

He adds that not having #1 means easily tripling the costs and doubling the time - "heads will roll." Not having #2 means wasting resources (time and money) and not getting full value out of the transformation. Not having #3 means "you are in real danger of not capitalizing on the full capabilities and efficiencies of the new system jeopardizing ROI."

Well said.

Kevin Hume, a consultant at Tompkins International, had some very interesting thoughts on implementing WMS and DOM together.

"DOM or WMS should always be independent of the other go live," Hume observed. "Typical best practice is to work through the stabilization of order orchestration [DOM] before you bring up a new facility/WMS."

He noted that by launching both DOM/WMS at once [which seems to have been the case at Finish Line] a company has to solve the order orchestration issues at the same time it may need re-direct volume to the other fulfillment points due to WMS issues.

"As a best practice, we typically plan to bring DOM on-line first because it enables a reliable mechanism to re-route orders in the event we do have WMS issue at the new facility," Hume added. "I don't have any details but it sure sounds like they were dealing with concurrent DOM/WMS issues. I don't want to even imagine dealing with that kind of situation."

He further said there are times when it may make sense to bring up the WMS first - but almost never WMS and DOM concurrently.

Mike Challman of CLX Logistics noted that "One aspect of the disaster that isn't mentioned is the apparent lack of a contingency plan for quickly and safely returning to "prior state" when it became evident that the new WMS was failing."

While as he observed in his email that this can be a difficult thing to pull off, and I will add will increase the cost of the project to have this back-up capability, "when the go-live plan hinges on "failure is not an option" it can force the project team to continue pressing a bad position. Better to have a plan for bailing out (even if doing so still creates a bit of a disruption) and then getting reset."

There were many more feedbacks but I am out of space. I may do another such column in a few weeks on this, featuring some other reader comments, especially if we get a few more observations out of this piece.

So send in your thoughts on this interesting story. And again I would be happy to confidentially discuss it with you if you have more insight about what actually transpired at Finish Line.

Any more perspective on on the Finish Line distribution disaster? What lessons or takeaways relative to WMS and beyond do you see, or reaction to these reader comments? Let us know your thoughts at the Feedback section below.

Your Comments/Feedback