Data Center Businessman

In the past couple years we have seen details emerge on high profile supply chain failures at shoe retailer Finish Line and retail giant Target (Canada), both being blamed on supply chain technology issues that left shelves bare. Both companies suffered staggering losses (relative to revenue) that resulted in the replacement of their Chief Executives. For Q3 2015, Finish Line reported a $21.8 million loss and stated that it expects to close up to one quarter of its 600 stores. The reason: the new WMS it installed in September could not process orders fast enough, starving its stores of inventory and resulting in up to $32 million in lost revenue.

Another article published by Canadian Business Magazine highlights the bizarre and incredible story of the rise and fall of Target Canada. Its ill-fated international expansion attempt cost Minneapolis, MN-based Target Corporation over $7 billion in losses before its Canadian subsidiary declared bankruptcy in January 2015, less than 2 years after its first store opened. The reason: every business system it implemented from ERP to POS to WMS to Store Allocation failed to effectively manage its supply chain and retail operations, leaving its shelves bare and customers frustrated.

Note: This post discusses system implementations at Finish Line and Target Canada as summarized in the following articles. If you would like to read these articles, just follow the links below:
http://www.wsj.com/articles/finish-line-to-close-25-of-stores-swaps-ceo-1452171033
http://www.canadianbusiness.com/the-last-days-of-target-canada/

All of the software solutions implemented by both Finish Line and Target Canada were sound choices for their business – they should have worked. How then could two successful companies have industry standard software solutions fail them? There are many complicated reasons that can be given, but when it’s  all said and done, the answer is simple: people made bad decisions.

From executives driving impossible timelines and drawing nonnegotiable go-live lines in the sand to software analysts disabling critical features to hide poor metrics, these two stories have many common threads with other similar stories of corporate disaster. In the case of Target, several people interviewed said that everyone knew the launch was a disaster in the making, but no one spoke up. The fact that so many people in a business can know the facts and their inevitable outcome, but fail to act, underscores a stark reality: in an environment where functional software is a prerequisite to operational execution, it is critical for the implementation team in a business to see potential failure coming and be self-aware enough to head it off rather than plunge into it blindly.

Business leaders must not only have the vision to lead their teams to achieve the impossible but also have the experience and self-awareness to prevent their teams from succumbing to the unthinkable.

Regardless of the software vendor selected, successful implementation requires certain process steps to be followed. At Accelogix, those basic phases of our implementation methodology are called Discover, Design, Execute, and Deliver, and similar steps are echoed in the formal implementation methodologies of almost every major software implementer. At a high-level methodology is a journey. At a detail level, it becomes a rigorous project plan. There is a science to it.

However, a robust project plan does not indicate success; it merely facilitates it. While software is implemented for the purpose of enforcing a repeatable process, implementation of the same software in two different operations never follows exactly the same process. There is an art to the successful implementation. It is for this reason that simply having a good project plan is not enough. The team must also have the experience and expertise to execute the plan.

Business leaders must not only have the vision to lead their teams to achieve the impossible but also have the experience and self-awareness to prevent their teams from succumbing to the unthinkable.

Bad process design, buggy software development, bad master data, failed integration transactions, poor visibility, and lack of adequate testing are just a few of the issues from which these projects suffered. However, none of those issues in and of themselves was the actual problem. The bigger problem was that in spite of the known issues, all of which were fixable given more time and proper management, both companies went live on systems that were not yet ready to actually run their business.

Who should have spoken up as the voice of reason and tried to stop it? Late last year we had a project that was running behind schedule for various reasons and the system was not ready to meet the planned November go live date. All our experience told us that no amount of go-live extended hours or heavy lifting was going to make the system ready.

We had two choices: speak up and warn our client or try to execute the project plan and cause what we knew would be a major crisis for their supply chain. We chose to raise the red flag and firmly assert that our experience indicated success was not possible on the original schedule. Our client initially pushed back, but we held to our assertion and further proved it out through documentation. The client then saw the same risk we did and we pushed the go-live to February. The February go-live was a great success and the system fully met their business needs. No one liked having to make that call, but driving forward placed too much risk on their business and we could not recommend or support taking that kind of risk.

So how can your company learn from these three examples and improve your probability of implementation success? The answer is that experience matters. Many companies have not implemented packaged supply chain software before. Their internal teams lack the experience needed to guide the project successfully. The software vendor has the resources to do their part of the project but in reality, the software vendor is responsible for only a small subset of the tasks that need to be completed in the overall project. The best way you can improve your chance for success is to honestly assess what you don’t know. Unknown unknowns, the things you don’t know you don’t know are always what kill a project. If your team lacks experience in previous successful implementations of the same solution you are implementing, then it is imperative that you engage experts to help you do the things you don’t know need to be done. And if your experts don’t seem to know any more than you do, find better ones.

Technology is an awesome thing and modern business can get more done with fewer people and higher accuracy than ever before, but the endless quest for efficiency and the high-impact promises of software vendors tend to downplay one incredibly critical reality of the Information Age: while we have reduced the number of people who need to make decisions, we have created a much higher level of dependency on the decisions of the people who remain. Unlike the computers of Sci-Fi lore, no enterprise system on the market today qualifies as anything close to a sentient being. The reality is that enterprise software does exactly what a person tells it to do and nothing more.

Seth Patin

About Seth Patin

Founder and President of Accelogix. Supply Chain Technology Futurist. Father and Husband. (American) Football and car enthusiast.

Learn more about Accelogix Cloud here!