You are currently browsing the tag archive for the ‘ERP’ tag.

2050This is for the moment the last post about the difference between files and a data-oriented approach. This time I will focus on the need for open exchange standards and the relation to proprietary systems. In my first post, I explained that a data-centric approach can bring many business benefits and is pointing to background information for those who want to learn more in detail. In my second post, I gave the example of dealing with specifications.

It demonstrated that the real value for a data-centric approach comes at the moment there are changes of the information over time. For a specification that is right the first time and never changes there is less value to win with a data-centric approach. Moreover, aren’t we still dreaming that we do everything right the first time.

The specification example was based on dealing with text documents (sometimes called 1D information). The same benefits are valid for diagrams, schematics (2D information) and CAD models (3D information)

1D,2D,3D …..

1DThe challenge for a data-oriented approach is that information needs to be stored in data elements in a database, independent of an individual file format. For text, this might be easy to comprehend. Text elements are relative simple to understand. Still the OpenDocument standard for Office documents is in the background based on a lot of technical know-how and experience to make it widely acceptable. For 2D and 3D information this is less obvious as this is for the domain of the CAD vendors.

CAD vendors have various reasons not to store their information in a neutral format.

  • First of all, and most important for their business, a neutral format would reduce the dependency on their products. Other vendors could work with these formats too, therefore reducing the potential market capture. You could say that in a certain manner the Autodesk 2D format for DXF (and even DWG) have become a neutral format for 2D data as many other vendors have applications that read and write back information in the DXF-data format. So far DXF is stored in a file but you could store DXF data also inside a database and make it available as elements.
  • This brings us to the second reason why using neutral data formats are not that evident for CAD vendors. It reduces their flexibility to change the format and optimize it for maximal performance. Commercially the significant, immediate disadvantage of working in neutral formats is that it has not been designed for particular needs in an individual application and therefore any “intelligent” manipulations on the data are hard to achieve..

3dThe same reasoning can be applied to 3D data, where different neutral formats exist (IGES, STEP, …. ). It is very difficult to identify a common 3D standard without losing many benefits that an individual 3D CAD format brings currently. For example, CATIA is handling 3D CAD data in a complete different way as Creo does, and again handled different compared to NX, SolidWorks, Solid Edge and Inventor. Even some of them might use the same CAD kernel.

However, it is not only about the geometry anymore; the shapes represent virtual objects that have metadata describing the objects. In addition other related information exists, not necessarily coming from the design world, like tasks (planning), parts (physical), suppliers, resources and more

PLM, ERP, systems and single source of truth

This brings us in the world of data management, in my world mainly PLM systems and ERP systems. An ERP system is already a data-centric application, the BOM is already available as metadata as well as all the scheduling and interaction with resources, suppliers and financial transactions. Still ERP systems store a lot of related documents and drawings, containing content that does not match their data model.

PLM systems have gradually becoming more and more data centric as the origin was around engineering data, mostly stored in files. In a data-centric approach, there is the challenge to exchange data between a PLM system and an ERP system. Usually there is a need to share information between two systems, mainly the items. Different definitions of an item on the PLM and ERP side make it hard to exchange information from one system to the other. It is for that reason why there are many discussions around PLM and ERP integration and the BOM.

ebom_mbom_problem

In the modern data-centric approach however we should think less and less in systems and more and more in business processes performed on actual data elements. This requires a company-wide, actually an enterprise-wide or industry-wide data definition of all information that is relevant for the business processes. This leads into Master Data Management, the new required skill for enterprise solution architects

black holeThe data-centric approach creates the impression that you can achieve a single source of the truth as all objects are stored uniquely in a database. SAP solves the problem by stating everything fits in their single database. To my opinion this is more a black hole approach: Everything gets inside, but even light cannot escape. Usability and reuse of information that was stored with the intention not to be found is the big challenge here.

Other PLM and ERP vendors have different approaches. Either they choose for a service bus architecture where applications in the background link and synchronize common data elements from each application. Therefore, there is some redundancy, however everything is connected. More and more PLM vendors focus on building a platform of connected data elements, where on top applications will run, like the 3DExperience platform from Dassault Systèmes.

androidAs users we are more and more used to platforms as Google, Apple provide these platforms already in the cloud for common use on our smartphones. The large amount of apps run on shared data elements (contacts, locations …) and store additional proprietary data.

Platforms, Networks and standards

And here we enter an interesting area of discussion. I think it is a given that a single database concept is a utopia. Therefore, it will be all about how systems and platforms communicate with each other to provide in the end the right information to the user. The systems and platforms need to be data-centric as we learned from the discussion around the document (file centric) or data-centric approach.

In this domain, there are several companies already active for years. Datamation from Dr. Kais Al-Timimi in the UK is such a company. Kais is a veteran in the PLM and data modeling industry, and they provide a platform for data-centric collaboration. This quote from one of his presentations, illustrates we share the same vision:

“……. the root cause of all interoperability and data challenges is the need to transform data between systems using different, and often incompatible, data models.

It is fundamentally different from the current Application Centric Approach, in that data is SHARED, and therefore, ‘NOT OWNED’ by the applications that create it.

This means in a Data Centric Approach data can deliver MORE VALUE, as it is readily sharable and reusable by multiple applications. In addition, it removes the overhead of having to build and maintain non-value-added processes, e.g. to move data between applications.”

Another company in the same domain is Eurostep, who are also focusing on business collaboration between in various industries. Eurostep has been working with various industry standards, like AP203/214, PLCS and AP233. Eurostep has developed their Share-A-space platform to enable a data-centric collaboration.

ISO-BIMThis type of data collaboration is crucial for all industries. Where the aerospace and automotive industry are probably the most mature on this topic, the process industry and construction industry are currently also focusing on discovering data standards and collaboration models (ISO 15926 / BIM). It will be probably the innovators in these industries that clear the path for others. For sure it will not come from the software vendors as I discussed before.

Conclusion

If you reach this line, it means the topic has been interesting in depth for you. In the past three post starting from the future trend, an example and the data modeling background, I have tried to describe what is happening in a simplified manner.

If you really want to dive into the PLM for the future, I recommend you visit the upcoming PDT 2014 conference in Paris on October 14 and 15. Here experts from different industries will present and discuss the future PLM platform and its benefits. I hope to meet you there.

pdteurope

 

Some more to read:

https://us.sogeti.com/wp-content/uploads/2014/04/PLM-Systems-White-Paper.pdf

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.

hbrRecently, 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

image

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.

slideplmThis 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.

imageAt 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:

  1. 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)
  2. 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.”

Quote from PTC’s website

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:

image

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 ?

2050In 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 ?

image

dummies_logo In many PLM communities, you see discussions and statements, that there will be a significant impact on the way we perform product lifecycle management using social media capabilities. In this post I will give my thoughts without going in-depth into certain products. At the bottom of this post you will find some links to posts which contributed to my opinion (the usual suspects).

PLM

Let’s first establish a baseline, why we want  Product Lifecycle Management. In a general  PLM is a vision, to bring products to the market faster, with better quality, being innovative and more customer focused.

plmbookThis vision can be implemented by best practices, like a standardized global staged New Product Introduction process, an enterprise wide Engineering Change Process, integration between different disciplines to work globally on a single repository for product definition and many more depending on your industry..

Two words pop up here: a single repository  for product definition and global. This is where the technology comes in. Due to an improved world-wide (internet / WAN) connectivity,  the capabilities are there to communicate efficient around a single repository for product definition and reliable, around the globe .  The world became a global workplace and we are all connected.  The improved connectivity enables PLM vendors (and others) to promote the “single version of the truth” concept.

Single Version of the truth

The idea behind it is that,  if you store everything in a single database, you will always find the right information. This idea was developed at the time the world was not yet global and people were thinking more local.

swiss Some of the major ERP vendors also push for this concept. If you store all your data in their single platform, you are sure there is no redundancy of data, so you are always confident about the content is the message.  This concept is often embraced by IT-departments, as the message having one single platform or one single system for all enterprise data sound like efficient.  (I call it Swiss Knife thinking – it does everything – but would you use it for professional work ?)

As long as we are talking about explicit data and local activities, this concept seems to prove itself. However, a lot of informal activities exist around the product development process, and these activities are not managed.

In 2009, I participated in a COE Automotive panel, where one of the attendees in the audience stood up accused the PLM vendors of making their life so complex. He said:

“If we have an issue on the shop floor with production, we just gather the right people and solve the issue – no need to fill in screens of data that PLM or ERP systems require. And if there was a customer with a problem, we send a service engineer and the problem is fixed”

Of course if his company was a global company, it would be impossible to gather all around the shop floor, or to visit the customer site and solve it in a reasonable time.

save To avoid missing information,  PLM and ERP systems try to collect as much as possible information in their systems, to have the best possible single version of the truth. Through immersive integrations and clever business logic, the user has to enter the minimum of information only once. However for the user still too much and way to complex they complain (and still not enough information is captured).

My conclusion so far: Single version of the truth is a concept to collect a majority of product related data, however missing all the informal communication, which is exchanged during talking (and later emailing and modern means of communication).

Extending the single version of the truth 

The single version of the truth is an important implementation concept for PLM and it requires already a major challenge for companies. Imagine all information that you produce will be stored in such a manner that everyone authorized can see it and it is stored in such a manner that someone else also can understand the information (and not only you) . This is such an important change process often overlooked by IT-driven PLM implementations.

knowledge

PLM Vendors focus on the tools to provide a platform to capture and share product data all around the product lifecycle. Not easy either as development is often based on generic functionality not optimized for a certain user role.

To understand the context of the shared data, you would like to hear or rewind the discussions people had at that time – as from these discussion a lot of implicit information can be retrieved. But no one wants to enter implicit information in a PLM system.

And then going global

Continuing with product development towards a global operation and addressing the communication around the product development is the next logic step. As it is much more difficult to communicate directly with everyone around the world, it is obvious that here social media come in the picture. 

email_lock Initial people were using email to exchange ideas with other people around the world.  This created new problems – sometimes huge attachments of unmanaged data, sometimes important information in mail boxes of only a few people, relevant for many.  Email is against the concept of a single version of the truth as people were creating there own non-pubic archives of product discussions. Before the WEB 2.0 revolution, PLM vendors provided email integrations or embedded email functionality in their PLM system. Still there a millions of email databases (Lotus Notes / Exchange) with product data, development data and more not visible for many.

The 2.0 change

A trend we see in social media is that your ‘old’ email system becomes more a notification system, that you got a direct message through one of your social platforms (RSS feeds, LinkedIn, Facebook, Blog, etc). Of course, if you are connected to all these platforms on-line all the time, you do not need a notification system anymore and you are connected to whom you want and when you want – a little bit back to the old days. If you enter a social environment, you are a participant of the communication going on – you can look around or participate.

social The benefit from social collaboration is that is does not push you into a structure of managed data. And it provides you with on-line communication with everyone who is in your selected community. The downside with the known social media is that it is not clear and secure, what happens with this information shared in social platforms. Will it be sold to special interest groups ? Can you find it through a search engine ?

For product related social collaboration, we need obviously  more secure communities to collaborate. And as for this collaboration you do not know who is in your trusted company network,  it is clear that cloud based solutions come in as a logical technical infrastructure. Of course these communities must be as easy accessible as popular social media and well integrated in the user’s environment.

 

Global single version of the truth ?

Combining the single version of the truth concept and the loose communication and content of social media brings us to the challenge of current PLM consultants, vendors and implementers.  All the information collected in current social platforms is hard to find or interpret. If you use the embedded search functions in these communities, they are not designed for clever searches – you need to know the context?  And then the question pops up if it is all information that existed ? You do not know as you do not see the full picture.

An old-fashioned managing all this data in our PLM system won’t work either. The capturing and classification and linking of data would be too much overhead for the reluctant user. We do not want to manage and justify each action that we do. (although this were knowledge management concepts in the 90’s)

Extended search

And this is where extended search comes in for PLM. The extended search is the glue between the single version of the truth and all the unmanaged data around the product in communities. Integrating this in a single environment is the challenge for PLM vendors (and less important for ERP vendors).

image Why mainly for PLM vendors  ? The main reason is that  in product development a lot of iterations, knowledge building, searching and capturing of date takes place. The more you know and understand, the better you are capable to make adequate decisions, understanding the right context during your development process. And for that you need the formal and informal information, global available across disciplines, companies and countries.

I see two major requirements for these extended search capabilities. 

  1. First of all the search engine should understand your context and skip irrelevant discussions and posts from your social media. I have seen how this could be done. In 2007,  Yedda,  an Israeli startup bought by AOL, came with an intelligent question and answer engine. The concept behind the engine was that it mapped the context of the question to your profile, to the community you belonged and compared it to other profiles of people in the community.  The more you asked and the more your answered the clearer your context became. In additions your answers were rewarded by others, and the more thumbs up you got, the more value you provided to the community – saving your boss to do appraisals.
  2. Search engines should provide you with a facetted search to drill down on the search results. As you do not know exactly what you are looking for, some keywords should do and then as a next step based on your context and the search context you should be able to drill down to the information you are looking for. This information should now give you a better understanding of the context of your product – if it is versioned ? if it is the latest ? Leave this to PLM.

 

My conclusion:

Classic PLM (single version of the truth) and social media capabilities (easy collaboration in communities)  combined with an extended search engine are the mandatory capabilities for a modern global PLM implementation where both formal and informal data are managed in the context of a product

Links for reference:

Tech-clarity white paper

Social Product Innovation

A hyper social organization for plm dummies

Atos Origin abandoning email

eb 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 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 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.

cad_txt 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.

erp_txt 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).

plm_txt 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:

  1. 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.
  2. 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.

ad 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.

md 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….

CADVARs 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.

varIt 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.

gw 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

observation 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.

planning 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.

erp_bom

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.

pointNot 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.

old_process 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 ….

sleep 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.

idea 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:

BTOprocess

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:

customer_delivery

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

sleep 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)

CBOM

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)

ETO_EBOM

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

observation 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

PxM 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.

sel_a 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.

vision

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.

myplmSo 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

observation 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: “

 

question

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 ?

point 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:

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:stepped

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:coop

  • 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 !

expressConclusion:  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

observation I am writing this post as i come across this question on a regular base,  and as a response on a recent post from Jim Brown. I addressed this topic already in previous posts in the past, for your convenience i have put all relevant links I considered at the bottom of this post.

myplm

I believe the question is hard to answers if asked this way. It all depends on where is your point of gravity. You can divide the PLM providers in different groups.

 

 

  • PLM vendors with a focus pure on PLM – their major business is in providing the majority of the PLM related tasks, independent of a certain CAD or ERP package, but interfaces usually through a generic approach with these applications. Matrix One (now integrated in Dassault’s ENOVIA offering), Aras (Open Source), Arena (On-line) are examples of this type of PLM providers.
  • PLM vendors coming from their CAD environment, initially manage their 3D CAD data and extending these capabilities to other authoring tools. ENOVIA VPLM and SmarTeam (main CAD system managed CATIA) are Dassault’s solutions, Siemens UGS (main CAD system managed NX) and PTC (main CAD system managed Pro/E) are examples of this type of providers
  • ERP vendors who extended their offering with PLM functionality – either by developing PLM functionality themselves (SAP) or by acquisitions of PLM functionality (Oracle / BaaN)
  • and there is still a vendor that does not do PLM, but calls it digital prototyping

PLMmindsharers

As each of these PLM providers has their customers and market share – interesting to read is CIMDATA’s overview of the PLM market. What you see there is that it is hard for the independent PLM vendors to be ranked in the top 5. Also the biggest independent PLM vendor in the past, Matrix One, had a hard time to compete against the CAD or ERP based vendors. Why ??

I believe because the major reason lies in the fact that companies want to keep their IT-infrastructure as simple as possible. Buying a PLM system from the current major CAD vendor or from the current major ERP vendor keeps their situation manageable. Why deal with a third vendor that has to integrate with their CAD and ERP software ?

This would lead to a statement that there are only two type of major PLM providers: CAD based or ERP based. And here I am back to the initial question: Can ERP vendors provide PLM ?

Here I believe there is a major difference in the approach of PLM. Yes, both types of companies can provide PLM functionality but they offer it in a different way. It is like Ferrari and Volkswagen provide cars, but are they addressing the same audience ?

planning Some years ago I had a conversation with a SAP country manager about PLM. It was in the time that SAP did not recognize PLM yet as a business approach required  in addition to ERP.  He told me that SAP was managing all the company’s data and processes and that it was just a matter of time before also companies would recognize that engineers working with their CAD systems are nothing else but resources in the whole process. “Designers believe they are artists and cannot be managed but we will show them we can” . Here you see the focus is not on creating the environment for innovation or new products, but on managing existing processes as efficient in a certain way.
To generalize ERP vendors talk PLM but practice efficiency and neglect the fact that innovation and creativity are not manageable (sorry for the generalization but it make things more clear)

CAD based PLM vendors focus a lot on the product creation process. Supporting companies to design and develop new products, mainly in the virtual world. They do not try to manage the development process like a production process but work with mile stones to assure progress and managing quality and risk (NPI – new product introduction). Only when the product definition is mature and complete it will be handed over to ERP to produce the products where needed. Did you ever wonder why CAD based PLM vendors do not expand into ERP ?

And here lies the the difference I believe. If you choose for a CAD based PLM vendor, your company is focusing on innovation, creating new products, when you choose for an ERP based PLM system you will focus on efficiency and process management. Ask the ERP vendor to which level PLM is integrated in their company – is there a person responsible for PLM in the top management ? Technically you can integrate a full portfolio of products, but understanding and making PLM a part of the strategy is the decisive question for the future.

Conclusion

Yes, ERP vendors can provide PLM functionality and as a company you should decide where is your business focus.
If your focus on efficiency and not on innovation ERP providers can offer a total solution.
If your company focuses on new and better products, I believe that your focus should be on CAD based PLM vendors as they offer the best environment for innovation support and capturing design knowledge.

 

And be critical – as before you know the front falls off

 

PLM and ERP previous posts:

PLM and ERP – the culture change

We already have an ERP system

Follow

Get every new post delivered to your Inbox.

Join 358 other followers