Product Lifecycle Management (PLM): Critical Issues and Challenges in Implementation - Information Technology and Product Development - page 92

5.3.4 The Misunderstanding of Process
Which came first - the product or the bill of materials (BOM)? Sometimes PLM
implementation teams lose sight of the fact that product engineers design and build
new products - not BOM. PLM software focuses heavily on capturing and managing
product data in a BOM product structure. Many product development groups - for
some of the largest, most complex electronic equipment companies - still use simple
solutions such as sharing Excel spreadsheets to collect product definition data. It is
true that the process of experimenting, testing, collecting, verifying, and sharing
product data is well understood by the engineering community. However, a funny
thing happens as soon as the product data is loaded into the PLM application's
structured format of levels, defined families, options, and acceptable values. Once
the data is placed into the PLM application, even the most distinguished engineer
fellow can be found scratching his or her head asking “where is the BOM that I
developed and how can I see it?”
5.3.4.1 The Chicken or the Egg
Many companies look toward PLM application vendors for complete product devel-
opment solutions. Automation is important enough that PLM software selection
criteria will typically include a section on process automation. The confusion with
the application vendors is that although the sales brochures talk about product
development processes, the applications don't automate them. This reality is often
overlooked by product engineering because to them the PLM applications are either
part, configuration, and document repositories (product data management); resource
capability, availability, and assignment planning for projects (resource manage-
ment); or products, project definitions, delivery dates, and revenue projections
(portfolio management) - but they are not processes that build products.
The challenge is that although the applications don't directly automate the devel-
opment process, the capture of the BOM information in the application represents
the end-result of an engineer's product development efforts. Although this is not
by itself a process, the creation of the BOM represents the product definition and
the engineering decisions that were made “along the way.” Implementation teams
often don't recognize that the handful of screens used to collect a certain bit of
data is not the process of product development - that actually happens outside of
the application - but instead are simply the inputs to a sophisticated data reposi-
tory. Typically, the engineer is confused because even though the data collected in
the PLM application, it is the product data that he or she is responsible for deliver-
ing, the representation of the data is different and the process for recording the data
unfamiliar.
5.3.4.2 “Labradoodle” - Neither a Labrador Nor a Poodle!
The BOM implementation and data collection issues are complicated because the
physical definition (structure) of the BOM - as driven by the PLM implementation