You are currently browsing the tag archive for the ‘Competitive’ tag.
The title of this post came in my mind when looking back on some of the activities I was involved in, in the past two weeks. I was discussing with several customers their progress or status of the current PLM integration. One of the trends was, that despite the IT department did their best to provide a good infrastructure for project or product related information, the users always found a problem ,why they could not use the system.
I believe the biggest challenge for every organization implementing PDM and later PLM is, to get all users aligned to store their information in a central location and to share it with others. Only in this manner a company can achieve the goal of having a single version of the truth.
With single version of the truth I mean – if I look in the PLM system I find there all the needed data to explain me the exact status of a product or a project.
If it is not in the PLM system, it does not exist !
How many companies can make that statement ?
If your company does not have the single version of the truth implemented yet , you might be throwing away money and even bring your company at risk in the long term. Why ? Let’s look at some undisclosed examples I learned in the past few weeks:
- A company ordering 16 pumps which on arrival where not the correct ones –
1 M Euro lost - During installation at a drilling site the equipment did not fit and had many clashes – 20 M Dollar lost, due to rework and penalties
- 7000 K Euro lost due to a wrong calculation based on the wrong information
- A major bid lost due to high price estimation due to lack of communication between the estimator and the engineering department
- 500 K Euro penalty for delivering the wrong information (and too late)
All the above examples – and I am sure it is just a tip of what is happening around the world – were related to the power & process industry, where of course high-capital projects run and the losses might look small related to the size of the projects.
But what was the source of all this: Users
Although the companies were using a PLM system, in one company a user decided that some of the data should not be in the system, but should be in his drawer, to assure proper usage (according to his statement, as otherwise when the data is public available, people might misuse the data) – or was it false job security as at the end you loose your job by this behavior.
People should bring value in collaboration not in sitting on the knowledge.
Another frequently heard complaint is that users decide the PLM system is too complex for them and it takes too much time for them to enter data. And as engineers have not been bothered by any kind of strict data management, as ERP users are used to work with, their complaints are echoed to the PLM implementer. The PLM implementer can spend a lot of time to customize or adapt the system to the user’s needs.
But will it be enough ? It is always subjective and from my experience, the more you customize the higher the future risks. What about upgrades or changes in the process ?
And can we say NO to the next wish of this almighty user ?
Is the PLM system to blame ?
The PLM system is often seen as the enemy of the data creator, as it forces a user in a certain pattern. Excel is much easier to use, some home-made macros and the user feels everything is under control (as long as he is around).
Open Source PLM somehow seems to address this challenge, as it does not create the feeling, that PLM Vendors only make their money from complex, unneeded functionality. Everything is under own control for the customer, they decide if the system is good enough.
PLM On Demand has even a harder job to convince the unwilling user, therefore they also position themselves as easy to use, friend of the user and enemy of the software developer. But at the end it is all about users committing to share and therefore adapt themselves to changes.
So without making a qualification of the different types of PLM systems, for me it is clear that:
The first step all users in a company should realize is that, by working together towards a single version of the truth for all product or project related data, it brings huge benefits. Remember the money lost due to errors because another version of data existed somewhere. This is where the most ROI for PLM is reported
Next step is to realize, it is a change process and by being open minded towards change, either motivated or pushed by the management, the change will make everyone’s work more balanced – not in the first three months but in the longer term.
Conclusion: Creating the single version of the truth for project or product data is required in any modern organization, to remain competitive and profitable. Reaching this goal might not be as easy for every person or company but the awards are high when reaching this very basic goal.
At the end it is about human contribution – not what the computer says:
Just back from the ECCAP in Tokyo where the Dassault Systemes roadmap for V6
combined with V5 was discussed and presented in the context of the Asian Pacific customers and companies.
As most of the activities around V6 are focusing on the future around a Service Oriented Approach (SOA), it might be interesting to look at Oleg Shilovitsky’s blog around PLM 2.0 . The conference kept me busy, so busy that I had almost no time to write this post, which actually targets a frequently heard message: We are too busy (to implement PLM / to do something else / etc …)
So in this post I want to conclude the sequel around reasons not to implement PLM. As a reminder:
The 5 reasons not to implement PLM I heard the most were:
- The costs for a PLM implementation are too high
- A PLM implementation takes too long
- We already have an ERP system
- Isn’t PLM the same as managing CAD files ?
- We are so busy, there is no time to have a PLM implementation in our company
And now, we reached #5
5. We are so busy, there is no time to have a PLM implementation in our company ?
Indeed a PLM implementation should not be underestimated. The impact on a company is significant if implemented correctly. I encountered two types of PLM implementations:
- implementations where the implementer automated the existing customer processes as-is, with a slight change due to chosen PLM capabilities.
- implementations where the implementer assisted the company in changing their current business process towards PLM capabilities and best practices provided by the system.
Both type of implementations might have consumed the same amount of money and implementation services. The impact on the company however is completely different.
In case 1 the benefits are relative low as mainly automation of repetitive tasks or data entry was optimized. People in the company did not need to change there way of working too much, and the impact on the way they worked was relative low.
Note: we have a work pressure of max 110 % (no big changes) but at the end we reach an effectivity below 120 % where the work pressure remains close to 100% (98 %)
This means thanks to automation we achieve 20 % more and feel just a little less pressure
(20 points difference between effectivity and pressure)
In case 2 the benefits were much higher as the changing of business processes lead to an optimized process for innovation and engineering changes, based on core PLM system capabilities and tuned for the company.
However the impact on people in the company was also much higher. Different ways of working, changed responsibilities, sharing of data all lead to a learning process.
Note: we have a work pressure close to 120 % but at the end we reach 95 % where the effectivity reaches 125 %
This means thanks to the automation we achieve 25 % more and feel approx 5 % less pressure
(30 point difference between effectivity and pressure)
The graphs are a generalization based on facts i learned in the field and I tried to visualize the impact of a PLM implementation on a company.
So now we have three options to:
- We have no time to implement – we are too busy
This leads to a dead end – assuming PLM is relevant for your company – it means the competitors will implement and get ahead of you. Making survival even harder and lead to stressed employees till it cracks
- We can implement PLM without changing our processes too much
This is what an inexperienced implementer will suggest. “Tell us how you want to work and we build it for you” . This leads to higher customization costs but probably less pressure on the organization to make changes. At the end as described in case 1 it will bring benefits but not affect the pressure so much. Consider it a band-aid till the next fix.
- We implement PLM as it supposed to improve our processes.
Implementing PLM with an experienced PLM implementer and a clear vision will lead to a higher pressure on the organization for approx a year and probably lower costs of customization, but higher temporary resources costs. However at the end it will provide the company with a base to be more competitive. Effectiveness has increased significant and reduced pressure can lead to new innovation
Conclusion
If your company would benefit from PLM according to its core business, delaying the implementation is giving your competitors more chances and will affect your market share. Next if you decide to implement PLM be aware that only by changing the way you work more in line with the PLM best practices for your industry you will gain the real benefits. For that reason you need an experienced PLM implementer as partner to guide you in this path.
Jos Voskuil's Weblog 
Jos, great thoughts about BOM management. Here are some of my thoughts. I can see how BOM management will evolve…
As a complement, even if more and more of the diversity of a product is managed at the software level…
1) A wiring diagram stores information (wires between ports of the electrical components) that does not exist in most of…
BOM has NEVER been the sole "master" of the Product. The DEFINITION FILE is ! For example the wiring of…
Interesting discussion about part numbers and where they originate. Though there seems to be consensus about the EBOM and MBOM,…