This topic is contained in the PDXpert help file: select Contents from the application's Help menu.

Change forms

Purpose

Classifies changes according to their usage; assigns numbering sequences; enables options; manages standard approval and notification 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 Enterprise Change Request or Production Deviation.
Abbreviation
The abbreviation is used extensively in identifying the change form. This is typically ECR, ECN, Dev and similar industry terms (up to 10 characters in length).
Description
This describes the change form and its purpose in your change process.
Identifier sequence
This permits you to specify either a common sequence for all change forms, or a unique sequence for the current form. In other words, 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 eliminate any confusion between, for instance, ECN 1234 and ECR 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.
Active: users can select
Default member of collection
Permanent member of collection
For a description of these checkboxes, see the Collections reference > Common properties & attributes 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 responsible engineer on the change. If this checkbox is cleared, then the additional person #1 combobox will not be 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 combobox will not be 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 a starting date and/or serial number
When this checkbox is marked, user will be able to 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 will be able to 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.
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.
Files attachments are accepted
When this checkbox is marked, files can be added to the change's Files tab. When this checkbox is cleared, the Files tab will be 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 tab.
Manage revisions on Affected tab
Mark this checkbox when you want specific item revisions to be displayed on, and affected by, the change form (notably, releasing and/or canceling specific revisions using a change notice). Clear the checkbox when you don't care about a specific item revision because you want to provide a more general notice about the item, regardless of the revision (for instance, a Change Proposal or Stop Shipment).
Releases/cancels items on Affected tab
When this checkbox is marked, the change form is considered an implementing change: all items listed on the Affected tab will be released or canceled (as appropriate) upon change approval.
This is the principal means for distinguishing change forms that permanently change an item revision's release status (such as a Change Notice) from those change forms that merely indicate an intent or temporary status (like a Change Proposal or Deviation). See Setup suggestions, below.
Display revision action
When this checkbox is marked, each item on the Affected tab will include an intended action, such as Release or Cancel. When cleared, no action will be displayed.
This checkbox is always marked for releasing/canceling changes. It's usually cleared for temporary changes (e.g., waiver, deviation, stop ship). Whether you want to display the action for other non-implementing changes, such as an ECR, depends on your process.
Change cannot be approved if an affected item has a rule violation
When this checkbox is cleared, the change can be approved even when the Affected tab lists items with rule violations. When marked, each item listed on the Affected tab must be free of all rule violations before a change can be routed to department reviewers.
Generally, this checkbox is marked for releasing/canceling changes, and cleared for requests, proposals and temporary changes (e.g., waiver, deviation, stop ship). Therefore, the value of this checkbox is typically the same as the Releases/cancels items on Affected tab checkbox.
Items on Affected tab can be dispositioned
When this checkbox is marked, items on the Affected tab can be dispositioned on the change.
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 identifier sequence on the General tab is ignored.
In most cases, this checkbox is cleared. It is typically marked only when another system assigns the change number, and you must replicate or coordinate releases with the other system.

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 will automatically be 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 will automatically be loaded with this text value, which the user can then edit.

Participants tab

Reviewing departments
You can define the list of departments that must approve this type of change form. For example, you can choose that a change request has a different list of reviewers than a deviation.
You can add to the Reviewing department list by dragging a department or group from under your organization's name, in the Organizations collection on the Collection Explorer.
You can modify the review notification Order so that one group (say, engineering) is notified of the routed change before another group (say, manufacturing). Setting a department's sequence to 1 ensures that department is the first to review the change. You can assign the same sequence value to any number of departments, and they will all receive notifications at the same time.
The notification order does not enforce a specific review sequence; any department can review the change earlier than specified.
You can specify the whether Participation is required or optional, meaning that the reviewer isn't required to respond but is free to veto or confirm the change.
The reviewer list is a starting point that can be modified when the actual change is created. You can ensure that a specific department's participation can't be changed by setting the department to Locked.
Observers list
People with valid email addresses, even those without a user login account, can receive email notifications during the change workflow. Drag the person's name from the Persons collection onto this list. You can designate when these observers are informed of a change's progress using the lifecycle phases map in the Workflow tab.

Workflow tab

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

Workflow phases
Each change workflow definition displays all possible lifecycle phases. For each phase, you can (a) enable or disable the transition paths to other phases; and (b) identify the user groups that should receive a notification when the change transitions to that next phase.
Notes regarding specific workflow phases:
  • The Submitted and Accepted phases are used as intermediate quality control steps, and are performed by an analyst in the configuration management (document control) team. Submitted provides the opportunity to verify that the change form meets internal standards for completeness and accuracy, while the Accepted phase 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 may be appropriate.
  • 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; in the Completed state, these attributes are locked.
Transition paths
To enable a path from one workflow phase to another, unlock the Change Forms template and mark the Enable transition path checkbox. If you disable a particular transition (such as from Released to Completed), then that selection on the Process menu will be disabled, and users won't be allowed to move their change form to that phase.
Some paths are mutually exclusive: setting path 13 will automatically disable path 14. Other paths are essential: moving a change to a specific phase (say, Held) implies it can later exit that state, and therefore a path (18) may be permanently enabled.
Notification parties
Mark the corresponding checkbox to identify the parties who will be notified when the change moves from one lifecycle phase 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 departments All authorized approvers of every listed department. The person must be listed in the Approvers list on the Departments member form, and the department must appear on the change form's Approve list. The notification will be sent without regard to the departments' current responses (Pending, Approve, Hold, Disapprove).
  • Reviewers in pending department(s) All persons who are authorized to review on behalf of a listed department where the department's current response is Pending.
  • Holding reviewer The person(s) who have set the department response to Hold.
  • Reviewers in current department All users who are authorized approvers for the current reviewer's department.
  • Observers Persons identified on the change form's Observers list.
  • Analyst The named person who has analyst permissions for the change.
  • Analysts The group of all persons who have been assigned an analyst role. Analyst roles are defined within a Roles collection member when the Is an analyst checkbox is marked, and that role is then selected for a Persons collection record.
  • Reviewers in next department(s) All authorized approvers for the next department(s) as specified by the Reviewing departments' notification Order. Notifications will only be sent where the next department's response is Pending.
  • Disapproving reviewer The person(s) who have set the department response to Disapprove.
  • Product team The set of unique persons who are 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, any custom attributes will appear on the change's Custom tab. For a complete description, see the Collections reference > Custom attributes topic.

Setup suggestions

PDXpert distinguishes between two types of changes. Informational changes (such as ECRs) propose changes, while implementing changes (like ECNs) can affect the status of documents and parts listed on them. (See help topic How to work with change forms > Processing a change for details.)

You define an implementing change by marking the Releases/cancels items on Affected tab checkbox on the General tab. 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 will be updated at the same instant that the change form is released.

Other changes that propose modifications but do not actually implement them (like a Change Request or Deviation) should generally permit items with rule violations to be processed, so set Change cannot be approved if an affected item has a rule violation as cleared. Conversely, you'll want to enforce more stringent data entry for changes that release or cancel items, and therefore the Change cannot be approved if an affected item has a rule violation checkbox usually should be marked for implementing changes.

If your change process dictates that only one person (say, the program manager or configuration control board ["CCB"] chair) ultimately decides on a change, then that person is the only required reviewer, and should be specified as the last reviewer in sequence. Any other CCB members would be designated as optional or listed as observers.

Workflow paths

The following diagram provides an overview of the possible change lifecycle phases and workflow transition paths. Note on the diagram that there are both change lifecycle phases (blue boxes, e.g., "Change Originated") that can be enabled and transition paths (yellow circles, e.g., "01") between the phases. Each path can have any number of notification parties.

Change workflow diagram

You should study the default settings for each change form as it was installed, and understand the effects of changing the settings, before modifying the change form's workflow.

After a change has been reviewed (all required reviewers have approved the change), you can force the system to set the phase to Accepted (path 13) so that the analyst can review the change prior to manually releasing the change, or can skip the Accepted phase and immediately set the phase to Released (path 14).

Similarly, you can choose whether the system will set a disapproved change to Stopped, Canceled, Submitted, or Rejected (paths 08, 09, 10, or 11) upon the disapproval of any one person.

2012

Help topics describe the most current PDXpert PLM software release, and may differ from earlier releases.