Change form rulesReturn to Revision or version Each change should have a unique identifierDon't try to match engineering change order numbers (for instance, ECO 1234) to the preceding change request numbers (ECR 1234). While this may have made sense in a manual process, there's really no point: it requires a manual identifier assignment process and guarantees that you can't combine multiple requests into a single order, or split a single request into multiple orders. To facilitate searches, most PLM systems allow you to explicitly identify interrelated change forms. Use a single source of change numbersRelated to the previous point, use a single identifier sequence for all change types. You'll eliminate any confusion between, for instance, ECO 1234 and ECR 1234. Users can simply work with the change number without having to explicitly state the change type. Changes have no revisionChange forms, such as engineering change orders, should be issued exactly once, and therefore should not have a revision. The difficulty is somewhat conceptual: if changing a document requires a formal change form to describe the rationale for the revision, shouldn't changing a change form require a similar level of documentation -- a "meta-change"? How does one know the status of an item that appears on a particular change revision, but not on another? A change is a "complete thought", a command to execute a specific bundle of modifications. If the command is wrong, then we (a) "roll back" the entire bundle by canceling the change and issuing a replacement, or (b) execute a new change that describes a further command bundle.
PLM0044 Rev 2007-08-24 16:46:33 -0700 |
|||||
|
Investigating Creating |
|||||
Copyright © 2004-2007 by Active Sensing, Inc. All rights reserved.