How does Release State differ from Item Lifecycle Phase?

PDXpert product lifecycle management software supports various data revision approaches, including traditional pre-production numeric and production alphabetic formats. Nonetheless, this topic explains why these traditional approaches should be considered obsolete. We describe how using only one revision format (alphabetic or numeric), coupled with PDXpert PLM software's built-in item lifecycle phase attribute, provides fine-grained control over product life cycle business rules while reducing the cost and risk of managing item revisions. We believe that using a single revision format regardless of the item's lifecycle phase is current best practice.

Item records, whether for document or part, must have one or more revisions. An item revision represents the technical content; a released revision represents an item's approved technical content at a point in time.

Separately, items have a lifecycle: they're conceived, designed, prototyped, validated, produced, serviced, disposed of, and (when no longer commercially viable) declared obsolete.

In PDXpert PLM software, an item's technical revision and the item's lifecycle phase are independent attributes. Multiple item revisions may share a common lifecycle phase, and a particular item revision can move through several lifecycle phases. Together, the revision and lifecycle are called an iteration.

Document and part release states§

The release state informs everyone: "Can this specific iteration (revision at lifecycle) be used now?"
Only a Released state says "Yes".

Release states reflect the availability, or "readiness for use", of a specific item iteration. PDXpert PLM software defines exactly 3 release states for any iteration:

1. Pending (unreleased, pre-release, created, originated, etc.)
2. Released (issued, authorized for use, active, in-use, etc.)
3. Canceled¹ (superseded, obsolete, invalidated, void, removed from use, inactive, etc.)

At any point in time, each item in PDXpert software may have no more than one Pending revision and no more than one Released revision, and zero or more Canceled revisions.

These business rules are universal, and applied regardless of the product data management process used:

• Users can discard an item iteration in Pending state without effect or penalty.
• Users can use the revision in Released state according to the appropriate item lifecycle business rules.
• Users may not use an iteration in Canceled state, and the revision must be retained to provide a historical reference.

Note that the only state that's relevant for production purposes is the Released state. And there are some corollaries:

• Each released or canceled item revision must have an associated implementing change (typically called an "engineering change notice" or "engineering change order"). A pending iteration need not be associated with a change.
• For an item structure ("bill of materials"):
  • A child component's pending iteration may only appear on an assembly's pending iteration. An unreleased child iteration can never be used on a released or canceled parent assembly iteration.
  • Released items can appear as child components on a released parent assembly iteration, as well as on pending and canceled iterations of parent assemblies.
  • A canceled item iteration may only appear on a canceled parent iteration.

The three release states decide if a specific item iteration can be used, but do not say what purposes the iteration can be used for.

Document and part lifecycle phases§

The lifecycle phase informs everyone: "Can this released iteration be used without restriction?"
Only a Production (or its equivalent) phase says "Yes".

The item lifecycle phase identifies a set of company-specific business rules that are used as the item moves from conception through to production, and is finally retired.

Any number of item lifecycle phases can be defined, and each may be applied to documents or parts or both. PDXpert software generally follows the enumerations² in the IPC-2570 standards, which other PLM software suppliers also use. These phases are specified by IPC-2570 but aren't defined, presumably because each organization will create its own set of business rules.

Here are a few examples of item lifecycle phases with possible business rules:

• Preliminary Document intended only for internal use. It is not approved for external distribution and may not be used to acquire parts.
• Prototype Information and the items created from it may only be used in very limited quantities to validate the design and to begin production tooling, fixtures and processes.
• Pilot Part may be acquired in limited quantities for proof-of-concept production, product support, and field testing. Depending on the product, you may include (potential) customers, and may either deploy or recover pilot units after testing is complete.
• Production Product information may be used without restriction to meet customer demand.
• Service-only Part may not be used for new designs. Part may only be purchased for servicing previously produced items.

Prototype ("alpha") and Pilot ("beta") phases in particular are often assigned more specific business rules regarding maximum quantity permitted, design approvals required, and tooling and fixture decisions. Contractual obligations or warranty policies may dictate business rules, such as setting tight inventory stock thresholds and tooling availability, for items at a Service-only phase.

Canceling an iteration at its current lifecycle is more powerful than releasing an iteration at an Obsolete lifecycle. PDXpert ensures that a canceled iteration isn't used on pending or released higher-level items. For example, a BOM component must be removed from an assembly before the component is canceled, and canceled components can't be added to new assemblies. In addition, you can easily restore a canceled item simply by creating a new pending iteration and releasing it.

Clearly, each company will approach the set of lifecycle phase definitions according to product complexity, industry norms, marketing considerations and internal accounting policies.

Item lifecycle business rules are only applied by the organization and its supply chain partners to currently-released item iterations, and are irrelevant to pending and canceled iterations.

Benefits of keeping revision values and lifecycle phases separate§

In many older engineering document control processes, an engineering drawing revision did double duty, indicating both a specific technical "snapshot" and the business rules currently applicable to the engineering drawing. Numeric ("01"), dash ("–"), and date ("14 Oct 2006") formats were recommended³ prior to production release, and alphabetic revisions ("A") were used for production revisions. In the pre-computer era, this was understandable because informing an item's user of its current lifecycle phase was difficult and lifecycle business rules weren't very sophisticated.

However, one paid a significant price for this scheme:

1. Moving the product into production required a sudden additional burst of resources to modify every engineering drawing to change the pre-production revision format to production format. Regardless of product complexity, the last thing you need is an empty exercise that runs every drawing though the CAD system one more time to update the revision block. It's a time-consuming distraction that adds little value and, with an unnoticed click of the mouse, can actually damage previously-validated information.
2. There's a severe limit to the number of lifecycle phases that could be represented by varying revision formats (dates, numbers, letters and, well, Roman numerals?). In general practice, there's no way to distinguish any lifecycle phase after production.
3. Within a specific lifecycle phase, changing a drawing revision always indicated that the technical contents of the document had changed. But changing the revision format to indicate a new lifecycle phase was unclear: did the document contents change at the same time as the lifecycle phase changed?

By separating the technical revision label from the lifecycle phase, PDXpert PLM software avoids these difficulties. Importantly, a single iteration format can now be used through the item's lifecycle. Incrementing the iteration value exclusively indicates an interchangeable change to a physical part, or a change which affects only the document contents. The engineering document process can also support an unlimited number of lifecycle phases anywhere between item concept and obsolescence, with each phase having a distinct set of business rules.

While PDXpert software can correctly increment separate pre-production and production iteration formats (and can support manual revision formats like dash and date), there is no longer any reason to maintain more than one revision format over the life of an item.

Notes

1. Items no longer in use may be superseded (replaced with a newer item) or obsolete (not replaced); see Samaras, Thomas: Configuration Management Deskbook, AACI (1988), page 137. We looked for generic term to accommodate both concepts and settled on canceled.
2. IPC-2578 globalLifeCyclePhaseCode (section 4.1) and globalManufacturerPartStatusCode (section 9.1).
3. See, for example, Watts, Frank: Engineering Document Control Handbook, Noyes Publications (1993), page 132.

This application note was relevant to the PDXpert software release that was current at time of publication. Product changes since that time may affect its utility. We'd be happy to assist you in assessing the applicability of this note to your situation.