The elements of a successful automation project

We’re excited to bring you our first-ever podcast series, Enabling Automation. This monthly podcast series will bring together industry leaders from across ATS Automation to discuss the latest industry trends, new innovations and more!

In our seventh episode, host Simon Drexler is joined by Adam Pringle to discuss the elements of a successful automation project.

What we discuss:

• Why defining success is important for your automation project
• What elements are important for your project success
• How defining gaps will set you on the right path in your project

Host: Simon Drexler, ATS Corporation (ATS Products Group)

Simon has been in the automation industry for approximately 15 years in a variety of roles, ranging from application engineering to business leadership, as well as serving several different industries and phases of the automation lifecycle.

Guest: Greg Debus, ATS Corporation (Life Sciences)

Greg Debus has been with ATS for about 14 years in the applications group. Greg has worked in the front of the business his whole career.

——Full Transcript of Enabling Automation: Episode 8——

SD: Welcome to the Enabling Automation podcast. I’m your host, Simon Drexler. I’ve been part of the automation industry for approximately 15 years in a variety of successive roles with both small and large companies. Today’s episode focuses on the elements of a successful automation project, and we’re joined today by Greg Debus. Greg, can you take a minute to introduce yourself to the listeners?

GD: Sure thing. First of all, thanks for having me, Simon. As Simon said, my name is Greg Debus.  I’ve been with ATS coming up on 14 years now, all in our applications group. So I really like working in the front of the business and that’s been, yea, been my role the entire time.

SD: And an excellent background and experience to be able to share with the listeners today. When we’re talking about the elements of Successful Automation Project, you spent, you know, 14 years setting up successful automation projects. So, really excited to chat with you today and learn about a few of those examples. There’s a lot of takeaways and things that we can impart on our listeners for how to set yourself up for success right from the very beginning. And so do you have some guidance that you would sort of start with when somebody comes in and says, Greg, how do I get this right?

GD: Sure, I’ll take my best stab at it here, of course. But I mean, it seems like the low hanging fruit answer, but I think the first step is just trying to define what success looks like. So before you get into, you know, concepting or jumping too far ahead, it’s like ultimately, what is the customer hoping to achieve? What are the key metrics? What are what are you trying to ultimately have this this system or systems do? Typically, you know, there’s the usual answers of we’re looking for a high rate, high MOEE system or we’re talking about, you know, reduced floorspace or best delivery. All those things are kind of inherent in any opportunity. But then it’s working through some of the, I’ll say, more customer specific things. Are there elements of a system that are very important to them? It might be important by location, for instance, like their, their technical staff may be more used to, let’s say, mechanical based systems, as such then things like training or post SAT support become important to them, right? They want to keep that success going after the machine’s delivered and as they’re ramping up, that’s an element that without kind of digging into those key, you know, success metrics, you might not understand we might be missing the mark in that the true measure of success.

SD: And what an awesome place to start is we often talk about the technology because we get really excited about it, right? You know, we put robots in and we’re going to automate the process. You really touched on organizational capability to support the technology that you’re implementing and how that’s part of setting your project up for success right from the very beginning. Have you seen a best practice before where you’ve seen a company do that really well?

GD: I would maybe go more generalized and say European customers typically are stronger or more comfortable with, say, mechanical based systems such as an OmniTrak, where there’s ones in North America that are moving towards more of a digital platform such as Symphoni and the electronic cam based solutions. So as we’re working through with a partner, that is one of the questions that we ask just to get a better sense for their own capabilities and what their technicians and engineers and etc. are looking for. We don’t want to go down the path of working through a concept that’s not going to meet their needs or leave them, you know, in a in a position to do to achieve success, post SAT. So really we would be asking those exact questions of what’s your what’s your maintenance staff look like? What’s the, you know, what’s their level of comfort with mechanical cams? Setting those up, doing maintenance like things like that versus you know, there’s customers within North America that maybe have more control support and are more comfortable taking on sort of that level of servo driven or service based chassis.

SD: And so when you’re looking to the people or the team that’s providing the automation, you know, part of setup, setting the project up for success is identifying those gaps and relying on that partner to train, to enable, to leave your organization in a place where they’re going to be comfortable with that piece of equipment. Is that right?

GD: Absolutely! Well-said. And that’s and that’s really what we want to identify. If they are interested in taking that next step or bridging that gap to bolster their own capabilities, that’s where we can really help them be just because of the breadth of knowledge and talent we have here to draw from, plus our, you know, our service group and that ability to send people to site to do the whatever level of training is required. Right? It could be as simple as staying on a week past SAT to work with their controls team to in more of an informal setting. Or it can be as a as advanced as operator training, maintenance training, engineer in class training. All those things are things that we can offer and it’s just finding that right fit.

SD: Our conversation is naturally gravitated toward the timing of the technology being in the facility and what’s required to make the team around it comfortable. If we move back into, you know, one stage before where the machine is being built or even when the machine is being designed, is there a best practice in that area to make sure that the team that’s accepting the technology is ready for it?

GD: Great question. I’ll maybe even go one step back further, right to the to the quote phase where I’m obviously most comfortable. So really, it’s bringing in the right people with the right level of experience upfront ahead of, you know, right in that concept development phase, not only from the customer’s team. Obviously, we want to have the right people there with the right skill sets that understand their product, their processes, their facilities, limitations. But also, we want to have our right experts weighing in on the direction that we’re taking the concept. I mean, let’s be honest, we’re an ETO or an Engineer To Order solution provider where things are typically done for the first time. Right? And we want to rely as heavily as we can on any previous experience that we do have there. The other element, I guess, to keep in mind is a lot of our customers are repeat customers. So even though a system may be new in that it’s for a new product, it may have elements related to a previous system that we don’t want to overlook. So it’s important to be pulling in the right folks to those discussions to make sure that we’re meeting kind of those underlying needs that maybe aren’t as clear or apparent in the in a URS, its just, you know that tribal knowledge type stuff.

SD: And as an ETO provider and I think a lot of those listening to the podcast today, they’re looking for ways to either get started in their automation journey or advance it in in some way. So Engineered To Order again, that’s generally something that’s being done for the first time. Do you find it common that in the application phase you can leverage machines that have come before the next one where you can kind of reach back into that experience pool or reach back into the design binder to pull out examples of something that’s come before something that’s been done before.

GD: Absolutely. 100%. I mean, obviously, that’s the ideal state. If we can pull from something that’s proven, there’s of course, going to be instances where that’s just not possible. We are looking at a product or a process that’s completely new. So granted, that’s why we do things like POPs and pull in, you know, again, those experts that can weigh in on risky areas and our goal is to, you know, remove or reduce that risk as much as we can upfront. But of course, we’re always going to try to leverage something that we know works. Again, it goes without saying, I guess, that why reinvent the wheel if we know that we’ve got something that we can pull from.

SD: And absolutely. I think for a recommendation to those listening and getting started or looking for a way to create a successful automation project, that the strong automation partner is something that’s quite important and that may vary depending on what your need is, but that person, that partner, that company, should be able to reference something that’s come before to reduce the risk of the new thing that’s being created. And if that is not possible, because sometimes it doesn’t have a level of defined process for how to reduce the risk for that new thing. And Greg mentioned the acronym, POP which is a Proof Of Principle, a fairly common way to describe we’re going to try to do something new. We’re going to take some technology, wrap some really smart people around it and prove to ourselves and to whomever else that we can actually do that. Is that fair?

GD: Absolutely perfectly said. Yeah, we are doing it to prove, obviously, to the customer but to ourselves that this is possible and we’re not going down a path that’s going to leave us scrambling during integration, trying to figure out how to make this work. We’re going to we’re going to get out ahead of that. Those risky areas, those risky stations, those risky mechanisms, whatever it is, and try to make sure that everything’s as clean as it can be for the project kickoff. Proof Of Principles are a fun part of the automation journey, at least to me they are because you’re trying to do the new thing.

SD: Do you have a best practice or an example where you’ve had the customer come in and get really involved in that Proof Of Principle so that they’re learning right up front about the challenges of their process?

GD: We did. We had one recently. It was actually quite interesting and it was, it was interesting in that it wasn’t necessarily to prove the capability of the mechanism or the process itself, but rather how we could do it faster. So there was this generally accepted restriction, I’ll say I’m trying to use the use very generic terms here, but a generally accepted restriction on our ability to do one particular thing fast. It was insertion of a prefilled syringe into a device. So the thing with a prefilled syringe, it’s got an RNS on it, which is the Rigid Needle Shield. Basically, if you do things too quickly, there’s a chance of compromising sterility of the prefilled syringe, which is critical for life sciences. So, there was this generally accepted oh we can only move so quickly while we engage the RNS into the into the device, I’ll call it. And that was fine. So the customer came over, we ran a POP with them and said, good, we won’t touch that particular element, that particular point of the process. But what we’re going to do is make everything before and after faster. So what that allowed us to do was take them from ten up down to like a four up because we just reduced the waste in the movement and because of the Symphoni RSMR.

SD: That’s very cool. Ah, and you know, that’s  part of in that Proof Of Principle you’re trying to do something that’s never been done. Yea.

GD: Or prove why it why it’s not scary to do it you know it was just this generally accepted restriction and we said why? We’re not changing the critical element, we’re we were going slower we needed to but fast where we could.

SD: Fast is an interesting term right now. There are a variety of reasons that people, providers, operators are looking to process faster. Are you seeing that in your role? You know, recently where there’s an increase in throughput expectations, speed expectations, process expectations?

GD: I’m actually going to say no because the expectation has always been there. It’s always been to maximize the output per square meter of floor space used right, especially in life sciences, because floorspace is expensive. So I’m kind of saying it a bit tongue in cheek. Of course there’s always that trying to drive forward and try to get more output out of a smaller footprint. But of course that’s yeah. What we’re seeing and I think that’s advanced our technology a lot too, right? Like we’re trying to do things a lot faster in a smaller footprint. That’s what led to, you know, us developing OmniTrak that has, you know, led to more innovations with Symphoni. It’s all about trying to, I’ll say, utilize the platform or utilize your, you know, units of productive capacity.

SD: I like that we’re disagreeing here because you’re right, the processing speed really has always been there. And I think the difference between the life sciences industry and a number of others is the automation maturity. And what we’re seeing is other. Precisely. Other industries are now catching up to that maturity level. And then it becomes speed, speed, speed, speed, speed. And recent events have sort of accelerated the need for automation, especially in North America and Europe. So speed, obviously, one of the goals we mentioned right at the top of the discussion to set yourself up for success, you really want to have the right automation goals from the very beginning. I think one of the greatest parts about the role that you have is you get to do this repeatedly with some really large customers. Have you seen some unique ways or a unique approach to the definition of goals for an automation project that’s worked really well for someone.

GD: The best practices or the best underlying practices always remain the same. It’s about getting that, maximizing your throughput, maximizing the MOEE. Those are inherent in any project. In terms of success, though, I know there’s been times where again, it’s those peripheral things that have helped our customers succeed. So it might be a case of introducing AIVs to properly utilize their headcount and service machines. So it’s all part of the overall automation solution, but not necessarily right in the core assembly equipment per say. So there’s another instance of a measure of success where they want to maximize their workforce.

SD: And I think that’s a good segway into exactly what the goals really are of the successful project. Because I think what we see and what’s very common is the implementation of technology can be as broad or as focused as you make it. And that very initial step of defining what’s successful for you is so critical to being able to rally your partner, rally your resources, rally experts to be able to help you.

GD: Precisely. Yeah, we want to come forward with best fit. We don’t want to provide a solution that’s way over your technological capabilities to be able to maintain the equipment. We don’t want to provide you a system that gives you more capacity than you need, right? It’s all about right sizing for the project.

SD: That’s awesome. If I’m a listener, I’m putting together my initial spec or I’m trying to get moving. What do I have to ask you? What do I have to write down as a goal that sets me up for that flexible scenario to take advantage of those flexible platforms?

GD: Great question. I guess really what we’re looking for is what are all the products that you would ideally run on a system? Let’s start there. Let’s look at where can we make sure that we’re completely utilizing all the channels of the units of productive capacity. And I learned that term from Larry Allingham I got to, I got to give credit it that I did not generate that. That was straight from Larry. But it really holds true. It’s making sure that we can utilize that asset because that’s going to help the customers pay back. But that’s where I would start. So it’s what’s your what’s your dream state of being able to put X number of products on there and then we go from there. So it’s okay. You’ve got six products that you’d like to run, but your capacity requirements exceed one chassis. Okay, that’s fine. Let’s look at groupings then. Let’s split that apart and say these two high runners on to one chassis, we do a second chassis that, or rather platform that can run the remaining four, something like that. It’s allowing us to start the conversation of how do we break this apart and really meet your product demands. Then from there we start getting into, you know, the rate and MOEE and the elements of MOEE like what’s your yield requirements? If you’re talking about a life science product, you’re going to want some pretty high yield because your products are expensive. Whereas, you know, in, in certain consumer packaged goods, it’s maybe not as critical. It’s always critical you don’t want to create waste, but there’s just those varying factors I’d say.

SD: Well, it’s always about tradeoffs because  you can drive one area or one goal higher, and that generally impacts another goal.

GD: It may. Yeah, absolutely.

SD: I really liked what you said there about your dream state and in other episodes of the podcast, we’ve talked a lot about starting with the end in mind, and that’s sort of a better or different way of framing that as if you’re starting into your automation path and you’re working with a team inside your organization and you start to work with a partner or experts. Don’t be afraid of talking about what your ideal state is. Talk about your dream, talk about where you want to be. You don’t have to time scale that. You don’t have to be there tomorrow. But I think it’s important that everybody understands the end objective.

GD: Absolutely. Because we can work backwards from there, if it’s schedule or price or something prohibitive at this point, that’s fine. But we can be planning for that future state to make that transitions may be the wrong word, but make that leap to the dream state easier as long as we’re thinking about it early.

SD: And I think that circles right back to that flexibility topic, that adaptability of machines. If we are lining up our dream state and talking about where we want to get to, ideally there are features that can be built in or technologies that can be selected right from the very start that could enable a part of that or all of that right from the start.

GD: 100%. In instances where the customer has a known requirement for a specific product, it’s not unreasonable to think that we would design the machine differently because they’re going to let that product run in perpetuity on that platform, and it’s just going to run. They’ve got no plans for reutilizing that asset in the future. It’s just we know that we’ve got demand and we’re going to all say purpose build a system accordingly.

SD: I think that’s a good place to leave the conversation for today. And Greg, thank you so much for imparting your insight. Your experience on the topic is of elements of the successful automation project. Before we close today, is there any thoughts that you want to leave the listeners with?

GD: Well, first of all, just thanks for having me. It was this was fun. Just looking forward to, you know, discussing any automation needs with you know, with anybody I guess is really the I’m happy to talk about talk about this stuff any time.

SD: I think for anybody who is listening that’s a really interesting way to close today. You’ve got a number of partners who are really just passionate about technology and passionate about automation. If you need help, if you have questions, reach out. They’ll definitely ask you the right questions back. And if you can’t answer them, that’s okay. Then you can go away, do some work and come back. But you know, we learn together. We learn about how to get technology successfully implemented together. It’s always a multiphase or multiparty project and approach. So I think that’s a great way to end today. As somebody who spent a lot of time working with customers at the front end of the automation project, you know, you genuinely look forward to hearing the next problem that somebody has.

SD: Thank you very much for joining us today, Greg.

GD: Thank you, Simon.

SD: And to our listeners, thank you for joining Episode 8 of the podcast series on Enabling Automation. Sincerely hope that this discussion was helpful for you in understanding the industry and how to get started on an automation project and if it was useful for you. I encourage you to join us for Episode 9, which is how to select an automation partner with Scott Cooper. Thank you so much.