In this conversation, Chloë Lind interviews Brian Shuckle, Director of Strategic Accounts at SVT Robotics, about integration issues that arise during the lifecycle of a WMS. They also discuss the future of automation and what successful deployments looks like.
Brian, I know you've been in manufacturing for most of your career, tell me a bit about how you got started.
I started with an internship at Lithonia Lighting in high school, where I handled inventory purchasing for manufacturing supplies. Later, I pursued a computer engineering degree and worked at an Italian-based gear company, which gave me experience in supply chain and warehousing conveyors. Subsequently, I joined an industrial computer IoT company and delved deeper into manufacturing and global supply chain.
That led me to Manhattan Associates, where I spent 15 years, originally starting as an account executive for the hardware team, but then moving to consulting and architecting server solutions in warehouses, which gave me a very good understanding of data center solutions servers, third party software, and cloud hosting. From there I moved to SVT.
When thinking about how things have evolved and your role today, describe the challenges that 3PLs and large retailers have in automating their facilities. What are their most burning problems?
A lot of problems. Today, 3PLs and retailers are converging after having been very different worlds. Large retailers used to have fantastic supply chains they built themselves, because it was cheaper to own and maintain your own supply rather than work through 3PLs.
But today, these same large retailers, like Walmart and Target, know that many companies need that service, so they can use the supply chain they've built and turn themselves into a 3PL while the remaining, smaller retailers look for 3PLs to help with their supply chain. Small retailers don't have warehouse capacity, they don't have warehouses in the right locations, and increased real estate costs are driving their costs up. I think in just the last two or three years, real estate is up 20% year-over-year in costs, combined with the fact that there's a 3% vacancy, and even less than a 2% vacancy in some locations. The warehouses that do exist weren't built with the density needed for the influx of product. So these retailers can't find locations to meet today’s current two- to three-day shipping expectation.
The next challenge is the labor shortage—getting enough people to pick all the warehouse product. Plus, high turnover and increasing labor costs.
Lastly, their IT groups are already overworked, so it’s hard to ask them to do more with less IT budget, because it takes more money to stand up the real estate and pay employees to do the work.
For people new to automation and integrating technologies into their host systems, isn’t there also a limited number of programmers that have the skillset and expertise to execute those projects?
Yes, there's a booming amount of automation solutions out there, robotics and high-end automation. And I think they're talking about a growth in robotics of like 14 or 15% over the next 10 years.
So as that industry grows, someone must connect those pieces to make them talk to each other, which is integration. If that expected growth happens, we need on average about 189,000 programmers every year, and we currently don't have enough college grads with the ability to fill all those annual vacancies. So integrations either won’t get done or it will become slower and costs will go higher because there's such a demand for programmers.
And that's not even considering what support looks like long term as business needs change. What does that integration look like even six months from now with 3PLs whose customers might rapidly change?
They’ll have to get developers back in to adjust the custom integrations. And going back to the shortage, you’ll have programmers who write the code and then left. The result is that no one understands that unique code.
And the companies are left holding that. What do you do?
Especially when the market changes, which again, anyone in supply chain or distribution in the last three years has seen vast changes—a shift from brick and mortar to E-com that changed everything.
So companies now have to be more flexible; adapt and move quicker than in the past when the supply chain did what it was supposed to and once it was working, no one touched it. But now companies need to optimize their supply chain each time there's a variance in the market or get left behind. We've seen that with company after company.
Absolutely. Just with the events of the last few years, I think the average person is aware.
Yes, people who didn’t know what supply chain was now have questions about it. And I'll say this too—people who worked in supply chain were most likely a factory worker, like a mechanical or industrial engineer, not a computer or robotics engineer. So that shift has suddenly brought more innovation into the supply chain than we had previously. And I think that’s a good thing.
Yeah, absolutely. I think everyone's like, “It takes six months to get a couch?” So everyone is keyed in. But stepping back a bit, it seems like there's now a shift to digitization in the supply chain?
Yes, what you've got is a shift to companies understanding that they have to digitize to move forward. That goes back to why a lot of companies come to SVT—there’s the old way of doing things, just the standard, complex way of building integrations, so it was also very rigid.
The point-to-point integrations are what APIs were supposed to solve, everyone was supposed to write a communication standard that people could meet. But with everyone writing their own standards, that didn't help.
So then people started building products for digitization, like iPads, or platforms like MuleSoft or Boomi that basically say, “Hey, your developers can just quickly write their own APIs.” But again, it goes back to what APIs they’re writing and how they’re writing them. What are they matching against? So it's still a specific set of APIs for the task they’re building to that aren’t generally useful.
Once again, you’ve got to have a developer come in to make those changes. And like we talked about, suddenly companies need to be able to quickly switch warehouses, or switch to products that are more viable in today's world.
So that's where SVT comes into play. We offer a low-code product, which means you don't necessarily need a developer, other people can learn it as well.
Yes, our SOFTBOT Platform has pre-built integrations to 90+ automation technologies. We give you “single pane” support visibility, decreasing time-to-problem resolution, which also decreases costs. It enables you to make real-time decisions based on business logic for orchestration in the integration.
But a little more background in what that means. Typically, integration meant you sent data, and that data got passed to other endpoints. That's all it was. But being able to make decisions in real time is a true game changer—it goes beyond just automation to bringing in disparate subsystems that have all the data you need. It's not just system to system, it's taking bits of usable data from across the enterprise and being able to make business logic decisions within your supply chain.
Integration with SVT also allows clients to deploy the best of breed solutions. So you don't have to have one vendor that does palletization, that does truck unload, that does picking, that does transport tasks, that does putaway. You can find best of breed for those individual parts to focus on what they do best, and then have SVT orchestrate all of it, which wasn't possible in the past—or—becomes very difficult if you use a standard integration method.
Talk about the risks associated with massive automation projects to begin with; they’re not cheap endeavors, and historically they’ve taken a long time. What does it look like when that doesn't go well?
Supply chain is everything for these companies. If the supply chain is broken, they're not making money. In my previous experience, changing a WMS, or fully automating a facility with massive automation is what we called “C-level killers.” Meaning a C-level person decides for that company, and if it goes wrong, they’ll probably lose their job.
In the past, automation projects required a lot of time because those systems are like a “walled garden;” it's very rigid. As an example, “This is how we'll go from point A to point B, and then from point B to point C, we’ll do this. Or we can go to point D.” They have to be designed out of the gate with every possible exception scenario worked out ahead of time, because once that automation is in place, it’s very difficult to handle an exception that wasn't worked out to begin with. Getting late exceptions taken care of by a vendor is extremely expensive.
So in today’s world, that’s just not been something that smaller retailers and the 3PLs have wanted to invest in. They're changing customers, changing products, and changing workflows, so they must be able to do that on the fly. “All in” large automation solutions aren't their best choice.
And particularly for 3PLs, but for really any business, it’s important to find best in breed solutions to meet those business needs that will change. How does the SOFTBOT Platform manage that?
The SOFTBOT Platform is fully agnostic to different robotics brands. Without it, integration is like square peg/round hole, because every time you add a vendor, you add multiple integrations. SVT takes data from all the endpoints, and rather than everyone trying to talk to each other through APIs, we have normalize the data in a layer we call “domain events.” So all the technologies communicate through those common domain events, then just publish and subscribe data into those events.
Think of it this way—if you speak French and I speak Spanish, we wouldn't have a good conversation. But if I'm able to talk through an avenue where everything I say gets translated into French, you hear exactly what you need to hear. And everything you say is converted and sent back to me in Spanish. The SOFTBOT Platform is like a universal translator that sits in the middle.
The platform can also interrogate what I'm saying and manipulate the words back to you so that it makes better sense to you in French. For example, from a WMS perspective, I might not have the ability to send a certain set of data, so rather than trying to teach that WMS how to send it or get a developer to write that code, SVT can interrogate that data and know that additional bits of information are needed to pass on to the execution technology. We can create that information in our layer before we send it on, so that means I've taken technical debt off the WMS provider and put it into our layer instead.
We can also write business logic that recognizes if you were trying to say something back that needs to go to a third person in the room instead of me. Our platform knows exactly who I'm sending data to and what data they need, so I can interrogate where it goes and can even orchestrate exactly who’s having the conversation. That's what SVT can do in the middle.
To clarify, that means the robotics tech can easily communicate with all the other technologies out there.
Right. We talked about our OEM vendors and the 90+ SOFTBOT connectors we have pre-built. We ask vendors to give us the “language” they’re “speaking” in, their APIs. We don't need them to change anything, we take that and convert it into our domain events, so they're already talking to my layer.
From an integration perspective, that decreases the time. I just go to all the endpoints and simply say, I don't care how you get me the data, I'll convert it into my domain events and my domain base, and then everyone can publish and subscribe. Those endpoints now are standardized, so the support for those technologies remain standard. They're not doing custom integrations for every single client, which gives SVT the ability to get integrations down to a 10 to 12 week timeframe vs. 12 to 16 months with standard integrations.
Yeah, that's a big difference. And again, with reduced risk, right?
Absolutely. And long-term flexibility and scalability. Because those components are reusable.
Before we close out this part, I would love to hear you give a specific example of the orchestration capability the SOFTBOT Platform can support. What are some common use cases?
Sure. We call it a SOFTBOT orchestration. A great example would be a client we had that was running AMR picking robots, but they found they hadn't slotted their facility. “Slotting” is when you put items in certain rows so that you pick efficiently. During peak season, the AMRs were getting very congested because they just couldn't get through the aisles, which led to poor bot performance and low ROI. So SVT built an orchestration that took their fastest movers and sent that data to a put wall and a pick-to-light wall.
We were able to pull the fast moving AMRs out of the aisles and create an orchestration that said those items should be picked from pick-to-light. We call those orchestrations “microservice-based” SOFTBOT connectors. So now on a seasonal basis, that company can add or remove those orchestrations as needed for specific periods of time.
Another great example is from a client who had a WMS that couldn't do super singles orders. “Super single” means a single item, single line, single SKU. So we suggested that instead of trying to fix the WMS, we can add a “super single” orchestration before the order is sent down to the picking bot, which can handle it from there.
Now, the great part is that IF they had chosen to change their WMS or even switch to an upgraded version of the one they had with the “super single” capability, we could then simply remove that orchestration. So we can fill gaps with orchestrations, and we can do work that WMS or ERPs or other host systems don't have the capability of doing without putting technical debt on those products.
That's amazing. It’s also a good segue into another question—what if a customer is in that phase where they need to upgrade their host systems but might be hesitant to embark on an automation initiative because they think they’ll have to redo everything with the new system?
A common perspective is that WMS upgrades are company killers, as are customizations within WMS or any software product making an upgrade. So clients tend to sit on the current versions of their software for like eight to 10 years. Often, it’s because they customized it and don't want to port those changes and don't want to move off of it. The WMS provider doesn't like it because it’s out of support, they'd rather clients be on a newer version.
And so WMS providers across the industry have gotten to the point where they can no longer take on that technical debt, they want to move towards having a standard version. They also want to stick with their standard APIs, they don't want custom APIs because it’s too difficult to manage and maintain. SVT has pre-built SOFTBOT connectors to those host systems, allowing that new product to be quickly integrated, giving flexibility and choice. And, again, that’s AS they’re upgrading,
Here’s a great example. We had a client that wanted to add automation, but they wanted to wait a year and a half until they finished their WMS upgrade. Using the SOFTBOT Platform, we helped them automate now by building a connector for their new automation to integrate it with their existing WMS. And because it wasn't a costly point-to point-integration, a year later when their upgrade was finished, we simply pulled out the old WMS SOFTBOT and dropped in the new WMS SOFTBOT without the automation having a clue. No one from the automation vendor had a conversation with the WMS provider about building the integration, and we changed their WMS within the warehouse overnight. The warehouse people didn't even realize it other than the screens changed on some of the user stations.
So that's the power of SVT and SOFTBOT connectors.
Great! And when should people start automation projects?
Early and now.
Companies are afraid to start automation because they think automation projects are big and scary with high integration costs and timing. But the way to look at it is to start now and start small. Digitize first, deploy smaller, and deploy faster. That lowers the risk and gives faster time to value on each of the products. Even if you can do something as easy as taking measurements to get better visibility into your warehouse with IoT. For example, how often a trash bin gets emptied. With simple IoT monitoring, when that trash bin is full, you can then have it picked up by an AMR and taken away.
Or how often are you doing cross docking? Look at how long pallets are sitting in your dock before they're moved across. You can get ROI out of an AGV moving product throughout the facility rather than labor doing it—put your people on tasks that bots can’t do. So all that leads into digitizing first, which is simple as taking your host system, building SOFTBOTS connected to it, and putting that data in the platform where it’s now visible to you. You can then take that data and access it to answer questions about what's happening in your warehouse that you might not have previously seen.
When you're having conversations with retailers, or 3PLs looking to automate, what elements in those engagements tell you those companies will be successful. What are they coming to the table having thought through?
It varies. Many companies are building their own “IT innovation teams” to go out and see how they can innovate, especially across the 3PL market. More companies are understanding that automation is now an inevitability, not a nice to have. So the conversations move a little quicker. But again, it's above and beyond automation, it's conversations around what to do with data and how they make better business decisions in the warehouse overall, not just an integration of sending data to a particular device.
So when you get a client who understands that if they take all their data mapping of where their product is, how often it's picked, who's picking it, how often they're picking it, where it's going, what they're picking it with, and how often that machine is used, they can actually orchestrate all that data from IoT, from other subsystems, from other providers, and use it to create business logic to orchestrate. That’s the key. The people that get that immediately have lights going off in their minds while we're having conversations.
What's one thing that surprises people when they learn about SVT or just about automation and what it takes to integrate and deploy it?
I think a lot of people have the misconception that SVT is just an integration platform, and we are quite a bit more than that.
Here’s a real world example—I was in a meeting with 20+ executives talking about issues within their warehouses. I pitched an idea of using the SOFTBOT Platform to take data from multiple subsystems in ways they hadn't thought of and give them access to real-time visibility to some of their labor force. Light bulbs went off. “Oh, you can do that?” And the answer is, yes. And again, it's because of our domain model that we can take data and put it into our system and aggregate it across multiple disparate systems. So that was a change for them because their viewpoint of integration was that they have to go from system to system, system to system, system to system. I made it very clear that with SVT, you don't have to start at the end, you can go all the way back to the beginning and take data from there, and then take data from the next step, and then take more from the next step, and then bring all of that in and merge that important data to make decisions from.
Previously, you had to look at one subsystem, log in and create a report, and then look at another subsystem on the other side and create a report, and then someone’s creating an Excel spreadsheet in the background that merges both of those reports for someone else to make a decision from. But what if you could take all that data into a singular location and make decisions from it? You can with the SOFTBOT Platform, and that's an eye-opener for a lot of people.
And that is a massive problem across all industries—how to take data from disparate systems and make it help the business by informing their decision making. That’s quite a game changer.
I think historically you can pull in data from different systems, but it's not mapped, there's different definitions. It's hard to reconcile and provide value. With SVT, not only are we pulling this data in, but it's already mapped, and because it’s within the platform, we're standardizing that communication.
That’s amazing. Okay, before we wrap up, I want to hear your thoughts on what a successful automation deployment looks like.
So successful automation deployment—here are the top three elements: Being on time, being on budget, and no exception cases. The crazy part is that is a unicorn in today's world, it just rarely happens. And really, you're trying to minimize the risk for each of those. So you need a tool that helps you deploy faster with less costs and gives you the ability to handle exceptions much quicker and more efficiently than traditional hard-coded integrations. And that is exactly what SVT’s SOFTBOT Platform is because it was built off the idea that projects were never on time, never on budget, and always have exception cases.
Any other advice you would give folks embarking on their automation journey before I let you go?
Automation and integration don’t have to be that complex. I think people in today's world make it out to be time consuming and painful, but it doesn't have to be.
Second, from an IT perspective, don't fight with your ops people, give them a tool like our SOFTBOT Platform that they can support and enhance and help the operations team and even have the operations team assist in supporting it. That’s huge.
Lastly, digitize first and even starting that process smaller. You don't need to throw everything on it at once, start smaller and then move faster. If you wait to try to do it all at once, you're not going to find the real estate to put in a brand new warehouse and full set of automation. You won’t have or find the developers to build all that code right now to get it done in time to get anything productive out of it. Use your existing locations, get it done smaller and faster and then it’s easier support. Use our tool set, which is the SOFTBOT Platform. That's the way to go in today's world.
