By Robert Jones, Sr. Distribution Consultant at Integrated Systems Design – ISD
There are a lot of different technologies out there in terms of automating a distribution environment. These can range from relatively simple and targeted technologies to highly mechanized, multi-million-dollar systems. These systems can be very powerful and provide unrivaled operational performance, but they also can bring an operation to its knees and push a company into very serious trouble operationally and financially. No different than owning a gun; it can save your life, or you can blow your toes off. Failed implementations, serious cost over-runs, compromised operating principles, unattainable return on investment, etc. – these are unfortunately all too typical in the world of automation.
But if these systems have a functional process that’s well defined with technologies that are mature, why would there be such a risk to implement them? Should implementing systems or automated processes be avoided? Of course not! Automation, when properly matched and applied to a SPECIFIC operation correctly, can dramatically change the way a company operates, its ability to service its customer base, and to increase overall corporate net profit – independent of sales or margin contributions – a profit center.
Then why are there so many incidents of failed or inadequate implementations of all manners of automation? The answer is, very simply, the lack of a clear understand of the TRUE requirements of the actual business model, as well as a lack of understanding of limitations of not only the automation itself, but as importantly (if not more so), all supporting processes and functions around it as well.
Unfortunately, the typical method of procuring automation is to consider systems or equipment based on the perception and marketing of what appears to be a good fit, then prove whether those assumptions are true. Many times, the manufacture, or even consulting firms that have their own agenda, are helping to determine and validate those assumptions, the very people that have a vested interest in providing/selling that solution. The “attraction” of the possibilities of the automation’s concept can start to mask the limitations it may have, especially if it the system concept isn’t properly vetted against the true operational realities of one’s specific company and requirements. Even reputable automation manufacture and integration companies will bend operational scope to win a contract, possibly believing system “limitations” can be modified to handle additional operational scope or exceptions
Trade shows are notorious for providing lots of flash, impressive automation, and very generic, but eye opening operational statistics. This is squarely directed at generating interest and dialogue with potential clients, and to give them an opportunity to sell how the system can fit a potential client – once again, the cart before the horse. The problem is that those impressive statistics that are marketed are very broad, usually the best case scenario (which most companies will not approach), and change dramatically based on the operational protocols and realities required by each individual client.
But even if a vendor/consultant does the prerequisite leg work and truly defines an automated solution that makes sense, what are the other things that they are not addressing in the operation? What are those critical processes and systems that are not part of the immediate scope of the automation but will absolutely define the success of the automation?
This is where the wheels start to come off – once live, the automation doesn’t function quite as predicted in terms of the expected results and of the overall FACILITY performance (not just the automation). The manufacture blames the “external” processes and procedures that they cannot control (receiving, put-away, inventory management, replenishment, etc…), along with support systems that they did not install (WMS, WCS, Controls, external conveyors, etc…).. The end client is pushing back, claiming promises of performance made by the vendor and that understanding the facility operation was the responsibility of the implementation team. Band-aids are ushered in, countless hours and cost overruns on services explode along with internal manhours and resources consumed, only to be left with a system that may be truly underperforming based on the original goals.
The fact is that any company looking to automate does not have to become experts at automation, rather just expert at their specific operation, but well beyond just the normal KPI’s and cursory knowledge of basic inventory models and order profiles.
A company must be ready to take truly in depth operational knowledge of the entire operation and be able to functionally apply it to the automation being considered, including WMS and possibly WCS functionality. If done correctly, it will be very clear quickly where the automation is capable and where it may have serious shortcomings, what systems may not support the automation as required, where it makes sense to automate, and where it does not. Sometimes, the automation scope/footprint should be much smaller than anticipated and very rarely does automation, either a single system or multiple layers, serve all purposes in a DC. It is critical to define the requirements the automation will DEMAND of all systems around it, hardware and software, for it to perform as expected – both in terms of processes up and downstream of the actual automation – from receiving to packing and shipping.
In a perfect world, the vendor / manufacture / consultant’s scope is to make sure you understand the automation they are presenting in order that you understand the true design capabilities and intent of the system, not to determine if the automation is right for YOUR specific business. Certainly, you want their “perspective”, but it’s critical to maintain your independence and focus on how the automation will work in YOUR operation. You, as the client, need to apply the actual business model to determine the automation’s viability – relying on someone with a vested interest in providing the automation to determine that viability is a critical error.
In Summary – unless you have the operational acumen and thorough understanding of all facets of your operation and the processing realities and requirements, you are not adequately prepared to make assessments in terms of what any system must deliver, therefor you are not prepared to research, specify, or implement – and certainly not able to understand the financial justifications that these systems require. It is important to note that many of these systems fail not because of actual automation, but due to supporting systems that are connected to the automation; receiving, put-away, packing/shipping, WMS/WCS/TMS software limitations, etc… along with the usual culprits like pipeline system processing limitations (peak days or seasons) space constraints, and system reliability issues.
By not understanding the true operational requirements dictated by the inventory and order models, service level models, automation and external software systems and limitations, volatility in the core business model, true project investment requirements, etc., it puts a company at undue risk for failed or marginalized implementations that can have catastrophic effects to a company (not to mention one’s career).
If you are currently looking at automation, considering moving in that direction, or simply curious of how to go about the process of defining your operation, please feel free to contact me and we can discuss in more detail how to prepare yourself, what information you need to gather, and the types of analysis that need to be performed