BOM: Manufacturing and Engineering

October 22, 2009

I’d like to continue discussion about Bill of Materials. I learned a lot from previous posts. Thank you all for excellent comments!

For those, who just joining us, these are links on previous posts:
BOM: Overstructured, Understructured or Lean
Seven Rules Towards Single Bill of Material

Picture 10
So, today, I want to focus on potential differences between Engineering and Manufacturing bills and put some ideas how, I think, these bills can be managed as a single, or more synchronized one bill. A very logical situation I had chance to see in many companies – both engineering and manufacturing have their own BOM. If you will request part list from both BOMs for the same part number, two different BOMs will appear. And these two bills supposed to be in sync…. However, they don’t. In my view, the fact, these bills are not synchronized can bring a very significant damage to the company nowadays. Increased regulation requirements, IT resource optimization – this is the only initial list of the reasons why we can prefer to make some optimization around both engineering and manufacturing BOMs.

I will try to figure out why engineers and manufacturers prefer to have their own bills. Engineers don’t understand the manufacturing’s need for more or less levels in BOM. Most of engineers prefer to have fewer levels in the bill, so it will simplify the process of changes. From their standpoint, it will make the process of changes straightforward. Another situation when engineers, indeed, create additional levels of sub-assemblies. However, in real life these sub-assemblies are consumed on the shop-floor almost immediately and manufacturing doesn’t see any need to assign Part Numbers to these sub-assemblies (lean practices). There is also a situation when manufacturing leads to a false conclusion about two BOMs need. One of the examples is when the assembly requires many parts,  but manufacturing is not using them all in once, or they are used in different assembly areas. Even more complicated situations may happen in case you are manufacturing configurable product with multiple options. Set of engineering documents and engineering parts can be significantly different from manufacturing bill you’ll have for a particular order. To manage synchronization between these bills can be a huge task, and it will result in high complexity of software (or procedures) used to make this synchronization happen.

The solution for this problem, I want to discuss is to maintain single bill of material with the sufficient level of granular (or I can call it modular) definitions of parts. The granularity needs to be on the level to satisfy both engineering and manufacturing. Engineers need to have the ability to manage parent/component information. At the same time, manufacturing can maintain the operation information and lead time offset data. In the case of manufacturing to order, a unique bill of material will be generated from a modular set of components.

Advantages of this approach will be eliminating costly synchronization between engineering and manufacturing BOMs. The visible disadvantages of such approach is how to implement it using today’s software. I’m not familiar with applications that can provide the level of flexibility to manage bill of material. I assume some service implementation or customization can be done, and maybe you can share your experience about that.

Just my thought.
Best, Oleg

6 Comments | Daily PLM Think Tank, PLM and organization, PLM+ERP | Tagged: , , | Permalink
Posted by olegshilovitsky

BOM: Overstructured, Understructured or Lean?

October 20, 2009

I’d like to continue discussion I started in my earlier post – Seven Rules Towards Single Bill of Materials. So, what are possible collisions on the way to the single bill of materials?. So, let’s take design, engineering and manufacturing bills. When I look on opposite sides – design and manufacturing, the purpose, and as a result, how these bills look like. Design bill started from CAD and, obviously, take as a starting point, design structure. So, we can get very structured bill of material. As opposite, manufacturing bill of material foundation is manufacturing process. The levels of manufacturing bill are driven by manufacturing process definitions, stocking and other elements of manufacturing process. What is the role of engineering bill? Do we need it?

If I’m looking from the perspective of needs, it looks like engineering bill is not needed (wait for a moment, don’t kill me now :)). Design Bill provides information about how my product structured. Manufacturing Bill provides information how my product will be assembled (or build). However, I found distance between these structures / views is a huge, connection between them is not obvious. This is, in my view, place where product lifecycle technologies need to be focused – to step beyond pure design or manufacturing structures to engineering level and build lean engineering bill of material that will become master BOM in the organization.

What are the advantages of such approach? Master Engineering Bill will be able to connect design elements, especially those that related to custom manufacturing and will provide set of configurable modules. Master Engineering bill will support different techniques to create a condition-based structures and many others. From Manufacturing side, engineering bill will get required information about Item Masters.  Different elements – design and manufacturing, will be interconnected in this engineering bill, so no more missing parts or impossible product options.

What are the disadvantages of such approach? I see two major problems – need to build unified data structure and synchronization work between department and people. The multiple bill of material approach solves problems of people collaboration and communication. Each department has their own bill, they are working on. The problem is in the end – missing parts on the shop-floor, missed dates or high product cost. In order to support, single Engineering Master Bill of Material, we need to find right technologies that allow to people to work simultaneously on different pieces of this bill, synchronize, change, update. This collective bill of material should be supported by PLM technologies looking on how to collaborate between design and manufacturing.

Just my thoughts.
Best, Oleg

26 Comments | Collaboration, Daily PLM Think Tank, PLM and organization, PLM+ERP | Tagged: , , , | Permalink
Posted by olegshilovitsky

Seven Rules Towards Single Bill of Material

October 14, 2009

I’d like to continue discussion around the topic raised yesterday by Jim Brown and this is about “single bill of material”. I was reading Jim’s post and my thoughts was about why managing of single bill of material is questionable? I think the key answer to that is because in a real company we have multiple systems and everybody are touching bill of material. So, since I hardly believe business owners of these systems will agree how to share Bill of Material, we do have a “multiple bill of material” status-quo.


Now, I don’t believe systems like we have in manufacturing companies – all these EDM, PDM, PLM, ERP, CRM, MDM… will be magically agree on how to share bill of material in short term. But at the same time, I think, our industry is spending mega-bucks trying to synchronize all these bill of whatever we have (materials, documents, processes, requirements, configurations etc.). So, since Daily PLM Think Tank is about ideas, I decided to put key seven rules that can bring us to the new status quo of “single bill of material”. May be definition of this bill of material in the beginning will be shared between multiple systems, but even so, it will create movement toward single bill of material.

So, here are my seven rules.

1. Complete Data Representation. Data in Bill of Material starting from Part Number and ending all characteristics need to be complete to satisfy needs on all “company-customers” in every department starting from sales and ending up in manufacturing and services.

2. Unique Part Numbers. We need to establish a central system to maintain by single system. If Part is going to change from Form Fit and Function standpoint, new unique Part Number need to be created.

3. Synchronized Changes. We need to prevent changes that potential can be made on partial data representation. Example could be changes in Design System without appropriated changes in manufacturing and all other systems or data collections.

4. To use Part Numbers only. Bill of Materials need to be made of Part Numbers only. We need to prevent usage of any alternative identification such as – drawing numbers etc.

5. Include all scheduled items. We need to include all items that need to scheduled for manufacturing and shop-flow. Everything that going to production need to be incuded into bill. There is no item that will be excluded for whatever reason (i.e. non completed assemblies and semi-finished items).

6. Less levels will be better. The simple solution is the most complicated one. Today manufacturing is struggling to become lean. I think to manage as less as possible levels in Bill of Material will allow to simplify significantly everything we are doing (including way to synchronize or management bill of material).

7. Complete Approval before change. All requested to change need to be approved by all people that are using Bill of Material before bill is going to change. This is will allows trust between users of the bill of materials.

So, in my view, by following such rules we can get much better quality Bill of Material in organization. This is not requires religious discussions about single vs. multiple bill of materials. In the end, nobody cares in how many databases/files/servers we are going to store this (or these) bill of materials.

As usual, I’m very interesting in your feedback. Especially on such non-technological topic. Please, let me know what do you think?

Best, Oleg

40 Comments | Daily PLM Think Tank, Interoperability, PLM+ERP | Tagged: , , , | Permalink
Posted by olegshilovitsky

Engineering and Manufacturing Data Management back in 1992

October 12, 2009

Reading again some books from 1992. Engineering and Manufacturing Data structures and Engineering Information Management Systems.

eng-manuf-data eng-inf-systems

I’d like to share some mixed feeling. We moved forward in many topics for the last 17 years in CAD/PDM/PLM/…. But some fundamental things remain the same, and we continue to discuss it heavily during implementation with customers.

Multiple Bill of Materials
Relations between Design, Engineering BOM and Routing
Early visibility of design information for manufacturing planning
Maintenance and Repair Bill of Materials
Design to Manufacturing process

So, my conclusion is as following:

1/ We are far from excellence in such implementations.
2/ Reading old books is an interesting exercise allows you to zoom out on what you are doing.

Enjoy Columbus Day holiday!
Best, Oleg

2 Comments | Daily PLM Think Tank, Interoperability, Market and Technology, PLM+ERP | Tagged: , , | Permalink
Posted by olegshilovitsky

PLM Prompt: Integrated PLM and ERP – Killer Ideas or Controlled Innovation?

September 28, 2009

Picture 1Short prompt in the beginning of the week. I was reading post from BSW “Killer Ideas And Controlled Innovation: Why you need to integrate PLM and ERP?”. First of all, an idea of integrating PLM (back 15 years it was PDM) seems old. I remember myself in the early beginning of my data management activities around AutoCAD back in 1993, an idea of communication between design data management system and manufacturing systems was highly important. But, I think, this problem is still not resolved.

So, is it a killer idea? Or may be the successful approach in integrating PLM and ERP can bring real innovative future?

Just my thoughts.

Best, Oleg

4 Comments | Interoperability, PLM Prompt, PLM+ERP | Tagged: , , , | Permalink
Posted by olegshilovitsky

PLM vs. ERP: Demand for Business Process

September 2, 2009

Picture 1I want to start today with twitter quote “PLM vs ERP – ERP a transactional system, not suited to manage development of product, integration of all info such as ingredients”. Well, PLM/PDM vs. ERP discussion is old, and I remember it for the last 10-15 years or even more… However, I’d expect some changes in this non-stop confrontation.

The original capabilities of PLM and ERP came respectfully out of their business roots – CAD Design/Data Management for PLM and manufacturing transaction from MRP/MRPII/ERP. However, both domains had demands to grow and make an expansion in organizations. PLM is looking for attractive domains such as requirements, manufacturing, supply chain. ERP is interested to expand toward product development. Both system domains (PLM and ERP) are looking how to establish connected space for enterprise organization business. So, how to achieve it?

I think, very interesting is that both classes of systems are very in favor of business processes. Even if PLM and ERP have a different notion of business processes, I’d say Business Processes can provide good synergy between both systems. PLM traditionally focused on very high level of people involvement in processes. Human based and hybrid processes is something that PLM requires. On the opposite side, ERP is focusing on automation and streamline of processes in organizations.

I think vendors on both (PLM and ERP) sides need to look very pro-actively how adopt Business Process Management technologies. This will be the key to success in organizations. From a technological standpoint, maturity of standards like BPMN and BPEL can provide a solid technological foundation for this work. But, at the same time, both PLM and ERP need to worry about growing capabilities of dedicated BPM vendors. They can take an attractive $$$ from aged PLM and ERP providers and establish strong BPM leadership in organization. I wrote about this in my previous PLM prompt.

So, what is my conclusion today? Business process have strong demand from both sides- PLM and ERP. The road toward successful BPM implementation can be very bumpy for PLM and ERP. Need to watch it out. Multiple vendors can still business and establish success business in front of enterprise behemoths.

What do you think about it? What are your practices with regards to process management in organization?

Best, Oleg

28 Comments | Business Process Management, Collaboration, Daily PLM Think Tank, PLM+ERP | Tagged: , , | Permalink
Posted by olegshilovitsky

PLM+ERP: How to Prevent a Divorce?

June 1, 2009

I’d like to start new discussion this week with this challenging topic. In my post about “Top Five Disappointing PLM Technologies” last week, I mentioned PLM/PDM -ERP integration as #2 and actually got lots of interesting comments on this. And as I mentioned, this topic, in my opinion, has remained the same for at least the last 5-10 years. So, I came to the conclusion that there is something fundamentally wrong and it will be really good to make open up a more detailed discussion on this.

So, I’d like to put the reasons that have brought us to our present situation regarding the PLM/PDM and ERP world into 4 groups:

  1. Bill of Materials Management. The way a Bill of Materials need to be managed in both systems is different. While PDM/PLM is more oriented on “work in progress”, such as the design Bill of Materials and Engineering stuff, ERP is more of an “effectivity-oriented” model. The bridge between these two models is the Part Number, but this is not always simple to coordinate between multiple manufacturing facilities and different Engineering /Design views. So, the fundamental models are different. Therefore, the connection and mutual life of these systems together is very problematic.  
  2. System and Process product supports. PDM/PLM and ERP support a different community of people (and processes) in the organization. Their work goals are unfortunately defined separately, and processes are not always well integrated. When they belong to different organizations, it’s very hard to make them work together since they are disconnected sequentially (input-output) and not designed to work in parallel. This causes major dissatisfaction and loss of interest among people, followed by #4.
  3. Concurrent Management. In many cases, people get the feeling they are working ‘on the same’ topic (BOM, Product, Part etc.). In this concurrent mode, systems (or people working with systems) are trying to establish a way to say their “final word on change”. Although the overall process spans across PLM and ERP, this process requires concurrent work.  In order to work concurrently, the integration between PLM and ERP needs to be robust.  If it is not robust enough, the process is not optimal and becomes a bad and unnatural process.
  4. People’s nature and various organizational issues. As you, probably know, in the end it’s all about people. When we have all the problems I just mentioned in #1-3, it causes people in the organization to resolve problems in the way they think will be appropriate – they do not always take organizational goals into account. They are driven by their position in organizations, organization political influence and various short and long trends. This is normally ends with organizational failure or one system dominance.

So, will the PLM/ERP marriage end in divorce or end-up as a happy partnership? What I see for a long future is happy ERP and PDM/PLM relationship, if they can find a good find way to live together. If this happens, it will provide huge advantages for customers from the standpoint of streamlining organizational processes and the ability to decrease the cost of the products they manufacture. Alternatives are very complicated and in most cases can be separated as 1/competitive dominance – one of the systems will be dominant in organization; 2/an extremely high price will be paid to integrate systems: 3/inefficient organizational processes.

I’m sure there is potential to solve this problem and that the solution can come from the technological side as well from the organizational side. I’d like to hear your voices and it will be great if you will share your experience and opinion on this problem.

10 Comments | Daily PLM Think Tank, PLM and organization, PLM+ERP | Tagged: , , | Permalink
Posted by olegshilovitsky

Next Entries »
Follow

Get every new post delivered to your Inbox.

Join 73 other followers