Episode Transcript
[00:00:00] Speaker A: Manufacturers are spending millions on digital transformation, but too many mes and industrial software projects still fail.
Ryan Crownover, director of Digital Planet Vertec, thinks it's time to stop treating industrial software like it's special and start treating it like, well, software. This is Control Alt Manufacturing.
Hello, hello, hello, hello everybody. Welcome back to another fine episode of Control Alt Manufacturing Resetting and Rethinking Manufacturing, the podcast that explores the people, technologies and strategies driving the digital transformation of manufacturing.
I, as always, remain. Gary Cohen joining me as always again, Stephanie Neal. How are you, Stephanie?
[00:00:51] Speaker B: I'm good, Gary. Thanks for the introduction. I feel like you've got this great signature intro where you do your hello, hello, hello. Like I have to work on mine.
[00:01:00] Speaker A: Yeah, we need something from you you could juggle at the start of everyone.
[00:01:05] Speaker B: Well, I could. It wouldn't, it wouldn't work out very well.
[00:01:09] Speaker A: Yeah, I gotta tell you, I almost introduced you as the inimitable Stephanie Neal and then I thought it's early in the day and I might flub inimitable, so I'm not going to do it.
But I went, well.
[00:01:22] Speaker B: So wait, I called you charismatic on a post recently.
[00:01:26] Speaker A: So which I very much appreciated. So everybody out there just know that I'm charismatic.
According to Stephanie Neal.
I had a whole idea of what we're going to talk about here at the beginning and then as we're recording this, although it's going to be in the past for our listeners, we had a little issue this week when aws, Amazon Web Services went down for most of a day. I think it was down for about 15 hours. And chaos rippled throughout the Internet and the world, which was kind of an interesting. So yeah, I don't know, Stephanie, how did that impact you? And then let's talk a little bit about how it impacted manufacturing.
[00:02:05] Speaker B: Well, it didn't really impact me. I think a lot of the Snapchat users were really upset about it. They took to TikTok to talk about.
They were so upset about it. But it did get me thinking, if you, if you noticed my 3am Slack message to you, that I was thinking about it and you know, as more manufacturers move their software and their platforms to the cloud, could this have a bigger impact in the future if there is a similar outage like that?
I just feel like this was representative of what could possibly happen in the future and it made me think, do we have to have more resilience built into our industrial software platforms? Because if this were to happen, we're talking, talking about mission critical systems in terms of maybe production won't go down, but we're going to lose all that data.
So the ripple effect is maybe we're not going to have the information that we need to do the predictive analytics that we need in the future. Maybe it's going to have a financial impact on the organization. So that's where my thought process went. I don't know if you had any.
[00:03:25] Speaker A: No, it was a similar thing. I mean, I think it was a reminder of how much we now rely on the cloud. I don't think we think about it that much. And we tend to think the cloud is bulletproof. And clearly that is not the case. I mean, everything from I was trying to edit a podcast that day and our podcast platform runs on aws. And so it was kind of a messy day. But I think a lot of, as you said, manufacturing's digital transformation is pretty tethered to the cloud right now. And so, you know, if a production line went down 10 years ago, you call maintenance and have somebody come in and fix it. Today you might have to call your cloud provider, which obviously the cloud allows us to do tons of different things. Scalable storage, analytics, lower it costs, real time collaboration.
But so which is great progress. But there's also a ton of risk built in there because when the cloud wobbles like it did for us this week, for our listeners, probably a couple months ago, now you realize how interconnected this stuff is. So, you know, I think the question isn't, should manufacturers be using the cloud? Because that genie is well out of the bottle. We already are using the cloud. So it comes back to what you said, Stephanie, which is how do we design resilience into what we are putting onto the cloud so when something like that goes down, we aren't losing debt.
[00:04:58] Speaker B: Mm.
One more quick thought before we introduce Ryan.
You know, a lot of, you know, the AI and stuff is happening on the plant floor and maybe it's tied to the cloud, maybe it isn't. But, you know, one of the concerns also is it's a wonderful tool to help people as they're maybe recovering from an outage. But we're also, you know, creating this whole culture that is AI dependent.
And if you can't ask AI to solve the problem, are we going to have the skill set in house where the operators and the maintenance people know how to do this stuff and they're not trying to turn to their cloud provider or their OEM or their machine builder or their agent on their AI agent on their phone. So that's A conversation for another day, but goes back to the reason I'm so afraid of AI.
[00:05:52] Speaker A: I was having a conversation with somebody about that recently. It's like I'm fairly technically proficient, computer proficient, but if the apocalypse happened, I have no skills that would allow me to survive in the wild.
You know, that kind of reliance on technology. And then there's people who can, you know, build shelters and you know, that I can't do any of that stuff because I am reliant on technology.
Anyway, we'll talk about that a little bit today with our guest, Ryan Crownover, Director of Digital Plant at Vertec.
He spends his days helping manufacturers modernize their digital platforms, connecting legacy systems, building MES solutions, integrating cloud based analytics. I mean, I think Stephanie, too often we kind of chase a new technology, whether that's AI like you talked about, using the cloud, digital twins, without doing that thing that you mentioned earlier, which is engineering failure into the equation.
But you know, AWS reminded us that failure is inevitable.
So that's going to happen. But your systems don't have to go down because of it. And Ryan's going to help us unpack some of that. We'll talk about what manufacturers are looking for in software, why some MES projects still stumble, how to prove ROI in digital initiatives, which I think is a really important thing and something that his company Vertech, uses the momentum method to help deliver value a little bit faster. So let's go ahead and bring in Ryan and let him be brilliant and tell us all about this stuff. Ryan, how you doing?
[00:07:20] Speaker C: Hey, doing pretty good. How's it going, Gary?
[00:07:22] Speaker A: Very, very good. Thanks so much for being with us.
I think software is, as we were talking about in the intro, the heart of digital transformation right now. But it's also a place where a lot of manufacturers kind of get tripped up.
Actually, before we dive into this technical stuff, tell us a little about your role at Vertec and what does Director of Digital Plant actually mean in practice?
[00:07:43] Speaker C: Yeah, absolutely. So as the director of Digital Plant at Vertec, I'm responsible for the group that executes any projects that fit inside of what we would call the digital plant domain. So if you think about what a systems integrator might do, you've got traditional automation and controls projects. Those are pretty self explanatory SCADA and automation work.
You've got what we call industrial networking and cybersecurity. So that's all of your OT networking, network design infrastructure, cybersecurity protection, managed services in that area. And then you've got the digital plant, which is our moniker to encompass things like digital transformation, mes, enterprise, scada, uns, anything that fits above that just pure SCADA layer. But isn't an ERP system.
That's what we build in digital.
Perfect.
[00:08:38] Speaker A: So let's start with the basics here. When you sit down with a manufacturer, what are they really looking for in software solutions right now? Is it efficiency, visibility, analytics, or is it totally dependent on the industry?
[00:08:49] Speaker C: I would say there's definitely threads that run across, but at the end of the day, when we're talking about manufacturers, what they're looking for is a way to improve their operations.
So some manufacturers are taking the approach of saying I have to measure my current state before I can make any improvements because how else would I be able to know if I made an improvement? And that's one approach that you can take. And we help customers do that.
You also have other customers that are coming in and saying, well, I need to comply with these future regulatory requirements.
And all of the, most of that I should say is still accomplishable with pen and paper, but you're helped by using a computer to get that done. And then the last category is just trying to make operational improvements. Is there a way that I can improve the efficiency of my workforce or of my equipment on the plant floor through some sort of technology adoption?
And so all of those are looking for, at the end of the day, an edge on how do I improve?
How do I get more boxes out the door is the real goal?
[00:10:04] Speaker B: Well, not only getting more boxes out the door, I mean, no matter what the reason is behind, you know, what they're trying to do, they need some sort of proof of their return on their investment. Right. It's becoming a make or break for software projects. So when a client's about to sign off on a major purchase order, what kind of evidence or projections do they expect to see? Ryan, I imagine that's kind of a tough balance, but you have to justify a digital project that may take months or years to show value, right?
[00:10:37] Speaker C: Yeah. Being able to demonstrate ROIs is super important. And for any business that is looking to take on any kind of software application, software developers, whether they're in house of the company or an outside contractor, should not expect a business to fund a software project that doesn't have some prospect of giving them a return on their investment.
That's a non negotiable. And sometimes as software developers we can get in our minds that no, this is valuable because what it's doing in the background it's really cool. And we get stuck on, on the reality that like, no, this has to be justifiable to the cfo, right, that ultimately they've got to be willing to sign off on, on whatever this thing is. And so because of that need for roi, what we see clients want is they want some tangible definition of features and they want, you know, a cost. And then, you know, how is that, how is that cost going to get justified in some sort of return on investment?
And what we have found a lot of success in is making those numbers smaller. And you think, oh, smaller return on investment, that's interesting. But we're trying to make those numbers smaller by making the amount of work that we take on in any one move smaller. So let's not spend nine months building this giant system and then have this one really risky go live and hope that everything we built is going to be relevant and going to make an improvement and going to do something important.
Let's do like, let's implement something really helpful that really makes an impact in like six or eight weeks.
And then, oh, that worked great. Let's double down on that and keep going.
And that's started to resonate with a lot of manufacturers.
[00:12:37] Speaker B: So, so you're breaking down a project sort of incrementally and doing, taking it one piece at a time. I mean, how do you choose or how do you figure out what you're going to do to show that it's, you know, you're going to have a successful project?
[00:12:54] Speaker C: Yeah, absolutely.
The simple way to say it is you go ask the users, you go talk to the people who the software is going to affect and you find out what their problems are.
What are the pain points? Hey, technician on the floor that's setting up web tensions for web printing and they've got all this stuff. What is problematic for your operation? Or you've got somebody extruding fiber optic cable and they've got some specific settings they have to do and things they have to deal with and quality issues they have to care about what, what causes you issues as you're going through your facility. What makes this difficult?
What are the things that management is coming to you and asking you to solve for? And they'll tell you and they'll give you that, that information and that feedback.
And we use that as the starting point to validate.
You know, customer comes to us and says, hey, I've got this problem and I want you guys to build this thing to solve it. Okay, that's great, let's go Talk to your people. Let's make sure we're addressing the things that are really going to make a difference in your operation and then we can start getting those wins. And those wins sell to more people in the organization as time goes on.
[00:14:18] Speaker B: So not everything is a win though, Ryan. We know that, right? Like what happens if a project fails. I know you are a self proclaimed problem solver, so what do you do if something goes sideways?
[00:14:33] Speaker C: Yeah, we expect that we're going to get some things wrong and we expect that we're going to pick some feature set at some point and the direction that we head down in developing, you know how this work order screen is shown to the operator is going to be wrong.
The advantage of doing things incrementally is that I only ever go the wrong direction for two weeks.
If we're doing a nine month project and we go the wrong direction and there's X amount of time, whatever that is, months between design reviews or between the last time we looked at it as wireframes and when we're actually deploying it to the operator on the line four months later, if we went the wrong direction for four months, it's really hard to win.
And with software, software can do anything, which is great, but it also means that it's really high risk that you go the wrong direction while being totally well intentioned. So by taking those smaller chunks, you're just squashing your risk in terms of wasted time.
You can get alignment and every time you get something wrong, you actually get more aligned the next time around.
So your misalignments get smaller and smaller as you do more and more iterations.
[00:16:00] Speaker A: So in a little side tangent here, in my family we're very baseball obsessed. My son is like baseball 24 7. And there's an old adage in that of aim small, miss small. Like when you're trying to throw, don't just throw for the body, throw for a small area. If you're really aiming to a small area, you can't miss by that much. It's sort of a similar thinking there. Aim small, miss small.
[00:16:22] Speaker C: Exactly. We make a plan, we define a plan, we pick where we're going to go and we head a direction and we might be off by a couple degrees and then we'll pivot and then we'll aim for another spot. And what's interesting is over the life of say a project where we're doing deployment after deployment after deployment every couple weeks, that part you're aiming for does change because something happens in the business right Some factor external to the project. All of the sudden this problem inside the facility, it's not WIP inventory.
We made some strides there. We made some improvements in how we can track and report on WIP inventory for the finance team and for the people on the floor trying to find stuff. But we've had a bunch of quality issues make it to customers. Okay, well now we're pushing on quality. Well, all right, let's wrap up the last week and a half of this WIP inventory thing and then let's aim at some quality stuff and now we can start working on the quality things. We don't have a bunch of unfinished half done work. We're trying to make sunk cost fallacy decisions of whether or not we throw all this work in the trash to pivot. We can just pivot.
[00:17:37] Speaker A: Makes sense.
Full disclosure. I met you, saw you for the first time at an inductive automation event down in Sacramento several months ago.
Something you said there kind of stuck with me, which is I think people think of industrial software as this unique thing, this unicorn, and it's specific to OT and very different. I think you said industrial software isn't unique. What do you mean by that?
[00:18:01] Speaker C: Absolutely. So I'll give the example that I've come to trust to help people understand what I mean by that, which is imagine you're an airplane pilot and you've got this iPad that tells you where you're going to go that day. It's got the four or five flights that you might be taking.
Each line tells you about that flight, gives you the status of that airplane coming in. You can select it, you can fill out your pre flight on that iPad. It connects to the airplane and gets the weight and balance information from the landing gear, from the sensors there. You do all that checkout, you do the flight right, that happens. You get to the end of the flight and you do your post flight on that iPad. You fill out all those forms, wait and balance again, submit now you move on to the next one. That's exactly the same application that an operator is going to use in a manufacturing facility where they've got a list of the work orders that they're supposed to run on their production line. They select the next one. They can see the status of the incoming materials, whether or not they can start it. They got all the information about it. They do their setup or their changeover process. They've got to fill out a couple, you know, start of the run form information, hit submit, do the production run. They do their post run workflow where they fill out a couple of things about what happened and then they move on to the next one. And those are, from a software development standpoint, the same exact application.
The content on the screen is different, the names of things and what goes into the database are different. But at the end of the day, there is a proven mechanism in the software world for building these workflow based applications.
And what we're doing on the plant floor, managing human and business processes with MES and MOM systems, all these layer three functions, they're all just B2B workflow softwares, just like we have everywhere else. We could come up with a bunch of examples of how those work. And once we realize that we can just steal those proven methodologies. I say we want to steal the wheel instead of reinventing it. We can take all those proven methodologies and just apply them into the industrial space.
[00:20:19] Speaker A: You just couldn't have given me a better segue.
So what lesson should we be stealing from the mainstream software?
[00:20:27] Speaker C: Yeah, the first one is the concept of iteration.
Taking things in small chunks and then moving on. You'll notice if you've noticed lots of people use the Google Chrome browser, you'll notice there is an update to the Google Chrome browser about every couple days.
Um, and now it's gotten really smooth, right? It's really clean. Those come in and what they're doing is iterative development. They're making these tiny incremental changes because what we've learned is that unless the users are really using the real system in production, the feedback you get isn't real.
It's. It's only so good until it's actually in real life. And then you start to get the feedback. You know, whether or not what you built worked.
Smaller increments also get you lower risk on rollout, right? If I roll out smaller changes, that deployment gets really boring because there's only this one thing that could have changed. It means I can test it better.
And the other big one is UX research. So I talked a few minutes ago about how we want to go talk to the users.
We want to go understand what their pain points are. And there's proven techniques and mechanisms for conducting those interviews, doing that research and learning that information and then taking a path of design that focuses on the user. Because if you focus on the user, you get that user adoption. And if you drive ease of use and user adoption, then your software is more effective because again, you're managing these processes that these humans are going through.
No one taught any of the three of us or anyone listening how to use Airbnb or how to use the Amazon app, or how to use Instagram. We didn't watch a training video. We all understood how to put our credit card in to spend potentially thousands of dollars, and we never even think about it. So if we're talking about the workflow for an operator to go through a work order process on the production floor, we should be able to design an application that allows them to do that with zero training.
And that's our target when we're building applications for our customers, is that especially. There's some. We've done projects and facilities that have 3,000 operators.
You want to train 3,000 operators?
No, no, thanks. If we build a system that they can learn and intuit how to use immediately upon looking at it the first time. Let's do that.
[00:23:11] Speaker B: So are you, I mean, this is interesting because, you know, the user experience usually gets ignored in the process. And, and you, you just talked about why it matters so much for operators or engineers. But does that mean you have to go in and, and customize for them?
Or is it the opposite? Is it the opposite? Is it you're trying to create something that is universal but targeted toward the end user being the operator or the engineer, versus the everyday consumer?
[00:23:44] Speaker C: Yeah.
Couple things in your question. Right? So what we're doing, building software for a specific targeted set of users, is very different from the mechanisms you might use from building a software that's targeted to try to capture users.
Right. So you look at a website or you look at an app, they're designing for this user retention. Like the user may or may not use my application, I've got to keep them in. Well, if you're talking about somebody on a production floor, they must use the system.
And that's actually a huge advantage for us because we now know what they're motivated by. If we ask them, we know what's going to make them successful. We know what's going to make them enjoy using the system if we ask them. Once we learn those things, we do tailor the application we're building for the those particular users. So in ux, throw out a little bit of jargon, just, just a little bit there, we develop what are called user Personas.
So we're going to understand all the different types of users that might be, might exist in the system and we're going to profile what's going to help them succeed and what things we need to avoid to prevent them from failing.
And the workflows, the actual path that they take through an application is built to tailor to fit those Personas and where we can make the features match across Personas, we draw a matrix and we try to make those as common as we can.
And you, you make those common when, when you want to. But then changing the skin of that application and that workflow to fit the user's step path on the literal physical floor is part of what makes it easy to use, is part of what gets you that engagement and that feedback from the people using the application.
[00:25:45] Speaker B: Excellent. Let's switch gears just a little bit earlier in the conversation, Gary mentioned the Momentum method that Vertech has developed about getting to ROI faster.
Can you just walk us through that a little bit? What is it? How is it different from the way manufacturers usually approach these projects?
[00:26:07] Speaker C: Absolutely. So momentum method is our agile development methodology that allows us to deliver an iterative set of quick wins to improve our lot.
Realistically what we do is we start with that UX research that I've been talking about. We understand the real problems and identify and essentially build an ordered list of what's going to be the best things to tackle.
Impact versus effort. Right? What's value to the business versus how hard it's going to be to do. We work with the customer and order those.
We pick an initial chunk to start working on and we do a full UI design build out. So we design the workflows of that application. The trick is that that initial application that we're going to build for what we call momentum launch, that first engagement is scoped to about eight weeks of time.
So most of the time we actually deploy our first deployment before eight weeks.
But our goal is to scope that to eight weeks of time so that from the moment we start developing and we've decided we're going to build this, we don't want more than a calendar quarter to go by before we get that in because odds are what's going to be the most valuable is going to change.
And so we want that in, we want that in fast and from there we just continue iterating. So that list that we built of all the things that are going to, you know, improve the operation somehow, we continue to work with the customer to update that list. Right? Things are constantly moving onto it. Things are changing on that list constantly. The order is changing regularly. Things fall off of that list. We keep that up to date. And every deployment, which is about every two weeks, we get a little bit more of that list into production. We cycle on that in what we call momentum iterate where we just Keep going on those iterations and keep providing value to the business.
[00:28:18] Speaker A: So let's take this from theory into practice a little bit.
What kind of obstacles are manufacturers hitting as they are trying to transition from this traditional development approach that they're used to to an agile approach?
[00:28:31] Speaker C: Yeah, the biggest rub is learning how to not boil the ocean.
And what I mean by that is when we start these workshops and we start trying to work with customers to understand what are we going to build first.
They ask for everything. They want all of it. So they want all the equipment connected.
They want all of the, you know, the work orders are in the ERP system. So we want the work orders to automatically come from erp.
Right now the operator fills out, you know, the production counts in a, in a work order close on an ERP screen. We want that to be in this MES system too, so they don't have to use that system anymore. All of that's the minimum viable product is what they'll tell us on day one. It's like, let's slow down and let's back up a little bit, you know, and understanding. Hey, a manual work order entry screen that allows the operator to say, this is my work order number, this is the part number I'm working and this is how many units I'm going to build. Let them type that in manually and hit start.
We get to the end. Let them hit end. We now know that all of the time series data in our SCADA system that we already have now is connected to that work order.
So now I can start doing things with my data. Now I can make that data better in a future iteration by getting the work orders automatically from the ERP system.
And that's one of the reasons we build that backlog so that customers can see, yeah, we're still going to do this, but it's not the minimum necessary to start earning value as an organization.
And figuring out what the partial solution that you could deploy to production looks like is definitely the biggest hurdle.
[00:30:27] Speaker A: So what has the feedback been like from the clients who have used this momentum method or have moved more toward this agile digital plant model? What kind of feedback are you getting?
[00:30:36] Speaker C: Yeah, it's addicting is really the.
Each one of these deployments, each one of these improvements for our customers is translating into a story that they can tell.
So they're able to say, hey, we had this problem, we deployed this feature. Because it's not written in. That feature isn't written in requirementes that talks about all the technical things. It's Written in the experience of the user. So we've enabled the user to report scrap on the screen. That's the goal. Right now our people on our floor, on our plant floor can report scrap.
And that's eliminated all this paper. That's eliminated all this. This. Now we have this scrap report. And we were able to identify that the biggest scrap was this and was was this product. And we asked around and we found out that was because this part on this machine was broken. And that's why that one part number was always thing because it was some weird esoteric thing. But our data showed us where to look.
That story was 12 week sprint.
Right. So you can imagine if you are a manufacturer and every couple weeks you're getting some improvement to your facility that gives you a story that you can go tell management, you can go tell leadership, hey, we're making improvements. We're growing this system and here's tangible savings that hit the bottom line of our financial statements.
That catches like wildfire.
[00:32:18] Speaker B: It's all about the story, right, Gary? We know about that. We know that.
[00:32:21] Speaker A: Yeah, absolutely.
[00:32:24] Speaker B: Hey, listen, Ryan, such a great conversation. Before we wrap though, if you could just give one piece of advice to a manufacturer just starting their digital plant journey, what would it be?
[00:32:37] Speaker A: We like to put people on the spot right here at the end.
[00:32:39] Speaker C: Yeah, no, that's a good.
[00:32:40] Speaker A: Let's Ryan, sweat.
[00:32:42] Speaker C: No, I would say unquestionably it is.
Talk to your the people on your plant floor and if you have an idea of what your problem is, have somebody who isn't you, isn't your management team, go ask those people on the plant floor what they think the problems are.
Because if there's a common thread across the people that are on your plant floor, if they're saying this is the issue, this will help me.
Tackling those problems is going to make a massive difference.
[00:33:17] Speaker A: Terrific stuff. Ryan, it was a pleasure having you here today. Thanks so much. A lot of this is good food for thought about the idea of iterative development and to use my phrase, the aim Small, miss Small philosophy. I like that a lot. Good stuff.
[00:33:29] Speaker C: Thanks. I really appreciate the time is good conversation, good questions, which I'm always a fan of.
[00:33:36] Speaker A: All right, Ryan, thanks so much for being with us and yeah, hopefully we can have you on again.
[00:33:40] Speaker C: Absolutely. Thanks y'. All.
[00:33:42] Speaker A: All right, food for thought there, Stephanie. I like, I like I just said, I this idea of making small incremental changes instead of like he said, the kind of boil the ocean. We want everything immediately.
It makes so much more sense to me. And I. I feel like sets companies up for success in this or at least smaller failures, which I think is a good place to be for manufacturers at this point.
[00:34:07] Speaker B: Yeah, absolutely. I mean, it makes a lot of sense. And I mean, remember the days back, the ERP days back when they were, like, deploying these massive monolithic enterprise systems and they'd flip the switch and it wouldn't work? Like, that was a bummer.
[00:34:23] Speaker A: Yes. Yes, it was. I mean, it's like any. I mean, if you really just go back to software and not manufacturing software, you see that happen all the time where a website is like, here's our new version and it doesn't work and it's glitchy and everybody hates it. And like, you took too big of a leap there.
Little like, walk us to where you want to get to instead of trying to do everything all at once.
[00:34:46] Speaker B: Yeah, makes sense.
[00:34:48] Speaker A: Yep. Absolutely. Well, everybody, thank you so much for listening again. We are really happy to have you on board with Control Alt Manufacturing. If you want more great information on digital transformation, industrial software development, any of the stuff we talk about with Ryan today, please check us out at ctrl engineering. That's controlenge.com it's probably where you found this podcast. And yeah, give us a, like a listen, a follow. We really appreciate you being here. Thanks so much for joining us.
[00:35:17] Speaker B: Thank you.
[00:35:18] Speaker A: Bye, guys.
[00:35:26] Speaker C: Sa.
