The reasons for this are twofold:<\/p>\n\n\n
- \n
- In some companies, there is greater pressure to play it safe than there is encouragement to take chances, so project team members err on the side of self-preservation.<\/li>\n
- Distinguishing between perceived risk and real risk is far more difficult than most project teams understand, so project teams tend to lump both perceived risk and proven risk into their judgement criteria.<\/li>\n<\/ol>\n\n\n
If those two factors are in play, the boundaries a project team will likely apply to the field of available market choices for a new project will not only be based on arbitrary risk perceptions, but also be over reaching in ways that not only reduce the company\u2019s chances for a positive outcome, but ultimately, increase the risk of project failure.<\/p>\n\n\n\n
Seems counter productive, doesn’t it? It is, but the logic behind risk averse behavior is sound. Why wouldn’t you want to protect your company (and yourself) from less-than-completely-safe decisions? <\/p>\n\n\n\n
The problem is that defining “safe” is difficult. And, as a result, we’ve watched a number of very smart people make some not so choices for their company. <\/p>\n\n\n\n
One real world example comes from a market leading company that had committed to automating its distribution centers. A few years earlier, we had been in the final round of their provider selection process for their first distribution center overhaul, but ultimately lost to what they deemed to be a “safer choice.” <\/p>\n\n\n\n
Cut to three years later. The company’s first automated distribution center had been completed and had been plagued by performance and support issues ever since. It seems there was a dodgeball approach to support coming from the software and hardware providers that had been brought in on the project, leaving the customer unable to ever really determine the cause of their issues. <\/p>\n\n\n\n
So when it came time to open a bidding process for a new distribution center, this new project team was understandably more guarded, distrustful, and risk averse than the first time. The project team did not want to find itself in the same position as it had with the last distribution center, so it decided strong action was required.<\/p>\n\n\n\n
Having had issues with finger pointing providers in the last project build, the project team decided to limit bidding on the new distribution center to providers that could supply both equipment systems and software under the same brand.<\/p>\n\n\n\n
To the risk averse project team, the solution seemed like a safe and logical choice. But was it?<\/p>\n\n\n\n
It would definitely protect them from the finger pointing between providers they experienced on the last project, but they could have accomplished that by just eliminating the offending providers.<\/p>\n\n\n\n
And in assuming that all independent providers would engage in the same behavior as those involved in the previous build, they not only eliminated a large swath of key providers, but also excluded seasoned integrators that would have provided a single source of accountability<\/a>.<\/p>\n\n\n\n
But what\u2019s worse, the exclusion did nothing to protect the company from any number of reasons why a manufacturer might deliver an underperforming system. <\/p>\n\n\n\n
The project team’s actions were driven by risk averse behavior based on perceived risk, not documented risk.<\/p>\n\n\n\n
In believing that independent providers posed more of a risk to system performance than original equipment manufacturers with their own warehouse software brand, they dramatically reduced the options, opportunities, and outcomes they might have otherwise realized for their new distribution center in critical areas that would dramatically affect potential outcomes in the areas of:<\/p>\n\n\n
- \n
- Data science<\/li>\n
- System design<\/li>\n
- Equipment technology<\/li>\n
- Emerging technology<\/li>\n
- Systems software<\/li>\n
- Systems support<\/li>\n<\/ul>\n\n\n
And in the end, the project team ironically exposed the company to a greater degree of risk for its new project than it likely faced for its previous one. <\/p>\n\n\n\n
Ultimately, the second distribution center became nearly as problematic as the first. A number of years later, both facilities are still struggling to achieve the results that were originally promised.<\/p>\n\n\n\n
![\"\"](\"https:\/\/mll9sbjiwkq3.i.optimole.com\/w:1024\/h:526\/q:mauto\/ig:avif\/f:best\/https:\/\/msi-automate.com\/wp-content\/uploads\/2022\/04\/Risk-Averse-1.jpg\")
<\/figure>\n\n\n\nDue Diligence Instead of Risk Aversion<\/h2>\n\n\n\n
A far better solution for this project team would have been to better understand the critical correlation between chosen providers and expected outcomes. <\/p>\n\n\n\n
Had they learned from their past experiences that the odds of realizing an expected outcome rise and fall depending upon the provider you choose, they might have put a more concentrated effort toward performing greater due diligence on both potential providers and their proposed solutions.<\/p>\n\n\n\n
Certainly, every provider will likely present well, but there are ways to perform a level of due diligence that will yield greater insights into potential outcomes. Here are a few:<\/p>\n\n\n\n
Step 1: Begin with Process<\/h2>\n\n\n\n
To understand what kind of outcome you can expect from a provider, it’s important to understand the foundational process behind their design concepts. <\/p>\n\n\n\n
Since any system design should begin with an in-depth understanding of the underlying relationships hidden within your company\u2019s operation data<\/a>, the provider\u2019s analysis of that data is the place to start. <\/p>\n\n\n\n
Read their white papers<\/a> and blogs<\/a> to understand their process. Read between the lines. Then, ask questions.<\/p>\n\n\n\n
Really understanding the answers to key questions will give you the insights you need to properly evaluate their process. <\/p>\n\n\n\n
Here’s a list of the kinds of questions separated by category that your team should expect clear, documented answers to from any potential provider:<\/p>\n\n\n
Data Preparation<\/em><\/span><\/strong><\/p>\n
- \n
- \n
- \n
- What process does the provider use to clean and analyze the data that holds the secrets to the solution that will work best for your unique business?<\/li>\n
- How do they prepare your data? <\/li>\n
- Do they perform data synthesis<\/a> to create future state data<\/a>? And if so, what and how many assumptions get factored into the process?<\/li>\n
- What automation tools do they use for their data science process? <\/li>\n
- Do they use machine learning to capture underlying relationships?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
System Design<\/em><\/strong><\/span><\/p>\n
- \n
- \n
- \n
- What kind of assumptions do they use in developing a design?<\/li>\n
- Do they use computer simulation modeling<\/a> to test their assumptions, develop their inventory strategy, and develop and refine the algorithms to be used in the software that runs the system?<\/li>\n
- How do they insure the robustness of their algorithms?<\/li>\n
- Do they use iterative computer simulation modeling to test system software and refine system algorithms and designs?<\/li>\n
- Do they know the break points for the system you are being offered and how did they determine them? Will they share that information with your team?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
Equipment Evaluation<\/strong><\/em><\/span><\/p>\n
- \n
- \n
- \n
- How do they determine the technology stack<\/a> proposed for the design?<\/li>\n
- Can they provide the value each piece brings to the overall system and show the financial justification for its inclusion?<\/li>\n
- How does the provider ensure a new technology will seamlessly integrate into your operation?<\/li>\n
- Does the provider emulate its proposed equipment technology<\/a> in order to test the ability of its software to optimize system performance under real-world conditions versus just assuming equipment rates will be constant in all production conditions?<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n
Step 2: Understand Your Provider’s Offerings<\/h2>\n\n\n\n
A good provider will provide the data you need to make the right decision. In doing so, it will explain not just its proposed solution, but the iterative steps it used to arrive at its conclusions.<\/p>\n\n\n\n
It will also provide you with the data points that justify its reasoning and allow your team to examine the data in order to reach its own conclusions.<\/p>\n\n\n\n
In examining the data, understand the offerings, the origins of the products, and the responsibility the provider is offering in integrating your operation. Will there be one point of accountability and support? Or will you be left to manage many contractors?<\/p>\n\n\n\n
Most importantly, understand the software that will run the system for that is where performance is derived. A good provider will walk you through the design iterations and explain the algorithms it plans to use to solve your unique challenges. <\/p>\n\n\n\n
And it will enable you to tour facilities and speak with current customers.<\/p>\n\n\n\n
Step 3: Realize the Outcome You Seek<\/h2>\n\n\n\n
Risk aversion can translate to the systematic elimination of opportunities to such a degree that your company can end up with a fulfillment system that may enhance internal efficiencies and even lower the cost-of-goods sold, but never realize the full potential of the strategic benefits automation can bring<\/a>.<\/p>\n\n\n\n
Safe bets generally don\u2019t get people fired, but they can erode the strategic advantages companies might otherwise get from the investment they make in warehouse automation endeavors. <\/p>\n\n\n\n
If risk averse teams in your company can channel their anxiety into due diligence, they can actually realize systems that can change your company\u2019s growth prospects. They can deliver leaner systems with:<\/p>\n\n\n
- \n
- Smaller infrastructure<\/li>\n
- Higher equipment utilization<\/li>\n
- Multi-tasking equipment<\/li>\n
- Lower cost-of-goods sold<\/li>\n
- Reduced labor demand<\/li>\n
- Higher service level capabilities<\/li>\n
- Increasing levels of efficiency throughout the life of the system<\/li>\n<\/ul>\n\n\n
Fulfillment and distribution automation can dramatically enhance a company\u2019s competitive market edge.<\/p>\n\n\n\n
If done right, it can bring measurable strategic advantages that go far beyond the obvious improvements of enhanced fulfillment capabilities and reductions in costs-of-goods sold, and enhance a company\u2019s capabilities and growth potential in a variety of areas such as a retailer\u2019s ability to move product, execute marketing initiatives, control profit levels, and increase customer loyalty and retention.<\/p>\n\n\n\n
Your company can realize systems that are scalable and can seamlessly accommodate the shifts in production demand, non-linear growth, order profiles (the mix of lines to orders, units to lines, and SKUs to service) that hamstring traditional systems \u2014 and even accommodate unanticipated growth and business demands, including non-linear growth, divergent merchandising strategies, and changes in business models.<\/p>\n\n\n\n
But only if your project teams choose due diligence over risk aversion.<\/p>\n\n\n\n
As always, if we can be of assistance, we\u2019d be happy to help.<\/p>\n\n\n\n\n
SCHEDULE A FREE CONSULTATION<\/a><\/p>\n
<\/p>\n\n
- How do they determine the technology stack<\/a> proposed for the design?<\/li>\n
- \n