Supply Chain Shaman

Lora's Latest Post

Trust, But Verify

When I joined the world of software as a business analyst from manufacturing, I was naive. How so? I never fathomed the amount of money that commissioned software sales personnel make selling software. This high level of compensation drives extreme behavior.
In the selection of software, where the rubber meets the road, the sale of software often becomes a brutal and competitive battle. With a heightened focus on winning the deal, sales teams push decision groups into emotional and political arguments. It is deliberate. As the battles become intense, the facts and intellectual discussions get pushed to the sidelines. It becomes all emotion. To sidestep the hype, I would argue that the teams need adopt Ronald Reagan’s slogan, “Trust, but Verify.”
A software supply chain planning project needs careful selection based on the fit of the engine and the data model. Unfortunately, for many companies selecting software, this is difficult. Why? Most technology vendor presentations sound alike and the business teams cannot determine the important differences from a demo. I frequently get calls from companies involved in a year’s process of software selection and they cannot make a decision. They will call and ask me, “Which vendor should I chose?” I never make the decision. Instead, I facilitate a discovery process. My recommendation? Ask the software company to demonstrate the proof.
My recommendation is for teams to ask the technologist to participate in a proof of concept to verify the solution. Unfortunately, few do this type of testing. The lack of this testing is one of the reasons why software satisfaction is so low.  There is a nominal fee, and a requirement of time and energy, to do the testing, but it makes a difference. In Figure 1, we outline some of the satisfaction rates with demand planning and S&OP software. The effectiveness of supply planning and production planning software is even lower than S&OP and Demand Planning. The highest satisfaction rate for business users is in the area of warehouse management. In essence, when it comes to planning, success is a flip of a coin. This is sad but true.
Figure 1. Satisfaction with Sales and Operations Planning and Demand Management Processes

How To Verify:

To understand and drive outcomes, test the software through a series of “Bake Offs.” Invite your most promising technology providers to participate and test the software for your use cases. Carefully provide requirements, and ensure that the team is clear, and in alignment, on the success criteria.

  • Forecasting/Demand Planning. To verify the “fit of the forecasting engines,” take four years of data and give the technology provider the prior years data. In this case supply 2012-2016 monthly (or weekly) shipment and order data and ask the technology company to forecast sales for 2017 (keep the 2017 data in confidence). Divide the data into demand flows–new product launch, trade promotions, line extensions, seasonal builds–and communicate these characteristics to the technology provider. Communicate the like demand streams, year-over-year, to the technology provider, but do not share the 2017 data. Then ask the technology provider to load their engines and deliver what they believe is the forecast for 2017. Then calculate the error and bias on each of the demand streams. Pay close attention to the items in the long tail.
  • Production Planning. Take a year of orders and share them with the technology provider. Give the technologist the characteristics of changeovers, constraints and cycle planning, and ask them to provide you with a sample production plan. Pay close attention to the details of the schedule plan and understand what drives schedule attainment. Evaluate the impact of the production schedule output to cycle stock, and make a comparison to the cycle stock requirements of your company’s prior year.
  • Transportation Planning. Take a year of orders, along with your route assignments and pooling specifications. Ask the transportation provider to provide you a set of sample plans. Look for capabilities for load assignments, pooling, continuous moves and backhaul definitions. Compare the impact on cost.

My Recommendations:

In my twenty years of following this market, I have five recommendations:

  • Triangulate the Market. Technology companies usually supply positive references. To get the best results, go around the technology sales person’s glide path, and try to find references on the entire spectrum–the good, the bad and the neutral. You can learn from all three. I know of no software implementation where there are only positive references. The question is “What is the best fit.”
  • 80% Is Never Enough. Many times software sales teams want to gloss over the details of optimization, stating that 80% is enough. Many times this is the rationale of an IT group pushing IT Standardization. To drive business results, data model fit and engine design are more important than integration. In the implementation of supply chain planning, integration is the easy part. Business process optimization is the more difficult and critical element. Test and verify that you have a technology that can do the job.
  • Industry Specificity. Look for deployments in like industries. While strategic network design technologies are more widely deployed across the industries, the more operational technologies like demand sensing, production planning, deployment, transportation planning and material planning are very industry-specific. Do not try to cross the lines: apply a solution outside of your industry.
  • They Don’t Have It Now, but the Vendor Will Build the Solution. Often if the capabilities are not in the software, there will be a claim that the vendor will build it. We find that the building of new software will take 9 to16 months and companies are seldom satisfied with the build. In my twenty years as an analyst, I only have two cases where this type of co-development was successful. Avoid one-off software efforts.
  • Avoid a System Integrator’s Recommendation. System integrators usually get a commission on the sale of the software. They are usually not a neutral party. Ask your system integrator for details on their arrangement with the software provider. Buyer beware!

For additional reading on this topic, check out my blog post on Forbes this week. I look forward to getting your feedback.

Search the Archives
Share this Post
Featured Image
Recent Posts