Asset Lifecycle Configuration Management

In this CMsights article we will examine the relatively new practice of Asset Lifecycle Configuration Management (ALCM), including how it is similar and different to product-centric CM, and the evolution in the use of CM software in industries with long-life products that have ALCM requirements.

As a starting point, a widely universal business definition of Configuration Management (CM) is the application of resources, methodologies, processes, best practices, standards, governance policies, and software tools to establish and maintain consistency and traceability between product requirements, the actual product as manufactured and serviced, and associated product data for all the creators and users of this information.

Regardless of the industry or application, the implementation of configuration management must support the foundational elements of CM which are: configuration planning, configuration identification, configuration status accounting, configuration change control, and configuration traceability and audits. The processes must all be part of a formal CM Plan, which is much more than just planning for the use of PDM or CM software. (Read more about that difference between a plan and planning in this CMsights article.)

Over the years the principles of CM have found use with proven value across numerous industries.  The first applications of CM arose during the 1950s in aviation, aerospace and defense where the complexity of products, including their design variants and long service lifecycles, required more than just rudimentary change control.

Now, some digital consumer products have more inherent complexity than early-era aircraft. It is not uncommon that a product portfolio is composed of a large number of variant products, each with different hardware and software configurations, to serve the needs of different international markets that use a vertically-integrated regional supply chain of numerous partners for sourcing and servicing. The n-dimensional matrix of product lines, individual products, geographical markets, suppliers, and resulting configurations is staggering.

The result is an explosion of complexity in products, processes, and partners each which can impact the final configuration. As a consequence, the practice of CM has evolved from a departmental engineering function, relegated to experts, to become an enterprise quality management mandate. This change in the role of CM has become valid for many industries beyond A&D which now includes transportation, marine, high-tech, energy, industrial machinery, AEC, and software development. More recently the newer industries with growing product portfolios of life sciences, medical devices, biotech, renewable energy, and digital consumer products have also adopted CM as part of their corporate quality programs and supply chain strategy.

This can be seen firsthand when looking at how the attendees of CM training programs and CM conferences, like those provided by CMPIC and Institute for Process Excellence have changed over recent years. Participants once came largely from the aerospace, aviation, or automotive industries. Now, those attendees are often in the minority. This diversity trend is accelerating as more training programs go virtual which lowers the cost barriers to attend for emerging industries and markets around the world.

As the role and reach of CM has expanded, so has the composition of those who participate in developing, adopting and revising standards. This trend is most evident when inspecting the history of CM-related standards such as Mil-STD-973, MIL-HDBK 61a, ISO 10007, and now ANSI EIA 649. (Learn more about all the different CM standards HERE.)

How CM Tools and Users Have Changed

The earliest CM software tools were spreadsheet beasts that required a herculean effort to understand, use and maintain. Limitations in these gave rise to successively more capable generations of specialized software tools for CM. Yet, most were still focused on meeting the needs of the OEM product engineering user who was the resident CM expert. These users were happy to see rudimentary change control functionality within the PDM tools they were already using, even when it was rather limited or elsewise required customization to enable true CM.

Rarely did these tools satisfy all the CM requirements and use cases of long programs, large projects, or complex extended-life products. As a consequence, companies were left to either write their own custom software, which became expensive legacy codes to maintain, especially as their original developers retired. Others avoided that by acquiring industry-specific best-in-class off-the-shelf software solutions like those first made available from CMstat over twenty years ago. (Read more about the evolution of CM software HERE in which we at CMstat were proud to have been part.)

As the use of CM practices and CM software expanded over the years, what changed the most was who the actual users and benefactors of configuration processes and data became. No longer are product design engineers the primary creator, reviser, or consumer of CM data. Downstream users in logistics, procurement, quality, tech pubs, service, maintenance, and sustainment have grown to become the biggest users of configuration data. This is good news as it validates the growing role of CM processes, products, and practitioners across the long winding digital thread that flows through the OEM enterprise, its upstream supply chain, and downstream service partners.

Asset Lifecycle Configuration Management

One of the fastest growing applications of CM is for Asset Lifecycle Configuration Management (ALCM). Across many industries, managing the in-service configuration of long-life assets over their extended lifecycle of many years is a far more important use of CM than that in product engineering. As a result, there are more users of CM data and software outside of the traditional engineering functions than within an OEM. This is especially true in the supply, support, and service chains of high-tech equipment manufacturers whose systems are deployed and maintained in the field around the globe. 

The mission-critical application of ALCM can be found in many industries including: aviation, aerospace & defense, industrial machinery, heavy equipment, transportation mobility, high-tech electronics, medical devices, energy, mining, marine, and AEC infrastructure. For these industries the process of tracking the as-procured, as-built, as-installed, as-deployed, as-maintained, as-repaired, and as-retired configuration of products, equipment, systems and networks far removed from the OEM’s original CAD or PDM vault is THE critical use case of CM.

For these uses of CM, engineering PDM software nor enterprise PLM systems provide the broad functionality, workflow adaptability, and robust usability required for performing ALCM by users in the supply, support, and service chains who are not CM specialists. Asset CM software, even more so than product CM software, requires broader functionality for product structure maintenance, configuration identification, baselines, configuration items, change management, status accounting and verification. And it must do so with agile workflow processes that are robust without loss of usability, data integrity, and reliability when employed by occasional non-expert users, not just CM specialists in product engineering.

Problems Addressed by ALCM Solutions

Old and new assets with life expectancies of decades are kept operational only by continual repairs, upgrades, and life-extending refurbishments.

While the range of products and processes varies a great deal within industries that manufacture and sustain long-life assets, the challenges and problems which CM addresses are quite similar. Which of these does your industry or organization experience?

  • The sheer volume, complexity, permutations, and variations in configurations of component parts, product deployments, and complete systems overwhelms legacy methodologies and tools

  • The actual as-deployed or as-maintained configuration has evolved to be very different from what was as-shipped or as-installed, and no one person or system knows the complete history

  • Lack of confidence in producing upon-demand real-time live configuration data of a deployed asset by specific lot or serial number or location

  • Where-used discovery and change-impact analysis on as-deployed equipment is unwieldly or untrustworthy

  • Management of processes that create, use, or revise downstream configuration data are absent, ad hoc, or broken; much less automated, optimized, and measured

  • Losing control of the change control process due to changes being made without approval or change history information unavailable, lost, inaccurate, or obsolete

  • Losing control of configurations after delivery from not having visibility to what components were installed or replaced on serialized assets

  • Difficulty in keeping all the different or downstream BOMs accurate and synchronized with engineering changes across all product variants by lot or serial numbers

  • Parts produced, shipped, or installed for the wrong configuration without visibility to alternate or substitute parts that are authorized and available due to faulty communication or superseded documentation

  • Service contractors not having access to the OEM’s product configuration data or being overly-constrained to use only that data which may be obsolete

  • Software maintenance version releases installed were found not compatible with hardware configuration of the deployed asset

  • Installation instructions, work orders, test procedures, training manuals and service bulletins are often in error or obsolete because of configuration inaccuracies

  • Configuration of digital twin models for service reference use is hard to create or maintain, much less synchronize with the actual physical asset

  • Completeness, accuracy, and security of data retention, document repository, and LOTAR requirements is undependable

  • Unable to maintain, document, and track ITAR compliance requirements

  • Failing the Product Configuration Audit mandated by the customer contract or program office

As a consequence, the managerial oversight of programs, projects, products, and profits suffers due to a lack of visibility and attention into these very-realistic CM challenges. Or worse, complete failures occur in components, equipment or systems in use in the field that impact financial performance of a business or even risk the safety of their customers. 

As-X Configuration Management

Scanning the above list leads to the conclusion that the most challenging task within asset-oriented CM is tracking all the many different “As-X” configurations. By this we mean the as-procured, as-manufactured, as-shipped, as-installed, as-certified, as provisioned, as-maintained, as-serviced, as-refurbished, and as-retired lifecycle stages of the asset.

The fundamental functions of CM for providing As-X management are the same as those in engineering, but their focus is different in obvious and nuanced ways as referenced in these examples.

  • Identification – Focused on identification of specific physical assets and not just focus on Configuration Items (CIs). This identification items can include serial numbers, versions, reference designators, software version information, government IUID, bar codes, etc.

  • Planning – Configuration Plans and configuration planning should also reference timely update of the as-maintained configurations and scheduled maintenance.

  • Change Management- Change processes to address notification and implementation of changes to fielded products must be included. Change impact assessment should address time of taking product out of service. Change audits must involve a physical audit of configurations to validate and verify change incorporation.

  • Product Structure Management – Product Structures may not and usually will not strictly follow the ‘design’ product structure used in the PDM data. Alternate and substitute parts may have been necessary.

  • Verification and Validation – Verification must be performed per change management and validations can now include scheduled maintenance.

  • Configuration Status Accounting – Status Accounting needs to be able to produce product planning information as well as current configuration including all changes either as a result of normal scheduled maintenance or change implementation.

(Read more about these challenges with examples in this CMsights post on As-X Configuration Management in the Aerospace and Defense industry.) 

Asset Lifecycle CM Software

It should be obvious by now that the requirements, users, and applications of asset CM are sufficiently different than that for product CM. Because of the wide variety of use-cases, the demands upon ALCM software functionality are more extensive, despite the majority of users being less experienced. As a result, software providers like CMstat have responded by developing a new era of nimble CM software tools to satisfy these competing needs.

EPOCH CM© is CMstat’s next-generation software product for Asset Lifecycle Configuration Management. EPOCH CM offers a rapidly deployable, instantly usable, easily extensible, and swiftly affordable web-based solution for managing the live configuration of in-service products, deployed equipment, remote systems, and other long-life assets along with their virtual digital twin representations.

EPOCH CM was developed to support program managers, project leads, product engineers, supply chain contractors, sustainment personnel and MRO operators with an agile CM software tool that could be quickly implemented on an as-needed basis with a minimum of IT support resources.

EPOCH CM provide users with the most comprehensive set of Configuration Management capabilities required for managing, documenting, tracking, and reporting changes to the past, present, and future configuration states of products, equipment, systems, and other assets deployed in-service for years or even decades. To explore all the features of EPOCH CM which support ALCM start with this introduction HERE.

Coming Next: A Demonstration of ALCM Workflow Process

In the next CMsights post we will provide a recorded demonstration of the use of EPOCH CM in an example workflow process taken from the support and service chain of an A&D OEM manufacturer.  In this demo, we’ll take a look at the downstream users of PLM data and the functions these users need from a CM software system by running through an example of As-Built configuration data that is central to performing supply and service chain tasks.  Users of this type of data need interfaces that are: easily digested, searched and manipulated with minimal training; standards-based CM rules and practices built in; ease of use and maintenance of configuration data; and of course, traceability and complete product history. This example will run through definition of configuration and associated product data, establishment of the As-Built configuration and how changes will be processed during the service life and through disposal.

Until then, to request a live demonstration of EPOCH CM, send us an email at information@cmstat.com. To follow the discussion and growth of ALCM register HERE to receive future editions of CMsights.

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.


Follow CMstat


Recent Posts


CMsight Topics

Previous
Previous

Asset Lifecycle Configuration Management Demo Using CMstat EPOCH CM

Next
Next

CMstat Announces Release of EPOCH CM for Asset Configuration Management