The current issue and full text archive of this journal is available at www.emeraldinsight.com/1741-0398.

htm

JEIM 19,4

Is business process integration feasible?

434

Gail Corbitt
California State University, Chico, California, USA
Abstract
Purpose The purpose of this paper is to investigate whether business process integration is feasible. Design/methodology/approach This paper employs a single case study strategy to research the aforementioned research question. The case study is exploratory. Findings Based on the ndings and within the context of the case organisation, it appears that enterprise application integration (EAI) technology can integrate business processes. However, since it is not possible to generalize from a single case study, further research is suggested to investigate this area. From the case study, it appears that EAI can easily integrate the business processes when it is combined with enterprise resource planning (ERP) systems. Research limitations/implications This is a single case study and thus the results cannot be generalized. Practical implications The empirical date suggest that organisations may combine ERP with EAI to integrate their business processes in a more exible way. Originality/value The contribution of the paper is threefold: it describes the business process automation layer of EAI technology, it denes and presents a stage model for the business process integration and it examines the research question. Keywords Integration, Manufacturing resource planning Paper type Case study

1. Introduction The continuously changing nature in the business arena has led organisations to seek ways to improve their performance and increase their prots. Managers have been thinking about business process change, integration and improvement for several decades. According to Harrington (1991) enterprises have turned to business process improvement (BPI) for many reasons as it supports organisations to: . focus on their customers; . keep the businesss focus on processes; and . provide a method to prepare organisations to meet their future challenges. Davenport (1993) suggested that signicant improvements can be achieved when organisations integrate and automate their processes at both enterprise and cross-enterprise levels. In doing so, organisations could coordinate the development of common business processes and IT infrastructures which better support business goals and vision. Improvements on existing processes often require changes in the organisational structure and/or the IT architecture. However, the transition to a

Journal of Enterprise Information Management Vol. 19 No. 4, 2006 pp. 434-449 q Emerald Group Publishing Limited 1741-0398 DOI 10.1108/17410390610678340

process-centric organisation is not an easy task. Signicant problems appear with organisations needing to address issues like: (1) control; (2) ownership; (3) structure; (4) culture; and (5) responsibility (Hammer and Champy, 1993). The idea of an integrated system, however, is not new. In 1965, Anthony described three levels of information planning and control: (1) a strategic level; (2) a management control level; and (3) an operational level. The strategic level used information to guide the objectives and policy of the organization. The management control level allowed for efcient and effective allocation of resources to meet the organizations objectives, and the operational level essentially ran the day-to-day activities of the business (Anthony, 1965). A few years later, Head (1967) articulated that this integrated information system (IS) needed to use an organizational database that created, maintained, accessed and used different kinds of data elements oating around. This is no doubt the beginning of conceptual enterprise resource planning (ERP) systems. Organisations shifted to the adoption of ERP technology to implement an integrated IT infrastructure which automated a number of their business processes. ERP systems are based on a set of internally integrated modules that support generic business processes. In many cases, companies have replaced their existing software solutions with ERP systems and managed to integrate their business processes. However, the ERP approach has its limitations especially in those cases where ERP systems co-exist alongside other software solutions. In addition to this, ERP systems have their own philosophy for business process automation and integration. ERP limitations have been well investigated in literature with Themistocleous et al. (2001) reporting that ERP systems are a partial solution to the automation and integration of business processes and IS. In recent years, organisations have turned to enterprise application integration (EAI) technology to integrate their systems and processes in a more exible and maintainable way (Zahavi, 1999). EAI is based on a set of integration technologies like message brokers, ebXML and application servers that allow organisations to incorporate functionality from disparate systems (Ruh et al., 2000). EAI has been designed to support the integration of systems and processes at intra- and inter-organisational level. In this paper, the authors investigate approaches to business process automation and integration. This paper is exploratory in nature and uses a case study method to gather data related to the implementation of an EAI solution. The basic research question addressed is: is business process integration really feasible if an EAI solution

Business process integration

435

JEIM 19,4

is used. In answering this question, Section 2 summarizes the basic search for BPI via legacy technologies. Thereafter, Section 3: . explains how EAI offers another BPI alternative to traditional approaches (including ERP); and . presents EAI perspectives to the integration of ISs and processes. Sections 4 and 5 describe a basic case study approach and investigates the EAI approach through a real life case study with the remaining section discussing and summarising the main ndings of this research. 2. ERP systems and their route to business processes integration For as long as software has been developed the goal has been to create systems that support business requirements and processes. Numerous methods of systems analysis and design, programming languages and integrated application suites such as MRP, MRP II and most recently, ERP have been developed that include more and more functionality required by business. Improvements in the technical infrastructure allow for larger and more comprehensive systems but it seems that the systems are never a perfect t with organizations (Schulz, 2001). So while the concept of ERP has been around for at least 40 years the infrastructure technologies to deploy and support the concept of a truly integrated system did not make the solution feasible until the late 1980s/early 1990s. The underlying database and network technologies were not large enough or fast enough to accommodate the data requirements of the software supporting integrated business processes used throughout organizations. MRP and MRP II system solutions were certainly forerunners to ERP systems which added more and more functionality with each new release. In implementing ERP systems, companies were faced with two approaches for making the system support existing business processes: (1) to change the software to t the organization; or (2) to change the organization to t the process. While in early implementations some companies did change the software provided by the vendor to t the business, most companies decided to change the organization and keep the ERP system software delivered by the vendor unchanged. In fact, Forrester reports that only about 5 per cent of the Fortune 1,000 changed the software (Lee et al., 2003). Similarly, Davenport et al. (2002) reported that 75 per cent of the companies implementing ERP had moderate to signicant business process change and modication. Another strategy to ERP implementations was the best of breed approach, in which enterprises combined ERP modules from different vendors to meet their goals. In order to make the ERP system delivered t as many variations in business process as possible, each ERP vendor supplies multiple business process scenarios to choose from. Companies then congure the system to t their individual business. For example, SAPs R/3 has at least eight different ways that sales orders can be processed and a company can choose as many of these processes as it wants to t the business processes actually used in the company. In addition, each vendor has ways that the

436

company can congure and change the software to t unique situations within each process. For example, SAP offers customers user and formula exits as ways to include custom code within the system and JD Edwards allows for variable data elements that are customer dened. Yet companies still nd gaps in t between the ERP and the process requirements of the business. Only 3 per cent of the companies in the Accenture study did no customization to the ERP software system (Davenport et al., 2002), leaving 97 per cent that had minimal to highly customized solutions. Furthermore, the companies in this study were planning to expand the use of ERP within the organization, add new systems such as CRM, supply chain, etc. Experiment with web services and consolidate the multiple instances of ERP systems running in the company. All of these things require not only technical integration but business process integration. The latter may require enormous amount of change and according to Lee et al.(2003) the behavioural integration is the biggest challenge in this case. 3. Enterprise application integration and business process integration On the surface, EAI appears to be the answer to BPI by giving companies a third choice; instead of having to change the organization or the software to make the system(s) t the organizations processes, EAI promises to leave the organization and systems in tact by offering a bridge between the two. In other words, EAI responds to this need to support the exible integration of business process and systems. EAI is an emerging generation of integration software that effectively addresses the need to integrate both intra- and inter-organisational systems. It securely incorporates functionality from disparate applications by combining traditional middleware technologies (e.g. MOM) with new EAI software (e.g. adapters, message brokers,.net) (Linthicum, 1999, 2000; Serain, 1999). Thus, application integration results in supporting data, objects and processes incorporation. In doing so, EAI integrates different types of software like custom applications, packaged systems and e-business solutions. However, the key to success is still the degree to which the business process is supported seamlessly both from technical and behavioural perspectives (Lee et al., 2003). 3.1 Integrating business processes through EAI: strategic and opportunistic approaches Carrier (1999) differentiates two kinds of integration purposes namely data centric and process centric. Data centric integration is dened by Carrier (1999) as the automation and integration of data ows that are exchanged between ISs. It does not, however, focus on improving and reengineering business processes. Data centric integration results in shortening the time cycle of business processes, however, if the processes are poorly designed or include errors, the data centric integration simply increases the frequency of occurrence of these errors. One of the purposes of data centric integration is to create mappings between data exchanged among disparate systems, to facilitate data exchange and manipulation among systems. Based on this type of integration, organisations increase their functionality and performance as IT becomes capable of processing and combining data from various applications. This integration signicantly reduces manual integration in processes (e.g. manual data mapping and formatting). For instance, electronic data interchange (EDI) supports data centric integration and allows automatic data mapping, transmission and processing from

Business process integration

437

JEIM 19,4

438

source application format to target using an EDI standard (e.g. EDIFACT). More advanced EAI technologies that support data centric integration mechanisms include message brokers and adapters (Ring and Ward-Dutton, 1999; Themistocleous and Irani, 2001). When EAI technology is adopted, adapters are frequently used to map data between applications or provide the libraries for formatting data in the right format. Also, message brokers can be used to receive, format and distribute appropriate data sets to target applications based on business logic and rules. Process centric integration deals with the automation of business processes by integrating functionality from disparate applications. According to Linthicum (1999, 2000) and Morgenthal and La Forge (2000) process integration is the highest level of integration possible, as it requires the collaboration and incorporation of all involved systems at all levels (e.g. data, components, interfaces and messages integration, etc.). Although, process integration pieces together data and applications, it does not mean that data centric integration achieves process incorporation. In some cases data centric integration may result in process integration (e.g. the data integration of an electronic ordering application with a back-ofce system may result in order process integration) but this is not a xed rule. For example, the integration of a database with a decision-making system enriches the functionality of the system by providing more integrated data but, it may not result in integrating and automating the decision-making process. Themistocleous and Irani (2001) found that organisations followed one of two different approaches when introducing application integration solutions. These strategies are labelled strategic or the opportunistic application of EAI. In the strategic approach to EAI, companies implement an alternative business strategy that focuses on an integrated model (e.g. develop a global integrated infrastructure instead of having several independent infrastructures). In doing so, they make all the appropriate changes to their IT infrastructure and redesign all their business processes to support this strategy. This approach is also supported by Brown (2000), Kalakota and Robinson (1999) and Linthicum (2000). All these authors suggest that organisations redesign their business processes and IT infrastructure to develop an integrated IT infrastructure that will allow them to take advantage of EAI technology. The strategic EAI approach is dened as a process centric integration as enterprise wide and/or cross enterprise integration which requires the redesign, automation and incorporation of business processes. Yet, some companies adopt application integration solutions to solve their organisational problems and do not design an enterprise or cross-enterprise wide integrated infrastructure. They adopt EAI to overcome point problems. This is the opportunistic approach. Edwards and Newing (2000) reported that British Airways faced problems in understanding and analysing market place and customer needs. The business information infrastructure consisted of heterogeneous systems that stored huge quantities of data. Nonetheless, data were not consistent and the systems could not combine or produce the information needed for decision making. As a result, British Airways took the decision not to integrate the whole organisation but to integrate all data sources needed for supporting decision making. In this case, the organisation did limited business process reengineering to piece together all these data sources. Hence, it can be said that British Airways followed an opportunistic EAI approach that was based on data centric integration. As a result, the authors observe

that opportunistic EAI adoption may follow either process centric or data centric integration, depending on the point problem being solved. 3.2 Bridging the technical and behavioural aspects of EAI process integration The purpose of this paper is not to describe and explain EAI technology. Numerous papers have been published in the normative literature that discuss: . the nature of EAI (Linthicum, 1999; Ruh et al., 2000); . its benets and barriers (Themistocleous and Irani, 2001); and . case studies on EAI (Edwards and Newing, 2000; Puschmann and Alt, 2001). The aim of this paper is to move a step forward and to investigate for rst time the following research question: RQ1. Is business process integration feasible through EAI technology? From a technical perspective, Themistocleous (2002) proposes that EAI is achieved at four integration layers. This approach extends previous publications by Themistocleous et al. (2000, 2002) who originally proposed three integration layers. Although, Themistocleous et al. (2000, 2002) highlighted the existence of points of access between the incorporated applications they did not consider these another integration layer. However, Themistocleous (2002) pointed out the importance of adding a new layer entitled connectivity. The importance of such a layer has been validated through a series of case studies. Evidence from these cases have shown that enterprises evaluate EAI packages using many criteria including integration layers (Themistocleous and Irani, 2003). It is, therefore, important for organisations to select an EAI package that supports the connectivity of their applications with the integration infrastructure. The four integration layers are the following: (1) Connectivity layer that creates common points of access among the interconnected applications and the integration infrastructure. (2) Transportation layer which transfers the information from source application to the integration infrastructure and from the latter to the target application. (3) Transformation layer that translates the information from source application format to target system structure. (4) Process automation layer which integrates the business processes, manages and controls the integration mechanism. This is shown in Figure 1. Figure 1 shows the incorporation of two ISs (source and target application) when EAI is used. Source and target applications are integrated by exchanging their application elements, which include data, objects and processes. Application elements are transferred from source application to the target through the integration infrastructure using the transportation layer. Meanwhile, application elements are translated from source application structure to target application format using the translation layer. The reason for using this layer is that source and target applications are not based on the same structures (e.g. data structure) or platform. Thus, translation is required to transform data into compatible format for target application. At a higher level, elements that are used for the integration of processes or the integrity of information (e.g. services, business logic, rules, constrains) are transferred to process automation

Business process integration

439

JEIM 19,4

440

Figure 1. The integration mechanism

layer. The latter uses these elements to audit integration tasks, incorporating and automating business processes and triggering events. The process automation layer is the brain of an EAI infrastructure. The business process scenarios are stored in this layer and through these scenarios the EAI infrastructure manages, integrates and automates the business processes. This layer results in one or more main actions: . Retrieve data that are stored locally (integration infrastructure) or externally (applications). Such an action is needed to provide other applications with appropriate information to full a process. Data that is stored locally is translated before sent to applications. External data is requested by the integration mechanism. In this case a request is generated and sent to relevant applications. . Request applications elements or other kind of information from external applications. . Trigger events or other tasks by sending all relevant information associated with this task (or event). A typical scenario at process automation layer could be the following: after receiving an order from source applications (sales) and translating the information to appropriate formats conduct the next steps: (1) retrieve customers details; (2) request stocks availability; and (3) trigger the tasks: . update stocks (using order details);

. . . .

update customer record (using customer id, order details); invoicing customer (using customer id, order details); update delivery services (using customer id, order details); and place an order to supplier (in case of out of stock).

Business process integration

4. Methodology ISs research has been plagued with difculty in terms of studying things objectively. As technologies become more complex and more interwoven into corporate environments research methods like surveys, eld experiments, and more statistically oriented studies become harder and harder to do. By necessity it is difcult to separate the issues being studied, like feasibility of EAI, from its context. Therefore, because EAI technology is relatively new, embedded within its context and highly complex, a case study approach to examine the feasibility of using EAI to achieve true process integration is reasonable. While using multiple case studies is also desirable not enough is known about all the factors that can inuence EAI feasibility to structure a study involving multiple companies at this time. This study is thus exploratory and involves a single case at this time. In this case, the authors chose a company that had ERP experience so that an EAI approach can be examined within the context of traditional approaches to BPI. The observations within the context of this company are to examine the technical solution and see if the process layers are adequate to make BPI possible. Is the promise of EAI fullled in this case? 5. An exemplar case The company under consideration is a multinational company that operates in more than 135 countries and with more than 100,000 employees worldwide. During the last decade, the tremendous changes in the global business arena led the company to adopt e-business practices and applications (e.g. e-supply chain management) to gain competitive advantages. However, the adoption of e-business applications was not enough to allow the company to achieve its targets. The reason for this is that the rapidly changing business environment, requires organisations to support exible and manageable IT infrastructures to gain competitive advantages. In this context, the company recognised that integration was a signicant parameter which inuenced the success of its e-business applications and supported the organisation in achieving a competitive advantage. Traditional approaches to inter-organisational integration such as EDI have proved insufcient and complex for the company. Other approaches to integration such as ERP systems have failed to support the companys intra- and inter-organisational integration, since they co-exist alongside other applications. The fragmentation in ERP implementations across the company is a constraint for successful e-business transformation. The reason for this is that, there are up to 90 ERP implementations at the organisation. Many of them run over mainframes or they do not support real-time capabilities. In addition, there are many compatibility problems among ERP systems (e.g. they do not support the same data formats or they were customised in a different way). Thus, the co-ordination of all these systems under an e-business umbrella that requires real-time data is an obstacle. When the company adopted ERP solutions it was forced to alter many of its business processes to adapt them to the ERP package philosophy. An interpretation of this is that the company came across many difculties regarding the customisation of

441

JEIM 19,4

442

ERP packages. Thus, it had an impact on the business strategy and plans as it ts its strategy into the package and not the other way round. The organisation believes that the way forward is to develop an integrated IT infrastructure by redesigning their business processes and IT infrastructure. In doing so, the company will phase out all redundant systems and data and dramatically reduce the complexity of the existing processes and IS. The non-integrated IT infrastructure has caused the company many problems: . high cost of maintenance; . unmanageable architecture requiring too many specialists; . inexible; . results in insufcient decision making; and . led to low customer satisfaction. In addition to this, there was a need to change the traditional asset-driven supply chain to that of a customer-driven value chain. As Figure 2 shows, this introduced a lot of changes at both the business processes and the applications. For instance, customers needs guide the whole chain whether in a traditional supply chain suppliers and in-house core competencies are the one that guide the chain. As shown in Figure 2 a customer driven value chain requires among others, integrated channels, exible processes and infrastructures and integrated suppliers. Nonetheless, the existing organisational structure and the IT infrastructure did not support such a transformation. There is, therefore, a need for rapid transformation from closed internal processes to open externalised processes. However, this target can be achieved through the development of an integrated, adaptive and consistent IT infrastructure across the company. Internal consultants proposed the development of a global integrated IT infrastructure to integrate and automate most business processes in the company. The proposed approach for integrating the organisation was based on a strategic approach. Previous integration attempts were not successful and there was a preconception regarding integrated solutions. The organisation had invested up to e812.6 million in less than 10 years to adopt ERP systems, which claimed to integrate and automate business processes.

Figure 2. Asset- vs customer-driven value chain

Even with this signicant investment, annually the IT department proposed a new scenario/approach for automating businesses processes and thus, sought and secured additional funding. Although, the managing board supported the proposals for ERP adoption, none of them provided a total solution to their problems. As reported by all interviewees, this (lack of inter-business integration) is attributed to the difculties in interfacing ERP systems with other applications (new or old). The company implemented a couple of pilot integration projects before commencing the EAI project that integrates the organization at a global level. Based on the outcomes of these pilot projects, the company made the decision to integrate the organization through EAI technology. 5.1 The EAI project In 2000, the company run a couple of pilot projects to test the efciency of EAI technology. The rst pilot focused on an application integration scenario in which applications were integrated one by one (with the EAI mechanism). The second pilot was based on a process-oriented approach in which the rst part of one process (running on one application) was integrated before moving to the next one (running on another software solution). This approach was proved more efcient as fewer errors were occurred. Thus, the organisation took the decision to integrate its systems using a process-oriented approach. The global EAI project started in May 2001 and is estimated to nish in 2009. The project is divided into two big phases: (1) the development of mega-data-centres; and (2) the integration of IT infrastructure. During the rst phase three mega-data-centres will be developed in Europe, America and Pacic-Asia. Each mega-data-centre has been based on a single SAP R/3 installation. All ERP systems from all subsidiaries will be phased out, with a transfer of their functionality to the regional ERP solution. Thus, only three SAP systems will be customised automated and integrated, based on the functionality and the processes of the existing 90 systems that are currently in use. In doing so, the company will automatically phase out all 90 ERP systems after the development of these data-centres. This will dramatically reduced the number and redundancy of ERP applications used in the organisation. However, in achieving this solution, the company needs to redesign and reengineer all its business processes. This is not an easy task, as there exist more than 1,500 legacy systems, 90 ERP solutions and e-business modules that support the existing business processes. The company signed a ve-year e115 millions single-source deal with IBM to provide hardware infrastructure. The rst applications were migrated to the European mega-data-centre in October 2001, with the transfer of the other installations being completed by the end of 2005. The overall cost for the development of the data-centres is estimated to be up to e575 million (e115 million for hardware, e200 million for software and e260 million for development). The second phase of the project will begin after the development of the mega-data-centres. It is estimated that once the European data-centre has been implemented, the integration phase will commence. As shown in Figure 3, the global EAI solution is geographically divided in three big integrated subsystems. Each of

Business process integration

443

JEIM 19,4

444

Figure 3. The global EAI solution

these regional subsystems integrates the applications and processes from all subsidiaries that are based in its region. For instance, all European subsidiaries of the company should integrate their applications using the European hub and spoke infrastructure (Klasell and Dudgeon, 1998; Ring and Ward-Dutton, 1999). In addition to the three regional hub and spoke integration infrastructures, a global one will be developed to unify the regional integrated infrastructures. Each regional subsystem will integrate custom applications (legacy, databases, data warehouses, etc.) and e-business solutions with SAP modules. Regional subsystems will have a number of hubs to integrate all applications. It is estimated that 90 per cent of custom systems will also be phased out with only 150 legacy systems remaining operable around the globe. The global EAI solution will need much business process reengineering. Based on the experience from pilot projects, the company estimates that 60 per cent of overall time will be needed for the design of the business processes and the system. This percentage is similar to that reported by Themistocleous (2002) who report that organisations spent the 70 per cent of overall time on systems design and business process reengineering when implementing the strategic approach to EAI. It is also estimated that 300 employees will work on the global EAI project. This salary component absorbs a big portion of the total budget, which is estimated up to e64.6 million (only for integration). However, the company estimates e46 million savings from data consolidation (e.g. less maintenance effort, data quality, less management and technical effort). 6. Discussion The case study in this paper reports the application of a strategic approach in a multinational organisation. Using this approach the company has redesigned most of its business processes to develop a global integrated IT infrastructure. In doing so, the organisation has spent 60 per cent of the overall time in redesigning. This evidence supports other ndings derived from the literature suggesting that organisations spend more than 60 per cent of their time designing their systems and business

processes when they adopt a strategic approach of EAI technology. Evidences from this case study show that a strategic adoption of EAI technology is not an easy task and it takes time be achieved. The company is taking on much bigger challenge to integrate processes across multiple systems and environments. Unlike, the ERP approach, which requires organisations to adapt their processes to the package philosophy, EAI efciently, supports the development of an integrated IT infrastructure that reects the business strategy and automates the business processes. It remains to be seen whether or not the company will achieve the benets proposed and what happens when the business process change to respond to changes in the environments within which the company operates. The project has been run for more than 5 years now, and it is almost half-way to its completion. During this period, the combination of the mega-data-centres with the EAI infrastructure has been helpful. Owing to the high volume of data, the development of the three mega-data-centres was proved extremely useful. Each of these data-centres is based on an SAP R/3 implementation. The organisation was happy with the efciency and performance of many processes running on the ERP system. For that reason there was no justication to re-engineer these processes. Thus, in practice the ERP system has been emerged as one of the most important components of the integrated architecture. This does not mean that the ERP solutions have replaced EAI but it supported the integration of business processes. Since, all the data are stored in the ERP system (data-centre), the EAI infrastructure makes better use of its resource to integrate the processes. Also, some processes are internally integrated in ERP system which further supports the performance of the integration mechanism. The empirical data revealed that EAI achieves business process integration and, therefore, the answer to the RQ1 is that within the context of this organisation, business process integration was achieved through EAI technology. Since, the results to this question are based on a single case study, they cannot be generalised. For that reason more in depth research is required in this area to further investigate this phenomenon. In the case study presented, EAI could achieve this integration without any support from other applications. Nonetheless, it is worth noting that the combination of ERP and EAI has resulted in a much more efcient and effective infrastructure. To this end, it appears that there is a new way[1] to integrate business processes based on the combination of EAI with ERP. Despite, the authors cannot generalise this nding, the practice supports this evidence. For instance, recently SAP has promoted a new software solution called NetWeaver which combines EAI technology with SAP R/3 package to support better business process automation. Table I summarises the approaches to business process integration and automation as these derived from this section and Sections 2 and 3.1 as well. In addition to this, the Figure 4 shows a stage model that explains the route to the business process integration. 7. Conclusion and implications for future research Since, 1965 the architects of corporate ISs envision a day when end-users can sit in front of a computer and have access to any and all information and data required by every process that they have a role. This end-user does not need to know where the data are that he/she needs, nor do they need to log onto multiple systems in order to

Business process integration

445

JEIM 19,4

Stage I II

Technology ERP ERP ERP EAI EAI ERP & EAI

Approach Customisation Fit the package Best of breed Opportunistic EAI Strategic EAI New wave

Description Customise the ERP package to t the organisation Change the business processes to t the ERP package Adopt suitable ERP modules from multiple vendors Integrate part of the organisation to address the current needs Integrate the organisation by focusing on the business processes EAI and ERP are combined to integrate business processes

446
Table I. Approaches to business process integration

III IV V VI

Figure 4. The route to business process integration

accomplish different processes. Simple button pushing accomplishes the tasks within the processes seamlessly. While ERP was a big step towards this vision, especially in the areas of data integration, processes integration remains a challenge. Even in companies that have successfully implemented ERP, standardized seamless process integration remains illusive. Similarly, the challenge with EAI is business process integration. Even if EAI did nothing more than integrate existing instances of ERP production systems within the same company it still plays a signicant role in advancing ISs into a more integrated approach. Yet, the task of standardizing processes across multiple divisions within even the same organization is not easy. People do not change easily and planning and managing a change to integrate processes takes much more than technology and new IT models. As a result many companies opt for opportunistic integration that solves isolated problems. The authors support that EAI technology allows organisations to redesign their business processes and recongure their IT infrastructure in a way that efciently reects the changes on the business processes. This is achieved through the development of an integrated EAI infrastructure that incorporates functionality from disparate systems that automate the business processes. In doing so, organisations can

follow a strategic or an opportunistic approach. The latter supports the integration of software solutions that automate a specic business process or a sub-process by redesigning limited parts of it. When a strategic approach is adopted, organisations reengineer the whole of their business processes or a signicant number of them to gain advantage of the technology and improve their performance. Most projects of this type take longer and have more costs than planned. ERP projects were noted for this during the 1990s and the authors guess is that EAI projects will be noted for this in the current decade. At the same time, EAI architecture can handle many of the shortcomings of ERP where every part of the organization needed to do everything the same way. In this way, EAI extends ERP into the new decade by offering a way to integrate other systems into the ERP backbone. First, however, the ERP backbone must be integrated itself. Thankfully EAI can help with this as well, and like many other companies, the case study organization is looking at ways to do that right now. The contribution of this paper is threefold as: (1) it denes and explains how EAI can achieve process integration through the business process automation layer; (2) it introduces a stage model on the business process integration; and (3) it suggests that within the context of the case study presented herein, business process integration is feasible though EAI technology. The question we need to answer in the future is whether EAI bridge the requirements gap? It seems clear that the key is to identifying what the gap requires in terms of business process. This is time consuming and expensive with results remaining illusive. The key is still to design integrated processes that can meet current requirements and still remain exible enough to respond to future changes in process requirements. So the research question, is EAI a feasible response to BPI, needs more study. Obviously, more case studies need to be done and examining multiple case studies across different organizational contexts is required to identify the factors that lead to the ideal EAI solution. Another area of interest is to identify the necessary and sufcient factors that are needed to implement an EAI solution, how these differ from ERP implementations, and more importantly, how what we learn can lead us into the next stage of business process integration. In other words, what is beyond EAI?
Note 1. The authors refer to this approach using the term new wave. References Anthony, R. (1965), Planning and Control Systems: A Framework for Analysis, Division of Research, Graduate School of Business Administration, Harvard University, Boston, MA. Brown, L. (2000), Integration Models: Templates for Business Transformation, Sams Publishing, Carmel, IN. Carrier, L. (1999), Managing at light speed, IEEE Computer, July, pp. 107-9. Davenport, T. (1993), Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston, MA.

Business process integration

447

JEIM 19,4

448

Davenport, T.H., Harris, J. and Cantrell, S. (2002), The Return of Enterprise Solutions: The Directors Cut, Accenture, Cambridge, MA. Edwards, P. and Newing, R. (2000), Application Integration for e-Business, Business Intelligence, London. Hammer, M. and Champy, J. (1993), Reengineering the Corporation: A Manifesto for Business Revolution, Harper Collins, New York, NY. Harrington, H. (1991), Business Process Improvement, McGraw-Hill, New York, NY. Head, R. (1967), Management information systems: a critical appraisal, Datamation, Vol. 13 No. 5, pp. 22-7. Kalakota, R. and Robinson, M. (1999), e-Business: Roadmap for Success, Addison-Wesley, Boston, MA. Klasell, T. and Dudgeon, S. (1998), Enterprise Application Integration, Dain Rauscher Wessels, New York, NY. Lee, J., Siau, K. and Hong, S. (2003), Enterprise integration with ERP and EAI, Communications of the ACM, Vol. 46 No. 2, pp. 54-60. Linthicum, D. (1999), Enterprise Application Integration, Addison-Wesley, Reading, MA. Linthicum, D. (2000), B2B Application Integration, Addison-Wesley, Reading, MA. Morgenthal, J. and La Forge, B. (2000), Enterprise Application Integration with XML and Java, Prentice-Hall, Englewood Cliffs, NJ. Puschmann, T. and Alt, R. (2001), Enterprise application integration the case of the Robert Bosch group, Proceedings of the 34th Hawaii International Conference on System Sciences, Maui, Hawaii, USA, (CD Proceedings), 3-6 January. Ring, K. and Ward-Dutton, N. (1999), Enterprise Application Integration: Making the Right Connections, Ovum Ltd, London. Ruh, W., Maginnis, F. and Brown, W. (2000), Enterprise Application Integration: A Wiley Tech Brief, Wiley, New York, NY. Schulz, Y. (2001), Custom software closes the gap: both approaches are closer in cost, risk and schedule than you might think, Computing Canada, Vol. 27 No. 16, p. 21. Serain, D. (1999), Middleware, Springer, Berlin. Themistocleous, M. (2002), Evaluating the adoption of enterprise application integration in multinational organisations, PhD thesis, Department of Information Systems and Computing, Brunel University, London. Themistocleous, M. and Irani, Z. (2001), Benchmarking the benets and barriers of application integration, Benchmarking: An International Journal, Vol. 8 No. 4, pp. 317-31. Themistocleous, M. and Irani, Z. (2003), Towards a novel framework for the assessment of enterprise application integration packages, in Sprague, R.J. (Ed.), Proceedings of Thirty-Six Annual Hawaii International Conference on System Sciences, (Hicss 36), Big Island, Hawaii, USA, IEEE Computer Society, Los Alamitos, California, USA, (CD Proceedings), 5-8 January. Themistocleous, M., Irani, Z. and Love, P. (2002), Enterprise application integration: an emerging technology for integrating ERP and supply chains, in Wrycza, S. (Ed.), Proceedings of Tenth European Conference on Information Systems (ECIS 2002), Gdansk, Poland, 6-8 June, pp. 1087-96. Themistocleous, M., Irani, Z. and OKeefe, R. (2001), ERP and application integration: exploratory survey, Business Process Management Journal, Vol. 7 No. 3, pp. 195-204.

Themistocleous, M., Irani, Z. and Sharif, A. (2000), Evaluating application integration, in Brown, A. and Remenyi, D. (Eds), Proceedings of Seventh European Conference on Evaluation of Information Technology (ECITE 2000), Dublin, Ireland, MCIL Reading UK, 28-29 September, pp. 193-202. Zahavi, R. (1999), Enterprise Application Integration with CORBA, Wiley, New York, NY. Further reading Charlesworth, I., Hamilton, L., Holden, J., Holt, M., Jagger, E., Jennings, T. and Jones, T. (2002), EAI and Web Services: Cutting the Cost of Enterprise Integration, Butler Group Limited, Hull. Duke, S., Makey, P. and Kiras, N. (1999), Application Integration Management Guide: Strategies and Technologies, Butler Group Limited, Hull. Corresponding author Marinos Themistocleous can be contacted at: [email protected]

Business process integration

449

To purchase reprints of this article please e-mail: [email protected] Or visit our web site for further details: www.emeraldinsight.com/reprints