In this talk Hermann Paetzold examines why companies pursue Product Lifecycle Management (PLM) and what cultural, organizational, and technical factors determine success. He argues that genuine business motivation is essential; without a clear understanding of PLM’s value, projects become forced experiments. Paetzold contrasts “Big Bang” migrations (e.g., moving an entire data schema from Teamcenter Enterprise to Teamcenter Unified) with incremental roll‑outs, noting that the optimal approach depends on whether the change is purely IT‑driven or also involves process redesign. He stresses that business and IT must collaborate from the start, sharing requirements and architectural decisions, otherwise communication breakdowns erode profit and delay delivery. A user‑centric perspective is crucial: tools must fit daily work, not the other way around, and early adopters act as cultural “infectors” who demonstrate PLM’s benefits, encouraging broader acceptance. Defined processes enable measurement; PLM provides real‑time data that fuels continuous improvement cycles, but only if users follow the prescribed procedures. Overall, Paetzold presents PLM adoption as a cultural transformation that requires clear motivation, coordinated change management, user focus, measurable processes, and champion users.
Chapters
Yes, the difficulty is all the time: do you really want to have a PLM? Because sometimes people want to have a PLM because the others want a PLM. That means they do not really know whether the PLM is good for the business. If people are really convinced that they want PLM and they know exactly why this PLM is really giving more benefit for the organization, then they have really enough power to go through these steps. Because what they have to do really, they have to invent the organization again with running these PLM systems, and this is quite difficult because because people don't like change. And if you do not this in a way that there's really a big step to that new practice, then people continue to work on the current practice. And this fails usually because, yes, the people continue the old practice with the new tool, and then they have double work because they work in the old fashion, and then later they add basically tasks which are related to PLM, and this is not beneficial for the organization. Yes, the issue there is that people usually focus on the application. They talk about PLM and then the first thinking is we want to have a system and behind that there is a kind of myth again, yeah, to have something automatic and this is then reducing the work. And this doesn't work because basically the computer is like a new member in the organization. And you have to give them the task this computer can manage. And then you have to define really all the procedures step by step, and people do not want to do that. That means they have a tool and then nobody knows really how to use it, and the user directly in front of the screen is lost. And yes, this is the case. Yes, this is quite a good question because there is not really an answer in the way Big Bang is all the time good and step-by-step is not all the time— is not good. I did both in my career and the basic question basically is what companies can manage because they are running a business process and in the end they have to ship products. That means everything you do on that level of tools must fit somehow in the business process. I did a big bang approach in moving from Teamcenter Enterprise to Teamcenter Unified, but this was Pure IT. We took the complete data scheme and workflows and moved it from Teamcenter Enterprise to Teamcenter Unified. No changes in the practice of people. People only had to switch from one tool to another one. That means a little bit training, nothing else. But if you change the procedures, then it's really important that you do it in a safe way that business continues. Otherwise it doesn't work. But for the user, it's important that he has a kind of Big Bang, because otherwise he works in several systems and this is not good for the user. From my experience, currently there is very often there's a fight because business says we are telling what IT has to do, and IT says business doesn't have any clue what they really want. And I think if you start doing like that, you lose a lot of profits because people then have emails back and forth and the distribution list gets longer and longer. The best would be if both of them are really collaborating. Business with IT. Of course, there is very clearly business gives the business requirements and IT on the other side decides about the application architecture, but both of them of course have behind the business strategy. That means basically they have a collaborative basis and based on that they can really start their innovation because because it's all about innovation. The business has requirements and they want to be better in shipping products. On the other side, IT is a service and they have to support them to ship products. If on IT side, business, if on IT side people understand the business, then of course they really can collaborate and then in the end you have good innovative tools supporting the business. Yeah, it's all about communication, and if people do not understand changes, how can they perform the change? It doesn't work. The issue is if you have these big projects of introducing PLM or introducing SAP, then the organization is all the time challenged a lot. Each manager knows that communication is important, but the resources for communication are not available because they are eaten up by all the other tasks. And therefore, a mismatch is getting up, then people are not informed and the complete change doesn't really work. Yes, the question is, is it— yeah, who is in the organization the user? Basically, if I go to my boss and tell to him I want to figure out something which is user-centric. Then my boss says, "Hmm, not user-centric, the organization is central, our business process is central." And then there is really a difficulty because you come up with tools, you come up with procedures which are not really fitting the user. And I think we have to turn it the other way around. Of course, the organization want to survive first. This is number one. Then of course they want to earn money, but if they want to earn money, they have to take care that users can really work in a profitable kind of way. That means if you are clever, basically, then you take care that the user can work with the tool in a way he can really solve the daily problems. If the user can't do that, that means he is all the time interrupted in this work because something doesn't work, then it's not good for the organization. That means in the end we look for a good business process, but we take care that the user can work in the best way. I'm infected by PLM. I like it because I see the benefits, and I think to see the benefits, this is something you experience together with your colleagues. If you start to work on PLM and you have colleagues which see the potential and they fight for it and they see, yes, we can win there something, we can win there something, 'Yes, I personally got in love because I saw these people working on that and now I really, yeah, I really have, I feel that kind of benefit.' That means for an organization to come to this atmosphere, it's important that innovation is possible, that these people, yeah, these are early adopters, that these people are really supported and in the end they can really bring the company one step forward and these people are infecting the other ones. That means then you come to the status of loving PLM. You can measure all the time something which is really defined. That means if you have a process which is not really defined, then you can't measure it. If you have a process which is defined, this is the first step, this is good, but the second is you have to take care that users are really following that process. If this is the case and you measure something, then you really measure what is happening there. If people, for example, are disturbed by firefightings, then in the end you do not have good measurement. Usually, if you do not have PLM, it's not required to define the supporting procedures in a very defined way, and therefore it's difficult to measure that. But as soon as you have PLM, if you do it in a way which in the end brings you benefit, You have to define the supporting procedures and then you can measure it. The big benefit is if you have PLM implemented, then you see exactly when the deliverables are in the system and then you have this new member in your organization which supports you to get this real data. And then with these data, you are capable to have this improvement cycles. Yes, it means again, PLM is really then the, yeah, the tool which supports you to, yeah, to use that feedback for that additional improvement. And I think this is a big advantage, but currently if I look to organizations, it's only on very few places implemented. If you look for users, then there are different kinds of users. On one side there are managers. Mainly I am currently thinking about users really working on day-to-day issues. And for them, getting a new tool, the question is all the time, do they support it or do they not support it? And I can understand people resisting that change because sometimes the tools difficult, they are not really helping them. But sometimes this is only the case in the beginning. I would really recommend that they really have a look to get clear, concise and valid data in the system and give them a challenge or even a challenge for, yeah, for a certain improvement until the tool is really working. Yeah, if you resist in the end, then it's negative for everybody. Doesn't help the organization, doesn't help the users.
