If you liked manufacturing resource planning (MRP II) and enterprise resource planning (ERP), you'll love product data management (PDM). "ERP deals with the physical assets, inventory, and shop floor control of a product within an enterprise. PDM deals more with managing the intellectual property managed by ERP," says John F. Howaniec, manager of Metaphase Business, branch manager for Metaphase Technology, Inc. (Madison Heights, MI). Adds Michael Rudy, vice president of Technology for Workgroup Technology Corp. (Lexington, MA), "PDM is a control system for the development process, similar to the way ERP is a control system for the manufacturing process."
Unlike ERP, PDM is firmly entrenched in the world of engineering. It manages engineering and product design data, and the relationships between those data, throughout the product development and production life cycle. These data include specifications and part definitions, CAD drawings and engineering models, engineering analyses, purchase orders and change orders, process plans and routings, project plans, multimedia, and all the other documentation created by engineering and manufacturing.
Managing this data with PDM yields benefits ranging from simply delivering the right information to the right person at the right time, to enabling local and global concurrent engineering practices, to providing core functionality for QS 9000 efforts, to ensuring global competitiveness. "Benefits extend well beyond reducing engineering design time to include manufacturing cost savings, reduced time-to-market, and increased product quality," says Ed Miller, president of CIMdata, Inc. (Ann Arbor, MI), a consulting firm focused on PDM and computer-aided design/manufacturing (CAD/CAM) technology. "For most organizations in highly competitive industries, these benefits are too great for the technology to be overlooked. The question becomes not really if they will implement PDM, but when."
What's in PDM?
PDM is a composite of several functions that go by such names as "engineering data management," "product information management," and "document management." Together, according to CIMdata, "PDM is used to control the product development life cycle within engineering and manufacturing. PDM systems are designed to manage product data and documents produced by a mixture of CAD, CAM, computer-aided engineering (CAE), material requirements planning (MRP), and other engineering and manufacturing control systems. They provide access and security controls, maintain relationships among product data, enforce the rules that describe data flows and processes, and perform notification and messaging functions. PDM systems also maintain product structures, part data relationships, and standard libraries."
Adds Rock Gnatovich, vice president of Marketing for Computervision Corp. (Bedford, MA), "PDM is about electronic product information: Creating, managing, sharing, and reusing product information. It's about managing and leveraging change."
Think of PDM as a work-in-process system for managing data files as they're created and modified by applications. For contrast, consider the Office Suite of applications from Microsoft Corp. Office Suite creates data for you, but it is your job to manage that data and figure out how to store what you have created: Word documents, Excel spreadsheets, Powerpoint slides, and more. You will need to track the revisions you and others have made to those files. Plus, if your colleague prefers Lotus for spreadsheet work, then the two of you have to work out whatever problems exist in accessing each other's spreadsheet data.
"The whole point of PDM is to make transactions transparent and to present them in a way that's appealing, compelling, graphical, and relevant to that particular user's task," continues Gnatovich.
At the 50,000-foot level, PDM is an evolving information management system operating on top of the client/server infrastructure. Servers run the core PDM package and maintain the central repository—the vault—of data and files related to engineering development. Users access these data and files from the applications that run on their desktop computers (clients).
PDM has several groups of functionality:
Vault. The vault stores, organizes, controls, retrieves, and protects product data. It supervises the access of those data by individual, project, or some other user-defined parameter. The vault can contain the data itself or contain metadata, data about the location of the data. "Users must go through the PDM system to get controlled data," explains Miller. "This may seem like a road block to getting the job done, but this is not the case, for it means that users don't have to know where data are actually located and ensures that they get the latest versions of data."
Process management, process modeling, and design control. This functionality involves controlling the creation and modification of product configurations, part definitions, data relationships, and other product data throughout product development lifecycle. PDM records each step of the creation of data, providing an audit trail crucial for tracking design intent, and reversing design changes.
Configuration management, product structure management, and engineering change. This group of functionality focuses on creating and managing production configurations and bills of material (BOM). Features include keeping and managing previous build versions, managing effectivities, supervising several different configurations of the product simultaneously, managing engineering change orders (ECOs), and providing different aspects of a product based on design discipline (such as mechanical, electronic, and even financial). Traditionally, engineering changes and BOMs were considered external to the product development environment. But products change over time, and manufacturing, which typically builds the product version delivered to it, cannot rely on MRP II once engineering is done with product development because MRP II does not perform configuration management.
Program management. PDM-based project management includes real-time resource scheduling and project tracking, progress reporting, status and location of deliverables, and identifying the individuals working on deliverables. PDM-based program management is the least mature group of functionality within PDM, and is often provided by third-party applications.
Workflow. A key element in both process and configuration management, workflow processes automatically parcel the results of tasks to the next set of tasks in a series, and can alert the associated individuals that work is waiting or being accomplished. The work defined in a workflow system can be serial or concurrent; in either case, work can proceed based on the simple completion of a step or on conditional requirements. Repetitive processes are ideal for workflow operations. When given a graphical interface, workflow lets users see where resources and deliverables sit in the overall engineering process.
PDM for Everybody
CIMdata's "PDM Buyer's Guide" profiles 49 commercially-available PDM products. "Some are directed at large organizations, some are PC-based and intended for small departments, some are focused on specific industries, some are bundled with other applications, while others are offered independently," says Miller. Their prices range from $1,500 to $4,500 per concurrent user, depending on the modules required. Add to that the services over the lifetime of a PDM implementation; Gnatovich of Computervision says that the cost of services is typically three times the cost of the software.
CIMdata categorizes PDM systems as "enterprise capable," "workgroup/department capable," and "application-oriented." The first category may be misleading. The term "enterprise" can apply to $10 billion companies with sites worldwide to $100 million companies situated on a single site. Huge differences exist in these two types of companies and their PDM systems. For example, a month-long brake assembly design project involving 10 people at a single site is quite different than a 3-year new car development program involving teams of people in three domestic locations, four foreign locations, dozens of certified suppliers, and a half-dozen globally situated strategic manufacturers.
"You've got two things to consider," explains Rudy. "How large is the enterprise's infrastructure to be supported, and how broad is the functionality that needs to be provided?"
Similar issues exist for workgroup-level PDM systems. For example, automotive engineering and design projects often encompass people working round-the-world, round-the-clock. These people are a "workgroup" because they work on the same project, communicate with each other, share design information, and presumably use the same tools. The trick becomes how to tie these people together, such as the engineering workgroup operating in Detroit during the day and the manufacturing workgroup operating in Singapore at night.
The difference between enterprise and workgroup PDM operations, proposes Rudy, is that "at the workgroup level, people are focused on managing the information from one tool. At the enterprise level, they're focused on managing information from multiple tools, such as CAD, ERP, and financials."
Application-oriented PDM excel in understanding the intricate relationships of data and complex applications within a vendor's product set. This makes these PDM products excellent for workgroup level operations, but may be a mismatch when applied to the much larger enterprise and its round-the-time-zone distributed workgroups.
Implementation: Always an Issue
To date, automotive companies have implemented PDM in drips and drabs, but they are now at the point where they need to build a corporate data model and leverage that to optimize their business processes. To do that successfully requires business processes that are reasonably consistent—not a strong point of monolithic OEMs and Tier-1 suppliers.
In many ways, implementing PDM is like implementing ERP. The effort involves organizational, operational, technological, and vendor issues that will evolve over many, many years. Says David Mitchell, EDS Unigraphics director of Marketing & Development for IMAN (Cypress, CA), "The biggest problem implementing PDM is not the technology, it's the cultural change involved in standardizing your processes and then enforcing those processes."
The effort often starts with a cross-functional team involving at least MIS, engineering, manufacturing, marketing, and purchasing. A PDM champion is absolutely critical to the success of the implementation. So too is top management support. Without that, the implementation will fail.
The PDM team will need to review the company's AS-IS and TO-BE business processes. It will also need to develop a model of the corporation's data. For example, an ECO may contain 50 fields of data, but what are those fields? How are they interrelated? And how do they relate to other documents, processes, and people? Some PDM vendors deliver an out-of-the-box data model. Yet even with this model, the PDM team still needs to focus on the company's needs and how it uses data. PDM customizations, even implementation approaches, often are not so much technologically based as operationally company-specific.
At some point early on in the PDM implementation process, engineering will have to do what was done when implementing MRP: Lock up its "inventory," in this case, secure the company's engineering and release data in a vault. Doing this both protects and enforces a structure to the data, and begins the management of making data readily accessible.
Business priorities will determine what to do next. If engineering release is the company's priority, work flow and change control may be the next implementation step. If the hand-off between engineering and manufacturing is a problem, the company may want to work on configuration management and the interface to ERP.
In any case, the goal is to eventually have PDM be an enterprise solution. "PDM has to reach backwards up into the marketing and requirements definition for products and it has to reach forward beyond design into the manufacturing and service world," says Scott Berkey, vice president of Operations for Metaphase Technology, Inc. (Arden Hills, MN). "Instead of PDM being focused strictly on concept to delivery-to-manufacturing, it has to be an enterprise solution with a wider view of the business process."
Potential PDM Benefits
Source: Computervision Corp.
PDM in Action
Motor Coach Industries (Winnipeg, Manitoba, Canada) relied on PDM when developing its new 45-foot-long tour coach. With more than 90% of the new product defined digitally using CAD/CAM software from EDS Unigraphics (Maryland Heights, MO), the company turned to EDS Unigraphics' IMAN (Information Manager) PDM product to manage the hundreds of thousands of components in the new vehicle's huge assemblies.
"The biggest benefit to our user base is better access to data," says Bruce Beally, CAD/CAM Administrator at Motor Coach. "We needed a simplified method for getting access to our data, along with a higher quality database and better version control. IMAN also provided us with the ability to electronically release items to the database. That has proved to be a big benefit to us."
Beally says PDM also played an important role in the company's overall reengineering program. This effort reduced the part count in one coach model by 20,000 parts and slashed time-to-market from 60 months to 34 months. While many other processes were involved in this effort, concludes Beally, "I don't think you are going to realize all the measurable benefits of reengineering unless you adopt a PDM system to efficiently manage your data."
Now for the Current Controversy in PDM
The PDM business is going away, says Computervision's Gnatovich, and being replaced by systems focused on configuration management. The rest of PDM's functionality is moving to Internet- and Intranet-based systems. "The Web paradigm is far more compelling for this application," Gnatovich observes.
Here's why. The Internet doesn't have a scalability problem; it encompasses, say, 50 million global users right now. And it doesn't appear to have a usability problem. All users seem to be able to get their hands on the data they want.
However, the Web is mostly about accessing data, says EDS Unigraphics' Mitchell. "It is not about controlling, securing, configuring, and managing access to data." Missing are such important features as accessing the right data, managing configured data, accessing and modifying workflows, and accessing vaults. Before the Web can be used in a production PDM environment—engineering or any other mission-critical, back office application—performance, management, and security issues need to be addressed, as well as the overall structure of data and the data modeling components. This is, of course, the role PDM plays, suggesting that a PDM layer will always exist between the user and the data.