Last week I started a small series of posts related to the topic PLM 2.0. I was hoping for more comments and discussion about the term PLM 2.0, although I must say I was glad Oleg picked it up in his posts: PLM 2.0 born to die? and Will JT-open enable future of PLM 2.0?
Oleg, as a full-time blogger, of course had the time to draw the conclusions, which will take me another two weeks, hoping meanwhile the discussion evolves. Where Oleg’s focus is on technology and openness (which are important points), I will also explain that PLM 2.0 is a change in doing business, but this will be in next week’s post.
This week I will focus on the current challenges and pitfalls in PLM. And we all know that when somebody talks about challenges, there might be problems.
Last week | : What is PLM 2.0? |
This week: | : Challenges in current PLM |
Next | : Change in business |
Final post | : Why PLM 2.0 – conclusions |
The Challenges in current PLM
First I want to state that there are several types of definition in the world for PLM, coming from different type of organizations – I listed here two vendor independent definitions:
In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.
Product Lifecycle Management (PLM) is the business activity of managing a company’s products all the way across the lifecycle in the most effective way. The objective of PLM is to improve company revenues and income by maximizing the value of the product portfolio
And there are more definitions. Just recently, I noticed on the PlanetPTC blog from Aibhe Coughlan a post where she promoted a definition of PLM published in the Concurrent Engineering blog. Here I got immediate a little irritated reading the first words: “PLM is software designed to enhance process efficiencies ……… and more …”
I do not believe PLM is software. Yes there is software used to automate or implement PLM practices, but this definition starts to neglect the culture and process sides of PLM. And as Oleg was faster – read his more extended comment here
(I am not paid by Oleg to promote his blog, but we seem to have similar interests)
Back to the classical definitions
The Wiki definition gives the impression that you need to have an infrastructure to manage (store) all product data in order to serve as an information backbone for the extended enterprise. It becomes more an IT-project, often sponsored by the IT-department, with the main goal to provide information services to the company in a standardized manner.
This type of PLM implementations tends to be the same type of implementation as an ERP system or other major IT-system. In this type of top-down implementations, the classical best practices for project management should be followed. This means:
- A clear vision
- Management sponsorship
- A steering committee
- A skilled project leader and team
- Committed resources
- Power user involvement
- Communication
- …… and more …
These PLM projects are promoted by PLM vendors and consultants as the best way to implement PLM. And there are a lot of positive things to say about this approach. For many big companies implementing cPDM or PLM was a major step forward. Most of the ROI stories are based on this type of implementations and have been the showcases on PLM events. It is true that data quality increases, therefore efficiency and product quality. Without PLM they would not reach the same competiveness as they have now.
But sometimes these projects go into extreme when satisfying users or IT-guidelines
To avoid the implementation of a ‘new IT-system’, companies often have the strategy that if we already have an ERP-system , let’s customize or extend it, so we can store the additional data and perform workflow processes based on this system.
In a recent webinar, I heard a speaker saying that in their company they had the following automation strategy defined together with IT is:
- First they will see if the needed PLM functionality exists in their ERP system or is part of the portfolio of their ERP provider. If the functionality is there (this means the ERP vendor has the capability to store metadata and a factsheet mentioning the right name), there is no looking outside.
- If the functionality is not there, there will be a discussion with the ERP vendor or implementer to build it on top of their ERP system.
I have seen implementations where the company has developed complete custom user interfaces in order to get user acceptance (the users would not accept the standard graphical interface). At that time, no one raised the flag about future maintenance and evolution of these custom environments. The mood was: we kept it simple – one single system.
I believe this closes the door for real PLM, as storing data in a system does not mean you will use it in an efficient and optimized manner. How will you anticipate on changes in business if it is just doing more with the same system?
And mid-market companies ?
The top-down approach described before is the fear of many mid-market companies, as they remember how painful their first ERP implementation was. And now with PLM it is even more unclear. PLM aims to involve the engineering department, which so far has not worked in a very procedural manner. Informal and ad-hoc communication combined with personal skills within this department was often the key for success.
And now an unfriendly system is brought in, with low or little usability, pushing these creative people to enter data without seeing any benefits. The organization downstream benefits but this will be only noticed later in time. And for the engineering department it will take more effort to change their work methodology focused on innovation. However, in general in the mid-market, the target of a PLM project is to have a Return on Investment (ROI) in a very short timeframe ( 1-2 years). Investing in usability should be even more important for this type of companies as there is less top-down pressure to accept this new PLM system.
And flexibility ?
In the past years we have seen that business is changing – there is a shift in global collaboration and manufacturing and from the recent history we can learn that those big enterprise projects from the past became a threat. Instead of being able to implement new concepts or new technology, the implementation became more and more vendor monolithic as other capabilities and applications do not fit anymore. This is against the concept of openness and being flexible for the future. I believe if PLM becomes as rigid as ERP, it blocks companies to innovate – the challenge for big companies is to find the balance between stability and flexibility (This was the title from Sony Ericsson’s presentation at the PLM forum in Sweden this year)
And again for mid-market companies who do not have the budget or resources to invest in similar projects. They have less a drive to optimize themselves in the same manner as big companies do as flexibility is often their trade mark (and capability to innovate) . So PLM for the mid-market will not work in the classical way.
This is one of the reasons why a mid-market PLM standard has not yet been found (yet ?). From the other hand many mid-market companies are dealing with PLM practices although often it is more close to PDM and CAD data management. And mid-market companies do not change their organization easily – there is more a departmental approach avoiding therefore a change in business.
To summarize the biggest challenges in current PLM described in this post:
- PLM is considered complex to implement
- PLM is a huge IT-project
- PLM requires change and structuring – but what about flexibility
- Where is the PLM value and ROI – user acceptance
- PLM for the mid-market – does it exist ?
Conclusion: I have been writing about the PLM challenges in the past, see the links below if you are interested in more details on a specific topic.
In 2008,I thought that Out-of-the-Box PLM systems and standard functionalities could bring a solution for the mid-market, perhaps future solutions based on the cloud. However I learned that if you want to do real PLM in a modern manner, you need to change the way you do your business – and this I will explain in my upcoming post.
Related links:
3 comments
Comments feed for this article
September 8, 2011 at 5:33 pm
Alan Taracuk
Sorry for getting to the party late so my comments address elements of Parts 1 & 2. I do not believe that PLM 2.0 as depicted in the charts in the first post replaces PLM 1.0. There will always be a need for some organization, structure, processes… but there is also a need for ad-hoc, communities… You can probably line these up around structure vs flexibility whatever the point is PLM in its broadest sense needs to address and support both. The question is where does your organization draw the line and what parts of the lifecycle spectrum does your PLM implementation support.
If all you have implemented is support for release and engineering change then structure may be more important than flexiblity. In my world, your innovation processes and your development processes are different and they need to be managed and supported differently. So you if you are trying to use “production release” management practices, processes and tools to support Front-End Innovation then good luck with your Return on Innovation. On the other hand, if you are completely flexible and ad-hoc on how you release changes to the plant, good luck with your quality and engineering/manufcaturing relations.
If we examine the PLM and PLM 2.0 elements from Part 1, some comments can be made. The days of long development cycles are done for almost any industry. That being said, across the lifecycle there is a time and place for everyone of these capabilities. Unfortunately, too much of PLM of PLM Branding is being driven by the large vendors with their own agenda. If PLM 2.0 is truly more about the blending of those PLM and PLM 2.0 capabilites the question is how do we as implementers and users select and implement those practices, processes and tools that support our needs across the lifecycle regardless of whose logo is on the top of the screen.
To me, PLM is a journey not an event. The challenges identified are real, the manner in which you deal with them depends on your situation and the path you envision and execute for your journey. While many IT organizations are best when dealing with event projects, IT needs to be a strategic partner from the beginning of the PLM journey in order to increase the probabilty of success in its largest sense.
Alan thanks for your valuable response.
For sure you are not late. I do not want to post my conclusions already here but you are right, there is no PLM 1.0 and next PLM 2.0 – it will be a mix depending on the type of company you are working in. And in relation to this point, I agree you can have areas where flexibillity is not desired, where at other places it is a must. I fully agree with your comments.
Best regards Jos
LikeLike
September 9, 2011 at 5:17 pm
Steve Porter
Jos,
I too aplogize for becoming aware of your series late. I really appreciate your perspective on PLM and particularly agree with your sentiments about trying to retrofit ERP to handle PLM functions and the results of this strategy. I do also agree that we are in somewhat of a transition for PLM. It is becoming more mainstream and more viable for smaller companies. From an IT perspective PLM is becoming less intimidating. Virtualization and Cloud Computing mean that even companies under a 100 million in revenue can easily support the overhead requirements of most PLM tools. I also believe as we get more small company implementations under our belt that the process becomes less challenging for companies. There are patterns that allow for PLM implementation resources to minimize the cost and time it takes to put PLM in place. I also think the user interfaces are improving as evidenced by the latest versions of Agile and PDMlink.
I am not sure I see the clear break from PLM 1.0 to 2.0 but I do see a shifting landscape where PLM is becoming less expensive to own and implement and easier to use. If breaking that down into versions helps define this process then I think it is a good thing.
Steve – thanks for your feedback – you are not late in the discussion – we are in the middle of the discussion and your thoughts are welcome in this stage – I agree there is a shift on-going – the question I hope to address in my next post is if this is going in the right direction and what could be changed. Stay posted and interact.
Best regards
Jos
LikeLike
September 9, 2011 at 5:43 pm
Stephen Porter
Jos,
I too apologize for becoming aware of your series late. I really appreciate your perspective on PLM and particularly agree with your sentiments about trying to retrofit ERP to handle PLM functions and the results of this strategy. I do also agree that we are in somewhat of a transition for PLM. It is becoming more mainstream and more viable for smaller companies. From an IT perspective PLM is becoming less intimidating. Virtualization and Cloud Computing mean that even companies under a 100 million in revenue can easily support the overhead requirements of most PLM tools. I also believe as we get more small company implementations under our belt that the process becomes less challenging for companies. There are patterns that allow for PLM implementation resources to minimize the cost and time it takes to put PLM in place. I also think the user interfaces are improving as evidenced by the latest versions of Agile and PDMlink.
I am not sure I see the clear break from PLM 1.0 to 2.0 but I do see a shifting landscape where PLM is becoming less expensive to own and implement and easier to use. If breaking that down into versions helps define this process then I think it is a good thing.
LikeLike