Survey on Information Monitoring and Control in Cross- enterprise Collaborative Business Processes

Abstract

The difference between Collaborative Business Processes (CBP) and ordinary sequential business processes (BP) is in the necessity for decentralized coordination, flexible backward recovery, participants notification about the current state, fast adaptability to changes in participants' work, multiple information systems, individual authorization settings of the participants, etc. The paper presents a literature survey of four CBP paradigms (namely oriented on activity flows, documents, cases, and business artifacts) conducted from the perspective of a vendor of the Enterprise Resource Planning (ERP) system. Restrictions of the case are implicit information flows in BPs, diversity of ERP integrations with customers' information systems (IS), a lack of mechanisms for BP monitoring, backward recovery and for user notification about the current state and tasks as well as inability to make changes in customers' ISs. The paradigms are reviewed and analyzed regarding these restrictions.

Keywords

• cross-enterprise
• collaborative business process
• process monitoring

-

In order to create innovative business products, share knowledge between people and business, or increase the control and quality of service, enterprises need to collaborate with each other, thus delegating or providing some pieces of work to other enterprises [ 1 ]. First introduced in [ 2 ], such processes are called Collaborative Business Processes (CBP). The specifics of CBPs is that they are not coordinated by one central workflow (WF) engine, but rather by multiple engines collaboratively. Research on CBPs have two aspects. The first, personal, collaboration includes support of personal negotiations, personal knowledge sharing as well as coordination and planning of activities (e.g., in the so-called industrial clusters [ 3 ]) by using networks, voice, video and audio IT solutions (e.g., [ 3, 4, 5, 6 ]). The second, let us call it “computer system driven”, collaboration includes support by a business-tobusiness (B2B) Workflow Management System (WMS) that “defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines (WE), which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications” [ 7 ], like FITMAN [ 8 ]. CBPs are more dynamic than sequential processes without collaboration and involve more complex communications between enterprises, especially in relation to non-functional aspects [ 1 ].

CBPs among enterprises are called also cross-enterprise [ 9 ], cross-organizational [ 10 ], multipartner [ 11 ], and intra-enterprise [ 2, 12 ] processes. The main distinction from inter-enterprise CPSs is that they involve several autonomous enterprises in the business process (BP) execution. This requires decentralized coordination (choreography) among enterprises’ BPs, since centralized coordination (orchestration) usually cannot help here (because of loosely coupled collaborations). Choreography is not trivial, since business independency and sometimes unwillingness/inability to introduce changes into the already implemented IT solutions is at the fore also for our business case [ 2 ].

Among other IT implementations, Enterprise Resource Planning (ERP) systems also support cross-enterprise CBPs [ 13 ]. It might have specific restrictions (discussed further) that make it hard to control and monitor such processes, e.g., private/public and explicit/implicit information flows, diversity of ERP integrations with customers’ information systems (IS), a lack of mechanisms for collaborative process monitoring and backward recovery, and inability to make changes in customers’ ISs. The goal of our research is to find out an answer to the question: “What existing solutions and techniques could be promising to solve issues caused by restrictions of the ERP business case discussed in this paper?” In order to achieve this goal, we have carried out a survey of techniques and mechanisms which are used for cross-enterprise CBPs. The results of the survey will indicate techniques and mechanisms for deeper research on BP monitoring and runtime user guidance during experimental modeling activities.

The paper is organized as follows. Section 2 provides a brief discussion of the cross-enterprise CBPs and their management. Section 3 illustrates the context of the ERP business case as well as its restrictions. Section 4 presents a view on existing solutions within the CBP management regarding the ERP business case. We conclude with the summarization of main results. 2

Cross-enterprise Collaborative Business Processes

Usually B2B collaboration systems are static. This means it is not possible to create/adjust BPs dynamically according to the constantly changing needs and constraints of the businesses. Instead processes are described in some hardcoded notations, e.g., BPMN (Business Process Model and Notation). Some research try to tackle this issue by applying semantic business process management (BPM) approaches, e.g., hierarchical task networks and Web ontologies [ 9, 14 ]. However, they are dealing rather with the task of generation of BPEL (Business Process Execution Language) specifications, but not with the task of running and monitoring execution processes thereafter.

BP monitoring has been widely applied in ISs (e.g., [ 15 ]). It usually involves some form of event-based processing, when it is possible to attach some action(s) before/after an activity. Such events are mostly used for monitoring the compliance within the enterprise, but they also can be used to send notifications to some external endpoints, e.g., for informing other systems/enterprises. Such systems usually utilize some form of a rule/condition engine, so that the events are fired only when the condition is met. However, in order to make a decision for a particular implementation, it is important to evaluate its appropriateness in the context of the used WF engine, e.g., whether addition of event processing involves changes in the BP definitions or can be applied transparently to it.

As mentioned in the introduction, in the cross-enterprise processes non-functional requirements, like privacy and confidentiality, might play even a more crucial role than functional ones. For managing interests and protecting privacy of the involved enterprises, CBP management system should provide different perspectives/views for a particular party. However such adoption of views inevitable increases complexity both in overall process representation and maintenance of ever changing BPs.

We are mostly concerned to add event processing and data state identifying capabilities to the legacy/non-process oriented systems. Namely we need to know how to ensure monitoring and runtime user guidance without influencing legacy applications and still be able to apply some form of BP modeling and integration with third party workflows. Currently there exist at least four paradigms to BPM [ 16 ]:  Activity-flow oriented, when the activities and their predefined sequences are used at firsthand, but the data that must be processed is perceived as second-class citizen [ 1, 2, 17 ];  Document oriented, when it is important to finish some document using a strict authorization mechanism, document partitioning and templates [18, 19, 20];  Case handling, when it is important to resolve a case without necessarily specifying the order of activities, obtaining some minimum amount of data or making predefined number of decisions [21, 22];  Business artifact-centered (a special case of data-centric paradigm), which combines and models both data (information model) and process (lifecycle model) aspects as a single unit [ 16, 23, 24, 25, 26, 27, 28 ].

The first paradigm is quite mature already and implemented in many enterprise information systems. Many WMSs offer general modeling and execution of structured BPs. Besides pure WMSs, ERP systems such as SAP, Oracle, Baan, PeopleSoft have also adopted this technology [21].

The second and the third paradigms are dedicated for knowledge-intensive applications, where decision making could be based on unspecified data and facts and usually involves mental activities or where a WF highly depends on the runtime context [21, 29]. The document-oriented paradigm provides a flexible decision making mechanism and a strong authorization mechanism, whereas case handling aims to provide rather full data than partial one, allow editing data before and after an activity is executed, decide about availability of activities based rather on the current information than on the previously executed activities.

The last paradigm, originally proposed in [23], initiated many further studies and applications because of “a natural modularity and componentization of business operations and varying levels of abstraction” and the familiarity of the artifact concept to the business people [ 16 ]. Business artifacts can be mapped onto a WF engine, thus enabling attachment of other BPM capabilities, including specification and monitoring of business rules and KPIs [ 16 ]. Artifact-centered research continues to be actively developed, especially in the context of declarative style for lifecycle specification and their tool support [24].

WF monitoring starts with the execution of a BP instance in the WF engine. Usually it is implemented in a form of event logging and logs more or less complete information. Another form that must be mentioned is process mining from event logs [30] or execution records [29]. Modern process mining tools use the control-flow dimension of a WF by using, e.g., Workflow Petri Nets [29]. Within ERP, bi-partial monitoring agents called probes can be used [31, 32]. They contain a memory for BP allocation and a logic for BP monitoring. However, deployment of agents over a business process may be hard to automate. 3

The ERP Vendor’s Business Case

ERP systems can be divided into two groups, namely ERP I and ERP II [ 13 ]. While ERP I systems focus on integration of back-office information systems, ERP II systems (which we consider here) focus on collaboration among companies and their customers, serve all sectors and have web-based open architectures. ERP II are complex systems that have more difficulties in coordination among partners as well as in management and assessment, and, thus, can lead to more frequent failures [ 13 ].

Let us illustrate the general features of our business case. An ERP vendor has many customers, mostly, small and medium size enterprises. Each customer uses the vendor’s ERP solution for his specific business needs, integrates it with its own and third party ISs and ERPs, and collaborates with other enterprises. The complexity of the case is that a single BP may have several participants from different enterprises, which collaborate to get some business value, as well as may involve functions provided by other vendors’ ISs. However, the ERP vendor has access and ability to change/enhance functionality only in his own product.

Let us look at the simplified example of the cross-enterprise CBP. Participant 1 initiates the business process, executes his own activities, and then requires collaborative activities from other enterprises, e.g., agreement of Participant 2 and approval of Participant 3. In the worse case, Participant 1 might not even know about the necessity of approval by Participant 3, since this could be Participant’s 2 confidential information. Besides, Participant 1 cannot monitor other participants activities and his own created documents until the final status of them will be available for all allowed participants.

From the ERP vendor’s viewpoint, this problem will look more complicated (Fig. 1). User tasks may be automated in the ERP and other ISs. There is no automatic coordination between tasks, i.e., only the experienced users might know about the correct order of tasks and how to conduct them. The participant who initiated the WF (e.g., Participant 1) does not even know what happens within the business process until the last “link” in the task chain is completed (e.g., registering the completed document in the database by Participant 3). Therefore, there is the necessity to know how the collaborative business process is executed in reality. In our case, it could be some external monitoring process that follows changes of data and BP states. In the context of legacy systems, when a running WE might not exist, or when knowledge about business processes are only in the users’ heads, or at best in some decoupled description, knowing how a process is being used in reality becomes even more crucial. If it would be possible to detect changes in the business objects or obtain information about ongoing/completed activities, this information could be used to generate some form of further user guidance. For example, by showing what activities a particular user should perform next. We should note once more, that the particular ERP vendor’s customers mostly are small and medium size enterprises, and they are not able to make great financial investments into purchasing and introducing expensive BPM products.

To sum up, the main issues within the business case that we are analyzing in this paper lie in the field of information logistics and are the following:  Each participant has its own ERP solution, integrated with other ISs. The ERP vendor has no access to these systems’ internals. It is not welcomed to change the existing IT solution, and it is not possible to change other information systems.  There is no mechanism to monitor the current state of the business process and data, if they are under other participant’s or system’s control. Only the direct user of the corresponding system is able to find out this information by querying data.

Other participants don’t have such rights due to an access control restrictions.  There is no notification mechanism about consequent participant’s tasks even when the document or activity is completed by another participant, and the participant has access to the database entries.  Information flows are not transparent for participants. Experienced users do know their own tasks and task execution order, but are not able to see the whole picture. Thus, a participant who has initiated the business process might not know about all other participants involved in the execution as well as about the results of execution of their functions or tasks within the business process.  There is no informational support regarding the required actions within the task execution, only experienced users’ knowledge.

Our idea is to introduce runtime user guidance to support participants' work with the vendor’s ERP by monitoring the current state of BPs and data. One approach to tackle this case is to employ some form of monitoring data changes in the data store (e.g., database). However, usual approaches that use trigger or transaction log analysis mechanisms might not be sufficient, because it is not possible to detect all kind of data usage with them. For example, selection queries are not logged in the transaction logs. Instead we must use specialized database activity monitoring modules (e.g., Microsoft’s SQL Server database Change Tracking or Oracle’s Audit Vault and Database Firewall).

Next sections are devoted to analysis of existing solutions in the field of CBPs. Since ERP systems are mostly process and data oriented, but quite often may require backward recovery, only the first and the last paradigms are considered relevant to our case and will be studied in the next section. 4

Existing Solutions in the CBP context

Accordingly to the issues and corresponding constraints mentioned in the previous section, we have defined criteria for paradigm/solution analysis that we will use further: maturity of the implementation technique, specification languages, execution principles, monitoring mechanisms (active or passive), easiness of current state and task identification, flexibility of decision making mechanism, communication and BP coordination/synchronization mechanisms, authorization and privacy, integration with other ISs, and a compensation mechanism (transaction backward recovery). 4.1

Activity-flow Oriented Paradigm

The first technique is peer-to-peer collaborative business process management [ 2, 33 ], where a role [ 17 ] or an agent [ 2 ] can create an instance of the CBP, initiate his own ”peer-side” instance, and then notify his peer to instantiate the peer’s side instance. In case of roles, the workflow must be well-understood, specified and shared by all participants. Holding privacy of enterprise activities within the workflow is the challenge in this case. In agents-based processes, an agent must know its communication paths with other agents and a corresponding part of the workflow state space. For roles the workflow could be specified using CPDL (Collaborative Process Definition Language) in an XML document, then compiled to DOM (Data Object Model) tree of Java objects, then to a Java class. For agents it could be any executable workflow specification. The process is executed as a set of peer process instances (which share the same process definition and may have private data and sub-processes) run by process management systems of the participants [ 2 ]. The monitoring is realized as a collaboration among multiple engines which share one common predefined workflow specification. Besides, each agent has its own engine and querying server which collaborates with other agents’ querying servers, thus getting data about the current process state and data statuses. Another way is implementing monitoring agents within the ERP that collect metrics from the ERP database and log files, make an analysis and inform the ERP users about analysis results [31]. The decision making is decentralized and could be based on predefined roles within the shared workflow [ 2 ] or on a set of predefined links to partners related to the possible process states [ 17 ] which contain also data about requested and suggested tasks. Communication is implemented as peer-to-peer messaging mechanism [ 2 ], however simple message interchange (at conversational level) is not enough when a workflow is complex and includes intra- and inter-enterprise collaborations. In this case process-level coordination is critical. Authorization can be role-based [ 2 ], when each participant has its own role within the shared workflow and the rights to manage access permissions within his/her role. If the multipartner collaboration uses the peer-to-peer messaging mechanism, then the solution could be embedded as a set of separate external WMSs [ 2 ], or completely implemented in the single WMS [ 17 ] that controls and coordinates all process invocations.

The second technique is workflow-view-based process collaboration [ 1 ], where processes are views on the workflow from the participant’s viewpoint, and their instances may form a network. Still, the common synchronization means is defined by the workflow specification. Specification could be written in BPMN, WS-BPEL (Web Service BPEL), ebXML (Electronic Business using eXtensible Markup Language), or RosettaNet, and then they can be run in some WMS [ 1 ]. Unlike [ 2 ], the specification is implemented and executed by a single WMS engine, and communication is controlled and managed by this engine. The open challenges are analysis of visibility constraints between entities, process view coordination and deployment of process views for partner organizations [ 1 ]. The monitoring uses tracking of a network of process instances that have multiple collaborative relations with each other. Unlike [ 2 ], in a variety of workflow views, each process has its own view on the common workflow and may change authorization settings. Tracking in a network of process instances could be a useful compensation mechanism for backward recovery, notifying corresponding partners about failures.

Another kind of views on the workflow are web services (WS). Their implementation, monitoring and coordination is well elaborated during previous years. However, currently service networks might not correspond to business services and their combination requires good understanding of their business properties (ontology based semantic services is the promising answer to this issue), and their coordination is not flexible. Specifications, like WS-BPEL and WS-CDL, use predefined processes or rules to solve questions on inputs/outputs, message correlations, etc., but do not take into account dynamics of business processes in collaboration. They require more transactional support because standards and protocols like BPEL4WS, WS-Coordination, WS-Transaction, WSCI (Web Service Choreography Interface) and WS-CDL have too fixed compensation mechanism [ 1 ]. 4.2

Business Artifact-centered Paradigm

While activity-flow oriented business process modeling is oriented on the activity/task flows and considers data flows as secondary, but document/case oriented modeling – vice versa, another paradigm is centered around the data. A very promising data-centric paradigm is the business artifact paradigm that uses a combination of data and process flows as a single building block called (business) artifact [ 16 ]. “Artifacts are business-relevant objects that are created, evolved and archived as they pass through a business” [ 16 ] (e.g., a deal).

Artifacts are specified by two models (or schemas [26]), namely an information/data model and a lifecycle model [25, 27]. The information model specifies data about the business objects during their lifetime. The lifecycle model specifies tasks and their order (way) in time, when they must be invoked on the business objects in the state-based form. There are two notations for the lifecycle specification [26]. The first one is Finite-State-Machines (FSM) for lifecycles without multiple state paths. The second one is Guard-Stage-Milestones (GSM) for lifecycles with complex branching. Decision making is implemented by rule definitions in form of Event-Condition-Activity (ECA), where artifact data serve as business terms in the rules. The current state and data statuses are kept in the artifact and business rule instances and are available on demand. Thus, monitoring could be provided in a simple way – by inspecting artifact instances directly [27].

Participants might use only a part of artifact’s lifecycle, however they will be familiar with other stakeholders needs and their own needs [25]. In this case coordination could be implemented by using log files and controllers of processes, artifacts, and business rules [27]. Artifact specifications may be mapped into workflow designs and executed by a WE, but this leads to losing information about business rules, since they are degraded to control flows and become hardly manageable [27]. Some authors encourage to use special artifact-oriented management systems [25, 26, 27]. In such systems business rules may be modified/removed/added at run-time. Authors suggest using two kinds of management systems: procedural and declarative. The imperative (Siena for FSM models [28] and Barcelona for GSM models [24]) systems are similar to the WMS. The declarative artifact system is under development. It is passive, since allows querying and retrieving artifact information, invoking business events and notifying about the pre-subscribed events [26]. Passive systems could be integrated easier than imperative ones. However, currently artifact-centric management systems mostly have prototype implementation. At the present realization of this paradigm in WMS is faster and more mature, however requires additional efforts in monitoring and business rule flexibility [27].

The artifact model is represented as an XML document and interpreted directly [ 16 ]. All these systems foresee participants’ access control over artifact data [ 16, 26 ] using the CRUDAE (create, read, update, delete, add, edit) mechanism.

The compensation mechanism could be implemented in the context of business artifacts, since all states are known and historical data are logged.

In overall, this paradigm is at the early stage of elaboration and its implementation may require additional research on implementation, e.g., in the context of databases, concurrency control of artifact instances, and data integrity [ 16 ]. Summarizing all features (see, Table 1), we can conclude that conceptually the business artifact paradigm has almost all features of the activity-flow oriented paradigm and is more flexible. It has a different viewpoint in the flow of work activities and data, but may be successfully mapped to the already matured activityflow oriented paradigm and existing tools. However, in such case the implementation will lose separate logic of business rules, since it will be distributed within control flows. Another advantage of the business artifact-centered paradigm is in its potential implementation as a passive (monitor) system that is one of our business case needs. However, this paradigm is new and its realization in an artifact management systems could have various technical challenges. 5

Conclusions

Small and medium businesses, which the ERP vendor targets, are not able to introduce expensive WE solutions, as well as adaptation of legacy ERP for WF based execution usually is not possible without completely redesigning the architecture. As a compromise, BP monitoring and runtime user guidance during cross-enterprise CBP execution could be introduced. However, there are various complex technological issues to solve among other, e.g., state change detection in the process and data flows, access control, determination and notification about subsequent tasks.

Analysis of the available techniques for managing cross-enterprise CBPs concluded that for the business case discussed we should focus on activity-flow oriented and artifact-centric approaches. The former is mature and has developed tool support, but is imperative and less flexible. The latter one might be more promising, but its practical application and tool support are weak and are to be studied in more detail.

This research is ongoing and we continue elaborating on the selected approaches. We plan to research technical implementation of their principles during experimental modeling activities based on the real cross-enterprise CBP.

Acknowledgment

The research has been conducted within the framework of European Regional Development Fund's project "Information and communication technologies competence center" Nr. KC/2.1.2.1.1/10/01/001 (Contract No. L-KC-11-0003) activity 1.2. “Technologies for managing services in workflows”.

References

1. Liu , C. , Li , Q. , Zhao , X. : Challenges and opportunities in collaborative business process management: Overview of recent advances and introduction to the special issue . Information Systems Frontiers 11 ( 3 ), 201 -- 209 , Springer US ( 2009 )

2. Chen , Q. , Hsu , M. : Inter-enterprise collaborative business process management . Proceedings. In: 17th International Conference on Data Engineering , 2001 , pp. 253 -- 260 . IEEE ( 2001 )

3. Pouly , M. , Huber , C. : Collaborative networks: Human aspects and corresponding IT support . In: 13th International Conference on Computer Supported Cooperative Work in Design , 2009 . CSCWD 2009 , 22 -24 April 2009 , pp. 576 -- 581 . IEEE ( 2009 )

4. Feng , X. , Peng , Y. , Xie , H. , Yan , Z. : Role-Based Learning Path Discovery for Collaborative Business Environment . In: Automation and Systems Engineering (CASE) , 2011 International Conference on Control, 30-31 July 2011 , pp. 1 -- 4 . IEEE ( 2011 )

5. GoToMeeting™, Citrix, http://www.citrix.com/products/gotomeeting/

6. Li , Q. , Abel , M. , Barthes , J.-P. : Sharing working experience: Using a model of Collaborative Traces . In: IEEE 16th International Conference on Computer Supported Cooperative Work in Design (CSCWD) , 23 -25 May, 2012 , pp. 221 -- 227 . IEEE ( 2012 )

7. Workflow Management Coalition: Terminology & Glossary. Document Number WFMCTC- 1011 , Document Status - Issue 3.0, Feb 99 , http://www.wfmc.org/resource

8. Future Internet Technologies for MANufacturing industries , http://www.fitman-fi.eu/

9. Hoang , V. M. , Hoang , H. H. : An Ontological Approach for Dynamic Cross-Enterprise Collaboration . In: 26th International Conference on Advanced Information Networking and Applications Workshops (WAINA) , 26 -29 March 2012 , pp. 1355 -- 1360 . IEEE ( 2012 )

10. Walter , P. , Werth , D. , Loos , P. : Peer-to-Peer-Based Model-Management for CrossOrganizational Business . In: 15th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises , 2006 , WETICE ' 06 , pp. 255 -- 260 . IEEE ( 2006 )

11. Khriss , I. , Levesque , E. , Tremblay , G. , Jacques , A. : Towards Adaptability Support in Collaborative Business Processes . In: International MCETECH Conference on eTechnologies, , 23 - 25 Jan. 2008 , pp. 34 -- 45 . IEEE ( 2008 )

12. de Laborda, C.P. , Popfinger , C. , Conrad , S. : Dynamic intra- and inter-enterprise collaboration using an enhanced multidatabase architecture . In: Proceedings. Sixteenth International Workshop on Database and Expert Systems Applications , 22 - 26 Aug. 2005 , pp. 626 -- 631 . IEEE ( 2005 )

13. Eckartz , S. , Daneva , M. , Wieringa , R., van Hillegersberg, J. : Cross-organizational ERP management: how to create a successful business case? In: Proceedings of the ACM symposium on Applied Computing (SAC '09) , 2009 , pp. 1599 -- 1604 . ACM, USA ( 2009 )

14. Ko , R.K.L. , Lee , S.G. , Lee , E.W. , Jusuf , A. : Dynamic Collaborative Business Process Formulation via Ontologised Hierarchical Task Network (HTN) Planning . In: ICWS 2009. IEEE International Conference on Web Services , 6 - 10 July 2009 , pp. 959 -- 967 . IEEE ( 2009 )

15. Thullner , R. , Rozsnyai , S. , Schiefer , J. , Obweger , H. , Suntinger , M. : Proactive Business Process Compliance Monitoring with Event-Based Systems . In: 15th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW) , 2011 , pp. 429 - - 437 . IEEE ( 2011 )

16. Cohn , D. , Hull , R.: Business Artifacts: A Data-centric Approach to Modeling Business Operations and Processes . IEEE Data Eng. Bull . 32 ( 3 ), 3 -- 9 ( 2009 )

17. Zheng , X.-Q. , Liu , M. , Yan , J.-W.: Design of the executable business state-model process based on finite state machine . In: IEEE 16th International Conference on Computer Supported Cooperative Work in Design (CSCWD) , 23 - 25 May 2012 , pp. 207 -- 213 . IEEE ( 2012 )