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

In my series of blog posts related to the (PLM) data model, I talked about Product, BOMs and Parts. This time I want to focus on the EBOM and (CAD) Documents relation. This topic became relevant with the introduction of 3D CAD.

Before companies were using 3D CAD systems, there was no discussion about EBOM or MBOM (to my knowledge). Engineering was producing drawings for manufacturing and not every company was using the mono-system (for each individual part a specifying drawing). Drawings were mainly made to assist production and making a drawing for an individual part was a waste of engineering time. Parametric drawings were used to specify similar parts. But now we are in the world of 3D!

imageWith the introduction of 3D CAD systems for the mainstream in the nineties (SolidWorks, Solid Edge, Inventor) there came a need for PDM systems managing the individual files from a CAD assembly. The PDM system was necessary to manage all the file versions. Companies that were designing simple products sometimes remained working file-based, introducing the complexity of how to name a file and how to deal with revisions. Ten years ago I was investigating data management for the lower tiers of the automotive supply chain. At that time still 60 % of the suppliers were using CATIA were working file-based. Data management was considered as an extra complexity still file version control was a big pain.

This has changed for several reasons:

  • More and more OEMs were pushing for more quality control of the design data (read PDM)
  • Products became more modular, which means assemblies can be used as subassemblies in other products, pushing the need for where used control
  • Products are becoming more complex and managing only mechanical CAD files is not enough anymore – Electronics & Software – mechatronics – became part of the product

Most PDM systems at that time (I worked with SmarTeam) were saving the 3D CAD structure as a quantity-based document structure, resembling a lot a structure called the EBOM.

CAD DOC structure

 

This is one of the most common mistakes made in PLM implementations.

The CAD structure does not represent the EBOM !!!

Implementers started to build all kind of customizations to create automatically from the CAD structure a Part structure, the EBOM. Usually these customizations ended up as a mission impossible, in particular when customers started to ask for bidirectional synchronization. They expected that when a Part is removed in the EBOM, it would be deleted in the CAD assembly too.

And then there was the issue that companies believed the CAD Part ID should be equal to the Part ID. This might be possible for a particular type of design parts, but does not function anymore with flexible parts, such as a tube or a spring. When this Part is modeled in a different position, it created a different CAD Document, breaking the one-to-one relation.

Finally another common mistake that I have seen in many PDM implementations is the addition of glue, paint and other manufacturing type of parts to the CAD model, to be able to generate a BOM directly from the CAD.

imageFrom the data model perspective it is more important to understand that Parts and CAD documents are different type of objects. In particular if you want to build a PLM implementation where data is shared across all disciplines. For a PDM implementation I care less about the data model as the implementation is often not targeting enterprise continuity of data but only engineering needs.

A CAD Document (Assembly / Part / Drawing / …) behaves like a Document. It can be checked-in and checked out any time a change is made inside the file. A check-in operation would create a new version of the CAD Document (in case you want to trace the history of changes).

Meanwhile the Part specified by the CAD Document does not change in version when the CAD Document is changed. Parts usually do not have versions; they remain in the same revision as long as the specifying CAD Document matures.

Moving from PDM to PLM

For a PLM implementation it is important to think “Part-driven” which means from an initial EBOM, representing the engineering specification of the Product, maturing the EBOM with more and more design specification data. Design specification data can be mechanical assemblies and parts, but also electrical parts. The EBOM from a PCB might come from the Electrical Design Application as in the mechanical model you will not create every component in 3D.

And once the Electrical components are part of the EBOM, also the part definition of embedded software can be added to the BOM. For example if software is needed uploaded in flash memory chips. By adding electrical and software components to the EBOM, the company gets a full overview of the design maturity of ALL disciplines involved.

The diagram below shows how an EBOM and its related Documents could look like:

EBOM.docs

 

This data model contains a lot of details:

  • As discussed in my previous post – for the outside world (the customer) there is a product defined without revision
  • Related to the Product there is an EBOM (Part assembly) simplified as a housing (a mechanical assembly), a connector (a mechanical art) and a PCB (a mechanical representation). All these parts behave like Mechanical Parts; they have a revision and status.
  • The PCB has a second representation based on an electrical schema, which has only (for simplification) two electrical parts, a resistor and a memory chip. As you can see these components are standard purchasable parts, they do not have a revision as they are not designed.
  • The Electrical Part Flash Memory has a relation to a Software Part which is defined by Object Code (a zip-file?) which of course is specified by a software specification (not in the diagram). The software object code has a version, as most of the time software is version managed, as it does not follow the classical rules of mechanical design.

Again I reached my 1000 words, a sign to stop explaining this topic. For sure there are a lot of details to explain to this data model part too.

Most important:

  • A CAD structure is not an EBOM (it can be used to generate a part of the EBOM)
  • CAD documents and EBOM parts have a different behavior. CAD documents have versions, Parts do not have versions (most of the time
  • The EBOM is the place where all disciplines synchronize their data, providing during the development phase a single view of the design status.

Let me know if this was to abstract and feel free to ask questions. Important for this series of blog post is to provide a methodology baseline for a real PLM data model.

I am looking forward to your questions or remarks to spark up the discussion.

observation The past few weeks a had various moments to interrogate myself about the values for PLM and what would be the best way to address PLM for a mid-market company.

First I was in Copenhagen, attending the Microsoft Convergence event. A meeting where Dynamic customers, resellers and partners from all around Europe came together to learn the latest from Microsoft, to network with other partners and discuss their business processes.

Of course the focus from all of the 4000 attendees was around logistical processes, I was very curious to learn how manufacturing companies would describe their needs and where they feel the missing link – PLM.

But they did not feel it ……….

I believe this is one of the most challenging issues for mid-market companies. They have been investing in their ERP system and consider this as the company’s backbone. Their production and finance is dependent on it. Other departments, like sales and engineering provide somehow their inputs to the system, often Excel is here the information carrier. No PLM vision exist – or in case it exists – it is perfectly hidden.

I touched this topic in one of my previous post, called:  “We do not need PLM, we already have ERP”

So why is PLM not yet adopted by mid-market companies and I raise this question mainly for those companies that obvious would benefit from PLM ?

I believe the major reason is the fact that often in mid-market companies there is no high-level strategy available analyzing where the company should be in 5 years from now and what are the challenges to overcome. Most of the companies I am currently working with want to implement something they call PLM, but often it is just PDM.

The big difference between PLM and PDM is that PLM requires the company to work different across departments, where PDM is considered more as an automated way to centralize product data, without changing the department responsibilities.

And now some generalizations

shout_left In addition mid-market CAD resellers try to explain their customers that PLM is only for big enterprises and that they just need PDM. This of course makes their sales beyond CAD easier, as touching cross-departmental processes requires different knowledge (which their resellers do not have), a different product (which they do not sell) and of course a longer sales cycle.

shout_right The same happens from the ERP side. ERP resellers consider what happens in the engineering department as a black box, where product data is generated and at the end a (configurable) Bill Of Materials. ERP vendors do not jump on PLM as extending the process to engineering requires different knowledge (which is not their domain) , a more extended product (which they do not have (yet))

Mid-market companies are of course influenced by these resellers of their core components and as mentioned before do not have the time and budget to take a strategic, holistic view where the company should be in 5 years. Usually their focus is on solving the pains they experience in their organization. For example we have too many databases and spreadsheets per department, let’s put them all in one central place – more an IT focus then a business focus.

So how to get the vision ?

Companies should ask themselves the following questions:

  • what is the success of my company ?
  • will I still be successful in 5 years from now if I keep on doing the same ?
  • how does globalization affect me ? Risks but also challenges.
  • how do I capture the knowledge of my (experienced) workforce before they retire ?

To answer these questions (and the above ones are only the most probing) it requires time and understanding to build a vision. Perhaps the economical downturn creates the opportunity or need to prepare for the future (survival).

And if you are working in a mid-market manufacturing company, chances are big that implementing PLM is a way to guarantee the company’s future and success. This has been proven in big enterprises and mid-market companies are not so different at the end.

Adapting business processes and connecting the whole product lifecycle are key activities. Beyond PDM and ERP it brings portfolio management (which product bring the real revenue) and innovation (New Product Introduction – how do we make sure we introduce a good product in the market).

Conclusion

listen PLM requires a company vision and strategy. Building the vision is something that PLM vendors, business consultants and others can assist you with. Each group has its own pro’s and con’s but at the end it is the vision that is needed before making the change – it requires first of all an investment in brain power – not in products

Interesting to read:

Stay with the business processes or change them ?

The gap between PLM and Mid-market companies

NPI and PLM

Economic Downturn – an option for success ?

observation This week was a week full of discussion with customers and VARs (Value Added Resellers) around PLM, PDM and implementation approaches and I will come back on this topic in an upcoming post. First I want to conclude the sequel on reasons why companies believe they should not implement PLM.

The 5 reasons not to implement PLM I heard the most were:

  1. The costs for a PLM implementation are too high
  2. A PLM implementation takes too long
  3. We already have an ERP system
  4. Isn’t PLM the same as managing CAD files ?
  5. We are so busy, there is no time to have a PLM implementation in our company

And now, we reached #4

4. Isn’t PLM the same as managing CAD files ?

As most of our customers do not have the time to study all the acronyms that exist in our business, it is understandable that it leads to a different interpretation as expected. In non-academic language I will roughly outline the differences.

In the eighties when most of the mid-market companies designed their products in 2D, bigger enterprises were investing in 3D CAD. In parallel these companies were working on concepts to manage all their engineering data in a central place.EDM (Engineering Data Management) was the word in fashion that time. We have to realize that networks were not as affordable as nowadays and that there was no Internet. It was the first concept to centralize and manage engineering data (files – no paper drawings). An EDM system was of course a system purely for the engineering department.

More and more companies started to expand the scope of data managed, it became the central place to store product related information plus being an infrastructure to collaborate on product data. The acronyms PDM (Product Data Management) and cPDM (collaborative Product Data Management) became in fashion in the nineties. A PDM system still focuses on the engineering department but no multi-discipline and if available in dispersed locations.

In 2000 the focus of PDM was again expanded to other departments in the company working on the product in different lifecycle stages. Instead of a static data management environment, it became a target to connect all departments working on the product through its lifecycle. By having all departments connected, the focus could switch to the process. The acronym PLM (Product Lifecycle Management) was introduced and this created a lot more areas of interest:

  • connecting the bidding phase and concept phase with feedback from production and the field.
  • bringing the sourcing of parts and suppliers forward in the product lifecycle
  • testing and planning on a virtual product
  • and more

But what should be clear from the scope of PLM compared to PDM and EDM, that it has become a cross-departmental approach and not only a system to enhance the way engineering departments work.

PLM is a strategic approach to enable innovation, better portfolio management and response to the market. The focus is on changing the traditional way of working into an approach where the process is as lean as possible still providing flexibility to adapt to global changes – changing customer demands, changing business situations.

Overview

EDM Focus mainly on centralizing mechanical design data
in an engineering department – mainly files
PDM Focus mainly on centralizing product related data in an engineering department – files, BOMs, etc
PLM Focus on the product development lifecycle cross departments and locations – files, BOMs, processes, resources.

Conclusion

No, it is not the same, where managing CAD files is mainly an engineering department related activity which can be solved by a product, PLM is a cross organization approach which requires a PLM system as enabler to implement various best practices

This time a short post, I am off to the ECCAP (September 9-10) to meet customers, implementers and peers all around ENOVIA

Adiosu

eccap

%d bloggers like this: