Change forms

Change forms should be Completed, Canceled or Rejected before editing their related Change Forms member. When a new change form is created, workflow, participants and some collection member attributes are copied from this template to the change form. New settings may not affect previously-created change forms, or may have unexpected results.

Other users should not be using the system while you're working. Close all item records in your workspace before you begin. Restart your PDXpert client application when you've finished.

Purpose

Classifies changes according to their usage; assigns numbering sequences; enables options; manages standard approval and email notice lists; defines workflow and custom properties.

Where used

Change form

Data fields

General tab

Name
This is the complete name for the change form, such as Change Notice or Production Deviation.
Abbreviation
The abbreviation is used extensively in identifying the change form. This is typically CN, Dev and similar industry terms (up to 10 characters in length).
Description
This describes the change form and its purpose in your change process.
Active: users can select
Default member of collection
Permanent member of collection
For a description of these checkboxes, see the Collections reference > Managing collections help topic.

Attributes tab

Display a Person #1 role
This checkbox allows originators to identify an additional person for the current change form. For example, you may want users to identify the design engineer on the change.
If this checkbox is cleared, then the additional person #1 dropdown list isn't shown on the change.
Person #1 role label
The textbox allows you to label an additional person's responsibility. For example, you may want to use Design Engineer as the label on the change.
Display a Person #2 role
This checkbox allows originators to identify an additional person for the current change form. For example, you may want users to identify the project manager on the change.
If this checkbox is cleared, then the additional person #2 dropdown list isn't shown on the change.
Person #2 role label
The textbox allows you to label an additional person's responsibility. For example, you may want to use Project Manager as the label on the change.
Display selection for a problem source
When this checkbox is marked, a problem source dropdown list box is displayed to the change creator. Manage this list using the Problem sources collection.
Display selection for a change reason
When this checkbox is marked, a change reason dropdown list box is displayed to the change creator. Manage this list using the Change reasons collection.
Show Files tab
When this checkbox is marked, files can be added to the change's Files list. When this checkbox is cleared, the Files tab is hidden.
Affected tab will accept documents
Affected tab will accept parts
When these checkboxes are marked, items of the specified class may be added to the change's Affected list.
Set to Released state before Completed state
When this checkbox is marked, the accepted change is stopped at the Released state. The Product Team attributes can be edited and items on the Affected list can be dispositioned. After the released data is updated, the analyst can lock the change at the Completed state.
If this checkbox is not marked, then the system immediately moves an accepted change from Released to Completed. Workflow notices are sent only to the email recipients defined in paths 14 and 24 (all email checkboxes for path 25 are cleared).
Release/cancel iterations when change is released
Before modifying this setting, finish processing all change forms based on this collection member.

When this checkbox is marked, the change form is an implementing change. When (1) all reviewing groups have approved the change and (2) the system or an analyst moves the change to the Released state, then each iteration on the Affected list is released (if previously pending) or canceled (if previously released).

When not marked, the change form indicates a future intent (like a Change Request) or temporary status (Deviation, Waiver, Stop Ship) to act on an item. It doesn't have any effect on an iteration.

A new Change Forms collection member does not display the following two settings. An existing (upgraded) collection member displays these only when they don't match the Release/cancel iterations when change is released value. These two settings may be ignored in future PDXpert releases.

When the Release/cancel iterations when change is released value is changed, or if all three values match, then the following two settings are immediately and permanently hidden.

Show item iterations on Affected tab
Mark this checkbox when you want specific item iterations to be displayed on, and affected by, the change form (notably, releasing and/or canceling specific iterations using a change notice). Clear the checkbox to provide a general notice about the item, regardless of the iteration (for instance, a Change Proposal or Stop Shipment).
Show releasing/canceling icon
When this checkbox is marked, each item on the Affected list includes an intended action, such as Release or Cancel. When cleared, no action is displayed.
This checkbox is automatically marked for implementing changes. It's always cleared for information change forms (e.g., change request/proposal, waiver, deviation, stop ship).
Display a starting date and/or serial number
When this checkbox is marked, user can view and modify date and serial number fields that indicate the change's overall effectivity.
Label for starting boundary fields
This value is displayed to identify the starting date as, for example, Beginning on/at.
Display an ending date, serial number, and/or total quantity
When this checkbox is marked, user can view and modify date, total quantity and serial number fields that indicate the change's duration and scope. Specifying a completion or expiration point (date, serial number or quantity) is often required for temporary changes, such as deviations and stop-ship orders.
Label for ending boundary fields
This value is displayed to identify the ending point as, for example, Expires after or Resume shipments.
User assigns number
When this checkbox is marked, the change form's Number must be manually assigned at the time the change is created. The selected Identifier sequence is ignored. In most cases, this checkbox is marked only when another system assigns the change number, and you must replicate or coordinate releases with the other system.
Identifier sequence

This permits you to specify the change number format for the current form. This selection is disabled if the User assigns number is marked.

You can choose a single identifier sequence for all ECRs, ECNs, RFDs, etc., or you can designate a separate sequence just for ECRs, another for ECNs, etc. For more information, refer to the Sequences: Identifier collection.

Use a single identifier sequence for all change forms. You'll avoid confusion between overlapping change numbers, such as ECR 1234 and ECN 1234.

Analyst label on change form
This textbox allows you to match an analyst's role to the change form. For example, the analyst for a design change may be labeled as Design Analyst while the analyst for a purchased part release is Component Engineer.
Default analyst
This dropdown list box allows you to select an analyst for the change form. The default analyst can be overridden when the originator creates the new change form. If the selection is empty, then the change form's analyst is (a) the originator if that person has an analyst role; or (b) any other person who has an analyst role; otherwise (c) the super administrator. Changing this value will not affect change forms that have already been created.
The persons listed currently have been assigned a Roles member that includes Is an analyst. If you later take away this analyst role, ensure that you update this value with a new analyst. 

Text Templates tab

Label for primary discussion
Label the primary discussion field based on how it's used. For example, you may want to label the field as Problem description or Solution summary depending on the change form you're defining.
Primary discussion text template
When a new change form is first created, the change form's primary discussion field is automatically loaded with this text value, which the user can then edit. Providing your users with a good change discussion template ensures that your change forms are clear, concise and valid. A good template enhances completeness and consistency, which makes locating, reviewing, and implementing a change form easier.
Display a secondary discussion text area
When this checkbox is marked, the change form displays a field (with your label) on the change's Attributes tab; this is used for auxiliary change information.
Label for secondary discussion
This value is displayed to label the secondary discussion field based on how it's used. Depending on the change, you may want to label the field as Rework instructions or Production impact.
Secondary discussion text template
When the change form is first created, the change form's secondary discussion field is automatically loaded with this text value, which the user can then edit.

Participants tab

Reviewing groups

Identify the groups that must approve this type of change form. This list is copied to a new change form, and can be further modified on each change form.

Add to the Reviewing groups list by dragging a group from the Groups collection on the Collection Explorer.

  • You can modify the review Order so that one or more groups (say, manufacturing) are notified of the routed change after another group (say, engineering). The review order does not prevent a group from reviewing the change before its turn.

    The most efficient review scheme is to set every group's order to 1.

  • You can specify whether Participation is required or optional. The change workflow waits for reviewers who Must act. A reviewer who Can act is free to approve, disapprove or ignore the change. After all required reviewers have responded, the workflow proceeds without waiting for the optional reviewers' responses (unless the Can act reviewer has Held the change).

  • You can ensure that a specific group's participation can't be deleted from an individual change form by setting the group to Locked.

Delete a reviewing group by selecting the row, and pressing your keyboard's Delete key.

Observing groups and persons

Persons with valid email addresses, even those without a user log-in account, can receive email notices during the change workflow. You can designate when these observers are informed of a change's progress using the lifecycle states map in the Workflow tab. This list is copied to a new change form, and can be further modified on each change form.

  • To add a group of observers, drag the group's name from the Groups collection of the Collection Explorer onto this list.
  • To add an observer, drag the person's name from the Persons collection of the Collection Explorer onto this list.

Delete an observer or group by clicking on it, and then pressing your keyboard's Delete key.

Workflow tab

The workflow map is used to enable various workflow paths between a change's current state and the next permitted state. The map also specifies which groups of users are notified as the change moves through the approval workflow.

The workflow diagram displays all possible lifecycle states. For each lifecycle state, you can (a) enable or disable the workflow paths to other states; and (b) identify the user groups that should receive an email notice when the change moves to that state.

Workflow diagram paths
Workflow paths are buttons 01 to 25. To allow a path from one workflow state to another, unlock the Change Forms template, click on the path button, and set the Enable workflow path checkbox. If you disable a particular path, then users cannot process their change to that lifecycle state.
Path definitions:
  • 01 [ORG→ORG]: The current originator or any analyst assigns a user as new change originator.
  • 02 [ORG→SUB]: The originator or any analyst submits the change form to the analyst who, after a quality check, routes it for approval on path 05.

    Path 02 also defines where a change form is returned for rework. When path 02 is enabled, then the change form is returned to the Submitted state. When path 02 is disabled, then the change form is returned to the Orginated state.

  • 03 [ORG→RTD]: The originator or any analyst routes the change form to reviewers for approval. If the change has been previously routed, all reviewer responses are reset (comments are retained).
  • 04 [SUB→ORG]: The analyst returns a submitted change form to the originator for further work.
  • 05 [SUB→RTD]: The analyst routes the submitted change form to reviewers for approval. If the change has been previously routed, all reviewer responses are reset (comments are retained).
  • 06 [SUB→CAN]: The analyst cancels the change form, which the analyst can then delete.
  • 07 [RTD→ORG/SUB]: The analyst takes the routed change form out of the review process. All existing reviewer responses are reset.
  • 08 [RTD.disapprove→ORG/SUB]: After any reviewer has disapproved the routed change, the system returns it to the originator or analyst.
  • 09 [RTD.disapprove→REJ]: After any reviewer has disapproved the routed change, the system rejects it and retains it as a permanent record.
  • 10 [RTD.disapprove→STP]: After any reviewer has disapproved the routed change, the system stops it and awaits analyst action.
  • 11 [RTD.disapprove→CAN]: After any reviewer has disapproved the routed change, the system cancels it, which the analyst can then delete.
  • 12 [RTD.approve→RTD.approve] (always enabled): After all reviewers in the current review order (for example, 1) have approved the routed change, the system routes the change form to the reviewers in the next review order (say, 2). Path 12 defines who gets an email notice when the change moves from the previous set of groups to the next set.
  • 13 [RTD.approve→ACC]: After all reviewers have approved the routed change, the system accepts it and awaits analyst action.
  • 14 [RTD.approve→REL]: After all reviewers have approved the routed change, the system immediately releases it.

    Path 14 is a fast-track combination of paths 13 and 24. The change form is released only if the affected items' relationships remain valid.

    However, if the change has a processing error — for example, an affected item now relies on a canceled reference item —, then the system sets the change form's lifecycle to Accepted, and email notices are sent as specified by path 13. The analyst resolves the processing error by (a) correcting the problem (say, by releasing a new iteration) and then releasing the change via path 24; or (b) correcting the change form via path 23. Therefore, when using path 14, set emails for path 13 and 24 to respond to processing errors.

  • 15 [RTD→CAN]: The analyst cancels the routed change form, which the analyst can then delete.
  • 16 [RTD.pending→HLD]: The reviewer holds the routed change form.

    An analyst (not the reviewer) must process a change form out of the Held state. If the analyst processes the change directly to Routed (path 18), then all previous approvals are retained. The reviewer who held the change remains selected. If the analyst processes the change to Submitted (path 17) and then to Routed, all previous responses are reset.

  • 17 [HLD→ORG/SUB]: The analyst withdraws the held change form from the review process. All existing reviewer responses are reset.
  • 18 [HLD→RTD.pending] (always enabled): The analyst returns the held change form to the routed state.
  • 19 [HLD→CAN]: The analyst cancels the held change form, which the analyst can then delete.
  • 20 [STP→ORG/SUB]: The analyst withdraws the stopped change form. All existing reviewer responses are reset.
  • 21 [STP→REJ]: The analyst rejects the stopped change form and retains it as a permanent record.
  • 22 [STP→CAN]: The analyst cancels the stopped change form, which the analyst can then delete.
  • 23 [ACC→ORG/SUB]: The analyst withdraws the accepted change form. All existing reviewer responses are reset.
  • 24 [ACC→REL] (always enabled): The analyst releases the accepted change form, which may update the release status of affected items.
  • 25 [REL→CMP] (always enabled): The analyst completes the released change form after all dispositioning tasks are closed. When the change is completed, all data fields, except the Notes tab, are locked.

    Approved changes can be set to automatically move from Released to Completed. In this case, emails are not sent using path 25. See the Set to Released state before Completed state checkbox setting.

Paths 08/09/10/11 and 13/14 are mutually exclusive; for example, setting path 13 automatically disables path 14. Some paths are always enabled; for example, moving a change into Accepted requires an exit on path 23 or 24.
Send emails to:
Mark the corresponding checkbox to identify the parties who are notified when the change moves from one lifecycle state to another.
  • Originator This is the person who created the change, and has principal authority for modifying (or deleting) it. This role is similar to a document or part trustee.
  • Reviewers in all groups All authorized approvers of every listed group. The person must be listed in the Persons list on the Groups member form, and the group must appear on the change form's Reviewers list. The email notice is sent without regard to the groups' current responses (Pending, Approve, Hold, Disapprove).
  • Reviewers in pending group(s) All persons who are authorized to review on behalf of a listed group where the group's current response is Pending.
  • Holding reviewer The person who sets a group's response to Hold.
  • Reviewers in active group All users who are also reviewers for the current reviewer's group.
  • Observing persons Persons identified on the change form's Observers list.
  • Analyst The analyst who is named on the change form. This analyst can edit the change, add/remove file attachments, and process the workflow.
  • Analysts The group of all persons who have been assigned an analyst role. Analysts may process the change's workflow, and assign a different named analyst. Analyst roles are defined within a Roles collection member when Is an analyst is marked, and that role is then selected for a Persons collection record.
  • Reviewers in next group(s) All authorized approvers for the next group(s) as specified by the Reviewing groups' review Order. Email notices are only sent where the next group's response is Pending.
  • Disapproving reviewer The person(s) who have set the group response to Disapprove.
  • Product team All members of Product Teams with affected items on the change.

Custom tab

You can define custom attributes (or "properties" or "extensions") to the system-supplied attributes for each change form. When a new change is created, the custom attributes appear on the change's Custom tab. For a complete description, see the Collections reference > Custom attributes topic.

Setup suggestions

Implementing and informational change forms

PDXpert distinguishes between two categories of changes. Informational changes (such as change requests) propose changes, yet even upon release won't update the items on the Affected list. Implementing changes (like change notices) will affect the status of documents and parts listed on them. (See help topic How to work with change forms > Processing a change for details.) Implementing changes cannot be routed if an affected item has a rule violation, such as canceling an iteration that's still on a released parent item.

You define an implementing change by marking Release/cancel iterations when change is released. If you create a change based on an implementing change form and put a document or part to the change's Affected tab, then that item's status is updated at the same instant that the change form is released.

Workflow states & paths

The diagram shows all change lifecycle states. As each change form is processed, it moves from one state (say, Originated) to another state (Routed) along an enabled workflow path (path 03). When the change moves, it can notify persons affected by the process.

Change workflow diagram

Notes regarding specific workflow states:

  • The Submitted and Accepted states allow the analyst to confirm that the change form has been processed correctly. Submitted provides the opportunity to verify that the change form meets internal standards for completeness and accuracy, while the Accepted state allows the analyst to verify that all reviewers' comments have been accommodated before the change form's release. If the organization doesn't require such intermediate reviews, then disabling path 02 and enabling path 14 provides the shortest workflow.
  • In smaller organizations, a disapproved change invariably is reworked and then re-routed for approval; it's therefore common to enable path 08. In more complex review processes, the change form can be disapproved for a variety of reasons, and therefore enabling path 10 offers the most flexible recovery.
  • Reviewers with participation set as Must act should keep the Response in Pending state until they're ready to approve or disapprove. Reviewers with participation set as Can act may use the Held state to block the change from leaving the Routed state while they investigate the change. If your Reviewing groups list doesn't include reviewers set as Can act, disable path 16 and rely on the Disapprove paths 08 to 11. When enabling path 16, keep in mind that the reviewer requires the analyst's assistance in moving the change back to Routed.
  • Moving a change into the Canceled state allows it to be permanently deleted from the system. The other terminating states, Completed and Rejected, retain a permanent record of the change.
  • In the Released state, the dispositioning attributes can be modified and closed; in the Completed state, these attributes are locked.

2012

Learn More
Help Guide Contents [PDF]