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

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

This week was again a week with several customer visits and discussions around PLM implementations. As analysts like CIMdata, AMR Research, the Aberdeen group are all claiming that PLM will be the next thing for small and medium manufacturing companies, the discussion around PLM is on-going. Of course PLM vendors are adapting their messaging and sometimes their products towards the SMB.

Some vendors like PTC and UGS try to downscale their existing products mainly by changing the packaging of the product (but it remains a PLM system originally designed for enterprises) others like Dassault Systemes have a special SMB offering with full PLM capabilities, ENOVIA SmarTeam.

But let’s assume we have the ideal PLM solution for an SMB company. This was the startpoint, I had during my meetings this week.  How would you motivate a company to implement PLM, knowing all the constraints of SMB companies. Miki Lumnitz wrote about it in his blog –PLM for SMB who are those companies ?

I noticed one of the main issues for discussion is the handling of the MBOM (Manufacturing BOM). So let’s look at the different view points in a company.

EBOM (Engineering Bill Of Materials)

 “The EBOM reflects the way a product was functionally designed”

When engineers define a product, they design (or reuse) assemblies (modules) and add new parts and assemblies to the design. When working with a 3D CAD system, saving the product results in a document structure which resembles a lot the engineering BOM. Traditionally companies got the impression that by changing this EBOM structure a little, they would have a structure ready for manufacturing, called the MBOM.

MBOM (Manufacturing Bill of Materials)

image “The MBOM reflects the way a product will be manufactured”

The MBOM is a structure derived from the EBOM. Main changes from EBOM to MBOM are:

  • removal of subassemblies that do not exist in the physical world. For example a grouping of two parts which are logically grouped by the designer, but as a group do not make sense for manufacturing (Assembly B). And in addition of non-design items which are needed for manufacturing the product. For example paint or grease. (Item F)

Traditionally – and also in the companies I was visiting – the EBOM is domain for the engineering department and with additional modifications they provide a BOM (is it EBOM or MBOM ?) to the ERP system.  Some companies add non-engineering items to their design – they draw a can of paint in their design to make sure the paint is part of the BOM . Some work with phantom production order to address the usage of subassemblies by engineering.

image

Both EBOM and MBOM definition are preparations before production can start. The EBOM and MBOM contain the product knowledge how to build and how to manufacture a product. For that reason they should be handled in the PLM system. The main reasons for that are:

  • during process engineering there is a need to use, analyze and sometimes adapt engineering data. This can be done in the most efficient way within one system where all product data is available
  • PLM systems, like ENOVIA SmarTeam contain tools to create quickly based on certain rules a MBOM derived from the EBOM and when changes occur even compare both structures again, to adapt to these changes
  • Having a single environment for product definition and manufacturing improves the total product understanding

So where is the MBOM ?

Ask yourself as a company ” where do I handle the MBOM ?”  Some of you might say, we do not have an MBOM as our EBOM with some modifications is already good enough for manufacturing.  Many companies might say, we manage the MBOM in the ERP system as this is (was) the only system we had where we could define such structures. These companies are candidate for improving their Concept to Manufacturing process, as for sure either users or working methods are compromised to work with the MBOM in the ERP system.

image

Some might says: Do we still need ERP systems ?

Yes, as ERP systems are built to schedule and execute the production of well defined products in the most efficient way. ERP systems are needed for the execution, often the core activity for manufacturing systems.

PLM systems are reason that ERP systems can execute, they bring the product definition and information to produce a product. And in case the company designs and manufactures excellent and innovative products the future is bright.

But we should not consider engineering activities in the same way as production activities.

Einstein once said (and he is not an expert anyway):

Innovation is not the product of logical thought, even though the final product is tied to a logical structure

I am curious to learn where your manage your MBOM

%d bloggers like this: