*Interview edited for length and clarity. (See the full interview at Automation Unpacked: Lessons from Deploying $500M in Supply Chain Automation w/ Nick Leonard)
It’s amazing what people can accomplish during their careers. That can be even more impressive in the tech space, where advancements in robotics and automation, as an example, are happening rapidly. And that can mean a lot of vital knowledge gleaned along the way by those immersed in it over a significant period of time.
It’s why we wanted to sit down with Nick Leonard,* SVP of Product for SVT robotics. As supply chain automation becomes more and more critical, Nick’s extensive industry experience is invaluable for both those just starting their automation journeys and those who’ve already deployed solutions but want to get the most out of their technologies. Nick has deployed upwards of $500 million in automation solutions for supply chain operators, so he might know a thing or two.
How did you get into this industry?
My college degree was in Information Science degree, which is kind of like a computer science and business management combo, and I wanted a role where I could apply software to real-world problem statements. I ended up getting a job in a large-scale logistics company as a junior IT project manager, which started my journey towards how we can apply software controls to supply chain automation.
What types of problems did customers ask you to help solve?
One primary challenge that we still don’t talk enough about today, is how to keep a well-running facility online in an existing network for an increased scale. You don’t necessarily need to remove labor, but you do need to increase the capacity of the facility. A lot of times we look at elements like:
- How to increase storage density?
- How to increase input and output of the building – receiving and shipping of goods?
- How can we extend or enhance the capabilities of these facilities by optimizing their processes and ultimately four, five, or even 10X that throughput?
Customers don’t want to take on yet another new facility and move their entire operational staff; they already have something that works.
What are some challenges that arise when you scope out new supply chain automation and then must piece together disparate systems?
Often companies have a very discrete need for automation. Whether they believe they’re not picking fast enough and need to have more storage density, or they need to have more loading and unloading speed at the dock. There’s a specific problem they’re looking at that’s very understood operationally. What’s typically not understood is how it will translate into automation, especially when deploying for the first time. So, there are a few things that we look at.
First, they probably need to gather and understand data earlier in the process. So, we look at the actual throughput of the facility, which a lot of times mean projects start with a data study to look at factors like:
- How many order lines are you fulfilling?
- What’s your dock turn speed?
- What’s your storage density today?
- What’s the days on hand of your inventory?
Many times, that data analysis enables the customer to learn a lot about their facility, which can also change the problem statement. As an example, we might point out that they’re loading and unloading fast, but the operational choke point is in a different location. Or maybe their storage density is not necessarily the issue, it’s the days on hand for certain SKU types.
The second piece we look at it what process they want to automate. Commonly, a customer wants to automate the most difficult and laborious process for the warehouse team. For instance, an engraving process that’s in the middle of their shipping or pack out procedure. But first, you want to look at the simplicity to automate. A perfect example is driving long distances, straightforward, that’s a great supply chain automation use case. “Driving equals dollars,” is how we look at it. So, focus on automating the simplistic movements in the warehouse and then let’s scale up the complexity as we go.
What comes next after understanding the problem statement and selecting the approach?
Then it’s about how to bring this thing to life. The question at that point may have been around material movement, so we might look at a data model that tells us the facility is moving one way today, but now we’ll add automation that will either change or enhance the flow of goods. Or it could mean we need to start with operational changes.
The next element we look at is how the system data is going to flow, because with modern supply chain automation projects, you need data to make intelligent decisions, and that’s where software comes into play. One of the more underappreciated aspects of the process is that none of these systems are simple anymore. Today, bringing on a new WES, or integrating your WMS with a new solution requires you to think about the business logic that will occur throughout the system while you’re automating. It’s important to know those requirements; the fundamentals that you’ll need to understand.
Can you describe a project where you realize the magnitude of putting it together?
Sure, so when you’re looking at a simple project, like a transport automation session with AMRs to transport from one location to another, those are relatively straightforward problem statements. Warehouses only have so many pickup positions and drop off locations. But with multi-operational interoperability—receiving to put away; picking to pack out to shipping—you need to think about how one choke point in the system can affect everything downstream.
When looking at large scale integrations, you have a lot of bolt-down automation that’s not easy to change, but you might need that for the throughput of the facility. The challenge is that you have to get it right the first time and you have to build in flexibility. So how do you build flexibility into an inflexible hardware package? That’s one of the things we look at— how do system changes over here affect three steps down the line? How can certain situations happen that maybe devalue another part of the solution? So those are really kind of the sweet science of building out supply chain automation solutions at scale, especially when you’re talking $100 million facility. The larger you go, the more complex the system, the more data analysis you’re doing to make sure you get it right.
What are some of the elements that can cause automation projects to fail, or be less successful than anticipated?
One of the first challenges companies get wrong is selecting the wrong operation to automate; again, keep it simple vs. complex early on. That can cause an opportunity for failure or not hitting the intended ROI because there are too many things to get right in the process while simultaneously learning how to deploy automation for maybe just the first or second time in a facility.
Second is to look at the data that tells the truth about what the system needs to do. Quite often, data is pulled manually instead of automatically. It’s great to get shift reports and the like, but if you size the facility from error data—especially with larger and more complex systems—the harder it’s going to be to hit the intended ROI of the facility and get the automation benefit that you want to see.
The next piece is selecting the right technology. Say you want to solve for picking, or put away, or receiving your docs; you need to determine which technology can solve your problem. Right now, there are over 250 robotics vendors. So as a customer, I have a ton of opportunities and technologies I can choose from, but I need to know the right solution for my problem statement. There are benefits to all the technologies available, so part of the challenge is selecting the right one.
And then lastly, and probably most important but least talked about in my opinion, is the need for IT involvement earlier in the process—part of the WMS team, the IT networking group, or the CIOs team in the organization. What we’re seeing more and more are systems tied into a WMS, or some intelligent system, so you have to think about whether you have an IT strategy to support your supply chain automation deployment:
- Are there any security concerns?
- Is it cloud first? Or is it on premises?
- Can we get these systems to talk to each other/Do we have the right integration technology?
- Are they compatible?
- Do we have the right data to enable the outcomes that we need? That’s one of the biggest questions that’s typically answered early in the process, so if we can engage IT in the beginning, I think we really can start to see a lot more success in that process.
What makes getting technologies to talk to each other and speak the same language particularly difficult in the tech space?
Out of 50,000 warehouses in the US, 70% are still running manually, off paper, Excel, etc. So going from that to, for example, an automated picking solution can be a high level of change. The first problem you might have is infrastructure. Do you have internet connectivity onsite that can support the input and outputs talking to the cloud fleet manager? Do you have adequate Wi Fi coverage in the building? Sometimes customers are not yet prepared to handle the level of infrastructure that comes with supply chain automation. As a result, those infrastructure needs ultimately add to that total cost of ownership for the customer. You don’t want to wait and have that conversation after you’re already down the road on the project.
Once all the infrastructure is in place, the systems are connected in the same environment, and they’re on the same switches, the next question is are they even compatible to talk to each other? No two APIs for any system are the same. Even if they’re in the same technology, like REST JSON or SOAP XML, they’re not written with the same data tags, so you need to know how to map the data from one system to another.
What would you say to any CEOs, CTOs, or warehouse managers reading this who are at the beginning of their automation journey—maybe they have a deadline to deploy by peak. What do you want them to know right now?
The first thing is to start with the data. Digitize the operations you have now. Sometimes the best supply chain automation projects don’t have any physical hardware installed; we deploy software to automate a process that gives us telemetry on what’s really happening in the system.
Second, start small. Start simple with an easy automated solution; something that has a very discrete, proven ROI. Go after a project that has a timeline of no longer than six months.
Lastly, plan for iteration; plan for learning something with your team. In other words, don’t deploy a team to go do the automation and assume everything is going to be perfect. Apply a “build, measure, learn” mentality, because that’s how we create innovation in the space. I think those teams need to employ that same mindset when they go into supply chain automation projects—be ready to learn, be ready to iterate, and be ready for the next automation project that will inevitably happen.