Keywords

1 Introduction

Industry 4.0 is the well-known paradigm characterizing the last decade of manufacturing transformation built upon digitization. Amongst the fundamentals of Industry 4.0, Cyber-Physical Systems (CPS) are the building blocks to develop future smart factories [1], bringing to the emergence of many characteristics such as the connectivity and the networking capabilities, the high degree of autonomy leading to self-capabilities (e.g., self-awareness, self-diagnosis, self-healing), the use of sensors and actuators to collect information about the physical operations in real-time. All in all, it is leading to a basis to build advanced systems to monitor and control the industrial assets along with their degradation. This capability leads to provide a detailed insight on a production system and its assets, which finally promotes maintenance as a key function to achieve operational excellence based on digital capabilities. Therefore, the manufacturing companies are becoming sensitive to this new role; indeed, the current evolution is now determining a perception of maintenance as a data-driven decision making process [2].

This perspective is not yet systematically integrating the evolution of the management discipline towards the inclusion of a lifecycle perspective as promoted by the Asset Management approach. Looking at maintenance in this extended scope, requires to embrace a wider digitalization to support the Asset Management (AM) system [3]. This should consider that the set of decisions is larger than the ones maintenance is used to, and theory is correspondingly extended [4]. Henceforth, it is worth pointing out that the ever-growing number of data sources is not reflected consistently in advancements of maintenance support systems: nowadays as in past years, most of the effort appears to be put on enhancing and improving computerized maintenance management systems (CMMS), see some recent studies such as [5,6,7]. Nevertheless, the adoption of AM by global players has further exacerbated the already existing criticalities related to information and data management solely bounded to the maintenance scope [8, 9]. This motivates the need to reflect upon the IT ecosystem of industrial software tools, as the CMMS appears to be not enough for meeting the challenges brought by AM in a global manufacturing context.

Indeed, we believe that there is a need to review the IT ecosystem on which maintenance is relying, by extending its functionalities and scope of work towards a more AM-oriented ecosystem, to finally comply with future evolutions integrating the lifecycle management of complex industrial facilities. This is particularly escalated for those companies owning multisite production systems since it involves both local and global management of the operations. To this end, this research aims at proposing a conceptual structure of the IT ecosystem, with the purpose to extend the “traditional” CMMS functionalities with the new ones claimed by AM needs.

For what concern the methodology to accomplish the objective of the research, two steps enable building the conceptual model: firstly, a systematic review of the scientific literature aims at summarizing the functionalities related to CMMS as consolidated basis; secondly, a review of the literature, including also selected references from grey literature, enables to integrate AM-oriented functionalities. Findings bring to locate the CMMS functionalities and to integrate the AM-oriented ones within a structure of three asset control levels (operational, tactical, strategic); it finally leads to establish a hierarchical structure of software families with their own uses.

Furthermore, the conceptual model has been developed along a collaboration with a world leading company of the food sector, challenged by the need to coordinate the management across geographically dispersed production plants. This collaboration allowed to collect feedbacks and insights relevant for future improvements.

The paper is so structured. Section 2 deals with the literature on the CMMS functionalities. Section 3 describes the proposed model of the IT ecosystem for global AM. Section 4 discusses the lessons learnt from the project, valid for large enterprise acting at global level. Finally, Sect. 5 draws conclusions and envisions future researches.

2 Literature Review on CMMS Functionalities

The CMMS functionalities are identified through a systematic literature review (SLR) on WoS (Web of Science) database. The research protocol is so defined: keywords (maintenance AND CMMS), only English-written documents and restrictions only to the field of Industrial Engineering. The searching process results in a set of 52 papers. A further screening process is performed, looking at those CMMS functionalities useful to manage the assets; the screening does not consider user-related characteristics like “ease of use”, important for selecting software [10] but out of scope of this research.

Figure 1 reports the agglomerated results, showing the main functionalities of the CMMS as retrieved in the analyzed documents with relative frequency of citations. The identified functionalities could be grouped in modules since some of them are parts of the same process, e.g. issue work order and record work order are functionalities grouped under the Work orders management module. The derived functional modules are Report management, Information and data management, Work orders management, Maintenance planning/scheduling, Spare parts management, Budget/Cost analysis, Supplier management. The relative citations of the modules are summarized in the top right-hand part of Fig. 1 as collected from the selected papers.

Fig. 1.
figure 1

CMMS functionalities and their grouping modules.

The identified modules are the consolidated basis to support maintenance management; the IT ecosystem for global AM will be completed by AM-oriented modules.

3 Model of the IT Ecosystem for Asset Management in Global Manufacturing Context

It is widely recognised in maintenance and AM literature the existence of three control levels in order to better manage the assets: operational, tactical and strategic (see [11] for maintenance management, and [4] for AM). Therefore, the whole set of modules could be framed in a three-level structure in accordance with the asset control levels. The discriminant to assign a module to a specific control level is its scope of work [12]:

  • Operational control level involves day-by-day activities aiming at work task controlling at tactical level, and measurement and reporting of technical performance always in compliance with what required at the tactical level;

  • Tactical control level is devoted to the coordination and planning of tasks at operational level, and to the control and reporting of KPIs (Key Performance Indicators) to orient decisions towards the strategic level;

  • Strategic control level includes analysis and evaluation of feedbacks from tactical level and provide long-term guidance for the tactical level.

It is worth noting the central role of tactical level that works as an important junction to align business objectives with day-by-day activities. Table 1 shows the result of the allocation of each functional module to a control level. The AM-oriented modules are extending the scope with respect to what presented in Fig. 1, restricted to CMMS only. These other modules derive from a selected reading of the scientific literature (indeed, limited to a few and recent publications) integrated by some blueprints derived by the grey literature. A kind of noticeable blueprint, defined courtesy by the vision of Gartner, shared by IBM, is raising the attention on modules that enable to make the so called Asset Performance Management (APM) and Asset Investment Planning (AIP), in order to enable an extended vision towards a long-term strategic management of capital assets, building on tactical and operational levels of activities already in place [13]. The corresponding reference highlighted in Table 1 are taken from the scientific literature.

Table 1. Conceptual model of IT ecosystem: allocation of functionalities to control levels.

In Table 1, AM-oriented modules majorly cover the strategic level, while the tactical level includes those modules that implies the definition of the plans driving the operational tasks. To this end, System modelling and assessment is central since an asset/system model is needed to support maintenance planning and risk management. Moreover, also Risk management is placed at tactical control level since we mainly refer to operational risks. Strategic risks, like demand volatility, must be tackled at corporate level. They influence decisions at AM strategic control level as capital investment planning.

The three-level structure of the IT ecosystem for global AM can then be correspondingly related to software families proposed on the market [13]. Therefore, it is possible to associate to each control level a precise software family:

  1. 1.

    Operational control level: Enterprise Asset Management (EAM) software that aims at governing shop-floor activities and reporting performance indicators to support better planning. Historically the CMMS and the EAM were not clearly differentiated, as described in [19]; indeed, the difference was blurred in past discussions; anyhow, [20] notices that the difference may reside in the fact that the EAM is enterprise-wide, while the CMMS is local.

  2. 2.

    Tactical control level: Asset Performance Management (APM) software, which aims at transferring the long-term business objectives to medium-/short- term decision, in relation to maintenance plans, suppliers and risk management, by developing component/system models determining performance.

  3. 3.

    Strategic control level: Asset Investment Planning (AIP) software; it is devoted to govern the entire asset portfolio/fleet, by establishing proper capital investment decisions to respond to business needs.

The hierarchical structure of the IT ecosystem for global AM is represented in Fig. 2. The three-level structure allows to join the business objective/needs with current asset functioning/condition, thus creating a virtuous loop that makes strategic decisions aligned with operational tasks and vice versa.

Fig. 2.
figure 2

Proposed IT ecosystem for global AM.

Figure 2 proposes also an integrated view with the lifecycle stages of the assets. Moreover, it offers a first insights a lesson learnt on global/local deployment of the EAM to enhance centralized AM for global operations, as better described in Sect. 4.

4 Lessons Learnt on the Proposed Model of the IT Ecosystem

This section summarizes lessons learnt from the implementation of the proposed IT ecosystem during a collaborative project with a world leader food company. The proposed model helps in better framing the existing software tools and platforms the company already owns to boost centralized AM over geographically dispersed plants:

  1. 1.

    Integration of activities along the asset lifecycle stages;

  2. 2.

    Support to local/global deployment of EAM, APM and AIP software families;

  3. 3.

    Implementation of risk management in APM, enabled by system modelling;

  4. 4.

    Management of data ownership through role-based module access;

  5. 5.

    Support to technology planning of the IT ecosystem evolution.

1. The three software families allow an integration of the activities done on the assets over all their lifecycle (BoL – Beginning of Life, MoL – Middle of Life, and EoL – End of Life). To this concern, an important challenge may typically regard the interface between the BoL and the MoL: a mismatch between what designed for the assets and what performed on the assets, tends to exist as a consequence of the lack of complete information and the partial data exchange between software systems.

2. The IT ecosystem allows to discern between software systems to be used at local level and at global level for centralized control in a global manufacturing scope (see the global/local perspective raised in Fig. 2). On one hand, the EAM is envisioned to have primarily a local usage, being integrated in an enterprise-wide perspective; on the other hand, the EAM has also a global use since it may enable an auditing system to control the correct implementation of decisions taken at tactical level, e.g. maintenance plans. To complete this viewpoint, APM has also a global perspective as it helps to translate the business objectives to the local production plants. As recommended within our conceptual model, this can be accomplished by means of the relevant lever of risk management (see next point). At the top, AIP is also carried out at the global level as it relates to corporate management tasks to achieve the business objectives.

3. Implementing an adequate risk management for AM is to be considered as a fundamental pillar of the integrated methodology discussed in the perspective of global/local deployment of software families. In particular, the operational risks must be managed at tactical control level within the APM software family. In order to comply with this vision, we may assert that a platform for APM is useful since it integrates the functionalities available in the EAM. The APM should be based on an accurate system modelling of each production plant in order to enable risk management through a performance-driven total cost of ownership evaluation (based on similar steps as described in [21]); at the tactical level, this would enable to translate the business objectives into day-by-day activities, driving any planning decision by relying upon a systemic perspective of the entire production plants (which is one of the principle of AM [4]).

4. The proposed three-level structure helps in defining a proper data ownership strategy. By separating the three asset control levels with as many software families, the access to information could be better managed and shaped according to the key users and their roles. When a global AM organizational department is present, composed by local maintenance managers, global maintenance managers and a global asset manager, this would lead to restrict the access to EAM to maintenance managers only, both local and global, while a more tactical and strategic level would be prerogative of the global asset manager and the asset management team.

5. The proposed model of IT ecosystem for global AM may support both a medium-term and a long-term planning of the IT development. In the medium-term, it is possible to establish a plan aimed to integrate or substitute functionalities/modules at each control level, to enhance a better centralized control, and between lifecycle stages, to share design and operational data. In the case of a more long-term perspective, a more cumbersome and demanding activity of re-structuring the entire IT ecosystem may be considered, to renew an extant ecosystem to better support a central control for global AM.

5 Conclusions

This research aims at proposing a conceptual model of the IT ecosystem for global AM. The IT ecosystem is built on the CMMS as basic software used for maintenance; therefore, a systematic literature review is used to collect the functionalities already implemented in the CMMS; as literature findings, a synthesis of these functionalities in modules is performed (see Fig. 1). The functionalities are also integrated with AM-oriented modules identified from additional scientific literature and even from grey literature, in order to look at the IT vendor perspective to consider the relative novelty of such kind of systems. All the functionalities are allocated to the three asset control levels defined in the AM theory (see Table 1), leading to the final contribution of this paper.

The proposed model of the IT ecosystem relates to different problems currently experienced in the scope of AM such as the missed information and data exchange between asset lifecycle stages and asset control levels, or the data ownership in complex management context with different organizational roles involved. Indeed, the collaborative project with a world leading company with production plants in numerous countries confirms the envisioned potential uses to manage such problems in IT management for AM. The so structured IT ecosystem is thus especially thought for those companies willing to implement a global AM from different starting points: i) companies with an already established IT ecosystem can check whether all the AM-related functionalities are present, or the ultimate goals are being pursued (Sect. 4); ii) companies looking after such an ecosystem can understand the needed functionalities and organize them against control levels and allocate them according to a local or global view.

If applied in company with a single plant, the potential uses blur and implementation effort could be not repaid in our current understanding; thus, our model should be downsized; this could regard future practical work. Besides, further work should concentrate on the strategic control level of AM. The developed IT ecosystem is built starting from maintenance, so partially limiting the entire set of decisions within the AM scope. Especially, capital investment decisions need to be further explored to include, within the IT ecosystem, appropriate modules to support their deployment.