The PDM Application

Abstract

A PDM application is a very specific type of PLM application. It has the primary purpose of managing product data. Like most things in the PLM environment, PDM applications are given different names by different people (Fig. 10.1). And like most things in the PLM environment, they are often referred to by a 2-, 3- or 4-letter acronym (Fig. 10.2).

10.1 Introduction

A PDM application is a very specific type of PLM application. It has the primary purpose of managing product data. Like most things in the PLM environment, PDM applications are given different names by different people (Fig. 10.1). And like most things in the PLM environment, they’re often referred to by a 2-, 3- or 4-letter acronym (Fig. 10.2).

Fig. 10.1

Some different names for PDM applications

Fig. 10.2

Some acronyms for PDM applications

Apart from PDM applications, there are, of course, many other applications that manage product data. For example, ERP applications, product testing applications and technical publishing systems all work with, and manage, some product data. However, the primary purpose of these applications isn’t to manage product data.

PDM applications can manage product data across the lifecycle. However, in the early twenty-first century, they often only manage a part of a company’s product data. Usually this is product data created in product development applications. Other product data is managed by other applications (Fig. 10.3).

Fig. 10.3

Examples of product data managed by PDM and other applications

10.2 PDM Application Overview

There are eight basic components of a PDM application (Fig. 10.4). In different PDM applications, the functionality corresponding to these components may be distributed differently between different modules. And, in different PDM applications, these components may have different names. As a result, these components aren’t always easy to see when investigating a PDM application.

Fig. 10.4

Eight components of a PDM application

The first component is the Information Warehouse. Product data is stored in the Information Warehouse.

The Information Warehouse Manager controls and manages the information in the Information Warehouse. It’s responsible for such issues as data access, storage and recall, information security and integrity, concurrent use of data, and archival and recovery. It provides traceability of all actions taken on data.

The PDM application requires a basic infrastructure of a networked IT environment. The infrastructure usually includes computer and communications hardware and software, a range of graphics terminals, printers, plotters, and other devices. It may include other data management systems. There will probably be a communications network that will be used for both local and wide area communications, and for both short transfers (such as messages) and long transfers (such as files).

The fourth component of the application is the System Administration Manager. This is used to set up and maintain the configuration of the PDM application, and to assign and modify access rights.

Users and other applications access the PDM application through the Interface Module. It provides a standard, but tailorable, interface for users. The Interface Module supports user queries, menu-driven and forms-driven input, and report generation. It provides interfaces for applications such as CAD, document scanning, electronic publishing and ERP.

The structure of the information and processes to be managed by the PDM application is defined by the Product and Workflow Structure Definition Module. The workflow is made up of a set of activities, to which information such as roles, resources, events, procedures, standards and responsibilities can be associated.

Once initiated, workflow needs to be kept under control. This is the task of the Workflow Control Module. It controls and coordinates activities. It manages, for example, the engineering change process.

The exact structure of all products and information in the system is maintained by the Information Management Module.

10.3 Importance of the PDM Application

A PDM application is one of the most important elements of a PLM solution. It can manage all the product data created and used in the PLM environment.

Whatever the PLM Strategy that’s chosen, it’s probable that the PDM application will be a major constituent. PDM gets product data under control. And, unless the product data in the product lifecycle is under control, it will be difficult to get the product under control.

The PDM application is used in the management of product data throughout the product lifecycle. PDM applications provide support, in the complex environment of PLM, to the many activities of the lifecycle such as design, sign-off, the sharing of data between multiple users, the tracking of engineering change orders, the management of design alternatives, and the control of product configurations.

Any application that’s put in place to manage product data must have functionality to limit activity to what’s allowed, and be sufficiently powerful to maintain control. Yet it must also be sufficiently flexible to support the changes that typify the product development and support environment. The application needs to be able, for example to allow partial, or early, release of data. It needs to allow changes to be made as work progresses. It needs to be able to manage activities that are still primarily paper-based as well as those that are computer-based. It needs to be able to handle scanned paper documents as well as the data created by other applications. It needs to be able to work with different levels of data definition, and with different representations of data.

At first sight, it may appear that the need for PDM results from the need to manage the large volumes of product data generated by computer-based applications. However, it’s actually the business reasons, the needs to improve productivity and to respond better to customers, that have become the driving force to achieve better management of product data. PDM oversees the creation and use of product information throughout a product’s life. It’s by improving the use, quality and flow of product data, that PDM makes it possible to reduce lead times and product costs, and improve competitivity, market share and revenues. PDM applications offer the potential for many improvements (Fig. 10.5).

Fig. 10.5

Potential performance improvements with PDM applications

A PDM application can provide exactly the right information at exactly the right time. Having digital product data under PDM control helps attain the objectives of improved product development and support in several ways (Fig. 10.6).

Fig. 10.6

PDM applications help improve product development and support

For most of the product lifecycle, information is all-important. It’s all people can work with when the product doesn’t physically exist. Product data is a strategic resource, and its management a key issue.

10.4 The Eight Components

10.4.1 Information Warehouse

The Information Warehouse stores information regardless of its medium (such as paper, tape, disk) or physical location (which could be, for example, in engineering, in manufacturing, on-site, or off-site). It can handle all the information in the company, or the Extended Enterprise, thus permitting centralised control of distributed data. Information only has to be entered once into the Information Warehouse. All information is indexed and traceable, and can be searched for. The Information Warehouse acts as a single source for all product information.

The Information Warehouse stores all types of product data. Information can be of varying sizes and formats. Information may be text, numeric, or graphic. It may have been created internally or externally. Information will be in various states (such as in-process, in-review, released) depending on its position in the lifecycle. Information will have various structures which can be stored in the Information Warehouse. The Information Warehouse can also store different alternatives and versions.

Apart from product definition data, the Information Warehouse will also store information such as relationships, workflow models, and product configurations. It will store computer applications and technical manuals. It will store procedures and standards. For a given assembly, for example, the Information Warehouse may store information on workflow models, parts in the assembly, relations between the parts, specifications, CAD models, drawings, process plans, tooling drawings, test results, and field information. Similarly, information on hierarchical structures, such as a car and the corresponding powertrain and transmission, can be stored in the Information Warehouse.

10.4.2 Information Warehouse Manager

The role of the Information Warehouse Manager is to store incoming information securely and with integrity, to provide controlled access, and to protect product information. The Information Warehouse Manager manages the Information Warehouse. It controls and guards the data in the Information Warehouse. The Information Warehouse Manager allows data to be entered into the Information Warehouse and retrieved. Once retrieved, it can be transferred, modified, and copied.

The Information Warehouse is sometimes referred to as a repository or a library. The Information Warehouse Manager is sometimes referred to as a librarian module.

The Information Warehouse Manager works in a distributed computing environment and a multi-organisation, multi-company environment. It must be able to control, for example, a text file on one vendor’s computer in one company that will be required by a CAD user on another vendor’s PC in a supplier company.

The Information Warehouse Manager must be able to keep track of information outside the company, for example, information that’s with suppliers. To support a variety of users and tasks, the Information Warehouse Manager allows for multiple views of data and multiple levels of data. The Information Warehouse Manager provides check-in/check-out facilities for individual files and sets of files. It’s used to set up and maintain parameters describing data characteristics. It stores and makes available information under allowed access conditions. It provides access to information through a range of permission levels. These allow access to be controlled by a variety of criteria such as user, product, project, group, device, state of information, and type of information.

The Information Warehouse Manager limits access to authorised users. Data can be given a range of classifications from user-private to public. Some users will have view-only rights. Some will be able to copy data. Others to read and write data. At various well-defined times in a project, or in a product’s life, these rights may change. For example, once design information has been released to manufacturing, designers will no longer be able to modify it, but manufacturing engineers will be able to modify it. The access conditions may change as the data moves through the product lifecycle. Depending on its status, data may be read-only. To maintain integrity, multiple simultaneous update will be prevented.

The Information Warehouse Manager supports private data bases (single-user), project data bases (multi-user, linked to project lifetime), and product data bases (multi-user, existing parts). It can manage information stored in simple files or in hierarchical or relational databases. It can manage information on paper. The Information Warehouse Manager provides security information on all unauthorised attempts to access data. It can provide an audit trail of all action taken on data. The Information Warehouse Manager automatically backs up the information it receives and is able to recover all information lost as a result of computer or human problems. It has responsibility for systematic and on-demand archival. This may be to electronic or traditional media.

10.4.3 Infrastructure

The basic infrastructure of the environment includes computers and a communications network. The PDM application runs in a multi-vendor computer environment. Some computers may be in the company. Some may be in other companies in the Extended Enterprise. A variety of data-creation applications such as recipe formulation, CAD/CAM, document scanning, electronic publishing, structural analysis, and process planning will run on these computers. The infrastructure will probably include workstations and personal computers, as well as handheld and other graphics devices. These may range from intelligent 3-D graphics terminals to less sophisticated 2D view-only terminals. There may be some other data management applications, such as relational data base management systems, in the environment. The infrastructure also includes other input devices, such as scanners, and output devices, such as printers and plotters.

The communications network will include both local area networks (LANs) and wide area networks (WANs), so that information can be communicated both on one site and between sites. Both short messages and long data files will have to be transmitted on the network. A message may be only a few words long. On the other hand, the volume of a data transfer, such as a product description file, will be much longer.

The infrastructure must be able to handle electronic messages, some generated automatically as a result of events occurring, that need to be distributed to application users who may be based locally or may be far away. They may even be on supplier or customer sites. Electronic messages could inform users and managers that an event has occurred and that work on the following task should now proceed. A message could, for example, inform a supervisor that a design has been completed and should now be reviewed.

10.4.4 System Administration Manager

The System Administration Manager is the component of the PDM application that allows the initial configuration and environment of the application to be described. It will also be used to handle the changes that will occur in the environment.

The specifications of the initial configuration will address, for example, the computers, data bases, data storage devices, networks, applications, workstations, plotters, printers, and other terminals within the environment for which the System Administration Manager will be responsible.

The System Administration Manager will be used to define users and applications in the environment, and to define and modify the access rights of individual users.

10.4.5 Interface Module

People and applications will want to communicate with the PDM application. Suitable interfaces will be needed for both classes of user. In some cases, people will want to access directly the data management application from a terminal without going through another application. They may want to query data held by the PDM application. They may want to look at a part attribute or a workflow description. Users may want to know what work they should do next. They may want to check on existing parts or look at test results. The user interface needs to support queries of many different types as efficiently as possible. The interface should be common to all the graphics devices in the environment.

In other cases, the users of the application will be applications that store, create, modify, process, or otherwise make use of data managed by the PDM application. An efficient and secure interface is needed for access by these applications. The applications could include recipe development, CAD/CAM, document scanners, software development applications, technical publication applications, business applications, and other data management applications. They could also include word-processing and spreadsheet applications. They may exchange large or small volumes of data with the PDM application. The data could be on the same computer as the PDM application, or elsewhere.

The user interface should be easy to understand and use without lengthy training. People from many functions will make use of it. It should be suitable for casual users, yet also offer efficient facilities for frequent users. The interface should include an online help facility.

The user interface should include both menu-driven and forms-driven approaches. Users should be able to tailor both menus and forms to their own requirements. The interface should offer report generation facilities. Again, it should be possible to tailor these to user requirements. Some users may want to view, or to print, information on products and parts. Others may want to generate reports on project status, change history, or attempts to gain unauthorised access to data managed by the PDM application.

10.4.6 Product and Workflow Structure Definition Module

The Product and Workflow Structure Definition Module is used to define the initial structure of a product. It’s also used to define workflows. And it allows these structures to be detailed as work progresses. The product structure defines the information requirements of a product throughout its lifecycle. There’ll be various generic classes of information, such as ingredient descriptions, assembly drawings, part drawings, NC programs, and user manuals. Each class of information will have characteristic attributes and tasks. The product structure describes the information that’s needed, or is produced, at each phase of the lifecycle. The workflow is defined as a set of tasks, characterised by resources, events, associated information, responsibilities, decision criteria, procedures to be used, and standards to be applied.

The product structure and the workflow structure are closely linked. For each group of products, there will be a specific product structure and a corresponding workflow structure. The product structure defines all the information describing a product or part. Some of this information will be created or used at each step of the workflow. New product structures can make use of parts of existing structures. In some cases it will be easiest to start at the beginning of a process and define the information that’s to be created at each step of the process. In other cases it may be easier to start at the end of the process (for example, with a Bill of Materials) and work backwards, identifying at each step the information that would be necessary to generate each information item. Initially, this task is very difficult, and a variable degree of detail is essential for the structure so that work isn’t held up by the unavailability of detailed information on the structure. The product structure has to be sufficiently flexible so as to be able to handle changes to information structures and items. The Product and Workflow Structure Definition Module should offer the possibility to add or associate information when enough information isn’t available to define a product, workflow, or relationship.

The workflow may be described for the entire product lifecycle or for individual processes. The level of detail needed to describe the workflow is variable. The workflow may be described either by starting with the end product and working backwards to the beginning, or by starting with a blank sheet and working forward to the end product. The workflow can be split up into projects or processes. In turn, these can be broken down into phases and steps. A workflow structure may be built up from existing steps, or a new structure may be built. In the same way that the product structure has to be sufficiently flexible to handle changes to the product structure, the workflow structure has to be able to handle changes to workflow.

The workflow structure can be used to control either individual steps in the product workflow (such as document creation) or the entire workflow. It has to include all of the information required to make this possible. It will become the source of work statements, defining the activities to be carried out and the resources to be used. For example, it should specify which users should be involved in the design of a particular part, the applications they should use, the information they will need, the information they should produce, the procedures they should follow, and the approval process. The approval process work statements should specify the roles and authorities of the individuals involved, the rules and requirements for sign-off, and the process to be followed if sign-off is refused.

During a process, “events” occur. An event marks the end of one activity and the beginning of another activity. Events need to be identified and included in the workflow definition. Completion of a design, and initiation of a periodic maintenance activity, are typical events. The activities that lead to and follow each event should be specified. The messages that should be communicated when the event occurs, or if it doesn’t occur within a specified time, have to be defined in the workflow definition. The review, approval, and release workflows have to be defined. The engineering change process has to be modelled. The various steps, reviewers, approvers, and sign-off procedures have to be defined. The definition should include hierarchies so that, if an activity doesn’t occur, it will be passed automatically to the next highest authority. Since many parts of the process are similar or repetitive, some workflow structure elements will be repeated throughout the overall workflow. The creation of change requests and orders is a typical example. Automatic process sequences can be set up to handle tasks such as the provision of copies to individuals named on a distribution list. Once the product and workflow structures have been defined, the PDM application can manage data and workflow. Formal description of the workflow will make it possible to identify unnecessary activities, as well as those that could be run in parallel.

10.4.7 Workflow Control Module

For a particular task, the product structure and the workflow structure will have been defined by the Product and Workflow Definition Structure Module.

The Workflow Control Module then manages the workflow of the various activities in progress, and monitors progress. It controls the progress of projects in an event-driven mode. It maintains status information on ongoing projects.

Once initiated, the Workflow Control Module is in control of the activity. It assigns tasks to individuals, informs them of the resources to be used and the procedures to be followed, initiates the associated actions, and maintains status information. If necessary, the Workflow Control Module can remind users of standard operating procedures, and can check that standards information is accessed. It distributes data and documents to the individuals as needed. When the task is finished it can, for example, request a review, or promote the design and initiate the next step of the process. It can enforce promotion rules. If the person responsible for the next step is absent, it can automatically pass the work to the most suitable replacement or the next highest authority. It manages the review, approval, communication, and archival of information.

Automatic process sequences handle such tasks as providing copies to individuals on a distribution list. Following the rules specified during the definition of the workflow and product definition structures, the Workflow Control Module controls versions and manages the engineering change process.

The Workflow Control Module, on the basis of the workflow and product structures, ensures that all necessary information is available before releasing parts to manufacturing.

The Workflow Control Module monitors the occurrence of events. When an event occurs, it initiates a previously defined set of activities. If an event doesn’t occur at the expected time, the appropriate level of management will be alerted.

When an event occurs, the Workflow Control Module sends, in accordance with the defined structures, the appropriate messages. Engineering change requests and change orders can be rapidly transmitted to inform all interested parties of impending and actual changes. Interested parties can be informed of upcoming events. The Workflow Control Module can notify other people that a change has been requested. It can initiate messages based on parameters captured at each step. It can notify downstream users that modifications have been made to upstream information.

The Workflow Control Module will keep status information up-to-date, and ensure that information is handled as planned. At any time, the Workflow Control Module will be able to display the exact status of each process that it’s managing. It can track and report the status of tasks in process. It can produce progress reports at specified times, showing, for example, how much lead-time has been consumed. The Workflow Control Module maintains an audit trail of activities relating to the process.

Performance analysis can be carried out on activities and on information access. The impact of proposed changes can be analysed and assessed. Resource-level loading can be coordinated, and schedule visibility maintained, for all related tasks.

Once set up for all activities in the environment, the Workflow Control Module should be able to promote parallel, rather than serial, workflow, thus reducing lead times. Increasingly, the Workflow Control Module should play an expert role, checking that input is legal and consistent, and that correct procedures are being followed, and automatically organising activities so as to minimise lead time.

10.4.8 Information Management Module

The information items include all the product data needed to specify, build, test, install, operate, and maintain the product, and to support its end of life. This will include information such as specifications, drawings, lists, programs, reports, and installation manuals. The Information Management Module is used to describe the exact configuration of a particular product throughout its life. It relates components, subassemblies, and assemblies. It supports multiple assembly levels, multiple hierarchies, and multiple membership. The Information Management Module maintains a complete history of the product through design, manufacture, delivery and field use to end-of-life. The status of all information (such as in-process, in-review, released) is maintained by the Information Management Module. It maintains the configuration of a given end product, managing all the required information. For a given product, for example, it may maintain information such as Bill of Materials, goes-into lists, assemblies, relations between the assemblies, CAD models, drawings, analysis results, recipes, parts lists, process plans, NC programs, tooling drawings, test results, and field information. The Information Management Module can distinguish between the as-designed, as-planned, as-built, as-installed, and as-maintained configurations of the product.

The Information Management Module maintains exact configuration information on each individual product. It supports multiple versions and alternatives of data. It takes account of engineering changes. It maintains information about the relationships between information, such as the creation of a document from a particular template.

The Information Management Module offers the possibility to navigate product structure by paging down and traversing the workflow and information structures. It allows information to be accessed in many ways, such as by model number and by part number.

10.5 Benefits of PDM

Different companies will have different drivers for implementing a PDM application. Some examples are shown in Fig. 10.7.

Fig. 10.7

Some reasons for implementing a PDM application

The reasons for implementing a PDM application can be divided into two classes. In one of these, the PDM application appears to alleviate some of the problems that occur in the product development and support environment. In the other, it appears to pro-actively and positively impact operations across the product lifecycle. Although these two classes of reasons can be treated separately, in practice, they’re closely related. Reasons in the first class address the resolution of existing problems. Reasons in the second class go one step further, and address the potential for further improvement. The reasons can be grouped into eleven categories. In each category, most of the reasons can be related both to the resolution of current problems and to pro-active improvement of activities across the product lifecycle. The eleven categories, and examples of benefits in each category, are shown in Fig. 10.8.

Fig. 10.8

Eleven categories of benefits of PDM applications

10.6 Common Issues

There are many PDM applications on the market. The detailed data management requirements of individual companies are different. Implementations of PDM applications tend to be company-specific. Nevertheless, there are several issues common to most PDM applications (Fig. 10.9).

Fig. 10.9

Issues common to most PDM applications

10.6.1 Naming, Functionality, Scope

The functionality and scope of a PDM application are often unclear from the name of the application.

The scope of PDM applications can be very different. Some may have a lot of functionality and have been designed to support product data across the lifecycle. Others may only have limited functionality, and be focused on specific parts of the lifecycle.

Some applications suffer from problems such as incomplete application functionality, malfunction of the application, poor response time, and unavailability of the application on a wide range of platforms.

Among the key factors in determining the functionality that a company needs from a PDM application will be the quality, quantity, and coverage of the applications that are already in place. What do these applications do? What functionality do they have? How will they fit with PDM? Is PDM seen as a replacement for these applications? Is it an add-on? To what extent should it be integrated with them?

PDM applications can offer a wide range of functionality including information management, change management, process management and product structure management. Some, or all, of these functions may already be present in a company’s existing applications. Product structure may be managed in parts master, BOM and MRP applications. Process management may be addressed in project management applications. Some information management functionality may be built into other applications such as a CAD application, or may be in an application developed in-house.

The required functionality will also depend on the way the company is currently organised, and the way it will be organised in the future. If everybody is on one site, then multi-site functionality may not be needed. On the other hand, if users are spread over several locations, multi-site functionality will probably be needed. If product development is carried out in teams, or the company has taken a Concurrent Engineering approach, then corresponding functionality would be looked for in the PDM application.

PDM applications range from simple, off-the-shelf packages with basic functionality to complex tailorable applications with wide-ranging functionality that can be further developed to exactly fit a company’s requirements.

10.6.2 Change, Version Management

One of the driving forces for PLM is the high level of change in the product environment. However, change can be an issue for PDM applications.

A new version of a PDM application can raise problems. The previous version may have met a company’s requirements perfectly. The change, while being of great value to most companies, may raise problems for others.

Changes to other applications can also be an issue. If the data structures in an application interfaced to the PDM application change, then the interface may need to be changed. If many applications are interfaced to the PDM application, and each one changes a few times each year, the situation can get complicated.

10.6.3 Interfaces

PDM applications need to share and exchange product data (such as part numbers, version numbers, product costs) with other applications in the company. Some interfaces may be provided by the vendor as part of the PDM application. Others may be developed with the Application Programming Interface (API) provided with most PDM applications. The API enables the team supporting the PDM application to create, using the application’s objects and routines, any additional functionality that’s needed. For example, an interface may be needed between the PDM application and an application that has been developed in the company.

Many PDM applications have their own specific user interfaces. It can take a long time for users to learn the details.

10.6.4 Data Model, Workflow

There may be issues related to the flow, use and quality of product data. There may be problems with the cost of entering information in the application. The application may not be able to handle all data types. It may not be able to store data where it’s needed. There may be incompatibility between data structures. Classification mechanisms may be inappropriate. There may be no way of encouraging re-use of information.

Problems may arise with particular types of documents. The application may only be set up to handle certain types or formats of documents, and not be able to handle others. It may only be able to handle a limited number of variants of a particular document. It may only be able to apply the same release process to all documents of a particular type, even though the company has different ways of releasing them.

There may be problems with storage and communication of data. The PDM application may only be able to store all data in one physical location, yet use of data may be required at two or more locations. In some cases, it will be the cost of communicating information between different sites that’s the problem, in other cases it may be security or confidentiality.

There may be problems with the structure of information. Different departments may structure the same information in different ways and unless the application is capable of accepting different structures (or views) for the same information, there may be issues as people try to ensure “their” structure is chosen as the standard.

Problems may arise if a company has several naming, numbering and classification conventions, but the application is limited to one convention.

10.6.5 Ownership, Funding, Support

PDM is cross-functional. It doesn’t belong to any one of the functional departments. As a result, it may be unclear who is responsible for it. It may not be obvious how it will be financed. It may not be obvious which practices should be followed in addressing it, which jargon should be used to describe it, or which rules should be followed when managing information in a PDM application. There may be problems cost-justifying the PDM application. Which department or departments should pay the costs of an application that’s used by several departments? How should costs be distributed so that the department that gets the most benefit pays the most? How can the running costs of the application be shared equitably? This is especially difficult to achieve if the application is installed in one department, supported by people from another department, and used by people from many other departments.

Insufficient investment is a common issue with PDM applications, as is the use of inappropriate project cost-justification calculations. These may generate over-optimistic expectations. The targets put in place to drive the implementation and use of PDM may be inappropriate or even unattainable.

10.6.6 Fit in IS Architecture

With a primary purpose of managing product data, a PDM application needs to be closely linked to the other PLM applications that create and use product data. The PDM application needs to fit seamlessly into the IS architecture.

10.6.7 Customisation, Installation

At installation time, all sorts of issues can arise with a PDM application. Its implementation may take much longer than expected. The people who planned for PDM, and selected the PDM application, may pull out before the application is installed, leaving implementation in the hands of people who neither understand the objectives nor are motivated to succeed. Insufficient training may be given to users and the application support team. There may be no guidelines describing how the application should be used. There may be problems with the application itself. It may not work the way the vendor claimed it would, or it may have bugs, or it may not be documented, or there may be no procedures showing how it should be used.

As another example of the type of problem that could occur, a PDM application vendor may propose to a company that a system integration partner will implement the application. The system integrator may not have enough people with the right skills available, so asks one of its partners if it has someone suitable. The partner doesn’t, but knows some people who have the skills. These people work hard at doing what they’re told to do. The only problem is that they’ve never seen either the company or the vendor. Not surprisingly their deliverables aren’t exactly what the company wanted. Then, of course, there are lots of meetings at which the company blames the vendor, and the vendor blames the integrator. None of which adds any value for the users.

Another potential problem, with its roots in the past, is the unorganised state of most information that’s under the control of traditional manual information management systems. Provided that it’s been possible for a person who has been in the company for the last 30 years to lay their hands on a particular document within a few hours, most people have been happy. PDM applications don’t work like that.

Other implementation problems can be due to poor understanding and definition of the processes. Problems may arise because the application doesn’t address the parts of the overall process that the company is interested in. Problems can also arise at the level of individual activities if the application doesn’t work the way the company wants to carry out specific activities such as release and engineering change control. It’s important that the process be understood and clearly defined. Otherwise it’s going to be difficult to use PDM to support it. PDM can’t be used effectively if key issues are unclear (Fig. 10.10).

Fig. 10.10

Lack of clarity concerning the process

Another problem that can arise is that the people who are supposed to look at the process issues can’t agree among themselves as to what the process should be.

10.6.8 Everyday Use

Some issues may arise when the application starts to be used on an everyday basis (Fig. 10.11).

Fig. 10.11

Potential issues when everyday use starts

Another source of problems can be the interfaces between PDM and other applications. Unless all the interfaces exist, some users will work entirely outside the PDM application rather than sometimes inside and sometimes outside. Problems may arise if new developments promised by the vendor don’t appear. In-house application developments can also be a source of problems. Sometimes, developments won’t be made because funding is cut or because they have low priority on the waiting list. Another problem that may arise after installation is that the project budget, in particular the training budget, is slashed. The funding of the PDM application support team, the group that should make sure the application works on an everyday basis and should provide everyday support to users, may be cut. As PDM gradually takes hold, some departments may feel they’re losing control or power. As a result they may start to block its use and hinder further development.

There may be issues related to top management such as lack of commitment, lack of leadership, lack of support and lack of patience. Problems at the middle management level may be due to conflicts with personal goals, empire-building, and fear of loss of power. Users may fear that the PDM application may play a Big Brother role, or may lead to job losses. Problems can also arise if the members of the PDM project team don’t work together effectively. Other issues may affect everyday use of PDM (Fig. 10.12).

Fig. 10.12

Issues affecting everyday use

Users may run into problems. For example, the application may crash or malfunction frequently. Users may complain that it’s not user-friendly and takes too long to learn to use. They may suffer from poor response time as the amount of product data in the application increases. Application upgrades may be necessary and the result may be that application use becomes too expensive. In some areas, the application may not behave as expected, and time-wasting workarounds may be necessary. As users get to know the application, they may find that functionality has been oversold. Functions they need may not exist, or may only be partially implemented. The application may only handle a limited number of document types. Documentation and on-line help may not exist for some key functions. There may be no guidelines describing how the application should be used. Necessary customisation may be too difficult or too time-consuming for users.

The people involved in PDM application administration and support will hear all about the problems that users are having. They may also have their own problems (Fig. 10.13).

Fig. 10.13

Possible concerns of the PDM support team

As time goes on, it may become clear that the wrong vendor was chosen. New versions may be delivered late, lack promised functionality, and have quality problems. Maintenance costs may become unacceptably high. There may be no upgrade path between successive versions. Key individuals may leave the vendor. Eventually the vendor may go out of business.

10.7 Little Data Management Excitement

Most business managers find “let’s spend a lot of money to manage data” about as interesting as “let’s watch paint drying”. If you are a technical manager trying to implement a PDM system, make sure you have plenty of reasons why it’s needed, and plenty of answers to the negative replies you are likely to receive.

The typical business manager will respond to the technical manager’s request for PDM with, “You mean you want to spend $1 million (or $100,000 or $10,000) on a system that’s just going to manage data? But you’re already managing the data, aren’t you? So why do you want to spend all that money? You can’t do that, that’ll just increase our costs. And at the end of the day there’s no real benefit. We’ll just be managing the same data a different way. Our costs will go up and our productivity will go down.”

“No”, says the technical manager, “there’ll be many benefits. Everyone will have faster access to product data and developers will no longer waste 30% of their time looking for it. We’ll be able to develop products faster, we’ll have fewer quality problems and, because we’ll develop faster, we’ll need fewer development hours, so our costs will go down.”

“Listen”, the business manager says, “the only way I can move this business forward is by increasing revenues or cutting costs. This PDM system of yours isn’t going to increase revenues. I’ll give you three good reasons why.

One, you say it’ll get our products to market quicker, but when I look at our Engineering organisation I can’t see that changing the way we manage data is going to cut the development time by even 1%. Two, it takes so long to get a product out in the market, and make money, there’ll be no benefit on the bottom line for at least 5 years. And no-one’s going to throw money at a project that doesn’t show a return for 5 years. Three, there’ll be such chaos when you try and take the old system out, and put the new one in, that there’ll be all sorts of problems for the customers. We can’t risk that again.

So, there’s no increase in revenues, and as I keep telling you, I’ve got to reduce costs. Knowing our cost structure, I can’t see how buying a new system will do that. It will do the opposite. It will push up costs. But let’s try to be positive. The easiest way for us to reduce costs is to reduce headcount. Where will this data management system help us lay off people? Who’s doing the data management work today? You said the engineers will save 30% of their time, but we can’t lay off 30% of each engineer.”

“You make it sound so difficult”, says the technical manager. “Just cutting the product data management workload will reduce the development hours, so we’ll cut costs. And because we’ll be faster to market, we can increase market share, and charge premium prices”.

“Listen”, says the business manager, “We just said that if we want to reduce costs we’ve got to lay off people. So first you tell me how many people we can lay off in your department in the next 3 years, and then you write down their names. As for speed to market, it sounds great, but it doesn’t mean anything. If we decide to go ahead with this data system of yours, it will take at least 2 years to select. Remember when we got the CAD system? It will distract everyone’s attention from the real issue of developing products faster. It will take 3 years to bring into operation. Look what’s happening with the ERP implementation. And after that it will probably be another 4 or 5 years before we’d actually see any product developed with the new system hitting the market. So you’re talking about benefits 9 or 10 years down the road. By that time, I’ll have retired, and you’ll be in a new job. Just forget it and get those drawings to the plant.”

10.8 No PDM Application is an Island

No PDM application is an island (Fig. 10.14), isolated from the rest of the company. All PDM applications are closely related with other PLM components. They are also influenced by other forces within the company, and outside the company.

Fig. 10.14

No PDM application is an island

If a type of document that’s managed by the PDM application is changed, and the metadata is changed, then it may be necessary to change the way that the PDM application manages the document. Relationships with other objects may need to be changed. If an application that’s interfaced to the PDM application is modified, it may be necessary to modify the interface. The information about users in the PDM application will need to be updated when new people join the company, or when people change roles or positions in the company. When processes are changed, workflows managed by the PDM application may need to be changed. If a new type of product is developed, a new product information structure may need to be created in the PDM application.

10.9 The Challenges

The specific PDM-related challenges that a particular company faces could come from several sources (Fig. 10.15).

Fig. 10.15

Potential PDM application-related challenges for a company

10.10 The Way Forward

The issues described in this chapter all relate to PDM applications, but they can’t be solved in isolation from the other components of PLM. Their solution, within the PLM environment, is addressed in Part 3 of this book.