Change form rules

Each change should have a unique identifier

Don'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 numbers

Related 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 revision

Change 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.