strategies for introducing pdm systems in engineering ... - CiteSeerX

28 downloads 0 Views 143KB Size Report
summarized as (CIMdata, 1995):. • Data Vault and Document Manager. • Workflow and Process Management. • Product Structure (Configuration) Management.
STRATEGIES FOR INTRODUCING PDM SYSTEMS IN ENGINEERING COMPANIES

STRATEGIES FOR INTRODUCING PDM SYSTEMS IN ENGINEERING COMPANIES Peter Pikosz, Johan Malmström and Johan Malmqvist Machine and Vehicle Design Chalmers University of Technology S - 412 96 Göteborg Sweden

ABSTRACT The paper analyses different strategies for introducing PDM (Product Data Management) systems in engineering companies. The identification of the strategies is based on observations from case studies in Swedish industry. The strategies are described with respect of how to perform them, their potential to support the integrated product development process, risks associated with each strategy and how to extend the implementation to cover the whole PDM vision. A number of success factors and pitfalls are listed. 1

INTRODUCTION In the product development process (PDP), the management of product data is of crucial importance. The requirements on efficient management of product data are steadily increasing: Product development lead times need to be shortened, so we need faster information flows. Products are getting more complex, so we need to manage systems with thousands of parts, many existing in different variants and versions. The globalization of the PDP necessitates that product data can be immediately made accessible from multiple locations etc. However, the current situation is in many companies characterized by “automated islands”, by large amounts of data stored in legacy systems that are increasingly expensive to operate and further develop, and by long-term document storage systems that are paper-based. Leading companies - Ericsson, Volvo, Ford and many others have realized the strategic importance of an effective product data management and have all begun projects that aim at implementing Product Data Management (PDM) systems - systems that manage all information about a product as a logically integrated information model. These implementations are usually based on one of the commercially available PDM systems (IBM PM, IMAN, Matrix, Metaphase, Sherpa are some examples), which is then customized to fit the companies needs.

Implementing PDM systems has, however, proven difficult. The implementation process takes a long time, failures have been reported and it is not uncommon that the goals for the PDM implementation have been lowered or postponed. Many factors may contribute to these difficulties: vital components of the technology are immature and untested, the implementation process is complex as it involves the whole company, with many users with different information needs and computer skills, and that different implementation strategies are needed in different companies due to differences in PDM requirements and legacy systems. The goal for this paper is to analyse the PDM implementation process in order to identify alternative implementation strategies, with associated advantages, disadvantages and risks. Furthermore, success factors and pitfalls will be identified. The study is based on reports from Swedish PDM implementation projects. The remainder of this paper is organized as follows: Section 2 provides an overview of the capabilities of currently available commercial PDM systems. Section 3 gives an analysis from a managerial perspective. In section 4, various alternative implementation strategies are discussed from a technical viewpoint. Case studies regarding those strategies are presented in section 5. Success factors and pitfalls are discussed in section 6 and conclusions listed in section 7. 2

PDM SYSTEMS This chapter describes the vision of the PDM technology and the current functionality of commercial PDM systems. 2.1 PDM vision The basic idea of PDM systems is that they should manage all information about a product as a logically integrated information model. The PDM vendors have claimed that the systems can be used as the main system within the company and integrate other systems that are used in different departments and by suppliers.

Suppliers

Customers Interface Sales/ Marketing

Design PDM System

Prototype Manufacturing

PostProduction Control

Meta-data Managed Files

Project Management

Manufacturing

Production

Process/ Plant

Purchasing/ Finance

FIGURE 1: Enterprise PDM The PDM system then forms the standard interface between the company’s integrated product data base and the information users, see FIGURE 1. A complete PDM implementation should be able to support all functions within a company as well as suppliers and customers with the appropriate information, at the right time and in the correct format. The globalization of companies and of development projects have lead to a need of global data access ability, enabling the “real-time projects around the world” (Johansson, 1995). The PDM systems must be able to support different users with heterogeneous data files in a distributed network environment enabling world wide access to product data. This demand has resulted in a trend to introduce internet user interfaces, enabling the use of common web-browsers (e.g. Netscape Navigator or Microsoft Explorer) to access PDM information on the company intranet. The access to the PDM system is enhanced since the user interface is well known world wide and therefore also to many of the employees. 2.2 PDM functionality The currently available functionality of a PDM system can be summarized as (CIMdata, 1995): • Data Vault and Document Manager • Workflow and Process Management • Product Structure (Configuration) Management • Parts and Components Management (Classification) • Program Management • Communication and Notification. • Data Transport • Data Translation • Image Services • System Administration The core of a PDM system is today a database containing metadata (data about data) for documents managed by the system. The PDM systems operate in a distributed computer network environment and must therefore be able to keep track of the location as well as format of each document. The document manager manages meta-data for the documents and also contains links to the digital file containing the document, which is stored in

the data vault. If a for the document authorized designer performs a check-out on a document, the document manager will automatically create a new version of the document and it will be locked for other users. Two very important functions are product structure management (or configuration management) and workflow management (or process management). The main task for the configuration management is to keep track on the correct set of documentation for each version of a product. The workflow functionality is used to automate various processes in the company. For example, many companies use a number of standardized release processes that can be implemented in the system. One process which is often sold as a separate module by the PDM system vendors is the engineering change process. PDM systems include functions for translating and communicate data and for linking data to different computer applications. This enables the integration of various computer tools with the PDM system. PDM systems can for example use translation software to convert the file to the new format when opening a CAD part for viewing in a VR (Virtual Reality) system (Menon and Horn, 1996). The PDM systems also provide an easy access to data for the users through their viewing functionality. 2.3 PDM system configuration Initially, PDM systems were marketed as the main company system (Enterprise PDM), intended to manage files from all applications. The PDM systems have however evolved from the MCAD systems, and are specialized for managing mechanical products. The PDM vendors have tried to apply methods for configuration management of mechanical products on all files. However, the configuration management of mechanical parts, software and electronics is different (van den Hamer and Lepoeter, 1996). In order to be able to manage all files in the best way possible, dedicated local PDM software for SW and electronics development applications can be introduced. FIGURE 2 shows how a local PDM solution can be used in order to support a multi-technological product development project. Instead of the original idea of PDM managing all documents within the company, the PDM system only manages MCAD and for example text documents. The ECAD files are managed by a local PDM system, whereas the configuration of software files is managed by a software configuration management (SW-CM) tool. Any change of document status in the local PDM is reported to the global PDM, where the product model is stored. Another approach is to let different functional groups within the company use their own local PDM system and to bridge them to a global PDM solution. The integration is here essential. Different levels of integration between PDM systems ranging from independent applications to total enterprise integration with workflow management are described by Carl and Judd (1994). An even more diversified PDM system configuration would be to select the best suited PDM solution for each application, project or department. The team members work in their application and have their files managed by the local PDM. Other users can follow the progress of work in the global PDM system. This strategy can be utilized in large companies, where the PDM focus might differ depending on organizational unit (FIGURE 3).

Archive

Archive

PDM

PDM EPDM

SW-CM

ECAD

SW

Projects

PDM_A

PDM_B

Dept. A

Project B

MCAD

Local Archive

Functional org.

FIGURE 3: Example of local PDM II FIGURE 2: Example of local PDM I 2.4 PDM technology status The current PDM maturity level differs depending on functionality. The most mature functionalities are data vaults and document managers which have been successfully implemented in several companies. The workflow managers are also proving to work, although it has been claimed that the workflow modules for engineering change management require too much customizing before they can be successfully implemented on a given company’s process (Pikosz, 1997). The alternative is to replace the company’s process by the one provided by the vendor. While this may not be an ideal process for the specific company, it will require less customization and maintenance and still improve the efficiency of the process. The product structure management has been proven to work for products without multiple variants and/or customer order based designs. It has yet not been proven that the PDM systems can fully support for more sophisticated configuration management such as that used in the automotive industry, where product with many variants based on a common platform are to be produced towards customer orders. The parts and components manager is a functionality where other vendors currently are stronger than the PDM vendors. The parts management software vendors argue that the introduction of a parts management system can simplify the introduction of a PDM system. Although, parts management software will only solve a subset of the problems involved with the PDM area, it can serve as a good start for future PDM implementation by the creation of a database containing meta-data and digital documents. The functionality for program management is used to support the project planning and control within a product development team. This functionality is however quite poor today and PDM vendors seem to have left this functionality to dedicated software and instead focused on interfaces to existing project planning software. The communication and data transport abilities are well developed. One of the trends among PDM vendors is well developed interfaces to different types of tools like CAD systems and word processors. Software for image services or viewing of documents are well integrated in most PDM systems.

Communication can be troublesome when the PDM system needs to communicate large amounts of data such as CAD files over computer networks (Kling, 1997; Cederbaum, 1996). The configuration of the network as well as of the servers differs in all companies which makes it difficult to predict the performance of the PDM solution, thus it is important that companies seeking to introduce PDM check the information technology (IT) infrastructure before the PDM introduction. Some fundamental limitations in the PDM systems ability to provide a complete product model have been identified by Pikosz and Malmqvist (1996). The product structure representation in most PDM systems is based on strictly hierarchical part-of relations. A capability to model non-hierarchical relationships could strongly support engineering change management by enabling relations between changed parts and affected parts or assemblies. Further, data modelling in PDM system is today entirely based on meta-data. A representation of, e.g., requirements as objects in the PDM database and linking these objects to design features in CAD systems would enable a richer representation of design history as well as support queries like “What design solution satisfies this requirement?”. 3

DIMENSIONS IN INTRODUCING PDM This chapter describes how a PDM implementation project can be performed from a tactical point of view. While implementing PDM systems in an organization there are five different dimensions that need to be considered. They are (1) focus; (2) level of change; (3) width of change; (4) participative or expert driven; and (5) speed of change. Different companies will address these issues differently depending on which context they are in. It is difficult to give a definite answer on exactly what the correct way of implementing a PDM system is, since the companies operate under different circumstances. 3.1 Focus Different companies have different reasons for introducing PDM systems. They will focus on different aspects of the PDM support. Full scale implementation of PDM systems is usually done as a part of a company’s long range plans to utilize modern information

technology support to make the PD process more efficient. In this case the entire, or most, functionality of a PDM system (section 2.3) will be used. Other companies will turn to PDM systems when they have certain problems where a subset of the PDM functionality can give great gain to the company. A typical example of this is engineering change management. Here the workflow management in a PDM system can greatly help a company that experiences trouble in that area. This is one usual starting point for PDM usage after the move to more complex products and more variants in today‘s business life. For example SAAB Military Aircraft introduced the PDM system SHERPA to secure proper handling of the multiple change orders in the development of a new multipurpose airplane for the Swedish Air Force, the JAS project. It was not uncommon that the same part had several different engineering change orders on it. The only way to keep track of this was through a PDM system. PDM systems can also be used to link different functional departments, and in that sense be an enabling technology for concurrent engineering. PDM systems support day-to-day contacts between different departments such as Engineering, Manufacturing, Marketing and Procurement. Another use of PDM systems is to provide support for geographically distributed product development. With the rise of outsourcing, and virtual companies, the need of an efficient method for sharing product data between different locations in the same company, and closely tied suppliers, has become even more important. 3.2 Level of change When introducing PDM, one of the more important tasks is to decide the level of change that must be made to the rest of the company in order to utilize the possible advantages of PDM. It is possible to implement a PDM system over the existing processes in a engineering company. This method is often assessed as easy, even though it may require extensive modification of the PDM system to bring into pace with the companies method of working and existing computer systems. However, this method does not utilize the full promise of PDM. The gains that can be expected are marginal, unless the PDM system is implemented in an area where there exist problems. Then the structure of a PDM system can bring order into the area, thereby proving to be very helpful. To fully utilize the PDM system changes must be made to the organization and work processes that the system is supposed to support. It is essential to have a sound knowledge of which processes that exists, and how they best can be implemented to make the workflow section of the PDM system work. Methods in the BPR (Business Process Re-engineering) area can often be helpful. Davenport (1990) presents a framework to analyse and improve processes. This can be helpful when building the workflow section of the PDM system, since it will affect both the work tasks and the work organization. Some benefits of having an effective PD process are shown by Sobek and Ward (1996). 3.3 Width of change Another area of interest is the implementation of the actual PDM system. Should it first be introduced in a pilot project, which gives a small with of change, or is it better to introduce it company wide? Both approaches have their own advantages and disadvantages. With a pilot project, the PDM system will be implemented within

just one engineering project in the company. In this project, all participants will work with the PDM system. Some companies choose to run the pilot with dummy data in a test environment. Others choose to do the pilot with “sharp” data in an actual product development project. This approach is more risky, but will fully test the PDM system. The pilot project gives the company a chance to try out the new technology and adjust it to their special need. A pilot project reduces the overall risk for the company, since only a small part of it is affected of the change. According to Dorfman et al. (1994) a greater percentage of the companies that did a pilot study succeeded with their PDM effort. However, there are some problems inherited in this approach. The PDM system might due to financial or technical reasons not be fully integrated in the company as a start. Thereby the personnel involved in the pilot project will often be forced to work in two parallel systems. Furthermore, necessary changes to the work processes may be hard to implement in the small frame of a pilot project. Company wide introduction of PDM systems can be risky. If problem arise in the implementation phase, the performance of the engineering department may suffer severely. This makes this approach less viable for introduction of the entire PDM functionality, which is very complex and affects many different areas. However, for a small subset of PDM functionality, it can be beneficial since it produces the potential profits faster. It also reduces the problems with parallel systems, providing the users with one work environment. For companies that primarily do large product development projects, like new car models in the automotive industry, it may be necessary to do a company wide introduction of the PDM system which is done by Ford in the C3P project (Werner, 1996). Here there are no small projects suitable for a pilot implementation, and the problem with people working in different environments may not be acceptable. 3.4 Participative or expert driven The PDM implementation project can be participative or expert driven to different degrees. In a participative project the users have a strong role through the entire project. Their knowledge will be utilized to secure a properly working system. Many studies address the importance of early involvement of the actual users of the system (e.g. Attaran, 1996; Hakelius and Sellgren, 1996; Langerveld, 1995; Ries, 1995). Early involvement of users will not only help with ensuring that an appropriate functionality is implemented, but it will also help with the acceptance of the PDM system. Usually, the engineering designers in the company are the people that have the best knowledge of how the PD process actually works. While most companies have a formally defined PD process it is not always followed in the actual day-to-day work. The designers tend to use the parts of the policy that they think will help them in their work. If the company policy is to cumbersome easier ways of working are often developed ad hoc. For a PDM system to have a good chance of being accepted this knowledge of the process needs to be accounted for in the development work. All functions that will be included in the PDM system should have users participating in the development group, a so called cross functional development group. Experts, often consultants, lack this knowledge and can thereby only adapt the PDM systems after the prescribed process.

3.5 Speed of change A fast introduction of the PDM system will reduce the problems with working in multiple systems within the company and will provide the potential benefits of PDM faster. However, this may be risky since PDM still is a relatively young technology that is not entirely fail-safe. The interaction in a software as complex as a PDM system which extensively uses information transfer over computer networks tends to need a lot of attention. It is important to have a clear plan for introducing a PDM system. After the decision to introduce PDM, and before the system can be operational, all users must be trained on the system and know in what aspects of their work the PDM system will provide support. Hands on experience of the system is important for successful implementation. All users need to have the computers and network resources needed for running the PDM system, firewalls and data security rules may make this hard to achieve. To provide training and suitable equipment will take some time. Here the process tends to slow down. Often, some of the problems can not be solved solely within the company, third party expertise is then needed. In the areas of adapting the PDM software to the company processes, communication and transfer protocols between different applications the individual company is usually in the hands of the PDM or other software vendors. Even though the STEP standard may provide a large step forward, there are still some problems involved with getting different applications to share the same data. The process should be completed in a relatively short period of time. Otherwise, the enthusiasm that the users may have felt during the earlier stages of the process will not last long. To ensure that the implementation process stays on track a dedicated PDM pilot manager with solid top management support is needed. 4

INTRODUCTION STRATEGIES FROM A TECHNICAL VIEWPOINT This chapter describes basic introduction strategies when introducing PDM systems in an engineering environment. Three different introduction strategies have been identified based on four case studies in the Swedish industry (Malmqvist and Pikosz, 1996; Hakelius and Sellgren, 1996; Johansson, 1995; Gustafsson, 1994). In order to describe the strategies different complexity levels of the PDM technology are shown in FIGURE 4.

PDM Complexity Level

However, an expert (from within or outside the company) can be helpful in the implementation process. The expert can provide knowledge of how the PDM system interacts with the entire company, that the individual users may lack. He/she can moreover provide the process with the necessary driving force to keep it on track. If the users then are involved early into the process and continue to be involved throughout the process, the results can be good. Nevertheless, the handing over of the PDM implementation process from the project manager to the functional organization can be difficult, especially if it has been driven by someone from outside of the company. It is necessary that the PDM effort still has a strong sponsor within the company that can provide the system with long term support. For example upgrading of the system, inclusion of more PDM functions, refresher training for the users, and training for new users.

Complete lifecycle support Communication with other IT systems Workflow Management

Configuration Management

Data Vault and Document Management

FIGURE 4: PDM Complexity levels 4.1 Project introduction The first introduction strategy is to introduce the PDM system for one development project for which all documentation is stored and managed by the PDM system. The strategy has thus a narrow width of change. This strategy aims at utilizing the PDM system for creating an integrated product and project model and thereby facilitate the exchange of essential information (Ulrich and Eppinger, 1995) for larger or geographically distributed project teams. The integrated product and project model is a good tool to improve the communication within a design team, enabling the support of important early communication in the design process. The complete model is accessible for all project team members and every participant can be up to date with the current project status and the project managerial control is supported. This strategy also gives the design team a fast PDM implementation regarding all complexity levels and a high speed of change. To create a digital data vault and hereby manage the first complexity level, the project begins to store all early project documents (e.g project plans and requirements lists) in a digital form. The second complexity level is reached when the project starts to formalize the breakdown of the product into subsystems and create an integrated product and project model in the PDM system. A need for managing engineering changes evolves when documentation is frozen due to the reaching of a baseline, after which all changes in the documents have to be carried out in accordance with a formal engineering change process. The workflow capabilities can be introduced for the engineering change process in this stage of the implementation process. The third level is to accomplish data exchange with other key IT systems throughout the company. A typical example is to create an interface between PDM and ERP (Enterprise Resource Planning) system or other legacy systems. The reason for such an interface is to enable a smooth data exchange from design to manufacturing. An efficient integration between PDM and ERP is essential for a fast ramp-up of production volumes and the possibility to control customer order based production. The final level is to be able support the complete life cycle for a product from early design to deleting them from the archive. This is accomplished as the development project ends and the responsibility of the product is overtaken by the functional organization. Since all product data is managed by the PDM system it is wise to let the organization keep managing the product within the PDM system.

The complexity of the integrated product and project model grows together with the complexity of the project, which gives a fast evolving complexity of the PDM introduction and a total PDM support can be reached in a short time. This strategy can be used when a high level of change is desired in a PD project. This strategy is regarded to have most potential to support a product development project, but it is also associated with the highest failure risk due to the high and fast evolving complexity level. When using this strategy, the company must verify that the PDM system works for all necessary functions before the introduction, rather than to assume that the functions will work in a latter revision of the PDM software. If the system does not provide the full functionality it will soon become a burden rather than an enabler for the design project. A complete pilot study to verify the system should therefore be performed before the introduction. A combination of a new PD process and a PDM system to cover all functionality aspects will have a dramatic impact on the work methodology. This can be difficult to perform without the participation of the involved PD project members and should therefore be participative rather than expert driven. In many cases, the first design project to use the PDM system will probably be forced to use duplicate archives: the PDM system and the old legacy system. This may require the team members to input the same data twice. This can cause frustration and, if the project is in a hectic phase or if the PDM system does not work properly, the team members will stop using the PDM system in favour of the old legacy system. One way to avoid this situation and reduce the risk of a failure is to make interfaces between the PDM system and the legacy system rather than forcing people to use two separate systems.

relevant, as not all document types will be affected. The meta-data can either be extracted from an old system or created to fit the supported function. Since the engineering change management and product structure management are closely associated (most engineering changes cause a change in the product structure!), a natural second step in the implementation would be to migrate both processes in the PDM system. One further step is then to integrate the PDM and ERP systems. The ERP bases its resource planning on the product structure, which already has been created in the PDM system. An integration would provide a more effective tool for changing product structures and managing variants. The introduction of PDM support for one specific function is associated with a lower risk than the first strategy aiming at a fast overall support. Focusing on one functionality makes it much easier to test and evaluate the system independent from other activities within the company. It is also easier to perform this introduction as an expert driven project although some participation is needed to point out the user needs. The complexity of the introduction is not rapidly evolving as in the first strategy, which gives more time for customizing of the system and a smaller speed of change. Necessary customizing can be done and verified without affecting the continuous work and introduced with a greater certainty of success. The system may further on solve a known problem and motivate the implementation of more PDM support through a “success story”. The support for the integrated product development is limited to the focused functionality, but the benefits in gained efficiency enable a large user acceptance and motivates an increased use of the PDM system focusing on a broader functionality.

4.2 Focus on one PDM function The second strategy is to focus on the introduction of one PDM function, such as engineering change management or configuration management of CAD designed parts, with a certain department (e.g. design department) as target group, which gives a broader width of change than the first strategy. The reason for choosing the “one PDM function” strategy is to support a key functionality or a functionality which can not be efficiently supported with in-house systems and/or where a fast increasing efficiency and user acceptance can be foreseen. A typical example is the engineering change management, where many companies experience long lead time combined with a low will to perform the process amongst the employees due to the tedious routine work. The process is associated with extensive document management activities which makes it suitable for the process support from a PDM system. By performing a BPR before the introduction the level of change is increased. Yet another way of applying this strategy is to introduce the system for linking the CAD created model files to a product structure. This gives an opportunity to manage large CAD assemblies with automatic versioning of the files and structures. The CAD system will, moreover, be closely integrated with the PDM system. Both of these two variants of this introduction strategy are on the second complexity level, since a basic pre-condition is that a database with meta-data exists. However, only a subset of the metadata and the digital documents needed for strategy one will be

4.3 Central archive introduction The third strategy is the support of the company’s central archive and the life-cycle support of documents for all functions within the company, enabling a broad width of change. The main focus in this strategy is to convert paper drawings and digital files into a long term storage format, i.e CCITT group 4, or to replace a legacy document management system within the archive. The first step in this strategy is to convert paper documents to digital format. The document management functionality is used to handle versions and distribution of documents. The second step is to enable a fast access to the documents, which can be done through viewing functionality or using the company intranet. The third step is to enable efficient storage possibilities, directly from different computer tools throughout the company. A design project is here supported by easier viewing of documentation from earlier and running projects and by faster search abilities as well as a faster delivery of archived documentation. Cooperation with suppliers is supported if the suppliers get access to the digital archive and can work with the correct version of documents. The security of the archived documentation is managed by the PDM system, which controls the access permission for each user on each document. This strategy is the least complex (first complexity level) and therefore also the easiest to perform without a failure. One of the reasons is that the PDM functionality for data vault and document management is well developed. The introduction of archive support can be expert driven, since there is less need for user participation

when the requirements can be clearly specified before the implementation. The expert can customize the system “off-line” and introduce it when the functionality has been verified. The potential to support the integrated product development is lower than in the other strategies, but a digital archive gives an overall company support through the faster access to archived documents. The level of change using this strategy is fairly low. The creation of a digital archive serves as a good base for future implementation of more complex PDM functionality. After the digital archive has been created it can be used as a foundation for further developments, e.g., local archives for each product development team, followed by an extension to higher complexity levels. Yet another extension is to let the archive system manage engineering changes of the archived documents. 5

CASE STUDIES This chapter presents case studies of PDM projects using the different introduction strategies. Two of the studies have been conducted by the authors and one is taken from the literature (Wall, 1996). 5.1 Project introduction A PDM implementation project that has utilized the first strategy has been followed by the authors. The company that chose this approach manufactures electro-mechanical products. The company’s products are complex and require much documentation. The life-cycle of the products are long: spare parts need to be available at least 20 years. This results in severe requirements on configuration and document management. The company was early in realizing the potential of PDM systems to support these processes, and when commercial PDM systems became available decided to acquire a system. The company’s requirements list for the PDM system emphasized vendor capabilities, system stability and response times. It was also required that the system should be based on the object-oriented paradigm and be easy to integrate with existing CAD systems and word processors. The system should further be easy to customize and upgrade. Several systems were evaluated, and one was chosen, the decisive reason being its tight integration with the CAD system used at the company. A demo PDM application was then implemented in a workstation environment. The demo was successful, and it was decided that the PDM system was ready for use in a “sharp” product development (PD) project. The project-based implementation strategy was chosen, the aim being to introduce the PDM functionalities as they were needed in the time schedule of the PD project, starting with document management, followed by product structure management (including communication with a legacy system) and, finally, workflows like processing on engineering change orders. This would enable a fast introduction of all the functionalities of the PDM system and, hence, obtain the high-level PDM benefits. Moreover, it was desired to identify the most difficult elements of a PDM implementation project. In order to do this, a test of the full functionality in a reasonably large setting was needed. The PD project selected for the implementation was a small project, involving during its duration of 18 months some 15-20 people, with an average of 5 people full-time. The participants were given

training and the PD project was allotted time to compensate for the extra work that the PDM system might initially require. However, soon after the PD project start it became evident that the PDM system was not used to the extent hoped for. Several factors played a part in this: • The response times of the system were too slow. This was serious as this was the users most highly prioritized requirement on the system. The root cause of the slow response times was further difficult to find, the configuration of the network and database servers needed to be reconsidered. The time needed for that diagnosis resulted in that the product data generated early in the PD project was not input into the PDM system. This, in turn, made it difficult to continue with the chosen implementation strategy, as the use of product structure management and workflows needed that information to exist in the system. • The PD project involved a high percentage of secret documents. These were not allowed to be available on-line, only references to the documents were stored in the PDM system. The consequence was that the PDM system for these documents did not store more information than the existing legacy systems, providing little motivation for the users to input the information in both databases. • The computer skills of the users varied. While all were computer users, not all were connected to the company network at the start of the project, implying little experience in basic communication functions such as e-mail. • The use of the PDM system was not “forced” by the PD project leader. The time schedule of the PD project was given first priority and the users were given the choice to use the PDM system if they considered it worthwhile. This tendency was further emphasized, when the initial PD project leader was replaced during the course of the project. To catch up, the replacement project leader then needed to focus on the development task of the PD project. In summary, the company did not reach its (high) goals, the root cause primarily being the slow response times. The company continues its PDM implementation, however, with a different approach: It is now focusing on document management (necessary due to the planned phase-out of a legacy system) and on management of product structures in the CAD system (a part of the PDM system that worked well). This approach is a variant of strategy 2 described in section 4.2. 5.2 Focus on one PDM function SAAB Military Aircraft used this strategy to improve their engineering change management process (Wall, 1996). SAAB started to investigate PDM solutions in 1988, in the framework of their CIM (Computer Integrated Manufacturing) program. Annell (1995) states that it was the growing numbers of engineering change orders in SAAB’s increasingly more complex airplane development projects that made them implement PDM. Since they, at the time, had problems managing the engineering change order process they chose to first implement the change order management part of the PDM paradigm. SAAB’s vision was to:

• Store all product data at one place, all personnel can thereby use the same data. • The company should have agreed on the definitions linked to the PDM system to avoid misunderstandings. • The equipment at the workplace should make it possible to reach the PDM system instead of using a special computer located somewhere else. • The user interface should make it possible for the users to access the information without knowing the exact name and location of the document or file. • The system should work with product oriented objects, rather than with documents.

documents and drawings into CCITT group 4, which is considered to be the most standardized bitmap format. A PDM system was selected to manage the documents within the archive, with the following functional requirements: 1. Automatic print and distribution in accordance to distribution lists when a new document version is stored in the archive. 2. Enable viewing and print-on-demand to users through the company network. 3. Enable storage into the archive directly from applications such as CAD systems and word processors. 4. Manage engineering changes on documents in the digital archive.

With this installation SAAB focused on small area where they experienced problems, where they implemented a small subset of PDM. The level of change was relatively low at the start, only the engineering change order process was affected. SAAB made an pilot with dummy data to test if the then new PDM technology could solve their problems. After a fairly successful pilot study, the PDM system took control of the engineering change process for a part of the engineering department. A high gain in efficiency of the engineering change management was obtained (Wall, 1996). The company is currently increasing the number of users as the system is introduced to the whole design department. The PDM project had user involvement in the framework of the larger CIM program that SAAB was currently working with. As a large engineering company, SAAB had the resources required to implement most of the PDM system in-house. The actual change in system for the engineering change management was fairly quick. Since SAAB focused on an orderly well controlled process, only meta-data was used. That reduced the complexity of handling big data transfer between different archives and users. The system was also well tested and could take over handling of the engineering change management from the previous manual system already from the start. This strategy tends to give very good results since it provides the companies with a solution that was not available earlier. The company can then, if it has good experiences of the PDM system, chose to continue their support of the new product development process with more parts in the PDM concept.

In order to minimize the scanning, only documents that are requested are scanned. The next step was to automate print and distribution and thereby extending the implementation to the second complexity level in FIGURE 4. The company is currently working on the second and third goals above. The level of change is quite low for this specific case. The employees still have to order a document and wait for the internal post to deliver it until the print and view-on-demand functionalities will work. There are no large impacts on the PD process due to the PDM introduction. The width of change is however broad. All new functionality is instantly made available for the entire company after test. The introduction in the archive made it possible to fully customize and try out the system without disturbing the continuous work in the company, which was considered to be an advantage. Each functionality was carefully tested before the sharp introduction, The introduction was mainly expert driven by the vendor company, which was possible in this case due to fact that the companys demands were clear and simple, no deeper process knowledge was needed and the company had no expertise in the PDM area.

5.3 Central archive introduction A PDM introduction in accordance to the third strategy, see section 4.3, was also studied by the authors. The company has a large paper-based archive. Each year, the archive distributes approximately 2.5 million document pages and handles 1,500 change requests to archived documents. The maximum time for document delivery is today set to 10 days, but the goal is set to a maximum of 2 days. In the same time an increasing amount of data is created in computer systems and stored digitally in local archives, which amplifies the need for a digital archive. The company has high internal and external demands on the quality of documents in the archive. The requirement from customers is set to 40 years, but the oldest documents in the archive date from the 19th century! It was therefore important to find a digital format that they will be able to view in a longer time span. The first step towards the completeness of vision was to create digital data vault. This was done by scanning and converting text

5.4 Summary Case studies in the Swedish industry show that most companies start with strategy two or three. The different strategies are summarized in FIGURE 5. The figure shows a common situation in a Swedish engineering company, where different design projects (Project A, B and C) are running in parallel using one data archive for the long time storage of documents. A PDM introduction in accordance with strategy one focuses on supporting one project, for example Project A, by integrating its computer tools and workflows in the most effective way possible. The second strategy focuses on maximum support for one aspect in all projects, which is illustrated by the thick black line in each project. The third strategy is focused on supporting many different projects on a long time basis by providing an easy access to the main document archive. In order to accomplish an efficient support using the first two strategies, system specific digital formats are used to store data and integrate computer tools. To accomplish the long time support of the third strategy a standard format, often based on pixel representation (e.g. CCITT group 4), is used to store data.

Strategy 1 Project A Data exchange Project B Archive Project C Strategy 3

Strategy 2

FIGURE 5: Overview of the different strategies 6

SUCCESS FACTORS AND PITFALLS The purpose of this chapter is to identify success factors and pitfalls associated with a PDM introduction. Many of the known critical success factors for projects in general (Meredith and Mantel, 1995) are essential also for the implementation of PDM systems, but we will here focus on aspects that are often forgotten or omitted in rush for a fast implementation process. We will also point out some specific risk areas linked to the PDM technology. A PDM introduction is often seen as any other introduction of a new computer system. This is however not true. A PDM system is more complex than most other computer systems (e.g. CAD systems, e-mail, simulation software), thus it demands more attention and work before, during and after the introduction. Some PDM specific topics are: • The PDM system must be able to work over different computer platforms (e.g. Unix, PC). • PDM is information intensive, which sets large requirements on the IT infrastructure. • PDM tries to integrate people from different departments and with different tasks. • The computer maturity varies strongly amongst users. PDM systems are not off-the-shelf products, they need to be customized to cover company needs. Before the purchase and the customizing of the PDM system, a prestudy that defines the company requirements and expectations should be performed. The prestudy can be used to identify key issues and expected difficulties. A pilot project using the PDM system before the actual introduction should be performed to verify that the system meets the requirements set in the prestudy (Hakelius and Sellgren, 1996). Dorfman et. al. (1994) noted that companies that first perform a prestudy obtain better results when introducing PDM. In the case of the second and third strategy, it is relatively easy to set up a pilot implementation, with a limited amount of data and users and use it as a demo system when the pilot implementation is completed. The pilot is used to evaluate if the system gives the proper support and whether it can be implemented on a full scale or not. The demo system can be used to show the system to future users in order to gain acceptance and to get feed back on how it should be improved.

The first strategy to introduce a PDM system requires that the complete functionality is available. If the system does not support some stage of the fast evolving complexity, it will cause delays in the PD process and in the implementation process. In worst case, the design project might be forced to change back to the old data management systems causing not only a project delay but also a substantial credibility loss for future PDM implementations. The amount of classified information is also of importance when introducing a PDM system according to the first strategy. Not having access to all information deteriorates the basic idea of the integrated product model, and forces team members to store information in two separate archives depending on whether the information is secret or not. It is important that the team members always see that they get benefits rather than increased work from the PDM system. A very important issue when introducing a new system is that the systems works properly without major disturbances. Some companies have difficulties with unstable systems and long response times, reflecting the maturity level of PDM systems In order to minimize the risk every company that introduces a PDM system should check that the IT infrastructure (e.g. hardware and network) has the capability of supporting the increased amount of communication. The system should be verified in a realistic company environment and not only in perfect vendor demo conditions. The company should improve the processes associated with the product development before the PDM introduction. It is possible to implement PDM over an already existing product development process, although doing this will not fully utilize the new information technology. One success factor, regardless which implementation strategy to be used, is to re-engineer the PD process in co-operation with the users to completely utilize PDM. Kay and Madden (1995) stress the need for understanding the processes and user needs. They propose cross functional groups early in the PDM implementation project to ensure proper processes. On the other hand, an adoption of a standard process from the PDM vendor can be sufficient to improve the process significantly and at the same time minimize customization and maintenance. It is very important that the users take part in the entire planning and implementation process (Ries, 1995; Langerveld, 1995), reporting experiences from implementation projects at their companies. Thereby the users knowledge of the PD process can be implemented in the PDM system. Moreover, early involvement of the users in the process will help with acceptance and usage of the system. The users must perceive the PDM system as beneficial to their own work. It is not enough that the company can argue benefits in later parts of the production chain. The importance of top management support can not be emphasized enough and it is also identified as a critical barrier for the introduction of a company wide system (Attaran, 1996). It is absolutely vital that the PDM project has a sponsor in, and support from the rest of the top management in the company. The manager of the PDM implementation project also needs to have a good position in the company. The term “heavy-weight” (Ulrich and Eppinger, 1995) is often used for this kind of person. Continuity in the PDM project management is important. Changes in the personnel, vision or leadership of the project are likely to be harmful for the outcome of the project.

7

CONCLUSIONS Many companies are investigating the introduction of a PDM system. However, some of them have not realized the complexity of the task. Most introduction projects have focused on the technical aspects omitting the organizational context related to the management of product data. Thorough attention needs to be put on the five dimensions: focus, level of change, width of change, participative or expert driven and speed of change. After evaluation of these factors a suitable introduction strategy can be selected. Three common introduction strategies are: project introduction, focus on one PDM function and central archive introduction. In the planning process it is important to consider future introduction of additional PDM functionality, thereby the introduced PDM functionality can act as a foundation for further additions of functionality. A well defined vision helps in this work. When the introduction plan is decided, an amount of work with customizing and training can be foreseen. In order to succeed with the PDM introduction, both top-management support and user involvement are essential. Acknowledgements This work was financially supported by the Swedish National Board for Technical Development. This support is gratefully acknowledged. REFERENCES Annell, M. Private communication, SAAB Military Aircraft, Linköping, Sweden, 1995. Attaran, M. Barriers to Effective CIM Implementation, Information Systems Management, pp. 52-56, Fall 1996 Carl, E. J. and Judd, J. L., Bridging Product Data Management Systems for Effective Enterprise Integration, Industrial Engineering, pp. 18-21, 1994. Cederbaum, J. Private communication, Ericsson Components, Stockholm, Sweden, 1996. CIMdata, Product Data Management: The Definition, CIMdata, Ann Arbor, MI, USA, 1995. Davenport, Thomas H. The New Industrial Engineering: Information Technology and Business Process Redesign, Sloan Management Review, 31(4): 11-27, Cambridge, MA, USA, 1990. Dorfman, J., MacKrell, J., Miller, E. and Romzick, P. PDM Implementation Survey Report. CIMdata, Ann Arbor, MI, USA, 1994. Hakelius, C. and Sellgren, U. PDM projects in Swedish industry - experiences from six engineering and manufacturing companies, Report MANDECO project, Dept of Machine Design, Royal Institute of Technology, Stockholm, Sweden, 1996. van den Hamer, P. and Lepoeter, K. Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data. Transactions of the IEEE, 84(1): 42-56, 1996. Harris, S. B. Business stategy and the role of engineering product data management: a litterature review and summary of the emerging research questions, Proceedings of the Institution of Mechanical Engineers: Part B: Journal of Engineering Manufacturing, 210: 207-220, 1996.

Gustafsson, I. Generella produktdatasystem i verkstadsföretag. (General product data management systems in engineering companies) Faktarapport, Sveriges Verkstadsindustrier, Stockholm, Sweden, 1994. (In Swedish) Johansson, J. Enabling competitive advantage through PDM - an Ericsson perspective. Proceedings PDM Europe’95, Noordwijk, The Netherlands, 1995. Johansson, G. Hur har PDM påverkat produktutvecklingen? (The effects of PDM on product development), IVF-skrift 95813, IVF, Göteborg, Sweden 1995. (In Swedish) Kay, C. and Madden D. Critical Success Factors in Implementing Product Data Management. International Journal of Micrographics & Optical Technology, 13(4): 191-194, 1995. Kling, H. Private communication, CelsiusTech Electronics, Järfälla, Sweden, 1997. Langerveld, S. Implementation: Centralized Document Management, Proceedings PDM Europe’95, Noordwijk, The Netherlands, 1995. Malmqvist J. and Pikosz, P. Koppling mellan produktutvecklingsmodell, produktdokumentation och PDMsystem (Linking product development model, product documentation and PDM systems), Report PDM2000 project, Machine and Vehicle Design, Chalmers University of Technology, Göteborg, Sweden, 1996. (In Swedish) Menon, J. och Horn, W. Virtual Prototyping of Product Structure in Product Data Management. Proceedings of ASME Design Engineering Technical Conference and Computers in Engineering Conference, Paper No. 96-DETC/DFM-1304, Irvine, CA, USA, 1996. Meredith, J. R. and Mantel, S. J. Project management: A Managerial Approach. Wiley & Sons, New York, 1995. Pikosz, P. Ändringshantering i tre svenska verkstadsföretag (Engineering Change Management in three Swedish Engineering Companies), Report PDM2000 project, Machine and Vehicle Design, Chalmers University of Technology, Göteborg, Sweden, 1997. (In Swedish) Pikosz P. and Malmqvist J. Possibilities and Limitations when Introducing PDM Systems to Support the Product Development Process, Proceedings NordDesign’96, pp 165-175, Espoo, Finland, 1996. (http://www.mvd.chalmers.se/publications/pub_list.html) Ries, R. C. PDM Pilot Experiences, Proceedings PDM Europe’95, Noordwijk, The Netherlands, 1995. Sobek, D. K. and Ward, A. C. Principles from Toyotas Set-based Concurrent Engineering Process, Proceedings of ASME Design Engineering Technical Conference and Computers in Engineering Conference, Paper No. 96-DETC/DTM-1510, Irvine, CA, USA, 1996. Ulrich, K. T. and Eppinger, S. D. Product Design and Development, McGraw-Hill, New York, 1995. Wall, H. PDM-erfarenheter på Saab (PDM experiences at Saab), Proceedings Produktmodeller’96, pp 405-419, Linköping, Sweden, 1996. (In Swedish) Werner, K. Val och implementering av PDM-system, erfarenheter från USA (Selection and implementation of PDM systems, experiences from the USA). Proceedings Produktmodeller’96, pp 71-81, Linköping, Sweden, 1996. (In Swedish)