Product Data Management (PDM)


www.johnstark.com












Benefits of PDM (Part 1 of 5)


At first sight, EDM/PDM systems may just appear to be the answer to the fairly well defined problem of how to manage large numbers of CAD/CAM files. However, further examination shows that this is not so. EDM/PDM systems respond to a large number of complex and currently unresolved issues that are all related to the problems of managing engineering information and engineering processes. Some of these issues appear as business problems, some at the level of the engineering function. Some are management problems and some are very closely related to engineering data itself. The problems can be grouped, from the technical viewpoint, into ten major categories.

Diversity and volume of data
The sheer volume of data, and the diversity of its physical support media, make engineering data difficult to manage. There is clearly sufficient difference between data on traditional media, such as paper, and data on electronic media, such as an optical disk, for them to require different management techniques. However there are also great differences between the various traditional media such as paper and aperture cards. Similarly, due to the diversity of computers, operating systems, storage devices and storage techniques, there are many differences between the various electronic media.

Computers have been used in the engineering environment for nearly fifty years. Numerical control of machines has been applied for over forty years. The earliest attempts at what is now known as CAD/CAM took place about forty thirty years ago. It could seem surprising that it is only now, in the 2000's, that the need for Engineering Data Management is really becoming apparent. However, the earliest applications of computers in the engineering environment were point solutions, creating 'Islands of Automation'. Self-management was possible on small isolated islands. While an island remained small enough, the amount of data it required and generated could be managed manually. It was only towards the end of the 1980's, as the number of islands grew, and individual islands became much larger, that the data management problem really became apparent.

Since the creation of files ranging from 50 KB up to 1 MB, or even 10 MB, only requires a few seconds, it does not take long, even in small companies with only a few users of computer-based engineering data, for manual data management techniques to break down. Users will not be able to find data. Data will not be secure. In larger companies, with several hundred engineers, many Gigabytes or even Terabytes of data may be created and accessed each week, and the problem is far worse.

The volume of data in the engineering environment is of itself a problem. Estimates for medium-to-large companies foresee data volumes far exceeding 1 million GB. There is currently no single electronic storage device that can handle such a volume of information. Of necessity, therefore, data will be stored in several locations. It will be difficult for a user to know where to store data. In what format should it be stored? What level of security will be appropriate? How will a user be able to find out where data was stored in the past? How will a user be able to find out which format was used to store it?

A company's engineering data represents its collective know-how. As such it is a major asset and should be used as profitably as possible. Too many companies ignore their engineering data. If $100,000 goes astray in their financial systems, there is a major panic. If $10,000,000 goes astray in their engineering systems, there is generally no panic at all, since most people in the company are completely unaware of the loss. Many managers find it difficult to put a value on their engineering data. Top management, in particular, is rarely aware of the extent to which valuable data is ignored and misused.

The scope of engineering data is wide. There are various types of data. There is text data (specifications, schedules, process plans, manuals, project plans), numeric data (descriptive geometry, formulae, results of analytic experiments and calculations, computer programs), graphics data (photographs, drawings, sketches) and voice data. Within each of these types of data, there may be differences. Among the computer programs that need to be managed are both those that are linked to products (programs developed to be used within the company's products), and those that are linked to processes (programs such as ERP and CAD/CAM that support the company's operations). Some of the graphics will be in vector form, some will be in raster form.

Data is processed in many ways. The best way for processing and managing any one of the different types of data will not be the best way of processing and managing another. If users want optimum performance, they will suffer from not having a common approach. If they prefer a common approach, they will not have optimum performance.

Many different computer programs are used in the engineering environment. They create and work with engineering data in different ways. In addition to the previously mentioned CAD/CAM and NC systems, there are finite element analysis, aerodynamic analysis, process planning, technical publishing, word processing, test, and many other types of system. Each one of these will probably be an Island of Automation, with its own specific approach to data management. Each will primarily address the function it is supposed to perform, such as geometry definition, with data management being a secondary (and ineffectively implemented) function.

To process data, the engineering function will be using computers of different sizes and from different vendors. There may be a supercomputer and one or more mainframes. There will be many minicomputers and microcomputers. There will be a variety of Personal Computers and Engineering Workstations. There will be some graphics terminals without significant computing power. Some of the computers will be linked together on one network. Others will be linked together on other networks. Some will be stand-alone. The hardware alone may come from five, ten, twenty or even fifty vendors.

The computers will run under a variety of operating systems. Some of these will be proprietary, i.e. not standardized. Others will, in principle, conform to a standard, such as UNIX. However, even those that are, in principle, standardized may have minor differences, particularly between different versions and releases.

A multi-user, multi-organization environment
Engineering data will be used by many people. These people may be in different functions and locations of a company. They may be outside the company. They may be working for a supplier, a partner, or they may even be the final customer of the company's product. Data has to be made available to all these people. At the same time, data must be protected against unauthorized access.

There will be many users of data. A given piece of information may be created by a design engineer, analyzed by another engineer, drafted by someone else, checked by a supervisor, and scrutinized by a manufacturing engineer even before it is accepted as potentially useful. These people may be in the same building, or in the same plant, but they could also be in locations in different countries, or even on different continents.

Data will be spread between different organizations. Clearly, a lot of information will be created in the Engineering organization, but information will also be created and used in the Manufacturing, Marketing, Finance, Sales and Maintenance organizations. Some of the data will probably be with the design engineer. Some will be with the manufacturing engineer. Some will probably be with the IS Department that looks after the ERP program. Some data will be on the shop floor. Some will be with the customer.

Traditionally it has been made clear, through organization charts, which human resources belonged to which part of a company's organization. It has been less clear which information belonged to which part of a company's organization. Even within a particular part of the organization, such as Engineering, it has not been clear who are really the owners of information.

Users will be working on a variety of tasks. Depending on what they are doing, and their level of computer literacy, they will have different data usage and data management needs. Some will create data, and some will modify it. Others will only want to reference existing data. Some of the users will be working with advanced concepts such as the creation of data that will help take Man out of the Solar System. Others will need data to help them solve more down-to-earth problems like finishing a part before the shift ends.

Different users will want to see different views of the data. They will want to see the view that is of interest to them. While the view of data that users may want to see is different, and the systems they use may be different, the underlying data must be the same.

While it is true that different users will have different requirements of a data management system, it is clear that they will also have some common requirements. For example, they may all want to make use of the same basic spreadsheet, text processing and electronic mail systems.

At the level of the data itself, there is a need to provide better security, control, access and protection. Although data is so valuable, it is often very easy for users to mistakenly destroy, or lose sight of data. The need to provide full protection of data has to be addressed alongside the need to make data available. At different times in the product life cycle, data should have different levels of protection. Until a design is released, a design engineer may be free to modify it. After release, manufacturing engineers should not be allowed to make 'improvements' without following the correct procedures. At times, the situation will be complicated by the need to share data among several users each of whom has different access rights

It is difficult for users to access data that is not readily available, and rather than searching and waiting for it, they may prefer to ignore it or re-create it. For example, designers rarely have easy access to product cost data in ERP systems and product quality data in field support systems.






Home | Top of page | Front of Product Data Management (PDM) section


Page last modified on March 3, 2000
Copyright 2000 by John Stark