In the world of engineering and manufacturing, managing data efficiently stands as a cornerstone for success. Any engineering or manufacturing team must figure out how to manage data. While CAD files and Excel spreadsheet is a mass usage winner, it often leads to failures, mistakes, burned hours of work and ultimately bad outcome. I can tell you more – even if you decide to use Excel and store files in OneDrive, understanding fundamentals will give you a chance to succeed and not to burn endless amount of hours. Understanding fundamentals will help you to get on the right PLM implementation path.
Without a clear strategy for data management, teams can find themselves in a quagmire, unable to locate or utilize essential information effectively. This challenge persists regardless of whether the data is managed through simple spreadsheets or through the most sophisticated Product Lifecycle Management (PLM) systems.
After working with thousands of engineering teams and manufacturing companies, I think, the process ends up with the following 3 topics. I found companies are discussing them again and again. Missing these three topics and trying to find a shortcut will hurt your results. Here they are:
- Part Numbers
- Data Structures
- Items and BOM organizations
Understanding the three fundamental pillars of PLM—Part Numbers, Data Structures, and Items/Bill of Materials (BOM) Organization—is crucial. This understanding is not just about choosing the right tools; it’s about setting the stage for successful data management implementation. You can choose to use PLM tools or you can keep your fancy spreadsheet – understanding of these basic elements will help you to survive in a complex world of engineering and manufacturing software.
Let’s dig into each of these pillars to uncover their significance and best practices.
Part Numbers
It is always amaze me how companies are missing the topic of data identification, which ultimate leads to discussing Part Numbers. It is like not having a unique way to contact your team members. You don’t do it in a normal life. But calling something “a screw.sldprt” sounds like an absolutely normal thing for many organizations. Later trying to figure out what needs to be ordered to build a product.
In my view, the topic of part numbering systems is ripe with controversy and variety. This is where everyone is trying to save time and add as much as more intelligence as possible. From fully automatic numbering schemes to intelligently coded systems, the approaches vary widely. However, one principle remains undeniable: the necessity of identification. Relying on designers to name files, like “Screw_m2.sldprt,” falls short of a strategy. At the same time, figuring out how to code part numbers to be able to know literally everything about this component from model, color, revision level, manufacturing process type and more is another extreme.
Postponing the alignment of data until later stages is a recipe for inefficiency. Therefore, establishing a part numbering (P/N) strategy upfront is non-negotiable for any team and organization (from design contractor, to hardware startup and large enterprise). Sometimes, it requires a bit more thinking about different Part Number types – OEM, manufacturer, supplier, etc.
From my experience, I can see there are three main options companies can use:
- Highly Structured: This method involves defining codes for types, groups, colors, trims, revisions, etc., creating a detailed and intelligent system. The pros of this option is that you can easy identify everything you need to know just by looking at the number. Also, you’re not dependent on other systems to get this information out (for example, you don’t need to search in PLM system to figure out what is the latest revision or what color/make/buy it represents. The ultimate con of this option is that it involves a lot of business logic in your systems to be coded around this numbers. You’re ultimately going to increase the implementation complexity, which turns back in $$$ you spend to customize PLM and other engineering and manufacturing systems.
- Basic Logic: A simpler approach, such as combining component type with a sequential number, offers a balance between structure and flexibility. In my view, it is a decent compromise that gives you some semantic, but not overloading with the complexity. Most of modern systems will give you this option of defining prefix/suffix system and go with running numbers. I usually recommend it to most of the customers as a compromise and the way to align between team members.
- Fully Automatic: Auto-generated numbers combined with attributes that define everything about the part, relying entirely on system management without manual interference. The best option if you go fully digital. Pared with QR code stored in PLM system, it is an ultimate winner if you think how to make a holistic digital system to manage engineering and manufacturing data. It is easy to migrate, import/export and transfer.
The choice among these options often depends on how important it is for the organization to understand part details outside of any system. The appeal of an intelligent P/N system grows with the desire to discern “What is the part?” without consulting any additional resources.
Data Structures
In engineering and manufacturing, data is inherently structured and interconnected. This starts with basic assembly-component relationships and expands to encompass systems, assemblies, ordering, maintenance parts, and more.
Understanding how to structure this data is critical to ensuring it is accessible and useful to different stakeholders, from engineering to production planning and maintenance. Identifying these data representations is a key step in organizing data and processes effectively. It involves establishing rules for creating structures and for transforming them, such as converting design/engineering data into a format suitable for manufacturing.
A typical way of thinking about structures in engineering and manufaturing is to think about product lifecycle and engineering and manufacturing process. Here are a simple way to identify them as following:
- Engineering
- Production planning
- Manufacturing
- Maintenance
These structures represent the way your organization is thinking about the data in different departments and processes. In fact, this is where digital thread begins. Companies that think how to be digital, defines the way these data structured are going to be intertwined, which leads to right strategies for product data management, choice of PLM software and building PLM solutions. It helps to organize business processes, product development process and supply chain management. These structures are basic elements of product lifecycle. These structures connect computer aided design (CAD) with document management and extracting of product data corresponding to each stage of product lifecycle.
Items and BOM Organization
The Bill of Materials (BOM) is a fundamental element of data organization, encapsulating information about products and processes in a way that is accessible and authoritative. Proper organization of Part Numbers and Data Structures lays the groundwork for effective BOM management, defining what must be included in BOM structures, how they should be managed, and how to make them accessible to the right people at the right time. An essential component of BOM management is change management, which provides a mechanism to track and differentiate item and BOM history and organize controlled changes.
The fundamental decision about managing of item information leads you to a definition of a single source of truth about everything. Connected to a part number, the information about items leads to everything – design information, requirements, functions, manufacturers, suppliers, customers using the product and many other aspects of data It helps to organize data sharing and get up to date information about everything you need. It collect an entire lifecycle of product under the same roof and creates a foundation for digital strategy and digital thread.
Bill of Materials (in my recent publication I like to address it as a product model) is a mechanism to create a detailed description about what is included in the product. It is usually aligned with your organization planning about data structures (eg. EBOM, MBOM, SBOM, etc). Also it provides a foundation for change management processes.
What is my conclusion?
When contemplating the organization of data and the implementation of PLM, it’s imperative to focus on the essentials.
If you’re struggling to decide about how manage data and to find information about products you need to crawl through thousands of Excels (or multiple systems), it means you’re missing something in your engineering and product data management. You need to get basics even if you plan to stick with Excels for the rest of your life. Understanding the basics will help you to move from marketing cliche and vendor presentations to the solid grounds of organizing data and managing processes.
These three topics—Part Numbers, Data Structures, and Items/BOM Organization—are not just important; they are absolutely crucial. Without a solid foundation in these areas, achieving a successful PLM implementation is virtually impossible, regardless of whether the term PLM is explicitly used. These are not just tools or processes but the very pillars upon which successful data management and product lifecycle management are built.
Just my thoughts…
Best, Oleg
Disclaimer: I’m co-founder and CEO of OpenBOM developing a digital-thread platform with cloud-native PDM & PLM capabilities to manage product data lifecycle and connect manufacturers, construction companies, and their supply chain networks. My opinion can be unintentionally biased.
