*Interview edited for length and clarity. (See the full interview at Automation Unpacked: Workers Sent Home—The Power of One Failed Message in Integration w/ Steve Thorne)
In this Automation Unpacked conversation, Steve Thorne, Vice President of Product Success at SVT Robotics, shares lessons learned from his 24+ years of experience in automation solutions for supply chain operators. Steve talks about how he got into the industry and the types of problems customers come to them with to solve, such as visibility and logging. He also warns what happens when companies don’t have system visibility in warehouse automation.
Talk a bit about how you got into this industry?
I was originally in the electronics industry, but started doing software in the late 90s and really liked it. After software engineering, I moved more into solution architecture over the course of my career. So, in the beginning, I was focused on one project for a long period of time; now my focus is multiple projects at the same time, looking at overall requirements while others manage execution.
You were at a systems integrator before SVT—what types of problems were customers wanting you to help solve?
I started off in the UK and Europe. They don’t have as much warehouse space as in the US, so everything is built vertically. We deployed a lot of high bay storage systems; how to make pallet storage and the like as dense as possible. The problems we were solving were focused on how to get more product stored in the same space or with only a very small space increase.
As my career progressed into solution architecture, I began talking to customers about how to integrate their WMS, how to get it to communicate—make this pallet move from the receiving dock into a controlled storage system and out to the shipping dock, for example. At that time, it wasn’t so much about the technologies, it came down to things like availability of human labor, whether there was a software developer available.
So, when it comes to deploying automation, what has made it challenging over the years?
The integrator I worked with, and many others, had their own equipment portfolio. Standardization was always something they wanted to give their customers, so they would offer specific pieces of automation they could readily deliver. But many companies needed to deploy alternative technologies, or one type of robot that can handle a specific type of payload. That meant we would have to talk to the manufacture of that technology about how their systems communicate.
Unfortunately, unwillingness on the side of the integrators to change how they do things, in addition to friction about that needed information, meant I had to get everyone around the table, which could take weeks, sometimes months. For any of these systems to communicate, someone had to change their process because one robot, for instance, does things a certain way and only that way. So, although you were talking to only one technology, a lot of things still had to shift and compromise, which sort of became like a jigsaw puzzle that didn’t quite fit. Getting any complete solution to work was difficult as a result.
And could you describe a moment or a project when you realized how vital it is to have system visibility in warehouse automation and how that impacted a successful deployment?
I vividly recall a project in which a single failed message within an ERP system caused the entire operation to grind to a halt.
I was working on a project in Holland for a pharmaceutical company that manufactured and shipped the finished product. We were integrating to an ERP—enterprise resource planning system—and one of the messages failed transmission, but we couldn’t see the failure within the scope of our software, and the pharma company wasn’t able to see the failure from their side.
So, in the ether somewhere a message had failed, but no one could determine what the message was and why it failed. Unfortunately, that one failed message ended up bringing down the entire system; it was like a domino effect.
After being on the phone with the ERP support team for about six hours, we finally figured out what was wrong. But in the meantime, a group of pharmaceutical company executives came to the office I was working in and beckoned me to the window to show that everyone was walking out of the site—they had sent workers home that day because there wasn’t any work for them to do. That shows the potential power of one failed message and how critical the role is of system visibility in warehouse automation.
Once the problem was diagnosed, the ERP support team still couldn’t access the database from their location, so they gave me instructions to access it. But then, we had to determine whether it was an incomplete transaction that I would have to force commit or force the transaction to be rolled back.
Instead of telling me what to do, the support gave me a long list of transactions to review. By this time, we’d been down for 8 or 9 hours; everyone had gone home, and I was desperate because there wasn’t anyone else available to help me.
So, I flipped a coin. For real, I flipped a coin.
Do I force commit? Or do I force rollback the transaction?
And it was a force commit.
So I followed their instructions for a force commit and the system came back up and running; everything started moving again. The next shift was able to come in and begin their work.
But that one message caused an entire system to stop. How much money they lost, I’m too scared to ask or to know. But it showed how fragile integration—or bad integration—can occur because nobody had visibility to the problem, just no visibility.
That painful experience underscored the need for comprehensive logging and system visibility in warehouse automation integration projects. From that point forward, I prioritized robust logging mechanisms to ensure prompt fault finding and effective triage. By enabling clear visibility, operators and IT teams can quickly identify and resolve issues, minimizing downtime and potential losses.
What are the circumstances that make it painful to integrate different technologies and systems
First, assessing whether any two technologies have a way to communicate to the outside world. If they don’t, that must be developed in the form of custom code. Even if they do have a way, how they communicate is still very different. APIs—Application Programable Interfaces—were developed to solve this, yet no two APIs are the same.
So companies end up doing multi-translations—this is what it means to do “X,” and this is what means to do “Y,” plus, any business rules the customer wants to apply. For example, when the robot “sees that,” we need the system to react in “this” way. Ultimately, to maintain all that there must be “dictionary translations” in the form of custom code development.
There’s no shortcut, no matter how much money you throw at it.
Correct. It’s the paradigms within the integration industry. It’s been very difficult to break out of that, and after the tenth weekend of being on site, or the fifth month of being away from home, you’re always thinking there has to be a better way.
That tees up the SOFTBOT Platform nicely. In case people aren’t familiar, please give a high-level explanation of why it was developed, because it ties in with the integration problems you lived with for so many years.
Yes, that was my reason for joining SVT, this opportunity to change the paradigm that we’ve historically operated in, and to improve the lives of the workers in the industry who don’t want to be away from family and friends for so long.
The SOFTBOT Platform integrates automation regardless of what’s happening in the middle—technologies only integrate to the SOFTBOT Platform; they don’t have to worry about anything else in the system. It can integrate completely standalone solutions, or one technology that’s working in harmony with 12 additional technologies, but the only thing that any of the solutions see and communicate with is the SOFTBOT Platform.
With the portfolio of technologies that the SOFTBOT Platform can integrate being so modular, they become literally “off the shelf.” If you have a system that wants to talk to “technology X,” for example, we have a SOFTBOT connector and orchestrations on the platform that already exist for technology X.
Or, if you use “warehouse management system Y,” SVT has that off the shelf as well. There may be some configurations that need to be done, but we can give you access to the technology now, within weeks as opposed to months or even years. It’s like the United Nations of automation—this robot speaks in German; this one speaks in Chinese—we “translate” to the “language” of the SOFTBOT Platform and orchestrate from there.
What about companies in the process of upgrading their existing WMS, so are hesitant to deploy new automation since they’re going to soon redo an integration?
With the prebuilt connectors we have on the SOFTBOT Platform, the technologies that companies want to deploy are, again, already on the shelf. So they can use it whether it’s one robot for a pilot project, one use for a full blown existing manufacturing plant, or even a warehouse with 30-40 robots.
What if a customer has a homegrown WMS, or maybe even multiple WM systems – how is that supported within the SOFTBOT Platform?
If the WMS connectors are already in our portfolio, then again, we’re off the shelf. If it requires a new SOFTBOT connector and we’re given the APIs, we can connect to it within about 45 days from the contract being signed.
Regarding a homegrown WMS, we never tell any application or technology they have to change. As long as the manufacturers can tell us how it communicates – what their messaging looks like – we’ll take their data to build a connector. The result is that what would have been a big problem with the old way of doing integration is now much smaller by integrating using the SOFTBOT Platform.
And just to level set when you say “connectors,” you’re talking about prebuilt integrations, correct?
Yes, we take data for specific use cases—for example, customer orders—and map it into the SOFTBOT Platform. Then in our order domain models, (and any other edge tech that it needs to operate with), we can convert them to whatever workflows the edge tech requires via their SOFTBOT connector.
Got it. And you also said “orchestrations”—could you give some examples of what those look like and how they play into these integrations?
Sure, here’s a simple and tangible example of something we’ve done very recently: orders came down from a WMS, and the robot technology processing those orders had a requirement to use a flag set to identify any “super single” orders, meaning only one item ordered within the other many fulfillment orders. But rather than asking the WMS to add an additional process field to their API to set the flag, the SOFTBOT Platform ingested the order and then used a pre-built orchestration to look for and recognize the super single order.
We did that by asking, “Does it have just one order line?” And “Does that one order line have a quantity of just one?” If the answer to both was yes, the SOFTBOT Platform orchestration would see it and say, “this is a super single.” Then we simply converted the order within the platform to the “super single” workflow instructions needed by the robot technology.
Wow, okay great! So you’re not asking even the host system or the edge tech to modify anything on their end, nor do they have to do a lot of extra work to accommodate that.
Correct. And again, the SOFTBOT Platform is not a big, monolithic piece of software, so the time it took to actually do that work was very fast because we just wrote one piece of code: the “super single” orchestration.
It’s not taking months.
Correct, it only takes hours in those cases.
That’s impressive! Before we wrap, what’s the number one thing you would tell someone just beginning their automation journey, or even someone tasked with deploying X, Y, and Z, automation by peak?
If you have a manual process you want to automate, don’t just copy that workflow exactly as it runs today and automate it. Too many times in my career, I’ve seen a paper-driven system simply replicated in automation, and as a result, all the advantages to be had with that new automated system are virtually lost because of the process being so rigid in its design.
Instead, really take the opportunity revisit your processes overall to see if there are areas you can restructure in order to get the most out of your automation deployment. So that would be that would be my advice, as well as, obviously, let the SOFTBOT Platform do the work.