Evaluation of Intégration Approaches between ERP and BPM Systems¹

Evaluación de enfoques de integración entre los sistemas ERP y BPM²

Avaliação de enfoques de integração entre os sistemas ERP e BPM ³

Hugo Santiago Aguirre-Mayorga⁴
Julio Ernesto Carreño-Vargas⁵
Carlos Alberto Vega-Mejía⁶
Johanna Stella Castellanos-Arias⁷
Yorlemni Paola Hernández-Martínez⁸

¹This article is derived from the research project Design of a Business Process Automatization Learning Laboratory by Means of Implementing a BPM System on a Model Enterprise (register 3302j,developed by the research group lentech of Pontificia UniversidadJaveriana, Bogota, Colombia.
²Fecha de recepción: 18 de ¡ulio de 2011. Fecha de aceptación: 16 de marzo de 2012. Este artículo se deriva del proyecto de investigación Diseño de un laboratorio de aprendizaje en automatización de los procesos de negocio a través de la implementación de un sistema BPM (business process management) en una empresa modelo (registro 3302), financiado por Colcienciasy la Pontificia Universidad Javeriana. Desarrollado por el grupo de investigación Zentech, de la Pontificia Universidad Javeriana, Bogotá, Colombia.
³Data de recebimento: 18 de julho de 2011. Data de aceite: 16 de março de 2012. Este artigo deriva-se do projeto de pesquisa Desenho de um laboratòrio de aprendizagem em automatização dos processos de negócios mediante implementação de um sistema BPM (business process management) em urna empresa modelo (registro 3302), financiado por Colciencias e a Pontifícia Universidade Javeriana. Desenvolvido pelo grupo de pesquisa Zentech, da Pontifícia Universidade Javeriana, Bogotá, Colômbia.
⁴Ingeniero industrial, Pontificia Universidad Javeriana, Bogotá, Colombia. Magíster en Ingeniería Industrial, Universidad de los Andes, Bogotá, Colombia. Estudiante del Doctorado en Ingeniería, Pontificia Universidad Javeriana. Profesor asociado, Pontificia Universidad Javeriana. Bogotá, Colombia. Correo electrónico: saguirre@javeriana.edu.co.
⁵Ingeniero de sistemas, Universidad Francisco de Paula Santander, Cúcuta, Colombia. Magíster en Ingeniería de Sistemas y Computación, Universidad de los Andes, Bogotá, Colombia. Profesor investigador, Pontificia Universidad Javeriana. Bogotá, Colombia. Correo electrónico: carreno-j@javeriana.edu.co.
⁶Ingeniero de Sistemas, Universidad Nacional de Colombia, Bogotá, Colombia. Magíster en Ingeniería Industrial, Pontificia Universidad Javeriana, Bogotá, Colombia. Profesor de cátedra, Pontificia Universidad Javeriana. Bogotá, Colombia. Correo electrónico: vega.carlos@javeriana.edu.co.
⁷Ingeniera en mecatrónica, Universidad Militar Nueva Granada, Bogotá, Colombia. Estudiante de la Maestría en Ingeniería Electrónica, Pontificia Universidad Javeriana. Bogotá, Colombia. Correo electrónico: johanna.castellanos@javeriana.edu.co
⁸Ingeniera electrónica, Universidad Central, Bogotá, Colombia. Estudiante de la Maestría en Ingeniería Industrial, Pontificia Universidad Javeriana. Bogotá, Colombia. Correo electrónico: yorlemni.hernandez@javeriana.edu.co

Submitted on: July 18, 2011. Accepted on: March 16, 2012.

Resumen

El objetivo de este artículo es evaluar diferentes enfoques para la integración de un sistema ERP (enterprise resource planning) con un sistema de administración de procesos de negocio (BPMS, por sus siglas en inglés). Los enfoques de integración incluidos son arquitectura punto a punto y una arquitectura basada en adaptador, los cuales fueron evaluados en un proceso de ventas implementado en el sistema ERP SAP R/3® y en el BPMS BizAgi Enterprise^®. Los resultados mostraron que la integración basada en BPMN y el bróker reduce el tiempo e incrementa la flexibilidad.

Palabras clave: BPMS, ERP, integración, SOA, servicios web, SAP, BizAgi, BPMN

Abstract

The aim of this paper is to evaluate different approaches for the integration of an Enterprise Resource Planning System (ERP) with a Business Process Management System (BPMS). The integration approaches include a point to point and a broker-based architecture that was evaluated on a sales business process implemented in the ERP system SAP R/3® and the BPMS BizAgi Enterprise^®. The results show that the integration driven by a broker provides better performance, requires less effort and increases flexibility.

Key words: BPMS, ERP, integration, SOA, web services, SAP, BizAgi, BPMN

Resumo

O objetivo deste artigo é avaliar diferentes enfoques para a integração de um sistema ERP (enterprise resource planning) com um sistema de gestão de processos de negócios (BPMS, por sua sigla em inglês). Os enfoques de integração incluídos são arquitetura ponto- a-ponto e arquitetura baseada em adaptador, os quais foram avaliados num processo de vendas implementado no sistema ERP SAP R/3® e no BPMS BizAgi Enterprise®. Os resultados mostraram que a integração baseada em BPMN e o bróker reduz o tempo e acrescenta a flexibilidade.

Palavras-chave: BPMS, ERP, integração, SOA, serviços web, SAP BizAgi, BPMN

Introduction

In the nineties, companies began to implement ERP systems in order to integrate business processes such as manufacturing, sales and distribution, procurement, accounting, and human resources. The most significant achievement of enterprise resource planning systems has been to provide an integrated and consistent database spanning large parts of an organization (Weske, 2010). Before ERP systems, companies had legacy systems, together with a series of heterogeneous applications that were lately replaced by the former, solving in part the problem of their integration.

With the enterprise growth process brought along by globalization, a concomitant demand for additional functionality arose, and after the year 2000, Supply Chain Management Systems (SCM) appeared in the market with the main purpose of supporting advanced capabilities of demand and inventory management, production and transportation optimization, and management of suppliers and distributors (Chen et al., 2007). Likewise, the Customer Relationship Management (CRM) software reached its maturity and thus started supporting marketing, sales and service processes.

In most cases, the companies that implemented these systems have chosen software from different vendors, because of their specific requirements. In consequence, they are currently facing the need to integrate heterogeneous information systems. As an example, when a customer calls for a service order, the call center supported by a CRM application takes the order and is capable of giving information about the order's status. But if the customer asks for a credit status or any other information, the answer will be that the service agent cannot access the information (which is in the ERP system). As a result, the customer will not be satisfied with the service.

On the other hand, workflow management applications developed into the current Business Process Management Systems (BPMS), which have been implemented by companies during the last decade in order to design, automate and control critical business processes where people and information integrate through a technological platform that makes use of Business Process Modeling Notation (BPMN) as the basis for process modeling (van der Aalst and Weijters, 2004).

The main goal of BPMS is to decouple the business process from the underlying technological infrastructure by using Service Oriented Architectures (SOA), in which functions are packaged into modular reusable (web) services that can be used by any other system such as ERP CRM, SCM or BPMS (Hagemann Snabe et al., 2004).

BPMS are not designed to handle large databases like customer master data, nor transactional data such as production or accounting documents or sales orders. As a consequence, they need to be integrated with ERP systems that store this kind of data and transactions. Indeed, some companies are using web supported BPMS to integrate intercompany business processes without disrupting the transactional systems of each of the organizations involved.

The goal of this paper is to evaluate both a point to point and a broker-based architecture for the integration of a BPM and ERP system, using a BPMN based process model. The evaluation was carried out at the Technological Center for Industrial Automation of Pontificia Universidad Javeriana, where a model company has implemented SAP R/3® as its ERP system, and Bizagi Enterprise® as BPMS. In the first part of the paper, we present a review of literature and related case studies; in the second part, we introduce the business scenario in question and the integrated business process of the model company; in the third part, the integration approaches are evaluated according to quality attributes. Finally, concluding remarks and future work perspectives are accompanied by several key lessons derived from the current analysis.

1. Conceptual background

According to Lam and Shankararaman (2007), there are four basic integration architectures:

1. Batch integration. In this architecture there is no middleware or direct communication between IT applications, so there is no real time integration. Batch files are transferred from one application to another.
2. Point to point integration. Point to point communications and direct interfaces between individual IT applications. In this kind of integration there used to be a combination of real and non-real time processing.
3. Broker-based integration. The broker acts as an integration hub that houses messaging routing and data transformation logic. The middleware between IT applications and broker enables real time processing.
4. Business process integration. The business process model captures the workflow between IT applications and the workers who perform the activities. This architecture extends broker-based integration with business process knowledge.

Both broker-based and business process integrations are considered to be part of the Service Oriented Arquitecture (SOA), in which IT systems present business functionality as a series of services which can be accessed by other IT systems, be they internal or external to the organization (Ciganek et al., 2007). SOA is based on three mayor technical concepts (Josuttis, 2007):

• Service: it is a piece of self-contained business functionality, comprising either simple activities (like retrieving customer data), or complex ones (e.g., sales order management). When the service is available on an intranet or internet, it is known as a web service.
• Enterprise service bus (ESB): it is the broker that enables high interoperability between distributed systems for services. It makes it easier to distribute business processes over multiple systems using different platforms and technologies.
• Loose coupling: it is the concept of loosing systems dependencies. Because business processes are distributed over multiple applications, it is important to minimize the effects of modifications and failures.

On the other hand, business process integration architecture is based on BPMN, which is a graphical representation for specifying business processes. The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analyst that creates the initial drafts of the process, to the technical developers responsible for the technology that supports both the processes and the integration between applications (Weske, 2010). BPMN is gaining rapid acceptance in the business and IT world (Smith and Fingar, 2005).

2. Related work

In the literature, we found previous works evaluating integration approaches, but none of them included a BPMN model. Ciganek et al. (2007) evaluated integration approaches involving SAP R/3 and a legacy system for B2B transactions between a manufacturing company and a customer (Ciganek et al., 2007). They used a web serviced broker, a broker and file transfer protocol (FTP), and a web service integration without a broker (point to point integration). The authors conclude that broker based integration provides higher flexibility as it allows the company to decouple the customer-facing_process from the data structure required in SAP R/3.

Li et al. (2010) developed a business processes oriented heterogeneous systems integration platform based on SOA and web services. This platform provides an open source option for web service management and orchestration and for the integration of distributed systems. Nevertheless, process modeling in this case is not based on BPMN. Wasser and Lincoln (2009) developed an integration method that applies SOA for connecting business process models with corresponding enterprise software systems. The novelty of this contribution lies in the definition of a dynamic SOA connector that develops direct links between business activities and ERP transactions, and invokes handling instructions regarding inconsistencies that may appear between the connected layers.

Previous work was conducted on the evaluation of integration approaches and the development of integration platforms and methods, but none of them uses a BPMN model as the foundation of a BPMS-ERP integration. This type of structured connectivity is important for ensuring a valid matching between the IT system elements of an organization where BPMS and ERP systems play a central role. The next chapter addresses the description of the business case where this evaluation was carried out.

3. Case study: CIM Company

CIM is the name of a virtual company created at Pontificia Universidad Javeriana, located in the Industrial and Automation Technology Center. The company manufactures metallic parts at a computer integrated manufacturing lab. In 2005, they implemented a SAP R/3 system to support the sales, distribution, procurement, manufacturing, production planning, quality and accounting processes. The goal of the CIM Company is to provide the business scenarios and technology for students and practitioners to conduct IT and business training and research.

In 2010, the company decided to start automating some critical business processes by means of Bizagi Enterprise BPMS. This allowed realizing that the BPMS has to be integrated with the ERP solution and a legacy system in order to obtain an end to end business process solution. The description of the automated process is presented in figure 1.

The sales process starts with the customer's identification in the BPMS system. If the customer is new, it has to be created in the ERP system. Once the customer has been created, the order is filled out in the BPMS system, and the sales order is automatically created either in the ERP system (if the production takes places in the Colombian facilities) or in the legacy system (if the production takes place in the China facilities, which do not have any ERP system). Once the production and billing have been done, the export/import process is performed on the BPMS system, where all the activities and documents are handled. Finally, customer payment is processed on the ERP and legacy systems at both facilities.

The integration points presented in figure 1 are used to evaluate each of the integration approaches that are presented in the section below.

4. Evaluation of the integration approaches

The following section explain three different approaches to tackling the case study's integration. For each approach, the components used are described, and their roles and interactions are defined.

Approach 1: Point to Point Integration
As shown in figure 2, this first approach consists in establishing a direct communication between the BPMS and the ERP:

To better illustrate the interaction between the components, a case scenario between BizAgi and SAP is reviewed below, considering integration point B1 in the Sales Business Process detailed in figure 1. Within the process, the "customer identification" activity asks the user that is creating the sales order to fill out basic customer data in order to look it up in the ERP System. When the customer is validated in the SAP ERP, its information is returned to the BPMS and stored locally while the sales process is carried out. This is shown in figure 3.

The way in which the integration was achieved is summarized as follows:

• The process activity contacts the web service adapter asking for the consumption of the SAP BAPI "BAPI_CUSTOMER_GETDETAIL2", gathers up the necessary parameters from the BizAgi data structure, and sends them to the adapter.
• The adapter transforms the data it receives into an XML message. This transformation is done accordingly to the WSDL exposed by the SAP web service to consume the BAPI. Finally, the adapter consumes the SAP web service.
• The SAP web service transforms the XML data in such a way that it can call the BAPI correctly.
• The BAPI executes all the necessary actions in the ERP to access the customer's information. The output of the BAPI is transformed by the SAP web service into an XML format, which in turn is sent as a response to the BPMS.
• Finally, the adapter receives the new XML and transforms the data it contains for them to fit into the BPMS data structure.

The browsing of the web service provided by the ERP system, as well as the transformation of XML input and output data, relay exclusively on the responsibility of the BPMS. The BPMS offers a user-friendly procedure for the generation of proxy's and the transformation of data, which allows not technical staff, the chance to define the integration interfaces with minimum difficulties. However, there can be situations in which complex data structures need to be sent to the SAP web service, thus rendering the user-friendly procedure useless. Therefore, a data mapping customization is required. This needs the assistance of trained personnel, thus making this procedure rather immature. On the other hand, SAP creates the WSDL of the web service automatically, making it unnecessary for the operator to have an extensive knowledge of the required BAPI. However, sometimes this process is not strictly straight forward and a programmer with advance knowledge of the integration process must make adjustments to the automatically generated WSDL.

It is worthwhile noting that not all SAP BAPIs support remote calling or require a SAP technician with ABAP knowledge (the programming language of BAPIs), in order to make the necessary changes in the business logic for this functionality to be available via web service.

A major obstacle of this approach was found when trying to save data sent from the BPMS in SAP. In this case, changes must be introduced on both sides of the integration environment: in SAP, changes in the web service are necessary to preserve a "conversational state" between points; also, there must be guarantee that SAP has all the necessary components for this task. The "conversational state" has to be configured on the BPMS side as well, through the inclusion of "cookies", for example. This makes the integration process even less straight forward.

Nonetheless, function calls can be done in a synchronous or an asynchronous mode. Due to the nature of business processes, they have relatively long processing times. Therefore, an asynchronous implementation is usually recommended. The complexity of the asynchronous handling is hidden by the BPMS, and only a few parameters have to be parametrized.

Consequently, this approach is easy to build, and the integration efforts are somewhat low. This approach can be suggested for situations in which changes are not required on either side of the integration: data only need to be consulted in SAP from data structures that are not too complex.

Approach 2: Integration driven by business process with broker

In this approach, the communication between the BPMS and ERP systems is done through an intermediary or broker, as illustrated in figure 4.

The integrator component works as if it were a SOA layer, which decouples the business process from the applications that support it. This component could be deployed on an SOA infrastructure containing an ESB (Enterprise Service Bus), to which the routing and look up functions of the SAP web services could be delegated. In addition, the BPMS exposes the integration tasks as web services, so that SOA applications can use them, thus avoiding the creation of application silos. For the sales business process illustrated in figure 1, the interaction component in integration point B3 is shown in detail in figure 5.

The integration process is summarized as follows:

• The process activity "Sales Order - ERP" contacts the adapter web service, asking for consumption of the service, in order to create a sales order in SAP; then it gathers up the necessary parameters from the BizAgi data structure and sends them up.
• The adapter transforms the data into an XML format, according to the WSDL exposed by the WS Sales Order Broker, in order to call the SAP BAPI "BAPI_SALESORDER_CREATEFROMDAT2". Then the adapter consumes the web service in the broker by sending the previously created XML.
• The broker transforms the received XML to the data format it requires. At this point, the integration controller sends the data to the SAP web service, after modifying them when necessary.
• The SAP web service transforms XML data in such a way that it can call the BAPI correctly.
• The BAPI executes all the necessary actions in the ERP to create a Sales Order. The output of the BAPI is transformed by the SAP web service into an XML format, which in turn is sent as a response to the adapter web service.
• The broker transforms the XML received from the SAP web service into an XML format that can be interpreted by the BPMS.
• Finally, the data inside the latest XML are stored in the BPMS data structure.

Approach 3: Integration driven by business process with broker and adapter This approach is similar to the second one, but with two important differences: (i) the SAP web service is replaced with an adapter that has access to the BAPI's RFC, and (ii) this adapter is not hosted on the ERP side, but on the broker's. This is illustrated in figure 6.

As said earlier, the difference with the second approach lies in that an adapter between the integration controller and the BAPI is introduced. This modification simplifies the complexity of the BAPI's interface by giving an abstract representation of the functionality the BAPI offers, and therefore does not require an extensive knowledge of the language in which the BAPI has been implemented. Figure 7 shows the component interaction for this approach, which was tested for the same integration point as the second approach.

The integration procedure is the same as the second approach with a slight difference: the broker delegates all communication with SAP to the Adapter (SAPNET Connector in this case). This adapter handles all data exchange between the BPMS and the ERP

4.1 Quality attributes and evaluation

Now that all elements have been established for the three integration options presented before, this section evaluates each one of these approaches according to Quality Attributes (QA) considered relevant, depending on the integration tasks to which they refer.

There are three transversals QA:

• Decoupling: the SAP functionalities that are exposed do not require to know their role inside the business process and when will they be called.
• Business Process encapsulation: the BPMS contains the necessary logical steps to carry out the integration process; in other words, the integration is driven by the business process.
• Business agility: the encapsulation also allows the business process to be easily changed, due to the fact that it drives the integration process.

The following table shows the evaluation made for each of the analyzed approaches in light of the following QA: integration interfaces changeability, performance, implementation, scalability, installation and configuration, and integration mechanism.

The results show that the integration driven by a broker and an adapter provides better performance, requires less effort and increases flexibility. This evaluation could be used by any organization that requires deciding between integration approaches between an ERP and a BPMS system.

5. Results and further research

The development efforts required for enterprise integration are reduced when BPM systems are used as orchestrators of the integration process through BPMN and its combination with the paradigm of independent and standardized services offered by SOA. This is so because BPM systems have been conceived to achieve business agility, promoting the use of services that encapsulate configurable functionalities. The majority of the BPM systems support communication standards such as web services and XML, which makes them an effective tool for systems integration. However, BPM systems still have a long road ahead of them and could improve their visual development language, which they promote as the accelerator in integration processes.

In addition, BPM systems provide different approaches in which system integration can be achieved, some of which were analyzed in this paper, pointing out their strengths and weaknesses. Despite the fact that the selection of a specific approach depends on the specific needs of a company, we consider the best approaches to be the ones that are based on SOA. These types of approaches allow flexibility when responding to changes made to the business process, due to the demands of the enterprise surroundings.

For this particular study, it is our conclusion that the approach based on "Integration driven by business process with broker and adapter", has advantages over the other analyzed approaches. It decouples both the BPMS and the ERP system effectively and further changes in the integration have to be done only on the Broker, leaving both of these systems untouched. This contrasts with the other two approaches where modifications on the BPMS or ERP are required at some point during the integration process.

As it has been stated, the work presented here describes the integration of the BPMS BizAgi and the SAP ERP using an adapter based on SAPNET Connector. Further work could be focused on the development of a generic adapter that could connect different BPM and ERP systems or on increasing business agility by developing functionalities for BPM systems that allow them to connect to a diverse range of ERP systems.

References

CIGANEK, A.; HAINES, M.; HASEMAN, W etal. Using a standars-based integration platform for improving B2B transactions. In LAM, W and SHANKARARAMAN, V Enterprise arquitecture and integration. Methods, implementation and technologies. London: Information Science Reference, 2007. pp. 108-118        [ Links ]

HAGEMANN SNABE, J.; ROSENBERG, A.; M0LLER, C. et al. Business process management: The SAP Roadmap. Dedman, MA: Sap Press, 2008.         [ Links ]

JOSUTTIS, N. M. SOA in practice. Sebastopol: O'Reilly, 2007.         [ Links ]

LAM, W and SHANKARARAMAN, V Enterprise arquitecture and integration. Methods, implementation and technologies. London: Information Science Reference, 2007.         [ Links ]

LI, Q.; ZHOU, J.; PENG, Q. R. et al. Business processes oriented heterogeneous systems integration platform fornetworked enterprises. Computers in Industry. 2010, vol. 61, pp. 127-144.         [ Links ]

SMITH, H. and FINGAR, P Business process management-the third wave. Tampa: Meghan-Kiffer Press, 2005.         [ Links ]

Van der AALST, W M. P. and WEIJTERS, A. J. M. M. Process mining: a research agenda. Computers in Industry. 2004, vol. 53, no. 3, pp. 231-244.         [ Links ]

WASSER, A. and LINCOLN, M. Process gene-connect: SOA integration between business process models and enactment transactions of enterprise software systems. OTM 2009 Workshops, 2009, LNCS 5872, pp. 184-193.         [ Links ]

WESKE, M. Business process management. Concepts, languages, arquitectures. Berlin: Springer, 2010.         [ Links ]