CMII-100E

CMII Standard

for

Enterprise

Configuration Management

Prepared by:

CMII Research Institute

CMII-100E Page 2

About this Standard How an organization does what it does has everything to do with processes. Every enterprise has a complex network of core business processes containing many interdependencies. Some of these processes and/or interdependencies may be clearly defined while others are not. Improperly defined or documented processes lead to gaps and inefficiencies that result in variability in the process output. Where this process variability occurs, unpredictable or unexpected output also occurs, resulting in the need for process improvement. The degree of needed improvement is revealed by the level of required corrective action. The need for corrective action does not just happen; it is caused by process issues. When these process issues arise, organizations typically respond by expending large amounts of intervention resources to resolve the problems in their attempt to rescue schedule and quality. Intervention resource activity represents unplanned expenditures which drive an organization’s costs up and have a direct impact on margins and/or profitability. To eliminate the need for these corrective action expenditures, the cause of the inefficiencies must be eliminated. To eliminate the causes of the inefficiencies, the variability in the core business processes must be removed. This standard provides a proven and measureable methodology that enables an organization to improve its core business processes and reduce the need for intervention resource expenditures. It also provides the foundation upon which projects can be successfully managed and conformance quality can be assured. The CMII methodology described herein provides the path to integrated process excellence. At its foundation lies a fundamental set of rules based on the sound principles and practices of configuration management. This fundamental set of rules has universal applicability across all industries and environments, and all core business processes. NOTE:

This business model has continued to evolve since the 1980’s and numerous contributions have been made to ensure the continued efficiency, and “best-in-class” status, of these practices by CMII graduates, CMII practitioners and CMII instructors worldwide. Although this standard is copyright protected, organizations that implement this standard may reuse any portion hereof. However, where those uses occur, source references to this standard must be provided. This standard can be used as a mandatory contractual requirement. © CMII Research Institute, 2010

CMII-100E Page 3

Please email any comments to vince@cmiiresearch.com or send them to: CMII Research Institute 11811 N. Tatum Blvd, Suite P135 Phoenix, AZ USA 85028-1651 Contact Numbers: Office: 602.595.8965 Toll Free: 1.888.816.2644

CMII-100E Page 4

TABLE OF CONTENTS

ACRONYMS ......................................................................................................... 5

DEFINITIONS ....................................................................................................... 6

1.0 GENERAL REQUIREMENTS ........................................................................ 9

1.1 Scope ........................................................................................................ 9 1.2 Infrastructure ............................................................................................. 9 1.3 Activities .................................................................................................. 10

2.0 DETAILED REQUIREMENTS ..................................................................... 11

2.1 Business Process Infrastructure ............................................................. 11 2.2 Development ........................................................................................... 12 2.3 Naming, Numbering and Reuse .............................................................. 13 2.4 Validation, Release Records and Audits ................................................. 14 2.5 Changes and Revision Records ............................................................. 15 2.6 Enabling Software Tools ......................................................................... 17

3.0 CONFORMANCE MEASUREMENT CHECKLISTS .................................... 18

3.1 Establishment of Basic Requirements .................................................... 18 3.2 Business Process Infrastructure ............................................................. 19 3.3 Organization Maturity .............................................................................. 20

CMII-100E Page 5

ACRONYMS

APAR - As-Planned/As-Released

CIB - Change Implementation Board

CRB - Change Review Board

CS-I - Change Specialist I

CS-II - Change Specialist II

CS-III - Change Specialist III

CM - Configuration Management

CMII - Configuration Management II

ECN - Enterprise Change Notice

ECR - Enterprise Change Request

PR - Problem Report

TRB - Technical Review Board

CMII-100E Page 6

DEFINITIONS Administrative Requirements – Requirements that define how an enterprise conducts its business. These include all requirements for each core business process as well as the requirements used to conduct all business activities.

Administrative Procedures – Documentation that provides the step-by-step instructions on how to achieve the requirements defined in an enterprise operating standard.

Alternate Item – An item authorized to be used in place of a preferred item on a temporary basis.

Application Requirements (Enterprise) – Requirements (normally externally generated) to which a business must adhere in order to satisfy all legal and regulatory demands where the business is conducted.

Application Requirements (Product) – Requirements (normally externally generated) that a product must meet to satisfy all customer, legal and regulatory demands where the product is developed and at each location that it will be sold.

As-Planned/As-Released (APAR) Baseline– A hierarchy of information which defines the current configuration of a product, facility or enterprise, provides visibility of pending changes, and is a portal for accessing all configuration documentation.

Baseline – A set of released documents, at specific revision levels, that define a configuration at an identified point in time.

Business Process Infrastructure – An integrated set of core business processes that ensure an organization’s requirements and intellectual properties are properly managed.

Change Implementation Board (CIB) – A cross-functional group that creates the implementation plan and sets the effectivity of full-track changes approved by the Change Review Board.

Change Review Board (CRB) – An upper-level management group that reviews the cost, benefits and risks associated with proposed changes processed via the full-track work flow and approves or disapproves each one accordingly.

Closed-Loop Change Process - A process in which a change, once initiated, remains in an active status until all actions and activities identified in the specific implementation plan are completed and the effectivity has been achieved.

CMII – A business model that is process and requirements driven and provides the path to integrated process excellence.

CMII-100E Page 7

Configuration Management (CM) – The business process that enables an enterprise to manage what a configuration is supposed to be, including changes, and ensure that configurations (when completed) conform to their documented requirements.

Conformance Quality – A definition of quality based on the principle that quality is conformance to requirements. Rather than focussing on first-time conformance, this approach demands every-time conformance.

Core Business Process – Any of the major disciplines or activities within an enterprise that are recognized by senior leadership as pivotal to the successful accomplishment of the business objectives and application requirements.

Corrective Action – The extra effort required to correct or compensate for something that should not have happened in the first place. Any time spent in a state of uncertainty about what to do, or how to do it, is also corrective action.

Creator (or Author) – The individual assigned the responsibility for creating and/or upgrading a specific document and who best understands the higher level requirements that are being flowed down for that document.

Dependent Demand – A term used in supply chain management wherein the demands for subordinate-level items are dependent upon, and driven by, the demand for their parent-level items.

Design Basis – A term given to the high-level views and definition of an entity which provides the basis for creating a hierarchy of its content and proceeding with detailed design.

Designated User - A person who is selected to co-own a document, along with its assigned creator, and who is responsible for ensuring that it is clear, concise and valid, and free of difficulty for all users.

Effective Date – A date that is entered into the as-planned/as-released baseline and represents when a newly released document is to be called out as a conformance requirement.

Effectivity – The point in time at which superseding items and documents are to be used in place of superseded items and documents, thereby achieving the objective of the change.

End-Item – The item that resides at the highest level of the product hierarchy and is also the deliverable entity (product or service) of an enterprise.

End-Item Traceability – The ability to trace specific changes, occurring at any level of the product hierarchy, to specific end-items which contain those changes.

Enterprise Change Notice (ECN) – A form that is used to authorize and control the implementation of approved ECRs and includes an impact matrix for each affected baseline. It is also the authority to upgrade and/or release a document.

CMII-100E Page 8

Enterprise Change Request (ECR) – A form that is used to request a change or initiate an improvement. It is the basis for performing an impact review and developing a cost/benefit/risk analysis from which a business decision is made.

Fast-Track Change – A change that is processed by the creator and designated user team, who are authorized to approve and implement their own technical recommendation.

Flow-Down – The process of driving the requirements for subordinate-levels in a hierarchy from the requirements for their parent levels. The flow-down begins at the highest level in the hierarchy and continues down to the lowest level.

Full-Track Change – A change that is prepared as a change package by Change Specialist I (CS-I) and is presented to the Change Review Board (CRB) for disposition.

Hierarchy – A top-down structure that links top-level requirements to bottom-level requirements through decomposition and requirements breakdown.

Interchangeable – Refers to the usability of an item (before and after it is changed) to satisfy any requirement for that item in any application.

Interchangeability – See the definition for interchangeable.

Intervention Resources – Any resource activity expended to accomplish the corrective action required to rescue schedules and/or quality, and/or the extra effort needed to compensate for inaccurate, missing or inadequate information.

Operating Standard – A document that describes a detailed requirement to be achieved by a core business process. An operating standard defines what the requirement to be achieved is, but not how it is to be achieved.

Problem Report (PR) – A form that is used to report a problem when the appropriate solution is unknown and also describes the issue in such a way that another party can recreate the problem during the investigation.

Release – An action that serves to formally activate, or put something into work. A document, for example, cannot be used until it is released.

Validate – To confirm or ratify the clarity, legitimacy, and acceptability of a document for use, prior to its release.

CMII-100E Page 9

1.0 GENERAL REQUIREMENTS

1.1 Scope

1.1.1 All information which could impact safety, security, quality, schedule, cost, profit, the environment, or an organization’s reputation or brand recognition is to be managed effectively. This information is to be documented and placed under formal change control, and is hereinafter referred to as requirements.

1.1.2 All product related requirements are managed per this standard.

1.1.3 All tool, equipment, facility and infrastructure related requirements are managed per this standard.

1.1.4 All administrative requirements (including process requirements and the requirements used to run the business) are managed per this standard.

1.2 Infrastructure

1.2.1 To properly facilitate the effective management of all enterprise requirements, a formal business process infrastructure is to be established.

1.2.2 The traditionally recognized activities of configuration management (identification, change control, status accounting and audits) shall be achieved through the business process infrastructure and integrated into the activities described in Section 1.3.

1.2.3 The business process infrastructure enables all core business processes, as well as project management and quality assurance activities, to be accomplished reliably and efficiently.

1.2.4 An as-planned/as-released (APAR) baseline is used to maintain the definition of a configuration in terms of its items, requirements and visibility of planned changes.

1.2.5 A development process is established which facilitates the flow-down of requirements to effectively create and validate all design and process definition.

1.2.6 Standardized naming and numbering conventions are used for the identification of all items and requirements that are managed.

1.2.7 Formal validation and release records are maintained and integrity of data and requirements has a high priority.

1.2.8 A closed-loop, self-correcting process is used to release new requirements and information.

CMII-100E Page 10

1.2.9 The same closed-loop process is used to change requirements and information previously released.

1.2.10 The required functionality for an organization’s information system/s and business tools is driven by the above infrastructure.

1.2.11 All requirements are to be properly identified, structured, linked and owned.

1.2.12 The lowest common denominators for managing information are items, documents, forms and records.

1.3 Activities

1.3.1 All configuration management related activities are formally recognized within the organization and their purposes, functions and interdependencies are understood.

1.3.2 Configuration management activities ensure that configurations conform to their applicable requirements.

1.3.3 Requirements management activities ensure that requirements are properly documented and are clear, concise and valid.

1.3.4 Change management activities ensure the use of a standardized closed-loop process for changing released requirements.

1.3.5 Release management activities ensure that documents are validated and released prior to use.

1.3.6 Data management activities ensure that databases are accurate and deliverable data is secure.

1.3.7 Records management activities ensure retention of traceability of all work and proof that the results conform to applicable requirements.

1.3.8 Document and library control activities ensure the protection of knowledge assets and the prevention of unauthorized changes.

1.3.9 Enabling tools ensure that the above activities are performed reliably and efficiently and serve to improve the predictability of process output.

CMII-100E Page 11

2.0 DETAILED REQUIREMENTS

2.1 Business Process Infrastructure

2.1.1 An integrated group of CM related activities is established to enable the proper management and visibility of requirements within the enterprise. This includes requirements for items, tools, equipment, facilities, infrastructure assets, services and each core business process.

2.1.2 As-Planned/As-Released (APAR) Baseline

2.1.2.1 A physical item APAR baseline is maintained for each

model or like family of end-item products, for facilities, for test equipment and for all infrastructure assets.

2.1.2.2 An administrative APAR baseline is maintained for all enterprise management and business requirements including all operating standards and administrative procedures.

2.1.2.3 Such baseline functionality and capability is also used to manage requirements regarding customers, suppliers, employees, etc.

2.1.2.4 A hierarchy is established as the framework on which the APAR baseline is constructed. The requirements extend vertically from the highest level application requirements to the requirements residing at the lowest levels.

2.1.2.5 Physical items are identified by a number, a standardized name and a system generated description. Documents are identified by a type code, a number and a revision.

2.1.2.6 The APAR baseline functionality provides visibility of the current configurations and future configurations, as well as visibility of planned changes. In addition, document release dates (planned and/or actual), effective dates and change effectivities are displayed.

2.1.3 Organization

2.1.3.1 All configuration management activities listed in section 1.3

are integrated into one consolidated unit.

2.1.3.2 The activities of this consolidated unit are uniformly applied to the management of requirements across the entire enterprise.

2.1.3.3 This consolidated function is officially recognized by the organization to be a core business process.

CMII-100E Page 12

2.2 Development

2.2.1 The development process commences with the identification of all

applicable application requirements from which the high level design basis is to be constructed.

2.2.2 Requirement Flow Down

2.2.2.1 Configurations shall be decomposed into a hierarchy of

manageable increments. The hierarchy is used as the framework for the APAR baseline and for linking the applicable requirements.

2.2.2.2 High-level requirements flow down through the applicable hierarchies into detailed requirements.

2.2.2.3 Requirements are progressively refined in the flow down process. They are progressively translated, documented, validated and released.

2.2.2.4 Work breakdown structures for the development activity, and the resulting work packages, are derived from the flow down of requirements.

2.2.3 Hierarchy for Development

2.2.3.1 Configurations shall be decomposed into a hierarchy of

manageable increments.

2.2.3.2 The hierarchy is the framework for the baseline and for linking the applicable documents.

2.2.3.3 The hierarchy for items during the design/production phases is comprised of make/buy items.

2.2.3.4 The hierarchy during the operation/maintenance phase is comprised of repairable/replaceable items.

2.2.3.5 Planned need dates for items and planned release dates for documents are calculated by dependent demand from the end-item need date.

2.2.3.6 Planned release dates and/or actual release dates are specified in the APAR baselines. All resources work to the planned release date as specified.

2.2.3.7 Effective dates denoting when a document is to be specified for application are identified in the APAR baseline.

2.2.3.8 Each item residing at each level within the product hierarchy has its own unique set of specified requirements.

CMII-100E Page 13

2.3 Naming, Numbering and Reuse

2.3.1 Standardized naming and numbering conventions shall be applied

to all items and documents including but not limited to: parts, assemblies, equipment, tools and software.

2.3.2 Naming Conventions

2.3.2.1 A listing of acceptable nouns to be used in the naming

conventions for the organization is created and properly managed.

2.3.2.2 The naming conventions are used to identify potential opportunities for reuse.

2.3.2.3 The assigned name is used as the start point for establishing the item description.

2.3.2.4 The item description is established from the key attributes of the item identified in descending order of significance.

2.3.3 Numbering Conventions

2.3.3.1 The numbering conventions are used to control the

interchangeability of physical items.

2.3.3.2 Items that are not fully interchangeable cannot be assigned the same identification number.

2.3.3.3 Although a different number, an alternate item may be used in place of a preferred item on a temporary basis; such usage must be properly authorized.

2.3.3.4 The numbering convention is preferably as short as practical, is numeric and except for standard parts is nonsignificant.

2.3.3.5 In addition to a number, items may also have a lot/batch number and/or a serial number. Physical items are not assigned revisions.

2.3.4 Reuse

2.3.4.1 Standardized naming and numbering conventions are used

to support the practice of reuse of inventory and existing intellectual property.

2.3.4.2 Reuse analysis is routinely conducted during the process of creating the work breakdown structure for development.

2.3.4.3 Reuse analysis is used to determine the potential reuse of previously defined items, documents and processes.

CMII-100E Page 14

2.3.4.4 Development program content and required activities are determined after the reuse analysis activity is complete.

2.4 Document Validation, Release Records and Audits

2.4.1 All formally controlled information is processed through a

standardized system of management that ensures proper validation, release and audit activities are conducted.

2.4.2 Document Validation

2.4.2.1 Every documented requirement is co-owned by an assigned

creator and designated user(s). They are jointly responsible for validating the “acceptability for use” of the document.

2.4.2.2 The assigned creator is an individual who best understands the higher level requirement being flowed down that must be incorporated into, and achieved by that specific document.

2.4.2.3 The designated user is an actual user of the document and is capable of coordinating with other users and ensuring that the document will be free of difficulty for all users.

2.4.2.4 Visibility of the individuals responsible for the validation of a document is provided in the metadata file for the document.

2.4.3 Document Release Records

2.4.3.1 Formal release records are generated and retained for each

document that has been validated and released.

2.4.3.2 Document release records include evidence that the proper validation activities have been accomplished.

2.4.3.3 A release record is retained for the initial release of each document that has been validated and released.

2.4.3.4 A release record is retained for the release of each revised document that has been validated and re-released.

2.4.3.5 A history record of release activity is retained for the full lifecycle of each document.

2.4.3.6 Release history records are protected against unauthorized access and are readily accessible to authorized personnel.

2.4.4 Document Audits

2.4.4.1 The Change Specialist III (CS-III) function is responsible for

conducting documentation audits to verify the continuity of the superseded/superseding information (not the content).

CMII-100E Page 15

2.4.4.2 Each newly created and/or revised document is submitted to CS-III for audit prior to the document being released.

2.4.4.3 The CS-III function coordinates required corrective action with the document creator when a document fails to pass the audit.

2.4.4.4 The CS-III function releases (or authorizes the release of) each document upon satisfactory completion of the audit.

2.5 Change Process and Revision Records

2.5.1 A standardized closed-loop change process is used to release new

information regarding safety, security, quality, schedule, cost, profit, the environment or an organization’s reputation or brand recognition. The same process is used to change information previously released.

2.5.1.1 The change process shall demonstrate the ability to

accommodate change and keep requirements clear, concise and valid.

2.5.1.2 Standardized change forms are used as templates to guide new releases and changes reliably and efficiently through the required steps of the change process.

2.5.1.3 The change process is managed by a combination of three change board and three change specialist functions.

2.5.1.4 The first of three change board functions is the conducting of a technical review (impact analysis) of each proposed change (Technical Review Board – TRB).

2.5.1.5 The second board function is the review and disposition (approval or disapproval) of each proposed change (Change Review Board – CRB).

2.5.1.6 The third board function is the creation of the implementation plan and establishment of the effectivity for each approved change (Change Implementation Board – CIB).

2.5.1.7 The first of three change specialist functions is the management of requested changes during the analysis phase (up to and including final disposition) of the change request (Change Specialist I, CS-I).

2.5.1.8 The second specialist function is the management of change implementations and the maintenance of the as-planned/as-released baselines (Change Specialist II, CS-II).

CMII-100E Page 16

2.5.1.9 The third specialist function is the audit and release (or authorization for release) of all new and/or revised requirements (Change Specialist III, CS-III).

2.5.1.10 A request for issue investigation is initiated via a Problem Report (PR) when the root cause of the issue is unknown.

2.5.1.11 The change process shall permit the processing of changes through either a fast-track or a full-track work flow.

2.5.1.12 Criteria for segregating changes into fast-track versus full-track categories are provided by the CRB.

2.5.1.13 The initial categorization (fast-track versus full-track) of change requests is done by CS-I.

2.5.1.14 A request for a change is initiated via an Enterprise Change Request (ECR) which may or may not be the result of a Problem Report (PR).

2.5.1.15 After the change request completes the analysis phase it is assigned a final categorization of fast-track or full-track.

2.5.1.16 An ECR categorized as fast-track is processed by the assigned creator and designated user(s) who may approve and implement their own technical recommendation.

2.5.1.17 ECR’s categorized for full-track are processed through CS-I who prepares the change package for, and presents the change package to, the CRB for disposition.

2.5.1.18 Each approved change enters the implementation phase wherein it is planned and managed by means of an ECN.

2.5.1.19 Implementation plans for ECN’s categorized as fast-track are created and managed by the assigned creator and designated user(s) that developed the technical recommendation.

2.5.1.20 Implementation plans for ECN’s categorized as full-track are created by the CIB and are managed by CS-II.

2.5.1.21 CS-II and the CIB calculate and establish the effectivity in order to achieve the objective of the change.

2.5.1.22 The implementation plans for both fast-track and full-track changes are used to update the APAR baseline.

2.5.1.23 Change implementations are properly planned. The principles of capacity planning and priority control are applied to all activities involved in the change implementation process.

2.5.1.24 Approved changes are assigned one of four priorities. Priority 1 is the highest and is worked full time until completed. Priority 2 is worked ahead of Priority 3 and 4 which use standard lead times.

CMII-100E Page 17

2.5.1.25 Approved changes are sorted into implementation groups wherein item reidentification decisions are based on the rules of interchangeability and the need for end-item traceability.

2.5.2 Revision Records

2.5.2.1 Document revision records are created and retained for

each released version of a document.

2.5.2.2 Previous versions of released documents are retrievable (or reproducible) from the document history file.

2.5.2.3 Revision records of the APAR baseline provide a complete trail of how each iteration evolved.

2.5.2.4 Superseded documents are moved from the APAR baseline to a history file once the assigned change effectivity has been achieved.

2.5.2.5 Previous versions of the APAR baseline are retrievable (or reproducible) from the baseline history file.

2.6 Enabling Software Tools

2.6.1 The basic requirements defined in this standard can be

implemented as a manual process, however to achieve the highest levels of throughput and efficiency enabling software will eventually be necessary.

2.6.2 Tool Functionality Requirements

2.6.2.1 Functionality requirements, as needed to enable the desired

process for the organization, are defined.

2.6.2.2 The functionality requirements are documented, validated, released and placed under formal change control.

2.6.3 Tool Functionality Capabilities

2.6.3.1 The documented functionality requirements are used to

evaluate candidate software tools being considered for implementation.

2.6.3.2 Software tool selection is based on the results of the functionality evaluation.

CMII-100E Page 18

3.0 CONFORMANCE MEASUREMENT CHECKLISTS

This standard may be used as a compliance document. The following checklists are provided for solely measuring compliance.

NOTE: These checklists are not intended as a replacement or substitute for formal CMII training, and do not assure a comprehensive understanding of the CMII Model or CMII Principles.

3.1 Check List for Establishment of the Basic Requirements

1. Core business processes have been identified and a cross-functional team has been established.

2. CM is identified as a core business process.

3. The business process infrastructure elements have been established.

4. The CMII destination has been documented and approved.

5. An assessment of existing practices and tools relative to the destination has been completed.

6. The operating standards and procedures of each core process have been validated and consolidated.

7. Capabilities for measuring and reporting corrective action are in place.

CMII-100E Page 19

3.2 Checklist for the Business Process Infrastructure

1. As-planned/as-released baseline functionality has been established.

2. The hierarchy is used as the framework for managing items, documents, data and records.

3. An information repository is established.

4. A documented development process is in place that includes provisions for identifying, structuring, linking and establishing ownership of all requirements.

5. Standardized naming and numbering conventions are employed.

6. Rules and definitions of “interchangeability” and “end-item traceability” have been validated and released.

7. All information that can impact safety, security, quality, schedule, cost, profit, the environment, or an organization’s reputation or brand recognition is under CM.

8. The closed-loop change process is defined, standardized change forms and work flows are used to authorize and manage all work.

9. Three change board functions have been established including Technical Review, Change Review/Approval, and Change Implementation Planning.

10. The closed-loop change process includes a fast-track capability and criteria for fast-track categorization has been validated and released.

CMII-100E Page 20

3.3 Checklist for Organization Maturity

M a

t u

r I

t y

L e

v e

l

1. Corrective action is measured and reported. The causes are identified and preventative measures for recurrence have been identified.

2. The preventative measures are embedded as an attribute of the business process infrastructure. The infrastructure has been validated in a pilot.

3.

Successful implementation of the infrastructure on the first business segment has been accomplished and the CMII methods have been proven to be reliable, fast and efficient.

4. Return-on-investment has turned positive.

5. Real improvements are being initiated.