Automation Unpacked: Evaluating Your Unique Warehouse Automation Needs

In this episode of Automation Unpacked, SVT Director of Solutions Architecture, Brian Stroup discusses the ins and outs of designing the perfect solutions for supply chain warehouses. Brian shares how he entered the industry and the types of problems customers come to his team to solve, such as integrating custom solutions.

Read on to see the valuable lessons and perspectives Brian brings to the table.

Tell us a little bit about what you do at SVT.

I'm the Director of Solutions Architecture, and for SVT, solutions architecture is kind of a three-pronged approach.

First, we support all our sales operations teams, we're like the technical liaison for those groups. So we do a lot of requirements gathering and product demonstrations with our potential customers and our partner base as well.

We also work on the project execution side, so all the specification writing and making sure we're developing the test cases that's appropriate to what we're deploying.

Lastly, we also report through the product organization. In that way, we are the market research arm of our product team, so we bring all the information we're gathering in the field—on both the sales and the project side—to our product team to hopefully incorporate it back into our product and ultimately improve our platform.

And before you joined SVT, you worked at a systems integrator?

Yeah, I've been in the automated material handling space since 2017 when I worked for a large systems integrator. I started as a business analyst and worked my way up to a solutions architect and have been in that space ever since.

Just to give a bit of color there, what types of projects and use cases were you working on?

With that company, I worked a lot on pallet technology, both in a crane and a pallet shuttle environment, with different supporting peripheral technologies—monorails, AGVs, things that help support pallet movement throughout warehouses. I also worked on several goods-to-person solutions and sortation type applications. My experience is all on the software side—the WES and WCS—of those solutions, so all the software and the logical business processes that support that physical robotic and material handling equipment.

In case a reader isn't aware, why would someone reach out for external support in deploying automation?

In my experience, most customers reach out because they want to gain an edge in their overall supply chain. In some cases, it's just about storage density, they’re trying to fit more inventory into a certain amount of square footage. Other customers want to gain efficiency on either their inbound or outbound processes or both. “How can I get this trailer unloaded as quickly as possible to get the material put away?” Or “How can I maximize the amount of material presented to a singular operator at any one time?” Because the more product you can move and the faster you can get it to your customers, the more money you ultimately make for your business.

So I think those are the things that lead people down the road of trying to find an automation solution—the business problem they're trying to solve, and how to improve efficiency in their building overall.

So say a company has selected the specific technology they want and then if they have an existing system, they have to figure out the integration piece.

When companies go on an automation journey, they start to think about how the system will fit into their building and into normal operations, including how it will integrate to their existing systems. I would say that 98 out of a hundred warehouses, in the US especially, are running some sort of WMS that ultimately runs the entirety of the building. And ultimately, most companies now have an ERP that would sit on top of that. When you run into those situations, you want all the data that's gained throughout the warehouse to end up flowing back into those systems for record keeping purposes: all of the accounting and financials are maintained within those systems. So in order to get to that point, you have to integrate the lower level of communication. And I don't think many people take into account all the different steps required to ensure that data is flowing from the level of the ERP that is managing the global assets all the way down to, say, the picking robot responsible for filling one singular order.

It's not necessarily that those elements are overlooked, it's just that they’re always the last piece of the puzzle people tend to think about. One of the beautiful things about what SVT Robotics is doing is that we're bringing the integration conversation to the forefront as much as possible, as there's a lot of information to be gained on the upstream side when you begin automation projects as opposed to at the end when you’re working to integrate them on site.

And what are some of the challenges that people face when getting to that integration step?

I think the first and foremost challenge people run across is how to communicate with each particular piece of technology. So if you took a really simplified use case and said, “I want to integrate my WMS to this one small picking engine,” like an AMR picking solution, you have to be able to talk to it and give it the information it needs to do its job and succeed. Ultimately that might simply be all the data about the order—the item you need picked, how much of it to pick, and where to pick it from.

All of that might seem simple on the surface, but to use language as an example, if you’re from New York, and I grew up in Southeast Virginia, we both speak English but not the same dialect. APIs were developed to be standard protocols that enable different systems to communicate with each other, but then they're not actually standard, right? Some might be a JSON format; some might be XML. The communication protocol—how you’re sending it—could be different as well. So when you drill down to it, the first challenge people run into it is just how to talk to this piece of technology.

And that’s a big barrier for people to solve because if your communication protocol is different, that's a wholesale change for that system, meaning there's a whole different piece of infrastructure that must now be changed and modified, so technical debt is being taken on by either the customer themselves and the WMS, perhaps trying to bring that back to the WMS provider on their own, or even the individual technology provider. And when you get to that point, it's usually the person who has like the lowest hourly rate that ends up having to take on the change. So that’s what SVT has taken on in the industry to try and solve.

Okay, so let’s tease that out a little bit. Technical debt. Someone's going to have to spend a good amount of hours.

Yeah, so let's break it down. We talked about languages, right? And different communication protocols. As an example, let’s say we’re integrating a WMS to a particular picking robot provider—if I am a SOAP communication protocol and you're a REST communication protocol, we don't speak the same language, which is fine.

But now if one of us decides to change—say you're like, “Well, I'll start speaking REST.” Okay, are you going to send XML messages? Or are you going to send JSON? If you agree to send JSON messages, now at least I’ll know how to read what you're sending, but even at that point I have to get into the actual field level naming of everything.

Meaning if I call an order, an “order,” but you call it a “sales order,” one of us has to change because those fields aren’t calling it the same thing. So, you need a mapping mechanism, something that's going to do that translation. And again, most often it's either the provider themselves or someone who has the lowest hourly rate that will now have to take on that technical debt to make all of those changes.

Additionally, that was just one field, on one message, for one workflow of a system. Now imagine that you have a more complex integration with a couple different subsystems trying to connect to the same WMS, and a more streamlined integration of different technologies working together. Then multiply that by four, five, or six, and however many messages and however many fields. You can see that the volume of this problem is not just down to one small change, it’s one small change that magnifies into a huge issue.

When you talk about changes and having to reconcile and create mappings, new technologies, incurring more technical debt and more development hours and resources, etc., you’re ending up with a lot of custom code, right? What are the long-term ramifications of that?

Well, you're not deploying automation in your building just to get it live and running, right? In some cases, you're deploying it to run for 15 or 20 years. You want it to be the backbone of how you fulfill orders or how you pick from different technologies for the next decade or so. Inherently, things are going to go wrong; at some point something isn’t going to work. And when that happens, someone must support it. So if you have a lot of bespoke integrations, custom code, that system isn’t stable overall, it's brittle and inflexible. A lot of things can break within that code stream.

Now when someone goes to diagnose the problem, they immediately run into having to spend the next five hours digging through all that code to try and understand what's happening in the system as opposed to being able to go straight to the problem. A lot of people who have worked in systems integration for a period of time will tell you that the amount of time it takes to diagnose the problem is directly related to the amount of time it takes to fix the problem. Most people spend five hours hunting in five minutes fixing.

So being able to get to the root of the problem faster is a main driver for why you want standardized solutions and high supportability solutions in place.

And within your experience in this industry, deploying automation solutions, could you describe a moment when you realized the magnitude of that ask?

Sure - I joined my former employer directly after several large projects had gone live. So, I didn't get a chance to dig into those specific projects myself, but as a new person at that company, I would hear the stories people were telling. For probably my first year working there, I didn't realize how large of a problem it was until I was two years in and started working on a project of relative magnitude to the larger ones the company had just finished. And I remember very distinctly that one of the first things we were looking at in terms of this project was a very large pallet system.

It involved a monorail used for transport as well as a couple of AGV providers. We started realizing that not only did we have an issue with communicating with everyone, but we also had all these different vendors, and we ended up being the central place that everyone was looking at to say, “Well, you guys are going to have to integrate to us.”

So now even outside the customer, we were the ones taking on a lot of technical debt on the project, and the majority of that was all technical debt that we had not as foreseen because we hadn't gone through the process of gathering those requirements well enough on the front end of the project to understand what those vendors were going to ask of us.

So I very vividly remember sitting in this little conference room in a corporate office at the customer site and having like a mild panic attack at not only the amount of custom code work that was going to have to be done on the project—and trying to get accomplished within the next 12 months because the timeline was extremely tight—but I was the one responsible for writing all the specifications for it.

I was losing my cool a little bit over the fact that meant five different documents to five different vendors, not to mention the ultimate document to the customer system. And so now all of a sudden, I have six or seven different integrations that I'm trying to balance. Not only from a know-how perspective—understanding how they all work—but then like, what do I write down? And making sure I'm not crossing my wires. So that was a huge challenge for me only a couple years into material handling in general, to understand that I have to manage all these different expectations and all these different communication protocols.

So the thing I learned with that experience is that in addition to being a huge lift on the system, it was also a huge lift on the project team to be able to understand what it would take to make sure that we kept [the communication protocols] all straight and did the right thing for each one, because they were all unique in how they approached the world. We had to be the thing that taught them a singular lens, but our software platform wasn't capable of doing that. So it all became a custom integration, all of it became custom code, and it was very brittle and it was a very difficult ask on the entirety of the project team.

And even if all that's done to spec and everything's running well, making a change or introducing an additional solution at some later time means going back to additional custom coded integrations.

Yes, if one of those vendors wouldn't have been able to deliver on time, not able to get their mechanics to the site or whatever it was, we would've had a really hard time trying to adjust our processes midstream of the project just based on the fact that everything was so rigidly defined. It's almost like starting at square one, as there was no fluidity in some of those requirements. It had to be this way or the highway, which means there can be a lot of difficult conversations with software engineers at that point because you're going back to them after they've already worked, you know, a hundred hours on this one piece. A lot of those folks are not real pumped about having to redo their work.

Can you also speak to the time changes that would take, because I imagine for a lot of people listening, speed to market and time to value are very important.

Yeah, for many people making these automation decisions, part of the challenge is it's the largest capital investment they'll make within their career. And so anytime that you're going to higher ups and saying, “We want to spend a million dollars on a project,” you're really staking your name to it. So they want it to be perfect and they're constantly assessing during the project, which can create very long lead times in terms of project life cycle.

An average project cycle was around 18 months, maybe longer. Customers would frequently change requirements, because from their perspective, things are different now than they were six months ago or eight months ago when the project began. So they needed to adjust that business requirement in order to meet the changing needs of their business. We had a rigid specification and process, and now we're trying to get out of that and make adjustments after the project has been like halfway or three quarters of the way coded, so there's a lot of rework that's created and extra costs that are now likely pushed back to the customer.

That's time lost on the project, which puts the final go-live in jeopardy. And when you're making such a large capital investment on that type of automation, that ultimate go-live date is what starts to justify the ROI. So you want to do everything you possibly can to hit that date, but you also need to hit that date and have the solution be perfect. It’s really trying to thread the needle in terms of what you're accomplishing, and that’s a difficult ask on any project team, on any company, on any systems integrator as well.

Let’s segue into a few other questions. For any operations teams that might read this, possibly looking to deploy automation by peak or other specific timeframe. What questions should they be asking?

One of the questions you should be asking is, “How are my people going to interact with this? What is the impact on their day-to-day activities?” Is it, is it making their lives easier, or is it making their lives more difficult, because maybe for a long time they've operated off of tribal knowledge. Maybe they've worked in the same building for the last 15 years so they know how things work. Now suddenly things are changing, so what’s the impact to the operations team on the floor.

Make it as streamlined as possible for them to understand in terms of the steps they no longer have to do. For example, be clear that these are decisions we're either taking out of your hands because it makes your job easier, or these are decisions we're putting into your hands because we know you can make the right decision to make the automation work effectively downstream. Because automation doesn't necessarily have to be a robot moving around, it could be a background process where typically an operator would've had to look at certain data points and utilize that 15 years of tribal knowledge to make those decisions.

The other big point to keep in mind is that regardless of how perfect you might plan the project, as we were talking about earlier, things will inherently go wrong, so how will your people fix that? What are the steps to resolve the issue? I think those are important questions to ask, and then make sure you're getting the proper answers to them because otherwise you could find yourself six months into an automation project not having thought through those types of variables.

We also want IT groups to feel confident in the solution, so if readers are looking to start an automation project in their environment, what questions should they be asking to be cognizant of the impact on their IT team from a resource perspective?

In my experience, most IT groups are, are very adept at asking the proper questions, as automation impacts their ability or their environment. But some of the topline questions are around how the system is deployed, or how the PC software is deployed. Is it on-premises? Is it a SaaS or a cloud solution? What are the security requirements? And if I'm the customer, how can you adhere to our security requirements?

A lot of customers maybe struggle to have their own individual security requirements well documented so that they can provide them to different vendors and say, “These are the things we need you to adhere to.” I think it's really important for companies that deploy automation to remember that they are ultimately the customer, so what gets done and how it gets done can be dictated by them. Having your wish list, writing it down and being able to present that to different vendors is an important piece to remember as you start pursuing an automation journey. Because the more information you can provide on the front end, the easier it will make things on the back end.

The last thing I would say is, what's really important, especially for an IT group is, again, “What do I do when things go wrong?” One of the things we do in solutions architecture is mapping out the workflows and the processes that will support the automation on site. We always term the way that we’re trying to accomplish things as the “happy path.” We can figure out the happy path in about five minutes; it's everything else that takes up the most amount of time. So the 98% we accomplish in about five minutes, and then it's that 2% of edge cases that will require us to drill into each of the little details, because we have to understand if something doesn't go quite right—if we short pick something on the floor, how does that data flow back into the system and get back to the WMS so that those records are properly updated—the inventory's properly tracked and we're updating the customer's order correctly. Because any missteps in those areas and ultimately you short a customer, or you short a vendor and it can cost you money. So we need to be asking ourselves at every step of the process how we will react if something goes wrong. What is the system going to do? And what does the data flow look like to support that?

Thank you so much, Brian. Before we let you go, I'll ask one last question—from your perspective, what would you say is the biggest misconception when it comes to deploying automation across the supply chain?

It's a good question because I think that what most customers I've interacted with tend to discount is the uniqueness of their environment. I can't tell you how many customers I've interacted with that think they’re like every other retail shop, or like every other food and beverage company, for example. And while there are common themes across those verticals specifically, there's definitely more uniqueness to each individual environment than what people give credit to. Businesses operate in their unique way for a reason. So don't discount that when mapping out your processes and trying to fit automation into them or adapting your processes to enable automation, because your environment is definitely unique. There's something that you do that nobody else does, and you can't take that for granted. Bring up everything you possibly can because you never know what might cause a vendor or an automation provider to say, “Oh, we can meet that need.”