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

If your are reading blogs related to PLM, I am sure you have seen a blog post from Stephen Porter (Zero Wait State), for example: The PLM state  the walking dead – PLM projects that never end.

Like Stephen, I am often triggered by an inspiring book, a touching movie or a particular song combined with my PLM-twisted brain I relate the content to PLM (there is no official name for this abnormality yet).

When driving home last week, I was listening to Phil Collins – In the air tonight

As I was just coming back from a discussion around PLM tools, BOMs and possible PLM expansion strategies in a company with customers and resellers, my twisted brain was thinking about two PLM related topics that were in the air tonight (at least for me).

Granularity vs. Integration: Suites vs. Best-in-class PLM

You must have noticed it, and if not, now you are aware:  Jim Brown and Chad Jackson started a PLM duel discussion platform at Engineering.com to bring PLM related topics to the table: TECH4PD.  Watch them argue and I hope with your feedback and the feedback of the PLM community, it will  help us to make up your mind.

The topic they discussed in their first session was about two different approaches you can have for PLM. Either start from a best in class PLM platform or build your PLM support by using dedicated applications and integrate them.

tech4pd

This is to my opinion one of the fundamental PLM topics to discuss.  And if I would have to vote (as  Jim and Chad ask you to do so), I would first vote for Chad (integration of software) and after a second thought, vote for Jim (best in class PLM). So see my problem.

If I relate the discussion to my experiences with  different companies, I realized that probably both answers are correct. In case you are an OEM you likely would benefit from a best in class PLM platform, as PLM systems aim to cover and integrate all data through the product lifecycle in a single system, single data model, etc.. So a good PLM platform would have the lowest cost of ownership in the long term.  OEMs are by definition not the smallest companies and in general have the highest need for global coverage.

But not every company is an OEM. Many mid-market companies are specific suppliers,serving different OEMs and although they also develop products, it is in a different context of market delivery. There is a need to be flexible, as their products used by OEMs might become obsolete in the near term, they need to be more flexible, reactive. and the best in class companies innovate and are proactive. For that reason they do want to invest in a best in class PLM system, which somehow brings some rigidness , but keep on optimizing these areas where improvement is needed in their organization, instead of changing the organization.

I believe this question will remain in the air until we get a clear split between these two types of PLM. There is a trend splitting classic PLM (OEM oriented) and new upcoming PLM solutions. Till that time, we will be confused by the two approaches. It is a typical PLM disease and the reason you do not experience the same discussion for ERP is obvious. ERP is much more a linear process that both for the OEMs and mid-market companies is aiming to manufacture products or goods at a single location. The differentiation is in global manufacturing. Where do you manufacture your products ?  Here the OEMs might have a bigger challenge. Global manufacturing is a PLM challenge too, which is in the air.

Where is the MBOM ?

This is the topic most visited in my blog and I am preparing a session with the MBOM as theme combined with PLM  for the upcoming PLM Innovation US conference end of October in Atlanta. I am not going to disclose all  the content here, but I will give you some thoughts that are in the air.

Companies historically manage their BOM in ERP, but as a result of globalization they now need to manage their manufacturing BOM at different locations. But each location has its own ERP and a local (M)BOM. What to do ?

This is in the air:

intheair
  • How do you keep the relation with the
    original engineering intent, the product information and the various local
    activities ?
  • Is the ERP system still the place to build
    the MBOM ?
  • Do you need an EBOM and MBOM in PLM ?
  • Cannot we have a single BOM ?
  • What about search technology ?
  • …..

I hope you will participate in both discussions that are the air, either by commenting to this blog, through Tech4PD, your blog (Oleg  ? ;-) ) or your participation at PLM Innovation US.

Looking forward to discuss with you about what you believe is in the air tonight.

image

Conclusion (as usual): It is a busy time – we are heading towards the end of the year, which for some reason is a deadline for many companies. So no long thought processes this time, just what is in the air.

blog_start

May 24th, 2008 was the date I posted my first blog post as a Virtual Dutchman aiming to share PLM related topics for the mid-market.

I tried to stay away from technology and function/feature debates and based on my day to day observations, describe the human side of the PLM  – what people do and why . All  from a personal perspective and always open to discuss and learn more.

Looking back and reviewing my 86 posts and 233 comments so far, I would like to share a summary around some of the main topics in my blog.

PLM

PLM_profIn 2008, PLM awareness was much lower – at that time one of the reasons for me to start blogging. There was still a need to explain that PLM was a business strategy needed beside ERP and PDM.

PLM will bring more efficiency, and in better quality, new innovative products to the market due to better collaboration between teams and departments.

At that time the big three, Dassault Systemes, Siemens and PTC  were all offering a very CAD-centric, complex approach for PLM. There was no real mid-market offering, although their marketing organizations tried to sell as-if a mid-marketing offering existed.  Express, Velocity, ProductPoint where are these offerings now ?

Now, In 2012 there is an established PLM awareness as everyone is talking about (their interpretation of) PLM and with Autodesk, a company that knows how to serve the mid-market, also acknowledged there is a need for PLM in their customer base, the term PLM is widespread

The new PLM providers focus on a disconnect between PDM and PLM, as in particular the handling of enterprise data outside the PDM scope is a white space for many mid-market companies that need to operate on a global platform.

PLM & ERP

NoChangeIn the relation between PLM and ERP, I haven’t seen a big change the past four years. The two dominating ERP originated vendors, SAP and Oracle were paying attention to PLM in 2008 in their marketing and portfolio approach.

However their PLM offerings in my perception, haven’t moved much forward. SAP is selling ERP and yes there is a PLM module and Oracle is having PLM systems, but I haven’t seen a real targeted PLM campaign explaining the needs and value of PLM integrated with ERP.

Historically ERP is the main IT-system and gets all the management attention. PLM is more considered something for engineering (and gets less focus and budget). Understanding PLM and how it connects to ERP remains a point of attention and the crucial point of interaction is the manufacturing BOM and the place where it is defined. The two most read posts from my blog are: Where is the MBOM and next Bill of Materials for Dummies – ETO, indicating there is a lot of discussion around this topic.

I am happy to announce here that in October this year during PLM Innovation US, I will present and share my thoughts in more detail with the audience, hoping for good discussions

New trends

There are three new trends that became more clear the past four years.

dummies_logoThe first one to mention is the upcoming of Search Based Applications (SBA). Where PLM systems require structured and controlled data, search based applications assist the user by “discovering” data anywhere in the organization, often in legacy systems or possible in modern communication tools.

I believe companies that develop an integrated concept of PLM and SBA can benefit the most. PLM and ERP vendors should think about combining these two approaches in an integrated offering. I wrote about this combined topic in my post: Social Media and PLM explained for Dummies

cloudThe second trend is the cloud. Where two-three years ago social media combined with PLM was the hype as a must for product innovation and collaboration, currently cloud is in focus.

Mainly driven and coming for the US, where the big marketing engine from Autodesk is making sure it is on the agenda of mid-market companies.

In Europe there is less a hype at this moment, different countries and many languages to support plus discussions around security take the overhand here.

For me a cloud solution for sure is lowering the threshold for mid-market companies to start implementing PLM. However how to make the change in your company ? It is not only an IT-offering. Like a similar discussion around Open Source PLM, there is still a need to provide the knowledge and change push  inside a company to implement PLM correct. Who will provide these skills ?

alm_1The third trend is the applicability of PLM systems outside the classical manufacturing industries.

I have been writing about the usage of PLM systems for Owner/Operators and the civil / construction industry, where the PLM system becomes the place to store all plant related information, connected to assets and with status handling. Currently I am participating in several projects in these new areas and the results are promising

People and Change

frogI believe PLM requires a change in an organization not only from the IT perspective but more important from the way people will work in an organization and the new processes they require.

The change is in sharing information, making it visible and useful for others in order to be more efficient and better informed to make the right decisions much faster.

This is a global trend and you cannot stay away from it. Keeping data locked in your reach might provide job security but in the long term it kills all jobs in the company as competiveness is gone.

The major task here lies with the management that should be able to understand and execute a vision that is beyond their comfort zone. I wrote about this topic in my series around PLM 2.0

Modern companies with a new generation of workers will have less challenges with this change and I will try to support the change with arguments and experiences from the field.

Audience

Since February this year, WordPress provides much more statistics and interesting is the map below indicating in which countries my blog is read. As you can see there are only a few places left on earth where PLM is not studied.  Good news !!

audience

Although most of my observations come from working in Europe, it is the US that provides the most readers (30 %) , followed by India (9 %) and on the third place the UK (6 %).

This might be related to the fact that I write my blog in English  (not in 100 % native English as someone commented once).

It makes me look forward to be in October in Atlanta during the PLM Innovation US conference to meet face to face with many of my blog readers and share experiences.

Conclusion

Reading back my posts since 2008, it demonstrated for me that the world of PLM is not a static environment. It is even that dynamic that some of the posts I wrote in the early days have become obsolete. 

At the end of 2008 I predicted the future of PLM in 2050 – here we are on the right track.

There is still enough blogging to do without falling into repetitions and  I am looking forward to your opinion, feedback and topics to discuss.

 

observationIn the past two weeks I had some interesting observations related to the core of PLM. Reading posts and some in-depth discussions with customers lead to the statements below:

Single version of truth ?

dummies_logo First I am going back to the intent of PLM – companies that implement PLM are not looking for a system where they can store information in a single database. Often the single version of the truth story is translated into technology . To illustrate this statement I was explaining a medical device company some weeks before how in PLM practices the interaction of requirements, integrated with regulatory compliance verification speeds up the product development process as deviations are early discovered during the development stage. The astonishing answer from the customer was; “Yes we already store this information in our well-known ERP system – so no need for PLM to handle this”

For this person the conclusion was that once data is stored in a system, it is managed. However  what the company never tried was to track each requirement individually (and its possible change) during the engineering process and have a direct connection to regulatory demands.

deaf_blindIn that area Excel, people’s knowledge and stored documents were used to collaborate. Off course with the late discovery of errors and several extra iterations due to it. As long as this company does not understand that the PLM system is not yet another tool to store data, but an enabler to work different and more efficient, these tools based statements will not bring them further. But as nobody get fired for selecting a well-known ERP system, but trying to change the way people work is a risk, often the first option is chosen.

And the more conservative the company culture, the more likely this will happen.

Tools do not make a change

global In a last week meeting I met a VP of a business group of a real global company. I am stressing the word real as there are many global companies, that actually have one main location where the IP and influence comes from – as compared to the real global companies where all around the world the knowledge and IP of the company is invented and spread from there. Although the discussion was on the current status and quality of the tools in use, during breaks we concluded that although the discussion is about tools, the hardest part for implementing PLM in their company is to master and motivate the changes in the way of working towards the users.

saveIn several blog posts from Oleg  (and others) I see the hope that new user interfaces, user data handling can provide a break through here. I partly agree here – in the eighties/nineties we had the single window terminal screens, which were easy to understand (no multi-tasking / no multi-windows). Slowly the current workforce got used to windows (still no multi-tasking) and the new generation (generation-Y) is less and less single tasking and has different ways of solving issues. New interfaces can contribute to the acceptation of a tool, but as in the end we are still doing the same – storing data in a central system without changing the way we work – there is nothing improved

MBOM in PLM

Another interesting statement of this VP was also that they are in the process of bringing all engineering data coming from different disciplines in their R&D / PLM environment. Originally it was the ERP system that was used to combine all data coming from different disciplines. However the disadvantage was that this product definition resided partly in an ERP (there is no concept of a single ERP as manufacturing differ so much globally)  and partly in PLM.  Their future plan was therefore to extend the coverage of PLM toward the whole preparation for manufacturing – my favorite topic too: see Where is the MBOM ?

Conclusion so far

In day to day relations customers and PLM vendors, implementers are talking about functions and features to implement and where and how data is stored. The major driver should be the concept of changing the way we work to be more efficient, more clever and with higher quality. This is not reached by storing data, but by having the right data available at the right moment. And this moment changes when implementing PLM

  • PLM Customers: Make sure that change of doing business is the target of your PLM implementation – do not look for tools only – check with your implementer and vendor which experience they have.
  • PLM Implementers: Schedule time and activities during the implementation to understand the business change and the customer to adapt. It is a different type of skill required but as important.
  • PLM Vendors: You have a hard time – as all are talking about the tools, you do not want to talk about the changes PLM implies – a pity but most customers do not want to hear this side during their PLM selection process

 

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

Follow

Get every new post delivered to your Inbox.

Join 330 other followers