Understanding the CMII Change Process

Introduction

This tutorial provides you with an understanding of the change management process in Windchill PDMLink. In addition, this lesson teaches you how Windchill PDMLink uses problem reports, enterprise change requests, and enterprise change notices to capture and route enterprise change information in the change management process. The Windchill PDMLink change management process adheres to the CMII industry standard closed-loop change process, including terminology. The CMII closed-loop change management reference model focuses on:

  • High data integrity
  • Up-front planning and decision making
  • Continuous process improvement

This reference model emphasizes the fundamental shift from controlling change to accommodating change. Simply put, CMII is traditional configuration management plus continuous improvement in the ability to "change faster" and "document better."

This tutorial outlines the CMII change management process steps to help improve your understanding and management of your change process. It walks you through the following topics:

  • Creating and Confirming the Problem Report or Enterprise Change Request
  • Fast Track and Full Track Changes
  • Plan and Implement Changes Using the Enterprise Change Notice
  • Audit and Deliver Closed-Loop Communications

Understanding the CMII Change Process

Creating and Confirming the Problem Report or Enterprise Change Notice

Product problems and issues relating to the documentation describing the physical product can be captured in Windchill PDMLink by creation of either a problem report (PR) or an enterprise change request (ECR). An organization's change process and structure determine whether a problem report is used, or if the change process is initiated with the creation of an ECR.

The diagram below illustrates how the Windchill PDMLink change process aligns with the CMII industry standard change process. Let's begin a walk-through of the process.

 

CMII Closed-loop Change Process -- Problem Report

The purpose of the PR is to capture and describe a product problem or suggest a product enhancement from any source involved in your product development process. PRs capture pertinent information regarding the problem or issue, such as a brief description, initiator, and priority. Attachments can be added to the PR to improve the gathering and packaging of information, such as affected item (system data), affected end item (standalone product), and attachments (external data).

Once the PR is persisted to the database it has the state of Open, signifying that it has been created but has not been submitted to the change process. Once submitted to the process, the PR has the state of Under Review.

When the PR is created, it is assigned to a product. The initial reviewer is the Change Administrator I (CAI) assigned to the product identified in the PR. The CAI confirms that the PR is valid. There are three possible outcomes:

  • Confirm the PR and send it on for ECR creation
  • Reject the PR as an unsuitable idea
  • Reject the PR as a duplicate of another PR

If the PR is confirmed, it is promoted to the Accepted state. If the PR is a duplicate or is rejected, it is promoted to the Resolved state. Any PR that is resolved by closing sends notification to the creator of the PR with the appropriate justification.

The CAI's view of a PR is shown in the following graphic. The highlighted section is a direct link back to the actual PR, which can be accessed simply by clicking on the link.

 

Analyze Problem Report Window

Once the PR is analyzed and completed, it is routed based on the given disposition. A confirmed PR becomes an enterprise change request (ECR). The objective of the ECR is to describe a product defect or proposed enhancement in detail, so that a business decision can be made. There are two basic decisions that need resolution:

  • Is there business justification to implement this change?
  • If accepted, is the change fast track or full track?

The flow chart displayed previously indicates the process for creating the ECR. Creating the ECR does not pre-suppose the creation of a PR. The change request Creator has the option of providing additional information to validate the issue, or impact analysis with corresponding proposals. The Creator may also collaborate with technical reviewers to validate and assess impact. Once the ECR is saved, it has the state Open, and may then be submitted to the next step in the change process.

The CAI receives the created or updated ECR, reviews the content and analysis, and answers the two bulleted questions noted previously. The following graphic is an example of the CAI's view of the ECR. Notice the routing choices at the bottom of the Analyze ECR window, and the decisions required by the CAI upon review of the ECR. Let's discuss this further on the next page.

 

Analyze ECR Window

Understanding the CMII Change Process

Fast Track and Full Track Change

 

A key point to emphasize is the difference between fast track and full track changes, as not all changes are the same. Some require more detailed analysis and approvals because their impact is greater; others are simple changes that should not be burdened with a complex analysis and “rubber stamp” signatures. The fast track change branch should handle the roughly 80% of all changes that can be done simply as an agreement between the data author and consumer, without bureaucratic delay.

 

CMII Closed-loop Change Process -- Full Track and Fast Track

Because full track changes require more detail and have greater impact, there is an additional step that involves review of the ECR by the Change Review Board (CRB). The outcome of this step is a business decision on whether or not to proceed with implementation. Fast track changes bypass the CRB, and are sent directly to the Change Administrator II (CAII) for implementation. Full track changes are sent to the CRB for business decision. Fast track changes should make up about 80% of all ECRs according to the CMII standard.

There are two change boards in the CMII change process:

  • Change Review Board (CRB)
    • A cross-functional team with representation from different company departments
    • Reviews the ECR and makes a business decision as to whether or not to proceed with implementation planning
  • Change Implementation Board (CIB)
    • A cross-functional team with representation from different company departments
    • Reviews the implementation plan captured by the ECN and decides whether or not the plan is complete and ready to be executed

Understanding the CMII Change Process

Plan and Implement Changes Using the Enterprise Change Notice

The primary change form used for implementation is the Enterprise Change Notification (ECN). The purpose of the ECN is to establish a work plan to implement the approved ECR. The ECN has a line item for each modified part and document that is assigned to specific data Creators for processing. For example, a drawing document would be assigned to a designer as the Creator. The resulting work for each line item is also checked by a User, or consumer, of that information. For example, the Creator of a drawing is a designer and the User is a manufacturing engineer.

Change Administrator II (CAII) creates the ECN and the table of parts and documents that must be modified to implement the ECR. The planning process includes assigning people to each required data modification. It may be necessary for CAII to delegate planning activities to another technical resource; however, CAII remains responsible for the total plan. It is also CAII’s responsibility to set the effectivity for each new or revised part version. Once the plan is complete (for full track), it is sent to the Change Implementation Board (CIB) for approval prior to implementation. If the CIB believes that the plan is incomplete or inaccurate, the plan may be sent back to the CAII for further planning. The ECR/ECN package may also be sent back to the CAI for further review of the ECR if details of the implementation plan cause the cost or impact of the change to increase. The ECN creation and implementation planning activities are performed in the highlighted section of the change process shown below.


CMII Closed-loop Change Process -- ECN Creation and Implementation

CAII is the chairperson for the Change Implementation Board (CIB). It is his or her job to schedule the meeting, set the agenda, and conduct the review. The CIB is made up of a cross-functional team of people who are empowered to review the ECN and determine if the plan is complete. The ECNs are rejected, approved, or sent back to CAII for further planning. If rework is required, the ECN remains in the Under Review state until it returns to the CIB. If the ECN is accepted, it moves to the execution phase. The ECN may also be rejected if, for any reason, the company decides the change should not proceed. If the ECN is rejected, its state is set to Cancelled. The ECR and any PRs are also set to the Resolved state.

The Implement Changes process step pictured in the diagram is performed by individual Creators and Reviewers assigned to a implementation task activity in the ECN. The Creator updates the document, making the necessary modifications per the instructions from the ECN. The Reviewer validates the changes as clear, concise and valid. If the modifications are not acceptable, they are routed back to the implementer for further update. If they are acceptable, the User approves the change and it waits for ECN audit. During this sequence of actions, the changeable data remains in the In Work state.

Understanding the CMII Change Process

Audit and Deliver Closed-loop Communications

The step in the process prior to Release is an audit by Change Administrator III (CAIII).

CMII Closed-loop Change Process -- ECN Audit

In this step, CAIII examines all of the document and BOM changes implemented by the ECN tasks. Each part version must also have a proper effectivity. If the audit is successfully completed, each changed object is promoted to the Released state. The ECN, ECR(s), and PR(s) are also promoted to the Resolved state. If the audit does not pass, the failed elements are sent back for correction to the appropriate implementers.

Completion of the audit task by CAIII causes the ECN, and all of the changed parts and documents, to be promoted to the Released state. This event either automatically triggers transmission of BOM and change information through the PTC Enterprise System Integration (ESI) module to the ERP system, or prompts the manual entry of BOM updates into the ERP system. Notification of this event goes out to CAII, CAI, and the ECR and PR Creators.


Understanding the CMII Change Process

Conclusion

You now have a basic understanding of how the change process in Windchill PDMLink works and how it aligns with the industry standard CMII change process. Lets quickly review the key concepts from this tutorial.

  • Windchill PDMLink provides three change objects (problem report, enterprise change request, and enterprise change notice) to capture and communicate change information at various points in the change process.
  • The change process requires three distinct Change Administrator roles (CAI, CAII and CAII), each with a different set of responsibilities that govern the process. In smaller organizations it is possible to have a single individual serve in the three roles.
  • Not all changes are created equal, and this is the purpose of full track and fast track changes -- to eliminate unnecessary bureaucracy and shift the emphasis to full track changes that carry the most impact.
  • The CMII change process is a closed-loop process, and it fosters communication throughout the process at each decision/action point.
  • The CMII change process is governed by two boards, the change review board and the change implementation board, to ensure that sound business decisions are being made in your company.