Identifying the type of automation you need 

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 identifying the type of automation you need

What we discuss:

• Questions you should answer when determining what type of automation you need
• The importance of understanding the requirements of your project
• Types of automation based on your circumstances and requirements

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: Ryan Tavares, ATS Corporation (Life Sciences)

Ryan Tavares is with ATS Life Sciences located out of Cambridge Ontario. Ryan has been a part of ATS for 15 years in many different roles from engineering and project management to where he is today in the Life Sciences Pre- automation Services segment. The focus of the Pre-automation segment is to engage early customers who are thinking about their path to automation and addressing their missing information and identifying areas of risk.

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

SD: Welcome to Episode ten of the Enabling Automation Podcast. My name is Simon Drexler. I’ll be your host today of the topic we’re tackling in identifying the type of automation that you need inside your business, we’re fortunate to be joined today by our guest, Ryan Tavares. Ryan, can you give the listeners an introduction to yourself?

RT: Hi, Simon. Thanks for having me today. My name is Ryan Tavares. I’m the director of Pre Automation Division based out of Cambridge, Ontario.

SD: In your role, you spend so much time focused on partners and customers and people looking to automate that, you know, your role is really about identifying the type of automation that they need at the current time. Is that a fair characterization?

RT: It is. It is. Thank you. It’s one of many things that we focus on during, you know, early stage engagement with customers. But identifying the type of automation it is equally as important as, you know, finding out if automation is even the right fit. So when we speak about identifying the type of automation, part of it is really understanding what are the needs the customer has today. And some of that could be driven by what phase they are on their roadmap. You know, if the customer is, for example, still doing product and process development, they may be looking for more custom, small scale, very focused automation that addresses a particular need today if their customer is thinking about, you know, maybe creating larger volumes of product that they already have today, but in a higher capacity processes standardized, there may be looking at more standardized type equipment, that is, I’ll say, less custom, but more configurable. That can just be adapted and modified to suit the needs that the customer has. I think the key is to really understand, you know, what is that particular need today and what’s the right type of automation that can address that need. Custom automation is great, but there may not always be an economic case to do that. If there’s something on the market today that does something very similar that can easily be modified to address what the customer is looking for.

SD: And that’s such a good point. And like I would use the analogy, almost like when you’re building a house or when you’re doing a whole reno. There’s just so many options that you sort of need an expert or you need a way to focus in through some of the fog or some of the noise on all of the things you could do and find what you should.  And if I’m a listener, how would you guide somebody through that conversation where you have all of these options available to you? How do you hone in on what should be done?

RT: So I think first is and use the analogy about building a house, which is a great one, I often think about it as in the same way. It’s really about understanding first the customer or the organization and the stakeholders that are involved in the to be manufacturing or what manufacturing’s going to look like in the future. So I think it’s really starts with understanding the requirements that the organization has. So thinking about the stakeholders that are involved, technical requirements that the system must be able to achieve and starting to think about building those requirements or as a basis or a foundation for which you start to look at, then explore the different types of solutions that are available in the market to be able to address those needs. When we say exploring solutions on the market, maybe there are solutions on the market that exist that are more standardized and can be configured, as I mentioned, or it’s a brand new product or process that’s very complex or is unique and does require either custom automation to achieve that or bringing together many different elements of maybe more standardized processes together into something that becomes a more customized end to end manufacturing solution in the end.

SD: You mentioned standards that are available off the shelf sometimes to automate or apply technology to certain applications. What would be the top one or two top of mind for you or for standards?

RT: When we think about standard equipment or a more common equipment, some pieces of are examples of that may be things like packaging equipment, carting equipment, sealing equipment, maybe things like different technologies to perform certain functions like, you know, laser welding, laser marking, leak testing.

SD:  So depending on the industry and depending on what you’re trying to accomplish, it is possible that there is a standard machine, a standard provider that could offer something that does exactly what you need.

RT: I think close to I think that’s the key. I don’t know, you know, if there was if there was always a machine on the market that was available and as a standard piece of equipment, that would be the go to, I think in most cases, there’s always going to be an element of customization or configurability that is likely going to happen because every product is not the same, every process is not the same.

So there are certain things that need to be considered there to make sure that that at the in the end, that that piece of equipment or that manufacturing system does address the specific needs of that specific device.

SD: And you mentioned a really interesting word, which is configured, you know, whether it is a semi-automated solution, a fully automated solution or a completely custom solution, it’s really the amount of configuration option and maybe by extension, customization that’s required to solve the problem. Talking with standards and I’m honestly not sure. Do you see a lot of implementation around collaborative robots in your world?

RT: I know that’s a standard that’s really come into the automation world very rapidly over the last several years. And we start to see that as a standard technology for efficiency gains. Is that something that you’ve seen a lot of?

RT: Well, I’d say that what we’re seeing is we’re starting to see and hear and talk about collaborative robots a lot more frequently. And I think that where we’re starting to see those types of conversations happening is less in the, of course, the high volume automation, but more in the earlier stages, like the R&D or pilot line or low volume programs where there’s still a lot of dependencies on operators for completing particular process steps, but also looking at how to incorporate robots or robots into an automated system that can also be interactive with a human or an operator to be able to still provide the operator input and judgment where it’s necessary, but also to allow it to be assisted by a robot where those particular process steps can be characterized and codified into something that’s repetitive for a technology to be able to accomplish.

SD: And it’s certainly one of those enabling standards or enabling pieces of technology that give you that semi-automated solution. You can automate some of it fairly easy to configure to your application, but would certainly stop short of a fully automated or custom solution.

RT: That’s right. It also goes to say, though, that there are cases where collaborative type environments can also be paired with higher volume automation, elements of the same system. So there may be portions of equipment of an assembly line that have equipment that are collaborative or require a lot of operators to perform certain functions because of the nature of that particular process that needs to happen. Higher volume automation, either downstream or upstream, may just be offset with a larger number of operators in that particular area. Again, assisted with robots or robots to be able to achieve those particular steps as needed. But again, that operator based system and being paired up with higher volume automation in upstream or downstream areas.

SD: And I think that’s a really key point for this dialog rate is when you when you have a facility or you have an operation, it’s never one or the other. Everything doesn’t have to be fully custom, everything doesn’t have to be semi-automated, everything doesn’t have to be manual. You can actually combine the best approach by sell or by process or by step or by area or even by product inside of an operation. It doesn’t have to be one or the other. Fair?

RT: That’s absolutely right. And there are there are systems out there that, you know, that exist that that can do both. Right. They have the flexibility of being able to allow operators to interact with a product that’s being processed in real time to perform certain functions. And then transition to and from fully automated higher speed processes at the same time.

SD: So as a listener today, I’m trying to identify the type of automation that I need. How do you draw the lines between keep it manual semi-automated solution, fully automated solution, and then custom solution? Like, are there easy frameworks to know when to apply each one?

RT: That’s so that’s a that’s a great question, Simon. I think what we see is every case is uniquely different in its own every organization, every product, every process has its own unique entities. There are some similarities, of course, that we see when you’re dealing with particular industries or processing capabilities of equipment. But at the end of the day, I think the determination of what type of automation is the right fit, it really comes down to a deep assessment from the right technical team to really look at things on a step by step basis, to really say, you know, is this something that is the right fit for automation, either at the macro level, at the full system and or are particular steps number one from that that addresses kind of the technical need. And then the other part is, is this something that needs to be designed custom for this application or are there things on the market already that can be leveraged? So I think that type of an assessment is important because, you know, if that’s not done, you could experience the case of designing everything from scratch for the first time where there may not be a whole lot of economical benefit to doing that. You may have a really great custom machine that does something specifically for you, but it could cost a whole lot of money. The other part is, you know, looking at those individual areas where you could leverage existing technologies that are on the market today and bring those things together as a whole to form a system that ultimately is better off from an economic perspective. And you’re also probably going to get a more reliable process because you’re incorporating things that are well understood now already established in the market today.

SD: So to our listeners, I was trying for a yes and an easy framework, but the definitive answer is no. There’s no easy answer to that one. And it is the truth. It’s every situation is different. Every application is different. If you could take standard approaches and apply them to every situation, they would already exist. And unfortunately they don’t. But there are common approaches which Ryan just walked through to identify and go through the evaluation of the options that you have to accomplish your need. So when you’re looking at a line and we’re trying to identify how we automate it, what guidance would you provide to somebody for where they draw the line for needing automation versus not?

RT: So I think it’s twofold. The first is, is it even technically feasible, right? I mean, it does. Can it be achieved in most cases? That answer could be a yes. The second part is, is it economically viable to actually do that? In other words, are you better off to have automation or are you better off to look at an alternative to automation, which could likely be an operator assembly process in lieu of? So I think those are the two key things that come into that assessment.

SD: Why don’t we dive further into both? Because I think those are both really important. You know, I’m looking at doing anything with technology. How would I determine if it’s technically feasible? What steps would I go through.

RT: From a technical feasibility perspective I think the first is to really understand what the objectives are technically. So if you’re assembling a product and it’s got four steps, what are those particular steps? Really defining and codifying, characterizing that process step by step along the way, understanding any particulars around what it means to bring those pieces together for that particular component from an assembly perspective and from a quality perspective. So how do you determine what product you would determine as a good or acceptable product versus one you would determine as a as a reject or an unacceptable product? Once that’s understood, then looking for technical solutions now to address each one of those individual process steps along the way. And when I say process, I mean the act of bringing things together, assembling or testing or doing online evaluations of the product quality and real time things that can be done there. Or there may be some obvious or easier path forward just from experiential perspective that it makes sense to do certain things in certain areas and other areas that may be a little bit less understood or well-defined. Things like feasibility studies or proof of principles may be good vehicles to use to be able to then dove deeper and assess the technical feasibility of being able to achieve something. So those types of exercises, you know, combination of experience, you know, evaluation about what’s on the market, working with suppliers and vendors with particular processing need, in particular processing areas along with feasibility studies and proof of principles. Usually, you know, are a couple of things that can provide a good, well-rounded picture of, you know, how risky is a particular sheen or price is going to be to automate in whole?

SD: Yeah, it’s a great and complete answer. I have nothing to add there. And so then if we go down the other path, then, you know, I want to determine if it’s economically viable. So I determined, yes, I can technically do that. How do I determine if I actually should?

RT: An approach that is common there to be taken as first of all, understand the base case? What would you do if you didn’t if you weren’t going to do automation, if automation is the only option? Well, I think then then the question is answer there. But it’s likely the case that there is an alternative that may be, you know, multiple operators doing things by hand, assembling testing by hand. So I understand that base case is key. And then looking at the alternative from an automation perspective is what is the investment or what does the investment look like to get you into automation, thinking more about the economics, it’s, it’s taking that technical understanding and the technical understanding of the technical need and then starting to, you know, do a very detailed assessment of all the cost drivers and effectively building up, you know, and understanding what that equipment’s going to cost you to actually purchase upfront everything from, you know, the capital equipment, expenditure, validation, everything. That’s all the activities that are going to happen through the validation phase before and up to getting into production and making salable product as well as what are all of your ongoing operating costs or it cost to maintain and own that asset over its lifecycle. So understanding those two use cases, the case of automation versus the case of I’ll call it status quo or the alternative will really help to understand or define, you know, the economics benefit or not. On the case to automation.

SD: I have never had anybody frame it out for me like that before. I thank you, and appreciate that and it’ll help me in my own work. As I invest in technology, I’ve always done it a slightly different way and your way is better. As somebody who would then need to approve the economic viability, you know, you’re looking at the difference between the base case and the technology implementation. As we went back to the beginning of the conversation, we talked about needs and wants and automation needs and wants. Do you have any advice or best practices for someone who’s looking at the implementation to define the line between something that’s needed in something that’s wanted for the implementation of technology?

RT: That’s it’s a good question. And I think from my perspective and from what I see often is, is drawing the line is really comes down to what’s critical to being to importance or critical to quality. And the reason I say quality is because ultimately we’re thinking about things from even particularly in the life sciences space, what’s, what’s the patient experience and what does it mean for a patient? How does each element or each requirement align to or influence the quality of that product, leaving the end of the line? What I mean by that is if requirements are on the edge or on the verge of being maybe a nice to have versus a need to have, I think ultimately understanding does that requirement really drive or influence the quality of that product coming off at the end of the line? And if the answer is no, then I think those could become nice to haves and strong consideration needs to be taken about whether all those needs to haves need to become must haves, because that can then drive up the technical complexity of a piece of equipment which ultimately drives up, you know, potential acquisition cost of that asset.

SD: And you could honestly really apply that to what we talked about before around, you know, do I want full automation, custom automation, semi-automated status quo. It’s the quality of the part coming off the line, going to meet my market demand, meet my customer demand and then you get into a bit of throughput and availability or planning. But you know, largely it really does come down to that for technology implementation.

RT: Yeah, there are I mean, as you mentioned, there’s other factors that to consider as well.

I think I think, you know, particularly in the life sciences industry, I mean, quality is very, very, very important. But there are other factors to consider. You know, one is obviously the availability, as you mentioned, and that’s something that you consider when you’re doing an assessment of the base case versus an automation case,  is what additional availability will that equipment provide you with?  What are the yield improvements? Because the yield is going to reduce your waste, which ultimately reduces the cost of cost of goods on a per unit basis. So all those factors should be considered as part of the automated automation assessment to really understand, you know, holistically how does automation touch in all those different areas and how does it affect not just the upfront cost and or the return on investment, but how does it look in the long run in terms of, you know, contributing or reducing my cost of goods sold?

SD: I’m really happy that we circle back to availability. And I think one of the big reasons we’re doing this podcast series in general and one of the reasons we want to be enablers to those getting into the their automation journey is we’re just seeing new demand because of the lack of availability of resources to support business objectives. It’s a good thing when we’re starting to get started in the automation journey, when we’re starting to talk about different technical solutions to recognize that there are businesses out there, there are cases and applications where technology is really the only option these days.

SD: Ryan, thank you very much for joining us today for Episode ten in identifying the type of automation that we need. Before we close out for this session today, is there anything that you’d like to leave our listeners with?

RT: Thank you. Simon. So I think to leave everybody, our listeners here with a kind of a closing thought, I think what I would say, you know, what I think about is when I think about identifying the right type of automation is really understand where you are in that journey. You know, if you’re in the R&D phase, product development, if you’re looking at, you know, doing a lot qualifications, low volume, high volume and really understand what that automation, what the purpose of it is and what it’s going to intended to resolve. And from that, really looking at working with your team or a team of experts that can really help you understand what your needs are. The problem you’re trying to address today and tie that to what’s available on the market and you know, to what extent you can leverage existing capabilities or what extent you need to look at, you know, developing custom solutions.

SD: Thank you so much, Ryan, for joining us today.

RT: Thank you, Simon.

SD: And to the listeners, thank you very much for joining us on the Enabling Automation Podcast. Everyone here sincerely hopes that this has been informative and enabling for you as you evaluate getting started or furthering your automation journey. I would be remiss if I didn’t thank the team behind the podcast. Thank you all so much for making this a reality. And for those listening, if you do find that this was valuable to us, please follow our YouTube channel and we’ll have a second season shortly. Thank you so much.