You are currently browsing the tag archive for the ‘PDM’ tag.
In my series describing the best practices related to a (PLM) data model, I described the general principles, the need for products and parts, the relation between CAD documents and the EBOM, the topic of classification and now the sensitive relation between EBOM and MBOM.
First some statements to set the scene:
- The EBOM represents the engineering (design) view of a product, structured in a way that it represents the multidisciplinary view of the functional definition of the product. The EBOM combined with its related specification documents, models, drawings, annotations should give a 100 % clear definition of the product.
- The MBOM represents the manufacturing view of a product, structured in a way that represents the way the product is manufactured. This structure is most of the time not the same as the EBOM, due to the manufacturing process and purchasing of parts.
A (very) simplified picture illustrating the difference between an EBOM and a MBOM. If the Car was a diesel there would be also embedded software in both BOMs (currently hidden)
For many years, the ERP systems have claimed ownership of the MBOM for two reasons
- Historically the MBOM was the starting point for production. Where the engineering department often worked with a set of tools, the ERP system was the system where data was connected and used to have a manufacturing plan and real-time execution
- To accommodate a more advanced integration with PDM systems, ERP vendors began to offer an EBOM capability also in their system as PDM systems often worked around the EBOM.
These two approaches made it hard to implement “real” PLM where (BOM) data is flowing through an organization instead of stored in a single system.
By claiming ownership of the BOM by ERP, some problems came up:
- A disconnect between the iterative engineering domain and the execution driven ERP domain. The EBOM is under continuous change (unless you have a simple or the ultimate product) and these changes are all related to upstream information, specifications, requirements, engineering changes and design changes. An ERP system is not intended for handling iterative processes, therefore forcing the user to work in a complex environment or trying to fix the issue through heavy customization on the ERP side.
- Global manufacturing and outsourced manufacturing introduced a new challenge for ERP-centric implementations. This would require all manufacturing sites also the outsourced manufacturers the same capabilities to transfer an EBOM into a local MBOM. And how do you capitalize the IP from your products when information is handled in a dispersed environment?
The solution to this problem is to extend your PDM implementation towards a “real” PLM implementation providing the support for EBOM, MBOM, and potential plant specific MBOM. All in a single system / user-experience designed to manage change and to allow all users to work in a global collaborative way around the product. MBOM information then will then be pushed when needed to the (local) ERP system, managing the execution.
Note 1: Pushing the MBOM to ERP does not mean a one-time big bang. When manufacturing parts are defined and sourced, there will already be a part definition in the ERP system too, as logistical information must come from ERP. The final push to ERP is, therefore, more a release to ERP combined with execution information (when / related to which order).
In this scenario, the MBOM will be already in ERP containing engineering data complemented with manufacturing data. Therefore from the PLM side we talk more about sharing BOM information instead of owning. Certain disciplines have the responsibility for particular properties of the BOM, but no single ownership.
Note 2: The whole concept of EBOM and MBOM makes only sense if you have to deliver repetitive products. For a one-off product, more a project, the engineering process will have the manufacturing already in mind. No need for a transition between EBOM and MBOM, it would only slow down the delivery.
Now let´s look at some EBOM-MBOM specifics
EBOM phantom assemblies
When extracting an EBOM directly from a 3D CAD structure, there might be subassemblies in the EBOM due to a logical grouping of certain items. You do not want to see these phantom assemblies in the MBOM as they only complicate the structuring of the MBOM or lead to phantom activities. In an EBOM-MBOM transition these phantom assemblies should disappear and the underlying end items should be linked to the higher level.
In the EBOM, there might be materials like a rubber tube with a certain length, a strip with a certain length, etc. These materials cannot be purchased in these exact dimensions. Part of the EBOM to MBOM transition is to translate these EBOM items (specifying the exact material) into purchasable MBOM items combined with a fitting operation.
EBOM end-items (make)
For make end-items, there are usually approved manufacturers defined and it is desirable to have multiple manufacturers (certified through the AML) for make end-items, depending on cost, capacity and where the product needs to be manufactured. Therefore, a make end-item in the EBOM will not appear in a resolved MBOM.
EBOM end-items (buy)
For buy end-items, there is usually a combination of approved manufacturers (AML) combined with approved vendors (AVL). The approved manufacturers are defined by engineering, based on part specifications. Approved vendors are defined by manufacturing combined with purchasing based on the approved manufacturers and logistical or commercial conditions
Are EBOM items and MBOM items different?
There is a debate if EBOM items should/could appear in an MBOM or that EBOM items are only in the EBOM and connected to resolved items in the MBOM. Based on the previous descriptions of the various EBOM items, you can conclude that a resolved MBOM does not contain EBOM items anymore in case of multiple sourcing. Only when you have a single manufacturer for an EBOM item, the EBOM item could appear in the MBOM. Perhaps this is current in your company, but will this stay the same in the future?
It is up to your business process and type of product which direction you choose. Coming back to one-off products, here is does not make sense to have multiple manufacturers. In that case, you will see that the EBOM item behaves at the same time as an MBOM item.
What about part numbering?
Luckily I reached the 1000 words so let´s be short on this debate. In case you want an automated flow of information between PLM and ERP, it is important that shared data is connected through a unique identifier.
Automation does no need intelligent numbering. Therefore giving parts in the PLM system and the ERP system a unique, meaningless number you ensure guaranteed digital connectivity.
If you want to have additional attributes on the PLM or ERP side that describe the part with a number relevant for human identification on the engineering side or later at the manufacturing side (labeling), this all can be solved.
An interesting result of this approach is that a revision of a part is no longer visible on the ERP side (unless you insist). Each version of the MBOM parts is pointing to a unique version of an MBOM part in ERP, providing an error free sharing of data.
Life can be simple if you generalize and if there was no past, no legacy and no ownership of data thinking. The transition of EBOM to MBOM is the crucial point where the real PLM vision is applied. If there is no data sharing on MBOM level, there are two silos, the characteristic of the old linear past.
(See also: From a linear world to a circular and fast)
What do you think? Is more complexity needed?
I will be soon discussing these topics at the PDT2015 in Stockholm on October 13-14. Will you be there ?
And for Dutch/Belgium readers – October 8th in Bunnik:
Op 8 oktober ben ik op het BIM Open 2015 Congres in Bunnik waar ik de overeenkomsten tussen PLM en BIM zal bespreken en wat de constructie industrie kan leren van PLM
I am just back from an exciting PLM Innovation 2012 conference. With a full program and around 250 participants, it was two intensive days of PLM interaction.
What I liked the most is that the majority of the audience was focusing on PLM business related topics. The mood of PLM has changed.
In this post, I will give an impression of the event, how I experienced it without going into the details of each session.
Several interesting sessions were in parallel so I could not attend them all, but MarketKey, the organizer of the conference confirmed that all presentations are filmed and will become available on-line for participants. So more excitement to come.
First my overall impression: Compared to last year’s conference there was more a focus on the PLM business issues and less on PLM IT or architecture issues (or was it my perception ?)
Gerard Litjens (CIMdata Director European Operations) opened the conference as CIMdata co-hosted the conference. In his overview he started with CIMdata’s PLM definition – PLM is a strategic business approach. (Everyone has his own definition as Oleg noticed too). Next he presented what CIMdata sees as the hottest topics. No surprises here: Extension from PLM to new industries, extending PDM towards PLM, Integration of Social Media, Cloud, Open Source, Enterprise integration and compliance.
Next speaker was Thomas Schmidt (Vice President, Head of Operational Excellence and IS – ABB’s Power Products Division) was challenging the audience with his key note speech: PLM: Necessary but not sufficient. With this title it seemed that the force was against him (thanks Oleg for sharing).
Thomas explained that the challenge of ABB is being a global company and at the same time acting as a ‘local’ company everywhere around the world. In this perspective he placed PLM as part of a bigger framework to support operational excellence and presented some major benefits from a platform approach. I believe the Q&A session was an excellent part to connect Thomas’s initial statements to the PLM focused audience.
Marc Halpern from Gartner gave his vision on PLM. Also Marc started with the Gartner definition of PLM, where they characterized PLM as a discipline. Gartner identified the following 5 major trends: Software everywhere in products, usage of social media for product development and innovation, using analytics tools to support the whole product lifecycle – after sales, service, connecting to the customer. Opportunities for existing products to deliver them through services (media content, transportation)
Next I attended the Autodesk session, a PLM journey using the cloud, where I was eager to learn their approach towards PLM. Autodesk (Mike Lieberman) let Linda Maepa, COO from Electron Vault in the USA explain the benefits of the Autodesk PLM 360 solution. Electron Vault, a young, high-tech company, has implemented the solution within 2 weeks. And here I got disconnected . Also when the suggestion was raised that you do not need time to specify the requirements for the system (old-fashioned stuff),
I suddenly got into a trance and saw a TV advert from a new washing power, with numerous features (program management, new product introduction, …..) that was washing whiter than all the others and a happy woman telling it to the world. I believe if Autodesk wants to be considered as serious in the PLM world it should also work with existing customers and managing the change in these organizations. Usually it takes already more than two weeks to get them aligned and agree on the requirements. Unfortunate I did not have time during the breaks to meet Autodesk at their booth as I would love to continue the discussion about reality as my experience and focus is on mid-market companies. Waiting for a next opportunity.
After Autodesk, I presented in my session what are the main drivers for making the case for PLM. I also started with my favorite PLM definition (a collection of best practices – 2PLM) and explained that PLM starts with the management vision and targets for the future. Is it about efficiency, quality, time to market, knowledge capture or a more challenging task: creating the platform for innovation?
Next I followed the Energy tracks, where I listened to Charles Gagnon from Hydro Quebec, who gave an interesting lecture called: Implementing Open Innovation and Co-Development.
At first glance this is a sensitive topic. When you innovate it is all about creating new intellectual property, and the fear that when working with partners the IP might be out of the company, Charles explained how this process of collaborative innovation was started and monitored. At the end he reported they measured a significant gain in R&D value perceived when working with external partners. And they did not use a PLM system to manage Innovation (to be investigated how they could survive)
After the lunch I continued with Jonas Hagner from WinWinD, a young manufacturer of windmills that are targeted to operate in extreme climate conditions ( a niche market). They are both implementing PLM and ERP in parallel and they did not have to suffer from years of ERP before PLM and therefore could have a more balanced discussion around part information availability / part number and more. Still I believe they have the challenge to connect in an efficient manner the services of the windmills back to their R&D organization, to do a full PLM circle.
Karer consulting together with Siemens Energy presented the case how they have designed and starting the implement the interface between their PLM system (Teamcenter) and ERP system (SAP). What was disappointing to see was that the interface between Teamcenter and SAP was relative complex (bi-directional with engineering activities in both sides) . Almost 1½ years of development of this interface and one of the main reasons, because SAP was first and they start the engineering order in SAP.
Apparently 2 years later Siemens Energy could not implement a clear distinct separation between PLM and ERP anymore and will not have to live with this complex interface. In the past I have written several times about this complexity that companies seem to accept due to political or historical reasons. Sad story for PLM – Where is the MBOM ?.
The day finished with a closing keynote from Peter Bilello, explaining how a successful PLM implementation could look like. Many wise statements that everyone should follow in case you want to come to a successful implementation (and define correctly what success is)
Thanks to Autodesk we had a nice evening reception, discussion and evaluating with peers the first day.
Day 2 started for me with an interesting lecture from Peter Fassbender, Head Design Center Fiat Latin America, describing how in Brazil the Fiat Mio experiment used modern social media techniques, like crowdsourcing, communities and user involvement to guide the innovation and development of a potential car. A unique experiment demonstrating that this type of projects are influence the brand reputation positively (if managed correct) and for me an example of what PLM could bring if R&D is connected to the outside world.
Christian Verstraete Chief Technologist – Cloud Strategy from HP gave an inspiring session about the open frontiers of innovation. The speed of business in the past 30 years has increased dramatically (you need to be from an older generation to be aware of this – the definition of response time has changed due to new technologies) Christian pushed everyone to think Out of the Box and to be innovative, which made me wonder how long will companies in the future build standard boring products. Will keep on innovating in this amazing pace as we did in the past 30 years ?
Graeme Hackland, IT/IS director from the UK based Lotus F1 team presented the challenges a F1 team has to face every year due to changing regulations. I visited Lotus F1 last year and was impressed by the fact that over 500 engineers are all working around one carper year to optimize the car mainly for aerodynamics, but next to assure it performs during the years. Thousands of short interactions, changes to be implemented a.s.a.p. challenge the organization to collaborate in an optimum manner. And of course this is where PLM contributes. All the F1 fans could continue to dream and listen to Graeme’s stories but Jeremie Labbe from Processia brought us back to earth by explaining how Processia assisted Lotus F1 in a PLM value assessment as a next step.
Meanwhile I had some side discussions on various PLM topics and went back to the sessions, seeing how David Sherburne, Director of Global R&D Effectiveness from Carestream Health presented his case (open source PLM) and his analysis why an open source PLM model (based on Aras) is very appealing in their case. Indeed the business value perceived and significant lower operational costs for the software are appealing for his organization and for sure will influence the other PLM vendors in their pricing model.
Pierfrancesco Manenti, from IDC Manufacturing Insights gave a clear presentation indicating the future directions for PLM: managing operational complexity, not product complexity. As you could expect from IDC Manufacturing Insights all was well based on surveys in the manufacturing industry and clearly indicating that there is still a lot to do for companies to efficient share and work around a common product development and operational platform. New technologies (the four IT forces: mobility, cloud, social business and big data analytics) will help them to improve.
The closing keynote came from Jason Spyromilio , who was director of the European Southern Observatory’s Very Large Telescope (http://www.eso.org) and he gave us the insights in designing (and building) the biggest eye on the sky. Precision challenges for such a huge telescope mirror, being built in the high mountains of Chili in an earthquake sensitive area demonstrate that all participants are required to contribute their IQ in order to realize such a challenge.
Conclusion: This PLM Innovation 2012 event doubled the 2011 event from a year ago in all dimensions. Thanks to the sponsors, the organization and high quality lectures, I expect next year we could double again – in participants, in content and innovation. It shows PLM is alive. But comming back to the title of this post: I saw some interesting innovation concepts – now how to enabale them with PLM ?
Note: looking at the pictures in this postyou will notice PLM is everywhere. I published this post on February 29th – a unique day which happens only every 4 years. In May this year my blog will be 4 years old.
Last week I started my final preparation for the PLM Innovation Congress 2012 on February 22nd and 23rd in Munich, where I will speak about Making the Case for PLM. Looking forward for two intensive days of knowledge sharing and discussion
The question came to my mind that when you make the case for PLM, you also must be clear about what you mean by PLM. And here I started to struggle a little. I have my perception of PLM, but I am also aware everyone has a different perception about the meaning of PLM.
I wrote about it last year, triggered by a question in the CMPIC group (configuration management) on LinkedIn. The question was Aren’t CM and PLM the same thing ? There was a firm belief from some of the members that PLM was the IT-platform to implement CM.
A few days ago Inge Craninckx posted a question in the PDM PLM CAD network group about the definition of PLM based on a statement from the PLMIG. In short:
“PDM is the IT platform for PLM.”Or, expressed from the opposite viewpoint: “PLM is the business context in which PDM is implemented
The response from Rick Franzosa caught my attention and I extracted the following text:
The reality is that most PLM systems are doing PDM, managing product data via BOM management, vaulting and workflow. In that regard, PDM [read BOM management, vaulting and workflow], IS the IT platform for the, in some ways, unfulfilled promise of PLM.
I fully agree with Rick’s statement and coming back to my introduction about making the case for PLM, we need to differentiate how we implement PLM. Also we have to take into our minds that no vendor, so also not a PLM vendor, will undersell their product. They are all promising J
Two different types of PLM implementation
Originally PLM has started in 1999 by extending the reach of Product Data outside the engineering department. However besides just adding extra functionality to extend the coverage of the lifecycle, PLM also created the opportunity to do things different. And here I believe you can follow two different definitions and directions for PLM.
Let’s start with the non-disruptive approach, which I call the extended PDM approach
When I worked 6 years ago with SmarTeam on the Express approach, the target was to provide an OOTB (Out of the Box) generic scenario for mid-market companies. Main messages were around quick implementation and extending the CAD data management with BOM and Workflow. Several vendors at that time have promoted their quick start packages for the mid-market, all avoiding one word: change.
I was a great believer of this approach, but the first benchmark project that I governed demonstrated that if you want to do it right, you need to change the way people work, and this takes time (It took 2+ years). For the details: See A PLM success story with ROI from 2009
Cloud based solutions have become now the packaging for this OOTB approach enriched, with the ease of deployment – no IT investment needed (and everyone avoids the word change again).
If you do not want to change too much in your company, the easiest way to make PDM available for the enterprise is to extend this environment with an enterprise PLM layer for BOM management, manufacturing definition, program management, compliancy and more.
Ten years ago, big global enterprises started to implement this approach, using local PDM systems for mainly engineering data management and a PLM system for the enterprise. See picture below:
This approach is now adapted by the Autodesk PLM solution and also ARAS is marketing themselves in the same direction. You have a CAD data management environment and without changing much on that area, you connect the other disciplines and lifecycle stages of the product lifecycle by implementing an additional enterprise layer.
The advantage from this approach is you get a shared and connected data repository of your product data and you are able to extend this with common best practices, BOM management (all the variants EBOM/MBOM/SBOM, …) but also connect the market opportunities and the customer (Portfolio management, Systems engineering)
The big three, Dassault Systemes, Siemens PLM and PTC, provide the above functionality as a complete set of functionalities – either as a single platform or as a portfolio of products (check the difference between marketing and reality).
Oracle and SAP also fight for the enterprise layer from the ERP side, by providing their enterprise PLM functionality as an extension of their ERP functionality. Also here in two different ways: as a single platform or as a portfolio of products. As their nature is on efficient execution, I would position these vendors as the one that drive for efficiency in a company, assuming all activities somehow can be scheduled and predicted
My statement is that extended PDM leads to more efficiency, more quality (as you standardize on your processes) and for many companies this approach is a relative easy way to get into PLM (extended PDM). If your company exists because of bringing new products quickly to the market, I would start from the PDM/PLM side with my implementation.
The other PLM – innovative PLM
Most PLM vendors associate the word PLM in their marketing language with Innovation. In the previous paragraph I avoided on purpose the word Innovation. How do PLM vendors believe they contribute to Innovation?
This is something you do not hear so much about. Yes, in marketing terms it works, but in reality? Only few companies have implemented PLM in a different way, most of the time because they do not carry years of history, numbering systems, standard procedures to consider or to change. They can implement PLM in a different way, as they are open to change.
If you want to be innovative, you need to implement PLM in a more disruptive manner, as you need to change the way your organization is triggered – see the diagram below:
The whole organization works around the market, the customer. Understanding the customer and the market needs at every moment in the organization is key for making a change. For me, an indicator of innovative PLM is the way concept development is connected with the after sales market and the customers. Is there a structured, powerful connection in your company between these people? If not, you do the extended PLM, not the innovative PLM.
Innovative PLM requires a change in business as I described in my series around PLM 2.0. Personally I am a big believer that this type of PLM is the lifesaver for companies, but I also realize it is the hardest to implement as you need people that have the vision and power to change the company. And as I described in my PLM 2.0 series, the longer the company exist, the harder to make a fundamental change.
There are two main directions possible for PLM. The first and oldest approach, which is an extension of PDM and the second approach which is a new customer centric approach, driving innovation. Your choice to make the case for one or the other, based on your business strategy.
Looking forward to an interesting discussion and see you in Munich where I will make the case
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:
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 ….
Last week was a week of transition. As I wrote in my previous post, I finalized a traditional PLM 1.0 project ( I will come back on this term ‘traditional’ PLM 1.0) and now probably because of the sunny days and some interesting articles I read (each word goes to a different article), I am reflecting what it means to think about the new trends: WEB 2.0 or even PLM 2.0
In this post I will try to explain the developments I have seen so far in the mid-market and from there project what might happen.
In the 80’s there was no PDM or PLM in the mid-market. This was the time most companies were moving away from the drawing board towards CAD. Most of the CAD was 2D and at that time in the mid-market AutoCAD was the dominant CAD software.
At that time I was working for the biggest AutoCAD distributor in the Netherlands (picture on the left). This was the golden age for hardware and software resellers – margins were high and there was little or none IT-knowledge inside mid-market companies. In order to keep the high margin we provided a free helpdesk for our customers to differentiate from others. It was an interesting time. Prospects came to our demo room to plot a drawing of A0 format and to discuss the quality of the lines and the hatching as compared to handmade drawings. There was always the discussion if CAD was more productive and must of us agreed that benefits only came when rework or changes were needed. In parallel we offered a training course for the heads of a design department how they learned to understand if their designers were productive. They were used to observe the behavior of the draftsman and the minor bar on the drawing board and from there they understood if someone was productive. We were talking about the new digital generation that would replace the people at the drawing board.
Are there still drawing boards ? Is there still free support as the margins are high ? This was 20 years ago.
Then slowly 3D CAD was introduced for the mid-market, initially only on Unix boxes, but with the introduction of Microsoft Windows it became achievable – SolidWorks for sure was leading in this area. Hardware became already more a commodity so the customer relation changed from free support to paid support, which required quality and knowledge. At that time in my company, we also saw the first demands for what customers called an “engineering database”. In the 2D world it was all about drawing management, now with 3D the focus was on managing the whole product. Initially called EDM (Engineering Data Management), later evolving in Product Data Management. The term PDM was not known at that time and I remember one of our customers visiting us with a sample of 13 reports – drawing list, spare part list, manufacturing BOM, etc. He told us: “I need a system that can generate these reports for me at anytime”. The solution: we implemented a PDM system for this customer. At the end of the nineties 3D was introduced in the mid-market combined with PDM. We were talking about the new generation of people that thinks in 3D which would replace the people who still worked in 2D
Are we still working with 2D ? Do we still look for support on hard- and software ? This was 10 years ago.
Then came the era of connectivity, initially through the first internet wave, leading to terms as cPDM and ultimately PLM. Instead of focusing on productivity in a single department, the intention was to focus on collaboration between departments, development teams and to address the whole product lifecycle. Specially Dassault Systems extended this concept by focusing on the process and virtualization: test and build your product virtually before you spend any money on prototypes. Autodesk does the same in different words, they call it Digital Prototyping and they try to avoid talking about the processes as here we touch the most sensitive point in mid-market companies: touching or changing processes – ‘classical PLM 1.0. And this is also what I read between the lines of Jim Brown’s post Is innovation or product pipeline killing profitability ? As long as we do not change our product development process but focus still on doing the same with better tools, the real innovation will not come. We are now talking about the global collaboration generation that has to learn to work together and replaces the people who are not changing their processes.
Are we still solving our departmental problems only ? Can we survive keep on doing the same ? This is now !
And meanwhile mid-market companies are learning to understand and digest the above, we already see the new wave coming. WEB 2.0 – social networking – social collaboration – PLM 2.0 – communities and more. Instead of companies working on their own data, the future is to work in communities, live data, cross-company with employees, who are focused as a team to bring a result, we do not send so much emails anymore, we chat, we twitter, we …….. and more. In addition as we will see the trend that teams have members from all around the world, the question comes up: What is the standard communication language ? German (past) , English (present), Chinese (future) ? Here I am a big fan and believer of the Dassault vision that 3D becomes the global language for communication as the people participating do not come from the same educational background anymore – so it easier to see what you mean. Meanwhile the futurists are all the time talking about the aging workforce (a lot of people plan to retire), but if you read back, you will notice every ten years we are talking about an aging workforce. Every time there was a new generation picking up the new capabilities and challenging the next generation.
Are we in 2020 a global, 3D twittering world ? What is each individual’s added value ? What are companies doing to anticipate to the above trends ? It looks like it is going to happen and the current economical downturn allows us to anticipate even earlier till the next pit stop.
A thought I take with me on the summer holidays.
(Yes, in Europe we still have holidays that are so long you have time to think about work –
you can find me on the island below in August)
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.”
“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:
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.
|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.|
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