Because Failure is not an Option: Steps and strategies to ensure system integration success
Author: Kevin Thompson, Systems in Motion (Guest Contributor)
Performance questions can arise during systems integration projects, we will examine what is considered a failure, along with the steps that MHI member companies take and strategies businesses must do to avoid getting an F on an integration project.
A lot can go wrong in any business, including warehouse automation. That’s the nature of things. However, when it comes to systems integration, MHI member companies strive to ensure that all systems are go. But what if…? While there may be issues to identify and problems to solve, rarely is there a total system failure. However, since performance questions can arise during systems integration projects, we will examine what is considered a failure, along with the steps that MHI member companies take and strategies businesses must do to avoid getting an F on an integration project.
When is it Considered a Failure?
This can be both the easiest and hardest question to answer, because sometimes issues are in the eye of the beholder. Most importantly, while there may be problems or bugs that need attention, that doesn’t mean the whole system is a failure. For integrations expert Kevin Thompson of Systems in Motion, there is one project parameter that determines a project’s outcome.
“One of the things that must be done early on is define what the metrics of success are. What does success look like?” He says these metrics are put together into a Service Level Agreement (SLA) between the customer and the integrator at the beginning of the project. This document clearly states the goals and outcomes the company wants to achieve through integration. If the company doesn’t get what is in the agreement, that is a failure.
Here are a few scenarios (some real, some hypothetical) to show what could be considered a failure, and the reasons these projects failed and their solutions.
1) A customer wanted a system that could move 10,000 items in a 7-hour shift with 15 people, but instead it took 20 people, working an extra hour. That didn’t meet customer goals. However, was that a failure of the system or of the operation? In this scenario, the customer’s goals led to a system designed to move 10 totes a minute. However, the integrator discovered that warehouse staff were running 50 totes a minute and thus clogging up the system, which took extra labor and time to fix. The system was designed according to specifications, but the processes used by the warehouse were incongruent. The solution was operations training.
2) A warehouse wanted to install an automated cardboard carton erector system. This type of system builds a custom cardboard carton designed to fit all the items in a specific order. However, the system sent some items that were too big for the cartons and rejected other items even though they fit because the system “thought” they were too big. In this scenario, it was discovered that the SKU dimensions the customer provided were inaccurate, so the integrator used incorrect sizes and weights in the design. The solution to this issue was to find the company’s Master SKU List with all the specific measurements and weights for each SKU.
3) A customer wants the biggest system available to handle every possible situation the warehouse might encounter, especially peak periods. Since that is what the customer wanted, that’s what the system integrator designed. However, the result was a system that was too complicated and over-engineered for regular operations. Think of it this way: If building a church, do you build it for Easter Sunday crowds? Easter Sunday only happens once a year. Instead, the system should have been designed for day-to-day operations with options for extra protocols that only go into effect when peak level benchmarks are reached.
Teamwork Makes the Integration Work
In each of the above scenarios, failure could have been avoided had both the integrator and customer worked together to achieve service agreement outcomes. One of the things Thompson and other MHI integration specialists do is prep work and research to ensure designs meet customer goals. This cannot be done without participation by the end user company. “Practitioners have to define to the integrators what that success looks like,” notes Thompson.
For their part, systems integrators will meet with owners and operators to learn what they want to get from the integration and will visit the facility to get an overview of what is currently happening and ask questions and request data, so designs are tailored to that specific warehouse. The integrator should never make assumptions about warehouse operations. They should use only real data provided by the company. The integrator will then design the system to fit service agreement parameters and do the appropriate testing to make sure the systems work as designed
The Practitioner (End User) also has a role to play. They need to not only communicate what outcomes they want, they need to be realistic about their current output, staffing, and future goals. They also need to provide all the data the integrator requests in a timely manner so the appropriate system can be designed. And the company needs to make sure all operators, warehouse staff, and IT departments are aware of and informed about what is happening so everyone is on the same page.
Another important aspect to failure prevention is training. Because it would be expensive for integrators to train every staff member in the warehouse, it is up to the operations department to create an in-house training manual and program for training additional staff/shifts or new hires on how the system operates. Although warehouses are dynamic environments, training is an area that cannot be postponed or overlooked to ensure continued system success.
Additional Factors
Thompson says there is a specific area in project design that often gets overlooked – communication around Operational Technology (OT). While Information Technology (IT) departments cooperate with the integrator on the system software, Thompson says all too often the technology on the operational side – hardware like cables, electrical boxes, routers, modems, etc. – gets brushed aside. That can lead to problems such as not having enough electricity to power the new system or not having enough wi-fi bandwidth for different pieces of equipment to talk to each other.
“If I’m going to send the system 15 commands and then the system sends out 30, that’s 45 commands that have to process through one router. Is the router sized right to handle that?” He says a good systems integrator will ask those questions up front to mitigate these issues before implementing the system.
Another issue he has come across is specific to the food service industry – lot discrepancies. That’s because perishable food items have expiration dates which require SKUs of the same item to have different lot locations. If the lot numbers given to the integrator are incorrect – even if the SKUs are correct – the system could pick the wrong item. For example, if there are 500 perishable item SKUs with three different lots assigned to them, that’s 1500 unique locations for those items.
Finally, Success!
Fortunately, even if one process or area has issues, the entire system is not a failure. Complete failures are rare, and any issues or bugs that crop up can be corrected to ensure that the system the customer needed and requested is the one they get.
About the Contributing Author:
Kevin Thompson is the vice president of Systems in Motion.
