Towards an approach to improve business process models using risk ...

2 downloads 0 Views 788KB Size Report
Abstract—Business process management aims to create and develop value inside organizations. Though, business processes are exposed to different risks that ...
Towards an approach to improve business process models using risk management techniques Hanane Lhannaoui, Mohammed Issam Kabbaj, Zohra Bakkoury Department of Computer Science, AMIPS Research Group EMI, MOHAMMED V University Agdal Rabat, Morocco [email protected], [email protected], [email protected]

Abstract—Business process management aims to create and develop value inside organizations. Though, business processes are exposed to different risks that may cause failures in their execution. In order to preserve this value, applying risk management principles in Business process management discipline has become a field that takes a lot of attention. Risk-aware Business Process Management (R-BPM) is an area that combines the advantages of Business Process Management and Risk Management. Some works tried to propose approaches for mitigating risks but only in the execution phase. Our research work aims to mitigate risks by design using a method based on a risk analysis technique HAZOP (HA-Zard OP-erability). In this paper, our objective is twofold. We will firstly introduce an approach for analyzing business process models using an adaptation of HAZOP, propose recommendations for reducing risks and we will then plan actions to implement those recommendations by design. Afterward, we will propose a redesign for the business process model and consequently get an improvement for the original model. Keywords— business process; risk aware; risk management; risk analysis; HAZOP; business process redesign

I.

INTRODUCTION

Business processes are fundamental to an organization’s success in producing its goods and services. For an organization to maximize its competitiveness it needs to have processes which are both well designed and which work effectively [8]. In that context, different techniques are used in business process lifecycle for effective management of business processes. Business Process Management (BPM) is a cyclic methodology in which business process are investigated in several perspectives during its phases [7]. Business Process management contributes to create value inside organization [1]. However, organizations are exposed to frequent changes and incidents, which constrains performance and value preservation. Risk management aims to reduce or neutralize potential risks and simultaneously offer opportunities for positive improvement in performance [12]. Mainly, BPM and Risk Management are two domains that remain separated inside organizations. Thereby, in the light of

many events in the last decade that had led to large scandals in business history, it is becoming essential to bring the risks management practices closer to business process management domain. In fact, Risk aware business process management system is a system which allows the reasoning about management of risks in BPM from the design to the post execution of business process. This paper addresses the topic of risk-aware business process management. It relates the result of our research project that aims to develop an approach for mitigating and minimizing risks by design. The objective of the current step is to show by example how risk management techniques, in particularly, risk analysis can influence the design of a business process models. We will use the design principles to minimize the risk in an earliest phase of the business process lifecycle: Modeling. The aim of this work is to provide a concrete mechanism for analyzing risks in business process models. For this reason, we propose an interpretation of a risk analysis method adapted to the context of business process models. We will, then, introduce an approach for reducing risks of models by proposing a redesign due to the result of the risk analysis phase. This paper is organized as follows. Section 2 describes riskaware BPM system. Section 3 talks about EPC-Based HAZOP Analysis which is an adaptation of the traditional method for risk analysis (HAZOP). Section 4 aims to develop our approach while section 5 covers the related work. The 6th section is devoted to an illustration example that shows the benefits of our approach. Finally, section 7 concludes the paper. II.

RISK-AWARE BUSINESS PROCESS MODEL

Risk-aware BPM is an area that attempts to integrate the two typically separate disciplines: Business process management and risk management. This integration has many advantages including the ability to: - analyze risks and incorporate risk mitigation strategies in a business process model during design time [4], - monitor the emergence of risks and apply risk mitigation actions during run time [2],

- identify risks from logs and other post-execution artifacts

models with risk-related information (such as risk factor and risk control measures).

Furthermore, it may also aid businesses to comply with various rules and regulations, such as Sarbanes-Oxley Act and Basel II [5].

Other works proposed extensions for other modeling framework. For example in [6], Lambert et al. proposed simple risk extensions to the integrated definition (IDEF) process modeling. Also in [17], the semantic business process modeling language (SBPML) is extended with a number of risk-related constructs such that the inclusion of risk-related information into business process models can be achieved. These constructs are expressed as a set of graphical notations. Finally, in [19], Cope et al. developed a semiformal extension to the BPMN standard.

[3].

A. R-BPM lifecycle The risk-aware business process management lifecycle embeds elements of risks into the four phases of the traditional BPM lifecycle described in [7].

In view of the fact that most works on risk-annotating models were considered in EPC, we will consider in this paper risk-annotated business process model based on EPC for the illustration. III.

EPC-BASED HAZOP ANALYSIS

A.

Fig. 1: Risk aware BPM lifecycle

As described in the Fig.1, in the Risk Identification phase, the process model is analyzed for potential risks using established risk analysis methods such as the Fault Tree Analysis (FTA) [21], Failure Modes and Effects Analysis (FMEA) [22]... The result of this phase is a set of risks. Each one is expressed as a risk condition that describes the set of events that lead to a potential fault occurrence. Then, in the Design phase, these risk conditions are mapped to process model-specific aspects. The result of this phase is a riskannotated process model. After that, in the Implementation phase, these conditions are linked to workflow specific aspects, such as the content of data variables and resource allocation states. The model is then executed by a risk-aware process engine in the Enactment phase. Finally, the Diagnosis phase involves risk monitoring and controlling, which can trigger changes in the current process instance, to mitigate the likelihood of a fault occurring, or in the underlying process model, to prevent a given risk from occurring in future instances. In this paper, we will focus on the two first steps. We will consider risk-annotated business process models. B. Risk-annotated process models Most representations of risk-relevant extensions to business process models were considered in the Event-driven Process Chain. Rosemann and zur Muehlen presented in [14] a riskrelevant extension of business process models in the Eventdriven Process Chain and a method for incorporating risks into EPCs. Another risk extension using the notation of EPC is presented in the work [11]. Sienou et al. proposed in their work [18] a set of graphical notations that are also based on the EPC language and that can be used to annotate business process

Process Hazard Analysis- HAZOP A HAZard and OPerability (HAZOP) study is a risk analysis technique that is used to identify weaknesses and hazards in a processing facility [10]. It is used in the planning phase (design). The HAZOP was initially developed by the company ICI in 1974 for chemical developing facilities but has later been extended to other types of systems and also to complex operations and to software systems. HAZOP is based on a theory that assumes risk events are caused by deviations from design or operating intentions. The purpose of a HAZOP study is to identify what potentially hazardous variations from the design intent could occur in components and in the interactions between components of a system [9]. Consequently this will permit us to avoid continuing development of designs with potential hazards [9]. The technique uses guide words to promote creative thinking about the ways in which hazardous situations might occur. A guide word is used to express a particular kind of deviation (Table 1). TABLE 1: HAZOP GUIDEWORDS [9] Guidewords No More Less As well as Part of Reverse Other than Early Late Before After

Interpretation This is a complete negation of the design intention. No part of the intention is achieved and nothing else happens. This is a quantitative increase. This is a quantitative increase. All the design intention is achieved together with additions. Only some of the design intention is achieved. The logical opposite of the intention is achieved. Complete substitution, where no part of the original intention is achieved but something quite different happens. Something happens earlier than expected relative to clock time. Something happens later than expected relative to clock time. Something happens before it is expected, relating to order or sequence. Something happens after it is expected, relating to order or sequence.

B. Event-driven Process Chain EPCs (Event-driven Process Chain) are a graphical business process description language introduced by Keller, Nuttgens and Scheer in 1992 [13]. It was developed at the Institute for Information Systems of the University of Saarland, Germany, in collaboration with SAP AG. The EPC is a core part of the ARIS-framework and combines the different views towards the description of enterprises and information systems in the control view on the conceptual level [23]. EPCs describe processes on the level of their business logic. They are targeted to be easy understood and used by business people. The name represents the control flow structure of the process as a chain of events and functions. Actually, the EPC describes processes by the use of alternating functions and events as time-referring state changes. Events and functions are linked by the control flow as directional edges [13]. An event-driven process chain consists of the following elements: • Functions: The basic building blocks. A function corresponds to an activity (task, process step) which needs to be executed. • Events: They describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. • Logical connectors: They can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR. The extended EPC includes the elements described below: •

The Organisation Unit or Role is responsible for performing an activity or function.



The Information Objects portray input data serving as the basis for a function, or output data produced by a function. They correspond to entities or attributes of the Entity-Relationship (ER) model.



The deliverables represent results (services or products) functions produce or input functions require.

C. Hazop method adaptation In this section, we will propose an adaptation of the HAZOP method for EPC-extended models. In our context, HAZOP is applied to each element of the EPC model. EPCBased HAZOP is based on a re-interpretation of the guidewords of HAZOP previously presented in table 1 in the context of EPC modeling. This proposal will consider a guideword interpretation for the deviations of EPC elements such as Function, Event, Organizational role, etc. While the EPC model is completed, the HAZOP method is applied by selecting model’s elements and applying the corresponding guidewords to them. Any Risk-annotated

business process model can be considered as a HAZOP entity and its EPC elements as its HAZOP attributes. The table 2 identifies the possible deviations that can be detected for the EPC model’s elements. It represents the different HAZOP attributes and guidewords as conform to the description in the preceding paragraph. IV.

METHOD OVERVIEW

The approach proposed in this paper aims to revise a business process model through the application of risk analysis principles. With consideration of risks identified in the risk analysis phase of the R-BPM lifecycle, design modifications are suggested. Those modifications ensure the mitigation of an identified risk through the reduction of its severity or the probability of its occurrence. Subsequently, a redesign of the original model is proposed. The starting point of our method is a model of business process in a risk aware business process environment. We will consider risk annotated business process models. The first step is to analyze our model by using EPC-based HAZOP. Guidewords are systematically applied to attributes of entities in the process design. A risk can be expressed as a consequence of a deviation of one or more components of a business model element. After, possible causes and consequences of those deviations are analyzed. The HAZOP principle consists of establishing the corresponding recommendations for minimizing the different risks that have been identified. The resulting recommendations can be translated either by business rules or by design modification. In this work, we will focus on recommendations that can be translated by design modification as a technique of risk reduction. We can then, propose a redesign for the initial business process model by implementing recommendations. Accordingly, the redesign of the initial business process will cause an update of the risk assessment. To sum up, the approach proposed here focuses on risk analysis techniques that are applied at the early design phase of the R-BPM lifecycle. Hazards are identified and safety requirements are derived, the design is redone in order to avoid or significantly reduce the risks. V.

RELATED WORK

Most approaches that have been proposed in the area of risk-aware business process management tried to address the issue of risk in business processes at design time [5]. Some papers attempt to reason about risks by introducing new integrated risk constructs to capture risk-related information within a business process model, others attempt to reason about risks through the use of existing risk analysis methods. In fact, Rosemann and zur Muehlen presented in [14] a method for incorporating risks into EPCs. Their work also included taxonomies for risk identification, a set of related models for expressing the risk structure, the risk state and the impact of risks on process goals. Sienou et al. proposed in [18] an integrated framework called the Business Process Risk Management Integrated Method (BPRIM) framework. In their

TABLE 2: LIST OF RISK IDENTIFIED Attribute Function

Event (post condition, precondition)

Logical connector

XOR

OR And

Control Flow Organisation Unit or Role The Information Objects (input, output)

The deliverables

Guideword No/None Other than Part of As well as More No/none Other than As well as Part of Early Late

Interpretation Function is not executed Unexpected activity or task is executed Only a part of a set of activity is executed Function is executed as well as another function Function is executed several times The condition is not evaluated and can have any value The condition is evaluated true whereas it is false, or vice versa The condition is correctly evaluated but other unexpected conditions are true The condition is partially evaluated, Some conditions are missing The condition is evaluated earlier than required The condition is evaluated later than required

As well as No/None Other than No/None Other than No/none Part of Other than No/None Reverse No/None Other than No/none More / less

Two or more paths are activated in the control flow concurrently. None of the two paths is activated Another path is activated None of the two paths is activated Another path is activated Both paths are not activated Just one of the two path is activated Another path is activated The path is not activated in the control flow The path is activated reversely The organization Unit or Role is not available The activity is executed by another Role or unit Input data serving as the basis for a function is not available or output data haven’t been produced by a function. There are less than demanded input data for executing the function/ function have produced more data than expected The function have produced the expected data output as well as other elements Only some of the required input data is available/ function have produced some of the expected output data The available input data is not the one expected for the execution of a function/the function have produced output data which is different from the expected The deliverables are not available or haven’t been produced The function require more or have produced less deliverables The function have produced the expected deliverables as well as other elements Only some of the required deliverable is available Some services or products have been produced but not the expected ones

As well as Part of Other than No/none More / less As well as Part of Other than

approach, activities that are commonly undertaken during the design stage of a business process (such as process modeling and analysis) are systematically mapped to activities from the risk management lifecycle to produce an integrated BPM and risk management RM lifecycle. Furthermore, the relationships between the concepts commonly encountered in the field of BPM (such as activity, resources) and RM (such as risk event) are explicitly studied and modeled (using class diagrams). In [15] and [16], Tjoa et al. proposed another framework for incorporating risks into process models. The framework is called the Risk-Oriented Process Evaluation (ROPE) methodology. It presented a three-layer model. The top layer is the business layer which consists of business process activities. These activities are decomposed into their corresponding Condition, Action, Resource and Environment (CARE) elements to form the middle layer of the model. The bottom layer is called Threat Impact Process (TIP) layer captures the various threats that may affect the corresponding CARE elements and the countermeasure activities. The authors described a simulation process for assessing the impact of threats on the process activities. Finally, in [19], Cope et al. introduced a comprehensive framework for identifying and modeling process risk and the associated graphical techniques for expressing these models and enabling a quantitative analysis of process risks.

Suriadi et al. enumerate in [5] some research gaps identified in the risk-BPM area including the lack of research dedicated to mitigating related process risks. Existing works on mitigating are rare and focus more on risk-aware BPM methodologies than on concrete algorithms on risk mitigation such as [4] in which Goluch et al. proposed to analyze risks and incorporate risk mitigation strategies in a business process model during design time. Mitigating action and countermeasure are described in procedures which are defined and validated via a simulator at design-time; enactment at runtime is designated to a ‘responsible person’, that is, the mitigation and recovery operations are not automated. As to the [20], Conforti et al. proposed a concrete approach for the automatic mitigation of risks but during process enactment. To this day, no work has treated the mitigation of business process risks by design. Our approach deals with this issue. In fact, it tries to facilitate the integration of risk analysis at the design stage. This will lead to the conception of reliable business processes. Reducing risks in an earliest phase of business process lifecycle will decrease the number of failures during execution and will minimize the business loses due to the investment in the other phases of business process lifecycle. The approach considers business processes in the modeling phase and proposes a change of design so that the hazard is avoided or the risk associated with is reduced sufficiently. This will contribute

Fig. 2: Order-Fulfillment: Payment Subprocess

to the improvement of business process in term for reliability and safety. Our paper makes a first step towards an approach for mitigating and reducing process-related risks by design. This will help organization to create robust processes even before being involved in other phases of the business process lifecycle. VI.

ILLUSTRATION EXAMPLE

To illustrate our approach, we will consider an example of business process model: the “Order-Fulfillment: Payment subprocess” which is described in [2] and [20]. It draws the payment subprocess of an order fulfillment business process. To introduce our method, we rewrote our example using EPC extended with risk [5] instead of YAWL (Fig. 2). We will consider risks identified during the execution of this payment subprocess. Table 3 presents a description of those risks.

In order to apply our approach, we established the associated deviations of the business process model components related to the list of risks identified in the table 3. The table 4 relates the result after applying EPC-Based HAZOP. TABLE 3: LIST OF RISK IDENTIFIED Risk Approval fraud

Risk description The Senior Finance Officer who has approved a Shipment Payment Order for a given customer, must have not approved another order by the same customer in the last x days.

Order unfulfillment fault

It is a situation where a process instance executes a given task too many times which may lead to a process slowdown but also to a “livelock” if the task is in a loop whose exit condition is purposefully never met. This can occur when the task Update Shipment Payment Order is re-executed five times within the same process instance.

Underpayment fraud

This type of fault occurs when a customer underpays more than three times within the last five days.

In our example, each deviation can be seen as a potential hazard. Each hazard can lead to an undesired event as described in the table 4. First deviation is related to the task “Approve Shipment payment order” (Fig. 2).

failure. In case no resource exists, we proceed then to a plan B which aims to assign the task to two resources instead of one. We opted for this solution to reduce the risk of approval fraud and also to avoid a process slowdown which may cause an overtime process fault.

In order to avoid the “approval fraud”, we proposed to insert a new activity which objective is to look for resource that meets the condition “must have not approved another order by the same customer in the last x days” (Fig.3).

Fig. 4: Design modification (second deviation)

Fig. 3: Design modification (first deviation)

In case all resources don’t meet this condition, we recommend to assign this task to two Senior finance officers instead of one (Table 4). If both senior finance officers approved the order, we pass to the process shipment payment. If, at least one of the senior finance officers does not approve the order, the shipment payment order is updated and we then go to the next step as it shown in the final redesign in the fig.6. The second deviation (Fig. 2) is related to the function “Update shipment payment order”. Through the establishment of recommendation in the table 4, a new model fragment (Fig.4) is proposed. The third and last deviation is linked to the function “Issue debit adjustment” (Fig.2). After translating the recommendation in table 4 into design modification, we get the new model element presented in the Fig.5: Through applying our approach, we proposed design modifications that led to the reduction of risks detected in our original model. The output of our method is represented in the fig.6. In fact, for the “Approval fraud” risk, we proposed, firstly, to check for resources that meet the condition to avoid the

Fig. 5: Design modification (third deviation)

TABLE 4: EPC-BASED HAZOP OUTPUT Element/ Attribute Approve shipment payment order

Guideword

Deviation

Use case Effect

Possible causes

New safety requirements

As well as

An other order had been approved by the senior officer for the same customer in the last x days

Approval fraud

All other finance officers are busy

Assign the order to two of Senior Finance Officers instead of one.

Update payment shipment order

More

Update payment shipment order more than 5 times

Order unfulfillment fault; Process slowdown

Human error in the shipment order

If the payment shipment order had been updated for 5 times, assign the order to another finance officer.

Issue debit adjustment

More

The number of debit adjustment issued to the customer is more than 3

Underpayment fraud

Assign the customer to legal Service Suspense Operation with customer until feedback from Legal Service

Fig. 6: The new model after applying our method

[4]

However, in our example we didn’t check the case when all resources are busy which may also cause an overtime process fault. For the second risk “Order unfulfillment fault”, we suggest to assign the task “issue shipment order” to another Finance Officer. Because if after 5 times we still have the same problem this may be a human error by the finance officer. For the third and last risk, which is “Underpayment fraud”, we propose to strengthen our process by recommanding a scenario: to assign the customer to the legal service and to suspend other operations with him until the problem of underpayment is resolved. In a nutshell, through the application of the approach proposed in this paper, the business process modeled in Fig.2 has been revised. This impacts the risk assessment of the initial model. In fact, the Fig.6 represents a redesign of the original model in which, we tried to avoid the hazards associated to its different components and consequently reduce the associated risks. VII. CONCLUSION In this paper, we presented the result of our research project aiming to elaborate an approach for mitigating business process related risks by design. We did introduce the concept of risk-aware business process management which integrates the risk management techniques in business process management. We also presented an overview of our approach which is based on an adaptation of a traditional process hazard analysis method (HAZOP) that have been reconciled with annotated business models environment. Later, we proposed a set of design modifications based on EPC-based HAZOP recommendations. Through applying this method on a motivating example, we demonstrated how our approach can lead also to a global business process redesign. Afterwards, we plan to elaborate a set of generic patterns based on the result of risk analysis. Actually, we are working on a generic approach that formalizes the output of EPC-Hazop method. This will help us firstly to establish a formal approach for mitigating business process related risks by design. And secondly, this will assure the improvment of business process models directly without going through the whole BPM lifecycle. Our approach will be beneficial to the extent that it improves the robustness of our processes in an earlier phase.

[5]

[6]

[7]

[8] [9]

[10] [11]

[12]

[13]

[14]

[15]

[16]

[17]

[18] [19]

[20]

REFERENCES [1] [2]

[3]

Burlton, R.T.: Business Process Management: Profiting From Process. Sams publishing, Indianapolis, USA (2001). Conforti, R., Fortino, G., Rosa, M. L., and ter Hofstede, A. (2011). History-aware real-time risk detection in business processes. In OTM 2011 Conferences. Jans, M., Depaire, B., and Vanhoof, K. (2011a). Does process mining add to internal auditing? An experience report. In Halpin, T. A., Nurcan, S., Krogstie, J., Soffer, P.,Proper, E., Schmidt, R., and Bider, I., editors, BMMDS/EMMSAD, volume 81 of LNBIP, pages 31–45. Springer.

[21] [22]

[23]

G. Goluch, S. Tjoa, S. Jakoubi, and G. Quirchmayr. Deriving resource requirements applying risk-aware business process modeling and simulation. In ECIS. AISeL, 2008. S. Suriadi, Burkhard Weiß, Axel Winkelmann, Arthur ter Hofstede, Michael Adams, Raffaele Conforti, Colin Fidge, Marcello La Rosa, Chun Ouyang, Michael Rosemann, Anastasiia Pika, and Moe Wynn : Current Research in Risk-Aware Business Process Management Overview, Comparison, and Gap Analysis, BPM Center Report BPM12-13, BPMcenter.org, 2012. J. H. Lambert, R. K. Jennings, and N. N. Joshi, BIntegration of risk identification with business process models,[ Syst. Eng., vol. 9, no. 3, pp. 187–198, Oct. 2006. M. Dumas, W.M.P. van der Aalst, and A.H.M. ter Hofstede. ProcessAware Information Systems: Bridging People and Software through Process Technology. Wiley & Sons, 2005. Harmon P, Business Process Change, Morgan kaufmann, San Francisco, 2003. Ministry of Defence. HAZOP studies on systems containing programmable electronics. Defence Standard 00-58, Parts 1 and 2, Issue 2, May 2000. Trevor A. Kletz. Hazop & Hazan: Identifying and Assessing Process Industry Hazards, Fouth Edition.Trevor Kletz, 1999. A. Sienou, E. Lamine, A. Karduck, and H. Pingaud, B. Conceptual model of risk: Towards a risk modelling language,[ in Proc. WISE Workshops, M. Weske, M.-S. Hacid, and C. Godard, Eds. SpringerVerlag, 2007, vol. 4832, LNCS, pp. 118–129. Ward, S. and Chapman, C. Transforming Project Risk Management into Project Uncertainty (1994). Management, International Journal of Project Management, 21, 97-105. G. Keller, M. N¨uttgens, and A.W. Scheer. Semantische Processmodellierung auf der Grundlage Ereignisgesteuerter Processketten (EPK).Ver¨offentlichungen des Instituts f¨ur Wirtschaftsinformatik, Heft 89 (in German), University of Saarland, Saarbr¨ucken, 1992 M. zur Muehlen and M. Rosemann, B. Integrating risks in business process models [ in Proc. 16th ACIS, Sydney, Australia, Nov. 30–Dec. 2, 2005. Simon Tjoa, Stefan Jakoubi, Gernot Goluch, Gerhard Kitzler, Sigrun Goluch, and Gerald Quirchmayr. A formal approach enabling risk-aware business process modeling and simulation. IEEE Transactions on Services Computing, 4:153-166, 2011 S. Jakoubi, T. Neubauer, and S. Tjoa. A roadmap to risk-aware business process management. In IEEE Asia-Paci_c Services Computing Conference APSCC 2009., pages 23-27, dec. 2009 B. Wei_ and A. Winkelmann. Developing a process-oriented notation for modeling operational risks - a conceptual metamodel approach to operational risk management in knowledge intensive business processes within the financial industry. In 2011 44th Hawaii International Conference on System Sciences (HICSS), pages 1-10, jan. 2011. Amadou Sienou, Elyes Lamine, and Herve. A method for integrated management of process-risk. In Proceedings of GRCIS, 2008. E. W. Cope, J. M. Kuster, D. Etzweiler, L. A. Deleris, and B. Ray. Incorporating risk into business process models. IBM Journal of Research and Development, 54(3):4:1-4:13, may-june 2010. R. Conforti, A.H.M. ter Hofstede, M. La Rosa, and M. Adams. Automated Risk Mitigation in Business Processes, 2012. International Electrotechnical Commission. IEC 61025 Fault Tree Analysis (FTA), 1990. International Electrotechnical Commission. IEC 60812, Ed.2: Analysis techniques for system reliability-Procedure for Failure Mode and Effects Analysis (FMEA), IEC 56/735/CD, 2001-04. Scheer, A.-W.: ARIS – Business Process Modeling. Springer Verlag 1999.