Scratching the Surface: Using Data to Drive Business Results

Welcome to the Industry 4.0 Club's fireside chat. The club's purpose is to engage the power of diverse worldwide talent to accelerate the global evolution to Industry 4.0. The club accomplishes this by hosting and supporting respectful, thoughtful, and interdisciplinary open conversations and creating quality content on wide-ranging Industry 4.0 topics to expand the reach of our community. My name is Mike Ungar, and I'm the CEO of the Industry 4.0 Club. I have 40— over 40 years of leadership and manufacturing experience, with, with most of that time being with Michelin. North America. Today we're airing the second episode of our series of broadcasts— I'm sorry, the, the fourth episode of our series of broadcasts called Lean Industry 4.0: Operational Excellence Meets Technology. Hosting this series with me is Tim Stewart. Tim is the president of Visual Decisions. Tim, would you introduce yourself, please?

Sure. Again, Tim Stewart from Visual Decisions. I've Created the company back in 2002 to help manufacturers get information from the shop floor and then utilize that to drive continuous improvement. I've got a continuous improvement background, having worked at a lean consulting company as well as Cummins Engine and Black& Decker. And what I found was that even though a lot of the tools in lean are data-based, you spend most of your time collecting the data with tick sheets and so forth, and less time actually utilizing that information to improve the operations. And so my focus has been to automate the process of collecting the data and then have the main focus for the people be on using that information to actually drive improvements to the business. We've done this across a number of different industries. lots of different manufacturers and have driven some great successes with them.

Yeah, thank you, Tim. So our broadcast today is entitled Scratching the Surface: Using Data to Drive Business Results. Our guest today is Dr. Marcel Schaefer. Marcel has been leading the Fraunhofer USA office in South Carolina since March of 2021. He is the senior program coordinator for Fraunhofer's USA activities within South Carolina's Fraunhofer USA Alliance. He previously spent 10 years with Fraunhofer in Germany. Fraunhofer projects cover a broad spectrum of ranging from artificial intelligence to smart manufacturing, Industry 4.0, digitalization, predictive analytics, sustainability, renewable energy, battery, hydrogen, and many other innovative and emerging technologies. So Marcel holds a master's degree in mathematics from the University of Wuppertal in Germany and a PhD in computer science from the Technical University of Darmstadt. Marcel, we're really glad that you could take time from your busy schedule to join us.

Thanks for having me.

So Tim, would you mind starting us off and sharing some background about our topic today?

Sure. So one of the issues that manufacturers often get into is that they'll dip their toe into this space of smart manufacturing, and they'll implement a single use case within a limited area within their manufacturing operations, and they'll kind of get stuck there. And so part of what we need to look at is, you know, how do you avoid that kind of pilot purgatory that many manufacturers end up in. And part of that is to focus on expanding the coverage of your different use cases over time. Part of it is focusing in on the people and so forth. But in terms of expanding that use case coverage over time, let's say that you do something like machine monitoring and your initial goal is just to, you know, see what is driving my downtime and improve that. That same information can be used for many different purposes within the organization, ranging from quality to costing and all kinds of different things, so that lots of different people within different departments can utilize that same information to drive improvements in their areas as well. And so the idea is that you're continuously increasing the number of people touching that information the number of uses you're getting out of it and being able to make better use of that over time to make sure you don't get stuck in that pilot purgatory.

Thanks, Tim. Super. Marcel, before we get too far into our discussion today, can you just talk some more about Fraunhofer and what their mission is globally?

Yeah, sure. Fraunhofer, the Fraunhofer-Gesellschaft, is the world's largest organization for applied research. With applied research, I really mean putting something into practice. As compared to universities that focus a little bit on the theoretical side, Fraunhofer focuses on the industry side of research. So Fraunhofer is present in over 80 countries in the world. The vast majority though is within Germany. So there are over 30,000 people in Germany working for Fraunhofer full-time, and most of them are scientists. There are 76 institutes in Germany alone, and each focusing on a different field of research. That's why also the breadth of the organization comes from. And over the last 10, 15 years, we calculated over 30,000 patents. So that basically means there's 10— we file 10 patents every single day if you count that back. We have the largest holder of IP in Europe with that, one of the big players in the world, of course. And frankly, these patents are only byproducts. So we really work with customers to implement industry solutions.

How do you— so with Fraunhofer, I could just ask, do you guys share knowledge with each other worldwide? So for example, what's going on in Germany, are you informed of that here in the US?

Yeah, so there is Fraunhofer USA and there's the Fraunhofer Gesellschaft. Fraunhofer USA is an affiliate of the whole German Fraunhofer Society, and there is— we see ourselves a little bit as a bridgehead to that technology. So we have centers here in the United States as well that do— that have different fields of research that they do stuff with, but we also see ourselves as the opening the— or helping the technology that is in Germany bring over to the United States and help the companies.

Very good. Well, maybe we can get into our discussion a little bit about today's topic a bit further. So maybe I'll start with you, Marcel, and then we'll get, Tim, your input on this question. What are some of the roadblocks that manufacturers face when working to evolve their organizations toward a data-driven culture? What are you seeing? What are you seeing for your work?

So, I mean, Tim already touched it a little bit, right? So there's oftentimes companies that start with something, Maybe it was successful, maybe it was not, but then bringing this to a broader scale, oftentimes they kind of struggle. So I always say when people ask me about this that the first thing you need to look at is the humans, like people on the shop floor and in the office alike. Most of them, many of them are scared that all this new technology kind of takes their jobs or will make, well, change while they're not embracing change. So instead of embracing this new technology and trying to get some support from whatever it is, they kind of, they rather oppose this and work, maybe work against it, or at least are not really going with it. And this kind of will, of course, hinder every project there is. So that's one, humans first. Then I would say the machines. If you look into a typical manufacturing floor, there are machines that are like 20 years old, capital investment of several million dollars, and of course those need to stay. You can't just replace them because they're old. They're not designed with data in mind. So you need to take these machines and upgrade it so that you can actually leverage the new technology with these machines in mind. And that typically also takes some time. Like, where do I get started? What do I need to do in order to have this machine or this machine connected or generally create data that we can use in order to do something with AI, do something with Industry 4.0, and so on?

Tim, what's your experience in this particular— what are some of the roadblocks you've seen?

Certainly the people. As Marcel mentioned, the willingness to adopt and adapt, you know, what they do, changing the habits of the people and changing the behaviors to take advantage of the new capabilities. And adapting the processes. If you look at something as basic as problem solving or root cause analysis, a lot of companies have fairly well-defined methodologies, but those methodologies don't call out looking for the data that's coming from these different systems in smart manufacturing.

Mm-hmm.

And so how do you, uh, look at not just upskilling your people, uh, how to, you know, talk to them and convince them that this is part of something that they want to do, but how do you actually look at the different processes within your organization across different departments and take a fresh look at how those could be done differently now that you have these advanced capabilities in place.

For me, the things that I've seen that's interesting is the, well, this has always worked for me, why do I need to change perspective? Where people are— and this is really a common thing where especially for a leader, what got me here, was this, this, and this, so I'm going to keep doing it. Why? Because I've been successful with it, right? Rather than, in fact, um, I need to look at new things and continue to adapt and learn. So I think that's one of the other roadblocks, at least that I've seen, uh, in, in my travels. Okay. Um, so I, I'm not a real— at times I feel like I'm under, um, under the gun in terms of my technical knowledge, and I, I I keep hearing the term stack solution, but I'm also not sure that some of our audience may know what that is. So Tim, maybe you can elaborate on what a stack solution is and what are some of its capabilities.

Sure. And it's a bit of a fuzzy term, but the idea is that you don't have a single solution that's going to meet all of the different requirements that you have across manufacturing.

Mm-hmm.

And so, uh, how do you, uh, put together a set of solutions that's going to build on a framework and have proper communication methodologies, proper data storage, proper cybersecurity, and so forth that's in place in order to address all of these different facets of the operation? And so when you start looking at Your communication layer, your data layer, your, you know, how you're actually talking to machines, your presentation layer. All of those different things need to be incorporated within that solution stack. And so you have different components of that stack and they all need to work together nicely.

And, and so is that pretty common? Or do people typically go for one? I mean, is it pretty common to see a stacked solution? Or is there usually like a vendor does one thing? What, what do you think is typical out there?

I don't know of any one vendor that will provide everything. I mean, certainly there are vendors that provide a large portion of that. If you look at something like SAP or Siemens or Schneider Electric with Aviva and so forth, they, in different industries, they provide a good portion of that stack. But if you look at all of the different portions of quality solutions that are out there and laboratory management systems and SPC and so forth, and then you look at inbound inspection and you look at Maintenance systems and you look at, you know, MES and so forth, there are so many different things going on within manufacturing that there's no one vendor that provides, you know, best-in-class solutions around everything.

Hmm.

And so typically you're going to be looking at multiple different vendors as part of that overall solution stack, no matter, Yeah, how much you're getting from any one of them.

Marcel, is that the same thing you've seen as well?

Yeah, absolutely. So there's no silver bullet, right? So there's no one solution that fits every manufacturing floor. All with the— I mean, even if you have sister plants that are in theory doing the same thing, it's not exactly the same thing. So there's always differences, and have one single solution that covers all what Tim just explained, that is maybe the wet dream of a manufacturing plant manager, but I don't think that's a reality right now.

Yeah, so if I wanted to make a— I think the question that comes to my mind when I think about a stack solution then is, how do I make it simple? You know, when I've got a lot of different partners working together, it would seem to me that would add complexity. Marcel, what's the reality that you see?

So the complexity all makes it a little hard to get really to the bottom of it. So if you really— I mean, it's different companies that have a different focus and then therefore want to have some different things created. We are Fraunhofer as a nonprofit. We don't have specific products. We always tailor to that specific company what their specific needs are right now. So, and for the most part, this is how it goes right now. You have some vendors that have specific solutions and that can be tailored, but it's limited in its flexibility.

So do you do the customization then within Fraunhofer for a company? Is that what you try to do?

Yeah, whether it's taking solutions that are out there and manipulating them, changing them, editing them, Or creating something that is really fresh specifically for that company.

That makes sense. Tim, have you, in your travels, what about your thoughts on this area of complexity versus simplicity? What are the trade-offs that you've seen?

Certainly you want to have as simple a solution as you possibly can that meets all of your needs. So, as simple as you can get, but no more than that. The best way to approach this is to begin with the end in mind. Have your vision well-defined, clear goals that you're trying to get to over the next 3 to 5 years, and map out what are the different requirements that you have to be putting in place and creates an architecture of different solutions that minimizes the complexity, but, you know, achieves those different goals. And so being strategic and intentional from the beginning with that complete picture in mind is going to help minimize the different point solutions that won't interact very nicely.

Thank you. That makes a lot of sense. Well, and so you were talking about implementing a solution, a stack solution at a company. So we've done our pilot. Now, we talked earlier, both of you, about pilot purgatory, right? So how do we break out of this pilot purgatory? I mean, so a young engineer has a great idea, gets enough money to put it in one part of the plant, one area, you It's successful, but, you know, the buy-in may not be there in other places, or the cost may not be there, or, you know, now we're stuck with a pilot. What, Marcel, what have you seen as some of the best practices to break out of pilot purgatory?

I mean, first of all, if this pilot was successful, that is the biggest argument that you can have, right? And so, I mean, if the pilot is not successful, don't ask for the next one, right? So that for sure. But you also need to make sure that you can show the success and how you can transfer this success to different operations. Maybe you don't— if you're successful in one operation, maybe the next thing is not doing something completely different, but sticking somewhere there close where you can actually see and where the people that are being affected by this new solution are able to see the potential benefit that this new thing And of course, return on investment. You need to be able to calculate something to your plant manager and saying, this makes sense, we need to do this. Um, quick wins, of course, um, but, but really, really have your, have your planning thorough so that you can, that you have the right arguments for doing something like that.

Yeah, that's good. Taylor, you're— have you seen things get stuck in it or things not get stuck? What kind of best practices have you noticed?

To pile on to what Marcel said, first of all, you know, as you're beginning, make sure that you establish a baseline of what the performance was before you began so that you can then go back and compare and contrast to say that, yes, this did make things better. Now, one of the things to focus on as you're doing that initial implementation or that initial pilot is, are you just trying to prove out whether the technology works, or are you actually trying to drive improvements during that pilot? Because you may be doing the pilot just to show that the technology works, and in that case, you're probably not going to drive a lot of performance increase as you do that. Because to drive the performance increase, not only do you have to, you know, capture the data and be able to display that and so forth, you have to change the behaviors of people. You have to change the process to take advantage of those new capabilities in order to actually see those benefits. Uh, the comparison I use all the time is a Fitbit. You know, I can wear the Fitbit, I can, you know, capture all the data, I can see all the pretty charts and graphs, But if I don't change my behaviors, I'm not going to lose any weight. And it's the same thing on the shop floor. You can put these things in place, you can do all the right things, the technology can work perfectly, but if you don't do anything with that information, then you're not going to see any performance increases. And so that has to be part of that pilot plan, is what are you going to do to take advantage of the information that's being provided to drive improvements in the process? process. And then you have to document that. You have to, uh, actually determine what those improvements are worth. So if you're just improving a KPI such as OEE or something like that, you have to determine what is the worth of improving that, uh, you know, KPI. And then you can go back to management and you can say, here's, here's what we were able to do. Now we should expand the scope of this either by rolling this out across different— the same thing across different departments, or by saying this area is now ready for a next step and some additional functionality within that same area within the plan.

Yeah, that's a really good thought process. You know, my experience here, if I'm dealing with a project that we've got to pilot first before we roll it out is to really write the entire project for the entire rollout, not just the pilot.

Mm-hmm.

Make sure upfront that management's ready to commit the resources, assuming we're successful upfront, because you don't want to surprise them and say, hey, we got this great idea, now can we take it further? And they go, no, we don't have the resources. To me, that helps to address the resources. The other thing that is quite helpful too is getting the stakeholders who are going to be involved in the proliferation really involved in helping to define the pilot. In other words, getting them to determine what is it that they're going to— what is it that they need to see in terms of defining what success is, so that when you're able— and then building those success criteria into the pilot.

Yeah.

I think that happens a lot of times where we build a pilot and We're not thinking about, as Marcel mentioned, maybe the next department over needs a little bit of different, something slightly different. We've got a proof of concept here, but have we gone far enough where that new department says, yes, I'm ready to take that on? I think there's some things you can think about there. Marcel?

Look for the people who are in that team to realize that. If you have the yes-sayer in that, the ones that are motivated, that's Definitely going to accelerate the project and then the success chance.

You could also look to build up the number of people that are touching that pilot data. So I touched in the opening around the idea that you've implemented a single use case, but now that same information can be used for multiple different purposes. And so, for instance, I talked about, you know, machine monitoring and looking at OEE and uptime and downtime and so forth. But, you know, once you've done that, now you can start to pull in, you know, maintenance afterwards and say, here's the different preventive maintenance tasks that we're running on this. We now have information about, are those things actually improving the performance of the machine? So now let's start to look at how can we optimize the perform— or the preventive maintenance tasks. You can take that same information, you can use it within, you know, the continuous improvement team for saying what are the kaizens that we should be running, you know, within this particular area within the facility and so forth. And so even without implementing additional technology, you can broaden the base of support and broaden the base of people that are interacting with the solution. And then you can, once you have that done, then you can start to look at Should we roll this out to other areas of the plant and kind of standardize this new way of working across a larger portion of the facility?

Yeah, neat. Very good. You know, last month we had a guest on, Adrienne Temple, and we talked about— she was from the South Carolina MEP— we talked about upskilling the workforce. And I know that while it's important to train and develop the workforce, it's certainly necessary to do that, it's usually not sufficient for the success in leveraging data to improve business results. Imagine I've got a workforce that's been trained, they know how to use the tools, they actually have been given some orientation to data, but how do you really create that culture where the workforce actually learns how to seek data to help them make better decisions? How do you actually flip that switch where they're actually pulling rather than you pushing? Marcel, do you want to start us off?

Yeah, sure. So of course knowledge is important, right? So keeping up with what is new, what is the new technology, and have people that can train and teach about this technology is good. Of course you need to be key with what's the new innovation that's out there that could potentially help you, but it needs more than theoretical knowledge, right? You need Someone who has experience in implementing this. You have someone that can actually take you by the hand and appear as a trustworthy partner that you trust, that the team trusts, that is bold enough to go this route. And then, of course, also you need the safety beyond. So if something— if you fail, if you have some approaches and you fail and you're afraid of losing your job, which oftentimes probably is the case, that is not creating a mindset that you need for embracing innovation, right? You need a mindset, and you can only create a mindset if you have the people— if the people that do this pilot project, this rollout of a new innovation project, that know they can fail and then they can start over, they have more experience, and then make it better the next time or something.

Yeah, very good. Tim, your thoughts?

Yeah, certainly in that previous conversation we talked about upskilling the people themselves and making sure that people have the training that is required to understand the graphs and the charts and the numbers and everything else. But I think that you can also look at what are the standard practices that you have in place. If you have you know, lean practices and so forth, how do you actually define, you know, how you go about doing root cause analysis, problem solving, etc., and make sure that you have within those definitions or those practices called out, you know, what are the different places that we can go and get data from, and how do we utilize that information in order to do root cause analysis? through the problem solving and so forth. And that helps with that process of becoming more data-driven. The other thing is, you know, how do you make sure that there's a win, you know, for the different people, whether it's just recognition or whether it's, you know, something else? How do you make sure that people understand that this is in their best interest? to go down this path and start to utilize these different technologies and so forth?

Yeah, that's a— those are really interesting questions that you share there. You know, I think one of the first things when we have new technology that we're introducing in a manufacturing facility is really before we try to bring that technology in, we try to look for the problems, really identify the problems that that technology can help solve. I think if you see that, if there's a relationship between the problem and the person on the shop floor, and what I mean by that, if that problem is something that the person on the shop floor is passionate about, and through the use of data and a different process, if you will, they see that that problem is solved. Well, I think then you have them. I think they're ready to go. They see the benefit of using data to drive business results that maybe wasn't done before, then I think you have them and you're able to then continue with the next part of the project, if you will. So I think finding ways to get that commitment is really key up front.

I had a customer that had a great process where they did TPM Tuesdays, and Tuesday they would go through, they would shut down a line for an hour at a time And they would bring the people, you know, the different operators for that line. They would try to do a shift change so that they could get operators from, you know, the different shifts involved and so forth. And they would bring in people from maintenance and so on. And they would involve everybody that's on that whole crew to look at the data, see what the key problems were over the past week. Brainstorm different solutions that they could put in place in order to address those. And just by making this inclusive and making this something that they were organizing around, they started to drive that more data-driven culture.

Yeah, it's really cool. Marcel, anything, any other thoughts on that question?

I can absolutely echo that. We actually have a, we call it Rapid Innovation Workshop, where we do exactly what you just described, Tim. You put the people in the room, so from all the hierarchies in the plant, the people that are affected by this new technology possibly, so that they are then in this room figuring out concepts themselves. And then when they have something at the end of 2 days or so, they feel they are part of the solution. They took part in solution finding. how to solve this problem with the new technology. And then of course you have them aboard, they have the buy-in way more than just top-down saying, okay, we're now using this technology, you've got to make it work. So absolutely echoing that.

Yeah, that's great. That's super. Well, we've been, we've been talking really during this Fireside Chat with Marcel Schafer from Fraunhofer and Tim Stewart from Visual Decisions about Just creating data-driven companies and really taking what is today maybe surface and really going deeper with this idea of using data to drive decision-making. As we begin to reach our wrap-up, maybe I can get some final thoughts that you would share with the audience and maybe we'll start with Tim about what we've been talking about today. Tim, you want to start us off?

Sure.

So, you know, as you're going into this, you know, if you're trying to avoid getting stuck in that pilot, you know, do your baselining up front, have clear definitions around what does success look like. Make sure that you're— if you want to do more than prove out the technology, if you want to prove that this is going to provide business benefit, make sure that part of your pilot plan is driving benefits instead of just making sure that the technology works. Make sure that you have, you know, the people with the skills, or get, you know, people upskilled so that they have that capability of driving those improvements and so forth. And then look at the different processes that are involved and how you need to adapt those processes and the behaviors of the people. people to take advantage of the new capabilities that you're putting into place.

Thank you, Kim. Marcel, who's better?

Yeah, kind of similar way. When I hear the people that are now saying, okay, we have the go, the green light, we can now do an innovation project on the floor doing something for the good, sometimes they feel like they're in the startup phase again. But they just right on jump on the problem. I would actually say take a step back, take a holistic view on that, do thorough planning in the beginning, and then do the first steps, and then implement with a real plan in hand. As Tim said, have the data at hand, have the arguments for specific processes or innovation products, and then do this innovation project. Not just dive into.

Yeah. Well, both of you described something that I've heard said quite often, and that's go slow to go fast. Yeah. With the idea that, hey, make sure you do everything correctly, you plan right, you get people involved, you train and develop, and make sure that your pilot is successful. And when you have that well done, your ability then to deploy quickly is much easier. Is that— I think that's kind of what comes to mind as I hear you guys talk about it.

As a lean guy, I certainly advocate avoiding rework.

Excellent, excellent. Well, I really appreciate your thoughts today. We're, we're kind of reached the end of our time together, so I want to thank Tim, and I want to thank Marcel for joining us for this very insightful discussion, really, and thanks to everybody else who's listening in today as well. to this broadcast. We certainly like to invite our listeners to participate in future broadcasts, and if you're interested in doing that, there's a form on our website and on our newsletter to invite you to join us that you can fill out so that we can, we can just gauge your interest in that. If you'd like to listen to more broadcasts like this one, the Industry 4.0 Club hosts conversations Typically on Tuesdays and Wednesdays at 12:30 PM Eastern time, looking at topics around women in manufacturing, the future of manufacturing, looking at a technical topic, fireside chat, and people, process, and culture. Also, please join our LinkedIn page and visit our website at www.industry4oclub.com. So on behalf of Marcel and Tim, I want to wish everybody a great rest of the day, and, and, uh, thank you for joining during this, uh, the broadcast. Thanks, guys.

Bye-bye.