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.
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.
posted by mftips at
8:05 PM
0 Comments:
Post a Comment
<< Home