You are currently browsing the category archive for the ‘ERP’ category.
As the year ends, I decided to take my crystal ball to see what would happen with PLM in the future. It felt like a virtual experience and this is what I saw:
- Data is not replicated any more – every piece of information that exists will have a Universal Unique ID, some people might call it the UUID. In 2020 this initiative became mature, thanks to the merger of some big PLM and ERP vendors, who brought this initiative to reality. This initiative reduced the exchange costs in supply chains dramatically and lead to bankcrupcy for many companies providing translators and exchange software.
- Companies store their data in ‘the cloud’ based on the previous concept. Only some old-fashioned companies still have their own data storage and exchange issues, as they are afraid someone will touch their data. Analysts compare this behavior with the situation in the year 1950, when people kept their money under a mattress, not trusting banks (and they were not always wrong)
- After 3D, a complete virtual world, based on holography, became the next step for product development and understanding of products. Thanks to the revolutionary quantum-3D technology, this concept could be even applied to life sciences. Before ordering a product, customers could first experience and describe their needs in a virtual environment
- Finally the cumbersome keyboard and mouse were replaced by voice and eye-recognition. Initially voice recognition and eye tracking were cumbersome. Information was captured by talking to the system and capturing eye-movement when analyzing holograms. This made the life of engineers so much easier, as while researching and talking, their knowledge was stored and tagged for reuse. No need for designers to send old-fashioned emails or type their design decisions for future reuse
- Due to the hologram technology the world became greener. People did not need to travel around the world and the standard became virtual meetings with global teams(airlines discontinued business class). Even holidays could be experienced in the virtual world thanks to a Dutch initiative based on the experience with coffee. The whole IT infrastructure was powered by efficient solar energy, reducing the amount of carbon dioxide drastically
- Then with a shock, I noticed PLM did not longer exist. Companies were focusing on their core business processes. Systems/terms like PLM, ERP and CRM did not longer exist. Some older people still remembered the battle between those systems to own the data and the political discomfort this gave inside companies
- As people were working so efficient, there was no need to work all week. There were community time slots, when everyone was active, but 50 per cent of the time, people had the time to recreate (to re-create or recreate was the question). Some older French and German designers remembered the days when they had only 10 weeks holiday per year, unimaginable nowadays.
As we still have more than 40 years to reach this future, I wish you all a successful and excellent 2009.
I am looking forward to be part of the green future next year.
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
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 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
Last week I conducted another ENOVIA SmarTeam Express training, this time in the Coventry office from Dassault Systems. The conclusion from the audience was that the SmarTeam Engineering Express concept is a perfect entry PLM system for the mid-market. It show the general best practices of PLM for a mid-market from concept to manufacturing. Additionally is provides the company a flexible PLM platform to further grow and expand to directions that bring more benefits.
But here I want to stop, as you will start to believe it is a marketing speech. In a certain way it is marketing. Marketing is needed to influence people and companies to change their way of thinking. Without marketing we would never buy Personal Computers, mobile phones, MP3 players, certain drinks and more. We tend to forget why we need certain products and what the real benefits are. PLM is not at that level of market understanding yet.
For that reason I will give the 5 objections why not to implement PLM that I heard the most and comment on them.
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
In this post I will address the first reason. Others in upcoming posts.
Note: I use generalizations in this post as specific cases my vary – specially when talking about comparisons with ERP system.
1. The cost for a PLM implementation are too high.
This is the argument I heard the most. And indeed, if you accumulate the total costs of a PLM implementation after 2-3 years, you might get that impression. The main reason for this perception is the fact that often companies have suffered from an ERP implementation in the past. I do not want to blame the ERP companies for the high costs of implementation, as they were the first major business system implemented in manufacturing companies. There were many horror stories in the past, but now you can say ERP has become mature and processes to implement are clear too. For that reason ERP companies now can provide an estimated cost and ROI (Return On Investment) for manufacturing companies. I guess that manufacturing companies that have not invested in ERP the past 20 years, probably stopped to exists, so benefits for ERP are clear.
But at what costs ? PLM is not as mature as ERP. This means a PLM vendor cannot come to a manufacturing company, identify its main business process and apply a PLM template. The major reason for that is the fact that the PLM vision encompasses many different processes in a company, many of them currently not even identified in mid-market companies. This leads to the situation where PLM implementers together with their customers spend time to learn and pay the price for learning. Most of the learning has been done already by the big enterprises, now the mid-market companies need to understand what is relevant for them.
We know learning has it costs, and specially when external (paid) resources are involved, the costs might add up too high. In parallel the biggest mistake made to implement PLM is to consider it the same way ERP is implemented. A project team builds in a isolated environment a new ‘to be’ PLM environment, once and a while involving key users for their feedback. Then after 8 months – 1 year they role out the PLM implementation to the users as a ‘big boom’. As a logical reaction the users object to this radical change, which leads to compromises, and rework of some of the project deliverables. At the end after 2 years the company might have an acceptable PLM implementation, meanwhile having a bad taste of a failed and costly project. And the ROI still to come……
See the diagram below:
So how can we avoid these high costs ?
First of all the investment of a PLM is done because we believe there is a Return On Investment. Companies invest in order to improve their competitiveness and PLM is a main driver for manufacturing companies. So how can we assure ROI and lower the total costs ?
A first best practice is the phase a PLM implementation into small, digestible steps with a durations of 3 to 6 months. Each step will have its investment and its limited scope. The result will be that even after the first step, people can start working with the new system, experience the impact of the new PLM system and start bringing ROI as the benefits will start paying of.
These benefits plus the fact that the company and their users start to understand what a PLM system can bring for them and this leads to a clearer and lower cost of implementation for the next phases. The figure below gives an impression of how costs and ROI will work out in this situation.
The Express offerings from ENOVIA, SDE (SmarTeam Design Express) and SNE (SmarTeam Engineering Express) are exactly targeting this approach. Instead of imagining what PDM and PLM could do for a company. They allow the company to quickly start and experience and later grow to the optimized environment.
The management of the company should always keep their ultimate PLM vision in mind, still anticipating changes as business evolves. Each implementation phase should fit in the ultimate PLM vision and its implementation should be judged on bring ROI.
This is a main difference between PLM and ERP. An ERP implementation focuses on a specific logistical process to implement. This implementation cannot be done for 50 % and than later another 30 % and again another 10 % till the ultimate ERP vision has been reached. It must be done in one implementation as it targets the whole production process.
A PLM implementation however is an implementation of Best Practices all around Product IP and innovation. The world in which products are defined has changed drastically due to globalization, customer focus and changed technologies. This means that the way companies define and develop their products have to be flexible and changeable. PLM implementations require a step by step approach, every time improving those areas that bring the best ROI. Still the company needs to remain flexible in to anticipate for future changes, merges, acquisitions or even different business processes.
Conclusion: PLM systems are not costly in case of a phased implementation targeting immediate ROI per phase and flexibility in the future.
In the previous post, I described that the item is the primary entity used in the connection between a PLM system and an ERP system. The initial definition comes from the engineering department, defining the main characteristics of the item, like ID (part number), Description and Classification Data for engineering usage.
Next when the item reaches a certain maturity stage, that it will be purchased or produced, the initial definition needs to be transferred to the ERP system and to be completed in ERP with logistical data. Often as part of the classification data, the engineer has already defined what type of item it will be. This information can be used in ERP to apply default data based on a certain template item or derived-from item.
Item identification / Part Number
Most of the manufacturing companies are using so called ‘intelligent’ part numbers to identify their items. This was done for historical reasons. As there was no IT system in the company, the part number contained logic and information in order to ‘immediately’ understand its usage.
For example M210-23-4-00-A3.C tells me immediately it is a manufactured part, first time used in the milling product line (210) and it is used for hydraulic (23), not in stock (4), a preferred item for engineering (00) and its definition can be found on the drawing with the same name, size A3 revision C.
If you did not understand this directly from the number, it does not mean you are not intelligent, although it is an intelligent part number. This shows that intelligent numbers are useful when people are trained and have a good memory. For everyone else in the company (and joining the company later) the number is initially the same as a meaningless number.
For that reason is is recommended to use ‘non-intelligent’ numbers to identify parts. This creates no overhead for people to learn all kind of intelligent numbering mechanisms and it pushes everyone to look to additional information which can be understood immediately, like the description or classification data. We have now IT systems like a PLM or ERP system that allows us to display more than a number.
For backwards tractability of course beside the new meaningless part number, there can be also a place holder in the IT system to define what the origin of the part was (with the intelligent part number). Specially when companies merge this will happen. The same part exists in different numbering schemes in each company. The only way to solve this is to add a new identifier, preferred to be the ‘non-intelligent’ number.
Conclusion: For part numbers it is recommended to use non-intelligent numbers based on a sequence, avoiding the creation of legacy information (merge) or training to understand the items by number.
Now the new created part has a meaningless identifier, we have achieved two things:
- The PLM and ERP system have unique key to share. Identifying this number with its revision (if relevant) immediately makes it clear for both the PLM and ERP system which part is meant.
- To understand what the item really does, we need to understand additional information like its description
Note
: Not all ERP systems support revisions of items. Some work always with the actual version of the item. Where PLM systems trace and keep the exact definition of an item, often ERP systems trace the item by effectivity. You need to know what was the engineering definition, when the item was manufactured.
Description / Classification
Initially when an item is defined the engineer might create a description, like HYDRAULIC CLAMP without any further details. Some years later there might be 10 or more hydraulic clamps in the system, where some of them might be identical and others differ. However the description HYDRAULIC CLAMP might be sufficient for a part list to be shipped to a customer (we do not want the customer to know the exact item characteristics in order to have him order the spare parts through us).
Often on the engineering side an additional description field is added, which is a detailed description. This description is used internally and should be standardized in order to support the engineer to select the right item.
So HYDRAULIC CLAMP could have an internal definition HYDRAULIC CLAMP 400-600 describing its usage. This detailed description should be either enforced and generated by the PLM or should be handled through a librarian or standardization role in engineering. This should be combined with a classification of the new item. The advantage of a detailed description and classification is two-fold:
- It supports engineers to search for existing items – so reuse is more likely. Often the description in the ERP system was not built in this way and for that reason engineers re-invent items while they might exist.
- The classification will alert the engineer or librarian that an item with the same classification characteristics already exists. This means it might be identical or an additional classification characteristic is needed to differentiate the two items.
The definition of a new item would go through the following steps:
- The engineer defines the description and can work with the item in a temporary mode as he is not sure of using the new item in this way
- The item becomes mature and he needs to generate the detailed description.
- At this stage the librarian or a standardization committee might come in, to analyze the need for the new item. And if so to define all its classification data, knowing it is a new and unique item needed.
- Once the engineering definition is completed, the item definition can be send to the ERP system in order to complete it with logistical data – who can manufacture it and tens of attributes more. The item still is not released
- A hand-shake from the ERP system will confirm that the item definition is completed and as part of the release process the item can be approved for manufacturing. In case no pre-production stage exists it might be released even.
Conclusion: Standard Description, Detailed Description and Classification information is done on the PLM side to support reuse of items and to avoid creation of similar items with a different part number. The ERP systems uses the description definition and completes the definition with ERP required information. Data relevant for the engineering is synchronized back once the full definition is available.
The next post in this sequence will be discussing the BOM transfer to ERP
This week I was in South-Africa working with Aerosud, one of the prominent companies in the Aerospace industry in South Africa, working with the major OEM’s One of the topics discussed in the workshop with Aerosud was the connection between PLM and ERP. As this is a question that occurs so often, see also previous posts, I will address in this post and the upcoming posts the logical steps for an PLM – ERP integration and issues a company might face.
For some people I guess the big surprise will be that most of the difficulties and discussions are not on the technical level, but on how a company has organized their data and organizes their data in the future.
The first rule for implementation is:
The PLM system manages all product related IP (Intellectual Property) and the ERP system manages the executing in the most effective way, taking into account resources, time, material scrap etc often linked with financial transactions
Although some ERP vendors might want you to believe they offer also PLM functionality in their system, it is always a small subset of the total PLM capabilities. Linking manufacturing documents to an item is not PLM. PLM is managing all product related IP and this requires connections to all information sources during the whole product lifecycle, not only during manufacturing.
So if we agree on the above, we understand there is a need to connect PLM and ERP, as both systems have a vital task in a manufacturing company and both work around common information, the product, composed of all its physical items.
The Item
The physical item, is the shared and understandable entity understood through the whole company. Some companies call their items parts. In order not to confuse between an item and a part designed in the CAD system, i will talk about items, when I mean the physical representation.
Items can be a single item, a rivet, a specific metal plate or it can be a complete product or smaller component of a complete product. They have one thing in common, we all identify them with a unique number the item number.
In engineering oriented companies you might hear designers say, the item number is equal to the part number of the part or product they are designing, as often in their case what they design on the lowest level of the assemblies, becomes an item.
In general you can subdivide the items in two major groups:
- standard purchase items
- company or project specific items.
Standard purchase items
The characteristic of a standard purchase item is that it has been designed and developed by external companies and that these items can be found in catalogs produced my one or more manufacturers around the world, based on defined standard. For example a M12 Nut, a bearing with specific diameter and performance characteristics. The company that uses these standard parts creates an own definition of the part and makes references to manufacturers who provide these parts in the right quality and standard. These manufacturers appear on the Approved Manufacturer List (AML), which is an engineering task inside PLM to define this list.
In addition, based on this approved manufacturer list, the purchasing department will allocate vendors for these parts and based on vendor performance and reliability, they create a List of Approved Vendors (AVL)for these parts. This is a execution task to be defined in the ERP system.
So in day to day operation, engineering will define new standard purchase items if not available and this request will lead into an AML and then in ERP towards a AVL of the standard item. It is a combined activity where each of the disciplines has participate. For existing standard items, there is also a process triggered from ERP that influences their usage. For example a certain manufacturer might stop producing a certain item and this affects the AVL – purchasing raises a flag that the item becomes hard to acquire or even unavailable, which leads to engineering to define a new AML, which might end up in an engineering change as by changing some of the product functionality other standard items can be used to replaced the original defined item.
So for standard purchase items we see:
- new standard items are introduced through PLM – starting from AML into ERP with the AVL.
Both system add information to the item information - exiting standard item can become obsolete through PLM – as the company decides not to use them (anymore) or become phase out or obsolete based on a trigger coming from the ERP side, as the AVL has changed.
- Standard purchase items do not have revisions
Items
With items here we mean the non-standard purchase items, which can be divided again in two major groups:
- company standard items
- project specific items
Project specific items are items defined by engineering during the definition of a product. These items need to be manufactured specifically for this product based on the specification provided by engineering. Outside the project these items are not used again anymore as they are too specific.
However companies try to standardize even their project specific items, in order to share and reuse them in other products. At this stage, the project specific item becomes a company standard item and is managed to be reused.
Both company and project specific items can have revisions as their maturity may grow. As long as the new definition complies to the Form-Fit-Function rules, the new revision of the defined item can replace previous revisions, meanwhile better support future usage.
So for items we see:
- project specific items are introduced through PLM and on the moment of production pushed to ERP to be manufactured according the design specification with the right revision
- company standard items are introduced through PLM and can be produced on stock (if there is a wide usage through various products) or pushed to ERP when needed to be manufactured according the design specification with the right revision
- Items are revision managed and follow the Form-Fit-Function rules
The conclusion of the above for this post is:
- Items have a common usage in both PLM and ERP
- Items are initially created in PLM and at a certain time transferred to ERP to be completed with logistical information
- Item usage can change based on availability triggers from ERP or use cases in PLM
- an item is a hybrid entity – with a common shared identification, PLM relevant data and ERP relevant data
- Some of the ERP data might be relevant for information to be viewed the engineer and the other way around
Once agreed on the above concept, we have the guidelines how to connect items between an PLM system and an ERP system. In my next post I will talk more about that, also about how to connect BOMs between PLM and ERP.
Subscribe to this blog if you want to follow this sequential on how PLM and ERP connect and work together
Subscribe in a reader
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.…