PLM yesterday and today - What has changed in PLM projects in the last 5-10 years
In the last 5-10 years, various effects have made an impact in the field of PLM.
In the past, people in PDM were very fixated on features & functions and the return on investment (ROI) calculation. Many believed in the Messiah of software. It was as if the mere purchase of the PDM system would make all the problems that companies had with the creation and lifecycling of product information disappear and the ROI that the PLM providers had calculated would then occur by itself.
The situation is roughly comparable to a tidiness problem at your home and you now believe that buying a new cabinet would solve the tidiness problem by itself. The right cabinet creates the basic prerequisite for good order, but that's it. This is exactly one of the insights that is finally catching on. With customers, I like to use the example of this Netflix series "Tidy up with Marie Kondo". I then say, in principle, what we do in the project is not unlike what Marie Kondo does.
There are a few more points that have changed. Not so long ago, the one-structure concept was preached. This was based on the idea that one product structure was sufficient to represent all aspects of the product. This approach assumed that the necessary views could be created ad hoc. The idea of the single structure concept has turned out not to correspond to reality. It is only suitable for a small number of very special cases. For all others, it has only led to even more excell lists and effort.
In the meantime, the multi-structure concept is being propagated. The name xBom is also often used for it. The multi-structure concept recognizes the fact that several different structures are created during product development, each of which also requires its own persistent structural semantics. Today, we can say very precisely in which case we need to establish which structures and how they should be structured in terms of their structural semantics. This is already an enormous step, but it is hardly ever seen because only a few experts are able to penetrate the subject matter and then explain it in a comprehensible way from the perspective of the companies.
However, there is one change that is the most important from my point of view. Up to now, the prevailing conviction was that it was sufficient to use tools of classic process modeling in order to be able to model and design the processes in PLM. Due to this conviction, companies often create wallpapers of process sequences that are built up over years for a lot of money and then are of little or no use.
That has its past: Process modeling was/is essentially used in the context of ERP implementation. There it also works very well for some reasons. In ERP, there are very formal processes that run transactionally on a hierarchy level. This is a perfect use case for process modeling and this is where it originated.
Over 90% of the creative activities that generate information about the product in the product lifecycle are not sufficiently formal, so modeling focused solely on processes fails. To design these processes, it is necessary to model the flow of product information across the different product structures. We call this the information architecture. In order to be able to shed light on this, we have developed in our Steinbeis Transfer Center (STZ-RIM) Tools for modeling the flow of information across the information architecture, as well as for modeling the structure semantics developed.
When I used to show these approaches, people from the companies looked at me with many question marks in their eyes. Today, they are often excited and eager to learn the methods to be able to discuss, understand and implement these topics on their own.
The pressure for digitization that prevails today naturally forces this. In the past, the focus was not on digitally available information. Everything revolved around the mostly order-related development and construction of the physical product. After the product left the ramp and was accepted by the customer, the next order was taken care of.
In the scenario described, it was enough that essential carriers of information were the people who shouted things to each other. Often there was the artist and hero mentality in mechanical engineering companies. Then there were the heroes in production, we'll call them Kalle and Paule. Kalle and Paule could be "called something" - that's how we say it in the Southwest. Here, it is the highest praise to say about someone: "You can be worth something". By this, we mean that you can give these people an almost insoluble technical task and they then manage to do it perfectly and on time. So Kalle and Paule often got rough drawings and pages of e-plans thrown at them by the artists from development, and then they got it right. In the end, the product was delivered to the customer on time and everyone was satisfied.
That has changed fundamentally. Today, customers expect the necessary digital information about the product in its current state of modification, and they also expect much more comprehensive after-sales service than in the past. If a service employee has to come on site first to find out which components have been installed and which software has been installed, this is increasingly met with a lack of understanding. As a result of the pressure building up from this direction, the realization is increasingly gaining ground that end-to-end management of product information and, in particular, the clean, explicit, digital storage of this information in backbone systems represents a central enabler for the business process capability of companies.
For consultants like me, this makes many things easier, because a lot of effort that used to be put into persuasion is no longer needed, and you can tackle the essential issues more directly.
