I recently came across a Tompkins Associate’s article entitled Seven Best Practices for Supply Chain Execution Implementations and it got me thinking about my experiences in implementing supply chain software and what has made one customer more successful than another.
I believe it boils down to 6 factors:
- Decision criteria
Most companies have many different supply chain business problems they need to solve to run their supply chain more efficiently. Sometimes picking one to work on is very easy, as the problem is so time consuming and causing so much pain that it is the obvious choice. Therefore, one might assume that just by focusing on one problem that the project scope is limited enough to ensure success. However, my experience has been that even within that one problem there may be many ways to solve it, some easy and some so complex that it would be difficult to maintain and/or would require a significant amount of business process change.
My advice is for customers to walk before they run, try as much as possible to implement the simple, elegant solution rather than the complex solution. Typically, this still provides significant improvement over the customer’s “as is” business process. Once customers find success with the simple solution, then it becomes easier to implement additional functionality as the customer resources are more knowledgeable on the solution and better able to support it.
2. Decision Criteria
Once a customer has decided they have an urgent business problem to solve, the decision to move forward typically comes down to one factor: money. While money is an important gating factor, it should not be the only factor in what gets implemented. Most successful customers have determined that implementing complex supply chain solutions is a journey and not a one-stop trip. Many times, the scope of the customer’s desired solution is too big for their budget, so they scrap the project altogether because the total solution doesn’t fit in their dollar amount. Rather, reduce the scope to fit the budget until customer resources are proficient with the technology and then implement additional functionality over time. In fact, many customers realize they didn’t need all the functionality they initially thought they did.
Every successful project will be supported by a strong Executive Sponsor who can make decisions quickly and remove any roadblocks for success. This sounds like standard boilerplate for successful projects, however if the Executive Sponsor does not instill the concept of “Ownership,” the project still may fail. The Executive Sponsor needs to ensure that everyone at the customer realizes that the solution is not a vendor solution, but rather “their” solution. Everyone needs to feel ownership of the solution and drive that down to the user level, so the users will adopt the new system as a new way of doing business rather than feeling like they are forced to use a new tool.
This is another common factor in the success of projects, but it deserves to be restated. If a customer cannot commit the appropriate level of subject matter expertise (SME’s) to the project, the project will either die during implementation or fail during user adoption. It can be difficult to get time from key resources, which is why it is important to ensure the scope of the initial project matches the time commitment allocated by key SME’s.
Given the complex nature of a company’s supply chain and its ever changing needs, it is important for customers to be flexible when implementing a solution to a business process or processes. As mentioned, a customer decides on the scope of the solution prior to implementing any technology to solve it; however, once a customer begins to design the solution with the technology, they may find the scope should be changed. This can be due to the fact they are more knowledgeable on the technology or that the customer had a change in their business .
Customers should have the courage to go back to their Executive Sponsor and tell them that they may have found a better way to do things than was originally planned. Many times, customers fear the “Change Request” and view it just as a way for whomever is implementing the solution to get more money. Change Requests on these types of projects should be related to the customer determining there might be a better solution. Customers who are flexible often times find themselves with a better solution than was originally planned.
Testing is extremely critical. All use cases of the solution should be defined by the key users and the test plan should be executed by the key users of the solution. This enables those key users to feel ownership of the solution and really understand how the solution will work in production. Too many times I’ve seen customers not thoroughly document all use cases and expect whomever is implementing the solution to execute the test plan, which typically leads to poor user adoption.