You are currently browsing the category archive for the ‘ERP’ category.
Last year, I read Clayton Christensen’s book “The Innovator’s dilemma – When New Technologies Cause Great Firms to Fail “. I was intrigued how his theory also applies to PLM and wrote about it in a blog posts last year.
Recently, I attended an HBR Webinar “Innovating over the Horizon: How to Survive Disruption and Thrive” , which raises serious implications for PLM. As presented by Clayton Christensen and Max Wessel, both professors in the Harvard Business School, I foresaw numerous consequences demanding attention.
I’d like to highlight some observations for you:
- Disruptive innovation will hit any domain – so also the PLM domain
- You are less impacted if your products/services are targeting a job to be done
- ERP has a well defined job – so not much discussion there
- PLM does not have a clear job – so vulnerable for disruption
- Will PLM disappear?
Disruption explained
The above diagram explains it all. Often products come into the market with a performance below customer expectations. The product will improve in time, and at a certain moment it will reach that expectation level. Through sustaining innovation, the company keeps improving their product(s) to attract more customers, and start delivering more than a single customer is asking for.
This is for sure the case in PLM. All the PLM vendors are now able to deliver a lot of functionality around global collaboration, covering the whole product lifecycle. Companies that implement PLM, just implement a fraction of these capabilities and still have additional demands. Still the known PLM vendors nearly always win when a company is searching for a new PLM solution.
Disruption comes from other technologies and products. In the beginning, they are not even considered by companies in that product space as a possible solution. As these products improve in time at a certain moment, they reach that level of functionality and performance, a potential customer can use these products to address their demands.
At this stage, the disrupters will nearly always win the battle. The reason is that they are more close to what the customer wants than the incumbents. Their product performance and price point are most likely to be more attractive than the incumbents´ portfolio.
Translating this to PLM it would mean: “Do not look for PLM systems as they already provide too much functionality, way above the line of customer desire”
As a PLM consultant, I need to provide some second thoughts to keep my job. There is much more behind Prof. Christensen’s theory, and I recommend before agreeing with what I write, read his books ! And although there is a horizontal time axis where the disruptive technology comes in, it does not indicate it will be this year or next year.
If you are aware that disruption can kill your business, how likely is it that it will happen in your business and when?
Professor Christensen makes two key points:
- Disruption will always happen, but this does not mean it is going to be fast and totally overtaking the old products. It might be a slower process as expected and incomplete. Here, I was thinking about disruptive cloud technology, which came in fast on the consumer level, but will it reach the business level too, in the same manner that it overrules the classical PLM platforms ? I am not sure about that (yet)
- If your company’s value is on delivering products, instead of delivering means to get the job done for your customer, you are extremely vulnerable for disruption.
As companies are looking to get their job done in the most efficient manner, they will switch at any time to new solutions that provide a better way to get the job done, often with a better performance and at a lower price point.
ERP has a well defined job
I realized that this is one of the big differences between PLM and ERP. Why is there such a discussion around the need for PLM and I do not catch the same messages from the ERP domain ? Maybe because I am a PLM consultant?
ERP has a clear mission: “To get the job done – deliver a product as efficient and fast as possible to the customer”. ERP is an execution system. Although ERP vendors as well are delivering more than their individual customers ask for, the job is more clear defined.
PLM does not have a clear job
For PLM, it becomes fuzzy. What is the job that PLM does ? Here, we get a lot of different answers. Have a look at these definitions from some vendors.
Quote from the Siemens website
CIMdata calls PLM “the most effective investment you can make to achieve product leadership.” AMR Research says “Companies committed to time to value in product innovation certainly cannot succeed without a sound PLM foundation.”
Product Lifecycle Management, or PLM, is a driver of successful product development, and a strategic contributor to business value across the enterprise. PLM helps product manufacturers manage complex, cross-functional processes, coordinating the efforts of distributed teams to consistently and efficiently create the best possible products
Quote from the Autodesk website
For companies of any size, Autodesk PLM 360 helps to streamline your business processes for more efficient product development, improved profitability, and higher product quality.
I also reviewed the websites from the other PLM vendors, and I can confirm: None of them is talking in a clear way which job needs to be done. All PLM solutions are around technology and products.
Companies want to get the job done
And here I come back to the webinar’s conclusion. If you want to secure your future as a company, you need to focus on the job to be done. And even better, focus on the experience to do the job and the best integration of these experiences in a total framework. See the slide below:
My interpretation is that PLM has not even reached level 1. Still many companies are struggling to understand the fundamental need(s) for PLM.
Interesting to see is that Dassault Systemes in their messaging and approach is already targeting level 2 – the experiences. If potential customers will embrace the experience approach without passing level 1, is something to observe.
Will PLM disappear ?
In my December 2008 blog post “PLM in 2050” and recently in The Innovator’s dilemma and PLM, I wrote that I believe PLM as it is currently defined, will disappear. Perhaps made redundant by a collection of disruptive technologies. Main reason is that PLM does not do a single, clear job.
One of these disruptive candidates to my opinion is Kenesto. They deliver “social business enterprise software to empower teams” as stated on their website. Kenesto is not considered as a competitor of classic PLM, starting on a different trajectory. For sure there will be more disruptive candidates aiming at different pieces of the PLM scope.
What do you think:
- Does PLM have too many jobs ?
- Will PLM survive disruption ?
The brain has become popular in the Netherlands in the past two years. Brain scientists have been publishing books sharing their interpretations on various topics of human behavior and the brain. Common theme of all: The brain is influencing your perceptions, thoughts and decisions without you even being aware of it.
Some even go that far by claiming certain patterns in the brain can be a proof if you have a certain disorder. It can be for better or for worse.
“It was not me that committed this crime; it was my brain and more…”
Anyway this post will be full of quotes as I am not the brain expert, still giving the brain an important role (even in PLM)
“My brain? That´s my second favorite organ” – Woody Allen
It is good to be aware of the influence of the brain. I wrote about this several times in the past, when discussing PLM vendor / implementer selection or when even deciding for PLM. Many of my posts are related to the human side of justifying and implementing PLM.
As implementing PLM for me primary is a business change instead of a combination of IT-tools to implement, it might be clear that understanding the inhibitors for PLM change are important to me.
In the PLM communities, we still have a hard job to agree between each other what is the meaning of PLM and where it differs from ERP. See for example this post and in particular the comments on LinkedIn (if you are a member of this group): PLM is a business process, not a (software) tool
And why it is difficult for companies to implement PLM beside ERP (and not as an extension of ERP) – search for PLM and ERP and you find zillions of thoughts and answers (mine too).
The brain plays a major role in the Why PLM we have ERP battle (blame the brain). A week ago I read an older publication from Charles Roxburgh (published in May 2003 for McKinsey) called: Hidden flaws in strategy subtitle: Can insights from behavioral economics explain why good executives back bad strategies. You can read, hear and download the full article here if you are a registered user.
The article has been written long before the financial and global crises were on the agenda and Mr. Roxburgh describes 8 hidden flaws that influence our strategic decision making (and PLM is a strategy). I recommend all of you to read the full article, so the quotes I will be making below will be framed in the bigger picture as described by Mr. Roxburgh. Note all quotes below are from his publication.
Flaw 1: Overconfidence
We often make decisions with too much confidence and optimism as the brain makes us feel overconfident and over optimistic about our own capabilities.
Flaw 2: Mental accounting
Avoiding mental accounting traps should be easier if you adhere to a basic rule: that every pound (or dollar or euro) is worth exactly that, whatever the category. In this way, you will make sure that all investments are judged on consistent criteria and be wary of spending that has been reclassified. Be particularly skeptical of any investment labeled “strategic.”
Here I would relate to the difference in IT-spending and budget when you compare ERP and PLM. ERP spending is normal (or strategic) where PLM spending is not understood.
Flaw 3: The status quo bias
People would rather leave things as they are. One explanation for the status quo bias is aversion to loss—people are more concerned about the risk of loss than they are excited by the prospect of gain.
Another reason why adapting and implementing PLM in an organization is more difficult than for example just automating what we already do.
Flaw 4: Anchoring
Anchoring can be dangerous—particularly when it is a question of becoming anchored to the past
PLM has been anchored with being complex and expensive. Autodesk is trying to change the anchoring. Other PLM-like companies stop talking about PLM due to the anchoring and name what they do different: 3DExperience, Business Process Automation, …..
Flaw 5: The sunk-cost effect
A familiar problem with investments is called the sunk-cost effect, otherwise known as “throwing good money after bad.” When large projects overrun their schedules and budgets, the original economic case no longer holds, but companies still keep investing to complete them.
I have described several cases in the past anonymously; where companies kept on investing and customizing their ERP environment in order to achieve PLM goals. Although it never reached the level of acceptance and quality a PLM system could offer, stopping these projects was impossible.
Flaw 6: The herding instinct
This desire to conform to the behavior and opinions of others is a fundamental human trait and an accepted principle of psychology.
Warren Buffett put his finger on this flaw when he wrote, “Failing conventionally is the route to go; as a group, lemmings may have a rotten image, but no individual lemming has ever received bad press.”
A quote in a quote but so true. Innovative thinking, introducing PLM in a company requires a change. Who needs to be convinced? If you do not have consensus (which usually happens as PLM is vague) you battle against the other lemmings.
Flaw 7: Misestimating future hedonic states
Social scientists have shown that when people undergo major changes in circumstances, their lives typically are neither as bad nor as good as they had expected—another case of how bad we are at estimating. People adjust surprisingly quickly, and their level of pleasure (hedonic state) ends up, broadly, where it was before
A typical situation every PLM implementation faces: users complaining they cannot work as efficient anymore due to the new system and their work will be a mess if we continue like this. Implementers start to customize quickly and we are trapped. Let these people ‘suffer’ with the right guidance and motivation for some months (but this is sometimes not the business model the PLM implementer pushes as they need services as income)
Flaw 8: False consensus
People tend to overestimate the extent to which others share their views, beliefs, and experiences—the false-consensus effect. Research shows many causes, including these:
- confirmation bias, the tendency to seek out opinions and facts that support our own beliefs and hypotheses
- selective recall, the habit of remembering only facts and experiences that reinforce our assumptions
- biased evaluation, the quick acceptance of evidence that supports our hypotheses, while contradictory evidence is subjected to rigorous evaluation and almost certain rejection; we often, for example, impute hostile motives to critics or question their competence
- groupthink, the pressure to agree with others in team-based cultures
Although positioned as number 8 by Mr. Roxburgh, I would almost put it as the top when referring to PLM and PLM selection processes. So often a PLM decision has not been made in an objective manner and PLM selection paths are driven to come to the conclusion we already knew. (Or is this my confirmation bias too 
)
Conclusion
As scientists describe, and as Mr. Roxburgh describes (read the full article !!!) our strategic thinking is influenced by the brain and you should be aware of that. PLM is a business strategy and when rethinking your PLM strategy tomorrow, be prepared to avoid these flaws mentioned in this post today.
Two years ago I wrote a post called PLM in 2050 as the concluding post for 2008. Now two years later it is time to see what has changed my landscape during this period. Are we going to a predictable future or are new trends arising ?
These were the points I raised at that time:
1. “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 bankruptcy for many companies providing translators and exchange software.”
I believe this trend is still happening only the big risk here is that it requires an open standard definition of this UUID. I am sure that before my retirement (see later below), there will be no global standard. There will be platform-vendor specific UUIDs and the challenge will be to operate in a heterogeneous platform-heterogeneous vendor environment. I feel less discussion on this topic in my environment, therefore the downward arrow.
2.”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)”
For sure this is the most important trend and I would rank it now as the number one trend for 2010. I just read an interesting article about Cloud Computing Predictions which addresses all dimensions of a cloud strategy and execution – very much worth reading.
What you see in that article and also around you, is that there is going to be a battle between legacy vendors, who will try to transform the cloud definition to a private cloud into a way it suits their platform, and the new cloud solution vendors which also require a platform and from there build and extend their services. It relates to one of the other trends I also mentioned in the 2008 post:
3. “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”
Combined with the new battle around the services platform it will be clear that in this approach dominant business systems, like CRM, ERP and PLM will no longer exist, as the focus will be to build business processes based on services and apps on a platform. Here I see PLM as the last hurdle to take. CRM already is understood by the market that it can be replaced by a cloud based solution, the first ERP attempts are already there too, but as PLM is a more, diverse and wide set of non-standardized functions, you will see that in this area the challenge to offer the required PLM capabilities will be the biggest. Another rising trend PLM vendors will move more towards the manufacturing execution, where ERP vendors will provide more PLM services.
The battle will be around, who owns the intellectual property of the company and where it is stored and managed.
4. “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”
This trend will also continue I believe and combined with different types of user-interfaces, mainly from the gaming world; the virtual reality will be the space where we do the most of our engineering work, shopping experience and entertainment. Big question will be, especially for the Matrix fans, will the real world stop to exist? So also here a growing trend – 3D television, 3D communication narrow the gap between the real and virtual world and understanding.
A trend I did not pick up at that time was the issue of social media and their influence on the existing business processes. At that time I wrote:
5. “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.”
And I have to say I was completely wrong there. Thanks to social communities, I am spending now more time per day to jump from community to community, from blog post to blog post (I admire my colleagues who have time to produce blog posts). Meanwhile I try to follow all my Twitter and Facebook friends and meanwhile processing the messages coming from everywhere, without having time to really dig into a problem I want to solve.
So quickly I post a question in various forums to see if someone has the answer, as I have not time to solve it anymore – hopefully somewhere in the world there will be a person who has the answer or time. Where to position this new trend into the relation of PLM is still a question for me. Yes, collaboration becomes easier, less boundaries, but also less structure to store data. Intelligent search engines which also understand the context of the information become more and more important, as we cannot structure upfront all information as we did in the classical past.
Due to the economical crisis another trend came clear. There is no retirement money left for the older workforce that should retire in the next 20 years. So companies will have a new generation of people asking the questions and if the older workforce adapts the new social media capabillities, they can be the ones that provide the answers.
In 2050 I will just be retired at the age of 90, and according to statistics, I have still another 20 years to enjoy my bionic life.
I wish you all a happy and successful new year and that the good dreams may come true.
Keep innovation and sustainability on your agenda
In 2008 and 2009 several analysts predicted that the mid-market was now ready for PLM and that most of the PLM vendors were building a targeted offering for the mid-market. I was, and still am, a believer that mid-market companies will benefit from PLM in case ………… they implement it.
When you review my observations in my blog from the past two years, apparently this does not seem to happen. Therefore in the past months, I have been analyzing posts and discussions around the ‘old’ and ‘new’ PLM, I have been talking with representatives from various PLM and PDM vendors, and last but not least analyzed what was the implementation process of a PLM system in companies, where I could get these insights.
This all lead to this post, perhaps too big for a blog, too small for a report.
First the definitions
Before giving my opinion, first my definitions of PLM and mid-market (as everyone has their own definition):
PLM means for me the management of all product related data and processes, from the initial concept phase, through planning, development, production planning and after sales/service. When talking about PLM, I have always a circular process in mind. Experiences from products in the market are again inputs for new product development. Instead of a linear process where every department manages their own data, the challenge is that every discipline contributes and collaborates around the product data. This implies that a PLM implementation always requires a business change process for a customer
Mid-market companies are for those companies where there is no strategic layer available plus a minimized investment in IT-resources. This leads to organizations where most changes are happening inside departments and cross-departmental changes are hard to implement. The IT-department might be a facilitator here but usually IT people focus on architecture and infrastructure instead of business change. This implies that a PLM changed should come from external people.
And who are doing PLM?
On the enterprise level, there is a battle between the big three (Dassault Systems, Siemens and PTC) and they are challenged mostly by the two big ERP vendors (SAP and Oracle) and on the PLM front by Aras, competing through its Open Source model. Of course there are many other vendors. These observations come from the area where I am active.
There are various ways to group these PLM vendors; one is from the CAD engine point of view: DS-CATIA / Siemens-NX / PTC-Pro/E. Although all claim to support a multi-CAD environment, the main focus in these companies is around the PLM integration with their primary CAD engine.
Where in the past, CAD independent PDM systems existed (Metaphase, MatrixOne), they could only survive in the major PLM industries by being integrated with CAD tools and were acquired for that reason. It will be interesting to see if Aras can play a major role in the PLM only domain, where others failed in the past due to lack of integration capabilities.
SAP and Oracle took a different path; they have understood that PLM cannot be neglected in an enterprise, so they need to address it. SAP did this by developing a PLM module as a logical extension on their infrastructure. Oracle has chosen to add PLM to their portfolio by the acquisition of two different PLM vendors. Where SAP does not have the challenge to explain to customers a full integrated story, Oracle has to spend more time on marketing to make it look like a single platform, which will come in the future. Big question however for both companies: do they really understand PLM? Is it in their veins and core strategy or does it remain an extension to gain market share, especially as you have no connections to the design world? (Try to find PLM on their corporate website).
Interesting to see how Aras will evolve. In their business model, the initial purchase of software is not needed, but once working with Aras you pay also for maintenance like with other PLM vendors. Their advantage is that switching from an existing legacy PLM vendor is less painful, as there are no initial software costs, which can be huge for an enterprise. I believe they have a good chance to succeed in industries where there is less a dependency on the CAD engine.So on the enterprise level the need for PLM is justified. Resources exist and are budgeted both at the customer level as at the supplier level. The PLM suppliers are either the PLM vendors themselves with service teams, or big, global service providers specialized in implementing the PLM software. They can do strategic PLM projects and support the required business change.
So why does it look like a mission impossible in the mid-market ?
The big enterprise vendors (PLM/ERP) believe that you can just strip down your enterprise software in a kind of prepackaged mode – PLM Out of the Box is a common heard expression. Also the analysts praise in their reports the mid-market approach from some of these vendors.
But do they really address the mid-market or only the high-end mid-market? Again it is all about the definition of where is the mid-market and in this post I stay with my definition of mid-market.
There are two main characteristics for this mid-market:
- Sales and implementation of software is done through Value Added Resellers and not through the vendors or big service companies. The software revenue per customer does not justify high expenses for global consultants with additional high expenses due to travel costs (and sometimes the local language issue). The local VAR is supposed to be the point of contact.
- Mid-market companies do not change their main company processes. Depending on the type of core process, let’s assume ETO or BTO, they have sales and engineering working close together on product/solution definition and they have manufacturing planning and production working close together on product/solution delivery. In term of functionality a PDM focus for sales/engineering and an ERP focus for manufacturing.
A mid-market company can be characterized as a two pillar company :
Who are successful in the mid-market ?
There are two software vendors, touching our PLM prospects , that really understand the mid-market, Autodesk and Microsoft.
Autodesk has a huge range of products and when we focus on the area of manufacturing, Autodesk does not talk about PLM. And I believe for several reasons.
Autodesk has never been a front-runner in making new technology and concepts available for the mainstream. They are more a company providing functionality for mainstream concepts, as compared to a company pushing new concepts and technology for premium pricing.
And this is what their customers like, as they also do not have internal strategic resources to push the company to new directions and surely no one wants to take the risk.
Thus risk avoidance and understandable concepts are key targets for mid-market companies.
Autodesk tries to avoid reaching beyond their engineering domain, the maximum they cover is presented in their Digital Prototyping solution. With their Vault product range they stay close to PDM, but do not go into the concepts of PLM, like mBOM handling. PLM is not established enough in the mid-market, so a no-go area for Autodesk.
Microsoft addresses the mid-market more from the IT-infrastructure. Slowly SharePoint has reached a certain status of an infrastructure component for content management – so why not for all the engineering data? SharePoint is the most relevant component related to PDM or PLM in my review and what I observed here is that the IT-manager often is the person who supports and enables a cross-departmental implementation of SharePoint. So not pushed from a strategic business level but from a strategic IT architecture approach.
PLM providers and implementers jumped on this opening in the mid-market by providing PLM capabilities on top of SharePoint. This to get their software used in the mid-market. It does not mean they do PLM, it means they expand the visibility of engineering data across the organization. Microsoft apparently does not want to enter the area of managing CAD or engineering data. You see mainly investments in the Microsoft Dynamics software, where ERP and CRM are targeted. Again PLM is not established enough in the mid-market to provide common functionality, so a no-go area for Microsoft.
And the impact of a indirect sales channel….
VARs are the next challenge for PLM in the mid-market. The PLM Vendors, who work with VARs, expect that these VARs are an extension of their sales organization. And sales means here selling software . PLM means however also selling services and I learned in the hard way in my past that companies selling products and services within the same group of people are constant in internal conflict how to balance software and service budgets
Selling and implementing PLM software is also difficult in mid-market companies as these companies buy software because they want to solve a pain in one of their departments. It is not common that they have a holistic approach. So VARs trying to sell PLM are engineering centric – often with their roots in CAD Selling. And as their nature comes from product selling, they feel comfortable in selling data management and PDM as this remains close to product features easy to justify. PLM requires different people, who can guide a business change across departments at the customer.
It is very rare for VARs to have these skilled people in place due to lack of scale. You need to act local to be cost efficient and close to your customer. As a VAR has only visibility of a limited group of implementations, the consultancy practices often are not based on global experience and best practices, but defined on their own best practices, sometimes bring their ‘magic’ to be even more different than required, to differentiate from other VARs.
The companies implementing PLM for enterprises can afford to share global knowledge; VARs need to build up the knowledge locally, which leads to an extreme dependency on the person who is available. And to be affordable on the payroll a VAR, the consultant often is an experienced application engineer, who knows to satisfy his customer by providing services on top of the product.
And as PLM is not established enough in the mid-market, they will not invest and push for PLM which requires a long term experience build-up, so almost a no-go area for VARs
So no PLM in the mid-market?
I believe real PLM in my mid-market will be a rarity, based on a lucky coincidence of the right people, the right company and the right product at a certain time. It will not become a main stream solution in the mid-market as there is the design world and the ERP world.
PLM SaaS (Software As A Service) delivered by Arena or PLMplus will not bring the solution either for the mid-market. You might remove the IT complexity, but you are missing the resources (internal and external) for business change – who will be there to initiate and guide the change . PLM SaaS probably will be implemented as a PDM environment.
I give more credits for Social PLM (Facebook alike collaboration, Google Wave). This approach might bypass the classical way of working in companies and lead to new concepts, which probably will not be tagged PLM – will the new trigram be SPC (Social Product Collaboration) ?
Still it will not happen fast I believe. It requires a change of the management in mid-market companies. Most of the managers are representative of the older generation, not wanting to take the risk to jump on a new hype they haven’t made themselves familiar yet
Conclusion: PLM in the mid-market seems like a mission impossible and although PLM concepts are valuable for the mid-market as analysts report, the typical mid-market characteristics block PLM to become a common practice there.
I am looking forward to learn from your comments
In my previous post, BOM for Dummies related to Configure To Order, I promised to come back on the special relation between the items in the BOM and the CAD data. I noticed from several posts in PLM and PDM groups that also the importance of CAD data is perceived in a different manner, depending on the background of the people or the systems they are experienced with.
So I would like to start with some general statements based on these observations.
People who are talking about the importance of CAD data and product structures are usually coming from a background in PDM. In an environment where products are designed, the focus is around data creation, mostly CAD data. The language around parts in the BOM is mostly targeting design parts. So in a PDM environment CAD data is an important topic – therefore PDM people and companies will talk about CAD data and vaults as the center of information.
When you are working in a PLM environment, you need a way to communicate around a product, through its whole lifecycle, not only the design phase but also supporting manufacturing phases, the possible changes of an existing product through engineering changes, the traceability of as-built data and more. In a PLM environment, people have the physical part (often called the ERP part) in mind, when they talk about a part number.
As PLM covers product information across various departments and disciplines, the information carrier for product information cannot be the CAD data. The BOM, usually the mBOM, is the main structure used to represent and produce the product. Most parts in the mBOM have a relation to a CAD document (in many companies still the 2D drawing). Therefore PLM people and companies understanding PLM will talk about items and products and their lifecycle as their center of information.
CAD data in relation to Engineering to Order
The above generalizations have to be combined with the different main business processes. In a strict Engineering To Order environment, where you design and build a solution only once for a specific customer, there is no big benefit of going through an eBOM and mBOM transition.
During the design process the engineer already has manufacturing in mind, which will be reflected in the CAD structure they build – sometime hybrid representing both engineering and manufacturing items. In such an environment CAD data is leading to build a BOM structure.
And in cases where engineering is done in one single 3D CAD system, the company might use the PDM system from this vendor to manage their Bill of Materials. The advantage of this approach is that PDM is smoothly integrated with the design environment. However it restricts in a certain matter the future as we will see in further reading.
Not everyone needs the Engineering to Order process !
Moving to an integrated, multi-disciplinary engineering process or changing the main process from Engineering To Order to Built To Order / Configure To Order will cause major challenges in the company.
I have seen in the recent past, several companies that would like to change their way of working from a CAD centric Engineering To Order process towards a more Built to Order or Configure To Order process. The bottle neck of making this switch was every time that engineering people think in CAD structures and all knowledge is embedded in the CAD data. They now want to configure their products in the CAD system.
For Configure to Order you have to look at a different way to your CAD data:
Questions to ask yourself as a company are:
- When I configure my products around a CAD structure, what should I do with data from other disciplines (Electrical/Tooling/Supplier data) ?
- When I upgrade my 3D CAD system to a new version, do I need to convert all old CAD data to the newest versions in order to keep my configurations alive?
- When configuring a new customer solution, do I need to build my whole product in CAD in order to assure it is complete?
- In Configure to Order the engineering BOM and manufacturing BOM are different. Does this mean that when I go through a new customer order, all CAD data need to be handled, going through eBOM and mBOM transition again?
For me it is obvious that only in an Engineering to Order environment the CAD data are leading for order fulfillment. In all other typical processes, BTO (Built to Order), CTO (Configure to Order) and MTS (Make to Stock), product configuration and definition is done around items and the CAD data is important associated data for the product definition and manufacturing
In the case of order fulfillment in a Configure to Order process, the CAD structure is not touched as configuration of the product is available based on items. Each item in the mBOM has it relations to CAD data or other specifying information.
In the case of Built To Order, a huge part of the product is already configured, like in Configure To Order. Only new interfaces or functionality will go through a CAD design process. This new design might be released through a process with an eBOM to mBOM transition. In cases where the impact or the amount of data created in engineering is not huge, it is even possible to configure the changes immediately in an mBOM environment.
A second point, which is also under a lot of discussion in the field ( PLM interest groups), is that PDM is easily to introduce as a departmental solution. The engineering BOM is forwarded to manufacturing and there further (disconnected) processed. The step from PDM to PLM is always a business change.
When PDM vendors talk about ERP integration, they often mean the technical solution of connecting the two systems, not integrating the processes around the BOM (eBOM/mBOM transition) 0r an integrated engineering change (ECR/ECO). See how easy it is according to some PDM vendors:
or
PLM requires an adaptation of all departments to work different and together around a single product definition. Especially in a mid-market company, this is a big issue, as all product knowledge is stored in the CAD data and the knowledge how to produce the product is stored in the mBOM on the ERP side. These environments are often disconnected.
Conclusion: In the context of PDM the importance of CAD data is clear and for companies following a strict Engineering To Order process the main source of product knowledge. Companies following the Built To Order / Configure To Order process should configure their products around items to keep flexibility towards the future.
Companies with the intention to move to Built To Order or Configure To Order should not invest too much in CAD data configuration as it creates a roadblock for the future.
In my next post I will address the question that comes up from many directions, addressed by Jim Brown and others, as discussed in one of his recent posts around a PLM standard definition and more ….
Continuing the posts on Bill of Material handling for different types of companies, this time the focus on BOM handling in a Build to Order process. When we are talking about Build to Order process, we mean that the company is delivering solutions for its customers, based on existing components or modules. A typical example is the food processing industry. In order to deliver a solution, a range of machinery (ingredient manipulation) and transporting systems are required. The engineering tasks are focused on integrating these existing components. In many cases new or adjusted components are required to complete the solution.
Research and Development in a BTO company
In a typical BTO company you see actually two processes.
- The main BTO process, fulfilling the needs for the customers based on existing components
- An R&D department, which explores new technologies and develops new components or modules, which will become available for selling to new customers.
This is the innovation engine of the company and often can be found in a complete isolated environment – extra security – no visibility for other departments till release. The task for this R&D department is to develop machinery or modules based on new, competitive technologies, which are rapidly configurable and can be used in various customer solutions. The more these machines or modules are configurable, the better the company can respond to demands from customers, assuming a generic machine and interfaces does not degrade performance, compared to optimal tuned machinery.
I will describe the BOM handling for this department in a future post, as also here you will see particular differences with the ETO and BTO BOM handling.
Back to the core of BTO
I found a nice picture from 2003 published by Dassault Systems describing the BTO process:
We see here the Bidding phase where a conceptual BOM is going to be defined for costing. Different from the ETO process, the bidding company will try to use as much as possible known components or technology. The reason is clear: it reduces the risk and uncertainties, which allow the bidding company to make a more accurate and competitive cost estimate for these parts. When a company becomes mature in this area, a product configurator can be used to quantify the estimated costs.
The result from the bidding phase is a conceptual BOM, where hopefully 60 % or more is already resolved. Now depending on the amount of reuse, the discussion comes up: Should modifications being initiated from the eBOM or from the mBOM?
In case of 60 % reuse, it is likely that engineering will start working around the eBOM and from there complete the mBOM. Depending on the type of solution, the company might decide to handle the remaining 40 % engineering work as project unique and treat it the same way as in an ETO process. This means no big focus on the mBOM as we are going to produce it only once.
I have worked with companies, which tried to analyze the 40 % customer specific engineering per order and from there worked towards more generic solutions for future orders. This would mean that a year later the same type of order would now be defined for perhaps 80 %. Many companies try to change themselves from a project centric company towards a product centric company, delivering configured products through projects.
Of course when solutions become 100 % configurable, we do not speak from BTO anymore, but from Configure to Order (CTO). No engineering is needed; all components and interfaces are designed to work together in certain conditions without further engineering. As an example, when you buy a car or you order a PC through the internet – it is done without sales engineering – it is clearly defined which options are available and in which relation.
See below:
However the higher the amount of reuse, the more important it becomes to work towards an mBOM, which we will than push the order to ERP.
And this is the area where most of the discussions are in a PLM implementation.
- Are we going to work based on the mBOM and handle all required engineering modifications from there?
Or
- Do we first work on a complete eBOM and once completed, we will complete the mBOM?
The reuse from existing components and modules (hardware) is one of the main characteristics of BTO. Compare this to ETO where the reuse of knowledge is the target no reuse of components.
The animation shows the high level process that I discussed in this post.
What PLM functions are required to support Build to Order ?
- Project management – the ability to handle data in the context of project. Depending on the type of industry extended with advanced security rules for project access
- Document management – where possible integrated with the authoring applications to avoid data be managed outside the PLM system and double data entry
- Product Management - managing all released and available components for a solution, related to their Bill of Materials. Often part of product management is the classification of product families and its related modules
- Item management – The main activities here are in the mBOM area. As items in a BTO environment are reused, it is important to provide relevant ERP information in the PLM environment. Relevant ERP information is mostly actual costs, usage information (when was it used for the last time) and availability parameters (throughput time / warehouse info).
As historically most of the mBOM handling is done in ERP, companies might not be aware of this need. However they will battle with the connection between the eBOM in PLM and the mBOM (see many of my previous posts).
As part of the BTO process is around engineering, an EBOM environment with connections to specifying documents is needed. This requires that the PLM system has eBOM/mBOM compare capabilities and an easy way to integrate engineering changes in an existing mBOM.
- Workflow processes – As we are dealing with standardized components in the BOM, the Engineering Change Request (ECR) and Engineering Change Order (ECO) processes will be the core for changes. In addition you will find a Bidding Process, a Release process for the customer order, Manufacturer Change Order process and a Standard Item Approval process.
Optional:
- A Sales Configurator allowing the sales engineering people to quickly build the first BOM for costing. Working with a Sales Configurator requires a mature product rationalization.
- Supplier Exchange data management – as many BTO companies work with partners and suppliers
- Service Management – as an extension of item management. Often in this industry the company who Builds the solutions provides maintenance services and for that reason requires another Bill of Material, the service BOM, containing all components needed when revising a part of the machine
- Issues Management – handling issues in the context of PLM gives a much better environment for a learning organization
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery
Conclusion (so far):
When you compare these PLM requirements with the previous post around ETO, you will discover a lot of similarities. The big difference however is HOW you use them. Here consultancy might be required as I do not believe that by having just functionality a company in the mid-market will have time to learn and understand the special tweaks for their business processes.
Next post more on configurable products
This time a few theoretical posts about BOM handling, how the BOM is used in different processes as Engineering To Order (ETO), Make To Order (MTO) and Build To Order (BTO) organizations and finally which PLM functions you would expect to support these best practices.
I noticed from various lectures I gave, from the search hits to my blog and from discussions in forums that there is a need for this theoretical base. I will try to stay away from too many academic terminologies, so let’s call it BOM for Dummies.
Note: All information is highly generalized to keep is simple. I am sure in most of the companies where the described processes take place more complexity exists.
What is a BOM?
A BOM, abbreviation for Bill of Materials, is a structured, often multi-level list of entities and sub-entities used to define a product
I keep the terminology vague as it all depends to who is your audience. In general when you speak with people in a company that does engineering and manufacturing, you have two major groups:
- The majority will talk about the manufacturing BOM (mBOM), which is a structure that contains the materials needed to manufacture a product in a certain order.
We will go more in depth into the mBOM later. - When you speak with the designers in a company they will talk about the eBOM, which is a structure that contains the components needed to define a product.
Both audiences will talk about ‘the BOM’ and ‘parts’ in the BOM, without specifying the context (engineering or manufacturing). So it is up to you to understand their context.
Beside these two major types of BOMs you will find some other types, like Conceptual BOM, Customer Specific BOM, Service BOM, Purchase BOM, Shipping BOM.
Each BOM is representing the same product only from a different usage point of view
The BOM in an Engineering To Order company
In an Engineering to Order company, a product is going to be developed based on requirements and specifications. These requirements lead to functions and systems to be implemented. For complex products companies are using systems engineering as a discipline, which is a very structured approach that guarantees the system you develop is matching all requirements and these requirements have been validated.
In less complex and less automated environments, you will see that the systems engineering is done in the head of the experienced engineers. Based on the requirements, they recognize solutions that have been done before and they build a first conceptual structure to describe the product. This is a conceptual BOM, often only a few levels deep, and this BOM is mainly used for costing and planning the work to be done.
A conceptual BOM could like this (open the picture in a separate window to see the animation)
Depending of the type of engineering company, they are looking for the reuse of functions or systems. The reuse of functions means that you manage your company’s Intellectual Property (IP) where the reuse of systems can be considered as the reuse of standard building blocks (modules) to build a product. The advantage of system reuse of course is the lower risk, as the system has been designed and built and tested before.
From the conceptual BOM different disciplines start to work and design the systems and their interfaces. This structure could be named the eBOM as it represents the engineering point of view from the product. In Engineering to Order companies there is a big variation on how to follow up after engineering. Some companies only specify how the product should be made, which materials to use and how to assemble them. The real manufacturing of the product is in that case done somewhere else, for example at the customer site. Other companies still do the full process from engineering and manufacturing.
As there is usually no reuse of the designed products, there is also no investment in standardizing items and optimizing the manufacturing of the product. The eBOM is entered in the ERP system and there further processed to manufacture the product. A best practice in this type of environments is the approach that the eBOM is not a 100 % pure the eBOM, also items and steps needed for manufacturing might be added by the engineers as it is their responsibility to specify everything for manufacturing without actually making the product.
This animation shows on high level the process that I described (open the link in a separate window to see the animation)
What PLM functions are required to support Engineering To Order
The following core functions apply to this process:
- Project management – the ability to handle data in the context of project. Depending on the type of industry extended with advanced security rules for project access
- Document management – where possible integrated with the authoring applications to avoid data be managed outside the PLM system and double data entry
- Classification of functions and/or systems in order to have an overview of existing IP (what have we done) and to promote reuse of it
- Item management – to support the eBOM and its related documentation. Also the items go through a lifecycle representing its maturity:
- The eBOM might be derived from the mechanical 3D CAD structure and further extended from there.
- For design reviews it would be useful to have the capability to create baselines of the eBOM including its specifying documents and have the option to compare baselines to analyze progress
- The completed eBOM would be transferred to the ERP system(s). In case of a loose ERP connection a generic XML export would be useful (or export to Excel as most companies do) - Workflow processes – to guarantee a repeatable, measurable throughput of information – both approval and change processes
Optional:
- Supplier Exchange data management – as many ETO companies work with partners and suppliers
- Issues Management – handling issues in the context of PLM gives a much better environment for a learning organization
- Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery
- A configurator allowing the sales engineering people to quickly build the first conceptual BOM based on know modules combined with engineering estimates. This is the base for a better controlled bidding / costing
Let me know if this kind of posts make sense for you …..
Next time we will look at the BOM in a Build To Order process
Two weeks ago I was writing about the Silent PLM approach. What I showed in that post that often the PLM vision as a complete vision does not exist in all layers of the organization.
Often the management in is not aware of where and how PLM can have an impact. In the Silent Management approach, one or more visionary people believe they can introduce PLM by starting it in their department, and from there grow and extend the impact of PLM. As I concluded, this approach usually fails in most of the cases as when the decisive step comes to extend PLM to other departments and to change current processes, this is the point where is mostly gets stuck.
Other departments and the management do not see how this engineering / CAD extension could benefit for them and the whole organization. Why not extending our ERP system as this already exists ? And here a stand still will come up until a push comes. The push can come from the top or from the outside world. From my experience more then half of the companies that started this silent PLM approach got stuck where they are ……..
So this time another approach, called the academical approach. And again a disclaimer, I am generalizing and putting some points a little more in the extreme to demonstrate the difference between the approaches. Any similarity with the real world is pure coincidence
Approach 2: Academical PLM
Inside our mid-market company ACCPY, the management has understood that PLM will bring a lot of benefits and in case they were not aware of it, they have learned from analyst reports, from blogs and from their network that PLM should bring a lot benefit for them.
So the management decides to prepare and educate themselves and they start a PLM taskforce inside ACCPY to collect and digest all the information. The team has enthusiastic members from all departments and starts buying some books and reports on PLM. In addition they visit some PLM events all around the country and sometimes around the continent. These visits lead to contact with PLM Vendors who also start to educate why their PLM is the one fitting ACCPY the best. After one or two years of education they are theoretical skilled and know to differentiate between EDM, PDM, cPDM and even they learn to understand the difference between PDM and ERP.
As a conclusion of their learning stage the PLM taskforce presents to the management a firm report, explaining what is PLM and how ACCPY can benefit from it plus recommendations how to proceed.
The management is happy with the result, that what they thought two year ago was really valid and agrees with the report and recommendations. Now the selection of the PLM system needs to be done and who will be the implementation partner. Although all PLM vendors have been knocking on their door already to explain the benefits and implementation approach from their solution, ACCPY decides to hire an ‘independent’ PLM consultancy firm to assist with the selection of the solution.
The consultancy firm starts with interviewing the key members of ACCPY, in order to understand the major processes and the needs per department. A month later they present to the management a PLM Vendor Selection Procedure, where in 15 pages the PLM Vendor has to explain and confirm requirement per requirement, the implementation approach and give a budget estimate.
This RFQ will be sent to 5 PLM vendors which were already in touch with ACCPY since the PLM research started. Also the consultancy firm brought in a company which they new very well. It takes a few weeks for the consultancy firm to compile the RFQ and two months later the responses are there.
From the received proposals three PLM vendors are invited to benchmark their system and company based on a business case developed by the consultancy firm together ACCPY.
PLM Vendor 1
The first PLM vendor gives a standard demo of the system and explains that the business case is well known to them and therefore instead of showing it, they give a whole set of screenshots and references. The attendees had a good feeling with this vendor
PLM Vendor 2
The second PLM vendor tries to follow exactly the business case as defined. The attendees liked the fact that all was demonstrated so well, however the PLM system seems to be rather too complex and giving a lot of overhead to the engineers, according to their impression.
PLM Vendor 3
The third PLM vendor was already known to the company as they were also providing the 3D CAD system. In their presentation they explained how well they knew ACCPY already and that the business case was too artificial. They demonstrated some gadgets of their PLM system which none of the competing vendors could do, thanks to their tight integration with the CAD system. The attendees were impressed, however a few days later, they were asking themselves, why were those gadgets needed ? None of the other vendors talked about it and it was also not part of the RFQ.
So now it was time for the consultancy firm together with the task force to process all the information and to determine the final score. On product features they had a nice comparison – only hard to tell what was most important. On usage it was more difficult, as they got three different approaches during the benchmark, so the scores for this section was rather artificial. Also the financial part seemed to be hard to compare but at least it gave an indication.
As it is an academical approach, my post for this week ends here. We need to give the ACCPY task force together with the consultancy firm some time to build a justification for their choice and next week we will discover how this story ended. Meanwhile ask yourself:
- how much time has passed since the management decided PLM was good for their organization ?
- how independent is the consultancy firm ?
- did they consider open source PLM as a solution ?
- what was the ranking of the PLM vendors ?
- read the book Blink the power of thinking without thinking about intuition
Conclusion (so far): Academical PLM takes time and it would be unfair to explain it all in one post.
So next week the real conclusion.
This week I realized that, although I believe the benefits of PLM are more and more accepted in mid-market companies, the decision how to start and where to start with PLM is often not clear. I recognize several approaches which I will describe in this and some upcoming posts.
All persons in this post are fiction and in case you recognize these persons in your company, it is pure coincidence. Instead of talking about approaches,I was tempted to call it strategies, but when you read my observation you will realize the word strategy would not fit.
Approach 1: The silent PLM
Inside our company, often there is an engineer or an engineering manager, who got caught by the PxM virus. The PxM virus is a modern virus, which makes you a believer that PDM or PLM will bring your company a lot of benefits. Documents and proof points of the severe impact exist all around the world. However nobody has gotten infected so far in this company. Everyone is working the way they worked since many years and life is secure and predictable.
Now this infected engineer is getting exited and dreams about the introduction of PLM in his company and how he will become the hero of the company and gets a big promotion. Unfortunate for him in this kind of business there are no big bonuses to collect, so the honor of promotion is already a big achievement.
So the first thing this engineer does is chatting with his peers and friends to find out where PxM has been implemented successful and he studies some success stories which he learned from his network.
Now the challenge starts.
He goes to the management and shows a nice PowerPoint, explaining why the company needs PxM and what are the expected benefits, based on reference stories. The management has no real clue what he is talking about, but it looks promising and they allow him to select a PxM system for his department and to start a pilot.
The engineer already knows which PxM system to choose. The one, recommended by the friendly reseller, who sold them their 3D CAD system (which is a success) and worked hard with him to finalize the slides. As requested by the management he had to invite two other PxM vendors to make an objective selection and at the end an impressive comparison matrix is shown to the management why system A has been chosen.
Now the implementation starts and step 1 is very successful. The document management part around the CAD system goes smoothly and everyone in the engineering department starts to be happy.
Following this successful implementation there are two options:
- the engineer does not get promoted and the implementation ends. It will remain a silent document management implementation and the dream is put aside.
- the engineer gets promoted and continues to push his vision as now he has a broader audience to spread the PxM virus. We will follow this story line…….
The engineer gets promoted and continues to push his vision
This is the best that can happen and the engineer, who now became the head of engineering, starts to express his vision to his fellow managers, explaining the advantages of PLM. Notice, he is now talking about PLM as the scope has been extended beyond product data management, involving other disciplines in the organization.
And here the head of engineering discovers that his fellow managers are also infected by a virus. Not the PxM virus, but one of them has already for many years the ERP virus. And as the ERP virus addresses the operational and financial tasks in the organization, the management trusts him. The sales and marketing department seems to be infected by CRM, but currently they caught a social disease, which made them push for all kind of communities. The management either likes it (as their kids are also on Facebook) or dislikes it, because they believe work is a serious business and being on internet all day is considered gaming.
So the head of engineering realizes that he has some freedom within his department, but the other departments and the management have their own priorities. And PLM is not on their list. Together with the friendly CAD reseller, who meanwhile was promoted to be Senior PLM Consultant, they work on a perfect PLM environment within the engineering department and they believe their success will show off in the upcoming years.
And then the crisis came and the company had to cut budgets. To be continued in (hopefully) 1 or 2 years
Conclusion: The silent PLM approach has a huge chance to fail as there is no corporate vision and management push to get PLM implemented. PLM should be addressed top-down. As in many mid-market companies there was also no strategically partner, who could assist the management to build a vision and to set priorities.
Next week:
approach 2: Academical PLM
The past few weeks I have been busy in an area which I believe is crucial for understanding PLM. I had meetings, web meetings with prospects, with implementers and existing customers – of course all in the mid-market. And the generalized key question on the table was: “
Yes, we understand document management, and yes, CAD management is understandable to us, but why do you need to work with the BOM further down the product lifecycle, as this is ERP, isn’t it ?
I realized several topics play a role here:
- Mid-market companies usually do not think top-down in their approach. As an example: they will not look at their whole organization’s business processes and then try to map all the activities cross departments, cross suppliers, etc. Usually they are looking per department to optimize the way they are working.
Classical enterprise PLM implementations are designed to go top-down. Describe the as-is situation, describe the the to-be situation and then transform the company to meet the to-be situation. Decisions are pushed to the people in the company as the to-be situation seems to be clear. Many of the classical PLM implementers still believe in this approach – and the risk / challenge is always that the to-be situation was not well understood, or that at the time we reach the to-be situation the environment of the company has changed and another to-be is needed. - Mid-market companies understand a central storage for documents brings a lot of benefits. Most companies realize that all this departmental archives of documents and files create too much overhead and a higher quality risk. Finding the absolute right file for a certain product release might be a quest and of course each of the departments claims that their solution fits exactly their needs. This is what I believe the main driver behind the success of SharePoint. As Microsoft Office is used as a common document authoring tool among all departments, why not use the Office Document Management tool as our common backbone ? PLM and ERP vendors might say we also manage documents, but usually these documents are managed in a structured manner – related to revisions of a product or to a product order. Usually an infrastructure to manage unstructured documents does not exist in ERP systems.
- Mid-market companies do not understand the value of managing the BOM outside ERP. As I mentioned, everyone understands documents, but items seem to be the domain of an ERP system. Understandable as ERP was often the first IT-system implemented. As mid-market companies usually do not have a holistic view, items will remain to be managed there (“as we invested so much in the first implementation the management will say – no other source for items !!!”)
And here i believe is the crucial go-no/go point for a PLM implementation. Once the company starts to understand that the definition of items is not done in the ERP system, but is a result of the work done in the engineering department, only then the value of managing the BOM outside ERP become apparent. And here is the catch 22, we already manage our documents in environments without items (BOM’s) (SharePoint / CAD Documents management) – so no place for PLM ?
So what to do as a mid-market company ?
It is hard to understand the full picture (because of the above points), can you trust the selling PLM partner ?(we have been promised easy implementations in the past with other IT-systems too) and at the end you do not believe the value PLM can bring (as you cannot imagine and digest the impact of PLM to your company)
And just when thinking about this – three articles came to my attention as they all address this topic, somehow from a different perspective:
- An upcoming white paper written by TechClarity on ENOVIA SmarTeam Express solutions
- A blog post written by Jim Brown (TechClarity) on the TeamCenter Express solution
- A blog post written by Oleg Shilovitsky (PLMtwine): PLM action plan for dummies
The first two posts deal with a packaged approach for mid-market companies, allowing them to implement PLM faster and with a faster ROI. As Jim (and many others are stating – in an economical down turn you cannot focus on efficiency only (the ERP slogan). It is innovation – better and more customer oriented and attractive products – brings much higher revenue as compared to doing more of the same more efficient.
Oleg focuses on the steps to implement PLM and I agree with most of the statements there. It needs to be gradual and implementing the business processes comes as the last phase.
There is one difference I see in my approach compared to what Jim and Oleg are writing. Both believe that PLM brings value (and i support this statement 100 % based on experiences with customers I have worked).
However the missing point to be addressed is the lack of understanding (and often also trust) of companies talking with a PLM vendor and committing to PLM. I tried to explain these points in the above 3 statements. As long as those points are not addressed, each stepped approach will lead to the question: “When are we really going to do PLM instead of CAD Document management or enhanced ERP ? “
My experiences with guiding successful PLM implementations are the following:
- Start with basic document management and CAD data management. It aligns with the understanding of companies that a centralized and secure repository for documents brings ROI. This step introduces to the company that a company wide approach of data management brings value (and ROI). Some basic processes might be introduced here already- basic document approval as required by all quality systems.
- Once basic CAD and Document Management are introduced, the company will realize that it is missing ‘place holders’ to hook the information. If you work in a document management system only, the system implementer will say: Use projects to collect your product data and use folders to collect your item related data. A PLM vendor would say; Now you are ready to introduce Items in your system, as they are the logical place holders for information. Here PLM starts to be introduced.
- Once understood that the item is a needed place holder to manage development data, the understanding for managing items in a structure becomes clear. Here we introduce the EBOM and as Items also contain logistical data, this is the first point to start connecting PLM and ERP to work with a shared ‘place holder’ but with different focus on characteristics.
- Once the Engineering BOM is understood, the discussion starts around the MBOM. Who is responsible for defining how a product is manufactured ? PLM believes this is part of their duty, ERP vendors will say, we own the item historically ,so we manage the MBOM. As a 100 % PLM believer, I think it should be in PLM as it is not part of the execution but part of the product definition (See the post I wrote on this topic: Where is the MBOM).
At the end the defined MBOM can be pushed to ERP once required. - Once you are able to manage and centralize all data related to product development and definition, a company becomes ready to guarantee the quality and flow of the data, by implementing company wide engineering change and development processes. Much in line with Oleg’s PLM action plan.
I have supported implementations of the above approach in several mid-market companies and key success factors were:
- the company understanding PLM brings benefits but also understands it will take a time to realize this vision.
Management vision and support were always there. - a PLM system that allows you to start simple with centralizing documents and keeping things understandable but also allows you to scale up to a PDM system and finally supporting the whole PLM vision once accepted and understood .
Think Top-Down – Implement Bottom-Up - an implementer who understands that in the mid-market a push of concepts will bring rejections from the end-users, and where listening to the end-users only, it will result in an unguided system. The implementation partner needs to say No at the right time and to push for Yes when needed.
The implementer is 50 % of the success !
Conclusion: A management vision, a scalable PLM system and an experienced implementation partner are needed to bring the innovation to survive in the long term – document management and ERP alone will not bring this unique value. The phased approach allows a company with digestible steps to grow to their ‘to-be’ situation – as building trust and understanding is still required in the mid-market of PLM
See also: ENOVIA SmarTeam Express
Recent Comments