You are currently browsing the category archive for the ‘Change’ category.
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 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:
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.
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
Last week I was working with several people on data management issues for the supply chain. As I mentioned in my previous post from the ECC in Munich, there is a trend where OEMs require more and more cooperation from their suppliers. Most of these suppliers are mid-sized companies and these companies often lack the management support to implement changes top-down in an organization.
In mid-market companies the concept for quality guarantee and consistent responses is often implemented in design data management (control the product data), a quality system (ISO,—–) and the ERP system. See also PLM and ERP culture change. As these systems could be implemented on department level, not touching each other too much, it is relative easy from the cultural point of view to implement them. Each department can optimize themselves and often the quality system is not enforcing the users to work completely different.
But who and where is innovation managed ?
Large enterprises discovered that, in order to innovate, you need to connect and analyze all information around the products they are manufacturing. In simple words they realized PLM is needed to connect everyone around the product lifecycle from the concept phase till the production and after-sales phases. For these companies PLM became the backbone for their specific knowledge – we call it IP (Intellectual Property). Big companies could implement PLM because they had the management vision, the resources (people and budget) and the top-down approach to enable (and sometimes enforce) this change.
In mid-sized companies there might be the management vision, but resources and a top-down approach are rare. When it comes to a top-down approach, often the management believes that the goal is to enforce one IT system to the organization to manage all the critical data. Naturally this is the ERP system, and ERP vendors remain claiming that they can do PLM. It is a kind of overestimation of these companies as their nature lies in processing data, resources as efficient as possible, not in being creative to find new innovations.
Innovation is not CAD design as others may believe. These beautiful 3D designs smell like innovation, but in fact before a designer could start working on a concept, a lot of work has been done before. Analysis about what is it that the market, the customers require? What is de feedback on our current products in the field ? What is the competition doing etc, etc.
PLM requires culture change
As long as an organization remains thinking around 1 or 2 major IT systems (CAD data management and ERP) to manage all, there is no chance for PLM to be implemented successful. All departments and disciplines around the product lifecycle need to work together, change their departmental habits and learn to adapt to PLM best practices.
There is enough argumentation why to implement PLM and I believe solutions like ENOVIA SmarTeam Engineering Express are from the technology point a good start. See all related posts and comments to my previous post.
What I wanted to stress is that changes in a mid-market company are not done from the logical point of view. As the top-down vision and implementation often are not available, we are waiting for all departments to decide let’s change our way of working as we read all these beautiful benefits of PLM. This is of course not going to happen, only in advertisements.
Culture change even in mid-sized companies is a management responsibility and requires an open mind. We often forget that we have two sides in our brain. One side the logical side, analyzes all the arguments and stores them logically as good or bad. The other side of the brain, the emotional side is making the decisions, grabbing arguments that suit from the logical side in order to explain to others and ourselves why a decision is taken.
If you read books like The Language of Change (very theoretical, but the groundwork) or Blink: The power of thinking without thinking (very popular) you will understand that changes won’t happen if we stick to the traditional way of posting our arguments and keep on doing what we feel good with.
It is the management responsibility to think how to enforce a change in their companies. But as they also have a two sided brain, for that reason, management consultants were invented to reflect and discuss the emotional and logical side.
If after reading this post, you are more aware of the fact that one side of your brain fools you, then I achieved something. If however you will say “This is nonsense”, your other half of the brain has won.
Footnote: No more words about soccer – Holland is out
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.…