Tech4PD: Episode 11
Should your path to PLM implementation begin by organizing your data? Or does the most value derive from getting your processes enabled by PLM? Dueling analysts Jim Brown and Chad Jackson disagree. Vote for the most compelling argument. Loser suffers pain, as usual.
Each stage within product development, from concept to design, manufacturing, service and retirement, can be prone to great amounts of complexity, change and even uncertainty. The two key elements of PLM that can help streamline it all are data and process.
Each is significant in its own way. Process coordinates cross-functional activities to reduce risk and rework and ensures all expert parties are involved. Data, and a lot of it, is what defines the product, making it important to store the data correctly and accurately.
This brings us to the topic of debate in the latest Tech4PD episode: “Should your path to PLM implementation begin by organizing your data? Or does the most value derive from getting your processes enabled by PLM?”
In this instance, PTC calls it a tie and strongly supports both sides of the argument. With many multi-discipline engineering teams working together you have to have your data “in order” but without well-defined processes, the data can be under-used and the benefits of PLM lost. Each is essential and affects and drives the other concurrently in the big picture.
Chad: Hello and welcome to Tech4PD, I'm Chad Jackson.
Jim: And I'm Jim Brown. Today we're going to talk about whether you should focus on data or processes first when you look at PLM. Chad, maybe you can start and talk for a little bit about data.
Chad: Yeah, absolutely. So when you talk about data and PLM, actually they all have product development there's a lot of different levels you can go after. The first level is all about CAD, managing your 3-D models and all the documentation that goes with that, but even within engineering, you can expand beyond that and start to get into documentation like specifications, so on and so forth. But also you can expand beyond that even into the enterprise, so you start looking at service documentation, manufacturing documentation. So there's a lot just within the data management realm.
Jim: Right, and process is similar because you can look at some very simple processes that happen within a design team, things like revisioning processes, engineering change control, release to manufacturing. Those processes that are very finite, but also very important, but then PLM has really expanded to cover a whole range of processes, anything from in the quality world, things like failure and effects analysis, APQP, you can look at things like design for compliance. There's just a tremendous amount that you can do in the whole realm of product development and innovation and engineering from a process perspective. Lots of value to be had.
Chad: Yeah, that's absolutely true. And just to be clear, so today Jim and I are going to be debating what you should do first with PLM. Where should your focus start, whether it should be data or process, not whether you have those things under control to begin with, because obviously that's very important.
Jim: I would say so, so let's get to the debate.
Chad: Sounds good.
Jim: So let's jump into the debate, Chad being the data wonk that you are, I think we know the direction that we're going on this one.
Chad: Yeah, and I guess unpredictable so far, but it's not going to sway me from my position, so I do believe.
Jim: Don’t let the facts get in the way.
Chad: Especially when it supports you. So my position is that you do need to have your data under control, it should be your first focus for PLM. And we've had this adage in the industry for a long time, and I think it's still true that if you enable your processes first and it's enabled off of data that isn't under control, then you're probably going to be making decisions based on the wrong data, and you'll be making wrong decisions. So I think you've got to get it under control first and then you can move on to process.
Jim: Yeah, so I think differently, I mean, I think there is levels of data, right. There's files, there's CAD files, there are documents that you're going to manage that are just need to be revision controlled and managed and centralized so people can get to them, totally agree with that. Then when you go beyond that and you want to start to really enable processes, you want to do something, you want to accomplish a task with it, then you need to figure out who's going to do what in what sequence, and how does what I do support what you do, support the person downstream you. And in order to do that, you need to know that process flow first to know what data everybody needs to do their job. So if you don't understand the process, there's no way to understand what data is you need in the first place.
Chad: Yep, yep. I think that's a fair point, although I will say that people today are using things like email to run those processes and referencing their own data would still be a valid way to do that even if the data is done in a PLM system. However, I think there is also another issue, and it's around kind of a trend in many organizations today to try and enable their employees to think with a little less constraint, a little less rigor in terms of you must do A then B then C, and to make the right decisions for the organization.
And if you can get that working for the company, then the organizations stands for a lot of gains, there's a lot of opportunity there, so you don't want to reduce your employees just to dumb cattle to do the dots in a row. You want them to add value along the way.
Jim: Okay, so don't get me as signing everybody up for making your engineers dumb cattle, not a plan. Here's my thought, though. I would love to have, if I was going to have a parade, first of all dumb cattle aren't the right thing to do. What I would do is maybe having herd of really smart horses, a team of horses, and what they would do is they would all be trained to do things either in synchronized fashion or they would be doing things that were coordinating, and unless you know what people need to do to work as a team together, whether it's a work group an enterprise, then you don't know what you need to support it.
So I absolutely agree, people need to have flexibility to not have handcuffs on them. At the same time, you need to align what people are doing or it's chaos and mayhem instead of a business.
Chad: Interesting. I think that's a valid point. I think ultimately the question is: where does an organization get the most value as its first step in the PLM. Should it be get your data under control and have it centrally accessed and secure? That's what I advocate, and you're saying that the best value first is going to be enabling your processes, focusing there first.
Jim: Yeah, I mean short of, like, purely just controlling files yes. When you get into the PLM world then you're really starting to talk about accomplishing business initiatives, and tasks, absolutely. You have to have focus on processes first.
Chad: Okay, all right, I think this is going to be really interesting vote for the viewers to see where they see the most value, I think it's a very timely debate in the industry.
Jim: Absolutely. Peer into your crystal ball, Chad, what do you see?
Chad: So I think what's interesting about this debate, I think software providers are getting it little bit more smart about how they approach this conundrum. And I think what you're going to see is more integrated offerings where they really look at, what is the data you need to support the processes, and what is the process need in terms of data, and you're going to see incremental sets that you can deploy in one fell swoop, and it won't be, should I get my data under control or do I automate my processes. The question will come.
Jim: Yeah, I think what you're talking about is maturity of PLM as an enterprise application as opposed to just being data or processes. We're seeing an integrated solution that really ties the two together and already understands the problems that are to be solved, and has the data required for something like a quality process.
Jim: Already has thought through what that data is and not have to have every company develop that themselves, and I think absolutely you're right on the direction for those things.
The other thing I think we're going to see, too, is more composite applications where you've got different applications via ERP, supply chain, maybe service, and we're going to start to see applications that access data from different systems to accomplish a task. I think we're going to see more of that. And the granular nature of the data in the systems in APIs and that sort of thing, I think it's really there to support.
Chad: Yeah, that makes a ton of sense. All right, that's our crystal ball session. Now we get to your favorite part of the episode...
Jim: My favorite part.
Chad: Mine too but let's take a look at the consequence from the person that lost the last episode.
Jim: All right, it's Jim and because you're seeing me, it must mean that you believe that technology is ready and culture is ready to use simulation technology in the concept phase. I'm happy to hear that, and I'm glad people are willing to spend the right amount of time to get things right up front. So because of that, it's time for me to suffer the consequences. The consequence this time is to get a full makeover, and because we spare no expense on Tech4PD, we brought in a true professional designer to come in and do this, and she's decided that she's going to make me up to be, look like the coolest person she's ever met, which oddly enough is Chad Jackson. So I'd like to introduce Amanda, you may begin. Thank you to our fashion designer Amanda.
I'm Chad from Tech4PD, and I'm here to tell you Jim was wrong. So Chad, I'm not really sure why we do this.
Chad: Yeah, no kidding. It's an exercise in pain. So to close out, we'd like to thank our fellow sponsor PTC, making the show possible.
Jim: Thanks for joining us.