Reasons for customizing packaged enterprise systems: a case study on an enterprise asset management system

ABSTRACT

Companies acquire information systems as software products developed by software vendors. These products, usually referred to as packaged enterprise systems (PESs), are customized to fit a customer company’s business needs and processes. Despite its practical relevance, the literature discusses customization sporadically and primarily focuses on the implementation, adoption, and critical success factors of enterprise resource planning systems. Another type of PES, enterprise asset management (EAM), is even more greatly overlooked, although it has a very large user base and a significant market share. In this paper, we explore why PESs are customized. We conduct a case study on the customization of a commercial EAM system in the Nordic region, which involves interviewing 16 business representatives and consultants involved in implementing and operating the EAM system in their respective organizations. We describe four categories of reasons for customizing EAM: the product lacks some features, business process needs necessitate customization, project management issues, and the relationship between the consultants and the business units leads to customization. We also show when they emerge in relation to the EAM project’s phases. Identifying and understanding these reasons can help product vendors and their customers assign their resources appropriately and tailor their activities toward achieving efficiency and feasibility

Introduction

An enterprise system (ES) is a software system designed to fulfil a broad range of organizational information processing needs on an organization-wide level (Singh & Pekkola, 2021). The term ES refers to a wide variety of systems, such as those used for enterprise resource planning (ERP), customer relations management (CRM), supply chain management (SCM), enterprise asset management (EAM), and manufacturing execution (MES) (Rashvanlouei et al., 2015). They are often provided as software products developed by an external vendor that customers customize according to their needs. These kinds of packaged enterprise systems (PESs) are a dedicated and currently dominating type of ES (Mabert et al., 2000). Each ES has its own objectives. For example, ERP manages core business processes, such as finance, human resources, and supply chains; SCM handles the flow of goods and services from procurement to their delivery to customers; CRM governs interactions with customers, including sales, marketing, and support activities; and EAM focuses on managing physical assets, maintenance, and repairs.

In this paper, we focus on EAM systems; they have not been thoroughly studied in the literature. Instead, they have been treated as generic ERP systems. This follows the approach that ERP is an umbrella term for a set of applications or modules put together (Rashvanlouei et al., 2015). However, as is the case with the differences between ERP, SCM, and CRM, EAM systems are also unique. They deal with an asset-intensive organization’s physical assets (industrial infrastructure, industrial plant, and equipment) and their life cycles, from investment planning, installation and commissioning, and operation to maintenance and decommissioning. Thus, EAM is primarily a transactional workflow system designed for the management and execution of capital asset maintenance. It provides maintenance history data and a linear or hierarchical asset register and supports the creation of a schedule for maintenance tasks by using historical records, vendor guidance, and product manuals or by predicting failures based on predictive artificial intelligence (AI) models. The EAM data generated during an asset’s life cycle are also used for monitoring performance, improving operational efficiency, and making informed decisions about decommissioning activities and new investments (Sinha et al., 2007). Therefore, EAM systems are business-critical systems for asset-intensive organizations. They help improve the efficiency of maintenance processes, ensure that assets are monitored and maintained appropriately for uninterrupted production, and optimize stock levels to avoid over- or understocking. Using EAM systems, organizations can predict asset failures and repair them before breakdowns occur. This saves money and minimizes the risks of production interruptions while balancing between over- and underdoing maintenance tasks. For these benefits, organizations have annually invested up to 5 billion USD worldwide in EAM systems.¹

EAMs and other ESs are often purchased as packaged software systems. These “out of the box” solutions do not usually meet organizations’ needs and must be somehow configured or customized (Markus & Tanis, 2000). This customization may take place either through adjusting and tailoring business processes or through modifying technology (Davenport, 2000). Customizing the software product is emphasized in any kind of process-intensive ES (Lucas et al., 1988). There are several reasons for this. First, there are usually myriads of other ESs and tightly interwoven business processes. Any mismatch between organizational requirements and these systems can be highly disruptive to an organization’s operations. Poor system-to-business fit can lead to negative business outcomes (Gattiker & Goodhue, 2002). Second, because of the numerous participants and integrations involved, ES customizations are especially intricate and are, consequently, difficult and expensive (Hitt et al., 2002). Third, although initial customizations may be very expensive, the cost implications associated with systems’ future maintenance and upgrades are often significantly larger (Ng et al., 2003).

Customization issues are emphasized from the information infrastructure viewpoint. ESs range from financing and accounting to manufacturing, stocks and supplies, and human resource management. Each area has its own systems (Davenport & Brooks, 2004). Despite the extensive amount of research on systems integrations (Da Xu, 2011; Kähkönen, Smolander, et al., 2017; Shang & Seddon, 2002; Volkoff et al., 2005), these systems remain disintegrated. The out- of-the-box systems consequently serve their own business silos and processes (Davenport & Brooks, 2004). To facilitate fluent data flows between business processes, a PES and/or its integrations are modified.

These challenges make it difficult to balance organizational needs and PES customization. Ideally, the system would meet the requirements completely, but this is very rare (Balint, 2011). As system customization has significant long-term impacts (Hitt et al., 2002; Ng et al., 2003), pursuing it represents an important business decision. Thus, one of the fundamental considerations is the reasons for opting for customization.

Current PES research does not focus on customization and, instead, revolves around several ERP-related issues (Singh & Pekkola, 2021). For example, ERP’s implementation, adoption, and critical success factors and cultural influence on the implementation of ERP have been previously studied (Clemons, 1998; Jayaraman & Bhatti, 2007; Markus & Tanis, 2000; Remus, 2006; Sheu et al., 2010; Svejvig, 2011). While some studies have touched upon ERP customization (Brehm et al., 2001; Haines, 2009), they have not provided an in-depth understanding of it or of the associated reasons or factors (Haines, 2009) and have not sufficiently addressed other ES types. In fact, there is very little mention in the literature about customization in general and EAM in particular (Singh & Pekkola, 2021; Davenport, 2000; Haines, 2009).

The practical importance of the EAM and the absence of EAM-related research motivate our study. We seek an answer to the following research question: “What are the reasons that drive EAM customization?” Therefore, we aim to establish an understanding of why and when organizations end up customizing their EAMs. We conduct a qualitative case study in which we interviewed 16 informants from 10 organizations located in Finland and Sweden that customized the same packaged EAM system: IBM Maximo. It is a widely used asset management system and is regarded as a world leader among EAM systems.^2,3 All the included organizations have extensive experience (some of more than 10 years) with the system.

The next section presents the related research. After that, we present the research methods, our findings, and an overall discussion. Finally, we conclude the paper with the conclusions and contributions sections.

Related research and theoretical background

Nowadays, all industries strive for efficiency, better insights into their data, and improved competitiveness (Sebastian et al., 2020). Regardless of system integration, different business functions and areas have different objectives and purposes. This signifies that it is very difficult to build just one system for all (Smolander et al., 2017). This also means that the reasons for customizing systems might be different. Although Haines (2009) argued that customization and its factors need to be understood in general, varying ES uses call for understanding different ES types, such as ERP, CRM, SCM, and EAM, and their different factors. Understanding the customization of individual systems is crucial, as the associated contexts, stakeholders, supported business processes and logics, and reasons vary. For example, while ERPs usually involve dealing with finances or supporting similar “standardized practices” (Davenport, 2000), EAMs support company-specific machine maintenance procedures, which vary across companies, machines, and vendors. This disparity emerges in the form of issues such as varying cultures, training needs, and safety criticality, with each requiring separate attention.

Organizations customize PES products according to their business needs. Although customizations play an important role in ES implementations and can be a significant cost factor (Zastrocky & Harris, 2008), research on PES customization is scarce (Singh & Pekkola, 2021). The literature mainly focuses on PES implementation in different enterprises (Ali & Miller, 2017; Haddara & Zach, 2011; Osnes et al., 2018; Tsai et al., 2010), the evolution of PES (Zhang, 2013), and its success factors (Haines, 2009) but not on PES customization per se. Even closely related studies focusing on, for example, requirement engineering in PES development (Alves et al., 2010) or PES development costs (Jorgensen & Shepperd, 2006) do not address customization. These observations are supported by a recent literature review (Singh & Pekkola, 2021). This indicates that PES customization is usually seen in the context of ERP systems’ modification during their implementation phase, and the studies provide examples of ERP successes and failures. In fact, 58 (of 67) papers examined PES customization through ERP customization in different contexts. Other systems include CRM and SCM. Furthermore, not a single study has specifically investigated EAMs or their customizations (Singh & Pekkola, 2021).

Enterprise asset management systems

In the early 1930s, machine maintenance was not done until the machines broke down or was done sporadically to prevent failures. Currently, organizations aim to repair their machines just before they are about to break down. The intention is to minimize production breaks and machine downtime and to optimize maintenance costs. EAM systems support these activities by collecting information from the machines and their historical records, vendor guidance, and product manuals and helping organizations make informed decisions according to their business demands and risk assessments.

The annual EAM investment market is about five billion USD worldwide (see footnotes 1 and 2 earlier). This is divided by industry as follows: transmission and distribution (26%), manufacturing (18%), process industries (16%), and power generation (14%). In addition, it is distributed globally as follows: North America (34%), Europe and Africa (31%), and Asia (27%). The companies that use EAM systems have a turnover of about 0.5–1 billion USD (42%) or 1–10 billion USD (24%). While many ESs are provided as cloud-based services, about 73% of EAM systems are still offered as packaged systems and deployed locally. This means that they are often customized according to local needs. This also means that they are adequate for realizing our objective of better understanding the reasons behind PES customization.

Consequently, there is a need to obtain an in-depth understanding of PES customization and the different types of PESs because of their significant business impacts. Specifically, EAM has been neglected in past research. Next, we review different customization characteristics and rationales.

Customization and its reasons

Customization has been defined in an inconsistent manner in the literature. Rothenberger and Srite (2009) define customization as “building custom features by using standard programming languages or the ERP system’s language, changing the ERP system code, and/or including third-party packages that require some degree of programming to implement” (p. 664). Haines (2009) defines customization as the “best of breed” module or enterprise system module designed to provide a better match with existing or desired organizational processes and data. In contrast, Luo and Strong (2004) state that customization is about modifying an ERP software package to match an organization’s existing processes, while Klein (2007) defines customization as an asset-specific information technology (IT) investment made by clients during the course of a strategic business relationship. Parthasarathy and Sharma (2016a) emphasize differences from a standard version and define “customization as the modifications made to the chosen ERP package to meet the client organization’s requirements that are not supported by the vendor as a standard feature” (p. 20). Nevertheless, customization can be classified into three types: configuration, extending the existing code, or modifying it (Haines, 2003). The main difference between configuration and modification is that, first, the former is mostly supported by the vendor and does not create any problem during upgrades, while the latter is not supported by the vendor and might lead to feature breakdowns after a version upgrade. Second, PESs often focus on dedicated business processes in which the customer expects a plug-and-play type of integration regardless of how it is achieved. Here, we consider configuration and customization synonymous because they are both implemented due to customization needs and result in significant lifetime costs. From this perspective, customization can be viewed as a dedicated business asset. From a business strategy perspective, only strategically important business assets should be specialized (Schoemaker & Amit, 1993). This implies that PES customizations should be linked to the business strategy employed.

The reasons for customization go beyond such strategy and vary across organizations and their products and supported processes (Rothenberger & Srite, 2009). An intricate network of interrelated factors that influence customization, categorized as strategy, system, project, and institution, has been identified (Haines, 2009). They all seem to contribute to customization, although product features, business process maturity, and project management have been highlighted in the literature (Rothenberger & Srite, 2009).

Customization and its consequences

The variety of reasons for customization results in versatile problems. The most frequently mentioned issue is “misfits.” Misfits are the gaps between the functionality offered by the package and that required by the adopting organization. Soh et al. (2000) identify three types of misfits: data, process, and output. Data misfits arise either from incompatibilities between organizational requirements and the ERP package in terms of data formats or from the relationships among entities, as represented in the data model. Functional misfits arise from incompatibilities between organizational requirements and ERP packages in terms of processing procedures. Finally, output misfits arise from incompatibilities between organizational requirements and the ERP package in terms of the presentation format and the content of the output. When a misfit occurs, an organization needs to either adapt to the new functionality (e.g. by changing its business processes) or customize the software package. A widely accepted practice is to limit customization, as it increases the system’s lifetime costs (Fryling, 2015) and makes change management more difficult. Consequently, it is argued that customization is one of the reasons why ES projects fail (Rothenberger & Srite, 2009).

In conventional software projects, customers specify their requirements during the requirements elicitation phase (Parthasarathy & Sharma, 2016b). The software product is then developed accordingly. In contrast, in the case of ES projects, a product is designed and developed not for one organization but for many so that it encapsulates the assumed best practices of the industry (Luo & Strong, 2004). This generic product is then modified according to customers’ needs. ES vendors often participate in this process to match a customer’s requirements with the ES solution. The customer organization may change its business processes – as promoted by the ES product due to its supported “best practices”—or the customer may request that the vendor modify the system. The former is referred to as business process customization, while the latter is referred to as ES customization (Luo & Strong, 2004). In business process customization, the vendor faces fewer technical constraints and problems, most of which can be treated as trivial, while system customization is accompanied by a greater risk of moving away from best practices and processes (Light, 2005). Although the degree of customization can be reduced and controlled by the vendor, it practically remains unavoidable (Parthasarathy & Sharma, 2016b).

Business process modifications align the processes with the PES’s “best practices” (Scheer & Habermann, 2000). The organization adopting the ES has several options in this regard (Brehm et al., 2001). For example, the vendor may configure the system according to the organization’s business needs by selecting appropriate components and setting parameters that allow the customer to modify it within certain boundaries. While this may address many customization needs, it may not accommodate all existing business processes. Alternatively, organizations can implement third-party packages designed to work with the PES and supplement its functionality. Vendors can also build dedicated features to address a customer’s unique needs on top of their ES platform. These approaches require additional system development but do not modify the existing system code. Consequently, when the PES is subsequently upgraded during its lifetime, the functionality can be retained if the new module adheres to the vendor’s interface standards and naming conventions. With respect to future system releases, ES vendors usually do not change certain standards that specify how one can connect to other applications. Finally, the ES source code itself can be modified to fit an organization’s needs. This requires substantial development effort and specialized expertise and easily splits the product versions into two developed paths. This, in turn, may necessitate code re-modifications when the system is upgraded (Rothenberger & Srite, 2009).

PES customization is expected to be linked to an organization’s strategic goals. This connection may be weak or even contradictory. The gaps between the goal and the PES can be costly and have severe business implications. Customizations may also have negative impacts on PES quality and may lower the system’s acceptance level among its users (Parthasarathy & Sharma, 2016b). However, associating the changes with strategic objectives tends to minimize the amount of customization (Haines, 2009). As customization has long-term implications for an organization and its finances, IT infrastructure, and processes, among other things, understanding the reasons why organizations customize their PES becomes evident.

Research settings and methods

A qualitative case study approach helps researchers gain an understanding of a particular phenomenon and its underlying issues in a certain context (Darke et al., 1998; Walsham, 1995). In the words of Klein and Myers (1999), “interpretive research can help IS researchers to understand human thought and action in social and organizational contexts. It has the potential to produce deep insights into information systems phenomena including the management of information systems and information systems development” (p. 67). This goal aligns with our aim of understanding EAM customization. Therefore, we follow the traditions and practices of interpretive case studies (Walsham, 1995, 2006). Next, we describe our research settings and methods in detail.

We conducted an interpretive and qualitative case study to understand why organizations customize their EAM systems. We studied a specific EAM called IBM Maximo. IBM Maximo (later referred to as “the Product”) is a market leader among EAM systems and has been globally used in numerous organizations for almost 40 years. Hence, it can be considered a mature and high-quality ES. As it is sold as a product, operates at an enterprise-wide level, and is customized to fulfil customers’ needs, it serves our needs for understanding the reasons for pursuing EAM customization. The focus on a certain EAM and product reduces the potential bias caused by different technologies and systems and helps us understand the reasons for customization beyond technologies, as the differences between the products do not hamper the findings.

We derived data for our study from 10 organizations located in Finland and Sweden. The Product is used in their enterprise-wide day-to-day operations, such as for work management, stock management, purchasing, and plant operations. Some organizations have upgraded the Product from an earlier version to make use of new features, while others use fresh implementations after having phased out another legacy system. Every organization customized the Product for implementation or upgrading purposes, for maintenance and support, or due to business-scenario changes. This variety provides us with a rich set of data to understand EAM customization.

The interviewees and their organizations operate in diverse business domains and have a broad range of processes. They were selected based on their extensive experience with the Product – some had been using it for a decade – and our interpretations of their processes’ high level of maturity. For example, these well-known companies have continuously improved their maintenance processes and kept their personnel safety at a high level, so their maintenance practices are considered when opting for an EAM system. We selected our interviewees based on their involvement with either the implementation or upgrading of the Product or with its day-to-day operations. We also had a practical reason: the first author had worked with the organizations for years as a consultant, so he was familiar with them and their employees and was able to identify and contact the appropriate people for the interviews. Table 1 lists the participants and their organizations.

Table 1. The list of interviewees and their organization’s business domain.

Organization	Business Domain	Est.	Interviewee code	Country	Role
Org A	Power grid operation (Annual Revenue 2020: 682.5 million EUR)	1996	I1	Finland	System Specialist
			I2	Finland	Project Manager
			I3	Finland	Consultant
Org B	Power plant (Annual Revenue 2020: 115 million EUR)	1998	I4	Finland	Business Representative
			I5	Finland	Consultant
Org C	Traffic authority (Annual Revenue 2020: 809 million EUR)	2010	I6	Sweden	Consultant
			I7	Sweden	Business Representative
Org D	Mining (Annual Revenue 2020: 758.6 million EUR)	2006	I8	Finland	Business Representative
			I9	Finland	Business Representative
			I10	Finland	Product Owner
Org E	Power generation (Annual Revenue 2020: 115.5 million EUR)	1977	I11	Finland and Sweden	Business Representative
Org F	Mining (Annual Revenue 2020: 307.3 million EUR)	1920	I12	Finland	Maximo Administrator
Org G	Power plant building and operation (Annual Revenue 2020: 1.7 billion EUR)	1834	I13	Finland	Maintenance Manager
Org H	Manufacturing (Annual Revenue 2020: 508.9 million EUR)	1988	I14	Finland	Business Representative
Org I	Hospital and municipality services (Annual Revenue 2020: 415.99 million EUR)	1863	I15	Sweden	Business Representative
Org J	Construction (Annual Revenue 2020: 109.5 million EUR)	1988	I16	Sweden	Business Representative

We conducted a set of semi-structured interviews. The questions were developed based on the first author’s 10+ years of experience in the implementation and customization projects of the Product and prior research literature. Using open-ended questions allowed us to learn the reasons behind customization and what the organization could have done to avoid it. The questions, listed in the Appendix, also focused on the roles of consultants and management with regard to customization and on the factors influencing customization. The interviewees were asked to refer to some examples, as this helped us ask “why” and “how” questions, gain insights regarding the big picture, and concretize the conversation.

All interviews were conducted remotely due to the ongoing pandemic in autumn 2020. Before the interviews, we informed the interviewees about the topic and type of questions but did not disclose the exact verbatim. The interviews lasted about 55 minutes on average, were audio-recorded, and were supplemented with written notes.

Following the interpretive research guidelines (Walsham, 2006), the first author inductively analyzed the data to form a list of customization reasons. The inductive analysis, exemplified in Table 2, consisted of going through the meeting notes and recorded interview sessions, identifying and summarizing the reasons for customization (open coding), collecting and combining the reasons from each interview into a single list, analyzing the list to remove duplicates, identifying the themes behind the reasons, and, finally, categorizing the themes and their relationships (selective coding). These findings were then collaboratively discussed and iterated with the other author to reduce potential single-researcher bias. The final list of reasons consists of 20 reasons for customization. Finally, we analyzed the reasons to see when specific reasons emerged in relation to the EAM project phases and whether any relationship existed between them.

Table 2. An example of the analysis.

Customization reason (Examples from the data) (Reason, as quoted by the interviewee)	Categorizationreason (open coding) (Key point from the reason for customization)	Category (selective coding) (Grouping customization reasons into a broader category)
Org A: Our goal was to change the process and do less customization, but there was too much resistance from the business people.	Resistance to change	Business process: Business representatives had different reasons that justified their current ways of working. Changing the business processes was not worth it.
Org B: The IT department wanted to keep the customizations low and change the business processes. However, the business	Cost and risks outweigh the benefits of change
units hesitated because of the risks and training needs.
Org E: The business units wanted to explore new ways of working.	Resistance to change
Org H: A legacy system had been used for more than 20 years. There was thus a comfort zone around the way of working. This was perceived as the only right way of working.	Resistance to change
Org A: Our processes are developed and operated locally. They do not follow any global best practice or the “way of working” recommendation. No system in the market would fulfil our needs. We went for a product that has higher potential for customization.	Localization	Product features: A PES is built on an understanding of an industry’s best practices. These practices are not valid in every context. This may result from the vendor’s geographical origin, which influences the supported processes, local regulations, and exceptional business needs, among other reasons. The product lacked many local features that had to be customized.
Org E: The Product lacked essential functionality. A new application and some features were added on top of out-of-the- box application. These include, for example, a customized permits- management application for regulatory needs.	Regulatory needs
Org G: The product lacked some features that are relevant to our business processes. The vendor had no plan to implement those in the near future. We were forced to customize.	Slowenhancement implementation

Findings

Our findings regarding the reasons for customization are summarized in Table 3 and explained in detail in the subsequent section.

Table 3. Summary of customization reasons.

Category	Customization Reasons
Business Process	Resistance to change
	Brainstorming the process and too many disciplines
	Costs and risks outweigh the benefits of change
	Missing the big picture
	Business expansion
Product Features	Missing features
	Localization
	Licensing model issues
	Slow enhancement implementation
	Too easy to customize
	Regulatory needs
Project Management	Ineffective or absent change management
	Creeping requirements
	Lack of management support and vision
	Lack of resource availability for project work
	Requirement-related clarity issue
	Lack of IT development skills
	Time constraint
Stakeholder Relationship	Communication gap between customers and consultants
	Bad design decisions

Business process

The business process category includes the reasons that originate from business development, business expansion, or changes in business processes.

Resistance to change. Often, organizations feel comfortable with fixed processes and their marginal improvements. A new EAM system, however, aims to markedly improve efficiency, reporting, and operational synergies. This may require significant changes to business processes. As this creates considerable resistance to change, the technology must be adapted to the situation. The need to cope with resistance to change was the single most frequently mentioned reason for customization. A project manager (I2) articulated this as follows: “We are a power grid operating company in Finland. Our maintenance and operation processes are homegrown and have been practiced for decades. The senior foremen think our processes are the best and there is no need to change them. It could be a cultural issue but that’s how it is.”

Brainstorming the process and too many disciplines. One organization (Org D) planned to expand its business to another area. A team of experts from different domains was summoned to define new business operations and processes. They brainstormed and built a process according to their previous experiences. The outcome was very different from the product capabilities, meaning that the system had to be customized. “We had too many experts for a simple process. Perhaps it would’ve been better to start with a simple process instead of discovering the best of breed at the beginning” (product owner, I10).

Costs and risks outweigh the benefits of change. The business representatives also experienced some problems with their current processes. When they assessed the process redesign work and the associated risks, they identified a need for training thousands of personnel and managing significant business continuation risks in association with process development. Hence, they decided to continue with their current processes and customize the product instead. “Benefits from the change were much less than the work needed to implement the change and manage the associated risk. Risks were especially high during the annual outage” (business representative, I4).

Missing the big picture. In Org G, the decision of whether to change the business process or customize the product was left to the business representatives at the shop floor level. They considered all the information they found feasible and made the best guess. Unfortunately, they missed the big picture and lacked an understanding of the strategic objectives behind the product, the long-term implications of customization, and the benefits of harmonizing the processes. This resulted in extensive customization. In the future, these small changes will cause severe problems, as managing them will be very difficult. A maintenance manager (I13) described this as follows: “Contract managers and work planners were free to decide how the system should work. The result was a process the consultants were asked to make. We ended up having a heavily customized system, which is not yet stable enough even after several years in production.”

Business expansion. The Product rollouts are governed by requirements defined earlier. After the Product rollout, Org H acquired a new factory, where the ways of working differed from those configured in the Product. As a result, Org H was in a difficult situation, with three competing sets of requirements: current practices, defined requirements from the pre-acquisition era, and new requirements from the acquired organization. This led to additional customization that had to be built on top of the existing processes: “Our original goal was to roll [the system] out for three factories. However, later we acquired a new business which was not big enough to have a dedicated system. We plan to extend [the system] there but it needs to be little modified” [I14].

Product feature

Missing product features are a large category of customization reasons.

Missing features. Most of the organizations had experienced missing product features. Although the Product has evolved and improved over time, it still lacked features that were desired by the businesses. Thus, they analyzed the Product and requested customizations: “The latest release of the industry solution lacked many features related to equipment groups, clearances, radiation permits handling, etc. We had to customize the product to get the missing features [I4].

Localization. Often, the work processes and practices were homegrown and did not follow any standards. The customers considered that there was no product in the market that could fulfil their needs. They felt that they had to either build one from scratch or modify an existing software product extensively. For example, a customer opted for a product that was easy to customize: “Our needs were unique. We knew no system in the market would meet them 100% and we have to anyway customize it a lot, so we focused on a system that offered a robust product base and was easy to customize” [I1].

Licensing model. There was a problem with the licensing model: “We needed one application for a root-cause-failure analysis. This application was not included in the product’s basic version. If we wanted to get it as an out-of-the-box solution, we had to buy an extra license for an add-on Health Safety and Environment. That was expensive compared to customizing and building one feature on top of the base solution. So we went for customization” [I8]. Organizations may have budget constraints or a need to strike a balance between costs and features. They may need only a few applications or features that are part of a larger package with many unnecessary items. With a product, the customer may have to buy a bigger and more expensive add-on. When the expenditure cannot be justified, customizing the base product becomes the evident choice.

Slow enhancement implementation. Organizations constantly monitor their environments and react quickly to different incidents and pressures. They also expect their vendors to be responsive and to provide enhancements quickly. If enhancements are requested by several customers, they may be implemented in the next product release. From the customers’ perspective, this could be very slow. It may also happen that the request is not considered at all. As customers cannot wait for potential future enhancements, they customize the product. A maintenance manager (I13) articulated this as follows: “We met a product manager at a conference and mentioned that [a certain feature] is not relevant because the machine loads might not be the same in the coming months and the machine might run on different types of fuel like petrol or gas, so following a fixed interval or meter-based maintenance strategy is not good enough for us. He responded that they know this is a valid requirement but since they do not have other customers bringing it up, it might take time to get it implemented in the out-of-the-box solution. We are now customizing it in the product ourselves.”

Too easy to customize. The Product has a lot of capabilities and is easy to customize. This encourages customization instead of compromising product features and changing business processes. “We customized it because it didn’t take a lot of effort” [I14].

Regulatory needs. Sometimes, geography-related or region-specific regulatory compliance needs to be implemented through customization. There might be a need for extra reporting, for example, to customs or tax authorities, or there might be specific safety- or legislation-related needs that are not supported by the standard product. “The Product is from the US. It lacked the local [Finnish] regulatory compliance features related to radiation permits handling and clearances. We had to customize those” [I4].

Project management

System renewal projects and project management issues are also possible sources of customization.

Ineffective or absent change management process. Many organizations lacked or had ineffective change management teams. This translated into change needs being analyzed superficially, potential implications not being discussed, or workarounds or alternate possibilities for the product not being explored. “Decision making related to customization was left to the personnel at the factory floor level. [Business representatives] gave the requirements to the consultant and asked them to configure the system accordingly. This was not the right way to do this. Unfortunately, this was how we did it. We should’ve been done it better” [I13].

Creeping requirements. Ideally, all business units participate in the systems requirement specification phase. In our organizations, this was often not the case. The business participants were not available or did not volunteer to participate in the requirements specification, or someone else designed the process. This resulted in new requirements emerging after the business process was implemented, as it was changing current practices. “During the requirements specification, only the headquarter people participated. Later, a new factory joined the project and started following what was already built. The product was then rolled out to another business site. They had completely new set of requirements, a few that even contradicted earlier designs” [I14]. The system was customized.

Lack of management support and vision. Management plays an important role with respect to setting a vision and guiding expectations and teamwork. When managers’ participation in scheduling or budgeting a project was inadequate, project teams acted independently, implementing and customizing features without prioritizing business needs or thinking about the big picture. “The implementation project lasted for approximately 2 years. Decisions on processes and customization were mostly done at the business level. Had we had an active senior management involvement beyond the timeline and budget, maybe we could have evaluated to customization needs before implementing them. Unfortunately that didn’t happen and, here we are” [I2].

Lack of resources for project work. Although the business representatives devoted time to a certain project, they also had day-to-day commitments. They had limited time to analyze the processes and test the system. This, in turn, resulted in a superficial analysis of certain details and changes and caused costly changes and additional customization. “The process planners had to do a lot of day-to-day work. They had very little time for the project. We could have done much more testing to avoid some surprises after the system went alive” [I13].

Requirement-related clarity issue. Consultants and business representatives could hail from and be located in different countries and cultures, and there could be gaps in their mutual understanding. Some customers indicated that the agreed-upon and documented requirements were understood differently by the consultants and then implemented according to their interpretations. For example, “the lead consultant and our business team had difficulties to understand each other, maybe the consultant was from a different country or culture” [I13]. This gap in understanding led to inappropriate designs and implementations, requiring additional customization later to fix issues and improve the system.

Lack of IT development skills. Some organizations did not have a proper way to manage their requirements and the system development process. This resulted in the project losing its focus. The system was developed and deployed in an unstructured manner. For example, problematic design issues and bugs were ignored, and the customized product was pushed to production. Extra changes and customizations had to be made to make the system stable and usable. A business representative articulated this as follows: “We had an issue with the document management. The features were derived from an old version of requirements. We realized this quite late in the project. The solution was already working but had some minor bugs. Due to the time constraints we had to push it for production and live with those bugs for sometime” [I11].

Time constraint. Time represents another constraint and is a reason for customization. Usually, software products evolve with each release when new features become available. For example, if a customer has an older version of the Product, they may have customized some operations that are now available as standard features. The time constraint limits the chances of investigating earlier customizations and comparing them to the new release. Therefore, customers end up re-customizing the new version, even though the functionality they need is now provided as a standard feature.

“There were some customizations that could have been phased out if we had time to go through the possibilities of the out-of-the-box product. Because of time constraints, we could not do this. The existing customizations continued after the product upgrade”. [I15]

Relationship between consultants and business representatives

Our final category focuses on the relationship between consultants and business representatives.

Communication gap between customers and consultants. Consultants and business representatives have different cultural backgrounds, education, and experiences. This often creates misunderstandings and communication problems (Kähkönen, Alanne, et al., 2017). In our organizations, explicitly articulated requirements resulted in a system that differed significantly from the business representatives’ expectations, which were not properly communicated to the consultants. Testing revealed some of these issues, but all the problems surfaced only after the system was put into use. The later the problems are found, the more costly they become and the more customization was needed. This emphasizes continuous communication to reduce the communication gap. A maintenance manager said, “The consultant’s interpretation of the requirement led to some bad design decisions, like creating a work order for every individual part of the engine. That caused many unnecessary work orders, which had to be dealt monthly by already overloaded planners” [I13].

Bad design decisions. Bad design decisions are made by business representatives and consultants. As consultants have limited business knowledge and representatives have limited product knowledge, they can easily make bad design decisions early in a project. This usually causes further customization later on when implementing the system. The business representative complained that “the consultant made customization decisions. Later it was found that the product already had that feature. The consultant was sold to us as an expert in the nuclear industry processes. It turned out that he didn’t have any experience of nuclear industry and learned it on our project” [I5].

Discussion

In this paper, we explored the reasons behind EAM customization. In total, we identified 20 customization reasons (as listed in Table 3), which were categorized into four themes: the absence of essential features, business – process gaps, poor project management, and complicated relationships between the parties. We also explored when customization takes place.

Reasons for customization

The categories illustrate that different problems with system implementation projects are solved by customizing the system. Poor project management, limited understanding of the business in general, and the relationships between different parties and stakeholders are well known in the systems implementation literature (Dwivedi et al., 2015; Luftman et al., 2017; Pan et al., 2008). In the context of EAM and PESs, however, the problems are managed by customizing the system, which makes the problems visible or even creates new problems. Interestingly, this issue has not been explicitly discussed earlier. The fourth category of customization, the absence of needed product features, touches upon business – IT alignment issues, where product deficits are solved by system add-ons or business process changes (De Haes & Van Grembergen, 2005). Again, customization as a means for coping with business – IT alignment problems has not been explicitly considered previously. Consequently, our categories of customization reasons are parallel with the earlier literature, but as the topic has not been considered explicitly (Singh & Pekkola, 2021), this research provides the first exploratory results and calls for more research.

Resistance to change has been well documented and discussed in the information system (IS) context (Jiang et al., 2000; Ross, 1999). This resistance reflects the organizational culture and its aversion to change, which can affect PES implementation outcomes (Stewart, 2000). From this perspective, our findings are not surprising. However, it has not been discussed earlier that organizations customize their ES to avoid changing their business processes.

On the other hand, organizations may unintentionally customize their PESs in the course of developing processes. Not understanding the benefits of ESs, missing the big picture, or having different business development objectives may result in changes and customizations that are not good in the long run. This kind of unintentional development indicates a poor business – IT relationship (Haines, 2009) and a lack of strategic business development (Rothenberger & Srite, 2009). Evidently, as with any ES implementation, as well as with PESs and their customization, no matter how small the changes are, they should be treated as strategic decisions.

Product maturity seems to be an important factor in PES customization. The more mature the technology, the less customized it is. For instance, optimistic expectations regarding the future functionalities of an incomplete packaged solution can result in it being favored over a custom-developed system. If a new software package with new features is delayed, the need for customization increases (Haines, 2009).

A PES and its deficits represent an evident reason for customization. If the Product is missing an essential feature, the feature needs to be implemented somehow, and this is usually achieved by customizing the PES. Customization may also take place due to the need to integrate PES with other systems in the organizational IT landscape (Haines, 2009). Similarly, local needs, such as regulatory or safety needs, localization, or dedicated processes may lead to customization.

Over the years, the Product has evolved in terms of technical architecture and features in response to the demands of the changing business environment. Despite this, the speed and certainty of the delivery of a feature may still be too slow for businesses, so they choose to customize their EAM. From this perspective, easy customization is an advantage, as new features can be implemented quickly. However, this ease may become a double-edged sword if the EAM is customized carelessly. The benefits of an ES, such as the integration of processes and data flows across an organization, may be lost, or maintenance and replacement costs could skyrocket.

Interestingly, the licensing model may also lead to customization. Large software packages with many unnecessary features result in a poor cost – benefit ratio, making customization a financially tempting alternative despite this increasing lifetime costs.

Top management support and project leadership have been identified as the key success factors in ES implementations (Beath, 1991; Brown & Vessey, 2008). We show that top management support influences not only projects but also customization decisions. In our organizations, many managers did not understand the constraints or long-term impacts of PES customization (Smolander et al., 2017). They focused more on project-related issues, such as schedule and budget, and not on thoroughly understanding the content and whether and how the Product should be customized. For example, change management was unstructured, customization-related decisions were made at the factory floor level, the big picture of the long-term effects was missing, and long-term objectives were either omitted or not communicated properly. All these reasons lead to system customization despite foreseeable future problems.

The structure and relationships within and among the ES project team members, including the consultants and business representatives, have been identified as important success factors for ES implementations (Brown & Vessey, 2008). Our findings demonstrate that poor relationships between these parties result in unnecessary customizations. Our findings also suggest that a well-performing project team has the potential to reduce customizations (Haines, 2009).

Customization in relation to the EAM project phases

Next, we analyzed the EAM project phases: product evaluation and selection, project planning, system design, and development and rollout (i.e. organizational implementation).

Organizations have compelling reasons to adopt EAM, which could be technical, functional, or both (Markus & Tanis, 2000). For example, organizations may consolidate a number of legacy systems into one ES to reduce the overhead costs of managing different systems and suppliers or implement a cutting-edge technology platform to help acquire competitive advantages. Furthermore, with a new ES, it might simply be easier to integrate the systems and support better information flows (Markus & Tanis, 2000). Usually, the rationale behind acquiring an ES is to solve one of the bigger organizational problems. This stance is considered one of the strategic success factors of PES implementation (Holland & Light, 1999).

We found that unless the project’s strategic objective and vision are communicated or top management support is continuous, the amount of customization easily becomes extensive. The vision, for example, guides contract and licensing negotiations with vendors and helps avoid unnecessary costs that stem from having a superficial understanding of long-term requirements. Similarly, clear objectives help business representatives define system requirements and weigh alternative change, benefit, and risk scenarios that seem costly in the short term, thus motivating customization, but provide reasons for fundamental process changes in the long term. This issue emerges early on in the project, resulting in customization later.

The next phase is project planning. This includes planning change management, how and when to communicate, and what kinds of resources are needed and when. Insufficient change management – any task in this phase – may lead to unwanted customizations later (see Figure 1). Hence, these factors indirectly influence customization.

Figure 1. Reasons for EAM customization in relation to a PES project’s phases.

We mapped the customization reasons in relation to an EAM project’s phases (Figure 1). In addition to the product evaluation and selection phase, as well as the project planning phase, subsequent phases may initiate EAM customization. This seems to occur especially during the system design phase, when different design decisions are made in collaboration with business and IT representatives and consultants. An effortless short-term decision to customize the system can be made rather easily at this time. Furthermore, local needs may be considered easily – even if they are not really needed – if the system is known to be easily customizable or if its vendor is known for slow response times. However, it should be noted that the reasons are independent and that subsequent reasons may appear even if their predecessors have been sufficiently managed.

Conclusion and contributions

This paper illustrates myriad reasons for opting for customization. ES customization is not done only because of poor support for business processes or because of poor IT – business alignment. We found that EAM can be customized for 20 different reasons, which are listed in Table 3. Although this list was composed of a case study, these findings largely align with the literature – although only on a general level and not in the context of PES customization. Therefore, Table 3 can be seen as a framework for understanding, analyzing, and managing the reasons for customization.

Our findings also highlight the needs for customization that may emerge throughout the implementation of a project and throughout the Product’s lifecycle (see Table 3). However, the absence of essential features is only one category of customization reasons. In addition, business activities and processes and the reluctance to change them may initiate customization. Furthermore, when an implementation project is ongoing, project management issues and the relationship between consultants and business representatives may result in unintended and unexpected customization initiatives (see Figure 1). This means that seemingly simple EAM customization, and PES customization in general, may actually stem from several interconnected factors (Brehm et al., 2001). This emphasizes

the strategic nature of PES customization and the fact that customization is not only about “modifying the software” but also about understanding its relationship in a broader business context with the business processes and long-term business goals. For example, if business representatives are more knowledgeable about new product possibilities and the benefits of a less customized system, the level of customization may be reduced. This is preferable because the system’s maintenance costs increase rapidly with customization (Haines, 2009).

Our study considers earlier findings regarding IS development issues in the context of PES customization. Our findings are supported by earlier studies (Haines, 2009; Rothenberger & Srite, 2009), but we expand their focus and deepen our understanding about the reasons for PES customization, especially EAM customization. Thus, we contribute to the existing customization literature in several ways:

• Our findings show that customization may be initiated not only during the EAM implementation project but also anytime during the system renewal project. In addition, inadequately planned customization results in small-scale improvements and the deterioration of enterprise-wide scope. These insights underline the strategic nature of customization and active top management participation.

• Top management participation is not sufficient if its understanding of the product’s capabilities, features, and business processes is limited. This, in turn, emphasizes the need to obtain a comprehensive understanding of the possibilities and limitations of the PES, its related processes, and the organizational culture, operations, strategy, and stakeholders.

• As customization is an understudied topic, our study builds the foundation for further research on customization and its reasons and impacts. For example, different types of PESs, business domains, geographies, and the relationships between different customization reasons need to be studied to understand the differences between the contexts and to gain an in-depth understanding of these concepts. Similarly, more research is needed to understand the relationships between different customization reasons. In this regard, Figure 1 acts as a starting point. Moreover, understanding the reasons behind customizations helps to reduce the amount of customization.

Our contributions to practice are as follows: Our findings help organizations implementing EAM (and PESs) manage possible blind spots where unintended and inappropriate customization may take place. This will allow them to achieve less customized systems whose lifetime costs are smaller and, at the same time, enable the PES to better fulfil their business objectives. When planning a PES implementation and during the implementation project, profoundly understood customization reasons increase the chances of achieving successful PES implementation. In addition, vendors benefit the study, as they can identify areas of improvement to make the product more adaptable to varying business needs.

There are some limitations. This is a single case study of an EAM system: IBM Maximo. Therefore, it is justifiable to ask whether the customization reasons are narrow and product- and organization-specific. We argue that our findings are generalizable to other PESs, as no product-specific items were identified. Our customization reasons focus more on the organizations and their business environments and not on the Product, EAM in general, or technologies per se. From this perspective, it can be said that focusing only on a certain PES reduces the potential influence of different technologies or of their varying maturity levels. It is also feasible to ask whether our consideration of Scandinavian organizations affects our findings. Again, we argue that this is a minor issue, as our findings align with the literature on different IS implementation contexts. Furthermore, the EAM markets of Western countries with a population of over 18 million are significant. Third, the choice of qualitative and exploratory research approach does not provide a basis for prioritizing customization reasons or understanding their interrelationships. Instead, our findings should be interpreted as a set of examples of the possible reasons for customizing PESs. Hence, more research is needed, as argued earlier.

Disclosure statement

No potential conflict of interest was reported by the authors.

Additional information

Notes on contributors

Chandan Singh

Chandan Singh, Masters in Computer Application (MCA) is doctoral researcher at Tampere University, Finland. He studies packaged enterprise system customization and its managerial practices. He has more than 14 years of IT industry experience on implementing and customizing EAM systems. He is currently working as Business Transformation Consultant at IBM, Finland.

Samuli Pekkola

Samuli Pekkola, Ph.D., is professor of information systems at Tampere University, Finland. His research focuses on users in different manifestations of information systems, information systems management and acquisition, and enterprise architectures. His research articles have appeared in journals such as Information & Management, Government Information Quarterly, Information Systems Journal, Decision Support Systems¸ Business and Information Systems Engineering, International Journal of Information Management, and The DATA BASE, among other journals and conferences. He is past editor in chief of Scandinavian Journal of Information Systems, and past president of the Scandinavian Chapter of the AIS.

Notes

1. SELECTHUB. 2020. Insights into the Enterprise Asset Management Software Market. Available: https://www.selecthub.com/cmms/eam/eam-market GLOBENEWSWIRE. 2022. Enterprise Asset Management Global Market to Reach $21.47 Billion by 2030 at a CAGR of 14.2%. Available: https://www.globenewswire.com/en/news-release/2022/08/01/2489182/28124/en/En- terprise-Asset-Management-Global-Market-to-Reach-21-47-Billion-by-2030-at-a-CAGR-of-14-2.html

2. GARTNER. 2019. https://www.ibm.com/blogs/internet-of-things/iot-gartner-magic-quadrant-2019/

3. GARTNER. 2020. Market Guide for Enterprise Asset Management Software 2020, https://www.gartner.com/docu- ment/3994833?ref=XMLDELV

Appendix Appendix

1. What was the strategic objective behind implementing Maximo?

2. Which is the most customized module in Maximo?

3. What were the reasons that the system got customized according to you?

4. Do you think there was a possibility to have a less customized system?

5. Was the product customized more during the implementation phase or the operation phase?

6. Did the project team (internal/external) have any influence on the level of customization?

7. Did you carry out a product evaluation before finalizing Maximo?

8. Did the project follow a particular budget and timeline?

9. How was the overall project experience?