Product Structure Matters: Part 2

Enabling tangible business improvements via hierarchical product structure management.

by Jonathan Scott | Published February 1, 2008

With a place to store, create, and manipulate product structure, everyone in your business can understand how responsibilities are divided and can work using the same “plan.”

Last month in DE, I identified product structure as the communication and change hub that businesses need in order to support concurrent engineering across multiple disciplines. I knocked ERP and CAD out as contenders for the title of “keeper of the product structure” and identified PDM as the clear favorite. This month, I’d like to dive into how a good product structure management system (PDM or another system of choice) can enable tangible business improvements.

To recap, an item-centric approach to management of your product data is the key. Each discipline might have its own design tools and resulting document formats with specification documents that are critical to the overall product definition. But equally important is the framework to which those documents are attached and that framework is the hierarchy of items known as the product structure. The framework is fundamental because it is frequently where the design actually begins.

To understand how product structure is the most basic element of product definition, let’s develop a derivative (custom) product together. To start, our sales team has found a fit for one of our existing systems at a new prospect; we just need to “tweak” the design a bit. Our intrepid sales manager has compiled the “tweaked” requirements into a customer specification and forwarded it to a sales engineer. With implicit approval to start the project, the sales engineer initiates a product structure baseline (baseline being a snapshot of the item hierarchy at a particular point in time) that includes a single item: the top-level end item.

To this top-level item, the customer specification is attached, and thus the first level of design requirements is captured (and available for all subsequent team members to reference). The sales engineer then finds the existing product model that most closely resembles the end item and copies the key reusable aspects over as children of this new end item, each bringing with it all of the appropriate links to specifying documents.

Leverage the design
Because our PDM system is linked with ERP, up-to-date cost information is available inside of PDM and the sales engineer is able to run a report indicating the estimated cost of the components in the design at this point. Our PDM system also captures this baseline as an “as-estimated” view of the data so that we can refer back to it at any point and understand the basis for the quote.

We’ll fast forward past receipt of the customer order and into design. We see our lead systems engineer roughing out the product structure using the contents of the as-estimated item hierarchy and her deep product knowledge to restructure and organize the tree for detailed design. The project manager joins in the process and makes assignments to various groups and subcontractors: The base will be designed by the structures group, the housing by a subcontractor, the manipulator by our own manipulators group, and the vision and controls system by our EE group. Without opening the first CAD tool, high-level product structure has been defined and responsibilities have been assigned; key elements of design reuse have been identified. The design groups will be able to leverage the existing product structure, expanding the level of definition by completing more and more aspects of the detailed design.

Now each of the groups gets started in earnest with their work, studying overall arrangement models and the preliminary drawings from their colleagues for setting interface points and design boundaries. The groups use the tool(s) of choice (flavors of MCAD, ECAD, and IDE) to move the design forward. Note that a master MCAD model isn’t necessary because the product structure identifies the overall hierarchy.

Drilling down into the manipulator group, we keep an eye on the team as it progresses with the MCAD design as new parts and subassemblies appear every day. The group was able to find and leverage older 3D models because the existing items reused early in the product structure definition kept their relationships to their corresponding 3D models and 2D drawings. As design progresses, the PDM system’s MCAD integrations and product structure copy-sync tools make it easy for the designers to leverage their MCAD design to continue filling out the details on the hierarchy of items.

Product structure view
While we’ve been carefully watching this design team, our subcontractor has been getting regular updates through their portal into our PDM system, and he’s likewise been uploading his design package once each week. And not to be left out of the early design, purchasing was able to do some lead-time analysis on the as-estimated structure and caught a possible delivery-crippling delay on availability of a key drive system. This put the EE group into overdrive trying to find a suitable alternate for this component, and they just recently specified the replacement system.

Because of the PDM system’s BOM comparison tools, the structures group promptly saw that they were using an out-dated component (the recent replacement of the original drive system). They sprung into action, revising panel layouts and mounting brackets to support the change.

Weeks later, after the design review meeting, the manufacturing group copies the as-designed (EBOM) product structure view to create a separate as-planned (MBOM) product structure view. With structure manipulation tools, they are able to flatten the structure and organize assembly kitting without affecting the initial design content and related documents.

Design process
We could keep following the product structure, but the picture is coming into focus — this hierarchy of items is serving as the backbone of the design process. The product structure is independent of the individual design tools, it organizes the support design documentation (identifying which revision of which specifying document is relevant per item), and it offers all functional groups their own “view” of the data.

Jonathan Scott is a principal consultant for Razorleaf Corporation based in Williamsburg, VA. Send your comments on this article to DE-Editors@deskeng.com.