Reducing risk in the automation process

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 fifth episode of season 4, host Simon Drexler is joined by Ryan Babel to discuss Reducing risk in the automation process.

What we discuss:

• What makes vision a critical aspect of an automation project?
• Risk management tools
• How does new technology impact risk reduction? Or is it causing more risk?
• How do you look at improving your process to identify and mitigate risk over time?

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 Babel, ATS Corporation (ATS Life Sciences)

Ryan is the Director of Systems Design for our Cambridge and Munich Life Science Systems divisions. He started his career over 12 years ago, right out of grad school working on on front lines for five years. He then worked in applications engineering for two years and before leading the growth of systems design engineering team.

——Full Transcript of Enabling Automation: S3, E5——

SD: Welcome to the Enabling Automation Podcast, where we bring experts from across the ATS Corporation to discuss topics that are relevant to those that are using automation within their businesses. I’m your host, Simon Drexler. I’ve been part of the automation industry for more than 17 years in a variety of roles at companies, both big and small. My passion area is really applying technology to issues that exist in companies looking to scale and automation just such a critical portion of that that are trying to scale or manufacturing. And that’s why I’m so happy to be a part of this podcast and be able to hold these discussions for you that are listening.

SD: We’re very fortunate today to be joined by Ryan Babel, who looks after a lot of the risk mitigation process at the front end of the equipment that ATS builds across the life sciences organization. Ryan, can you take a moment and introduce yourself to the listener base?

RB: So Ryan Babel, director of systems design for our Cambridge and Munich Life Science Systems divisions. Started my career over 12 years ago, right out of grad school and working on the front lines for five years. I had an amazing opportunity to dabble in applications engineering for two years, which was a great experience working with customers directly, working with our sales team directly, and then ultimately coming back to help grow and support the growth of our systems design engineering team to now over 25 strong and growing every day. A little bit about systems design is that it’s a multifaceted role. And one of the and it’s actually quite fitting for today’s podcast topic. One of our team’s philosophies can be simplified to find the technical and process risk and make it go away.

SD: You’re after my own heart. I’m a systems design engineer by trade. So I’m excited about this conversation. And I get, amped up about reducing risk as well. And I think the big reason for that is custom automation is inherently risky. You’re doing something for the first time or it wouldn’t be custom. And when you’re doing something for the first time, risk always exists. So it’s interesting that the mantra of the group is find the technical or process risk and mitigate it, because it does. It’s always there. And so where would you recommend to those listening. How do they start their discussion on mitigating risk in the technology that they’re trying to apply?

RB: I see this a lot. Where to start can be overwhelming, but you can’t start mitigating risk until you identify what the risks even are. Our team’s mission statement is built around this philosophy. and in order to anticipate, identify, then mitigate. Right. You can’t mitigate until you identify what the risk is. We start by understanding and defining requirements. This is the most critical key to upfront risk management. We kind of have a slogan on our website. Direction is more important than speed or you’ll end up nowhere fast. Getting back to your question where can our customers start? Create a framework of objectives. And it sounds simple, but write it down. That can be the hardest step, right? That’ll start the foundation of eventually, user requirements specification, functional and critical requirements, gaps and missing information is okay, and it’s expected. But start by writing things down. What we specialize in is bridging the gap between those unknowns to document clear requirements.

SD: And then once you have clear requirements, you can understand where there are gaps in information or something that may be outside of what’s been done before.

RB: Yes. And we have many tools. Probably the most important tool in our arsenal is the risk heat map. It comes by a various different names, but by having clear requirements that are written down, then we can identify what’s green, what’s yellow, what’s red. There are then a sandbox of tools and strategies that we have to move those items along the path to go green and mitigate risks. But we don’t just deploy tools for the sake of deploying tools. What are the risks? There’s a tool for the risk. We don’t take a chainsaw to go cut a toothpick, right. We’re going to use the right tool for the job. Risk mitigation tools that we deploy. And there’s many specification development. We just talked about that. Proof of Principles, POPs, DOEs, Design of Experiments. It could be third party testing. Engineering analyzes, right, behind a desk crunching numbers, on-site assessments. Let’s go see it with our eyes. Let’s go feel the parts. Put them together. Talk to the operators, doing complex simulations or simple simulations. Right. There’s a lot of software tools that exist now to also mitigate risk depending on what we’re trying to achieve on the path to go green. Right. And it can even start even earlier in the journey with a product designed for automation and, you know, potentially even product redesign. Right. If we’re at that stage or if our customers are at that stage.

SD:  So there’s a lot of different tools and a lot of different approaches. My ears perked up when you said a risk heatmap. How would you walk somebody through how you create a risk heatmap.

RB: The inputs to the risk heatmap are generated by ultimately our customers requirements. Right. What are we trying to achieve or trying to you know put an auto injector together. We’re trying to you know I have a new I have a new product. I’m trying to bring it to market. We have to dispense a certain amount of adhesive. We have to cure it. I’m not even really sure where to start, but I know I have to dispense an adhesive, and I know I need to cure it. And so that can be as simple as, you know, what Sometimes that’s all the information we have. Sometimes it’s we know exactly the parameters we need to use. And so the path to go green is very simple because we’re going to use this volume of adhesive. We’re going to use 385 nanometers to cure it for two seconds. We’re going to use this temperature. And it’s going to pass because it’s a mature, proven process. So I guess that is the foundation for starting a risk heat map. And then we look at the gaps together and then we prioritize how we’re going to start mitigating and closing some things out.

SD: Is a way to characterize the gaps, your ability to write it down, because it may be as straightforward as the example that you just said. You can write down in very specific terms what the process is, but there’s going to be other times where that’s not the case. Is the ability to write down the process in detail a proxy for the risk that exists.

RB: Yeah, I would say yes. If we can’t write it down, then it’s going to be very difficult to execute and deliver to know what the specifications are. Right? Our ultimate, you know, our end goal of writing something down isn’t to just write it down. It’s to achieve performance to spec, to make good parts, to automate a process. Right? If we can’t write things down, it’s going to be very difficult to know that you’ve achieved your goal and to know when to stop because you don’t have a clear finish line, right? So yes, absolutely. Writing it down is important. There are numerous ways to go about extracting the information to write something down.

SD: Inside of my team. It’s kind of simple, but I always talk about how writing it down makes it real, and it’s not even so much in the technical specifications. It might be an idea that you have or a business plan, but as soon as you write it down and have to put it into words and show it to various stakeholders, it becomes real. And it takes something from conversational world that might be perceived in a variety of different ways and makes it specific. And I think that’s part of what you’re after with, the risk keep map is write it down, make it specific. It’s if it’s specific. Now we know if we understand it or not.

RB: Yes. And then we can prioritize because some things we might find urgent and there could be a reason to accelerate things and start building and start pulling ahead a proof of principle, opportunity. Or we can delay because it’s a yellow risk and we have confidence that we can characterize parameters during the integration phase. We’ll carve out some time to do that without having to spend money and time and effort to duplicate that effort if it’s unnecessary. Yeah.

SD: One of my favorite things that we do inside of building custom automation is proof of principles. Identify a risk do a proof of principle. For those that haven’t done one before, could you just describe the process and maybe give an example of an interesting one we’ve done in the recent history?

RB:  Oh yeah, our team is doing proof of principles multiple times a week, it seems. So again, a proof of principle. A POP is one tool in the sandbox to mitigate risk. There’s typically three types of POPs that we’ll execute with different reasons. So there could be a proof of concept. Can we perform the operation at least once? Is it feasible? Proof of reliability. Can we perform the operation for a significant period of time? What’s the capability? Process characterization. It’s number three, right. What are the limitations to the defined process? What are the parameters? We know we need to heat seal a piece of foil to a plastic blister. What are the parameters? Is it 220 degrees? Is it 150 degrees? Is it plus or minus one degree plus or minus ten degrees? What’s the force? What’s the time? Right. What are the parameters. Right. To be able to then define and document what those are. Because then we’ll know when we automate in the future we will have that figured out. And it doesn’t become a science experiment at the expense of right of costly production time to figure it out, we can pull that ahead.

SD: It’s a common theme across our Enabling Automation podcast, especially when we’re talking about automation. It’s really about being able to understand the process and the characteristics before you apply automation. Because if you try to automate a problem, you’re just going to get a faster, more expensive problem.

RB: Yes, it’s always the right thing to do is to, you know, the earlier you can mitigate a risk in the automation project cycle, the less impactful it will typically be because you can catch it before it’s validated.

SD: Absolutely. Right. So we’ll stick on the POP tool. And I understand only one tool in the toolbox. Do you have a favorite proof of principle. Maybe being, the majority of the department has, worked in research in university and doing, different thesis work. And I think being a little bit of, science experiment. Right. Is something feasible? Will this even work? I’m going to push my creativity to the limit. Right. Let’s say tribal knowledge tells me to use a vacuum pick in place. But I want to see is this feasible and can I use a magnetic embedded gripper instead? Right. Those are my favorite type. That’s what I see excite the team the most. Right. Is I have an idea to mitigate this risk. Let me try something. Don’t underestimate the value in trying something quickly and learning. Even if it doesn’t work out as opposed to guessing, the benefits can greatly outweigh the indecision or the fear of getting something wrong and working behind a desk or behind a screen to ensure that it doesn’t go wrong. Right? Sometimes, trying something quickly with a magnet or going to the hardware store and buying a heat gun can quickly confirm or reassure that you’re on the right track and then we can elaborate on. And that’s when the magic happens. That’s when innovation comes into play. That’s when solving problems, and mitigating risks can also differentiate a solution and empower our customers to have, something that isn’t just an innovative solution for the sake of being innovative, but it’s an elegant solution that’s really drives value.

SD: That’s a good example of applying new technology. And I was going to ask you if the integration of new technology, because innovation is happening so rapidly in our space, is that helping the idea of risk reduction in automation, or is it actually causing more risk in the work that we do?

RB: Yeah, adoption of new technology to mitigate a known technical risk can create some questions. Let’s say, around the introduction of a new unknown risk. And my response to that would be to be curious, not intimidated. And now what do we do? Define a test plan. Execute. Collect data. Words talk, data screams. If you have the data to show that a new technology will help that what’s going to drive the adoption because the team is going to see that. Holy smokes, this new 3D sensor, this new technology that I was previously magnets, magnetic grippers instead of, you know, traditional vacuum grippers. When the team sees the data from a clear test plan that also defines what your goals are, what is your specification? What are you trying to achieve? How do you know when you’ve achieved it? When you have that test plan, which is the foundation of a POP test plan, what are my goals? Let’s execute. Let’s generate a report. Is there a residual risk? Are we green? Are we still red? Having the team find the value in it will be so much more effective than just mandating the use of new technology from up high to say, we’re going to use new technology, embrace it. That will be less productive than you think. I would say there’s a balance. Don’t be intimidated. Be curious and try it.

SD: Try it, design it, analyze it.

RB: So that’s exciting. It’s easy to say the other thing. And this is a part of the systems design kind of fundamental mentality, is we don’t just shoot from the hip with a shotgun, right? We’re precise. We aim.

SD: Somewhat staying on the theme of new technology, one of the easiest ways to reduce the risk is to pull from past projects to pull from what you know. Do you find that that’s an effective risk mitigation strategy in the custom automation world, when you’re always trying to do something new?

RB: There’s a balance to that too, right? I will take advantage of the tribal knowledge that exists around me every day. My own past experiences, relying on the network of your peers, their experiences. You can have some blind spots if you only limit your solution to tribal knowledge and past experiences. And I feel like this is what we just kind of, explained with the creativity.  Right, with it. Within reason. There’s got to be a we need to know what our objectives are. So we apply creative thinking. That’s the balance, right? We need to be grounded in our past experiences, but not afraid to, to deviate from them.

SD: The reason I’m asking is because with some, some insider knowledge, Ryan, very respectful of the work that you do inside of your team. And I feel like you balance that line very well where you give the team freedom to explore new technologies while being very grounded in the reality of what we’ve done in the past, as well as the reality of the data that we have. And I was wondering if you’d just share a little bit of your best practice, or your thinking around how you how you structure your team to walk that line so well?

RB: I think what it helps with our team is by nature of our role. We work with customers, we see new problems. We see the challenges that they’re facing, right? We work with applications. We work with our account managers, our sales team. Right. So we’re on the forefront in helping be creative with new solutions. We also have the practical reality of the experience of now executing a project right. The systems designer enables the continuity between that proposal phase and then a project execution phase. So those critical requirements, those, you know, if we do a POP, for example, a risk mitigation simulation, a vendor trial, an analysis with our customers on the front end and we come up with an attractive solution. That same systems engineer would then be embedded in the project team. So there’s that continuity from, right, almost like a front end of the business project management team to the operational project, you know, execution team. And the third new exciting part of our role is in the innovation space, right, where we have the resources and the engineers playground to go down and try things with the resources that are available. And we have the opportunities to work with others in the innovation department to rapidly try new things without the traditional constraints that exist. When executing a project. Right. We want to go buy this. We want to do this quickly. Let’s try it. And we can do that in a few days sometimes. Sometimes in the same day. Sometimes it’s a little more elaborate. Yeah, it might take a few weeks, but we’ll get there.

SD:  And that’s all in the vein of learning and trying to build our knowledge base and trying to build more past projects to pull from and mitigate risk.

RB: Yes. Right. You can you can tell the difference between someone who’s walked the walk and someone who’s then talking the talk. And the exciting part of why I love systems design is we can walk the walk all the way to the finish line with our customers, see what it’s like getting to the final gate of a successful customer SAT and their ramp up through validation, and now they’re deploying the automation and selling good product and the journey that it took. And sometimes it might be six months, sometimes it might be three years where it started with defining requirements, understanding what the needs are. Doing some proof of principles, some risk mitigation activities, and seeing how that actually ends up in reality, as opposed to, you know, we don’t just throw it over the wall and then we’re on to the next one.

SD: Well, absolutely. And I think for those that are listening, looking to reduce the risk in the automation process, just even what you’re speaking about is accountability from beginning to end around the detailed requirements of what the system needs to do through execution, right to the very delivery of that system.

RB: The self accountability is very high, right? We set up and this is where we are transparent with our customers and why we’re doing what we’re doing, right. Risk mitigation activities. They’re in everyone’s best interest, our customers best interest. How do we mitigate risk? Yes. Right. They can be used for many reasons. Right. Gain understanding, mitigating technical risks, establishing process capabilities, confirming scope, budget and providing contractual protection on both ends. Right. It’s not just a get out of jail free card. It’s a why would we overcomplicate a solution and, you know, burden a customer with complex tooling and solutions that might not be necessary if we prove it out and we can make things a lot simpler and still achieve the requirements that we’ve defined together. I think that is why many of our customers are now actually coming to us, and they’re proposing POPs, they are like, “Here’s our assessment of the critical or process technical risks. We’ve seen what you’ve done in the past with mitigating them and going through a pre-engineering phase, a POP phase. Let’s do that again, because it was a heck of a lot of fun, and we were very successful with those results and how it impacts the ultimate mission of a custom automation assembly line.”

SD: Oh, it’s exciting that the conversation is flipping. You’ve been at this for a while, Ryan, doing this for a number of years. There’s new technologies that are coming into the world, not just for applying to automation, but you mentioned software tools and the advancement of software tools as a risk mitigation. I know we’re using our 3D printing. Are there specific advancements over the course of the last couple of years that have made a change in the work that you do?

RB: Certainly. I would, I would also… So, 3D printing is a good one. Software the advancement in the tools that we now have at our disposal, and I would say the aptitude and the capability of the new candidates that we’re lucky enough to have join our team, their drive and eagerness to independently learn new technology. And many of them have 3D printers at home and they 3D print. I’ve seen some, you know, we have 3D printers in our lab. We have 3D printers at ATS. Seems like a third of our department has their own hobby, 3D printers, right? They’re software developers. They can create apps. These tools are enabling us to go even faster. We can try things and not be afraid to try something because we can have an idea in our in our mind. We can design it quickly. I’ve seen this happen. The next day someone will come in with the 3D printed grippers that we were talking about on a whiteboard the day before, and now we are trying it. And I’ve seen one success story where those 3D printed gripper fingers that were made at home by somebody for fun. We ended up using that same design in production for our customer on multiple lines. So that, to me is the power of a tool that you can imagine and create overnight as opposed to what it used to be. Even, you know, when I started over a decade ago, you’d have to have a drawings, you’d have to send it out for fabrication or to the machine shop. And right, this would be a multi-day activity.

SD: It’s an incredible change, to be honest, to see the team be able to work like that and work that rapidly with the advancements in technology and just the tools that are at their disposal is pretty amazing.

RB: Yes. And the exciting thing is there’s new tools every year. It seems like there’s new tools. We’re building on them, and that’s also what keeps the motivation, keeps I would say the energy of the team is looking for those new tools to be even more valuable. And this kind of get gets back to the, you know, the data we don’t just use here’s a new piece of software because it’s flashy. It’s the team finds value in it when they find value in it, and then our customers find value in it, and it gets celebrated by their peers and it gets acknowledged by our customers. That’s what creates the pull for the use of that new simulation software. Rapid prototyping by more and more people. Right. As opposed to I just purchased a 3D printer for the department. Thou shalt use it once a week, right? And find a reason to use it. Right. That doesn’t work nearly as effectively.

SD: And you mentioned a number of different tools at the start of our conversation. POP, DOE, analysis assessment. There’s so many different ways that you can look at risk. Inside of your department, how do you look at improving your process to identify and mitigate risk over time?

SB: Maybe this comes back to the savviness of our team. You know, there’s so many different projects on our team, keeps growing, and building databases can be a blessing and a curse, let’s say, because now you’re burdened by it. You know, a lot of noise that might be unnecessary. But by listening to the team and what makes them effective, if it means better templates, we have a risk heatmap template, for example, concept technical risk assessment that continues to evolve, you know, month to month. Every time we use it, we keep making it better. So it’s almost like an element of continuous improvement driven from the team. And they help each other out. Sometimes our best ideas are from engineers working on something for the first time because they’re not jaded by the way things always have been. And like, okay, I see this template, I see this, but you know, it would be great if we added a column in here to a identify vendor testing or, initial safety risk assessment, you know, so we’re, we’re catching things a little bit sooner and driving value to some of our internal customers, as well as all of our external customers. They are making the changes without, you know, a reminder from, you know, a team lead or a manager to say, “let’s update the template, let’s make things better, let’s improve our process.” It almost seems like every time someone will go through a template, if they add a comment, that’s the new template that makes it better for the next time that someone’s going to use it. And I think the biggest resource we have is our network. Certainly at ATS, asking, right, you can spend two hours looking, you can spend 30 seconds asking and you’ll find the answer. You know, I would say nine times out of ten just by asking and it’s not a burden to ask, right? I would say same thing with our customers, right? If they’re searching for solutions, they’re searching for ideas. Try it. Ask somebody, you know, go for a tour at, you know, if you if you can get into, neighbor neighboring, automation place that someone’s automating something that has nothing to do with your technology. It could be, you know, a a tour of the Toyota assembly line, you know, just inspire you, right? You’ll learn so much from asking others that have been through it. Going out and gathering information, gathering context.

SD: Ryan, we’re so fortunate to be able to have this conversation. And I like talking to you so much because you’re at the front end of the custom automation journey, where you’re dealing with all the risk, you’re dealing with the hard problems right up front. For those that are listening, a lot of them are looking to do automation for the first time or looking to scale automation fairly significantly. Do you have any closing thoughts or any cautionary tales that you’d like to share with them before we finish up for today.

RB: I would say don’t be paralyzed by risk, understand it, be okay with it, try it and iterate. Be curious. Trying something now and learning through failure is far more valuable than indecision or endless analysis behind the screen.

SD: I couldn’t agree with you more. Ryan, thank you so much for joining us today on the Enabling Automation Podcast. I really appreciate your insights, sharing your experience in reducing risk in the automation process. It’s there, but we can deal with it and we can deal with it effectively.

RB: Thanks, Simon. hopefully I’ll be back for season four.

SD: Great time having you. Always a great conversation. To those that are listening, thank you so much for joining us, as always. so this was our fifth episode, reducing risk in the automation process. We’ll be back in a month with our sixth episode, which is automation Roadmaps and the Smart Factory integrations. And we’ll be talking with Roland Echter. Thank you again for joining us. And I look forward to chatting again next time.