Outlining a Process to Manage the Complexity of Enterprise

Systems Integration

Tommi Kähkönen

and Kari Smolander

Enevo Oy, Linnoitustie 6, 02600 Espoo, Finland

Aalto University, Department of Computer Science, P.O. Box 11000, 00076 Espoo, Finland

Keywords: Enterprise Systems, Integration, Governance, Process, Grounded Theory, Manufacturing Enterprise.

Abstract: New service combinations are constantly needed to be created from the array of information systems and

technologies, developed in different times for different purposes, crossing the organizational boundaries.

Integration is the key matter in organizations, yet it is also an ambiguous and often a misunderstood concept

in the field of information systems. In this paper, we construct an integration process from an inductive study

in a large manufacturing enterprise, by examining its long-term ERP development endeavour. The process

consists of four sub-processes with dedicated actors and activities. Integration Governance is needed to align

Integration Realization with the strategic goals of the organization. Integration Housekeeping is dedicated to

standardization activities and keeping the architectural description of the enterprise systems’ landscape

updated, and to aid Realization. By utilizing the assets produced by Governance and Housekeeping Integration

Evaluation is done to decide whether it is feasible to set up an integration project or abandon the initiative.

The process helps managers to manage the complexity of enterprise systems integration and avoid its pitfalls.

1 INTRODUCTION

“From the IT perspective I state that integration work

is the most challenging and it has a great impact on

the functionality and quality of the systems.” –

YCorp, Business-IT Negotiator

To better serve the business and customers,

information systems need to be integrated. Enterprise

systems integration has remained as a challenge since

the early days of business automation (Jacobs and

Weston 2007). The advances of integration

technologies enabled enterprises to shift from

mainframes to distributed systems automating more

complex business processes crossing the

organizational boundaries. (Alonso 2004). Currently,

the information systems landscape of a modern

enterprise consists of numerous different systems,

like ERPs (Enterprise Resource Planning) and CRMs

(Customer Relationship Management), and the

integration of these systems is a necessity (Gericke et

al. 2010; Vathanophas 2007). However, as the

number of systems increases, managing the array of

integrated systems become troublesome (Henfridsson

and Bygstad 2013). Additionally, the changing

dynamics of business increases the need to integrate

information systems as the movement towards more

collaborative nature of business has taken place. For

instance, end users and customers desire to access the

enterprise systems with mobile devices (Lozano et al.

2014). This in turn creates a need to provide the

enterprise systems’ functionality from the back

offices to the field of business (Lam and

Shankararaman 2004). Firms’ interaction with

customers, suppliers and employees have changed

through mobile services and social networking

(Tilson et al. 2010). Integration is at the focal point

of this change and it calls for means to be

systematically managed.

Unfortunately, the term integration is generally a

misunderstood concept surrounded by a fair amount

of confusion (see e.g. (Chowanetz et al. 2012;

Gulledge 2006). Even in the field of information

systems, there are various understandings of this term

(Rodon 2006). In addition, instead of addressing only

the management of a single enterprise system,

managing the arrays of systems has only recently

been addressed by academics (Henfridsson and

Bygstad 2013; Tilson et al. 2010). In this study, we

aim to increase the understanding of integration and

its importance in a complex environment. We

examined integration in a large manufacturing

enterprise, which was building and renewing its ERP

306

Kähkönen, T. and Smolander, K.

Outlining a Process to Manage the Complexity of Enterprise Systems Integration.

DOI: 10.5220/0006349703060315

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 3, pages 306-315

ISBN: 978-989-758-249-3

system landscape (i.e. the key systems and integration

technologies for its business) while wrestling with

major organizational and business changes. The

integration process is inductively constructed with the

Grounded Theory methodology. The following

research question has been set: What constitutes the

process when attempting to manage the enterprise

systems integration?

2 BACKGROUND

In general, the concept of integration has been

identified as an ambiguous concept, prone to

misunderstandings due to its nature (Chowanetz et al.

2012; Rodon 2006). Integration has been studied

from different viewpoints, e.g. technological,

organizational and strategic perspectives. The

technological aspects of integration have been studied

widely, but in the context of ERP systems, the studies

focus mostly on a specific target system (Kähkönen

and Smolander 2013). The organizational perspective

has focused on organizational characteristics and

intra-organizational factors, such as top management

support and cultural fit (Chowanetz et al. 2012). From

the management viewpoint, the strategic perspective

of integration has mainly focused on the management

of integration in mergers and acquisitions (Alaranta

and Kautz 2012; Henningsson and Carlsson 2006;

Mehta and Hirschheim 2004; Wijnhoven et al. 2006).

It has been suggested that the broader context in

which integration takes place should be studied more

to understand how the arrays of enterprise

information systems can be managed (Lee and Myers

2004; Tilson et al. 2010).

There is a lack of processes or approaches that

capture the specific needs of integration (Wing Lam

and Shankararaman 2004). Our aim is to better

understand the process of integration when aiming to

manage the complex array of information systems. To

achieve this, we made an inquiry to practice and

examined the development of a key information

system of the company - a customized information

system for sales and logistics. At the time when the

interviews were made, this system reached the

retirement phase of its life cycle after 20 years of

intensive development. The rationale behind this

study is that when managers understand the

integration process better, they make better decisions

to control the arrays of information systems and avoid

their unmanaged evolution and undesired outcomes

(Ciborra 2001).

3 RESEARCH APPROACH

Since the mid-1990s, qualitative research methods

have resonated. They represent a shift away from

technological issues to managerial and organizational

matters in information systems development (Myers

1997; Myers and Avison 2002; Sarker et al. 2013).

Qualitative methods, such as Grounded Theory, have

been recognized useful when there is a goal of

understanding from the point of view of the

practitioners and when the rich social and institutional

context is important for understanding (Kaplan and

Maxwell 2005). In this paper, we use Grounded

Theory, originally developed by Glaser and Strauss in

1967 (Strauss and Corbin 2008), as the research

method to investigate integration process from the

organizational perspective.

Grounded Theory is especially suitable for

approaching complex organizational phenomenon

such as enterprise systems integration (Charmaz

2006). This suited to our research interest well,

because integration imposes social and organizational

issues besides the technical challenges (Welker et al.

2008). Our approach is interpretive, because we aim

at making sense of the full complexity of the

phenomenon in its social and organizational context

(Walsham 1993). Grounded Theory allows

developing theory iteratively based on systematically

collected and analysed data (Strauss and Corbin

2008). The data is usually collected by interviewing

or observing one or several cases, but other sources

of evidence, like written documentation or other

archive material can be used as well (Urquhart et al.

2010). Grounded Theory is useful for creating

context-based and process-oriented descriptions of

organizational phenomena. For example, the Corbin

and Strauss version of Grounded Theory provides

clear guidelines for data analysis (Corbin and Strauss

1990). The main benefit of Grounded Theory is that

it allows the researcher to trace back to the original

sources of data in order to observe how the theory has

been developed and how different instances of data

have emerged into concepts and relationships

between them (Strauss and Corbin 2008).

3.1 Data Collection

The dataset contained 21 transcribed theme-based

interviews addressing ERP development and

integration issues encountered in the organization.

The interviews, that were selected by snowball

sampling, included viewpoints from the organization

adopting the ERP system (from now on referred as

YCorp), the vendor implementing the system

Outlining a Process to Manage the Complexity of Enterprise Systems Integration

307

Table 1: The organizations and roles of the interviewees.

Representatives of YCorp Representatives of Vendor and Middleware

Provider

ID Role R1 R2 ID Role R1

YC1 Business-IT negotiator 62 100 V1 Software manager 48

YC2 IT manager of business

area

49 65 V2 Service owner 32

YC3 Program manager 32 - V3 Continuous service

manager

YC4 Enterprise architect 38 - V4 Infrastructure manager 56

YC5 Service manager of sales 58 - V5 Project manager 29

YC 6 IT support manager 32 - V6 Lead software

developer

YC 7 Representative of

logistics

31 - V7 Service manager 52

YC 8 Project manager 43 - MP1 Middleware manager 73

YC9 Manager of E-business

and integration

- 83 MP2 Technical consultant 73

YC10 Head of E-business and

integration

- 60

YC11 Business support

manager of a business

area

- 83

YC 12 Director of business

process development

- 34

R1, R2 = duration of the first and second round interviews in minutes

(Vendor) as well as consulting company (Middleware

Provider), who all were involved in implementation

the key information system of YCorp’s infrastructure.

The interviews were made in two rounds: the first

round (14 interviews, conducted in spring 2013)

addressed the general ERP development issues while

the second round (6 interviews, conducted in summer

2014) focused more deeply on integration and

enterprise architecture issues. The questions were

open-ended, and more detailed questions were based

on the answers. The positions of interviewees ranged

from upper management to mid-level management

and developers. The duration of interviews ranged

from 29 to 100 minutes, the average being 53

minutes. A list of the interviewees’ organizations and

roles is presented in Table 1.

3.2 Context Description

YCorp is a large manufacturing enterprise with an

annual turnover about 10 billion euros. In the

remaining sections of this paper, we refer to the array

of information systems and integration technologies

described in this section by using a term ERP System

Landscape. Figure 1 describes the ERP System

Landscape of YCorp.

Figure 1: ERP System Landscape, i.e., the key information

systems and the related business processes of YCorp.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

308

As a core technology in their ERP System

Landscape, the company has a custom-build ERP

system (Custom ERP) with a lifespan of 20 years of

development and use passed. This system automates

the sales processes currently in three of the five

business units of the company. It also takes care of

the high-level production planning while the detailed

production planning is done in Manufacturing

Execution Systems (MES) in facilities. Previously

automated by the custom ERP, the logistics processes

have been automated by several different systems

created for this purpose. Custom ERP is used in most

of the facilities world-wide, and it is integrated with

MESs via a custom middleware. The system has been

constantly adjusted according to the drastically

changing business conditions. The global SAP ERP

is used company-wide to manage the administrative

processes in most of the facilities, but some sites have

their local configuration of this system. The main

instrument for external integration is a middleware

product which provides the messaging and allows

building of business process logic. This platform is

mainly used for external integration with customers’

ERP systems and external transportation providers’

and warehouse systems. Different interfaces for

business partners have been built. The customers and

converters whose services YCorp utilized in product

modification have their own portals, through which

they can access the relevant information in Custom

ERP. Customer apps are mobile applications for

business partners to access the custom ERP. They

have been considered, but not yet implemented due to

cost-cutting pressures. Recently, the company has

been forced to constantly cut the development costs

and make its operations more efficient.

3.3 Data Analysis

The data analysis in the GT consists of three coding

procedures: open, axial, and selective coding (Strauss

and Corbin 2008). In open coding, the transcribed

interview data is first labelled with codes that capture

the meaning of the current piece of data. The most

important procedure in open coding is constant

comparison between the pieces of data in order to find

similarities and differences. In axial coding,

connections between codes and categories are

formed. Basically, this is the interpretation of codes,

categories, and properties developed in open coding

with the goal of refining the constructs and making

them more abstract and theoretical (Urquhart et al.

2010). In selective coding, the goal is to choose a core

category, interpret its relationships with other

categories and explain it as a theory. When data is

collected and analysed iteratively, the main question

is when to stop the process. As a theory emerges,

more focus is needed on some aspects of it. At the

same time, the categories, dimensions, and properties

become more refined when more data is collected.

The situation when the researcher finds out that a new

set of data will not bring significant new codes,

categories and/or relationships is called theoretical

saturation (Strauss and Corbin 2008). 169 codes and

16 categories were created during open and axial

coding. For example, category Actors contained all

the different sub-organizations and groups, such as

consultants, competitors, and end users involved in

system development. In addition, a category was

created for some of the organizations, such as

adopting organization, vendor and middleware

provider. Other categories were Activities (for

example, maintenance, deploying the system and

business process improvement) performed by Actors

and Assets (such as, enterprise architecture, ERP

strategy and standards). Integration was considered

as its own category, including codes such as planning

and decision making, project characteristics, and

target. Challenge was a category that contained the

notions of encountered problems related to any of the

other codes.

As the coding progressed from open to axial

coding, we noted that integration process cannot be

easily described with a single category, but other

categories were tightly coupled with it. We identified

4 sub-processes from the data: Evaluation,

Realization, Housekeeping and Governance. Each

sub-process was then further examined by first

creating a code for it and identifying the codes and

categories that were related to the sub-processes. This

revealed, for example, some of the related actors,

activities and assets of each sub-process. Axial

coding produced also four network diagrams. The

creation of new codes was ended when there were

indications of theoretical saturation, i.e. it was noticed

that no new codes related to integration issues

emerged from the data, and already observed

phenomena and patterns were repeated. In selective

coding, instead of choosing a single core category, we

interpreted the relationships between the four

identified sub-processes and constructed the

integration process, presented at the end of the next

section.

4 FINDINGS

In the following we describe the four identified sub-

processes of integration (realization, housekeeping,

governance and evaluation) identified in the data

analysis. The integration process is presented in

Figure 2 and summarized at the end of this section.

Outlining a Process to Manage the Complexity of Enterprise Systems Integration

309

Governance

 Defining and adjusting

organi zati onal strategies for

integration

 Perfo rmed by dedicated

actors

Housekeeping

 Standardizing ESL

 Upgradin g the technolo gy

base of ESL

 Maintaining the architectural

description of ESL

 Perfo rmed by dedicated

actors

Evaluation

 Identification of

integration requirements

 Piloting the new

technologi es

Realization

 Carrying out the integration

projects to realize the

business needs

 Perfo rmed by dedicated

actors

Project

established

Inputs

Features

realized

Figure 2: The integration process and its sub-processes.

4.1 Realization

“[The client organization’s] business units are

customers to their IT department. Our customer is

their IT organization. This is the old model that we're

stuck with. We would like to be more involved and

make better solutions”–Vendor, Service Owner

Realization is a sub-process of integration, during

which the development work required by integration

to satisfy the business need is carried out after a

project for integration initiative has been established.

In YCorp, integration had required a significant

amount of effort during the entire life cycle of Custom

ERP, since the initiation of the project in mid-1990s.

Both small and large-scale integration projects had

been taken place. An example of a rather small

integration effort was a sending of internal invoice

from one facility to another. In a large integration

project, the system was deployed to a facility and

integrated with the MES of the facility.

Vendor had a major role in integration realization,

especially when deploying the system to facilities and

integrating it with a MES. While the most intensive

roll-out phase had been completed during the time of

interviews, deployments were still ongoing in remote

locations as the business expanded to new areas. The

Vendor had provided some of the facility systems and

had the inside knowledge of them. Therefore, the

deployments were carried out in close cooperation

and systematic manner between YCorp and Vendor.

Supportive practices depending on the characteristics

of the facility system in question were used as assets

in integration. However, currently the vendor felt that

the current way of carrying out the development work

in integration was not optimal. The constant cost

saving pressures due to the drastic changes in

YCorp’s business performance had forced YCorp to

cut down the development costs. Because of this, the

development work was offshored to lower cost

countries by the vendor. This slowed down the

development process. The time that it took to realize

a new feature request as a feature to the ERP system

increased. This also prevented the rapid reaction to

integration needs. Additionally, the representative of

Vendor (V2) stated that the development process was

not fully utilizing the expertise of Vendor. Vendor

wanted to be more involved in the early phases of the

development and affect the development decision

making to utilize its domain knowledge accumulated

during the years of collaboration. To speed up the

development process, agile development approaches

that enable better cooperation between the client

organization and the vendor were suggested.

4.2 Housekeeping

“[It] is a separate messaging standard which has

been built for [our] industry. [Our company] is one

of the companies developing that. There are also all

our biggest competitors involved in that work.” –

YCorp, Manager of e-business and integration

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

310

Standardization, making technology upgrades to

ERP System Landscape and maintaining its

architectural description were identified as activities

of the housekeeping process, because they facilitate

the integration realization but do not directly transfer

the business needs to the system features. The actors

performing this process can be different than those

who deal with realization. For example, YCorp and

Vendor both had dedicated teams responsible of

supportive activities ensuring the fluent operation of

the ERP System Landscape.

To facilitate message exchange with external

systems, YCorp participated activities with

standardization agencies and other companies,

including competitors in the same industry.

Standardization activities enabled the integration

with external systems, including raw material

suppliers’, transportation companies’ and warehouse

operators’ systems. Standards development had been

an ongoing activity since the early phases of the

Custom ERP. In addition, technical upgrades, such as

changing the database platform from one vendor to

another and upgrading the application servers had

been conducted. These were done due to performance

issues encountered as the scope of the Custom ERP

grew larger.

Previously automated by the Custom ERP, the

logistic processes were later automated by acquiring

numerous different systems for this purpose. This

created a need for managing the interfaces between

the systems and achieving transparency of the

business processes. YCorp faced a problem of not

being able to reliably trace the customer orders

because of the increased complexity of the ERP

System Landscape. To manage the complexity of the

ERP System Landscape, the role of architectural

descriptions in facilitating the identification of

integration requirements was discussed. While

having a small team responsible for dealing with

architectural issues, for example, ensuring that a new

technology fits well with the current technology

portfolio of the organization, it appeared that no

detailed description of the architecture of the ERP

System Landscape existed. It was also suggested that

by forming the architectural description of the ERP

System Landscape was considered difficult because

of its complexity and there cannot be a single person

to manage it. Instead, an interviewee (YCorp10)

suggested that a virtual enterprise architecture team

consisting on application experts should be formed.

Currently, architecting was not the responsibility of

application experts. The virtual enterprise

architecture team was predicted to better enable the

knowledge sharing between the organizational units

to tackle with complexity.

4.3 Governance

“But then the question is that who will pay what and

who can decide what? Can a single division decide

something which will have big effects on other

divisions, without asking for their acceptance? These

are questions which are not yet clear. –YCorp, IT

Manager of a business area

YCorp had a process to govern integration efforts.

The top management of YCorp had a major role in

governance. For example, ongoing integration

projects with biggest customers were terminated for

two years of time by a new CEO who joined the

organization, because the new CEO did not

emphasize e-business. The company aimed to align

its integration efforts with organizational strategies

and constantly considering the future state of its ERP

System Landscape. This was especially relevant due

to the drastic changes taking place in YCorp’s field of

business. For example, YCorp had established a

company-wide strategy for its ERP systems

utilization. When a new organization joined the

company, it was supposed to use a SAP template

defined for the organization. However, this did not

always happen. The new organizations continued

using their own configuration instead. This resulted

to additional, local SAP ERP configurations,

increasing the complexity of the ERP System

Landscape. Moreover, in the early phases of

development managers in facilities could impact on

the decisions about the business process coverage in

MES and the Custom ERP. Later, this caused data

quality issues when retrieving data from the MESs.

The company was also creating a roadmap for its ERP

systems by figuring out the future needs of these

systems. Establishing a unified strategy for the

system landscape turned out to be difficult due to the

different interest of business units using Custom ERP,

but having differing strategic interests. Eventually,

this led to a situation in which a single division

initiated a massive architectural reconstruction

process majorly affecting the future state of Custom

ERP without first getting acceptance from other

business units. In addition, a lack of integration

governance increased the complexity and caused

other issues, such as a need for renew the ERP System

Landscape. For example, YCorp was looking for an

option to fix the fragmentation and complexity caused

by multiple logistics systems by introducing yet

another system to integrate them.

4.4 Evaluation

“When investing tens of millions of euros [to the

system development] I think it is weird if there is no

funding for an extra validation round in the

Outlining a Process to Manage the Complexity of Enterprise Systems Integration

311

beginning. […] To implementing one part of the

system fast […] to ensure that, when talking about

new technologies, will they work at all? –Middleware

Provider, Manager

An evaluation process for investigating the

feasibility of integration initiatives was identified

from the data. The interviewee (Y4) stated that before

taking the business initiatives further, an architectural

evaluation is performed. However, this kind of

evaluation was not always performed. For example,

YCorp encountered difficulties due to insufficient

piloting and validation when choosing the integration

technologies to be used in Custom ERP. The non-

scalable architectural design led to a major

architectural redesign. According to the consultants,

the selected technologies were not analysed

comprehensively enough, and scalability issues were

‘outsourced’ to a technology provider. As further

stated by (E2), companies “should not believe the

sales speeches, but instead have sangfroid to test the

options”. Furthermore, YCorp faced difficulties in

identifying the integration needs and technical

requirements. It was pointed out by (Y1) that a critical

issue causing resourcing problems was to either

underestimating the integration needs or not to

establish a separate project for integration. Moreover,

some of the integration projects were ‘disguised’ as

other projects and carried out rapidly, until to a point

where it was realized that interconnections to other

systems were needed. Similarly, the need for testing

was often underestimated or sometimes even omitted.

This caused project management problems and

resourcing issues:

“The biggest challenge is to evaluate the size and

complexity of the project. I state that the

significance of integration is mainly

underestimated […] it is just stated that the

technology and tools are clear, this cannot be a

big issue. […] but then it is not noted that it

requires a lot of testing […] the resources that are

then used, they are not specifically allocated for

the project but are internal resources instead. But

then, what are their skills and motivation, and

how is it documented that something has been

tested?” –YCorp, Business-IT negotiator

The evaluation process had connections to

governance and housekeeping. On the one hand,

YCorp had a hard time defining an organizational

integration strategy. The custom ERP was used by

three differently operating business units, each of

which had their own development needs regarding

Custom ERP. Collaboration between the business

units, which would have been necessary for

determining the direction and the area of emphasis in

the development, was not sufficient. This led to

coordination issues, and eventually, wasted resources

due to duplicate development efforts. This way, the

benefits for the whole organizations were not always

emphasized in integration initiatives, but the benefits

of individual business units were preferred instead.

On the other hand, lack of detailed architectural

descriptions hindered and internal cooperation

hindered the identification of integration

requirements. The company had only a high-level

architectural description of systems and technologies

and a dedicated team responsible for maintaining this

description. This description was only used as

guidance to ensure that the technologies of the new

solutions should be compatible with the existing

technologies. There were no systematic means to

evaluate the integration needs in early phases of

development, leading to situations in which they were

discovered in later phases of development.

4.5 Summary of the Integration

Process

Based on the data analysis, we could distinguish four

sub-processes of integration: Integration Evaluation

(IE), Integration Realization (IR), Integration

Governance (IG), and Integration Housekeeping

(IH). In addition, the relationships between these

processes were revealed. Dedicated actors need to

take responsibility of Integration Governance,

Integration Realization and Integration Housekeeping

while Integration Evaluation requires collaboration

between all the actors of every other sub-process.

Integration Realization is the process during

which the business requirements are transformed into

new capabilities and features in ERP System

Landscape, as a result of system development and

integration. The vendor had a key role in realization.

Initially, a close relationship between YCorp and

Vendor drifted apart, slowing down the cycle of

realization of new features. Integration Governance is

needed to align the integration efforts in the company

with organizational strategies. This process should

establish the high-level integration and

standardization needs of the organization. YCorp

attempted to govern its integration efforts by creating

ERP templates and roadmaps for the system, but

struggled in reaching a consensus on the scope and

the future direction of Custom ERP. By not following

the organizational strategies for integration, as for

example happened in the merger explained in Section

4.3, the complexity of ERP System Landscape

increased. Integration Governance is critical activity

to avoid the increased fragmentation and complexity

of the ERP System Landscape. The purpose of

Integration Housekeeping is to facilitate integration

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

312

efforts. This is can be done with assets such as

standards, technical upgrades and architectural

descriptions of ERP System Landscape. YCorp did

not have a detailed architectural description, which

led to duplicate development initiatives and

undiscovered integration requirements. Both

Integration Governance and Integration

Housekeeping processes are periodically needed to be

executed because, for example, strategic and

standardization needs must be constantly monitored

and adjusted with the organization.

Finally, we identified that Integration Evaluation

(IE) is a critical process to evaluate the needs to find

out whether an integration realization project should

be initiated. Before establishing either large or small

scale integration projects, an evaluation of feasibility

of the initiative should be conducted. This includes

finding out the business and technical requirements

for integration, the needed resources and constraints.

For instance, interconnections to other systems and

the needs for testing need to be clarified. Assets

created by Integration Housekeeping and Integration

Governance processes are needed in Integration

Evaluation. For example, unlike it was in YCorp,

organizational ERP strategy should be applied by the

possible new organizations joining the company. By

having an architectural description of ERP System

Landscape (an asset created during Integration

Housekeeping) would enable the better control of

integration efforts. Evaluation should include piloting

of new technologies that are needed. This was not

done in YCorp when choosing the base technologies

for the Custom ERP. Integration Evaluation is a

critical process to be executed to avoid the pitfalls of

integration. If the integration initiative seems to be

unfeasible, the initiative should be abandoned. This

means that the Integration Evaluation may also lead

to a disqualification of an integration initiative.

5 DISCUSSION

Already 15 years ago, it has been suggested that that

attempts to manage the arrays of enterprise

information systems or infrastructures is not often

successful because of constant surprises and side

effects that cause the infrastructure to drift (Ciborra

2001). We state that understanding better the

integration process can partly reduce the drift and

undesired side effects. The integration process

described in this paper complements the Enterprise

Integration Method (EIM) proposed by (Lam and

Shankararaman 2004). The EIM process starts from

the assumption that a business case has been already

accepted by the top management. We state that the

evaluation of feasibility of integration initiatives is

also a critical part in the process. Even when there is

a business justification for the project, the array of

systems can evolve in an undesired direction as it

happened in YCorp. The main difference between our

process and EIM is the separation of governance and

housekeeping processes from the integration

realization process. EIM mostly focuses on the latter,

describing in more detail how integration is carried

out on the technical level. Unlike EIM, our process

takes a long-term view on integration and emphasizes

the continuous management of the systems landscape.

Our study has its limitations. The current process

stays at a very high level without describing detailed

roles, activities involved or steps to carry out the sub-

processes. This will be our task in the future, as we

intent to refine the integration process in other

contexts. As integration is a collaborative effort

conducted with different organizations and multiple

actors, different roles need to be included when

refining the process. Our current dataset is limited in

this sense, focusing only on the client organization on

the second interview round when dealing with

integration and enterprise architecture issues. The

future research could also take an action design

research approach in which the process is refined with

cooperation with the companies

In the future, we will refine the process further.

The detailed identification of actors, activities and

assets of the processes by utilizing other case

networks of organizations is our intention. In

addition, it is interesting to see how the decisions to

establish projects are made – are they triggered by

strategic, business or technical needs. Similarly,

investigating how coordination of the sub-processes

(governance, realization and housekeeping) in the

evaluation phase is worth of more thorough research.

Furthermore, it is necessary to investigate, how

different processes are executed after the

requirements are derived and how the processes

interrelate during development. Our model is generic,

but helps practitioners when tackling with integration

issues in organizations, especially in complex

environments. The integration process described in

this paper will help managers to re-engineer their

current processes.

6 CONCLUSIONS

Integration is a crucial activity as the enterprise

systems built in different times for different purposes

are taken beyond their originally intended usage

scenarios. Additionally, new service innovations

need to be constantly created by integrating the

resources provided by the existing landscape of

information systems in the company. This study took

Outlining a Process to Manage the Complexity of Enterprise Systems Integration

313

a Grounded Theory approach to construct a process

to manage the complexity of enterprise systems

integration. The process was constructed by analysing

the data collected from a large manufacturing

enterprise. The process links together the four aspects

(sub-processes) of integration. Dedicated actors need

to take responsibility of governance, realization and

housekeeping, while evaluation requires

collaboration between all the actors of each sub-

process. Integration Governance aims at maintaining

and updating the high-level strategy that exposes the

integration needs of the organization. Integration

Realization is a collaborative process, during which

the needs are realized to the landscape of information

systems as features. During Integration

Housekeeping, the ERP System Landscape is

standardized and maintained technically. In addition,

a detailed architectural description is formed to

facilitate the integration efforts. Integration

Evaluation needs inputs from both governance and

housekeeping processes to properly identify the

integration needs and requirements. The integration

process described in this paper can be used by

practitioners to align their operations and to avoid

pitfalls in enterprise systems integration.

ACKNOWLEDGEMENTS

This research is funded by Academy of Finland Grant

#304439.

REFERENCES

Alaranta, M., Kautz, K., 2012. A Framework for

Understanding Post-Merger Information Systems

Integration. Journal of Information Technology Theory

and Application, 13(1). Available at: http://aisel

.aisnet.org/jitta/vol13/iss1/2.

Alonso, G. ed., 2004. Web services: concepts,

architectures, and applications, Berlin ; New York:

Springer.

Charmaz, K., 2006. Constructing grounded theory,

London ; Thousand Oaks, Calif: Sage Publications.

Chowanetz, M., Legner, C., Thiesse, F., 2012. Integration:

An Omitted Variable in Information Systems Research.

In ECIS 2012 Proceedings. European Conference on

Information Systems (ECIS).

Ciborra, C., 2001. From control to drift: the dynamics of

corporate global IT infrastructures, Oxford: Oxford

Univ. Press.

Corbin, J., Strauss, A., 1990. Grounded Theory Research:

Procedures, Canons, and Evaluative Criteria.

Qualitative Sociology, 13(1), pp.3–21.

Gericke, A., Klesse M., Winter R., Wortmann, F., 2010.

Success Factors of Application Integration: An

Exploratory Analysis. Communications of the AIS,

27(37), pp.677–694.

Gulledge, T., 2006. What is integration? Industrial

Management & Data Systems, 106(1), pp.5–20.

Henfridsson, O., Bygstad, B., 2013. The Generative

Mechanisms of Digital Infrastructure Evolution. MIS

Quarterly, 37(3), pp.907–931.

Henningsson, S., Carlsson, S., 2006. Governing and

managing enterprise systems integration in corporate

M&A. In ECIS 2006 Proceedings. European

Conference on Information Systems (ECIS). Available

at: http://aisel.aisnet.org/ecis2006.

Kähkönen, T., Smolander, K., 2013. ERP Integration - A

Systematic Mapping Study. In 15th International

Conference on Enterprise Information Systems (ICEIS

2013). SciTePress - Science and and Technology

Publications, pp. 23–35. Available at: http://www

.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/

0004419900230035 [Accessed November 6, 2014].

Kaplan, B., Maxwell, J.A., 2005. Qualitative Research

Methods for Evaluating Computer Information

Systems. In Evaluating the Organizational Impact of

Healthcare Information Systems. Springer New York,

pp. 30–55.

Lee, J.-C., Myers, M., 2004. The Challenges of Enterprise

Integration: Cycles of Integration and Disintegration

Over Time. In ICIS 2004 Proceedings. International

Conference on Information Systems (ICIS). Available

at: http://aisel.aisnet.org/icis2004.

Lozano, Á., Gil, A.B., Li, T., 2014. Integration of Different

ERP Systems on Mobile Devices. In J. Bajo Perez et al.,

eds. Trends in Practical Applications of Heterogeneous

Multi-Agent Systems. The PAAMS Collection. Cham:

Springer International Publishing, pp. 27–35. Available

at: http://link.springer.com/10.1007/978-3-319-07476-

4_4 [Accessed June 8, 2015].

Mehta, M., Hirschheim, R., 2004. A framework for

assessing IT integration decision-making in mergers

and acquisitions. In Proceedings of the 37th Annual

Hawaii International Conference on System Sciences.

IEEE, pp. 264–274. Available at: http://ieeexplore

.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=12656

31 [Accessed December 1, 2014].

Myers, M.D., 1997. Qualitative Research in Information

Systems, Originally published in: MISQ Discovery,

June 1997. Available at: http://www.inclentrust.org

/inclen/uploadedbyfck/file/compile%20resourse/Qualit

ative%20Research/Presentations/Qualitative%20Resea

rch%20in%20Information%20Systems.pdf.

Myers, M.D., Avison, D.E. eds., 2002. Qualitative research

in information systems: a reader, London ; Thousand

Oaks, Calif: SAGE.

Jacobs, R.F., Weston, T.F.C., 2007. Enterprise resource

planning (ERP)—A brief history. Special Issue

Evolution of the Field of Operations Management SI/

Special Issue Organisation Theory and Supply Chain

Management, 25(2), pp.357–363.

Rodon, J., 2006. A methodological and conceptual review

of inter organizational information systems integration.

In ECIS 2006 Proceedings. European Conference on

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

314

Information Systems (ECIS). Available at:

http://aisel.aisnet.org/ecis2006/206.

Sarker, S., Xiao, X., Beaulieu, T., 2013. Qualitative Studies

in Information Systems: A Critical Review and Some

Guiding Principles1. MIS Quarterly, 37(4), pp.iii–xviii.

Strauss, A., Corbin, J., 2008. Basics of Qualitative

Research: Techniques and Procedures for Developing

Grounded Theory 3rd ed., SAGE Publications.

Tilson, D., Lyytinen, K., Sørensen, C., 2010. Digital

Infrastructures: The Missing IS Research Agenda.

Information Systems Research, 21(4), pp.748–759.

Urquhart, C., Lehmann, H., Myers, M.D., 2010. Putting the

“Theory” Back into Grounded Theory: Guidelines for

Grounded Theory Studies in Information Systems.

Information Systems Journal, 20(4), pp.357–381.

Vathanophas, V., 2007. Business process approach towards

an inter-organizational enterprise system. Business

Process Management Journal, 13(3), pp.433–450.

Walsham, G., 1993. Interpreting information systems in

organizations, Chichester, West Sussex, England ; New

York: Wiley.

Welker, G.A., van der Vaart, T., van Donk, P.D., 2008. The

influence of business conditions on supply chain

information-sharing mechanisms: A study among

supply chain links of SMEs. International Journal of

Production Economics, 113(2), pp.706–720.

Wijnhoven, F. et al., 2006. Post-merger IT integration

strategies: An IT alignment perspective. The Journal of

Strategic Information Systems, 15(1), pp.5–28.

Lam W., Shankararaman, V., 2004. Enterprise integration -

An enterprise integration methodology. IT

Professional, 6(2), pp.40–48.

Outlining a Process to Manage the Complexity of Enterprise Systems Integration

315