What resources are required for automation?

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 resources required for automation.

What we discuss:

• What resources are required for automation
• How to determine if your product is right for automation
• The team needed for implementing automation and alignment of resources

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: Adam Pringle, ATS Corporation (Industrial Automation)

Adam Pringle is the Director of Project Management at ATS Industrial Automation in Cambridge. Adam has been with ATS for 19 years and has been in the automation industry for about 20 years.

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

SD: Welcome to the Enabling Automation podcast, where we tackle a topic each month to empower our listeners to implement and support automation projects within their organization. I’ll be your host, Simon Drexler. I’ve been a member of the automation industry for approximately 15 years in a variety of roles spanning from applications engineering through business leadership. My current role at ATS Automation, I’m the General Manager of the Products Group, looking after the innovation and development of core enabling technologies for our organization. We’re very fortunate today to have Adam Pringle join us for the topic of the resources required to implement automation. Adam could give our listeners a brief introduction to yourself.

AP: Sure. Thanks, Simon. Like Simon said, I’m Adam Pringle, I’m the Director of Project Management at ATS Industrial Automation in Cambridge. I’ve been with ATS for 19 years and in the automation industry for about 20, working for- starting with electrical design and working up to my current role as Director of Project Management.

SD: That’s great and just the absolute best background to be able to have this conversation with you today, Adam. I’m quite excited. So just to get started, you know, let’s jump right into it. What resources are required for automation?

AP: It somewhat depends on the customer, but the first step that they need is they need a product that can be assembled with automation. So that involves a lot of, I would say, shared discussions with an automation provider looking at their product details, how the product’s delivered and what the process to assemble that product is. That’s sort of step one. Step two is they need a business case to show that it’s going to work for them.

SD: And I think a big portion of the podcast and what we’re trying to provide our listeners is some guidance in those two phases. And you know, me having known you for quite some time and knowing your background, that Phase One really aligns to that application’s engineering role at an automation provider. Can you provide a little bit of guidance to the things that our listeners should look for and the people they might want to pull into the discussion to evaluate whether or not their product is right for automation?

AP: Sure, it was, I think, 15 years in the application’s role at ATS. I think I probably have, I’d say, an ability to do that without even thinking about it, but I think the first step is probably to schedule a meeting face to face, Teams, Zoom, whatever, and just talk through your product, show the show the processes, look at how it’s assembled, share drawings. But ultimately, what you’re looking for is, you know, products that are fairly stable, fairly well-defined and have features that allow for, you know, I would say, repeatable gripping, repeatable fixturing. You know, if it needs vision, they need to you need to have ray contrast. A lot of these things we can work around, you know, a few here and there, but, you know, some products just aren’t really easy to automate, you know, like a factory assembly automation perspective.

SD: And one of the analogies I use often and I think one of the reasons I was so excited about doing this podcast in particular is we have so many guests that we get that we have on this series that have been in the industry for so long that it comes so naturally. And the analogy is almost like when you go to a carnival or something like that and somebody draws your character and they can draw your character and, you know, 10 minutes and, you know, cost $50 or $100. And it’s not like you’re paying for their time. It’s that you’re paying for their experience to have gotten so good at drawing that they can do something that quickly. And I think that you’re that person and your response is very much that, you know, very naturally coming across, you know, look at your product, make sure that it has repeatable gripping, you know, make sure there’s not too much uniqueness to it. Can we dive one level further and just say, you know what, what does repeatable mean to you?

AP: I think from an automation perspective, it means that it generally needs to be a rigid part. It needs to have features that are, you know, either parallel or round or something like that that would allow for a robot or a pick and place or something like that with a machine gripper to grab the part and put it into a fixture or nest or assemble it to another component that allows the, you know, the following processes or the preceding processes to align to whatever build tolerance you’re looking for, whether that’s microns or, you know, thousands of an inch or a millimeter. And it does very much depend on those processes and the tolerances that your part is designed to be assembled with.

SD: Thank you very much. And then the other part of your response was, there’s always something custom, you know, no matter what customer, no matter what phase of the process you’re at, no matter what it is that you’re trying to do, there’s always something unique about that process, when we’re trying to implement automation, how do you identify those unique pieces? And then what would our listeners do to think about how to enable the uniqueness, with automation and automation technology?

AP: I would say there’s probably two different levels of uniqueness. There’s one that’s not commercially available. So like we could buy a, a gripper actuator from like a Festo, SMC etc. in that piece is not unique, it’s commercially available. But the, the gripper fingers that go on that would be unique and their unique for basically every application. But the level of detail in most cases that’s different from other applications is usually fairly minor, but sometimes there’s a unique shape, a really tight tolerance or something like that, that is really different than anything sort of we’ve done before. And that level of uniqueness is different and deserves special attention when we’re going through the process of, you know, coding, designing, building, testing, all those things.

SD: And so then when we’re talking about the resources required for automation and right now we’re living in, I would say, the design for manufacturing phase, there’s sort of those standard parts and more straightforward things to look at. You know, the parallel pieces, the rigidity of the part and things like that. And then there’s the custom part are the resources needed to tackle both of those conversations are they different or are they the same?

AP: They’re probably a little bit different but there’s, I would say, a lot of overlap. When we go through this process with a lot of customers, it usually starts with a mechanical engineer or a project manager or production engineer or something of that sort. Their goal is usually about making a production line for their company. Often times, you know, they get told, this is the part, here’s the drawings. There’s no flexibility. Where we find that we often get to with some companies is that their part isn’t it does require that sort of detailed level of customization and then it gets some times into a bit of a back and forth with their product designers, hey, if you change this feature, it now becomes less custom or less risky, or you know, sometimes it’s their component providers. If the material comes in a certain tray or comes in this orientation, it changes the way that the product’s presented to the robot or the pick and place and changes how what has to happen to that part to do the next assembly step, whether it’s, you know, rotating it or changing its orientation. Sometimes it’s the cleanliness of the part. There’s all sorts of different elements of how the components are delivered to the line that impact what the assembly line looks like.

SD: You’ve obviously been a part of hundreds, maybe even thousands. It’s at this point in time of these types of conversations, have you seen a pattern of when is it most effective to start this discussion with the resources that that you just mentioned.

AP: Generally as soon as possible. I think the later that these conversations happen, the generally more costly the changes are either because, you know, a mold’s been cast or, you know, something’s been, you know, a component part manufacturer has been signed to a contract with a certain set drawings and now changes are more costly. In general, the earlier these conversations start, the more successful they become in terms of providing a more financially sound business case for automation in the end.

SD: And so when we started this conversation, we, you know, what resources are required for automation, you identified two phases. There’s the applications phase, which is that design for manufacture piece. And then there’s that, that next phase of the actual implementation. And so why don’t we dive into that a little in a little bit more detail? And what resources should our listeners be thinking about to effectively set up that team to implement the automation that’s designed on the other end of this conversation?

AP: That’s a great question. I think it does change a little bit depending on the customer and their, I would say, level of maturity with automation. A company that has automation already generally has some people that I would say have experience in a number of different aspects of automation and can probably fulfill multiple roles. But if you look at it from a sort of role perspective, you know, generally you need somebody from the maintenance side of the, you know, running the equipment, keeping it running. You need someone on the controls side. I would say typically a lot of customers will come with a mechanical engineer, production engineer, and the controls is kind of a black box to them. And so often decisions will get made early in the project that at the end of the project they’ll bring a controls person on who’s confounded by some of the decisions that were made early on. Again, you need a mechanical person that understands the part, depending on the level of processing, if it’s a straightforward assembly, probably not. You don’t need a process engineer, but if you’ve got adhesives or dispensing or curing or any of those types of processes, you need to have somebody who’s fairly adept and knowledgeable on those processes involved. Sometimes that’s outsourced to a supplier or some sort of contract subject matter expert, but sometimes it’s, you know, they have somebody that just spends a lot of time and becomes that subject matter expert themselves.

SD: Understood. And you mentioned something that made me smile. And, you know, it’s people coming on later in a project. And, you know, most often the automation project lifecycle can be fairly long, to potentially several years. And as people come on, they’re confounded (Adam: Yes.) by the decisions that have been made before them and before their arrival. Have you seen a best practice in your past on how to avoid that feeling or that that nature where you know, you’re always going to get new people joining and they might not understand what’s come before them?

AP: I would say, you know, best practices like the best practice would be not having new people, but that’s probably bordering on impossible in most cases, I would say the next thing is, you know, documenting decisions, whether it’s through meeting minutes or some sort of summary on key milestones and when decisions are made, explaining a little bit why they were made as well, often there is a reason and you know, it’s a series of compromises and that just happens to be the compromise that potentially impacts later down the road. Other things that we’ve started using, especially through COVID with people working online, is just recording some of the meetings, either for internal use or with the customer just for later on to go back, you know, revisit a conversation. Sometimes we can change some of those compromises and make a change later on the project. Maybe it costs a little bit upfront, but leads to a better solution in the end.

SD:  I like that one about recording major, major meetings. One of the things that we always suggest is at least try to maintain continuity of leadership through the implementation of a major automation application because they’re at least able to explain some of the Why to the new people coming in. But, you know, hearing a little bit more about how we’re documenting and even, you know, dealing with a pandemic and remote working, recording meetings, better notes, better highlight of major decisions made so that as new people come on, they have almost an onboarding package. Is something that our listeners could certainly plan for as a best practice.

AP: Yea, and I would say most of those are lessons learned the hard way, right? Especially through COVID, some of the projects definitely delayed in duration. There was probably some of our customers had, I would say, more change in their workforce than we would have seen maybe five years ago. So there was a lot more of that churn, I would say, which led to some of those conversations, you know, near the end of a project saying like, why did we do this? Continuity on at least one side is helpful, but ideally continuity on both sides is ideal to be able to say that.

SD: This is going to take us on a bit of a tangent, but it actually makes me remember one of my automation stories is, you know, implementing a significant piece of high speed packaging automation. We got about three quarters of the way through the implementation of the automation or at least the design and build of it. And someone came on that started to evaluate the supply chain that was coming to the automation and identified that the way that we were feeding parts into the system was actually impractical for their vendors, their sub-vendors. Because the decision was made early on without including the people who were actually feeding parts to the line. That led us to, to not scramble but to, you know, make some, some urgent changes to the piece of automation we were building.

AP: And I think, you know, I worked on that project with you and fairly, fairly knowledgeable on what went on there. And I think one of the key things there was a bigger company and bigger companies tend to have a lot of departments and I would say that’s another problem we do see with some of the bigger companies and lots of departments and lots of stakeholders is that oftentimes the project for project efficiency and meetings and approvals, they try to keep the team small and then the other people get sort of brought on later and their voices maybe aren’t heard at the appropriate time to best coordinate with their needs. And I think that, you know, ideally that’s done earlier where it’s identified and, you know, evaluated to meet, you know, whether we’re meeting their needs or not because effectively, you know, they’re internal customers, I would say those types of challenges in one form or another sort of come up fairly regularly.

SD: And you deal with maybe more large companies than I do in my business unit. I’m dealing more with, with smaller companies. And so one of the things that gets more challenging with any initiative, let alone in automation initiative across a large organization, is alignment of resources. Have you seen any of the major partners that you work with do that exceptionally well? Is there something that we can share with our listeners as a as a nugget of advice there?

AP: I would say that there’s been a couple of different things that have proven effective. I think we’ve had some customers with a fairly significant continuity across multiple projects. So we end up almost effectively like a joint project team on both sides where the same people are working together, one project to the next. That’s, I think, proven very effective for both sides in terms of efficiency and just understanding the needs of each other. I would say in some other cases we’ve had assigned resources. So we have a customer currently, pretty big customer has assigned an engineer who’s actually in our building almost every day. It turns out that they aren’t living that far away, so it’s been convenient for them, but that’s allowed them to be sort of a central point of contact to help facilitate conversation on both sides. Because there are so many players and departments and divisions and whatnot involved, it’s sort of a conduit of communication.

SD: And so this has been an interesting discussion because even for me, I wouldn’t have framed it this way coming in. But it’s almost like we should be planning for people to come and go inside of an automation project. If you’re implementing technology, there’s a number of different stakeholders involved, but a best practice would be to keep some level of continuity from start to finish, and maybe depending on the complexity of the project, that that continuity team might look different. But a key best practice is some level of continuity.

AP: I think that yeah, like I would say in most projects we plan for a project team to be on a project the entire time, but and I think most of our customers do as well. But I think one of the things that makes us and our customers successful is, you know, promotion from within and, you know, treating our people fairly. And I think trying to keep someone on a project that, you know, is eligible for a promotion to, you know, a different, different level or a different division or something like that is probably not fair to the employees and probably doesn’t treat the projects well in the end. And so I don’t think you necessarily want to plan for every individual employee to leave the project, but in general know that there’s going to be change.

SD: Interesting. So let’s shift back to something that you said around organizational maturity. What do organizations do if they’re starting at the beginning? You know, they’re immature in the technology implementation. Maybe this is the first piece of automation that they’ve ever implemented. What would you recommend to a listener who sits in an organization like that?

AP: I think the biggest thing for a company like that, and it’s probably hard because I think a lot of those are either growing quickly or in the startup type environment, and they’re generally trying to get a product to market extremely quickly or trying to grow to meet some new contract demand as quickly as possible. But it’s to plan for some inefficiency, and I don’t think it’s necessarily a bad thing, but there’s going to be bumps in the road. Oftentimes where those types of customers, I think, fail, at least in the short term, is they don’t leave any buffer. So they end up making decisions to meet a deadline, whether it’s not having you know, they can’t get their parts in time, running into supply chain delays is a common issue right now, or product change seems fairly inevitable in a lot of market spaces right now. And if they don’t have a little bit of leeway in the back end of their schedule, often what happens is they’ll do an incomplete acceptance test at our factory and the line will get shipped in less than ideal condition and arrives at site and generally there’s still maybe not as many parts as required. So we sort of get through that initial phase. Not everyone’s, I would say happy because it’s not maybe, you know, meeting the requirements that they had set. And then there tends to be a bit of either a bumpy road or a tail down that back end as everyone tries to get it to where it needs to be, which leads to usually costs for both sides.

SD: I really like the way that you phrased that, and it’s about planning for some level of inefficiency. I’ve heard that framed in a number of different ways. And, you know, one would be oftentimes if this is the first or first major implementation of technology, you don’t know what you don’t know is one way. So you’re sort of learning along the way and you should plan to make some poor decisions because you’re learning. But you also want to make space for that learning. If you’re investing in technology, you’re trying to build a new competency inside of your team and you’re saying that you that you can and should plan for that. Is that a fair statement?

AP: Yeah, I think a lot of customers in that space are probably growing their team so they’re either have new people on board or people that are maybe stepping up to some new challenges. I think that leads to either, you know, like you said, failure in some of the decisions or even just inefficient. Some decisions maybe take longer to make. One of the big ones I think we see is the time from first approaching us with, hey, we’ve got this opportunity we want to automate to actually placing a PO for automation equipment tends to take longer than they planned, but their end date doesn’t change, which means that the automation design build test phase ends up getting squeezed. And all the buffer that may be was in that schedule initially or in the planning in the early stages gets eaten up before any work actually gets done. I think that ends up leading to a lot of pain on the back end.

SD: And I think both of us have lived those experiences certainly over the course of our career. Would you have any recommendations for how to avoid that? Is there things that our listeners could do right now, maybe staring down that situation where might be the first time, might be the early time, might be a major implementation. How do we avoid that crunch of time frame or the lack of planning for inefficiencies?

AP: I think some of the things that where we end up seeing that are, you know, it’s at that PO time, it’s a lot of, I would say, wasted time between, you know, the RFQ and the PO, and I think that deadlines often treat it as a soft deadline and maybe it needs to be a little harder, like the start of production deadline. That would probably be a way to, you know, maintain some of that buffer that’s usually built in initially. And then after that it’s just, I think, regular communication, understanding that, you know, week to week there’s probably some variation. But you know, how is the end date looking but committing the people on their side, the parts, the product designers, the customers or the suppliers, the customers, whatever the case may be that many of these sort of intermediate milestones or gates are just as critical as the one at the back end and delayed decisions early, you know, just put more pressure on the back end and more pressure usually is not good.

SD: It’s a great piece of advice. Is there any training or partnerships or organizations that you would recommend that listeners in this type of environment or in this type of evaluation could leverage outside of their organization to get best practices or guidance?

AP: Well, yeah, aside from like a PMP or something like that for project management planning, I would say just talking to one or more automation providers is probably the best example. The front end or sales and applications team are fairly well versed in how a project runs and how to plan for it. And I think that through that conversation, you know, whether it’s coming and visiting, visiting our site or, you know, another automation supplier, we’ve arranged discussions with customers in the past so that, you know, one potential customer talks to a prior customer and sort of builds up a level of confidence and trust that, you know, we know what we’re talking about or the automation provider’s aware of the challenges of doing that. I think that’s probably a good avenue to try to really understand the challenges that lie ahead of them.

SD: You said a word there that’s important to me and especially in the business unit that I’m a part of is trust, you know, find that trusted partner and leverage their experience and that might be different depending on your industry it might be different depending on your stage. But there are people sort of out in the world that have done this before and, you know, find that trusted partner, leverage their experience to put together a plan and then stick to that plan, especially at the front end.

AP: And I think in most projects that I would say, you know, 80% minimum of the project has been done before, if not 95 or 99%. You know, I would say typically most of it isn’t really all that unique. Maybe it’s slightly different, you know, a different cycle time or a different part shape or geometry. But most of the processes have been done to some degree before.

SD: And that’s interesting because when you go to a machine builder or an automation provider, especially one that’s working across industries, you know, the been there, done that catalog that has been built up over years of deploying automation gives you the ability to, to, to say that and say that so confidently, you know, we’ve done it or we done something similar before. Now we’re going to leverage that part of our catalog, our experience, our history and we’re going to put it on this.

AP: And I think through the experience in, in the applications group, like I think my one big takeaway from that whole time was that  while we’re selling automation, we’re at an early stage and it’s hard to visualize necessarily what the final product is going to look like, what we’re really selling is confidence. We’re telling them, you know, essentially that what they’re trying to do, while challenging, while unique to them, isn’t really all that unique. And it is a series of things we’ve done before on different projects, assembled in a unique manner for their product.

SD: And so I think that’s a really interesting piece of advice and a really interesting framing for any listener where this is new to them because it’s new to you, absolutely, there’s some level of uniqueness. But to those that have done this before, we’re pulling references, we’re pulling processes, we’re pulling bits and pieces that have all been done before together into some unique way, still unique, but not as risky as it may be perceived inside of their organization.

AP: And I think that that final sort of leap of faith, if you will, I think, can often be overcome in my experience with, you know, coming and visiting us and looking at what we’re doing on our floor with, you know, some of our other customers today. And seeing many of those same pieces spread across different pieces of equipment, and we’re saying, you know, we picked that robot and we picked that dispense process and we put them together and that’s what we’re offering to you.

SD: Coming back to the topic of today and the resources that are required for the implementation of automation. A lot of our conversation today is, you know, there is there’s a number of different resources required. There’s a plan that could span many months or potentially years. Are there recommendations that you would provide the listener to educate decision makers inside of their organization to be able to allocate the right resources at the right time to a project like this?

AP: It’s a complicated question.

SD:  I know, big question.

AP: I’m not sure if there’s resources that would say that explicitly. Maybe there’s textbooks that somebody has written or, you know, business type books on that. But I would say to probably plan more people than you think you need upfront and for longer durations, not necessarily that the project is going to take longer, but that it might have, you know, you’d probably want to start them a little earlier on the project and you probably want them to be on the back end of the project a little longer and not have some other competing need that’s taking up their time when you’re really trying to finish that project because they just end up with, you know, sacrificing one or two projects at that time.

SD: I was actually hoping that’s how you would answer that question, because that’s what I’ve seen as well, is you want to identify the team that you need and then allocate them as early as possible and then also make sure that they’re not being pulled off or pressured to leave the project before it’s ready. And I think you touched on such a key topic that no matter what the technology implementation is, whether it’s simple or ranging all the way to up to complex, you’re learning something along the way and you should plan to learn there’s going to be some level of inefficiency, but you’re trying to build an organizational capability.

AP: And I think even though we’re talking about automation, we’re talking about robots and whatever, it still is people that make it work, whether it’s our people or the customers people or both, really ultimately through that design phase, through integration, making it work for your product the first time on our floor or when it gets to site, getting it to speed to make good quality products and meet your manufacturing needs. That’s when the customers people need to become the experts on the equipment.

SD: I can’t think of a better way to end our session today than that statement. So, Adam, I just want to thank you so much for joining us today, for sharing your thoughts, your experience, your expertise with our listeners. And thank you to our listeners for joining us today for Episode Seven of our Enabling Automation podcast, where we’re really seeking to share information to help enable you and support you in the implementation of automation at your organization. I would encourage you to join us next time for Episode Eight, which will start to dive into the elements of a successful automation project. Thank you again for joining us today.