While computer-aided design (CAD) systems are expert in design and design analysis, and product data management (PDM) systems are excellent at managing all the bits and pieces of geometric definitions and data that go into that design. None of that data helps make the product or, later on, service it. The problem is that PDM has no way of storing in detail the processes involved in making the stuff described in the drawings that PDM does store. That is, PDM was not really designed for manufacturing process management and, thus, it has no way of storing process data or, for that matter, resource data.
Over time, explains Vynce Paradise, Director of Marketing for Digital Manufacturing for EDS (Cypress, CA), PDM developers began thinking product, product, product—to the exclusion of managing data about processes, plant design, and resources, plus the associated relationships and intelligence that goes along with those data.
For example, the product structure to create BOMs in a PDM became the bill of materials. The behavior and semantics of solids models focused solely on product design; process elements were handled elsewhere. PDM core competency, such as vault check-in/check-out, also became product-design focused. The result was ultimately a system that could create the most perfect BOM—which would then be thrown over the wall to a commercial business system, points out Gregory Mekjian, Vice President of SCM and PLM for SAP Americas (Detroit, MI).
That was okay until users began realizing that manufacturing is more than product design. In fact, it's a great big, integrated, collaborative world out there. "That has been the gotcha," says Mekjian. Which has led to PLM—Product Lifecycle Management. For example, in managing numerical control data with part designs, users and PDM vendors often had to jump through hoops; they either created a partition or folder in the database, or they somehow appended the process data to individual product items in the PDM. Some of the semantic relationships, such as process sequencing, didn't quite work right or they were limited.
The Big E
PLM is managing what CIMdata (Ann Arbor, MI) calls the "product definition lifecycle"—from product creation to its obsolescence. PLM, explains Peter Bilello, a CIMdata Senior Consultant (Automotive), manages the "Big E"—not just product engineering, but also manufacturing engineering. This is consistent to Mekjian's PLM definition: a management system that "bridges the gap between engineering, manufacturing, procurement, and the back office financial and human resource systems." Unfortunately, Bilello continues, many organizations don't have the Big E. Their idea of manufacturing engineering is someone on the other side of the wall who will catch product engineering. Plus, there's the other problem of product definition: the whole dynamic nature of product creation, production, logistics, and what CIMdata calls the intellectual assets, which includes the people in finance, human resources, and so on.
To be fair, notes Bilello, users and vendors have had this holistic vision of what data and systems were needed and how, maybe, to put it all together. Unfortunately, the technology did not support that vision. Companies typically started with PDM because they had to; there were simply too many CAD files to deal with.
"I see this as an evolution, not a revolution," says Bilello. "And there's always been an integration issue at the heart of it." Plus, by incorporating creation tools with data management, that line between data creation and data management has become blurred over the last couple of years. This, continues Bilello, has done two things. First, people now recognize that product definition is much broader than once thought. Second, it has shown why PDM and broader-based data management systems are important.
At the heart of a PLM system is a data model that lets product, process, plant, and resource data entities and their inter-relationships be managed. "Overall, the platform provides a managed, web-accessible, collaborative manufacturing environment," says Paradise. PLM capabilities include product and process configuration, change control and effectivity, process creation, workflow, access management, digital mockup and visualization, as well as vaulting, storage, security, and other data administration capabilities. All of these capabilities are integrated.
How would you use it? In talking about his company's PLM product, Mekjian says SAP's integrated Product and Process Engineering (iPPE) capability lets you "document, track, and manage information on your product at each stage in the development process." You first define the functional structures that represent the basic components of your product. Then you add more detail, completing the product documentation by including design drawings, specifications, and part numbers. While the product is still in development, you can use iPPE to define and work separately on products based on partial product definitions. (For example, you can create parts for special orders, perform development studies, and build prototypes.)
Here's the kicker: Mekjian points out, "As you define your product structure and its variants, you can simultaneously begin to model manufacturing processes and factory layouts. This means you can simultaneously construct the details of your product, manufacturing processes, and factory production. For each of these three functions, iPPE lets you define the basic structures first, then refine them later."
You can't do that with off-the-shelf PDM or, for that matter, ERP, which contains both BOMs and routings.
What's more, you can model a vehicle or any configurable product in a logical fashion using English or whatever natural language you wish—without having to wait for a part number or even CAD drawings. Says Mekjian, "I can model my car as a logical construct. All I need to know is that this car will have chassis, wheels, and an axle." Moving downstream, manufacturing engineers don't need to know that parts A, B, and C, and parts X, Y, and Z have to go together in a particular set sequence. All they need to know is that there will be an axle and a wheel will be put on it. The same holds true for factory layout. Production engineers don't need to know material numbers. All they need to know is where this wheel and axle will be put together and how many of these have to be put together in a day. From that, they can work on line balancing.
Heck, they can work on building the entire plant and laying out equipment long before they have the CAD drawings and materials numbers for a new vehicle.
Suppose a car design has been released to manufacturing. Entering a car model into the PLM system will lead to all the manufacturing processes, resources, and plants associated with making that car. Entering a facility number, even a production line ID, will lead to what products are being produced there. Likewise, entering a resource descriptor will show what product and processes are being produced.
Both design and manufacturing engineers can check what processes and tools are assigned to what parts and assemblies, thereby quickly identifying what could be affected and who can resolve any associated issues in the case of the classic—and typical—late design change. "That's a simple example," says Paradise, "but it's the kind of example that costs tens of thousands of dollars to fix if it isn't properly identified beforehand."
In a nutshell, PLM makes possible all those promises about "collaboration," "simultaneous engineering," "silo busting," and "leveraging" information so that the left hand of an enterprise knows what the right hand is doing, and vice versa. PLM, says Paradise, "is extending our ability and the technologies we have in product development, moving them downstream into pre-production planning, right up to the start of production.