PDM introduction. Very very good material

fatdong

PDM in Brief
The Challenge is to maximize the time-to-market benefits of concurrent engineering while maintaining control of your data and distributing it automatically to the people who need it - when they need it. The way PDM systems cope with this challenge is that master data is held only once in a secure 'vault' where its integrity can be assured and all changes to it monitored, controlled and recorded.  
Duplicate reference copies of the master data, on the other hand, can be distributed freely, to users in various departments for design, analysis and approval. The new data is then released back into the vault. When a 'change' is made to data, what actually happens is that a modified copy of the data, signed and dated, is stored in the vault alongside the old data which remains in its original form as permanent record.  
  
This is the simple principle behind more advanced PDM systems. To understand it more fully, let us look separately at how these systems control raw product data (Data Management and Process Management).  
  
What is Data Management?
Manufacturing companies are usually good at systematically recording component and assembly drawings, but often do not keep comprehensive records of attributes such as 'size', 'weight', 'where used' etc. As a result, engineers often have problems accessing the information they need. This leaves an unfortunate gap in their ability to manage their product data effectively. Data management systems should be able to manage both attribute and documentary product data, as well as relationships between them, through a relational database system.  
With so much data being generated, a technique to classify this information easily and quickly needs to be established.  
  
Classification should be a fundamental capability of a PDM system. Information of similar types should be capable of being grouped together in named classes. More detailed classification would be possible by using 'attributes' to describe the essential characteristics of each component in a given class.  
  
Classification of Components
Components will be entered in the database under a variety of classes which suit your business needs. Classes themselves can be grouped together under convenient broad headings. This allows all your company's working stock of components to be organized in an easily traceable hierarchical network structure. Each part can be given its own set of attributes. Additionally, some systems allow you to register that certain components are available with specific 'optional' attributes. This can be invaluable in controlling Bills Of Materials (BOMs) for reasons that we will deal with in the chapter headed 'Evaluating Systems for Process and Management'.  
  
Classification of Documents
Documents relating to components and assemblies can be similarly classified; for example, classes might be 'drawings', '3D models', 'Technical publications', 'Spread Sheet Files', etc. Each document can have its set of attributes - part, number, author, date entered. And, at the same time relationships between documents and the components themselves can be maintained. So, for example, a dossier for a specific 'bearing assembly' could be extracted, containing 2D drawings, solid models, and FEA files.  
PDM systems vary greatly in their classification capability. Some have none. Others support the ability to define a classification only at the time when the database is implemented. More recent PDM systems have provided a capability that can be defined and modified at will as the demands of the organization change.  
  
Product Structure
The third way product data can be accessed is by product structure. For any selected product, the relationship between its component assemblies and between the parts that make up these assemblies should be maintained. This would mean that you could open a complete Bill of Materials, including documents and parts, either for the entire product or selected assemblies. One distinct advantage is the ability to hold not just the physical relationships between parts in an assembly but also other kinds of structures; for instance, manufacturing, financial, maintenance or document relationships. So, it is possible for specialist team members to see the product structured from their point of view.  
  
Querying the Data
As you can imagine, you need to be able to 'get at' the components and assembly data by a variety of routes. You could move up and down a classification tree; pick your way through a product structure; simply call-up the data you want by searching for it by name or part number, or search for groups of data by specifying an attribute or combination of attributes. For example, you could ask to see all stainless steel rivets with anodized shanks less than 10mm long.  
  
What is Process Management?
So far we have dealt only with organizing data so that it is easy to access, refer to and cross-reference; basically passive procedures. Process management, on the other hand, is about controlling the way people create and modify data - active procedures.  
This may sound like just a new name for 'project management'. It is not. Project management concerns itself only with the delegation of tasks; process management addresses the impact of tasks on data.  
  
Process management systems normally have three broad functions:  
  
They manage what happens to the data when someone works on it. ('Work Management'.)  
  
They manage the flow of data between people. ('Workflow Management'.)  
  
They keep track of all the events and movements that happen in functions 1 and 2 during the history of a project. ('Work History Management'.)  
  
PDM systems vary widely in how they perform these functions. The following is a broad overview.  
  
Work Management
Engineers create and change data for a living. The act of designing something is exactly that. A solid model, for example, may go through hundreds of design changes during the course of develOPMent, each involving far-reaching modifications to the underlying engineering data. Often the engineer will wish simply to explore a particular approach, later abandoning it in favor of a previous version.  
A PDM system offers a solution by acting as the engineer's working environment, meticulously capturing all new and changed data as it is generated, maintaining a record of which version it is, recalling it on demand and effectively keeping track of the engineer's every move.  
  
Of course, when an engineer is asked to carry out a design modification, he or she will normally require more than just the original design and the Engineering Change Order (ECO). Many documents, files and forms may need to be referred to and other members of the design team involved, too. In a traditional design environment you would compile a project folder or dossier which the team could refer to as needed.  
  
Current PDM systems cope with this requirement with varying degrees of success. One approach is that which emulates paper-based processes by using what are known as 'user packets'.  
  
The packet allows the engineer to manage and modify several different master documents simultaneously as well as providing various supporting documents for reference. This approach also supports the concurrent engineering principle. For example, although only one user can be working on a 'master' design, colleagues working on the same project can be instantly notified that there is an updated master design, and reference copies of it will be made available to them in their own packets. A given packet can be worked on only by the user to whom it is logged out, but its contents can be looked at and copied by everybody with the necessary access permissions.  
  
Workflow Management
Packets have the advantage of making it easy for team members to share meaningful groups of documents, but they are useful for another reason, too. They make it possible to move work around from department to department, or from individual to individual in logically organized bundles.  
During the development of a product many thousands of parts may need to be designed. For each part, files need to be created, modified, viewed, checked and approved by many different people, perhaps several times over. What's more, each part will call for different development techniques and different types of data - solid models for some, circuit diagrams for others, FEA data for others.  
  
As if this is not confusing enough, work on any of these master files will have a potential impact on other related files. So there needs to be continuous cross checking, modification, resubmission and rechecking. With all these overlapping changes, it is all too easy for an engineer in one discipline to be investing considerable time and effort in pursuing a design which has already been invalidated by the work someone else has done in another part of the project. Bringing order to this highly complex workflow is what product data management systems do best. In particular they keep track of the thousands of individual decisions that determine who does what next.  
  
Most PDM systems allow the project leader to control the progress of the project via 'states' using pre-determined 'triggers' and a routing list which may vary according to what type of organization or development project is involved. The way systems differ is in how much flexibility they permit within the framework discipline. The most rigid systems are based on procedures. Every individual or group of individuals is made to represent a state in a procedure - 'Initiated', 'Submitted', 'Checked', 'Approved', 'Released'; a file or record can't move from one individual or group to the next without changing states. Some systems make it possible to give the task an identity of its own, separate from the people working on it.  
  
For example, suppose an engineer working on a design wants to confer with colleagues as to the best way to approach the design. So long as the master model and all the associated reference files are contained in and controlled by a packet, then it is simple to pass the entire job across to any number of other people without triggering a change of state. The formal workflow procedure is uncompromised by this informal re-routing because the authority to change the file's state doesn't move around with the packet. It remains with the designated individual.  
  
Communication within the development team is enhanced too. When packets of data and files are passed around, they can be accompanied by instructions, notes and comments. Some systems have 'redlining' capability; others even have provision for informally annotating files with the electronic equivalent of 'post-it' notes.  
  
In other words, a process management system could be seen as a way of 'loosening up' your working environment, instead of constraining it. The challenge is how far you can allow informal teamwork and cross-fertilization to carry on and still keep overall management control of project costs and deadlines?  
  
Most systems allow the up-to-date status of the entire task, with all supporting data, to be tracked and viewed by authorized individuals at all times.  
  
Of course, a packet represents one task in a product development project which may consist of many thousands. Each packet follows its own route through the system but the relationship between packets also needs to be controlled.  
  
To coordinate such a complex workflow effectively you need to be able to define the interdependence of tasks so as to match the way your individual project is structured. Not all systems are easy to customize in this way. The ones that are have the ability to create a hierarchical relationship between files. For example, you could instruct the system to prevent an engineer from signing off an assembly for release until all its parts have been individually released.  
  
Work History Management
As we have seen, product data management systems should not just keep comprehensive database records of the current state of the project, they should also record the states the project has been through. This means that they are a potentially valuable source of audit trial data. The ability to perform regular process audits is a fundamental requirement for conformance to international quality management standards such as ISO9000, EN29000 and BS5750. But project history management is also important to allow you to 'back-track' to specific points in a project's development where a problem arose, or from which you may wish to now start a new line of development.  
What specific development milestones the system records is important. Some systems record only the changes in ownership of documents. So ownership can be traced at a specific point in time, but not the modification itself. Others have the ability to record changes but may do so as a series of 'snap-shots' taken only when a file changes 'state'. This can leave large gaps in workflow history as a user may have been making modifications to a design for several weeks without any change to its state. Some systems provide an historic record which is like a 'moving picture' by allowing you to record changes to any system-defined level you choose - for example, every time a modified file is saved.  
  
This level of historical tracking, as well as providing comprehensive auditing, also permits the active monitoring of individual performance - invaluable during time-critical projects.  
  
What are the Benefits?
Reduced Time-to-Market
This is the major benefit of a PDM system. Three factors serve to place limits on the speed with which you can bring a product to market. One is the time it takes to perform tasks, such as engineering design, and tooling. Another is the time wasted between tasks, as when a released design sits in a production engineer's in-tray waiting its turn to be dealt with. And the third is time lost in rework.  
A PDM system can do much to reduce all these time limitations.  
  
It can speed up tasks by making data instantly available as it is needed.  
  
It supports concurrent task management.  
  
It allows authorized team members access to all relevant data, all the time, with the assurance that it is always the latest version.  
  
Improved Design Productivity
Product Data Management systems, when driving the appropriate tools, can significantly increase the productivity of your engineers.  
With a PDM system providing them with the correct tools to access this data efficiently, the design process itself can be dramatically shortened.  
  
Another factor is that designers should spend more time actually designing. Historically a design engineer would spend as much as 25-30% of his time simply handling information; looking for it, retrieving it, waiting for copies of drawings, archiving new data. PDM removes this dead time almost entirely. The designer no longer needs to know where to look for released designs or other data, it is all there on demand.  
  
A third major time saver is the elimination of the 'reinvented wheel' syndrome. The amount of time designers spend solving problems that have probably been solved before, is notorious. It is often considered quicker to so it again than to track down design elements that could be re-used. With a PDM system, however, the identification, re-use and modification of existing similar designs should become routine.  
  
Improved Design and Manufacturing Accuracy
An important benefit of PDM systems is that everyone involved in a project is operating on the same set of data which is always up to date. If you are working on a master file you know it is the only one; if you're viewing a reference copy, you know it is a replica of the latest master. So overlapping or inconsistent designs are eliminated - even when people are operating concurrently. Naturally this leads to far fewer instances of design problems that only emerge at manufacturing or QA, fewer ECOs, more right-the-first-time designs and, once again, a faster path to the marketplace.  
  
Better use of Creative Team Skills
Designers are often conservative in their approach to problem solving for no other reason than the time penalties for exploring alternative solutions are so high. The risks of spending excessive time on a radically new design approach which may not work would be unacceptable. PDM opens up the creative process in three important ways.  
  
First, it keeps track of all the documents and test results relating to a given product change, minimizing design rework and potential design mistakes.  
  
Second, it reduces the risk of failure by sharing the risk with others and by making the data available to the right people fast.  
  
Third, it encourages team problem solving by allowing individuals to bounce ideas off each other using the packet-transfer facility, knowing that all of them are looking at the same problem.  
  
Comfortable to Use
Although PDM systems vary widely in their levels of user-friendliness, most set out to operate within the existing organizational structure of a product engineering operation, without major disruption. The system should, in fact, make familiar tasks much more user-oriented than before. When users wish to view information on a PDM system, the application is loaded automatically, and then the document is loaded. In a conventional working environment, users would either have to be much more skilled at accessing the information or be prepared to accept it in a much less flexible form.  
  
Data Integrity Safeguarded
The single central vault concept ensures that, while data is immediately accessible to those who need it, all master documents and records of historical change remain absolutely accurate and secure.  
  
Better Control of Projects
The reason that product development projects are almost invariably late is not that they are badly planned in the first place, but that they routinely go out of control. Why? Because the immense volume of data generated by the project rapidly snowballs beyond the scope of traditional project management techniques. The greater the competitive time pressures, the greater the scope for inconsistency, and likelihood of rework. PDM systems enable you to retain control of the project by ensuring that the data on which it is based is firmly controlled.  
Product structure, change management, configuration control and traceability are key benefits. Control can also be enhanced by automatic data release and electronic sign-off procedures. As a result, it is impossible for a scheduled task to be ignored, buried or forgotten.  
  
Better Management of Engineering Change
A PDM system must allow you to create and maintain multiple revisions and versions of any design in the database. This means that iterations on a design can be created without the worry that previous versions will be lost or accidentally erased. Every version and revision has to be 'signed' and 'dated', removing any ambiguity about current designs and providing a complete audit trail of changes.  
  
A Major Step Toward Total Quality Management
By introducing a coherent set of audited processes to the product development cycle, a PDM system should go a long way towards establishing an environment for ISO9000 compliance and Total Quality Management (TQM). Many of the fundamental principals of TQM, such as 'empowerment of the individual' to identify and solve problems are inherent in the PDM structure. The formal controls, checks, change management processes and defined responsibilities should also ensure that the PDM system you select contributes to your conformance with international quality standards.

KingTiger