Abstract
Since the effectiveness of the development and operation of scientific facilities (especially those presenting specific hazards, such as ionizing radiations) relies heavily on state of the art practices, such as systems engineering and product lifecycle management, configuration management (CM) is becoming a key management process. However, while some maturity models exist to assess the degree of the implementation and effectiveness of many management processes, such as project management or systems engineering, there is no specific framework available to assess the degree of maturity of an organization towards CM. This paper focuses on revealing the important maturity dimensions and levels for CM as a means towards developing a CM maturity model.
1. Introduction
There are many facilities in which development teams cannot eliminate all possible hazards. Scientific facilities, such as CERN in Geneva, Switzerland, or GSI in Darmstadt, Germany, involve the circulation of high energy particle beams, and as a counterpart have to deal with ionizing radiations. All these scientific organizations make tremendous efforts in mitigating as much as possible the consequences of ionizing radiation: they have all developed enhanced radiation safety management systems to optimize, justify and limit the radiation doses received by workers and the general public living in the surrounding areas. This effort is known as the application of the ALARA (or ALARP) principle [1]. In practice, this search to reduce doses has led to the optimization of interventions by better planning and, in some cases, the replacement of humans by teleoperated devices or robots. However, planning scheduling and performing interventions efficiently (whether they are manned or not) all rely on a thorough and updated knowledge of the facilities and systems, equipment and components that comprise them [2]. The reason for this could be explained better from the sources of intervention, presented in Figure 1.
Sources of intervention in scientific infrastructures
As can be seen in the figure, the sources of intervention in most cases incorporate changes in the facility, which in turn brings the requirement for accessing detailed knowledge about the current status of the facility before the change occurs, as well as updating this knowledge after the change occurs. Therefore, the availability of updated knowledge about the facility during its lifecycle will ease the planning, scheduling and performance of the interventions to a high extent and reduce mistakes, mishaps, unnecessary changes and loopbacks.
Thus, a key question is: how should we capture, maintain and use the knowledge associated with the facility all along its lifecycle?
CM is a managerial discipline that aims to provide for the consistency and accuracy of product knowledge throughout its lifecycle and - for the same purpose - it is being used to different extents in most organizations. The primary objective of CM is to ensure that in all the phases of the product lifecycle, changes to product components (such as requirements, design and “as-made” information for both software and hardware aspects, whether they are related to the facility itself or to the telerobotics means) are assessed and approved before being implemented, recorded and traced after implementation [3]. In other words, CM guarantees that facilities, including all the systems, equipment and components, are accurately described all the time [4].
Although the benefits of effective CM processes are prominent to all professional organizations, there have not been many studies elucidating a clear roadmap to evaluate their maturity in the field, prioritize their improvement activities and implement missing elements step-by-step. So far, CM has mostly been considered as part of other subject areas and, therefore, has not been covered comprehensively or with sufficient level of detail in maturity models [5]. Therefore, it would be highly beneficial for organizations (especially those operating in safety-critical areas, such as CERN) to have a framework by which they can evaluate their CM processes in order to uncover their gaps and focus on future improvements in a more efficient manner. The aim of this paper is to address this gap and to move towards creating a CM maturity model.
The rest of this paper is organized as follows. The next section includes the necessary state-of-the-art analysis towards developing a maturity model according to the maturity model design framework (Figure 2) proposed by De Bruin et al. [6]. This section presents the most important dimensions of CM and the critical activities under each dimension, which were extracted and formalized using extensive state-of-the-art analysis and a comprehensive review of current maturity models and standards in the field. Afterwards, the suitable maturity levels - which were developed according to the idea of maturity and organizational alignment utilized by Batenburg et al. [7] - are described in section 3. The next section includes information related to different aspects of the model gathered at CERN using qualitative research methods, such as semi-structured interviews, reviews of the organization's documentation and participation in a business process enhancement project. This was mainly done In order to check the reliability, validity and applicability of the findings and the model. Finally, section 5 summarizes the main results of this paper and draws conclusions.
Maturity model development phases [6]
2. State-of-the-art Analysis
2.1 Configuration Management
CM is a recognized discipline within the systems engineering field and is vital for every phase of a system's lifecycle. The history of CM goes back to the formalization of the discipline by the Department of Defense (DoD) in the 1950s for hardware, based on the need to reduce waste and duplication. Since then, and with rising complexity in projects, the importance of the discipline has been realized day by day, and it has focused on reaching out into software, documentation and processes, etc. [3]
With the aim of ensuring consistency between the reality and information about that reality, CM includes the following main activities [3, 5]:
Developing and maintaining CM plans, which will include a CM strategy, a standard CM terminology [8], responsibility distribution, the processes to be followed and the tools to be used.
Identifying configuration items as the system artefacts on which the CM and change control process will be applied.
Establishing and updating requirements and evolving a system baseline as snapshots of the at-the-time status of the system.
Establishing and implementing change control processes, including version and release management.
Maintaining the traceability of configurations in a way that all changes can be traced to the requirements.
Status accounting of the CM activities performed.
Performing physical and functional configuration audits to monitor the system features after the changes.
An illustration of overall CM activities that will be performed in each phase of the system lifecycle can be seen in Figure 3.
CM activities [9]
Implementing effective CM processes not only improves safety in organizations but also has a direct positive impact on return on investment, product lifecycle costs, on-time deliveries and product quality [3, 10].
A study carried out by Dvir et al. [11] illustrates that configuration control, as a part of project control activities, generally plays an important role in project success and providing customer benefits. The same study suggests that CM plays a vital role for projects in reaching their design goals, including their defined functional specifications, technical specifications, schedule and budgetary goals.
2.2 Maturity Models
Due to the particular importance of continuous improvement in organizations in obtaining greater competitive advantages, there is always a need for supportive tools to assess the “as-is” situation, prioritize improvement measures and control the progress of such improvements. Maturity models are the key tools to address these issues [6, 12].
A maturity model consists of a sequence of maturity levels, ranging from the very basic level to the completely mature level for each important criterion within the discipline being measured. By using detailed assessment techniques, such as questionnaires, document reviews and interviews, organizations can be assessed and positioned as per the maturity model. Next, investigating points of weakness and incorporating additional comprehensive knowledge into the model can allow for the prescription of an improvement scenario, including detailed implementation roadmaps aligned to an organization's strategic direction and goals. In this way, there will be a vision for the organization to reach this “to-be” situation in a step-by-step manner and efficiently [13, 14].
The main elements of maturity models, according to Fraser et al. [15], are: (1) a number of maturity levels, (2) a descriptor for each level, (3) the characteristics of organizations in each maturity level, (4) a number of important dimensions of the discipline being assessed, (5) important activities under each dimension, and (6) the description of the way in which each activity might be performed in each maturity level.
The Capability Maturity Model (CMM), Capability Maturity Model Integration (CMMI), project management maturity model, spice-bootstrap and systems engineering capability model are just a few of the successful examples of maturity models. By using them, many organizations have improved their processes and gained a competitive advantage in relation to their competitors.
2.3 CM in Maturity Models
The available maturity models in the field of business processes generally focus on business process development in general and, although some of them include requirements for CM, the requirements vary from model to model depending on the processes that they focus on. [5]
Capability and maturity levels in CMMI [16]
As an example of a need for complementary requirements in this maturity model, Gupta and RAO [18] acknowledge the role of IT tools for reaching higher maturity levels in CM practices, and they try to find matches between the CM process areas which are described in CMMI and the current IT tools to support them.
Program management, which focuses on management support in defining CM strategic objectives and policy, the physical scope of the CM programme, configuration item extraction and the roles and responsibilities involved in CM activities. It involves establishing clear terminology and knowledge sources, as well as identifying the core methodologies to be used in different stages of the CM programme. Furthermore, the information system that enables the organization to perform all its CM activities should be identified.
Design requirements, which include the establishment of formal design requirements for configuration items, as well as the identification of equipment lists and product structures to be used for the CM of configuration items (CIs). The CIs should be classified based on the most important design requirements and as such the degree of CM for each CI will be identified. New or revised requirements are identified by the CM authorities based on the organization's strategic mission, lifecycle phase and other relevant factors.
Information control and change control, which include the CM process and activities to be performed on receiving information, as well as physical entities for ensuring a match between the real facility in place and the available information representing the reality.
Assessment, which focuses on the evaluation of the organization's activities and processes to identify the potential for improvement.
Training, which comprises the utilization of different means of education for both personnel and stakeholders of the CM programme as to extent the knowledge and competence of resources in the enterprise [4].
The CM practices defined in SPICE are:
A CM strategy is developed.
All of the items generated by the process or project are identified, defined and baselined.
The modification and release of the items are controlled.
The statuses of the items and modification requests are recorded and reported.
The completeness and consistency of the items are ensured.
The storage, handling and delivery of the items are controlled.
The maturity of CM, according to the SPICE model, could be defined in the following stages [5]:
To obtain level 1, CM must be performed in such a way that the goals are fulfilled.
At level 2, CM should be planned and followed up as to performance according to the plan. The work products should be controlled with regard to both quality and integrity. Here, CM is a requirement for all process areas, including CM itself, to reach level 2 maturity.
At level 3, the CM process should be documented in a standardized way. The necessary resources for performing the CM (human resources, tools and equipment) should be identified and made available.
Level 4 requires that the CM performance and its results should be controlled through measurements and, if out of control, the process should be adjusted.
At level 5, the continuous improvement of the CM approach is ensured by using the process measurements.
Project integration activities [24]
For reaching different maturity levels in the project management integration knowledge area, an abstract of the various requirements is presented below:
Level 1 (initial process): The communication of the changes to the project manager and the team members is performed in an
Level 2 (structured process and standards): The scope of changes mostly follows a documented change control process. The scope changes are identified for large and highly visible projects and they go through a formal change request process to be tracked and approved. There is still insufficient control for cost and schedule changes, since baselining is not performed.
Level 3 (organizational standard and institutionalized process): There is a defined and documented change control system providing processes for scope, cost and schedule change controls using a change control form and change log. Changes are identified, assessed, coordinated, managed and communicated to the stakeholders and corrective actions are taken. The process is standard and repeatable, and baselines are established, maintained and managed.
Level 4 (managed process): All change and CM is integrated with the monitoring programmes and risk management processes. Functional, physical and data configurations are consistently documented, maintained, managed and controlled for all projects.
Level 5 (optimizing process): There is a full change control process on deliverables, which only initiates changes if they are fully understood, documented and approved by management after a value proposition. Project changes are included in the determination of efficiency and effectiveness. This is also the case for the evaluation of potential changes. There is a particular process for calculating these metrics and there is a continuous improvement process for the “project integrated change control process”. Historical changes in projects are examined to discover any trends and to improve the project planning process. [23]
The American standard
This standard also discusses the same standard processes for CM, including identification, change control, status accounting and the auditing of the product and the elements defining the product (e.g., requirements, interfaces and design representations, etc.) [25].
This capability assessment framework incorporates six capability levels, namely initial, performed, managed, defined, measured and optimizing. Each systems engineering focus area (including CM) is assessed based on its level of formality and standardization in the organization, and is located in the capability ladder. This is done by evaluating the application of pre-defined generic practices for each capability level and analysing each focus area's fulfilment level in relation to those practices (see [25]).
2.4 CM in Standards
In order to capture the essence of CM in a way towards developing a comprehensive maturity model in this area, in addition to the available maturity models there is also a need for a review of commonly used standards.
The CM activities defined in this standard are abstract and limited to the general steps of planning and execution. In the execution part, organizations are recommended to maintain configuration information with an appropriate level of integrity and to ensure the changes to the baselines are properly identified, evaluated, approved, incorporated and verified. For further information, this standard refers to ISO 10007.
In standard
This standard provides a more detailed description of what is expected in a CM plan. This demonstrates the importance of having a CM strategy and policy together with a clear set of defined roadmaps and methodologies, as well as clearly defined responsibilities and powers to be used in each process stage.
The US military standard
The importance of using a clear set of terminology for CM is acknowledged and followed in this standard. The main functions of CM introduced in this standard are shown in figure 6. These functions match the primary CM processes proposed by most other standards.
CM functions in standard EIA-649-B [28]
However, unlike most other standards, the focus on the planning and management of the CM discipline over the product lifecycle is of exceptional interest in this standard. EIA-649-B proposes the following main activities to be followed by organizations in CM planning and management:
Implementing policies and procedures, resulting in effective product CM.
Assigning CM functional responsibilities to various organizational elements.
Training of CM personnel and any others who have CM responsibilities.
Determining and applying adequate resources, including CM software tools and facilities.
Establishing CM performance indicators to serve as a basis for continuous improvement.
Ensuring the performance of CM by suppliers.
Integrating the organization's product configuration information processes.
Currently, the US Department of Defense (DoD) is in the process of releasing a new standard for CM (
2.5 Summary
In this chapter, CM practices and sub-practices in different maturity models and standards are analysed. A set of high-level CM aspects covered in the models discussed are brought below in Table 1.
Comparison of high-level CM aspects
3. CM Maturity Model
3.1 Maturity Criteria
The wide range of maturity models in different areas and the growing number of new models being developed shows the high range of applicability and acceptability of such models in various organizations. The reason might be the illustrated results and benefits of well-established models, such as CMMI, as well as the higher levels of interest and support from academic practitioners and their contributions to constantly enriching content and usability.
However, in considering CM as one of the primary support processes across all lifecycle phases, there remains a lack of individual focus on the discipline. In order for organizations to target shortcomings in their CM processes, there is a need to have a wider focus on the subject and measure its maturity among other business processes already in place. Furthermore, evaluating CM exclusively would give organizations the opportunity to realize the sole benefits of improving this process area for different purposes, such as investment justification.
In addition to the above discussion, as can be seen from the empirical studies, the availability of a mature CM system in some enterprises (such as safety-critical infrastructures) is vital and has a direct impact on their efficiency. Therefore, there is a need for such organizations to understand their specific needs in terms of CM activities and, accordingly, identify a customized and tailored roadmap based on their requirements. This could be facilitated by means of a comprehensive maturity model.
In the previous sections of this paper, the various functions and categories that influence the level of success in an organization's application of the CM discipline were discussed. Accordingly, and by the classification of the data, the authors propose five categories as primary dimensions of the CM discipline to be evaluated for maturity assessment purposes in organizations, as explained in Figure 7.
CM primary dimensions
In sequence, the sub-categories in each dimension are illustrated in Figure 8. These sub-categories are extracted from both the analysis of the models and standards in the previous chapter and various sources focusing more specifically on different aspects of product lifecycle management and CM, such as [7, 29, 30, 31, 32].
CM sub-categories
3.2 CM Maturity Levels
The maturity levels represented by CMMI and models using similar levels cannot match the assessment methodology used for this maturity model. The primary reason for this is that the scope of the maturity assessment for the CM maturity model is limited to a single discipline, whereas CMMI has a comprehensive organizational business process focus. In CMMI, the application of different disciplines or practices in each level specifies an organization's maturity improvement. For this purpose, the practices being assessed have different priorities and should be implemented in a sequence for the organization to achieve higher maturity levels [Figure 4]. However, in the proposed maturity model, various dimensions of CM are correlated and should be applied together for the organization to benefit from the discipline. Nevertheless, as two of the support disciplines in systems engineering - product lifecycle management and project management - the extent to which these disciplines permeate into the organization's structure and activities could be a good indicator of the level of the organization's maturity in this discipline.
Therefore, the concept of maturity and organizational alignment as utilized by Batenburg et al. [7] is used for categorizing different maturity levels of organizations with respect to their CM activities. Figure 9 represents the authors' proposition of four maturity levels.
CM maturity levels
Considering the CM maturity dimensions and sub-categories discussed in the previous chapter, a detailed description for organizations fulfilling the requirements for each maturity level is proposed below.
CM requirements have not been considered in the choice of information technology. Therefore, only a few of the required functionalities are supported in the projects. In the best case, the functions are performed by self-developed tools that are either offline or else not clearly connected to the main IT system.
The importance of CM is understood by some of the personnel in charge of specific projects, and only in those projects is the implementation of the discipline supported. However, the terminology introduced at the beginning of the project is based on limited knowledge and is different from project to project. CM roles and responsibilities are assigned at the beginning of each project and vary depending on the specific opinions, knowledge and experience of project managers involved in different projects. An information system - whether developed in-house or chosen from COTS products - is used for the CM activities and requirements of each project. There may be similarities among the systems used in different projects, but there is no single standard choice or framework for choosing the IT system for the whole organization.
The importance of CM is understood by the higher level management of the organization and they support the implementation of the discipline. A standard and specific CM terminology and knowledge source is in place, which is developed based on the CM expert's knowledge.
CM roles and responsibilities are assigned in a standard way at the beginning of most/all projects based on both the organization's and the specific project's needs. The standard functionalities of CM are the rationale behind the choice of information system; however, there is no regular benchmark for updating the IT system. The IT system is standard for most/all projects and, therefore, there is a central repository for all information.
Standard CM processes are defined for the whole organization and are accessible in a central process repository for all stakeholders. These processes have specific owners who are responsible for providing training and developing processes further by collecting field feedback. There is a clear methodology for change management, which involves clear guidelines for cross-functional change impact analysis. CM terminology is distinguished from other disciplines and standardized throughout the whole organization. This set of terminology along with a CM knowledge base is available for all stakeholders and correct usability is assured.
Wise decisions about whether to have a centralized CM organization or whether to scatter CM-related personnel among projects is taken based on the complexity level and specific requirements of the organization. Clear roles and responsibilities are defined and communicated to the employees. There is organized practical training for CM that is consistent throughout the organization and the knowledge captured from different situations in different projects is used for updating the training. The CM support level comes from the top management and is deployed at the operational level. Management promotes internal and external benchmarks related to CM features, and overall the CM discipline in the organization is continuously improved. When choosing information technology, the CM functionalities and requirements are taken into consideration. Any IT system to be used is first checked for correspondence and alignment with the main IT system of the organization. The information is globally available throughout the whole organization and a clear authorization system is in place for creating using and modifying any information.
4. CM at CERN
The information in this section was captured using three types of qualitative research methods. First, semi-structured interviews with engineers involved in CM and product lifecycle management activities in some projects were performed. In the meantime, related data was obtained from regular meetings associated with a process enhancement project with participants from different departments. The information was complemented by a review of the related organizational documentation, such as quality assurance guidelines and process definitions. Next, the information associated with the important CM practices, historical examples, requirements and possible solutions, are characterized and presented in this section.
In general, the lifecycles of equipment and facilities in scientific infrastructures such as CERN are very long in such a way that one generation of employees design and develop the equipment while it is likely that it will be up to the next generation to operate it and perform maintenance, services and disposal. Therefore, in such facilities, the importance of having safe and sound processes for capturing knowledge and insuring its consistency throughout this long lifecycle is of great importance. Moreover, higher levels of organization and product complexity automatically raise the need for more accurate information about the facility. Therefore, there is always the potential for optimization in business processes and activities to survive the chaos and maintain competency at a level high. The following comprise the understood requirements for further improvements in the CM discipline at CERN based on the CM maturity dimensions.
Considering the complexity of the facility and the interdisciplinary nature of activities (the involvement of people from more than 17 disciplines in each accelerator development project, for instance), the use of the same vocabulary for addressing different objects and functions is not unexpected. This is also the case with the CM terminology. Therefore, the importance of having a clear set of terms and definitions for each discipline is paramount and realized by CERN.
When a facility like the Large Hadron Collider (LHC) is in operation, there is a great deal of equipment involved that is not easily reachable after installation in the underground tunnels. If their design information does not match with the reality, it is likely that a lot of time and manpower will be spent capturing the missing knowledge. A good example is the CERN's proton-synchrotron (PS) accelerator facility. The PS is the oldest accelerator still in operation at CERN, which first accelerated protons in 1959 and has played the role of supplying other accelerators after new ones were built [33]. This facility has undergone many modifications over the years to optimize and enhance its functionality. Due to a lack of technology and problems associated with hard-copy archiving the consistency between the facility documents available and the reality has not been completely verified during its lifecycle. Therefore, there are resources and activities dedicated to acquiring more knowledge on-site and ensuring such consistency. Having a clear long-term CM strategy supported by standard policies during the long lifecycle could be effective in that it could lead the organization towards ensuring the application of the CM discipline in all lifecycle phases as well as in every environment.
KPIs [34] are frequently used in optimization-oriented organizations for measuring the performance of a practice or discipline as a means of evaluating the level up to which the organization has been able to reach its strategic objectives in the field. For CERN, this functionality for CM has been limited to some organizational units. Configuration managers use unofficial metrics to measure their periodic performance in the field. However, having CM-oriented strategic objectives and capturing the correct information for the metrics in the operational field affects this process. The deployment of the organization's overall strategy into different functions and units assists the organization in achieving its vision faster and in a more efficient manner. As an example, CERN has strategic objectives for the medium- and long-term operation of the LHC, including future upgrades. This objective could also be deployed into a CM objective as a goal for fewer failures or change requests due to measured and observed inefficiencies and informational inaccuracy, and might eventually be measured via suitable KPIs.
Sometimes, processes are not standard and/or are not applied to all organizational units, equipment or functions. A simple example would be information about the current state of the cables in the LHC which, due to the various corrective and preventative maintenance operations (as well as consolidation and upgrade activities performed by different groups or even, occasionally, subcontractors) could be particularly dependent on the processes. Cases might arise whereby operations such as maintenance or updating do not capture the relevant information about the cables, causing important safety and reliability risks later on or else simply resulting in the need for longer times for future interventions. Therefore, the standard processes of configuration identification and baselining, change control and status accounting, and regular configuration audits, should be clearly defined and standardized among all the actors involved in modification activities. The importance of such processes is greater when dealing with emergency situations, such as emergency corrective maintenance which, due to the high safety requirements of the facility, is on call 24/7. Since the word “emergency” sometimes carries the green light for deviation from the standard processes, it could result in facility being modified without capturing the relevant knowledge. Therefore, having standard processes designed for this kind of situation is of a great importance in ensuring CM functionality and quality across the lifecycle.
One of the most important criteria in CM processes when evaluating the feasibility or applicability of a change request is the consideration of its impact on other configuration items. Usually, changes are categorized with respect to their scope and the extent of their impact. Therefore, there should always be clear processes for analysing the effect of changes on other equipment, which might sometimes be owned by other organizational groups. The long time needed for communication and inquiries among groups before performing their activities might sometimes lead to this impact analysis being neglected and future reworks or safety issues occurring. With CERN's LHC, for instance [35], changes go through a strict and systematic evaluation process for categorization. Changes affecting costs, schedules and the performance of the whole facility as well as the form, fit and function of the product structure, should go through a change management process for approval. The process in use is given in Figure 10. Due to various costs and the duration of formal change processes, it is not desirable to have all changes go through the formal process prior to their implementation [36], especially quick corrective maintenance repairs. Therefore, some changes are performed instantly and their impact on other equipment are analysed based on the knowledge of the personnel involved in the activity that led to the change. A simple example is the autonomous change of one part which, due to a change in form, fit and function, has blocked the maintenance access to other piece of equipment. This issue is more likely in older facilities where the information about the configuration in place is not clearly known. Therefore, in considering such use cases, the processes should be updated to include a good level of change classification and impact analysis, as well as a responsibility distribution, so as to reduce the risk of important and influential changes being implemented without going through the evaluation process. Moreover, the application of these improved processes should be supported and enforced by upper management.
Change management process as implemented in CERN's LHC [35]
Most of the CM functionalities could be performed with the help of IT. Functions such as managing configuration items, developing baselines, naming and numbering, versioning, requesting changes, evaluating change proposals, aligning physical equipment (assets) with the design documents and requirements, recording and reporting information and performing audits, could all be supported by an effective information system. At CERN, this is done with the help of several information systems, which used for different purposes or lifecycle phases. The accessibility of this information and its ease of use in this complex environment (with millions of items) are of great importance. Moreover, the outsourcing of activities along the facility lifecycle introduces the requirement for subcontractors to use the same CM information system so that the activities are harmonized [32]. Therefore, the choice of information system fulfilling CM needs throughout the facility lifecycle should be made wisely, and the interfaces with other disciplines in the organization should be considered so as to minimize issues such as repetitions in data entries and data losses.
One of the most common issues occurring across industries is being kept busy in dealing with daily issues and forgetting that, sometimes, effective solutions can be found outside. In the case of CM, CERN is not an exception. There have not been very many benchmarks performed at CERN in terms of the best practices of other similar industries (and if performed, the results of such benchmarks have not been distributed). This does not only apply to the application of the CM discipline, but is also missing in the evaluation of CM information system tools available on the market. In order to continuously improve the processes and solve the issues experienced, not only should internal benchmarks from best practices be performed but so too should external success stories be used and distributed among the involved personnel.
In large organizations, the roles of the different actors in the value-stream should be monitored so that inconsistencies are avoided. This is also the case with CERN, which is an open organization and involves many actors in different activities. An example could be the use of subcontractors for maintenance work, which involves making the facility information available for them and allowing them to autonomously modify the facility during their operations. However, the importance of capturing the information about operations and modifications for CM purposes was discussed before. Therefore, a standard policy and process during both contract negotiations and work inspections should be in place so as to avoid information loss. To be solution-oriented, this could be made similar to the Japanese “poka yoke” concept [37], which refers to providing the means in place for avoiding ordinary human errors.
The modification of the organization's processes and routines is not in itself liable for the improvement of CM activities. As is the case with any change management activity in organizations, the involvement and support of high level management as well as the availability of suitable training accessible by everyone will supplement the change. Continuous training for CM ensures knowledge transfer among employees and facilitates a means of guaranteeing feedback from people using the CM tools for further improvement, corrections and the coverage of new problems. There has been a positive culture at CERN for all the various projects and the results show a better understanding and cross-functional collaboration among all stakeholders. The management of development projects at CERN could be a good match to the chief engineering system described in detail in [38].
5. Conclusion and Future Work
According to the findings in this paper, the level of maturity of an organization's CM activities is not solely dependent on its processes, and other factors such as its strategy and IT, etc., are crucial. The maturity dimensions, sub-categories and levels described in the previous chapters could be useful for organizations - especially in safety-critical environments - in their continuous improvement activities towards the better application of CM and, consequently, a higher return on investment, a lower lead time and higher safety, by facilitating less intervention.
In future, according to the findings in this paper, a suitable appraisal material will be developed for evaluating the current situation of CM activities in various target organizations. This is, to some extent, performed and the results can be found in [39].
The next step would be to develop clear roadmaps for improving the maturity of organizations from their present maturity level to the next by prescribing suitable improvement practices.