Rhiannon Gallagher sat down with Ryan Gelotte to talk about failure and MBD. It happens. And of course, the people aren’t the problem. Not talking to them is. So, what you do next can make a big difference.
Why do you think failure is not a bad thing when it comes to MBD?
I don’t think anybody can argue that failure is the best educator. At a high level, that to me is the punchline. We know that everybody’s going to fail the first time they try MBD. Now how a company failed and whether they’re going to take advantage of the opportunity to learn from it, that’s really up to them. They may just say, “We’re moving on, we are not even going to bother with this anymore.” At a minimum, a failed MBD implementation should at least uncover where it’s failing, right? And maybe where they need to put their focus on, on the next attempt. Then we get into the whole tactical iterative pilot approach to mature and to pace their journey.
Is part of the problem that too many companies are thinking this is a Product Definition or an IT Tools initiative?
Yes, if you do it as an IT project or a tools project, it will expose the failure points, the big failure points, and then you can start prioritizing. The MBD transition often isn’t a problem for design, they liked it. They hated creating drawings anyway. So we know the problem isn’t there.
But too many companies are thinking, well product definition must have done something wrong, so then they just keep iterating and having product engineering try it different. Maybe what product engineering did was fine, but your machinists tell them, “Just give us your drawings.” Then we know it’s a problem in operations, and it may expose somewhere else that you didn’t even think of, like quality or in your supply chain, and so on.
The key to that kind of failure is failing fast, so you don’t make the scope of your implementation so big. You plan to fail, so make your first pilot an educational academic exercise. Too often, companies finish the design and create a 3D PDF and say, “Oh, that looks awesome. And it looks modern, it’s 3D.” Then all the executives get really excited, but downstream operations and quality or suppliers just say, “No can’t do this,” and you’re stuck. You just learned nothing from that, other than that you can create a 3D model with annotations and publish a 3D PDF. That is not the same thing as a pilot. You created a cool presentation artifact and went out and convinced the company that everybody wants some of this, and you never sent it to the shop floor.
How do you think it goes better the second time?
Holistically, what is MBD and MBE? It’s a communications initiative. The more MBD and MBE projects I’ve been a part of, the more I realized this is a communications initiative. I remember I was in engineering classes and all my friends were MIS, Management Information Systems. What is IT? It’s information technology. And so it really comes down to communication of information. And everybody is a bunch of engineering tools geeks and is so focused on machine-readable information, that’s all they ever want to talk about. They spend so much time and energy making stuff that’s machine-readable without checking in with the people that also need to use the information they’re communicating.
SkyNet isn’t here yet. There are still people in factories. Sure, automation is huge in the world of manufacturing and increasing your throughput, but there are still people involved. So the second time, focus on the failure points, and it gets very simple. The people who said they couldn’t achieve some task or whatever they need to do to get their job done? Go talk to them. It’s that whole subtle play of, “I need that dimension.” “Okay. Well, what do you really need? What do you need it for?” When you ask the right questions and dig into it, MBD can help them. They’re putting something down on a plate, and then they need to turn the crank up 4 inches because that’s what the dimension was. Okay, what they need to know is how far this surface needs to be from this surface, it’s that information that they need, not the dimension.
Talk to your stakeholders and find out what information these people need. Not what the machines need, we all know what the machines need, everyone has been talking about it for 15 years. The reason your MBD implementation is failing isn’t because the machines can’t read it, although there is still a long way for the tools to go.
How do you know when you have a successful pilot?
Success is partly defining your desired outcome. If your desired outcome is that we can design, build, qualify, and sell this product without a drawing, then your next pilot’s going to fail. But if the purpose of the pilot is to figure out how a CMM programmer can use MBD to automate the creation of a CMM program, that’s one very specific user story at the end of your pilot, then you’re not going to fail. You’re going to achieve the results of that particular pilot. Basically, you need to start with that, look at all the people that look at the drawing and ask about what kind of information they get from that drawing. Nobody wants to do that. Everybody just wants to go right to the end state and say, “Hey, you had a drawing, now you have a model, now go do it.”
But that just doesn’t work, and it hurts your budget and your credibility every time. You must do it incrementally, iteratively, and learn from the little failures along the way. You need to say “For this new product development project, we’re going to pick three or four capabilities and also create an MBD version of this, and as we’re going through, we’re going to pilot these new MBE capabilities, and not only just the tools, but the information that the people need and the training.” From the get-go, get corporate communications involved in this, because that’s what we’re doing, we’re changing the way everybody communicates.
