Developing a Business Process Modeling Language for the ... - uDoo

Americas Conference on Information Systems (AMCIS)

AMCIS 2009 Proceedings Association for Information Systems

Year 2009

Developing a Business Process Modeling Language for the Banking Sector – A Design Science Approach Joerg Becker∗

Burkhard Weiss†

Axel Winkelman‡

∗ ERCIS,

[email protected] [email protected] ‡ ERCIS, [email protected] This paper is posted at AIS Electronic Library (AISeL). † ERCIS,

http://aisel.aisnet.org/amcis2009/709

A Business Process Modeling Language for the Banking Sector

Developing a Business Process Modeling Language for the Banking Sector – A Design Science Approach Jörg Becker University of Muenster / ERCIS [email protected]

Burkhard Weiß University of Muenster / ERCIS [email protected]

Axel Winkelmann University of Muenster / ERCIS [email protected] ABSTRACT

The need to extensively analyze business processes for multiple purposes is currently of major relevance to banks. Automatically analyzing business process models not only in a syntactical but also in a semantic way becomes increasingly important in order to achieve additional value from modeling efforts. In this article, we introduce a domain-specific BPML which supports the economically efficient semantic analysis needs of banks. Hence, we develop a language using process building blocks for the specific application of IT-driven business process analysis in the banking sector. With a design science approach, we adapt a language from the public sector to the banking requirements and evaluate our findings with the help of a real-life case from the banking industry. Keywords

Business process modeling language, banking sector, PICTURE, design science research. PROBLEM IDENTIFICATION: ANALYZING PROCESS MODELS IN THE BANKING SECTOR

During the past decades, business process modeling has become an important means in business reorganization and management projects. A business process is a “[…] collection of activities that takes one or more kinds of input and creates an output that is of value to the customer” (Hammer, Champy 1993). Modeling is a way to capture the implicit process knowledge of an organization and document it explicitly in a (semi-)formal way. It describes the logical sequence of activities, the resulting products and services, the required resources and data, as well as the involved organizational units (Lindsay et al. 2003). These process models can be used e.g. as a basis for decisions on IT investments, reorganizations or the selection and implementation of information systems. Furthermore, a semantic analysis of the model inherent knowledge can explicate the underlying corporate structures and procedures. However, with a semi-formal specification of business process models (e.g. with the help of the event-driven process chains) an automated model analysis is hardly possible although the automated semantic analysis of business process models would allow significant cost saving potential in contrary to manual evaluations. Current broadly distributed, commercial modeling tools provide only limited support for the automation of analyses (Blechar 2007; van der Aalst et al. 2003). Highly trained advisors with sufficient domain expertise are in many cases necessary in order to evaluate the business process models (Vergidis et al. 2008). To date, there are various research projects and prototypes which deal with pattern identification and semantic annotations of process models (Celino et al. 2007). For instance, Thom (2006) identifies typical block activity patterns as business functions frequently found in business processes. Iochpe et al. (2007) discuss a suite for business processes based on the reuse of contextsensitive workflow patterns. Often, process modeling languages are linked to ontologies. For example, Lin (2008) introduces an ontology-based semantic annotation approach to enrich and reconcile semantics of process models. Thomas and Fellmann (2007) also use metadata to connect actual process models to ontologies. Those approaches need a domain ontology and a (manual) matching between business models and ontological concepts. In our point of view, this two-step approach is very difficult to communicate and use in practice. Hence, we were looking for an easy to use language for banking purposes only that allows an automated semantic process evaluation. It should allow (Pfeiffer 2008): • a comparison of business process elements or sub-processes as to whether they are semantically equally (although they might be named differently), similar or different, • a pattern search in models in order to analyze the occurrence of a particular collection of model elements (e.g. the number of media breaks as an indicator for the introduction of a document management system),

Proceedings of the Fifteenth Americas Conference on Information Systems, San Francisco, California August 6th-9th 2009

1


• and an evaluation of business process models as to check whether a business process model is an adequate and complete representation of its application domain. This need to extensively analyze business processes for multiple purposes is currently of major relevance in the banking sector (Harmon, Wolf 2008; IBM 2005; Cocheo, Harris 2005; Papastathopoulou et al. 2001) and has become even more important in the financial crisis. Analysis purposes in banks include the optimization of business processes, compliance of processes with legal rules, management of (operative) risks in the process landscape, human resource requirements planning according to necessary capacities and skills for executing processes and product costing according to the process-oriented allocation of costs. With the shared ambition among many banks to industrialize banking processes (Drake, Hall, Simper 2009; Wilken et al. 2008), the need to model and analyze process landscapes in banks is omnipresent. Thus our goal is the development of a semantic BPML for the specific application of IT-driven business process analysis in the banking sector. In our article, we introduce first results of adapting and applying a semantic modeling language to the banking domain. The paper is structured as follows: after the introduction in section 1, we justify our decision to adapt the PICTURE modeling language to the banking domain in section 2. In section 3, we discuss our research approach and in section 4 we explain our adaptation procedure and the design of the artifact. We demonstrate our approach in section 5 by applying the developed process modeling language to core banking processes in a case study, which is the first part of the evaluation. In section 6, we further evaluate and discuss our approach by measuring the utility of the process modeling language. In section 7, we conclude our article. In total, our way of research is a design science approach. We adopted the recommendations for design science procedures from Peffers et al. (2007) and Hevner et al. (2004) in order to achieve rigorous research. OBJECTIVES OF A SOLUTION: ADAPTATION OF A DOMAIN-SPECIFIC SEMANTIC BUILDING BLOCK-BASED LANGUAGE FOR THE BANKING SECTOR

Within our projects and expert interviews in the banking sector, we realized that modelers only used generally applicable modeling languages without any specific relation to the banking sector. Furthermore, it turned out that these languages did not support the economically efficient semantic analysis needs of banks. As a consequence, we engineered a method that allows an automated analyzing of process models in the banking sector. Within method engineering, it is possible to distinguish approaches by their starting point. Ralyté et al. (2004) describe four differrent approaches in order to create a new modeling language. The ad-hoc strategy is concerned with the construction of a novel method from scratch. It is necessary if no other modeling languages seem to be feasible. The paradigm-based strategy (Ralyté et al. 2003) starts from an existing meta-model of a modeling language in order to derive a new method. In contrary, the assembly-based strategy reuses method fragments to construct a new method (Gupta and Prakas 2001). In addition, the extension-based strategy focuses on an existing method and provides new additions to it. Many “new” modeling languages originate from other languages and hence are adaptations or extensions of existing languages. We therefore decided to start our research with a closer look at existing domain-oriented languages which allow an automated semantic analysis of process models. Within the process of searching for suitable languages, we soon realized that there is a lack of practically applicable domain-specific languages for semantic analysis (Blechar 2007). From our point of view, the PICTURE modeling language that originates in the public administration sector allows a sufficient support of semantic analyses (Becker et al. 2007; Becker et al. 2006). Hence, we decided to try to adapt the language to our needs in the banking sector. With regard to their processes, we expected banks rather to be similar to public administrations than to retail or industry companies. Most processes are highly repetitive and linear. They are conducted in large numbers and do not have many intersections in comparison to their lengths. In many cases, the processes are highly structured, consistent and standardized due to legal obligations. Furthermore, processes in banking are often decentralized because of many branches which exchange documents and information among each other. As a result of these similarities, we decided to apply an extension-based strategy in order to develop a domain-specific semantic building block language. Hence, we adapted the existing PICTURE method from the public government sector to the banking domain. RESEARCH APPROACH: APPLYING A DESIGN SCIENCE RESEARCH METHODOLOGY

For the development of the semantic process modeling language we apply the problem-centered approach of the design science research methodology (DSRM) presented by Peffers et al. (2008) while aligning our research with the seven guidelines for design science research by Hevner et al. (2004). We selected a design science approach for our research methodology since it addresses important unsolved problems in a unique or innovative way or solved problems in a more effective way. On one hand, we are faced with the solved (more general) problem of business process analysis and provide a solution to handle this more effectively by providing a basis for automated business process analysis with the help of an innovative artifact, whose former absence led to laborious manual analysis of business process landscapes. On the other hand, we can argue that we also faced the unsolved (more specific) problem of automating business processes analysis in the banking sector. The DSRM approach consists of six main activities (cf. Figure 1), which we present with each chapter of this paper in detail. From a top level methodological perspective we utilize different research techniques in each activity to appropriately support our overall


2


objective. The activities we follow in this paper after identifying the actual problem and our objective of developing a modeling language for the banking sector are as follows:

Figure 1. Design Science Research Methodology used for Constructing a Semantic Process Modeling Language for Banking

• Design and Development: We cooperated with a large globally positioned universal retail bank and a specialized bank, which focused on consumer credits only, to find out about their specific needs for process modeling and analysis and their use cases. In addition we made interviews and asked process management experts from banks what needs to be changed in existing process languages and how the PICTURE approach may be suitable for the banking sector. To adapt the language we made an in-depth analysis of processes in one bank. Analyzing all different possible banks and their process landscapes to provide a complete set of building blocks to describe all kinds of activities in banks seemed infeasible. Simon (1996) suggests in such cases to narrow the search process to find a satisfactory solution, i.e. satisfying solution without explicitly specifying all possible solutions. We used heuristics to select a good case such as select a bank with typical bank processes (the credit process is in fact the possibilities most discussed and researched in the literature), and select processes inside the bank which are complex and include many different activity types as to test the power of the method to describe these. We then adapted it to the banking sector, since it is a domain-specific approach. For the final selection and definition of building blocks we used a consensus-building approach among all modelers and analyzers to select the minimal amount of building blocks which were necessary to describe all activities in the given processes. • Demonstration: We did a case study, in which we applied our new banking-specific building blocks to production department of the bank. We did not study the other areas (portfolio management, product engineering and sakes) of our bank case as these did not fit to our objective regarding core banking processes. The purpose of our case study was to demonstrate the applicability and generalizability of the defined banking building blocks as well as to test if process analysis with regard to the specific purpose of identifying business process optimization potentials could be done on an automated basis. • Evaluation and Conclusion: To evaluate the adapted PICTURE method for the banking sector we used three techniques common to evaluation in design science research (Hevner et al. 2004): we used informal argumentation to build a convincing argument for our artifact's utility by building upon the previous research results from PICTURE publications and transferring findings in the similar domain of public administrations, where these were arguably also applicable to the banking sector, as we did not change the PICTURE method apart from the building blocks. In addition we use the scenario technique when we constructed detailed scenarios for process analysis (i.e. process optimization as a specific purpose scenario for process analysis) around our developed artifact to demonstrate its utility. And we followed Peffers et al. (2008), who suggest to compare the


3


artifacts functionality with the solution’s objectives, as well as to use client feedback and logical proof. These research techniques revealed that the artifact was good for the given problem in the given context as there was no further need to extend the process building blocks to be able to model the tasks. In addition analyzability was given “upfront” through the adaptation of an approach designed to fit the needs of analyzability. Finally, we critically discussed the limitations and constraints of our new artifact and concluded with an outlook. DEVELOPMENT AND DESIGN OF THE ARTIFACT: CONSTRUCTING A SEMANTIC BUILDING BLOCK-BASED PROCESS MODELING LANGUAGE FOR THE BANKING SECTOR

Originally, the PICTURE approach is a result of research projects in public administrations (cf. Becker et al. 2006). It strives for a flexible, efficient and simple representation of administrative processes. PICTURE consists of views, process building blocks and attributes (cf. Figure 2). It differs between a process view (How is a service delivered?), a business object view (What is processed/produced?), an organizational view (Who is involved in the modeling process?) and a resource view (What resources are used?).

Figure 2. PICTURE Language Constructs (Views, Models and Language Elements) and Sample Process in PICTURE Notation

The main constructs of the PICTURE modeling language are 26 domain-specific process building blocks. A process building block represents a certain set of activities within an administrative process and applies the vocabulary of the domain. Process building blocks are atomic, have a well-defined level of abstraction and are semantically specified by a domain concept. With process building blocks problems like naming conflicts in a model comparison are avoided, because the name of a process building block is specified by the language designer rather than the modeler. Examples for process building blocks are “Incoming Document”,


4


“Formal Assessment”, “Enter Data into IT”, or “Archive Document”. Process building blocks belong to the process view. With building blocks a sequential order within administrative processes can be specified. Additional facts about the processes can be collected with the help of attributes assigned to each block. These attributes specify the properties of the corresponding building blocks in detail. For example, a possible attribute for the building block “Enter credit application data into IT system” is “Duration”. Attributes provide the core information for a subsequent process analysis. They establish a connection to the business object, organization, and resource view. In the PICTURE notation processes are represented as a sequential flow of building blocks (cf. Figure 2). This sequential order restricts the degrees of freedom of the modeler and simultaneously promotes the construction of structurally comparable process models, as they are linear on a subprocess / variant level. As many processes are quite complex and run through several different organizational units, it is possible to define sub-processes that are conducted by just one employee. However, the strict sequence does not allow for intersections. As a solution, PICTURE allows either the modeling of process variants that define an alternative sequence within a sub-process or the annotation of attributes that can be used to specify different cases with percentage values. Furthermore, an anchor allows for establishing connections between process building blocks in different sub-processes and variants to enable parallel process structures. We focused on transferring the domain-specific building blocks from the public administrative domain to the banking domain. This goal was reached by an iterative process in which we analyzed several dozens of banking processes and sub-processes from a bank and from literature studies. The idea was to identify different activities and from these abstract to common activity types, which resembled the original set of building blocks (also with respect to keeping a similar granularity in defining the building blocks). While we were able to map most activities with the building blocks known from the public sector, there were several specifics in the banking business models, which we believe are distinct to the banking sector as compared to public administrations and needed specific attention. Concerning the processes in the banks, we were confronted with many payment activities, as well as many verification activities and documentation activities, but also many accounting activities, which were performed by employees. As the old building blocks had two different building blocks for incoming payments and outgoing payments we merged these two closely related building blocks to one process building block named “Make / Receive Payment”. We were able to differentiate incoming and outgoing payments by the introduction of a new a payment building block specific attribute, which could differentiate between an ingoing or outgoing payment. A similar optimization possibility for reducing the complexity of the building block set was given as the old building block set had two building blocks for verification activities (one for formal verification – i.e. missing fields in a document and one for verification of content – i.e. verification if claims made via an application form could be accommodated by the bank or not). Since these two building blocks are again closely related, and there was no necessity to strictly separate these activities, we also merged these two building blocks to form a more general building block with the new name “Verification of Document / Information”. Regarding documentation activities, we had to create a new process building block since there was no adequate building block to describe this activity and this was an activity which was frequently found in the banking processes and thus justified the action of creating a new building block for the act of documenting something (the building block was named “Record / Document”). As accounting transactions were made almost as frequently as documentation activities and are daily business in banks, we used this to justify the creation of another new building block named “Make Accounting Transaction”, even though this could probably also be seen as a type of “Enter Data into IT” or “Edit Document / Information”. Since monetary flows and accounting transaction are not just another data entry job, but a very important and common one in banks, we decided against hiding this specificity in an attribute in an existing building block but preferred to create a new building block. To other activities, which were performed sometimes and did not directly correspond to any existing building block but complemented the existing building block set well were “Destroy Document / Information” and “Request Document / Information”, which we therefore added as new building blocks in the subsets “Information Processing” and “Information Search and Coordination”. As typical management activities like planning, monitoring or steering were also of interest to the banks process documentation we had to further expand the building block set to include a high level building block under which all three activities could be subsumed. This new building block was called “Management Activity” with an attribute refinement for differentiating what type of preparation activity was performed. With this new building block we are able so far to even document and analyze management processes, which were formerly not part of the specification PICTURE was designed to (originally it was only designed to support the modeling of core administrative / operational processes and not management processes). A first real peculiarity of the banking process documentations we analyzed was that the bank tried to not only model human activities but to a certain extent also modeled IT system activities, as banks nowadays are highly IT-supported and many activities are hidden and performed solely by the IT system. As to not lose this knowledge the bank required to be able to model these types of activities. The difficulty was to decide how to integrate this request into the PICTURE approach as it was originally only designed to support the modeling of human performed activities. Option a) was to define the IT system as an “organizational role” and linking the IT system role to the building blocks provided also for human activities. Option b) was to extend the existing building block set to include various IT system activities and option c) was to create one new building block, which would hide the


5


complexity of IT system activities, but would yet preserve the knowledge of which processes were triggered and done within the IT system landscape. We decided against option a) as sequential sub-processes in the PICTURE notation follow the “model what you do” principle and thus an employee should be able to model his own activities without knowing what the IT system does in the background. We decided against option b) as adding to many new building blocks would make the building block set to complex for use in modeling purposes and we wanted to keep it small for ease of use reasons and well-arranged. Therefore we decided for option c) and just created one new building block named “System Activity”, which would belong to the subset “Information Flows and Participation”. Thus, an employee would just model this abstract non-human activity into his process without having to know what would happen behind it and the IT department experts could use more sophisticated models like UML for defining IT processes and data flows on a lower granularity which is typically needed for IT implementations.

Figure 3. Proposed Process Building Block Set for the Banking Sector

A second peculiarity was that unlike in public administrations customer activities were included in process models as banks are very customer-oriented and also try to optimize customer activities. Since PICTURE was defined to support only company-internal


6


business processes, we solved this hurdle by introducing a new organizational role for customers aside from the normal internal organizational chart, which is used in the organizational view of the PICTURE methodology. Finally our interviews with bank employees and business process management experts revealed that two further activities were very common in banks which needed to be documented within the business process models. These were creating follow-up activities (i.e. when an employee sent a document to a customer and needed a response within a specific time frame) and the application of the four-eyes principle in numerous activities. As these tasks are not very complex, but moreover usually supplement other activities we decided to integrate these facts into building block specific attributes, esp. those including document flows and client contact regarding the setting of follow-up requests and those where payments and transactions were made with respect to the four-eyes principle. The final building block set developed for the banking industry can be seen in Figure 3 as the central outcome of our extension based method engineering approach. DEMONSTRATION: APPLYING THE DEVELOPED PROCESS MODELING LANGUAGE TO CORE BANKING PROCESSES

To demonstrate the general applicability of our redesigned BPML for modeling and analysis purposes and utility in the context of a specific process analysis project (referring to our original objective of creating a language which makes analysis of business processes easier), we chose to do an extensive case study at a bank, where we could model a large part of the daily operating process landscape with a focus on analyzing core banking business processes. Therefore, we chose a banking partner that would disclose a large share of his process landscape in his complete production department to us (since production processes represent the core banking processes we are focusing on), so that we could evaluate the extended PICTURE methodology on behalf of the dailyin-use business processes, that would also be generally similar to other banks. Our partner bank for the demonstration case was a bank, which operated only a single product – namely consumer credits. The bank provides credits for over 900 banks in Germany and Austria, while at the same time also operates over 60 subsidiary shops in different cities, which only offered its credit product. It employs over 1.000 people in 2007, who together as a bank serve 411.000 customers, totaling a credit volume of 4.63 billion Euros.

Lei stungsba uste in K re dit über Inter net be ste lle n [A U. 10 0. 06 _K red it b este llen (In tern et )] Le is tungs baus tein B es te ll support übe r Inte rnet dur chführe n [A U .1 00 .07 _ Be ste llsu pp o rt (Int erne t)] Lei stungsba us te in K unde naquis e durc hführe n [A U 1 00 .01 Be ste llterm in verein ba ren ]

Kunde übe r Inte rne tbe ste llm öglic hk e it en in form ie re n

Pr odukt m er k ma ls be ra tung dur chführ e n

Kunde übe r m öglic he s B e ste llungsge s prä c h inform ie re n

B e ra tungs ge s prä c h im e C -Shop v er e inba r en

Pr oze s sber at ung dur c hführe n

An w endungs be r atung dur chf ühre n

Da te npr üfung durc hführ en

B e sta nds kunde nbe ra tung

R KV Be ra tung durc hführ en

S ys te m be ra tung durc hführ en

Pr oduk taus w a hlbe r atung durc hführ en

P roduk tber a tung du rc hführe n

Fe hler bei Kr e dit bes te llung übe r Inte rne t be hebe n

Da te npr üfung dur c hführe n

St anda r d

K re dit übe r Inte rne t be ste llen

Le is tungs baus tein U nter lage n di gi ta li sie re n

Te rm in für pe rs önlic he s B e ra tungs ge spr äc h ve re inba re n

B e ra tung zu Be s tellung durc hführ e n

A llge m eine K unde nber a tung dur chf ühre n

K undeninte r es s e a n e as y Cr e dit bea rbe ite n K unde nbe ra tung zu B eis piela ngebot dur c hführe n

Le is tungs baus tei n U nte rla gen di gitali si ere n

Ter m in für pe rs önliche s B e ra tungs ge spr äc h a kt ualis ier en

B e ra tungs ge s prä ch in PB -Filia le v er e inba r en

Lei stungsba uste in e C - B e stel lunterl age n anforde rn [AU . 10 0. 03 e CBe ste llu n terlag e n a nf orde rn ]

St anda rd

Lei stungsba uste in K re dit bes tel len (B rie f) [AU 10 0. 08 Kre dit be ste lle n (B rief)]

Da te n für ne ue pos ta lisc he Kr e dit anf ra ge e rf as s en

A ngebots w uns c h e ntge genne hm e n

Ange bots w unsc h m it K re ditunte rla ge n e ntge ge nne hm en

N e ukunde nda te n f ür e inen K re ditnehm e r e iner ne ue n pos ta lis c hen Kr e ditanf ra ge er fa ss e n

A nge bots w unsc h ohne K re ditunte rla ge n e ntge ge nne hme n

D at en für ber e it s e inger eic hte Kr edita nfr a ge e rfa s se n

B e sta nds kunde nda te n Ne uk unde nda ten für zw e i für eine n K r editne hm e r Kr e dit nehm e r e iner neue n eine r ne ue n posta lisc he n pos ta lis c hen K r edita nfr age Kr e dit anf ra ge e rf as s en er fa ss e n

B es ta nds k unde nda ten für zw ei Kr editne hm e r e ine r ne uen pos talis che n Kr edita nfr a ge e r fas s en

K unde ndat en er gä nze n

K unde ndate n v er v olls tä ndi ge n

Le is tungs baus tein e as yC r edit C he ck durc hführen [A U 1 00 .0 2 e C -C hec k durc hführen ]

K re dita ntra g a uf Aus k unfte iZustim m ung prüf en

Be r atu ng z u B es te llung dur c hführe n

A llgem e ine Kunde nbe ra tung durc hführ en P roduk tm e rk m als ber at ung dur c hführe n

P roz es sbe ra tung durc hführ en

A nw e ndungs ber a tung du rc hführe n

A usk unft über K undens itua tion ge be n

D igit ale K re ditunte rla ge n a r chiv ier en

B es ta nds kunde nbe ra tung

Kr e dit ablös ung be r at en

Sy s tem e nts c heidunge n e rk lär en

P roduk tfolio v ors te lle n

A n ande r er e A bte ilun gen v e rw e ise n

A usk unfte iZus tim m ung für K r edita uftr ag w ur de e r te ilt

B es te llunt er lage n a n K unde n se nde n

K re ditunte rla ge n ar c hiv ie re n

Au sk unfte i Zus tim mun g f ür K re dita uftr ag w ur de nic ht e rte ilt

Lei stungsba uste in K re dit übe r e C -Shop ode r P ar tne rba nk be s te lle n [A U. 10 0. 04 _K red it b este llen (Sh op /P B)]

Leis tungsba ustei n B es tell support für eC -S hop ode r P artne rbank durc hführen [A U .10 0 .05 _ Be stellsu pp ort (S h op , P B)]

Pr oduktbe ra tung durc hführ e n

Pos talis che K r editunt er la ge n a rc hiv ier en

Fa chlic hen Fe hler be i eC -B e st ellung im Inte rne t be he ben

Aus k unft übe r D ate n ge be n

1 . Kr e dit ent sc he idung durc hführ en

Fehle r be i e ingege be nen

Inform a tione n von A usk unft-

D a ten

e ien be nötigt

K re dite nts c heidung gr ün

Kr edite ntsc he idung gra u

K r edite nts ch eidung rot

K r editbe s te llung im eC -Shop

SB S führ t D ruc k und V er sa nd dur ch

R ück tritt von eC -B es tel lung be stätige n [ AU .1 00 .1 1 R ückt ritt e C Be ste llu n g b es tät ig e n]

Stor noa nfra ge für e C- Shop ode r P ar tne rba nk bea rbe ite n

S tornoa nfr age v on nic ht fre iges c halte te r B es te llung be a rbe ite n

S tornoa nfr age v on fre ige sc ha lt e te r und nic ht im Sy s te m v er m er kt er B es te llung be a rbe ite n

S tornoa nfr age von fre iges c ha lt e te r und im S ys te m v er m er kt er B es te llung be a rbe ite n

R e st lic he D a te n zur 2 . K r edite nts che idung e rfa s se n

Rüc k tritt v on e C-B e s tellung be stä tige n

S tornoanfra ge für eC -S hop oder Pa rtner bank be arbe iten [ AU .1 0 0.1 0 _S torn o/ Än de ra nf ra g e b ea rbe iten (S ho p/ PB )]

Rüc k tritt v on nic ht fr e ig ege benem K re dit bes tä tigen St ornoa nfra ge bei a bge lehnte m K re dit be ar be it en

Rüc k tr it t von fr e ige ge bene r und nic ht im Sy s te m v er m er kt er B es te llung be s tä tigen

Rü ck tr it t von fr e ig ege be ne r und im S ys te m v er m er k ter B e ste llung bes tä tigen

Sta nda rd

Rüc k tr it t von a usge führ tem K re dit bes tä tigen

2 . K r edite nts ch eidung durc hführ e n

2 . Kr e dit ents che idung gr ün

2 . Kr e dit ents che idung zue rs t gra u; w ird z u g rün

2 . Kr e ditent s ch eidung zue rs t gr au; w ir d z u rot, w obe i La ufze tt el be nötigt w ird

2 . Kr e dit ents ch eidung zue rs t gra u; w ird z u r ot, w obe i La ufze tte l nicht be nötigt w ird

2 . Kr e dit ent s ch eidung r ot, w ob ei La ufze tte l be nötigt w ird

2 . Kr e ditent s c heidung r ot, w obei La ufze tt el nicht be nötigt w ird

2 . Kr e dit ent s ch eidung a ufgr und fe hlende r U nte r la ge n nicht dur chführ ba r

B e s te lls u p p o r tfü re C -S h o p o d e rP a r tn e rb a n kd u r c h fü h re n[A U .1 0 0 .0 5 _ B e s te lls u p p o rt(S h o p ,P B )]

F ra g e nzue C g e h e n e in

F ra g e nz ue C g e h e n e in

P r o d u k tb e ra tu n g d u r c h fü h r e n


A u s k u n ftü b e rD a te n g e b e n D o k u m e n t/In fo rm a tio n g e h te in


A n a n d e reA b te ilu n g v e r w e is e n

D o k u m e n t/In fo rm a tio n g e h te in


P r o d u k tp o rtfo lio v o rs te lle n



S y s te m e n ts c h e id u n g e r k lä r e n



B e s ta n d s k u n d e n b e r a tu n g d u r c h fü h r e n

R K V -B e ra tu n g d u r c h fü h r e n



K r e d ita b lö s u n g b e r a te n


A u s k u n ftü b e r K u n d e n s itu a tio n g e b e n D o k u m e n t/In fo rm a tio n g e h te in


B e r a tu n g z u B e s te llu n g d u r c h fü h re n

A n w e n d u n g s b e r a tu n g d u rc h fü h r e n D o k u m e n t/In fo rm a tio n g e h te in


P r o z e s s b e r a tu n g d u r c h fü h r e n D o k u m e n t/In fo rm a tio n g e h te in


P ro d u k tm e r k m a ls b e r a tu n g d u r c h fü h r e n


A llg e m e in eP r o d u k tb e r a tu n g d u rc h fü h r e n


Va ria nte „… “

Le is tungs baus tein eC B e ste llung und fr eige ben (B ri ef/Inte rnet) [ AU 1 00 .2 1 eC -Be ste llu n g p rüfe n un d freig eb en (B rie f/I nte rne t)] Te ilproz es s „… “

Te ilproz es s „… “

Va r ia nte „ …“

Va ria nte „… “

F o rm e lle /In h a ltlic h e P rü fu n gv o rn e h m e n


A u s k u n fts a rtk lä re n

A u sk u n ftsa rtk lä re n

Lei stungsba uste in B es tell te rmi n v ere inba ren [A U. 10 0. 09 B e stel lterm in ve re inba ren (G rünN ic ht

P ro d u k tb e ra tu n g g e b e n

R e c h e rc h e d u rc h fü h re n

A u fa n d e reQ u e lle v e rw e is e n

B e ra tu n gd u rc h fü h re n





S y s te m e n tsc h e id u n g m itte ile n

P ro d u kta u s w a h lb e ra t u n gd u rc h fü h re n


S y s te m e n tsc h e id u n g re c h e rc h ie re n


D o k u m e n tie re n

Leis tungsba ustei n eC B es te llung und frei gebe n (S hop/P B ) [A U 10 0. 20 e C -B est ellu ng prü fen u nd fre ige be n (Sh op /P B)]


Lei stungsba uste in U nterl age n digital is ier en

A u sk u n fts a rtklä re n


R K V -B e ra tu n g d u rc h fü h re n




K re d ita b lö su n g s b e ra t u n gd u rch fü h re n


R e c h e rc h e d u rc h fü h re n

A u sk u n ftü b e rd ie K u n d e n s itu a tio n g e b e n



A n w e n d u n g sb e ra tu n g d u rc h fü h re n

A u sk u n fts a rtklä re n





P ro z e s s b e ra tu n g d u rc h fü h re n





P ro d u k tm e rk m a ls b e ra tu n gd u rc h fü h re n




SB S führ t D ruc k und V er sa nd durc h


D a te nre c h e rch ie re n

A u s k u n ftg e b e n

B e a u s k u n ftu n g d o k u m e n tie re n

Va ria nte „ …“

Figure 4. Modeling of the Process Landscape at the Bank Used for the Case Study: Example of Three Subprocesses with their Process Variants Extracted from the Underlying Complete End-to-End Banking Process Regarding a Credit Order


7


The bank followed the paradigm of continuous process improvement throughout the entire process landscape and thus had its own professional business process management team, which was responsible for the entire process management cycle (process strategy, process design, process implementation and execution and process monitoring). In this setting we had the opportunity to model, analyze and optimize the frequently used and standardized core banking business processes within the production unit, the service and support center unit as well as the shared services unit of the production department. Applying the newly designed PICTURE notation for the banking sector we were able to model all activities and processes without the necessity of further extensions, wherefore we did not do a second iteration of the design science research cycle regarding the construction of the semantic BPML for banks. An extract of our modeling effort can be seen in Figure 4. As many banks have similar processes and other banking products and services – generally speaking – use similar activities, we argue that our derived banking specific building block set may not be complete, but is very likely a satisfying solution. We recall that an optimal solution cannot be determined within a feasible amount of time and research done, as it is not possible to look at every banking case (in particular uncovering rare special services and activities in banks, which may need different building blocks apart from those we have found in our research).

Print Scan

Document / Information Comes In

It is possible to determine patterns of sequences of process building blocks which can indicate process optimization potentials. To illustrate this idea we have designed two patterns, we believe to be suboptimal in many cases if they are identified in processes (cf. Figure 5). A first pattern consists just of one building block (“Document / Information Comes In”) and one defined attribute ("Used Incoming Communication Channel via E-Mail / IT Application" = 0%). We claim that not getting documents or information electronically forces employees to use more time allocating the information to the responsible employee and that it costs additional time for employees to digitalize the incoming document if this shall be at least processed more efficiently (so electronically) in subsequent activities and processes. Hence, this simple pattern is a good indicator for improvement potential. The occurrence of this pattern of course can be detected automatically throughout the whole process landscape. Thus a first estimation can be given if there could be any value in investing in an external professional business service which automatically digitalizes documents, identifies keywords in the documents and routes the documents directly to the corresponding employee. In the second case we have defined another simple pattern – a media break – consisting of two building blocks (a print activity followed by a scan activity). This pattern could be interpreted in that way that a document is printed and maybe the same document is then scanned again to archive it into a different system. In this case we would have identified another pattern which should be avoided in processes. Just as the first pattern the number of occurrences or even instances of occurrences in specific processes could be determined automatically by defining a simple query or programming a simple database search algorithm (provided the tool for modeling in the PICTURE notation uses a database to store all process models).

Figure 5. Examples of Patterns Defined for Identifying Process Optimization Potentials

With this small demonstration of the abundant possibilities semantic business process languages provide us with in terms of analysis possibilities, we have shown that the PICTURE methodology works well within the boundaries of the case study for our defined analysis purposes and argue that there is a high chance that it will also perform well, for many but certainly not all different types of process-oriented analyses, provided that the information is modeled in a semantically analyzable way. EVALUATION: FINDINGS AND LIMITATIONS FROM THE MODEL APPLICATIONS IN THE REAL-LIFE CONTEXT

The adoption of the PICTURE method turned out to be very suitable for our modeling needs in the banking sector. We could identify a stable set of building blocks for describing core banking processes. The modeling of the building blocks turned out to be very simple due to the limited set of building block alternatives. However, the standardization of building blocks did not limit the individual naming of a block in the context of the process. For example, the actual building block “Create Document” could be renamed individually (e.g. “Create Payment Document”) although the underlying semantic remains the same. As one bank employee put it “we were able to describe our processes in a structured but still very flexible way without much knowledge about process modeling rules itself”. Although we did not measure the time that was needed for actually modeling processes in


8


comparison to modeling the processes with generic modeling languages such as EPC, we observed it to be much shorter. For an actual comparison of the modeling durations of processes with the help of EPC in comparison to modeling with PICTURE in public administrations see Becker et al. (2006). From various projects in the public administration, they came to the result that modeling with PICTURE is at least three times faster than modeling with any form of EPC notation. With regard to automatically analyzing business process models we consider the method to be very valuable. The process models are especially useful for automatically analyzing IT investment decisions, for process comparisons, and for IT implementation analyses (esp. for workflow management systems and document management systems because building blocks focus on information flows and document flows). In addition, we have done first research on using the PICTURE method for activity based costing in banking and also for human resource requirement planning and organizational roll documentations. For example, we are able to automatically derive job descriptions and required skills from the process models. Analyses can be done in terms of which IT system and IT mask knowledge is required, and how much and what client contact is necessary in order to fulfill the job. Furthermore, it is possible to analyze the usage of different contact channels (telephone, fax, letter, e-mail, or face-to-face contacts). With regard to compliance rules and new requirements from the financial crisis management, we were also able to identify the involvement in critical decisions that actually require a four-eyes principle. These analyses are very important in banks. Furthermore, we were able to retrieve information about processes and/or employees that are involved in physical money handling or money booking. We also used the method for identifying benefits of IT systems implementations. Regarding limitations, the PICTURE method so far explicitly focuses on core banking processes. We do not expect it to be able to model all types of processes apart from core banking processes. So far, we did not try to model supporting processes, found in many types of businesses such as human resources, accounting, etc. Even though we concentrated on core processes only, there is also the opportunity to adapt the language to the need of support processes as these are also highly administrative, structured and repetitive. As a first start, we have only applied the building block approach to critical core processes especially within the area of credit management. However, looking at a bank with a larger product base, it may be possible that not all processes can be modeled. Domain-neutral languages have the advantage, that they can be universally applied to any type of process and activity whereas the usage of our language is limited to the banking domain. PICTURE offers less degree of freedom in how to model. It is not possible to choose different abstraction levels or types of processes to be modeled. However, we believe that our approach is more sophisticated in terms of syntactic evaluations of processes as well as – even more important – in terms of semantic evaluations. PICTURE offers a much higher degree of analysis possibilities due to the encapsulation of semantics in attributes and building blocks. CONTRIBUTION AND OUTLOOK

With respect to our contribution to the body of knowledge we have provided a valid piece of design research according to Hevner et al. (2004)’s seven guidelines by creating an innovative and purposeful artifact for automated business process analysis in the banking sector (Hevner et al.’s Guideline 1 – Design as an Artifact). Due to legal and compliance restrictions as well as process reorganizations as a consequence of the financial crisis, our research proves to be very relevant to the domain of banking (Guideline 2 – Problem Relevance). We evaluated the actual adoption of PICTURE for banking with the help of a real project case study accompanied by informal argumentation and scenarios (Guideline 3 – Design Evaluation). Our approach solved the known problem of automated business process analysis in banking in a more effective, efficient and orderly manner (Guideline 4 – Research Contribution). By doing so, we have rigorously defined and formally represented an artifact, by adapting the domain-specific parts of a similar artifact. (Guideline 5 – Research Rigor). We have went through a rigorous search process by applying the design science research methodology (DSRM) (Peffers et al. 2008) and constructed a problem space and enacted a mechanism to find an effective solution (Guideline 6 – Design as a Search Process). As a result of our research we have communicated our findings to a technical and managerial audience in order to improve the modeling approach. Furthermore, with this contribution we enable researchers to extend our artifact and study it in an appropriate context. The practical description within this article allows an understanding of the utility of this approach and hence serves as a first blueprint for a commercial implementation (Guideline 7 – Communication of Research). In addition the application of the yet new design science research methodology (Peffers et al. 2008) within our research project is in itself a contribution to the philosphy of IS research debate. With respect to an outlook we suggest further field studies to monitor the use of our artifact in multiple projects and derive new areas of application from these studies. We also suggest further case studies for an in depth study of the artifact in different banking business environments and project settings regarding the type of analyses that are of interest to banks. As we have just made one case study looking at a specific type of business process analysis (for process optimization purposes) we do not claim that our building block or even method itself may need further extensions as the scope of the design problem to serve multiple analysis purposes is extended in detail. For example we can imagine that a generation of job profiles can be done from analyzing the process landscape based on use of the PICTURE notation. However regarding the purpose of identifying risks in processes we assume that it will not be enough to adjust the building blocks but maybe it will be necessary to adapt a whole new view (like the organizational model view or resource model view we can imagine a risk model view) which links different operational risk types in processes to single activities.


9


REFERENCES

1.

Becker, J., Algermissen, L., Falk, T., Pfeiffer, D. (2006) Reorganization Potential in Public Administrations: Identification and Measurement with the PICTURE-Approach, Proceedings of the 5th International EGOV Conference, Krakau, Poland, pp. 111119.

2.

Becker, J., Algermissen, L., Pfeiffer, D., Räckers, M. (2007) Local, Participative Process Modeling: The PICTURE-Approach, Proceedings of the 1st International Workshop on Management of Business Processes in Government, Brisbane, Australia, pp. 33-48.

3.

Blechar, M. J. (2007) Magic quadrant for business process analysis tools, Gartner RAS Core Research Note G00148777, Gartner, Inc., Stamford, CT, USA.

4.

Boekhoudt, P., Jonkers, H., Rougoor, M. (2000) Graph-based models, Proceedings of the WSES/MIUE/HNA International Conference, Montego Bay, Jamaica, pp. 227-235.

5.

Celino, I., de Medeiros, A. K. A., Zeissler, G., Oppitz, M., Facca, F. M., Zoeller, S. (2007) Semantic Business Process Analysis. Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management (SBPM) (Hepp, M.; Hinkelmann, K.; Karagiannis, D.; Klein, R.; Stojanovic, N. (Ed.)), 3rd European Semantic Web Conference (ESWC 2007), CEUR Workshop Proceedings, 251, pp. 44-47.

6.

Cocheo, S., Harris, K. (2005) Key Customers Today and Tomorrow. ABA Banking Journal, 97, 3, pp. 3-6.

7.

Drake, L., Hall, M., Simper, R. (2009) Bank modeling methodologies: A comparative non-parametric analysis of efficiency in the Japanese banking sector. Journal of International Financial Markets, Institutions & Money, 19, 1, pp. 115.

8.

Ferscha, A. (1994) Qualitative and quantitative analysis of business workflows using generalized stochastic Petri nets, Proceedings of the 9th Austrian-Hungarian Conference on Workflow Management: Challenges, Paradigms and Products, Linz, Austria, pp. 222-234.

9.

Gupta, D., Prakash, N. (2001) Engineering methods from method requirements specifications, Requirements Engineering, 6, 3, pp. 135-160.

10. Hammer, M., Champy, J. (1993) Reengineering the corporation: a manifesto for business revolution, Harper Business, New York, NY, USA. 11. Harmon, P., Wolf, C. (2008) The State of Business Process Management. BPTrends. 12. Hevner, A. R., March, S. T., Park, J., Ram, S. (2004) Design Science in Information Systems Research, MIS Quarterly, 28, 1, pp. 75-105. 13. IBM Business Consulting Services (2005) The paradox of Banking 2015. Achieving more by doing less. Somers. 14. Iochpe, C., Chiao, C., Hess, G, Nascimento, G., Thom, L., Reichert, M. (2007) Towards an Intelligent Workflow Designer based on the Reuse of Workflow Patterns. In: Proceedings Simpósio Brasileiro de Sistemas Multimídia e Web, Gramado,

Brazil. 15. Lin, Y. (2008) Semantic Annotation for Process Models: Facilitating Process Knowledge Management via Semantic Interoperability. Dissertation at the Department of Computer and Information Science, Norwegian University of Science and Technology, Trondheim, Norway. 16. Lindsay, A., Downs, D., Lunn, K. (2003) Business processes: attempts to find a definition, Information and Software Technology, 45, 15, pp. 1015-1019. 17. March, S. T., Smith, G. (1995) Design and Natural Science Research on Information Technology, Decision Support Systems, 15, 4, pp. 251-266. 18. Papastathopoulou, P., Avlonitis, G., Indounas, K. (2001) The initial stages of new service development: A case study

from the Greek banking sector. Journal of Financial Services Marketing, 6, 2, pp. 147-161. 19. Peffers, K., Tuuanen, T., Rothenberger, M. A., Chatterjee, S. (2007) A Design Science Research Methodology for Information Systems Research, Journal of Management Information Systems, 24, 3, pp. 45-77. 20. Pfeiffer, D. (2008) Semantic Business Process Analysis: Building Block-based Construction of Automatically Analyzable Business Process Models, Dissertation, Doctoral Thesis, University of Muenster, Muenster, Germany. 21. Ralyté, J., Deneckère, R., Rolland, C. (2003) Towards a generic model for situational method engineering, Proceedings of the 15th International Conference on Advanced Information Systems Engineering, Klagenfurt/Velden, Austria, pp. 95-110.


10


22. Ralyté, J., Rolland, C., Deneckère, R. (2004) Towards a meta-tool for change-centric method engineering: a typology of generic operators, Proceedings of the 16th International Conference on Advanced Information Systems Engineering, Riga, Latvia, pp. 202-218. 23. Simon, H. A. (1996) The Sciences of the Artificial, MIT Press, Cambridge, MA, USA. 24. Thom, L. H. (2006) A Pattern-Based Approach for Business Process Modelling. Thesis at the Universidade Federal do Rio Grande do Sul. Brasil. 25. Thomas, O., Fellmann, M. (2007) Semantic Business Process Management: Ontology-Based Process Modeling Using EventDriven Process Chains. International Journal of Interoperability in Business Information Systems (IBIS), 1, 2, pp. 29-44. 26. van der Aalst, W. M. P., ter Hofstede, A. H. M., Weske, M. (2003) Business process management: a survey, Proceedings of the 1st International Conference on Business Process Management, Eindhoven, The Netherlands, pp. 1-12. 27. van Hee, K. M., Reijers, H. A. (2000) Using formal analysis techniques in business process redesign, Business process management: models, techniques, and empirical studies, Springer, Berlin, pp. 142-160. 28. Vergidis, K., Tiwari, A., Majeed, B. (2008) Business process analysis and optimization: beyond reengineering, IEEE Transactions on Systems, Man, and Cybernetics, 38, 1, pp. 69-82. 29. Wilken, R., Maifarth, M., Lehmann, K., Ziggel, A., Ziganke, T., Borchert, A., Geske, M. (2008) Efficiency of Credit Processes in German Banks (in German). PricewaterhouseCoopers. Frankfurt / Main.


11

Developing a Business Process Modeling Language for the ... - uDoo

Developing a Business Process Modeling Language for the ... - uDoo

Suggest Documents

Business Process Modeling for developing Process ... - CiteSeerX

Modeling and Analysis of Business Process Compliance - uDoo

Modeling and Analysis of Business Process Compliance - uDoo

Extending a Business Process Modeling Language for Domain ...

Exploring the status quo of business process modelling ... - uDoo

Selecting a Process Modeling Language for

Selecting a Process Modeling Language for

Rule-Enhanced Business Process Modeling Language for Service ...

Towards a Business Process Modeling Technique for

Business Process Modeling for Successful

Extending BPMN for Business Activity Monitoring - uDoo

A Formal Semantics for the Business Process Execution Language for ...

Business Process Modeling Defined Business Process Model ...

Using a process modeling language for the design ... - Semantic Scholar

Gameful Business Process Modeling

DEVELOPING A HOLISTIC BUSINESS PROCESS MANAGEMENT ...

The REA-DSL: A Domain Specific Modeling Language for Business ...

Developing Business Process Monitoring Probes

A Business Process Design Language - CiteSeerX

A modeling language for 3D process plant layout ...

Multidimensional Data Modeling for Business Process Analysis

Conceptual Method for Flexible Business Process Modeling

Quality metrics for business process modeling - wseas.us

Modeling Control Objectives for Business Process Compliance