Dissecting the Functional Requirements for Configuration Management Solutions: The Use of Configuration Items
In our last CMsights post we listed the “Top Ten Requirements” of configuration management software (CM) solutions that CMstat has heard most often from CM practitioners over our many years in business. They were presented in no particular order because their relative importance varies greatly across different industries, product lines, and supply chains.
In this and the next several posts we will examine these requirements to help new or existing users with their evaluation of CM solutions, whether they be home-grown applications, enterprise bolt-ons, or commercial-off-the-shelf products like CMstat’s PDMPlus. Here’s the first requirement involving the use of Configuration Items that is typically at the top of everyone’s list.
#1 – Capable with deep functionality and features needed by CM professionals in production use.
Most “Big Bang” enterprise PLM systems offer an impressive, increasingly similar checklist of PDM functionality. However, the granularity of their out-of-the-box implementations with regards to CM capabilities is often limited to Change Management, BOM Management, & Document Management. The depth of functionality and nuances of usability for each of these functions can vary so much that it often takes weeks to fully evaluate and compare.
While enterprise PLM solutions can be customized to meet industry or site-specific requirements for CM, that project is not always as easy as it might seem. As example, one CM deployment feature that always generates great attention is Configuration Item (CI) management.
What exactly is a CI? Here are a few definitions found on the Internet:
“A Configuration Item (CI) is any component of an IT Infrastructure, including a documentary item such as a Service Level Agreement or a Request For Change, which is (or is to be) under the control of Configuration Management and therefore subject to formal Change Control.” Reference ITIL v2.
“A component of a system that is treated as a self-contained unit for the purposes of identification and change control. All configuration items (CIs) are uniquely identified by CI registration codes and version numbers. A CI may be a primitive system building block (e.g. code module) or an aggregate of other CIs (e.g. a sub-system is an aggregate of software units).” Reference www.chambers.com/au.
“Configuration items can be any individual, location or device connected to your account. By adding enough Configuration Items and their relationships, you can build up an interconnected database of people, machines and locations, which helps you maintain control over them and their affiliated incidents, changes and problems. In ITIL, this is known as a Configuration Management DataBase (CMDB).” Reference www.citrixonline.com.
“Selected items of system hardware or software (or combinations of hardware and software), in which the Government or acquiring activity has configuration management concern, are designated as Configuration Items (CIs). CIs are the basic units of configuration management. They may vary widely in complexity, size and type, from an aircraft, ship, tank, electronic system or software program to a test meter or a round of ammunition. Regardless of form, size or complexity, the configuration of a CI is documented and controlled. CI selection separates system components into identifiable subsets for the purpose of managing further development.” Reference MIL-HDBK-61A.
CI management is a basic must-have requirement that should be present in any CM solution out-of-the box. The capabilities of an integrated CI module should include the following requirements which prima facie look simple:
providing a means of defining the high-level product structure when in the conceptual phase of a program before any parts or documents are known
allowing users to cross-reference an additional identifier to hardware or software items and/or document records
allowing any item to be designated as a CI and tracked as such
Drilling down further, major features of this functionality should include the ability to perform:
allocation tracking of how many of each CI need to be produced or delivered per a given contract, with allocations that can be changed at any time and a history tracking log maintained
when allocation tracking is used, As-Builts should be compared to the available allocation per contract to ensure that allocation is not being exceeded
serial number tracking such that when a CI is designated as serialized or tracked, the CI functionality can be used to track usage of the government-assigned serial numbers for the product being produced; as the product is built the serial number can then be assigned to the proper as-built configuration record
CI structuring function which allows users to create parent-child relationships between CIs and where the list can mimic the engineering product structure, or be completely different, depending on the requirement
additional functionality such as block number assignment, action Items, notes, contract/project cross-reference, supersession, duplicate CI, vault and effectivity (based on part effectivity), and CI tree structure management relating to the CI record as stand-alone functionality
Here’s an example from CMstat’s product PDMPlus of one of these important features, serialization tracking for CI:
Once a CM requirement like CI is confirmed as available in a solution, it is important to evaluate it against expected use cases. Here are five examples of CI tracking use cases:
Identifying items of interest in the product structure such as: safety-critical items, hazardous materials, high-value items, life-limited items, and items with environmental impacts.
Allow users to build baseline records, as-configured records and custom reports using only the CI structure, thus filtering data captured to include only those items of interest.
Creating document structures that may be set up for the CI module to cross reference “documents only” so a ‘spec tree’ can be managed. Each document is cross-referenced to a CI and CI structuring is used to maintain all parent-child relationships.
Tracking of customer or government furnished equipment (GFE), especially if the customer has furnished serialized equipment, so that the serial numbers and usage of these items can be controlled.
Other functional uses include tracking product sub-sets or creating hypothetical or test product structure variants different from the EBOM.
The CI relationship can be used to link records together that would not normally be related via the product structure, but are required for a customer’s particular need. Here’s another example screenshot from PDMPlus of a CI cross-reference to a document and an item with effectivity.
In summary, the management of Configuration Items is a core function required by nearly all CM practitioners. As noted in the recent whitepaper “Nimble Configuration Management for the Contract Supply Chain” (available at our Downloads Page) there are those who prefer a big bang PLM implementation from a single software provider, and those that desire a more open, federated product innovation platform architecture using a robust portfolio of rapidly deployable best-in-class applications. Whether using a big bang PLM implementation, or an incremental best-in-class strategy, deep CI functionality should be immediately available and usable upfront without customization. Otherwise, by the time the road map of an enterprise PLM solution has been driven down to finally arrive at a time capable of addressing CM requirements, the underlying PLM solution or its customization may already be obsolete.
Receive CMsights
Subscribe to CMsights News for the latest updates from CMstat on Configuration Management, Data Management, EPOCH CM, and EPOCH DM.
Request a Demo
See how EPOCH CM and EPOCH DM support industry standards and best practices in Configuration Management and Data Management.
