You are currently browsing the category archive for the ‘MBOM’ category.

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 This is the third post on Bill of Material handling for different types of companies, this time the focus on Configure To Order (CTO). In the CTO process, products are assembled and configured based on customer requirements. This means there is no more engineering needed when customer requirements are known. CTO examples are, the ordering process of a car with all its options, or ordering a personal computer over the internet.

So what has Configure To Order to do with PLM as there is no engineering?

The main PLM activity takes places when designing the configurable product. Designing a product that is configurable, requires a complete different approach as compared to Engineering to Order or Build to Order. Although we see a similar Configure to Order activity in the R&D departments of companies that follow the Build to Order process. They are also designing products or modules that can be used as-is in customer specific orders as part of the solution.

dashboard The challenge of CTO is to design products that are modular, and where options and variants are designed on a common platform with common interfaces. If you look to the dashboard of a car you will see placeholders for additional options (in case you have the minimal car version) and also you might see that for example the radio display in a basic car version differs from the complete board computer in the luxury version. The common platform is one dashboard, fitting to numerous options.

An engineering department will not focus on designing and defining each of the possible combinations of options as this would be impossible to manage. What can be managed is the common platform (the baseline) and all different options on top of this baseline.

So what happens with the BOM?

The initial design of configurable products goes through similar steps as the BTO process, which means starting from a conceptual BOM, moving to an Engineering BOM (eBOM) and finally produce a BOM for manufacturing (mBOM). The difference is that in the CTO process the mBOM is not developed for just one product, but contains all definitions for all possible products. In this situation we talk about a generic mBOM.

Only when a customer order exists, the generic mBOM is resolved into a specific mBOM for this customer order, which then can be sent to the ERP system for execution.

filter In a generic BOM the relations are managed by filters. These filters define the effectivity of the link, in simple words if the relation between two parts in the BOM is valid (and shown) or not. There are various ways to define effectivity – with again a differentiation in usage

  • revision based effectivity – which means the relation between two items is valid in case the revisions match
  • date effectivity – which means the relation is valid during a certain time interval

Both methods are used most of the time for non-configurable products. The revision and date effectivity are used to be able to track the product history through time and therefore to have full traceability. But this does not work if you want to configure every time a customer specific order.

In that case we use unit or option based filtering.

  • unit effectivity – which means the relation between two items is valid for a unit (or a range of units) produced. For example a batch of products or a unique product with a serial number
  • option effectivity – which means the relation between two items is valid in case a certain condition is valid. Which condition depends on the configuration rules for this option. Example of options are: color, version, country

It is clear that unit and option based filtering of a BOM can lead to a conceptual complex product definition which goes beyond the BOM for Dummies target.  Below an illustration of the various filter concepts (oops the animated gif does not work – i will investigate):

CTO

The benefit of this filtering approach is that there is a minimum of redundancy of data to manage. This makes it a common practice in the aerospace and automotive industry. An example describing all the complexity can be found for example here, but I am sure on this level there are enough publications and studies available.

And what about the CAD ?

I will write a separate post on this topic, as all the possible interactions and use cases with CAD are a topic on its own. You can imagine, having the 3D virtual world combined with a configurable BOM brings a lot of benefits

What PLM functions are required to support Configure to Order ?

  • Project management – not so much focus here as the delivery project for a customer does not require much customer interaction. Of course, the product development processes requires advanced capabilities which I will address later in a future post.
  • Document management – same approach as for project management. The product related documentation needs to exist and secured. Customer specific documentation can be generated often automatically.
  • 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. Capabilities for BOM generation (eBOM/mBOM), baseline and compare using filtering (unit based / option based) in order to support the definition if the manufactured product
  • 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. And as we want to manage controlled manufacturing definition, the Manufacturer Change Order process and Standard Item Approval process are often implemented

Optional:

  • Requirements Management – specially for complex products, tracking of individual requirements and their implementation, can save time and costs during delivery to understand and handle the complex platform
  • Service Management – as an extension of item management. When a customer specific order has been delivered it might be still interesting for the company that delivered the product to keep traceability of the customer configuration for service options – managing the Service and As-Built BOM
  • Product Configurator – the reason I write it as optional, is because the target is order execution, which is not a PLM role anymore. The ERP system should be able to resolve the full mBOM for an order. The PLM product configuration definition is done through Product and Item management. Depending on the customer environment the role of configurator might be found in PLM in case ERP does not have the adequate tools.

Conclusion:

It is hard to describe the Configure To Order process in the scope of BOM for Dummies. As various detailed concepts exist per industry there is no generic standard. This is often the area where the PLM system, the PLM users and implementers are challenged the most: to make it workable, understandable and maintainable

Next time some industry specific observations for a change

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 The last month I have been working with Aerosud Aviation in South Africa to finalize and conclude on ROI and the lessons learned around their PLM implementation, which started in May 2007.  I was lucky to be involved in the initial scoping of the project in 2007 and assisted the local Value Added Reseller together with the team from  Dassault Systèmes UK team in a step by step project towards PLM.

planningWhen I met the people in Aerosud the first time in 2007, I noticed it was a young company, with open-minded people, everyone trying to improve their daily activities per department. There was the need for PLM as some of their major customers required Aerosud to have a PLM system in place. Also Configuration Management was mentioned many times in the interviews and what I learned that time: Excel was the tool for configuration management.

Based on the initial interviews a plan needed to be developed in which steps to implement PLM.  The following three major points were the guidance for the implementation:

  1. The company was thinking documents and understanding documents especially Excel
  2. The company had no clear understanding of what PLM would mean for them as real awareness was not inside the company. Customers like Boeing and Airbus talked about the importance of PLM, but how this could impact Aerosud as a company was no commonly clear
  3. People in the company had a major focus on their department and there was no availability of a overarching group of people leading the implementation

You could say you will see the above points in many smaller and medium-sized companies. I wrote about it also in one of my previous posts: Where does PLM start beyond document management ?

The project phases

riaan The good news for Aerosud was that their PLM Champion was an expert in CATIA and was familiar with writing macros in Visual Basic plus the fact that everyone in the company was open for using the system as standard as possible – no demands for special behavior of the system:  “because we do this already for 100 years”

The last phrase you hear a lot in ancient Europe

The choice was to start with implementing ENOVIA SmarTeam Design Express and to focus in two phases around design data management (phase 1) and the usage of design data by other users (phase 2)

The plan was that each phase would take maximum 2-3 months and we would give the users the time to digest and change their habits towards the standards in the system. In reality it took almost a year, not due to technical or conceptual issues, but this was the maximum pace we could have with the amount of time and available resources. The good news after these two phases was that the first bullet was much clearer understood – the difference between having a system with a single version of the truth or Excel management.

businesssystem In the summer of 2008 (our summer – as it was winter in South Africa) there was a management workshop in Aerosud and here after three days of discussion the position of PLM became clear. One year ago this would not have been possible, now people had seen ENOVIA SmarTeam and they could imagine what benefits the system could further bring. This addressed the second bullet I mentioned before. Although this workshop was not scheduled upfront, looking back now I see this was a crucial point to get understanding for the next PLM steps.

 

The next PLM steps were extending to a real Item-centric data model, because if you want to do PLM you need to work around Bill of Materials and all related information to the items in the Bill of Material. At the end this gives you configuration management without chasing Excels.

Again the next steps were divided in two phases with again a scope of 2 – 3 months. The implementation would be based on the ENOVIA SmarTeam Engineering Express methodology which came as a logic extension of the current implementation, without having to change the database or existing data model.

In the first phase we had awareness sessions for BOM (discussing EBOM / MBOM / Effectivity, etc) plus in parallel we introduced the item as place holder for the information. Not longer folders or projects as the base.

Introduction of the item was conceptual not a big issue and the major activities in this phase were focused on connection legacy data or current data from projects to the items. Data coming from various sources (directories, legacy databases) plus NC data became connected and visible in the single version of truth.

In the second phase of moving to PLM the focus was on EBOM and MBOM. Initially assuring that from the designer point of view the CATIA design and EBOM were connected as smoothly as possible, trying to avoid a lot of administrative overhead on the designer (sometimes unavoidable – see my previous post: Where is my ROI, Mr. Voskuil)

ebom_mbom

After having implemented a streamlined CATIA – EBOM connection, the focus moved to the MBOM. For me this is the differentiator for companies if they implement PLM or just Product Data Management). Implementing the MBOM requires a culture change and this is the place where the ERP people need to see the benefits instead of the threats . Luckily in Aerosud the manufacturing engineers were working in their Excels initially and not in the ERP system – which happens a lot in older companies.

For that reason the concept of MBOM in PLM was much better understood. Now Aerosud is experiencing these capabilities and once they become obvious for everyone the third bullet will be addressed: people start to work in processes cross-departmental instead of optimizing their department with a specific tool.

phased implementation As this activity will continue, I also conducted with the Aerosud management and PLM implementation team an ROI assessment. Estimates about the experienced and projected benefits were kept low and on the realistic side. The result was that the outcome for the ROI period was approx 27 months, almost the same time as the whole project had as throughput time. This proved again the statement about a phased PLM approach. payback of project comes in parallel with the implementation and will ultimately fund the next steps.

 

 

shout_left End of July I will be holding a webinar with more details about this implementation for the Dassault VAR Community. I will be happy to expand this information for a wider audience afterwards, as I believe the project is representative for many mid-market companies that struggle to find the place where PLM fits ….. and brings ROI

 

Let me know if you are interested in this follow up and I will collect the inputs for a follow up.

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

22112007178In the past year I shared with you my thoughts around PLM. Most of the post were based on discussions with customers, implementers, resellers and peers around the world. I learned a lot and will keep on learning I assume, as PLM has many aspects:

 

– the products, there are many products with the label PLM

– the concept, how do we interpret PLM per industry

– the customers, what do they want to achieve, without buzz-word

– the world, people and economic trends drive us sometime to irrational decisions

In this post I will give an overview from the 2008 posts, categorized by topic. I am looking forward to further suggestions in the comments if you are interested in more depth in certain areas. In parallel I will continue to share my experiences and provide an overview of best-practices and terminology experienced in the PLM space.

PLM concepts

Managing the MBOM is crucial for PLM

Is there a need for classification – and how should it be done ?

Is the PLM concept applicable for mid-market companies too ?

What will happen with PLM – looking towards 2050

 

PLM and ERP

PLM and ERP – the culture change, continued

Connecting PLM and ERP – part 1, part 2, part 3

 

PLM and ROI

Implementing PLM is too costly ?

Implementing PLM takes too long ?

Why implement PLM next to an ERP system ?

How is PLM different from CAD data management ?

Too busy to implement PLM ?

Economical crisis creates the opportunity for change

 

Business Process Change

PLM in SMB requires a change in thinking

The management is responsible to initiate a change towards PLM

The change in automotive/aero supply chains to more advanced partners

How will mid-market companies pick-up the benefits from implementing PLM ?

 

Experiences

European Enovia Customer Conference (ECC)

PLM in Greece – does it exist ?

Is the concept for PLM mature enough ?

Don’t expect a bottom up PLM implementation to become successful

 

Conclusion

I would like to conclude with a quote from my favorite scientist, who taught us everything is relative, however:

“We can’t solve problems by using the same kind of thinking we used when we created them.”

Looking forward to your feedback, wishes in 2009 !

8years

Jos Voskuil

sleepAfter two posts on objections for PLM, I want to come back to the basics around connecting PLM and ERP systems. Most of the people are enjoying their holiday at this moment and for that reason I have the time to complete the PLM and ERP story. I guess, for a company in the mid-market, it is hard to decide which approach to follow.

ERP vendors will claim that by managing items and relations to the design documents, they are able to provide an  environment that supports engineering on top of their system. For mid-market companies this might be the ‘cheapest’ option – buy or get your solution from a single vendor. Especially when the ERP vendor provides the PLM module for free. And this is exactly one of the reasons why it will fail. When no PLM knowledge or best practices are provided to the company, but just a set of function and features, how would these companies know how to implement PLM ?
If you give a module for free it obviously also shows you do not understand the value of it.

My two last posts with the common title 5 reasons not to implement PLM are addressing some of these issues.

But now back to the PLM and ERP connection. In my two previous posts, I described how would be shared between a PLM and an ERP system, combined with issues as: intelligent part-numbers and classification. You will find similar discussions on the manufacturing center.

The connection between PLM and ERP has little value in case only items are exchanged. Of course engineering can have the benefit of early visibility of item logistical data, like costs, stock and status. But the real value comes when engineering, through the PLM environment, feeds the ERP system with the definition of how to manufacture a product. The way to manufacture a product is based on the MBOM (Manufacturing Bill of Materials), combined with operations that need to be performed on the items in the BOM.

In my post Where is the MBOM I already discussed the classical challenge many companies are facing. Historically they enter all the data for manufacturing in their ERP system, as this was the first system driving production. The input for the ERP system came from the engineering department, sometimes provided as Excel sheet or in case of more automation with the CAD environment as an EBOM (Engineering Bill of Material)

As the concept of connection CAD through PLM with ERP might be new for many companies, I will describe below some ‘bad practices’ that I found in past implementations and what we can learn from them.

Bad practice 1: A CAD file equals and Item number

As PLM is often introduced starting from the design department, the initial thought to connect CAD files and Items is based on the simple rule: “Every CAD file represents an item number”. In the ‘good old’ 2D world this might have been true, as in the ERP system, related to each item to be manufactured a drawing existed.

However in the 3D world this approach leads to the following problems:

  • Flexible parts like rubber tubes or belts have a different file representations when used in a different position. This means for one item number several CAD files may exist.
  • Some CAD systems like CATIA, SolidWorks allow the designer to store within one file different configurations of a design, as they share a common design but vary on some specific points. Each variation of course is a different item number. This means for one CAD file several item numbers may exists.

The conclusion from the above exceptions is:

  • Handle CAD files and Item numbers as separate entities in your PLM system
  • A CAD file CAN NOT BE equal to an Item Number

Bad practice 2: The CAD structure can be used as the BOM to be send to ERP

As in many companies the EBOM and the MBOM resemble a lot, the temptation exists to push the engineer instead of defining a design in the concept of the EBOM, to work in a mixed environment.

This approach will lead to the following problems:

  • Drawing of non-design items in the 3D CAD assembly as they are needed to represent an item. For example a paint-can symbol, an oil-can, etc. As these materials are needed for manufacturing, the designer has to add them to the product structure as in this way they will appear in the BOM. This approach leads to a dependency on the CAD assembly that is not needed. Imagine another type of paint is needed – this would require the designer to change the CAD assembly files as they represent the manufacturing structure – or you do not update the CAD assembly files and in that case you have no reliable data anymore.
  • The designer might use in the design subassemblies that group two or more items logically together. For example a bolt, a nut and two rivets. As the subassembly does not exist as an item number in the ERP system, the ERP system treats this assembly as a phantom assembly. No operations needed, but an extra intermediate step is defined in the ERP system, as-if for each usage the bolt, the nut and rivets need to be assembled.

The conclusion from the above points is:

  • Handling the MBOM in the CAD system to send it automatically to ERP leads to complexity either in the design environment or in the ERP system
  • There is no need to have this complexity when the concept of EBOM and MBOM is implemented in PLM
  • Handling EBOM/MBOM transformation in the interface leads to costly complexity, see Where is the MBOM ?

Bad practice 3: The Items in CAD structure are tightly linked to the MBOM

This practice often appears in combination with the two bad practices above. As the company focuses on a resemblance of the CAD structure and the MBOM, people start to imagine also the other way around. They expect the PLM system to keep the CAD structure in-sync with the BOM. In case an item is deleted or replaced in the BOM, the CAD system should be updated automatically..

I guess this is one of the things I learned that is an utopia and probably not needed if a clear understanding of CAD structure, EBOM and MBOM exists. Removing or changing items in a BOM does not give enough information about the impact on the CAD structure. For example if one item appears 3 times in an assembly and one instance is replaced by another item, how would the CAD structure know which item should be replaced ?

The conclusion from the above point is:

  • changes in a product assembly can be initiated from the BOM but should be executed in the CAD system
  • Automatic synchronization of CAD structure based on BOM changes is an utopia

Conclusion

In general my conclusion is (after many years of trying to satisfy customers learning from the above points and more) :

In order to create a smooth connection between PLM and ERP you need:

  • Item creation in PLM – completion in ERP
  • ERP provides feedback on costs and availability
  • In case of production issues an ECR/ECO should be launched – going through PLM to assure engineering impact has been analyzed
  • PLM needs to manage the capture of the CAD structure towards the EBOM
  • EBOM/MBOM transformation needs to be done in PLM
  • The connection between PLM and ERP should go through the MBOM
%d bloggers like this: