8-key indicators for PLM readiness of companies
One of the biggest hurdles to PLM success is the lack of PLM readiness in the companies concerned.
PLM-ready companies have developed in basic tenor the 8 following conviction from top management to the working level!
- The availability of well-constructed and correct information is seen as a basic prerequisite for business process capability and thus the success of companies.
- The organization and design of the flow of product information in the company are understood as a lever to achieve the company's goals.
- It is clear that the design of the information architecture must also take place at the strategic/tactical level and cannot be left solely to clerks at the operational level.
- It is recognized that the flow of information from the market/customer, through the company and back to the customer must be considered holistically, i.e. end-to-end.
- Measures have been taken to ensure that shaping the flow of information does not stop at departmental boundaries.
- There is an awareness that the early availability of information upstream (towards development) generates more work, but this is well invested as it avoids a lot of problems downstream (towards production). This extra work that occurs upstream is then also accounted for in terms of capacity.
- A PLM introduction is not compared with the introduction of an application in the sense of authoring systems, but it is known that it has an effect on a large number of central business processes of the company.
However, PLM readiness alone is not enough.
There are a number of things that have been hidden for a long time and in the past you just had to hope that things would go right.
Today, we can formulate these hidden things much more precisely. PLM implementations lie in different Process pattern of the information architecture. These patterns do not depend primarily on the industry, as is often assumed, but on how a company wants to position itself strategically in relation to the market. Which of these Process pattern The question of whether a company wants to or must control a solution is therefore a strategic management decision made by the company itself. This must not and cannot be made by a solution architect, who is the PLM Implementation accompanied be taken from the gut.
Added to this are the weaknesses of today's PLM systems. These originate from PDM systems, which often did not know the material. Even today, most of them have large gaps in dealing with material, especially when the modeling of the material in the plant reference becomes necessary. When I see how this is sometimes implemented and what solutions are propagated, my hair stands on end.
This sometimes has the effect that some solution architects push the customer toward an unsuitable solution because they feel this gap with the material in their stomach and want to proactively avoid it. The customer is then often unable to outline this and goes along with the proposed path until it comes to a crashing halt in the project.
As you can see, PLM projects contain a very explosive mix without anyone being aware of it. If, against the background explained, dissatisfaction arises among the employee concerned, this is of course justified, since what they are getting does not correspond to what they really need.
What process capability is to be obtained
I think and propagate that it is necessary to think the implementation of PLM fundamentally differently. Before the project, the question must be answered which process capability a company wants to achieve tomorrow and in the future. This also makes the statement "but we have always done it this way" superfluous. If this statement were correct, the project would not exist, since the process capability would already exist in the status quo. The answer to the necessary process capability is followed by the choice of the necessary Process pattern for the information architecture. Such a process pattern affects the company as a whole, i.e. also all backbone systems implemented or to be implemented there, i.e. CRM/PLM/ERP and MES.
Adapt process mutters
The process patterns can now be adapted by the companies by creating an overall concept for process capability and information architecture adapted to the company, which must first of all be agreed with the important stakeholders in the company. It is not just a matter of getting the okay for the concept, but rather of generating acceptance of the change that goes hand in hand with it.
At this point, a state is reached where it should be clear to all stakeholders what needs to be done, why it is being done, and what the big goal behind it all is. Then the essential basis has been created.
Detailing the Alpha Edition
Now the conception must be detailed, distributed to the backbone systems and cut into realizable slices. In principle, I recommend testing this detailed concept on a short list of possible backbone systems. It is not enough to be shown a solution and then to query the existence of desired functions on the basis of long Excel lists. This is a procedure from the 90s of the last century, and when I see consulting companies propagating this today, I can only shake my head. Testing in a kind of digitization lab in the company is not just about checking the suitability of the system in question. It must be understood much more as a place for developing the future process and PLM capabilities of a company. In this digitization lab, employees are introduced to and trained in the technologies. In addition, the technology that is right for the company is still being evaluated.
Accompanying change management
If the whole thing is flanked by a suitable change management approach, so that communication into the company also runs smoothly, implementation becomes much easier. The problem with this approach is the need for a larger budget. No matter how you slice it, eventually the costs are incurred anyway. Process capability is a capability that is driven by the self-image of one's own employees. It's not something you buy in with an IT system. If you ignore the preparation at the beginning and act as if it were not necessary, you will be in for a nasty surprise later.
I also have an example of this, based on a true story. Once upon a time there was a PLM system consultant who was involved in a PLM project at a large medium-sized company. This PLM system consultant had the problem that he had to create rights and roles in the system. Thus, he raised the question of who was allowed to access what and when at the administrator level. The clerks did not know this and asked their manager. The manager was upset. Role and rights was something that needed to be clarified internally at a higher management level, not at the clerk level in the PLM project. When the PLM system consultant came to the next meeting, he wondered why it felt like he was talking to a deaf, cold wall. He didn't get the answer he needed, nor could he continue to do his job. Then, over a year later, when concept slides with the management's view of roles and rights, created in the project with the support of expensive strategy consultants, arrived at the PLM system consultant, this concept was in no way implementable.
In the end, the system provider was to blame with its poor PLM system consultants. The system provider's sales staff groveled with the customer and gave him their best PLM methods consultant for over a year.
Yes, that's how it was back then. Admittedly, this story is a little exaggerated, but in essence it really did happen that way.
