You are currently browsing the category archive for the ‘PLM’ category.
The past few weeks a had various moments to interrogate myself about the values for PLM and what would be the best way to address PLM for a mid-market company.
First I was in Copenhagen, attending the Microsoft Convergence event. A meeting where Dynamic customers, resellers and partners from all around Europe came together to learn the latest from Microsoft, to network with other partners and discuss their business processes.
Of course the focus from all of the 4000 attendees was around logistical processes, I was very curious to learn how manufacturing companies would describe their needs and where they feel the missing link – PLM.
But they did not feel it ……….
I believe this is one of the most challenging issues for mid-market companies. They have been investing in their ERP system and consider this as the company’s backbone. Their production and finance is dependent on it. Other departments, like sales and engineering provide somehow their inputs to the system, often Excel is here the information carrier. No PLM vision exist – or in case it exists – it is perfectly hidden.
I touched this topic in one of my previous post, called: “We do not need PLM, we already have ERP”
So why is PLM not yet adopted by mid-market companies and I raise this question mainly for those companies that obvious would benefit from PLM ?
I believe the major reason is the fact that often in mid-market companies there is no high-level strategy available analyzing where the company should be in 5 years from now and what are the challenges to overcome. Most of the companies I am currently working with want to implement something they call PLM, but often it is just PDM.
The big difference between PLM and PDM is that PLM requires the company to work different across departments, where PDM is considered more as an automated way to centralize product data, without changing the department responsibilities.
And now some generalizations
In addition mid-market CAD resellers try to explain their customers that PLM is only for big enterprises and that they just need PDM. This of course makes their sales beyond CAD easier, as touching cross-departmental processes requires different knowledge (which their resellers do not have), a different product (which they do not sell) and of course a longer sales cycle.
The same happens from the ERP side. ERP resellers consider what happens in the engineering department as a black box, where product data is generated and at the end a (configurable) Bill Of Materials. ERP vendors do not jump on PLM as extending the process to engineering requires different knowledge (which is not their domain) , a more extended product (which they do not have (yet))
Mid-market companies are of course influenced by these resellers of their core components and as mentioned before do not have the time and budget to take a strategic, holistic view where the company should be in 5 years. Usually their focus is on solving the pains they experience in their organization. For example we have too many databases and spreadsheets per department, let’s put them all in one central place – more an IT focus then a business focus.
So how to get the vision ?
Companies should ask themselves the following questions:
- what is the success of my company ?
- will I still be successful in 5 years from now if I keep on doing the same ?
- how does globalization affect me ? Risks but also challenges.
- how do I capture the knowledge of my (experienced) workforce before they retire ?
To answer these questions (and the above ones are only the most probing) it requires time and understanding to build a vision. Perhaps the economical downturn creates the opportunity or need to prepare for the future (survival).
And if you are working in a mid-market manufacturing company, chances are big that implementing PLM is a way to guarantee the company’s future and success. This has been proven in big enterprises and mid-market companies are not so different at the end.
Adapting business processes and connecting the whole product lifecycle are key activities. Beyond PDM and ERP it brings portfolio management (which product bring the real revenue) and innovation (New Product Introduction – how do we make sure we introduce a good product in the market).
Conclusion
PLM requires a company vision and strategy. Building the vision is something that PLM vendors, business consultants and others can assist you with. Each group has its own pro’s and con’s but at the end it is the vision that is needed before making the change – it requires first of all an investment in brain power – not in products
Interesting to read:
Stay with the business processes or change them ?
This time a more theoretical post about classification in PLM. A topic that always has been around for more than a decade. Recently classification also came up in some discussions both with customers and on discussion groups on the Internet. So what I will try to do in this post, is to explain the goals of classification, the ways classification is implemented and finally how I see classification will evolve. As always feel free to comment or extend my post.
The goals
Classification is a generic understanding, so to start I want to narrow classification to item classification. Companies might use classification in various ways, for products, for knowledge, for supported functions and more. The most discussed topic in the context of PLM however is item classification. The idea of item classification is twofold: understand what you already have (designed) and promote reuse. Historically the item definition has been stored in the ERP system and reuse was mainly based on recognizing parts of the description. Sometimes the ERP system also supported a kind of classification id to group certain parts – like fasteners, frames, base materials etc.
With the introduction of electronic parts this rough classification as defined in ERP became insufficient as already the description and classification id were not enough to really understand if an item could be reused. During that same period of time more and more companies where merging or acquiring other companies and they want to understand and benefit from items already used in one of the companies.
So this brings back the challenge for the two goals mentioned:
- How can I make sure my engineering reuse existing items in future products ?
- How can i consolidate and understand items i have used in my company ?
Item reuse
In order to promote item reuse companies have used various classification systems in engineering to promote reuse and standardization within the company. Design catalogs with standard purchase parts, extended with company standard parts were implemented to limit the variety of choices for a designer. Companies & Products like Trace Parts, SolidWorks Toolbox, Inventor Content Center address this need.
Additional mostly in the German speaking countries a classification standard exists, called sachmerkmahl leiste (sorry only in German) or often referred to in the context of the DIN 4000 standard. This is also a standard classification standard, less CAD design centric. Interesting to analyze why this standard does not exist in other countries.
One of the reasons might be that classifying all your engineering data takes a lot of time – specially when you haven’t done it from the start. I worked with some companies where more than a man-year was spent on classifying information. This work had to be done by someone with engineering knowledge, so you can imagine the investment for classification, beside the software was huge. Main question is, what will be the (expected) Return On Investment ?
In this area I think that a cultural difference plays a role here. Some countries invest more in their working methodology and processes than others where the focus might be only on the single result. From my global experience to be fair, i have not seen and heard the real benefits of this type of classification for reuse. I am looking forward for statements from companies that have measurable result here. Like many IT projects we have the emotional feeling that this approach should bring benefits
Item Consolidation
In the mid nineties when companies started to merge, PDM became PLM, CRM became important, also another trend became visible. The need for item classification systems, more on the inventory side, for companies to understand which items they were using around their (merged) enterprises. One of the first companies that time was Aspect Development Inc, later in 2000 merged with I2. Customer case studies learned us that in some of these enterprises a single item could exist with 100 different ID’s, all described or classified in various departments a little different, so hard to reuse. Only by classifying items within an enterprise based on their specific characteristics, people start to recognize identical items. Also in smaller mid-market companies I have seen situations where items have been named or identified just a little bit different, although they were the same.
Here benefits of item consolidation can be easier justified. I assume most companies can estimate what is the total cost of handling an item through its lifecycle and what are the purchase benefits by consolidating for example 10 different named into a single item to be purchased in a much bigger quota.
The benefits really come when you control your inventory and from this base feed the engineering department with an optimized selection of validated items for reuse. And this is to my opinion the most important goal of classification
How to implement classification ?
As described above classification is needed to promote reuse of engineering knowledge and to standardize on inventory (purchased items).
To address the first need I believe PLM offers various ways to support a classification. Some might believe DIN 4000 is a useful standard. From my experiences with companies it appears that it is important to bring rational to what you classify. Where is the ROI. Classification brings a lot of constraints and overhead to the engineering department – all parameters needs to be mandatory managed for each part, otherwise your classification looses its value. Probably you will realize that classifying metal strips does not bring the reuse value as the overhead for maintaining the classification is higher then the cost of producing a new strip. So I am not so convinced about classification for this need.
For the second need – inventory optimization – here i believe the classification brings a measurable ROI, specially when the company uses a New Item Approval process or Standardization Process, where every new item will be reviewed (and classified) to guarantee its unique need. Of course it depends very much on the type of industry and main business process if this approach brings value. Listed in a more relevance order: Engineering To Order / Configure To Order / Design For Manufacturing
Folksonomy versus Taxsonomy
A new trend for classification is the way search engines work on massive unstructured data. No one tries to classify all the web pages that exist (although there might be a standard for that). It is easier to perform a context search and specially with new web development you see that tagging information becomes more and more important for retrieval. For example I tagged this article with PLM, ERP, Classification, Item Reuse and Item Consolidation. These tags will be used by search engines and I do not have to worry on which level and where Item Reuse is stored. As a creator of this text part I tag my information for reuse.
This is called Folksonomy, this in contrary to Taxsonomy, the classical method for ordering information. See for more background the related wiki hyperlinks.
Conclusion
Implementing Folksonomy in a PLM environment depends on the type of PLM system you are using (in case you use a PLM system). It requires a way to tag information in an user-friendly way and to retrieve information by tags in an easy way – the ease of use of a search engine. In case it is too futuristic this approach, evaluate your engineering classification needs based on your expected ROI and goals, keeping in mind in the classical way of classification will evolve.
Do you have examples of classification with a proven ROI for engineering, let me know
The words used in this title are the ones that I heard the most the past weeks- only all of them in a different (more pessimistic) context. Speaking with potential customers and vendors I heard most of the times the combination: Can we do PLM when there is an economical crisis ?
A famous Dutch soccer player (Johan Cruyff) once said: “Every disadvantage has its advantage” and this is also valid for the economical crisis. It forces companies to think (different) as their future is challenged. Less orders means less works and probably less pressure on the organization – companies might decide to lay off people to reduce costs. This is in many cases a pity as knowledge (IP = Intellectual Property) might be lost.
One of the benefits of PLM is that the IP (stored in people’s brain) becomes available and visible inside the company without the need to consult these experienced persons. Would this mean implementing PLM would reduce they amount of people in engineering ? No, it reduces the risk for a company to be held hostage by these people and even more. By making internal IP available inside the company, it allows companies to overlook their portfolio and performance – and from there to decide where to focus an innovate. It creates a competitive future.
In some of my previous posts, I mentioned that one of the most heard excuses not to implement PLM was the fact that companies claimed they are too busy. This means reduced work creates the opportunity to invest time in PLM – and as the budget for implementing PLM might not be available, at least the time exists. The work done during this time assists the company once we are in an economical upward move – usually at that time companies become stressed as more work needs to be done with few resources available – and new resources need to be hired.
For me a PLM implementation can be compared with a journey through an unknown area. As companies usually do not understand what is the impact of PLM to their company – the ultimate goals somehow are known, but how to get there, no one knows. A company can hire consultants and implementers to guide them during this journey, and i believe this is required, to avoid going in the wrong direction.
However the knowledgeable people inside the company know best which changes in business processes will bring value and which are not yet understood. And this is crucial in a PLM implementation – a company needs to digest and understand the impact of PLM.
So considering the points above and the fact that as a company you do not want to invest much in a PLM implementation at this moment due to the financial situation, what can you do:
- Spend time inside your company to decide where you want to be in two to five years, assuming that once you have a more promising market you need there to be ahead of your competitors
- Learn and invest with PLM providers who can offer you a solution. Pay attention in this phase on which partner understands your business and can guide you in a step by step approach towards your goals. Do not get distracted by function and feature comparison of systems at this stage as most PLM systems can do the same, it is more about your implementation / consultancy partner.
- Define a step by step implementation roadmap, where each step brings you ROI (return on investment) and closer to your goals.
Considering the three points above you will be able to say:
Economical Crisis and PLM ?
YES we can (start)!!
The past month I was involved in a two ENOVIA SmarTeam projects, where both had the target to become the company’s PLM system. However the way these projects were executed lead to the conclusion that the first one was probably going to fail as a PLM system, were the second project was going to be successful.
And only by looking back to the history of the first implementation, it became clear what prevented it from becoming implemented as a PLM system. It had all to do with a bottom-up approach and a top-down approach. I guess ENOVIA SmarTeam is one of the few products that allows a customer to make a choice between bottom-up or top-down.
Somehow also Jim Brown’s post was in line with this observation, but judge yourself.
Most classical PLM systems require a top-down approach as the PLM scope requires departments to work in a different way and to enforce a change on the organization. Organizational change usually only happens top-down based on the vision of the management.
ENOVIA SmarTeam however has the option to be implemented as a CAD data management system, managing the Product Data in the form of documents. This brings a lot of value to the engineering department and depending on the PLM awareness of the company they might try to replace the Excel based Bill Of Materials into a BOM inside the system. As we are working in the scope of engineering this is in most of the cases the Engineering BOM.
There are also other CAD data management systems that claim to be an enterprise PDM system as they manage the product data (usually only the native CAD data) and the engineering BOM. As these systems do not contain capabilities to become an enterprise PLM system, it will be clear for the organization, where to position it – and to keep it in the engineering department.
There are engineering managers in mid-market companies that have the PLM vision and this was the case in the first implementation I mentioned. As his initial mission was to manage the product data based on SolidWorks and AutoCAD, the company decided that ENOVIA SmarTeam was the best multi-CAD data management solution for the company. Meanwhile the engineering manager had the hope (or dream) that once this implementation was completed all other departments would stand in a queue to get connected to ENOVIA SmarTeam too………
…. and this did not happen. Why ?
The main reason for that was that at the time the management had understood the PLM benefits and considered implementing PLM, they looked at SmarTeam and it was implemented too much as an engineering solution, too rich in functionality (and complexity) to be used and integrated by other departments. But when the company was looking to an PLM extension from their ERP system, the engineers refused to work with that system, as according to their opinion the system did not support their needs.
How could this be prevented ?
This was done exactly in the second project. Also here the implementation started in the engineering department, but from the start it was clear for the management, that they would extend the implementation towards a full cross-departmental PLM implementation. The main difference was that the implementation was not focused on satisfying the designers, but from the start it was clear ENOVIA SmarTeam should be useful for other departments too. This implicated less customization on the existing product, more standard functionality. Yes, the designer had to change their way of working as they worked file-based before. But as the focus of the implementation was always on providing data access across the organization, the system remained attractive for the production planning and manufacturing people. It was not an engineering tool only.
Additionally the standard ENOVIA SmarTeam system required from all departments adaptations to their working methods, but as it was not heavily customized, it was much easier to extend the scope beyond engineering.
So what is the conclusion:
- Do not try to build the ultimate engineering solution as step 1 in a PLM project. Remain with the core capabilities.
- Keep the focus on storing information in such a way that it becomes usable for departments outside engineering. This requires less detailed data and more reporting capabilities
- Do not hide the intentions to the management that ENOVIA SmarTeam can become the company’s PLM system. Make the management aware of that but also explain the benefits of a step-by-step implementation, starting with engineering and expanding when the time is ripe
- It would not be the first time that ENOVIA SmarTeam was the best kept secret for the management. The engineering department was happy, but no-one made the effort to explain the full capabilities to the top management
And now a small advertisement add the end
The ENOVIA SmarTeam Express offering allows a customer to start design centric (SDE = SmarTeam Design Express) and to extend the scope step by step by applying engineering capabilities extending the scope from Concept to Manufacturing (SNE = SmarTeam Engineering Express), guiding a bottom-up implementation step-by-step.
The last two weeks I spent around two events for the automotive industry. First the SAE event in Chicago and this week the COE Automotive in Detroit to give a lecture around the future possibilities of a supply chain in a web 2.0 (PLM 2.0) world. For many of the lower tiers suppliers in the automotive supply chain this seems to be something far from their daily business. I guess one of the issues here is, that these companies are used to solve their problems per department, without having a corporate vision or strategy where the company should be in five years from now.
And here I see many challenges (in Europe we would call them possible problems). As the smaller mid-market companies try to solve their problems per department, you will find all around the world bright engineering managers who conclude that their company needs PLM. As they understand all the engineering challenges, they understand that in order to really understand what their department is doing, they should work in a different way than file based.
This is what companies working file-based think
When working file based companies rely on the following main contributors for getting information (in order of importance)
- we do not need these expensive solutions for PLM etc …
- the most important is the experienced engineer who knows what has been done in the past and where to possible find it
- the company directory structure which allows everyone to find and store data related to a customer, project or product
- the file name of the designs and documents which ‘exactly’ describes what’s inside the file
You just need to follow this order and you will always find the right information (or be close to it).
..and these are the issues they do not tell you.
- I guess we really do not know what to do with PLM as we never studied it, what it would be for our company
- we cannot bypass our experienced engineers – although at a certain moment they will retire, currently they would feel very insecure if we tried to collect their explicit knowledge and make it available for all. They would feel their jobs are less secure
- there are some issues with this directory structure. Sometime someone deletes or overwrites a file that we needed, and of course we are not sure if all the data we need is really there. We always need to double check with the people to be sure – and sometimes it hurts, but we are used to it
- or people are creative that only they understand what is in their own files and even from the file name, which can be long, we do not fully understand where it fits, what is the status and where is it also used.
Seeing these two opposite messages, we need to understand what are the challenges for these companies in the near future.
Challenges for these companies
The current workforce is aging all around the world – i recently read that although many believe China is the next promising country for the future, due the the one-child-per-family strategy in the past, they also will face in the near future (10-20 years) the same problems Europe and the US will have.
A huge part of the population will retire and especially in Europe and the US with this retirement a lot of real knowledge will disappear. The new generation will come with different skills, a different background and attitude to engineering. And due to the difference in attitude there is little or no communication between these generations.
So if you are an (aging) manager in a mid-market company in an automotive supply chain, you have two options to react:
- you become fatalistic and believe that the new world is bad and you cling as long as possible to the old habits you are familiar with
or
- or you understand every few decades a change in the way of working is required, which means moving away for the traditional knowledgeable people with their files to an internal, knowledge sharing environment where everyone has access to understand what exists and in which status it is.
So only one conclusion
Survival for the future requires a change in the way these companies are working. It reminds me of the boiling frog story. We do not see the world is changing around us, till it is too late. I guess human beings should be more clever than frogs and they are able to collect information from outside their ‘pan’.
Working with ENOVIA SmarTeam solutions, in particular the Design Express solution, I learned that this solution is an excellent entry point to move away from file based work towards data management.
Still not convinced ? Challenge me by adding a comment (public exposure) or sent me a private email for a one-to-one discussion
As there are many engineering managers who believe that they understood the issue and started to implement an implement a PLM solution in their department, I will address in my next post they challenges they face with this bottom-up approach to convince the company PLM is unavoidable
Below just a goodie to enjoy
The past weeks I have been traveling and visited several implementers and potential PLM customers in Europe. Afterwards I presented and joined a panel session in the SAE 2008 Commercial Vehicle event.
Between the traveling I had enough time to reflect what i saw and heard and I realized that in the mid-market and perhaps in the lower tiers of the automotive industry, people are locked in by the way they are working and thinking, meanwhile seeing PLM vendors already coming with future concepts, talking about PLM 2.0
Many of the mid-market manufacturing companies I met in Europe are just realizing PDM (Product Data Management) in their company, usually as an extension of CAD data management. If you look to the demands of these companies through RFQs, they are trying to build a complete environment for their product data mostly around the engineering department.
This is the classical way bigger companies were implementing 15 years ago, and now mid-market companies see and understand the maturity of this concept.
Is PDM the first step to PLM ?
In my previous posts I already argued that implementing PLM (which goes beyond PDM) brings the real benefit for manufacturing companies, but this requires a change in the current way of working. Disciplines (marketing/sales,engineering, production engineering, maintenance & service) have to collaborate around the major business processes from the company, instead of optimizing each department and then forward information to the next department as we can see from the (classical) picture below:
Now these companies implement PDM, but what is the result ?
For mid-market companies the above step is easier to implement as it has not so much impact on the organization, however the fundamental way of working does not improve and does not provide the full benefits that bigger enterprises experience. The main benefits in the above situation are quality and efficiency benefits for engineer. As there is still no connection between the customers (marketing/sales) and the field (customers / service), the engineering department will work in an ivory tower, knowing what’s best. Only the real problems will reach them but the fine, combined information from the field will not reach them, and for that reason innovation is much harder to come from this approach.
Although PDM can be a first step towards PLM, it is only a step to get organized
The real benefits come when the collaboration around the whole product lifecycle is implemented. This is mostly not going to happen by a bright individual in the company. It requires a strategic vision and approach from the management, to change the way departments are working and connected.
In the very small mid-market companies this kind of collaboration has always existed ad-hoc. Quotes I heard in the past weeks were:
“if there was an issue, we all gathered around the machine in production and we solved it on the floor. This is collaboration.”
or:
“we do not need workflow and other tools to spend time informing each other. If there is something required, we just talk to each other”
These quotes above show, that people are not prepared for a structured, global approach. The main manufacturing process should be defined in such a way that exceptions like the first quote do not occur. Also the talking from the second quote is replaced by something that is traceable and secure, in order to guarantee repeatable results. This is the major task for the management in mid-market companies.
Meanwhile it is the role of the PLM providers to talk and understand the language from the mid-market companies. Not technology but work/task-oriented solutions will narrow the gap between the user and the software. Once the gap becomes smaller, mid-market companies might understand and feel the benefits of PLM.
So is the gap 15 years ?
I guess not, and for the following trends:
- More and more early adapters from PLM in the mid-market report the benefits from their PLM implementation. So the acceptance for PLM becomes mature.
- Mid-market companies will become more and more part of enterprises, which will bring the strategic vision of PLM to them.
- The aging workforce requires companies to capture knowledge that will disappear if they keep on working the same way. Joe, who knows everything, will retire in 5 – 10 years. This is where the management will get alerted to act – in time we hope.
- The new workforce comes with different, multi-tasking skills, used to work with a computer on parallel sessions. It is to the management to understand these new talents and develop them.
As most of the points are addressed to the management, I want to point once more to the following posts from the past:
culture change in a mid-sized company a management responsibility
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.
This week was a week full of discussion with customers and VARs (Value Added Resellers) around PLM, PDM and implementation approaches and I will come back on this topic in an upcoming post. First I want to conclude the sequel on reasons why companies believe they should not implement PLM.
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 #4
4. Isn’t PLM the same as managing CAD files ?
As most of our customers do not have the time to study all the acronyms that exist in our business, it is understandable that it leads to a different interpretation as expected. In non-academic language I will roughly outline the differences.
In the eighties when most of the mid-market companies designed their products in 2D, bigger enterprises were investing in 3D CAD. In parallel these companies were working on concepts to manage all their engineering data in a central place.EDM (Engineering Data Management) was the word in fashion that time. We have to realize that networks were not as affordable as nowadays and that there was no Internet. It was the first concept to centralize and manage engineering data (files – no paper drawings). An EDM system was of course a system purely for the engineering department.
More and more companies started to expand the scope of data managed, it became the central place to store product related information plus being an infrastructure to collaborate on product data. The acronyms PDM (Product Data Management) and cPDM (collaborative Product Data Management) became in fashion in the nineties. A PDM system still focuses on the engineering department but no multi-discipline and if available in dispersed locations.
In 2000 the focus of PDM was again expanded to other departments in the company working on the product in different lifecycle stages. Instead of a static data management environment, it became a target to connect all departments working on the product through its lifecycle. By having all departments connected, the focus could switch to the process. The acronym PLM (Product Lifecycle Management) was introduced and this created a lot more areas of interest:
- connecting the bidding phase and concept phase with feedback from production and the field.
- bringing the sourcing of parts and suppliers forward in the product lifecycle
- testing and planning on a virtual product
- and more
But what should be clear from the scope of PLM compared to PDM and EDM, that it has become a cross-departmental approach and not only a system to enhance the way engineering departments work.
PLM is a strategic approach to enable innovation, better portfolio management and response to the market. The focus is on changing the traditional way of working into an approach where the process is as lean as possible still providing flexibility to adapt to global changes – changing customer demands, changing business situations.
Overview
| EDM | Focus mainly on centralizing mechanical design data in an engineering department – mainly files |
| PDM | Focus mainly on centralizing product related data in an engineering department – files, BOMs, etc |
| PLM | Focus on the product development lifecycle cross departments and locations – files, BOMs, processes, resources. |
Conclusion
No, it is not the same, where managing CAD files is mainly an engineering department related activity which can be solved by a product, PLM is a cross organization approach which requires a PLM system as enabler to implement various best practices
This time a short post, I am off to the ECCAP (September 9-10) to meet customers, implementers and peers all around ENOVIA
Adiosu
This time a short post. When I committed myself to write posts about connecting PLM and ERP, I already touched several times the PLM and ERP vision (from the point of view of a PLM missioner of course)
Just as a reminder the 5 most objections I heard the most from companies when discussing a PLM implementation. You also will find references to the first two objections I already discussed.
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
3. We already have an ERP system.
From the analyst point of view, PLM has established itself as a discipline beside ERP and CRM. Which discipline requires the major focus in a company depends on the major business process of the company. It is clear PLM brings it benefits for manufacturing companies, where innovation and managing their product IP are major reasons for success.
Various publications on this topic (in order of relevance):
- Collaborative Visions.com- PLM action
Perfectly explaining where PLM brings value and where it is different from ERP - Aberdeen Group – The Best Kept Secret of Top SMB Product Developers. Finding the Shortest Path to PLM Value
Showing the difference in perception and real attention needed when implementing PLM and where the benefits are for SMB companies - AMR research- PLM Report
Showing the PLM market is growing steady, which means for companies that PLM vendors will invest in a more and more mature product based on common principles - TechClarity – Complementary Roles of ERP and PLM
Explaining the differences between ERP and PLM and why you need them together - Aberdeen Group – Integrating the PLM Ecosystem
Explaining integration of your PLM system will bring competitive advantages - CIMdata – SAP PLM roadmap
Showing that even SAP recognizes PLM exists
So by studying all the links in this post, you might come to the conclusion below:
Conclusion
All my previous posts and the above publications (and much more) explain that if a company is interested in managing their Intellectual Property (IP) – the reason why they really differentiate , plus if they want to remain in business by being innovative,PLM is the proven approach for this type op companies.
And tired of innovation, watch this:
After two posts on objections for PLM, I want to come back to the basics around connecting PLM and ERP systems. Most of the people are enjoying their holiday at this moment and for that reason I have the time to complete the PLM and ERP story. I guess, for a company in the mid-market, it is hard to decide which approach to follow.
ERP vendors will claim that by managing items and relations to the design documents, they are able to provide an environment that supports engineering on top of their system. For mid-market companies this might be the ‘cheapest’ option – buy or get your solution from a single vendor. Especially when the ERP vendor provides the PLM module for free. And this is exactly one of the reasons why it will fail. When no PLM knowledge or best practices are provided to the company, but just a set of function and features, how would these companies know how to implement PLM ?
If you give a module for free it obviously also shows you do not understand the value of it.
My two last posts with the common title 5 reasons not to implement PLM are addressing some of these issues.
But now back to the PLM and ERP connection. In my two previous posts, I described how would be shared between a PLM and an ERP system, combined with issues as: intelligent part-numbers and classification. You will find similar discussions on the manufacturing center.
The connection between PLM and ERP has little value in case only items are exchanged. Of course engineering can have the benefit of early visibility of item logistical data, like costs, stock and status. But the real value comes when engineering, through the PLM environment, feeds the ERP system with the definition of how to manufacture a product. The way to manufacture a product is based on the MBOM (Manufacturing Bill of Materials), combined with operations that need to be performed on the items in the BOM.
In my post Where is the MBOM I already discussed the classical challenge many companies are facing. Historically they enter all the data for manufacturing in their ERP system, as this was the first system driving production. The input for the ERP system came from the engineering department, sometimes provided as Excel sheet or in case of more automation with the CAD environment as an EBOM (Engineering Bill of Material)
As the concept of connection CAD through PLM with ERP might be new for many companies, I will describe below some ‘bad practices’ that I found in past implementations and what we can learn from them.
Bad practice 1: A CAD file equals and Item number
As PLM is often introduced starting from the design department, the initial thought to connect CAD files and Items is based on the simple rule: “Every CAD file represents an item number”. In the ‘good old’ 2D world this might have been true, as in the ERP system, related to each item to be manufactured a drawing existed.
However in the 3D world this approach leads to the following problems:
- Flexible parts like rubber tubes or belts have a different file representations when used in a different position. This means for one item number several CAD files may exist.
- Some CAD systems like CATIA, SolidWorks allow the designer to store within one file different configurations of a design, as they share a common design but vary on some specific points. Each variation of course is a different item number. This means for one CAD file several item numbers may exists.
The conclusion from the above exceptions is:
- Handle CAD files and Item numbers as separate entities in your PLM system
- A CAD file CAN NOT BE equal to an Item Number
Bad practice 2: The CAD structure can be used as the BOM to be send to ERP
As in many companies the EBOM and the MBOM resemble a lot, the temptation exists to push the engineer instead of defining a design in the concept of the EBOM, to work in a mixed environment.
This approach will lead to the following problems:
- Drawing of non-design items in the 3D CAD assembly as they are needed to represent an item. For example a paint-can symbol, an oil-can, etc. As these materials are needed for manufacturing, the designer has to add them to the product structure as in this way they will appear in the BOM. This approach leads to a dependency on the CAD assembly that is not needed. Imagine another type of paint is needed – this would require the designer to change the CAD assembly files as they represent the manufacturing structure – or you do not update the CAD assembly files and in that case you have no reliable data anymore.
- The designer might use in the design subassemblies that group two or more items logically together. For example a bolt, a nut and two rivets. As the subassembly does not exist as an item number in the ERP system, the ERP system treats this assembly as a phantom assembly. No operations needed, but an extra intermediate step is defined in the ERP system, as-if for each usage the bolt, the nut and rivets need to be assembled.
The conclusion from the above points is:
- Handling the MBOM in the CAD system to send it automatically to ERP leads to complexity either in the design environment or in the ERP system
- There is no need to have this complexity when the concept of EBOM and MBOM is implemented in PLM
- Handling EBOM/MBOM transformation in the interface leads to costly complexity, see Where is the MBOM ?
Bad practice 3: The Items in CAD structure are tightly linked to the MBOM
This practice often appears in combination with the two bad practices above. As the company focuses on a resemblance of the CAD structure and the MBOM, people start to imagine also the other way around. They expect the PLM system to keep the CAD structure in-sync with the BOM. In case an item is deleted or replaced in the BOM, the CAD system should be updated automatically..
I guess this is one of the things I learned that is an utopia and probably not needed if a clear understanding of CAD structure, EBOM and MBOM exists. Removing or changing items in a BOM does not give enough information about the impact on the CAD structure. For example if one item appears 3 times in an assembly and one instance is replaced by another item, how would the CAD structure know which item should be replaced ?
The conclusion from the above point is:
- changes in a product assembly can be initiated from the BOM but should be executed in the CAD system
- Automatic synchronization of CAD structure based on BOM changes is an utopia
Conclusion
In general my conclusion is (after many years of trying to satisfy customers learning from the above points and more) :
In order to create a smooth connection between PLM and ERP you need:
- Item creation in PLM – completion in ERP
- ERP provides feedback on costs and availability
- In case of production issues an ECR/ECO should be launched – going through PLM to assure engineering impact has been analyzed
- PLM needs to manage the capture of the CAD structure towards the EBOM
- EBOM/MBOM transformation needs to be done in PLM
- The connection between PLM and ERP should go through the MBOM
Jos Voskuil's Weblog 
[…] (The following post from PLM Green Global Alliance cofounder Jos Voskuil first appeared in his European PLM-focused blog HERE.) […]
[…] recent discussions in the PLM ecosystem, including PSC Transition Technologies (EcoPLM), CIMPA PLM services (LCA), and the Design for…
Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…
Jos, as usual, you've provided a buffet of "food for thought". Where do you see AI being trained by a…
Hi Jos. Thanks for getting back to posting! Is is an interesting and ongoing struggle, federation vs one vendor approach.…