Episode Transcript
[00:00:00] Speaker A: Very seldom do we have to Automate. In the 30 years I've been doing this, I almost never spend any kind of capital expenditure to improve a process. It's usually taking steps out and reducing the steps from, you know, a thousand to a hundred.
[00:00:17] Speaker B: Welcome to why they Fail, the podcast that pulls back the curtain on why continuous improvement efforts fail. Buckle up because we're not here for motivational fluff. We're dissecting the short sighted decisions and leadership agendas that sabotage CI success.
But don't worry, we'll clue you in to the few simple keys to success to avoid these pitfalls. If you're ready for the truth, let's do this.
[00:00:50] Speaker C: Welcome to why they Fail, the podcast where we unpack why 96% of continuous improvement initiatives stall out and show you the exact strategies to ensure yours succeeds. I am your host Kevin Clay, Master Black Belt and founder of Six Sigma Development Solutions.
Today we are exposing one of corporate America's most expensive mistakes, slapping flashy software and AI onto broken, inefficient processes instead of fixing the root cause. Joining me today is John Todd, Senior Business Consultant and Product Researcher at Total Resource Management.
John is an IBM Champion Project Management Professional, Lean Six Sigma Black Belt and certified Maintenance and Reliability Professional with an electrical engineering background from Arizona State University.
Over his multi decade career, John has led reliability engineering and mission assurance initiatives across mission critical environments including the Jet Propulsion Laboratory, Deep Space Network and major Department of Defense programs. He is also a featured industry author and speaker known for his work in Reliable Plant magazine and recurring contributions across the Total Resource Management technical community. Let us jump right into the conversation and examine why enterprise technology fails when organizations automate before they simplify.
[00:02:10] Speaker A: John, what was your catalyst? What got you into number one, being a black belt.
Number two, being a expert in maximo and all the things that you experience over your life.
What was your journey?
[00:02:24] Speaker D: I appreciate that I'm one of those kind of odd people that my education, my college degree was in hardware, electronics and things like that. I have always worked for software companies. That's kind of the beginning of it. The current place I'm at now is largely a maximo integrator and I got involved in process improvement early on. Certainly reliability engineering back there at the Deep Space Network that was a lot of hardware understanding. I've always enjoyed the hardw hardware side of things, the understanding of equipment and electronics, but then of course the software side of things where you actually keep track of all of that stuff and all the data and the telemetry that you use Software for. And then of course, behind all of this, or at the foundation is the business side, the processes, the maintenance processes, the budgeting processes and everything else that's around all of this. I've always found myself going around this triangle of people, processes and programs, regardless of what kind of a job job I had at the moment.
[00:03:27] Speaker A: Excellent, John. You manage mission assurance where failure, it literally is not an option yet. Cross assets intensive industries nearly 96% of continuous improvement initiatives crash and burn, really, in about 18 months.
In your experience, where does leadership commitment break down first?
[00:03:50] Speaker D: If they fall apart in 18 months, they basically take too long. Everyone gets all excited about a new project. You've got a new sponsor, maybe you've brought in a contractor to help out. 18 months is a lifetime anymore these days, these improvement projects, they need to perhaps descope a bit, quite a bit. They need to move a lot faster so that not only the people that are doing the work, doing the improvements, the analyses, but also the sponsors and the other stakeholders, people just lose interest. I think leadership, they need be productively pushy. I don't know if that's a proper phrase or not, but to expect some early results, results and continued results and be interested in six months to see if the project is really making some progress or not, and also be able to say, okay, that's enough, we need to stop and move on to something else now, rather than letting it drag on and on.
[00:04:46] Speaker A: I would say that I engage with companies all over the world. The thing they want from us, at bar none, every place we go wants the same thing. They want us to come in and help teach our people to save world hunger, to save the world, cure world hunger. And we tell them it's not going to happen.
You have to really. And you said a very important word, scope. I tell all my green belts and black belts and my colleagues that there's three very important words when it comes to scope. And those three words are focus, focus, focus.
Get down to something that's small, that you can manage to change. Most companies don't want to do that. They want to solve the big picture. And the big picture is too large in scope, it's too intensive, it's too complex, and they never get to the end goal. Instead of saying, hey, maybe I tackled this wrong, they say the methodology is failed, it's flawed. It's not flawed. It's because they didn't really use a tool that I love, a Pareto chart. Getting down to what is a 20% of what you do that cause you 80% of your problem.
I find that's one of the biggest problems when anybody solves a problem in an organization is they want to train somebody to fix everything all at once.
We have to understand what are those key things that we need to fix. But and to do that you really have to have a structure in place to find those things.
[00:06:16] Speaker D: Yeah, it's very true. I know implementing enterprise software we've always historically taken like a waterfall project approach. You do this and then you do this, you do this anymore. Of course the, the agile approach to things is nothing new. But taking an agile approach to process improvement has a lot of value as well. It's a little uncomfortable here and there because things aren't quite baked yet. But that's the whole idea is to try things, experiment a little bit and say, oh, this is the right direction, we're doing the right things. And then you kind of finish it off with some icing there. So yeah, definitely could that, that scope and the flexibility is important.
[00:06:55] Speaker A: Yes, that's excellent. And agile. I was in it for many years and in continuous improvement and I melded or I saw how Lean, Agile, Six Sigma, all of these things can really meld together because they all have the same end goal to improve the process that we're doing to make it better, more streamlined and get us to the end goal quicker.
I often say in my class that common sense is not very common.
We don't think in common sense terms when we're trying to reach that. We don't take on the small things that we understand are important. We take on the big things if we think the big thing is important and it ends up getting too cumbersome and complex to solve.
We often see organizations rush to automate a messy 27 step process instead of doing the hard work to cut it down to 6.
Why are leaders so quick to treat enterprise software or even AI like an easy button before fixing the underlying workflow?
[00:07:56] Speaker D: Yeah, there's this big double edged sword there. An enterprise software, it's sophisticated unto itself.
It's been designed over many years in many industries and baked into it is some pretty good business process flow.
But the other side is that these tools, these solutions also have the ability to be very customized. You can take an already sophisticated business process that's out of the box and you can make it even more complicated with your customizations. There's a lot of temptation to adopt what's in the product, but then to customize it to fit whatever your business processes are today, which I would posit that the Business process of today is very inefficient. Why would you want to take an inefficient process and apply that into an already sophisticated environment?
Customize it now you have to maintain that over time.
A good place to start is to take a hard look at that 27 step process and just ask the question, does it need to be that complicated? Do you need to have so many levels of approval? Do so many people need to be involved? What are those tall poles of time where a record sits in an approval cycle or in a bin somewhere waiting for someone to take action? Take a hard look at that stuff first. And maybe you go from 27 steps down to 6, maybe you go down to 13. You've refined your business process, everybody says yes.
And then you can take a look at your software solution and say, all right, what of this? Our business process is already in that system and maybe even refine a little more to where you're using these systems more so out of the box. And then you end up with something that one, the solution reflects your business processes and in a lot of ways makes them more efficient to actually execute. Then as the business change, it can change.
[00:10:01] Speaker A: What I see companies do is they, they jump at the shiny thing. We've got all these complex manual processes.
A salesman comes in from this big consulting firm, says, hey, we'll bolt this in, it will change the way you do things.
And then six months later, when everybody has created their own Excel worksheets, their own access databases, because the system doesn't do what they want to do, because they've taken a very complex process full of waste, full of governance, full of wasted time, people communicating with each other through email and all that. And they've put this on top of it and said, okay, I'm going to put some workflows in place where if somebody doesn't answer an email or sign a form, they're going to have alarms that go off.
And then because they're, they're not addressing the complexity in that process, the alarms start going off.
And after a while people stop listening to the alarms. Nobody pays attention to the alarms.
[00:11:05] Speaker D: Right.
[00:11:05] Speaker A: You have this automated tool that was supposed to help your company and it just makes it worse. I've seen this so many places.
I actually used to follow some different applications when I was in IT that we would go in about six months after they implemented and we go in and after and say, okay, we know the problems you're dealing with and then we'll help you fix them. But to fix them, it's not reprogramming, it's stepping back and saying what are we doing presently that we can streamline, that we can take that thousand step process and drill it down to 100 step. But I've got a hierarchy of improvements. When my belts get to the improved phase and I always tell them to follow this hierarchy, I say, you don't automate first. The hierarchy is simplify, innovate and automate first. Look at the process and say, can you simplify it?
99.9% of the time that's a fix.
[00:12:02] Speaker D: Yeah.
[00:12:02] Speaker A: And then innovate is where I have to re engineer the process. Maybe I'm taking a line that has been broken up into 12 sections departments and it takes a long time because there's a lot of waiting between departments bringing it closer together, increasing the flow and. But if that doesn't work, which again, most of the time it does, very, very seldom do we have to Automate. In the 30 years I've been doing this, I almost never spend any kind of capital expenditure to improve a process.
It's usually taking steps out and reducing the steps from a thousand to a hundred and saving that operating cost. I see the same thing, John, in it from being from that side of the coin, everybody wants to jump to the shiny thing. This new AI tool, this new system. Every single time I see what happens at the end and what happens at the end isn't what they want.
[00:12:59] Speaker D: Yeah, There is no shortage of technology feature functions, we'll call it opportunities to automate whatever in these enterprise applications. Some require some basic scripting, some are low code, no code.
Now with AI agents and workflows and all of this, it's not a question as to whether the software solution can support any type of workflow.
For sure it does. The question is to what extent do you really want to use that?
I'm a big fan of having folks manually go through their process. Once a new system is into place, or at least you're in proof of concept. Mode is to manually move records approving things in the system itself at first and say, is that efficient enough? And then you mentioned emails. Everybody says, oh, I want a notification.
Okay, you want an email, you want a text, you want something on the screen. Are you going to pay any attention to it when you get 50 of them?
[00:14:03] Speaker A: Right? Yes.
[00:14:03] Speaker D: It goes back to like you said, that very first step in your hierarchy there is simplify, simplify, simplify.
[00:14:09] Speaker A: Yes. It's amazing. I watched the company go from a very manual process to a systematic process and they Put these workflows in place and these alarms that go off. It was a manufacturing plant and they had out on the floor, they had Taktine boards, they had visual cues, but nobody looked at them. And I knew that was going to happen in their system.
So when those alarms started going off, people started learning how to game the system. It's amazing how smart we are because they found ways to turn those alarms not off, but to where those alarms. They would put those alarm emails into a certain subfolder and they would never see them because they couldn't not get them because there was so much complexity going on in the process.
It was an excellent example of what happens all the time in these different companies when enterprise tools get shoved onto the floor without buy in. Technicians rebel usually with rogue Excel sheets and offline workarounds. How do you bridge that gap? So frontline maintenance teams actually embrace the system instead of bypassing.
[00:15:20] Speaker D: That is definitely an issue. A lot of people ignore that. The way we approach it is that's where we start.
We start with who is going to be pushing the buttons, moving the mouse, entering stuff on the keyboard or the tablet or whatever.
What exactly are we expecting them to do?
Ultimately, these enterprise systems, they're there to collect data.
That data then gets analyzed and used to make decisions.
So the question is, the people who are out in the field collecting the data, knowingly or not, how aware are they of ultimately the decisions that are being made? For example, they fill out a work order, they put in their actual times, the items they use, things like that, do they have a sense of what that information is being used for? Which they should.
The company owes that to them. But then the design of that application, whether it's a browser or maybe they're using the tablet, how efficiently can they enter that information?
Or that information gets captured while they're using the application, so they don't even have to think about it. Most folks out in the field, they want, what do I need to do?
Where is the broken thing? And what's the minimum I need to do to capture my time? There's actually some opportunities now to where?
Let's say, for example, I was assigned five or six work orders today, and each one's a couple hours long.
Where you can actually have an AI agent ask me and say, hey, did you really spend two hours in that work order? It's like, yeah, it's close enough. Okay, good.
The point is, I didn't have to enter that two hours.
I didn't have to think about it and say, oh, it's an hour and 45 minutes. Two hours is close enough. That's kind of where we start is who are the people going to use this software? Ultimately the stakeholders, the sponsors, upper management, they're going to be using the data, making decisions, but they're completely reliant upon those people to actually push the buttons and enter the data. That's where you start is their usability.
[00:17:27] Speaker A: I kind of correlated back to it's hard to run a process, IT process or a business unless you understand what the end goal is.
If you don't understand your KPIs, you don't understand what makes your company successful, then you're just going to run around like lemmings and turn switches and turn knobs and hope that something happens to where you make money.
That's where I see a lot of companies is the people on the floor don't really understand how they affect the process. They're told to do something and then when I go out and ask what are your metrics of success? They usually say, well talk to my supervisor, my manager. It's really this top down process where the bottom who is the ones that are actually making the money don't really have the information or the power.
They have to be relegated to what's going on on top. And that always baffles me that we don't understand our KPIs at that level. If we understood exactly how we affect company success, the site success, the organization success, then it would be easier for us to understand what we were doing in the system to help propel that. Does that make sense?
[00:18:45] Speaker D: Absolutely. Yeah. In fact, I have a very recent example that I'll scrub a bit to protect any names, but there's an instance where they had a piece of equipment that has not been functional for 15 years.
It's been sitting there and 15 years ago it cost about five grand to have it put into place. They were having an issue with something related to it and they said, well let's just spend the thousand dollars to fix this other thing and recovered. But the person involved in it, they said, well let's fix the $5,000 one. And with a few blows from a hammer and some saw cuts, they actually solved the problem.
They didn't have to spend a thousand dollars and they brought a piece of 15 year old equipment that had cost them money at the time back to life and solved the issue. You kind of scratch your head and say why did that take so long? These are the boys and girls that are out in the field. You Talk about innovation and such. They're the ones that can come up with these things.
[00:19:51] Speaker A: In my book why they Fail, I discuss how continuous improvement leads shouldn't be the company cop or the sole problem solver. How can reliability engineers step back into the guide on the side role at frontline operators to truly own root cause problem solving?
[00:20:11] Speaker D: I think it comes down to how it's facilitated. I've sat through a lot of root cause encounter sessions. Some involved, some injuries, some near misses and things like that, and they're pretty uncomfortable. It's that environment to be able to look at information and data objectively, draw conclusions as a group, and then ultimately everyone, you know, it's almost like a jury. Everyone needs to be able to say, yeah, that was the problem.
We hate to say that, but it was a human related issue or whatever, which a lot of the times it is.
It really comes down to who that facilitator is. Also have a bunch of different kind of people in the room. You've got reliability engineers that look at data and that's just the cold hard truth. But then you've got other folks that are a little more in tune with the humans. And there's a human factor to it. It's taking advantage of everybody's skill set to as a group come to a final conclusion. I think the facilitator, the process is the key there.
[00:21:17] Speaker A: It's really important to have data when you're taking that guide on the side roll so that we understand we're not making decisions based on gut feel or emotion or subjectivity. Where is that data in this age of AI, the data is everywhere.
That always baffles me. Again, because we teach tools that are focused on data. Six Sigma is really focused on making decisions based on what the data tells you, not on qualitative tools.
We have people that still really want to back up and use their gut feel and their emotion. You have to understand the people side of things, but
[00:21:55] Speaker D: you
[00:21:55] Speaker A: really have to lead the root cause from the fact that we have data of what's going on.
[00:22:00] Speaker D: Right, Mentioned that. I've been on a couple of RCA sessions and sometimes an accident's just an accident. Nobody was speeding, the road was less than wonderful conditions, just the holes in the Swiss cheese lined up and there's really wasn't one particular thing that caused it. RCA in many contexts is a really good process to go through.
[00:22:24] Speaker A: I love root cause analysis. What I don't like is people that take on a root cause analysis and reinvent the wheel. I solve a problem and then I don't control it or I don't put systems in place to control it. I don't get any kind of a feedback.
I don't understand how that process works going forward. I just go into a group and we solve the problem and then we all leave and go to our own places. And then that problem comes back again.
[00:22:54] Speaker D: Oh yeah, you have to have an improvement. You have to have something that comes out of it. And beyond somebody getting fired.
[00:23:01] Speaker A: Yes. Even more than that, you have to have a control in place to monitor it and to make sure that it is performing in the new requirements. That's where I see that people go wrong, get so excited when we improve our process
[00:23:15] Speaker D: that
[00:23:16] Speaker A: once we improve it, we want to go improve something else. Well, then we leave the hard part. The hard part is control. Making sure that when we leave that the operators, the SMEs, the people who are at that process, number one, will adopt it, number two, have the tools so that they see the health of that process in real time. And that's where you come back to data. If I don't have a data tool that can really help me understand the health of that process in almost second by second increments so that when it starts to go back out of control, I then have an understanding of what to do to keep it from going bad.
What I usually see is again, we improve the process in the short term, we put a band aid on the wound, then we go away. And because we don't have that data in place, that band aid, eventually the womb comes back and people.
[00:24:10] Speaker D: Yeah, for sure. You really want, a year from now, once you implement something that someone's able to ask the question to say, well, why do we do it that way? Well, it's because of, we used to be like this and now we're like this. And here's the data to show it.
[00:24:22] Speaker A: Yes, yes.
[00:24:23] Speaker D: And we have, we have such amnesia years. A long time.
[00:24:28] Speaker A: I like that term, amnesia. Yes, absolutely. A lot of times that comes with new leadership, with new people.
The way that we control a process is by telling somebody else what to do. It's by verbal communication. It's Johnny teaching, Jimmy teaching, Jackie. It's that grapevine game where you whisper in one person's ear and they whisper in another and eventually it goes back out of control instead of creating standards, creating active work instructions and things. That stays there when the people leave.
[00:24:57] Speaker D: Right. I had an experience, we were doing some requirements gathering several years ago and this one gentleman wanted to walk us through, explain the what's and the whys.
And so he made a tent out of a piece of paper and put it in front of him and it said what on one side and why on the other. And he says, okay, let me explain you the what. This is what the process is. And da da, da, da da. And he says, then he'd flip it around and say, okay, now this is why.
And for someone like me who is capturing requirements, it was great because sometimes the what just doesn't make a lot of sense. But when he explains the why, it's like, okay, that's why you're doing it. And of course then it could show
[00:25:41] Speaker A: it's a great tool.
[00:25:45] Speaker D: The what and why. 10.
[00:25:47] Speaker A: Another question.
Too many CI and reliability pipelines are driven by the loudest emergency or the newest executive pet project.
What does an objective KPI driven hopper look like that prioritizes projects strictly by the bottom line impact or the impact to KPIs?
[00:26:09] Speaker D: I think the difficulty is most, most KPIs sit in the green and don't really show any change over time. And everybody's happy that. I think it comes down to truly identifying those issues that are costing excessive amounts of money.
And to be able to quantify that, you can say, look, last year we spent a million dollars on maintenance and a third of that was on this one particular thing that failed. And you want to try to avoid that. To base an improvement project solely on a KPI that even if it's sitting in a yellow zone, but it's been yellow for a long time and hasn't changed. Well, is it really even a problem because it hasn't changed what is going to save money, make money quantitatively, avoid risk or mitigate risk, that gets into a bit of a gray area. But you have a perceived risk that everybody agrees, well, what can we do about that? You're not necessarily going to find that in a KPI.
[00:27:16] Speaker A: I tend to think on the other side, if you have good operational targets and Most people think KPIs are at the organizational level, that's where most companies go wrong, is we've got these overarching KPIs that Johnny bag of donuts on the floor, a cut machine or a press machine doesn't really understand how his process affects that KPI because it's way too high up there. But when you start to cascade KPIs down from organizational level to site level to department level to a cell level to a human level, then you start to understand, well, what I do when I press something I have to make a certain amount of quality that directly affects my cell oee.
And all of a sudden now when I screw up, I know it. I also know how not to screw it because I understand the tools and the methodologies to help me improve my process. Most companies aren't like that.
[00:28:15] Speaker D: No.
[00:28:15] Speaker A: We have people sit in the ivory tower and they delegate things down, but as it floats down to the floor it, it gets watered down. So nobody really understands what they're doing. They work all day, they may think man, I've done a great job today. Then I get yelled at and I'm not really sure why. I'm on the other side of the coin. I think the more that you let data lead you to where the process and problems are, but if you're going to do that, you better have good data. And that's where it comes in. That's where these systems come in.
Because garbage in, garbage out,
[00:28:50] Speaker D: right?
[00:28:50] Speaker A: If I don't have good data going in, I'm not going to be able to make decisions on the problems to fix going out. That's where I see 90% of companies go wrong. We collect data but we don't have any clue how to use it.
[00:29:04] Speaker D: Right.
[00:29:04] Speaker A: Then we go out and find more data, but we never really analyze it correctly. And that just baffles me sometimes.
[00:29:12] Speaker D: But you're absolutely right. And oftentimes what is perceived to be a problem, maybe something that does cost money, is just a small drop in the big bucket that sure you could fix it, but it's really not going to move the needle. It's really not going to have any impact. They got to be cautious of that as well because everything does kind of flow upwards. There could be a much larger vendor relationship of regulatory fines and things like that are in the hundreds of thousands or millions of dollars.
And at the same time we're trying to improve some operators efficiency. A half a percent.
[00:29:49] Speaker A: Right? Right.
[00:29:50] Speaker D: Yeah. Really got to pick the right things for sure.
[00:29:53] Speaker C: Thank you so much for tuning in to why they fail. In today's episode we broke down why automating a 27 step mess only gives you a high speed disaster. Remember the core improvement hierarchy. Simplify first, innovate second and automate last.
Sustainable results come from eliminating waste, cascading KPIs directly down to the frontline technicians who input the data and putting real controls in place so your process never slips back into chaos. If you are ready to eliminate these costly blind spots across your own organization, be sure to grab a free PDF copy of my book why they fail and the simple key to success linked directly in the show notes below. Subscribe to our YouTube channel as it is a completely free way to support what we do and stay ahead of every new release.
Make sure you are following the podcast on both Spotify and Apple so you get every new episode instantly. If you gain valuable insights from this discussion, please leave us a five star review.
