Design of a Maturity-‐based Framework for the
Alignment of Maintenance Management
Processes and Supporting IT-‐functionality
MSc THESIS
Ing. Wil Haasdijk MSc.
Student number: 1952285
RuG -‐ Faculty of Economics and Business
First supervisor: Prof. dr. ir. J.C. Wortmann
Management Summary
This thesis is the result of the final research project for the MSc Business Administration program. The object of this research is the design of a process-‐oriented maturity-‐based framework to improve the alignment of commercial off-‐ the-‐shelf (COTS) Information Technology and maintenance management.
The use of COTS software for maintenance management at the Dutch Fire and Rescue Services is problematic. The key problem is the lack of alignment between the maintenance management processes and supporting IT functionality. An aggravating element is the fact that regional
maintenance departments differ in maturity of their maintenance processes. Also the need to keep IT functionality aligned with maturing maintenance management processes is an important element of the problem.
The research project has two phases:
i. Initial design of the Framework
ii. Refinement of the Framework
In the initial design phase, a literature review is conducted on the basis of three research questions, in which applicable knowledge is acquired to be able to design the Framework. On the basis of the knowledge on maturity models, maintenance management processes, IT functionality for
maintenance management, and alignment of IT functionality and work processes, a capability
maturity-‐based framework with process areas for maintenance management linked to appropriate IT functionality is designed.
In the second phase a multiple-‐case study in four maintenance departments of the Dutch Fire and Rescue Services is conducted to evaluate the Framework and make a first refinement of the initial design of the Framework. The evaluation and refinement has been mainly focussed on the
alignment-‐model of the Framework, in which process area activities (practices) are linked to one or more supporting IT-‐functions.
Maintenance practitioners in the four cases evaluate the Framework (i) as a contribution in providing insight into the alignment and (ii) as a potential tool for the alignment of COTS IT functionality and maintenance management processes. Furthermore, the Framework could be applied in other domains than maintenance management, where the alignment of work processes in development and IT functionality is a problem.
Preface
The idea to do my final research project on the subject of IT-‐support for maintenance management has been in my mind since I was professionally involved in this domain for the Dutch Fire and Rescue Services. I would like to thank some people who were indispensable for the realisation of this thesis. First of all I would like to thank my first supervisor, Hans Wortmann, for the guidance. Thanks to his critical, but always-‐positive feedback and input throughout the whole process, I was able to finish my thesis. Secondly, I would like to thank my colleagues at Dutch Fire and Rescue Services, especially the colleagues at the four Safety Regions for voluntarily acting as interviewees. Last but not least, I would like to thank my family for giving me support throughout the whole education program. Without them I would not have the motivation and energy to finish this thesis.
-‐ Dedicated to both my fathers -‐
Wil Haasdijk
October 2014
CONTENTS
1
Introduction ... 4
2
Research methodology ... 7
2.1
Conceptual research design ... 8
2.2
Research-‐technical design ... 9
3
Literature Review ... 13
3.1
Search Methodology ... 14
3.2
Introduction of Maintenance Management ... 14
3.3
Maintenance Management Models ... 16
3.3.1
Implementation frameworks for Maintenance Management ... 16
3.3.2
Maturity grids ... 18
3.3.3
Capability Maturity Model Integration for Services ... 20
3.3.4
Process models for maintenance management ... 23
3.4
Maintenance Management Information Systems ... 26
3.4.1
IT supporting maintenance management ... 26
3.4.2
IT functionality for maintenance management ... 27
3.5
Alignment of IT Functionality and Work Processes ... 30
4
Initial Design of the Framework ... 33
4.1
Design of the Process-‐oriented Capability Maturity Model ... 33
4.1.1
Maintenance Management Process Areas ... 33
4.1.2
Maintenance Management Maturity Model ... 40
4.2
Design of the EAM/CMMS Functionality Model ... 43
4.3
Design of the Process Area – Functionality Matrix ... 47
5
Framework evaluation and refinement ... 52
5.1
Evaluation method ... 52
5.2
Multiple-‐case study design ... 54
5.2.1
Design of the Interview ... 54
5.2.2
Selection of cases and interviewee ... 55
5.2.3
Interview records format ... 56
5.3
Case study results ... 56
5.3.1
Active practices and available functions ... 56
5.3.2
Results per case ... 58
5.4
Analysis of the results ... 65
5.4.1
General remarks ... 65
5.4.2
Analysis of practice -‐ functions alignment ... 67
5.4.3
Conclusions ... 69
5.5
First refinement of the Framework ... 69
6
Conclusion, Reflection and Recommendations ... 75
References………77
Attachment -‐ Interview Guide………81
1 Introduction
Assets and human resources play an important and often critical role for organisations in producing physical products and services. In many cases assets represent considerable investments. For that reason careful maintenance is needed to guarantee a long-‐time effective and efficient usage of assets. Maintenance management (or asset management) has become an important factor in reaching the goals of the organisations.
During the last fifty years maintenance management has developed continually. Apart from the increasingly sophisticated techniques, methods and policies for maintenance, information
technology has created new possibilities in supporting maintenance management. This has resulted in a great variety of specific applications of information technology for the execution and the
management of maintenance. A specific group of application are the information systems to support maintenance management indicated by terms as Maintenance Information Systems, Computer Maintenance Management Systems (CMMS), Enterprise Asset Management (EAM) systems, etc. (in this thesis the terms CMMS and EAM will be used)
On the market a great many commercial-‐off-‐the shelf (COTS) CMMS in all sorts and specifications: from very simple and limited to very sophisticated and comprehensive functionality. These COTS software packages support maintenance management but are not customised to the activities (or work processes) of a specific maintenance department.
Dutch Fire and Rescue Services and maintenance management
The Dutch Fire and Rescue Service, consisting of fire brigades and ambulance services, is a good example of a service organisation with capital-‐intensive assets. Main assets of the fire brigades (see Figure 1.1) are the various specialised vehicles (fire engines, command vehicles etc.) with related equipment (for communication, safety, pumping, extraction etc.) These assets are critical for the operational activities of the Service, therefore asset maintenance is explicitly mentioned in Article 10.h of the Safety Region’s Act* as a responsibility of a so called Safety Region.
The Dutch Fire and Rescue Service consists of twenty-‐five autonomous Safety Regions, see Figure 1.2. Safety Regions are still in the process of re-‐organisation and development. Originally the fire brigades were part of Dutch municipalities of which there are more than four hundred, so the same amount of fire brigades were active in the Netherlands. These fire brigades together with the ambulance
services are being transformed in the twenty-‐five Safety Regions.
In this process also the municipal maintenance departments (where maintenance is performed on the assets) are transformed into twenty-‐five regional maintenance departments. These maintenance organisations are in different stages of development and implementation. A number of them have just finished the transformation and start working in the new regional environment. Other regions are a little bit further and have already a basic maintenance structure up and running. A small number are further developed in their maintenance activities and already have started up performance management.
* http://wetten.overheid.nl/BWBR0027466, in Dutch
Figure 1.1 Examples of Fire Brigade Assets
Use of CMMS by Dutch Fire and Rescue Services
Since 2002 a number of the (then) municipal fire brigades use different types of COTS CMMS. The implementations of CMMS until now can be described as ‘problematic’: the functionality of these information systems doesn’t fit the asset management and maintenance activities. The COTS software packages as implemented by the suppliers in most cases, deliver a too extensive functionality to the users. This functionality is not tuned on the needs of users performing maintenance management, leading to wrong and suboptimal use of CMMS. Although the functionality in most packages can be customized to a certain degree, CMMS suppliers are apparently not able to determine the specific work processes and fine-‐tune the required
functionality. Many CMMS suppliers are more expert on IT than maintenance management expert (Peters, 2006).
The problematic facts as described above are the reason for this research project and can be summarised in the following three statements.
The maintenance departments of the twenty-‐five Safety Regions of the Dutch Fire and Rescue Service:
• are not able to align the maintenance management processes and CMMS functionality • differ in the maturity level of the applied maintenance management processes
• are developing and improving maintenance management processes and accordingly have the need to continually update CMMS functionality to keep it aligned.
Figure 1.2 Safety Regions of the Netherlands
2 Research methodology
In the previous chapter the problematic situation of the Dutch Fire and Rescue Services with respect to maintenance management is described. The key problem is the lack of alignment between the maintenance management processes and IT functionality supporting the execution of processes. An aggravating element of the problem resides in the fact that regional maintenance departments differ in maturity of their maintenance processes. A second aggravating element is the need to keep IT functionality aligned while maintenance management processes are in development. These elements are important preconditions in designing a practical solution.
Many researchers and practitioners highlight the implementation problems with IT functionality for maintenance management including the alignment of processes and IT functionality. This alignment is crucial for the success of IT in supporting maintenance management (Fernandez, 2003; Kans & Ingwald, 2009), but on the other hand also problematic to achieve (Braglia, 2006; Bagadia, Cato & Mobley, 2002; Carnero & Novés, 2006; Gomez & Carnero, 2011; Mather, 2003).
Practical solutions are not easy to find, at the best implementation methods are available, in the form of consecutive steps to be taken (Bagadia, 2006; Mather, 2003; Kans, 2008). There is consequently a great need for a practical tool to support the alignment process.
The main cause for the existing problems is the fact that most of the information systems for maintenance management are commercial off-‐the-‐shelf (COTS) type software packages, which are designed to serve a variety of organisations. A similarity can be drawn with the broadly
acknowledged problematic implementations of Enterprise Resource Planning systems (Soffer, 2005). The software packages contain a very large quantity of functions and features organised in modules and applications of which only a subset is needed to effectively support a particular maintenance department. A positive fact is that COTS software packages today are configurable, on the basis of which some system customization can be done in the process of alignment. Despite of this feature of software packages, the problem of selecting, and customizing i.e. aligning functionality with a specific maintenance department using specific maintenance processes, still remains.
As stated earlier, the regional maintenance departments of the Dutch Fire and Rescue Service are in a process of autonomous development. This fact has two consequences (i) the departments differ in their process maturity and (ii) the maintenance management processes are under development. A practical ‘alignment tool’ has to incorporate a concept of process maturity to cope with the variety of maintenance departments using different work processes. This requirement plus the need to be able to support the development of maintenance management processes in close harmony with the alignment of IT functionality, led to the choice for a holistic approach to these requirements in the form of a process-‐oriented maturity-‐based framework.
In this chapter the design of the research project for an alignment tool for the Fire and rescue services maintenance departments is presented. Verschuren & Doorewaard (1998) divide the design of the research methodology into two groups of activities. The first group, referred to as the
authors, contains the activities on how the research will be executed and defines the research material used, the research strategy and planning. In the next two sections the conceptual design i.e. the problem statement and the research-‐technical design consecutively will be explained.
2.1 Conceptual research design
According to Verschuren & Doorewaard (1998) the conceptual design or problem statement contains the research goal and the research (sub) questions. The research goal defines the scope of the research project and describes the contribution of the research project in solving the problem. In this research project the alignment problems of COTS IT functionality with maintenance processes is the key subject, while aiming at improvement of the problematic alignment by means of an alignment tool.
This leads to the following definition of the research goal:
The improvement of alignment between commercial off-‐ the-‐shelf Information Technology and maintenance management by means of the development of a maturity-‐based framework, in which the process areas of maintenance management are linked to appropriate IT functionality.
To reach the research goal, applicable knowledge must be acquired. For this project research questions are developed of which the answers lead to the knowledge that is needed. Knowledge in the following areas is indispensable to develop the framework, as cited in the research goal: theory on processes, maturity models, IT functionality for maintenance management, and process – IT functionality alignment theory.
The following research questions are defined: i. RQ1:
What are the characteristics of a process-‐oriented maturity model for maintenance management?
This question is answered by literature review of theory on maturity models and maintenance management processes (Chapter 3) leading to the design of the process-‐oriented maturity model for maintenance management (Chapter 4)
ii. RQ2:
What commercial off-‐ the-‐shelf (COTS) IT functionality is available for the support of maintenance management?
This question is answered by literature review of theory on IT functionality for maintenance management and an analysis of the functionality specifications of market leader information systems for maintenance management (Chapter 3) will lead to the definition of the IT functionality model (Chapter 4)
iii. RQ3:
Which COTS IT functionality is needed for each maturity level to effectively support the maintenance management process areas?
This question is answered by literature review of theory on alignment of IT functionality and work processes (Chapter 3) and the input of expert knowledge leads to the matching of IT functionality and process areas (Chapter 4)
2.2 Research-‐technical design
The research-‐technical design consists of the research strategy, materials and planning. The
approach of the research project i.e. the research strategy is the most important choice to make for the research-‐technical design: ‘in what way will the research be conducted?’ (Verschuren &
Doorewaard (1998). In this section this question will be answered and explicated.
The core of this research project is the development of a framework contributing in solving an IT alignment problem, as is stated by the research goal. The Framework, as a result of this research project, is a model or artefact to solve a problem and fits in with the design science paradigm. The design-‐science paradigm is a problem-‐solving paradigm. In contrast with the behavioural and natural science paradigms where the development and justification of theories that explain or predict phenomena is the goal, the design science paradigm seeks to create innovations that define ideas, practices, technical capabilities, and products through which a problem is solved (Hevner et al., 2004). Holmström et al. (2009) defines design science as the research that seeks (i) to explore new solution alternatives to solve problems, (ii) to explain this explorative process, and (iii) to improve the problem solving process.
The research-‐technical design is based on the theory of Holmström et al. (2009) on design science and the design science research guidelines of Hevner et al. (2004).
In the theory of Holmström et al. (2009) the design science, a research paradigm aimed primarily at discovery and problem solving is complemented to the theory-‐oriented academic research, aimed at the accumulation of theoretical knowledge. Holmström et al. define four consecutive phases of research divided in two exploration research phases (design science) and two explanation research phases (theoretical science). Table 2.1 based on Holmström et al. (2009) gives the most important characteristics of the four phases.
Research type Exploration (Design Science) Explanation (Theoretical Science) Research phase 1.Solution incubation 2.Solution refinement 3.Explanation I 4.Explanation II Objective Development of an
initial solution design
Refinement of the initial solution design
Development of substantive theory
Development of formal theory
In Research phase 1 the initial solution design is developed, refinement of the initial design takes place in Research phase 2. In the Research phases Explanation I and II theory is developed, in Explanation I more scanning and reflective and in Explanation II formal theory building.
For this research project the two Exploration research phases of Holmström et al. (2009) are used to structure the phases of the research project.
• Phase 1 – Initial design of the Framework
On the basis of the literature review in Chapter 3, a capability maturity-‐based framework with process areas of maintenance management linked to appropriate IT functionality is designed in Chapter 4. See Figure 2.1 for an overview of Phase 1.
• Phase 2 – Refinement of the Framework
A first step refinement is conducted by evaluation of the initial design of the Framework through a multiple case study in 4 regional organisations of the Dutch fire and rescue services in Chapter 5. This phase is depicted in Figure 2.2.
Figure 2.1 – Phase 1: Initial design of the Framework !"#$%&&'#"(%)*%+' ,-*."(*/',#+%0' 1#"'2-()*%)-)$%' ,-)-3%,%)*'' 4.)$5#)-0(*/'6' 7#"8'9"#$%&&%&' -0(3),%)*' *:%#"/' ;<' 4.)$5#)-0(*/' ,#+%0' =%&(3)' ;)(5-0' 4.)$5#)-0(*/' -0(3),%)*' 1"-,%7#"8' 2-*."(*/',#+%0&' *:%#"/' 2-()*%)-)$%' ,-)-3%,%)*' 9"#$%&&'*:%#"/' >?<@';<' 1.)$5#)-0(*/' =%&(3)'' ;<'1#"' 2-()*%)-)$%' ,-)-3%,%)*' *:%#"/' A)-0/&%''
Chapter 3 Literature review
Figure 2.2 – Phase 2: Refinement of the Framework
Due to a limited timeframe the Explanation research phases are not incorporated in this project, so this research project is a ‘Design Science’ type of research.
The seven guidelines of Hevner et al. (2004), contained in Table 2.2, are used as a reference in structuring, conducting and evaluating the research project. These guidelines are meant to assist researcher, reviewers, and readers to understand the requirements for effective design science research. The guidelines are for that reason not for mandatory or rote use (Hevner et al., 2004). The guidelines will be used in the following manner:
• Guideline 1, ‘design as an artifact‘ is complied with by the stated research goal: the development of a framework. The Framework and its design will be further explained in Chapter 4.
• Guideline 2, ‘problem relevance’ is explained in Chapter 1 and in the previous sections of this chapter.
• Guideline 3, ‘design evaluation’ is the subject of Chapter 5
• Guideline 4, ‘research contributions’ will be a subject in Chapter 6
• Guideline 5 and 6, ‘research rigor’ and ‘design as a search project’ respectively, are complied with by the introduced rigorous research methodology based on Holmström et al. (2009), as described in this chapter. Reflection on the research methodology including the aspects applicability and generalisation of the design artifact will be presented in Chapter 6 • Guideline 7, ‘communication of research’ will be a subject in Chapter 6
!"#$%&' ()"*$+"%&#,-' %&#."/0",' 12%/03+24' 56%&)%$+"' *2#,02#%' 7)&$8&0'*%90' 9,):-' ;"%&-9#9'209)&,9' <0="0/0",' *2#,02#%' >9,'<0="0:'' ()"*$+"%&#,-' %&#."/0",' 12%/03+24'
Chapter 5 Refinement of Framework
Guideline Description
1. Design as an Artifact Design science research model must produce a viable artefact in the form of a construct, a model, a method, or an instantiation.
2. Problem Relevance The objective of design science research is to develop technology-‐ based solutions to important and relevant business problems. 3. Design Evaluation The utility, quality, and efficacy of a design artifact must be
rigorously demonstrated via well-‐executed evaluation methods. 4. Research Contributions Effective design science research must provide clear and verifiable
contributions in the areas of the design artifact, design foundations, and/or design methodologies.
5. Research Rigor Design science research relies upon the application of rigorous methods in both the construction and evaluation of the design artifact.
6. Design as a Search Process The search for an effective artifact requires utilizing available means to reach desired ends while satisfying laws in the problem
environment.
7. Communication of Research Design science research must be presented effectively both to technology-‐oriented as well as management-‐oriented audiences
Table 2.2 Design Science Research Guidelines (Hevner et al., 2004)
3 Literature Review
In this chapter a literature review is presented for providing the required knowledge to answer the Research Questions RQ1 to RQ3. After the first section on the performed search methodology into literature, the main subject of maintenance management is introduced in Section 3.2. In this introduction the development of maintenance management from a half century ago till now is described and basic policies, definitions and terminology used in maintenance management are explained. Section 3.3 will be focused on maintenance models. In the search for an answer to RQ1 a number of specific models are discussed: implementation models, Maturity grids, Capability Maturity models and process-‐oriented models for maintenance management.
IT for maintenance management will be the main topic of Section 3.4 to provide for the knowledge needed to answer RQ2. After a thorough introduction on IT for maintenance management, the functionality of commercial-‐off-‐the shelf software-‐packages for the support of maintenance management is researched.
Finally in Section 3.5 RQ3 is answered by the last subject of this literature review: Alignment of IT functionality with work processes.
The scope of this literature review is depicted in Figure 3.1. To illustrate the business-‐IT alignment character of this research project, the subjects are placed in the business and/or IT domain.
3.1 Search Methodology
For this literature review a search is conducted using the electronic databases via the RuG library web applications: ACM Digital Library, Business Source Premier, EBSCOhost COMPLETE, Elsevier ScienceDirect, Emerald, IEEE Xplore, SpringerLink and apart from that Google Scholar, with the following key words: maintenance management, maintenance process, computerized maintenance management system, cmms, commercial-‐off the shelf software, cots, maturity model, business – it alignment, asset management, eam, erp, maintenance repair overhaul, mro. With the same keywords also the catalogue of the TU Delft is searched for books on maintenance subjects. In the process of literature search three articles were encountered with literature overviews of maintenance management. The work of Garg & Deshmukh (2006) delivers an encompassing literature study in six key research areas of maintenance management including IT.
López Campos & Crespo Márquez (2009) focus on an overview of representative maintenance management i.e. declarative and process oriented models; in particular the last group of models is of great interest for this research project. Kans (2009) presents a literature review in which 97 scientific papers of the period 1988 to 2003 are contained, which is used as a basis for the literature research on IT for maintenance management.
3.2 Introduction of Maintenance Management
Some decades ago definitions of maintenance were introduced of which many examples can be found in literature. For instance EN 13306:2001 defines maintenance as the combination of all technical, administrative and managerial actions during the life cycle of an item intended to retain it in, or restore it to a state in which it can perform the required function (López Campos & Crespo Márquez, 2009).
A similar definition of maintenance as introduced by O’Donoghue & Prendergast (2004) is ‘to try to maximize the performance of equipment by ensuring that, items of equipment function regularly and efficiently, by attempting to prevent breakdowns or failures. In fact, it is the objective of the
maintenance function to maintain or increase the reliability of the operating system taken as a whole.’ In addition O’Donoghue & Prendergast state that an objective also is to minimise the total cost of maintenance by minimizing the costs of repair and the costs of preventive maintenance similarly.
The maintenance function has gone through many phases in the last 60 years. Before 1950 maintenance was considered a ‘necessary evil’. The maintenance concept used was ‘fix it when it breaks’ or ‘run-‐to-‐failure’ so only breakdown maintenance was applied (Waeyenbergh & Pintelon, 2002; Peters, 2006). In the 1950s preventive maintenance (PM) was introduced and also specialized maintenance departments emerged to perform maintenance activities. Preventive maintenance is an interval-‐based surveillance method in which periodic inspections are performed on assets to
determine the progress of wear in its components and subsystems. When wear has advanced to a degree that warrants correction, maintenance is performed on the asset to rectify the worn condition (Peters, 2006).
are deployed to measure the physical condition of an asset such as temperature, noise, vibration, lubrication and corrosion. When one or more of these indicators reach a predetermined
deterioration level maintenance activities are undertaken to restore the asset (Ahuja & Khamba, 2008). Another method called reliability centred maintenance (RCM) was originally designed for the aircraft industry but is also used in general industry. The first step in RCM is gathering information. RCM interprets and defines functions of the asset (in general a complex technical system) and thereafter the possible functional failures are reviewed. Failure modes and causes are linked to these failures and their effects determined. With this data the most critical items can be located
(Waeyenbergh & Pintelon, 2002). On the basis of this information feasible and effective maintenance tactics are selected, scheduled, implemented and optimized. Various tools are employed to affect maintenance improvement including FTA (Fault Tree Analysis), FMECA (Failure Modes and Effects and Criticality Analysis) and HAZOP (Hazard and Operability Analysis) (Ahuja & Khamba, 2008). In Figure 3.2, based on Schneider (2006), the four reviewed maintenance policies are classified by distinguishing whether the condition of the asset is considered and whether the importance is considered.
Figure 3.2 Classification of maintenance policies (Schneider, 2006)
Nowadays the maintenance function is an important input to the core process of an organisation in maintaining the business assets such as production lines, vehicles, buildings etc. The maintenance goals should support the realisation of the organisation’s goals by a proper set of policies and resources (Kans, 2008). To accomplish this, proper maintenance management will have to be conducted. In EN 13306:2001 maintenance management is defined as all activities of the management that determine the maintenance objectives, strategies, and responsibilities and implement them by means such as maintenance planning, maintenance control and supervision, improvement of methods in the organisation including economic aspects (López Campos & Crespo Márquez, 2009).
structures and how to improve maintenance management. In the next section a number of these models will be reviewed in order to answer RQ1.
3.3 Maintenance Management Models
In the search for effectiveness and efficiency of maintenance management to fulfil the enterprise objectives, maintenance management models play an important role. In the literature on
maintenance management a considerable number of contributions on models can be found with the common goal to improve the management of maintenance.
Three kinds of maintenance management models were encountered: • Implementation frameworks
• Maturity grids • Process models
A selection of these models will be introduced in the next sections because they contain valuable input for answering RQ1.
3.3.1 Implementation frameworks for Maintenance Management
A number of implementation frameworks are presented in the maintenance management literature. Some models define implementation of maintenance management in a phased sequence. The models of Waeyenbergh & Pintelon (2002) and Crespo Marquez at al. (2009) are examples of this kind of models.
The framework presented by Waeyenbergh & Pintelon (2002) is designed as a guideline to develop a customised maintenance concept to the requirements of companies, see Figure.3.3
Figure 3.3 Framework for maintenance concept development (Waeyenbergh & Pintelon, 2002)
The framework consists of 4 modules: starting with identification of maintenance objectives and resources module, followed by the module with identification of the most important systems (assets), next comes the module with the decision on the maintenance policy to be used and finally
the performance measurement module. Depending on the output of the performance results the 5th
module of continuous improvement will act on the first 3 modules.
Crespo Marquez at al. (2009) present a similar approach in their maintenance framework (see Figure 3.4), consisting of 8 phases for maintenance management implementation.
Figure 3.4 Maintenance management framework (Crespo Marquez at al., 2009)
The first three phases consider the effectiveness of maintenance management, phases 4 and 5 focus on improving the efficiency and phases 6 and 7 on the assessment of maintenance. The last (‘and everlasting’) phase 8 is the continuous improvement phase.
The implementation frameworks of Waeyenbergh & Pintelon (2002) and Crespo Marquez at al. (2009) deliver valuable knowledge for RQ1.
The framework of Waeyenbergh & Pintelon (2002) gives input to the necessary steps to structure maintenance on a strategic / tactical level (objectives, resources needed, identification of critical systems and maintenance policies needed) and makes choices for achieving effectiveness of maintenance management. In the next phase the chosen preventive maintenance policies are optimised by setting the parameters (for instance: PM frequency) i.e. tuning the efficiency of the maintenance policy. The choices made are subsequently evaluated by measuring the performance and improve on the choices implemented.
Crespo Marquez at al. (2009) follow exactly the same line in their implementation sequence. With the sequence ‘effectiveness -‐> efficiency -‐> assessment -‐> improvement’ in their framework,
maintenance management stages are defined which could be used as an input to RQ1 in guiding the definition of the maturity stages of the capability maturity model for maintenance management in Section 4.2.
3.3.2 Maturity grids
A maturity model can be defined as a model conceptually representing phases of increasing quantitative or qualitative capability changes of a maturing element in order to assess its advances with respect to defined focus areas. Typically, the maturing element is a person, an object or a social system. The focus area determines which indicators for maturity can be used to assess a maturing element. Examples of focus areas are maturity of processes, maturity of digital resources or maturity of people’s competencies. (Kohlegger et al., 2009)
Fraser (2002) indicates that a maturity model consists of the following components: (i) number of levels, (ii) descriptor for each level, (e.g. uncertainty ßà certainty), (iii) description of characteristics expected of an organization at each level, (iv) number of dimensions, (v) description of
elements/activities at each dimension, and (vi) description of each activity as performed at each maturity level.
Figure 3.5 Maintenance organisational maturity grid (Fernandez, 2003).
A number of maturity grids for maintenance management are inspired by Crosby’s five stages* maturity grid for quality management (Paulk, 2009). This maturity grid with the stages Uncertainty, Awakening, Enlightenment, Wisdom and Certainty was used by Antil to define the Maintenance organisational maturity grid which was adapted by Fernandez et al. and depicted in Figure 3.5 (Fernandez, 2003). The maturity model describes performance measures in five stages on four selected focus areas: Management Understanding & Attitude, Problem Handling, Company Maintenance posture and CMMS. Stage 1 is the stage in which maintenance management is not active (‘chaotic‘ stage). The stages 2-‐5 are consistent with the ‘effectiveness – efficiency –
assessment – improvement’ – sequence of the model by Crespo Marquez at al. (2009) as described in the previous section.
Oliveira et al. (2013) present another application of Crosby’s maturity grid. They undertook a survey on industrial plants to produce another maintenance focused maturity grid with four stages on five focus areas. The four stages as showed in Figure 3.6 are extracted from maintenance policies. The focus areas are maintenance strategy, KPI’s, maintenance data system, technical competence and management models.
Figure 3.6 Four-‐staged maintenance maturity model (Oliveira et al., 2013).
In the stage descriptor as well in the stage descriptions in the focus areas descriptions again the similarity with the sequence of the Crespo Marquez at al. (2009) model is apparent. The chaotic’ stage (no maintenance management present) is not a part of this model.
Pintelon et al. (2006) introduce a four-‐stage framework in which the degree of maintenance strategy effectiveness is indicated (see Table 3.1)
The framework is adapted from the well-‐known four-‐stage framework of manufacturing strategy effectiveness of Hayes and Wheelwright. Stage 1 is the lowest level of effectiveness where
maintenance is regarded a nuisance, has a strictly reactive character (breakdown maintenance) and maintenance is fully outsourced to OEM or external service providers; stage 4 is the highest level in which maintenance is seen as an important management factor and continuous improvement in all aspects of maintenance management is activated.
Also for this framework the same similarity with the Crespo Marquez at al. (2009) model sequence is apparent and similar to the model of Oliveira a fifth stage ‘chaotic’ is not present in the model. In relation to RQ1 these maturity grids can be used for the stage-‐design of a process-‐oriented capability maturity model for maintenance management. Especially the sequence effectiveness (reactive) – efficiency (preventive) – assessment (predictive) – improvement (maintenance engineering) can be used as the maturity stages on top of a chaotic stage. There is however one drawback: these maturity grids are not process-‐oriented, although they contain some description of maintenance activities on each stage, which can be used as guidance for the design. In this respect the framework by Pintelon et al. (2006) offers the most comprehensive descriptions, but this is not sufficient for designing a process-‐oriented capability maturity model. A capability maturity model that is actually process-‐oriented is the well-‐known CMMI (Capability Maturity Model Integration) for Services, one of the CMMI variants for the specific processes of service organisations that are comparable to maintenance organisations. In the following section CMMI for Services is reviewed.
3.3.3 Capability Maturity Model Integration for Services
The Capabilities Maturity Model (CMM) of the Carnegie Mellon University Software Engineering Institute (SEI) was initially released in 1987. The CMM dealt mainly with the reliability and consistency of software development. CMM places proven practices into a structure that helps organisations assess their organisational maturity and process area capability, establish priorities for improvement, and guide the implementation of these improvements. (Paulk, 2009; Hauge & Mercier, 2003; Talib & Abdullah, 2010).
CMMI (Capability Maturity Model Integration) is a process improvement maturity model for the development of products and services (i.e. integration). The maturity levels of CMMI (Initial, Managed, Defined, Quantitatively managed, Optimising) are made up of a number of process areas (see Figure 3.7). A Process Area is a collection of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. Goals apply to a process area and describe what must be implemented to satisfy the process area. A practice is an activity that is considered important in achieving the associated specific goal, describing the activities expected to result in achievement of the goals of a process area. (Baskarada et al., 2006). CMMI is available in two representations: staged or continuous. A staged
representation may be said to focus on the organization's processes as a whole, to provide a
Figure 3.7 CMMI concept (Baskarada et al., 2006)
The following capability levels are defined within CMMI: • Capability Level 0 – Incomplete
An incomplete process is a process that either is not performed or is partially performed. • Capability Level 1 – Performed
A performed process is a process that accomplishes the needed work to produce work products; the specific goals of the process area are satisfied. Although capability level 1 results in important improvements, those improvements can be lost over time if they are not institutionalized.
• Capability Level 2 – Managed
A managed process is a performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.
• Capability Level 3 – Defined
A defined process is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related assets to the organizational process assets.
With equivalent staging it is possible to translate results in a continuous representation to/from a staged representation. If improvement is measured relative to selected process areas using capability levels in the continuous representation this can be converted to maturity levels. For a specific
maturity level rating a specific target profile of capability levels is needed. In Table 3.2 the
Level (ML) a selected group of process areas must have a specific target profile i.e. minimum capability level (CL). For example: to achieve ML2 the selected 8 process areas must achieve CL2. (Software Engineering Institute, 2010)
CMMI for Services is a specialised maturity model of the SEI that focuses on the improvement of processes and quality in service organisations. The architecture is similar to the previously introduced CMMI (for Development). It covers in total 24 process areas that are grouped by the four categories Process Management, Project Management, Support and Service Establishment and Delivery. The CMMI for Services builds upon existing CMMI models and integrates concepts and best practices from other service-‐oriented standards and models like the Information Technology Infrastructure Library, ISO/IEC 20000, Control Objects for Information and related Technology and the IT Service CMM. (Hecht, 2011; Software Engineering Institute, 2010)
the knowledge is acquired for the design of process areas and practices specific to maintenance management.
3.3.4 Process models for maintenance management
In this section process models for maintenance management are reviewed to be able to compile a set of process areas and practices.
Hassanain et al. (2001) present a data model for maintenance management of roofing systems for buildings. The data model was developed following a methodology that began with developing process models and usage scenario’s. This results in a detailed process model in IDEF0 notation of a number of maintenance management key processes, as depicted in figure 3.8.
Figure 3.8 Maintenance management key processes (Hassanain et al., 2001)
Each key process is further detailed in sub-‐processes like the example in Figure 3.9 for the key process ‘Manage maintenance operations’.
Crespo Marquez & Gupta (2006) define maintenance management closed-‐loop processes on strategic -‐ tactical -‐ operational management levels (see Figure 3.10).
Figure 3.10 Maintenance processes on three management levels (Crespo Marquez & Gupta, 2006) On the strategic level the maintenance plan with the definition of maintenance priorities is
formulated based on the business plan. On the tactical level the maintenance plan is the basis for the assignment of resources and task scheduling and on the operational level the tasks are executed, completed and data is recorded.
Pintelon (1999) also defines three different levels of decisions for maintenance management: • Strategic or long-‐term planning
provides the resources required to ensure maintenance capabilities by considering costs, capacity, impact of technological changes etc.
• Tactical or medium-‐term planning
ensures effective resource utilization by finding the optimum maintenance policy. The optimum policy ensures the availability of reliable assets, while keeping maintenance costs (direct costs of labour, spare parts etc.) and maintenance-‐related costs (indirect costs such as excessive wear due to bad maintenance).
• Operational or short-‐term planning
concerns the day-‐to-‐day planning and scheduling decisions of maintenance activities: preparations in terms of availability of personnel spare parts, required skills for the jobs, special tooling availability etc. and arrangement of the sequence in which work orders will be executed.
Another process view of maintenance, but in this case in the form of a Deming Improvement Cycle (Plan-‐Do-‐Check-‐Act)*, is presented by Söderholm et al. (2007), see Figure 3.11. The argument to relate a maintenance process to the Deming cycle is the continuous improvement goal of Maintenance Management models.
