Business processes as well as their supporting information technology (IT) can be affected by compliance requirements. In the case of changing the business process, an IT component or a compliance requirement the interactions between business process compliance (BPC) and business process change must be determined to ensure BPC. However, there is a lack of tool-support that can analyze the interactions between BPC and business process change considering compliance requirements and supporting IT components. Therefore, we developed the prototype BCIT (Business Process Compliance and IT) which can analyze these interactions considering the change patterns “delete element” and “replace element”.
Business process compliance (BPC) denotes the execution of business processes in
adherence to applicable compliance requirements [
The rest of the demo paper is structured as follows: Section 2 defines preliminaries and provides a motivation example that can be solved by our prototype. Section 3 shows the architecture and implementation of our prototype; and finally, Section 4 concludes the paper. 2
Business Process Compliance and Business Process Change
There are various approaches used to check for or ensure BPC. One possible solution
to ensure BPC during the design time of the business process is the separate modeling
of so-called compliance processes and their integration into the business process. In this
context, a compliance process is defined as an independent process (part) consisting of
at least one compliance-related activity that ensures BPC [
In the literature, many business process change patterns are discussed. In the
following, we focus on the change patterns “replace element” and “delete element” (e.g. [
Physical access
Create purchase request ERP MM
Send Receive purchase goodsand request invoice
Hardware § 238 German Com.
Code
Internal policy
Inform purchase requester about received goods
Approve invoice payment
Pay invoice ERP FI
Replace ERP FI Logical Logical access(CR) access § 238 German
CommercialCode (CR)
Hardware (IT) Physical access(CR)
§ 238 German CommercialCode (CR) Pay invoice (activity) Internal policy (CR)
§ 238 German CommercialCode (CR) Approveinvoicepayment
(CP) IT is prerfeoqruisite CP cehleamngeendt redliarteicotn eilmempaecntt egxatceluwsaivye cehleamngeendt trraenlastiitoivne eilmempaecntt
Delete ERPFI
Approveinvoice payment(CP) Internal policy (CR)
§ 238 German CommercialCode (CR) Logical access(CR)
Obsolete element BPC violated because CR is prerequisite CR for place CR demands to IT
IT is prerequisite activity IT is prerequisite IT for for place
CR demands to activity CP: compliance process | CR: compliance requirement | IT: IT component
CP hsealtpissftyo CR start event,
end event
The left side of Figure 1 shows a simplified purchase-to-pay process including IT
components that support both business activities and the compliance process, which is
based on our previous work [
In the case of deleting the IT component “ERP FI” the compliance requirement “internal policy” and its prerequisite “§ 238 German Commercial Code” are violated. In this case, the compliance process “approve invoice payment” that helps to satisfy the “internal policy” cannot be executed since “ERP FI” is a prerequisite to execute this compliance process. Additionally, the “logical access” becomes obsolete. 3
Tool Architecture and Implementation
We developed the software prototype BCIT1, which is available as a cross-platform
desktop application, based on the software frameworks Node.js and Electron. Figure 2
describes the basic interaction between the components of BCIT to perform each user
step. When starting BCIT, the component app each create an object of process-view,
IT-architecture-view and compliance-view. According to [
<<UI>> IT-architecture-view
<<UI>> comp<l<iaUnIc>e>-view process model model/ link model elements/ change element process-editor
interaction-analyzer process model
app <<UI>> model link model
elements graph-creator link model elements graph change element graph
change graph element interaction-view <<UI>> result graph component provided interface
requested interface
1 Our prototype, the sourcecode, a screencast and further information can be found at:
http://informationsmanagement.wiwi.uni-halle.de/projekte/bcit/
Import Models: Within the component process-importer, we use bpmn-js [
Link Models: Next, the user must link the corresponding elements of the imported
models together. Here, the following relationships are possible: process flow element
and IT component, process flow element and compliance requirement, IT component
and compliance requirement, and compliance requirement and compliance
requirement. Technically, within the component graph-creator the imported models are
transformed into a single graph = ( , , , , ) with its elements ∈ . The graph is
modelled using the graph library Cytoscape [
When linking two elements together, the graph-creator generates the corresponding edges between the vertices of the linked elements. In the case of linking an IT component or compliance requirement to the process, the process-editor (1) extends the respective extension element of the process flow element by the id of the added vertex and (2) adds a data storage symbol or rather a data symbol to the process flow element. Then, the process-viewer visualize the updated process model again.
Define the Element to be Changed: For analyzing the interactions between BPC and business process change, the user has to define the element to be changed. This element can be a compliance requirement, IT component, or a process flow element that includes a compliance process. The interaction-analyzer always performs the analysis when the interaction-view is opened. The analysis is based on the graph that was generated and adjusted in the previous step. Figure 3 shows the algorithm used to analyze the interactions between BPC and business process change by replacing an IT component.
Input: Graph g, element to be replaced v g where h=it architecture 1 // get all direct related compliance requirements and compliance processes to v 2 Foreach k in (get all predecessor of v where h=compliance requirement) do 3 mark k as direct AND add k including all vertices between k und v to result 4 // get all transitive related compliance processes and compliance requirements to v 5 Foreach it in (get all leafs of v where h=it architecture) do 8976 ForFoerkmaacerh=ackghaciettctr,iavliiatnclyt(pigivreniettdy(ega,celelcstrsdaoilarrnledocdfkticrpraerscetdterscauencsscsieotsrisvoorfANoDafcatitdidviwtthoyerwreheesh=ruelbtuhs=incoemspslpiarnocceesrse)qudoirement) do 10 Foreach complianceprocess in (get all direct successor of it where h=compliance process) do 111213 Formkaer=ackghietctr,alicnolm(ppglreieatdneaccleelpsrsodoicrreesoscf,tcsrcurcacensdskoraosftcroamnspliitainvceApNrDoacedsdstowhererseuhl=tcompliance requirement) do 14 generate result_graph based on g and result
Output: Graph result_graph
Fig. 3. Algorithm to analyze interactions by replacing an IT component (based on [
Conclusion, Maturity and Future Work In this paper we presented BCIT, a software prototype that is able to analyze the interactions between BPC and business process change considering supporting IT components and compliance requirements. The interaction between BPC and business process change occurs in two cases. First, the changed element is affected by a compliance requirement or a compliance process. Second, the changed element affects a compliance requirement or a compliance process. More precisely, our software prototype considers the business process change patterns “delete element” and “replace element”.
Currently, BCIT considers the user-provided links between elements of the three model types’ compliance requirements, processes and IT architectures. Furthermore, only vertices of our single graph can be changed. As a consequent next step, we are planning to add the data and resource perspectives on a business process to our algorithm. Additionally, we are planning to extend BCIT by a function to add or remove edges between individual IT components or compliance requirements. As a result, it is possible to detect demands by compliance requirements and thus avoid compliance violations due to changed relations between individual IT components or compliance requirements.