Lightweight Process Support with Spreadsheet-Driven Processes: A Case Study in the Finance Domain [original]

Lightweight Process Support with

Spreadsheet-Driven Processes: A Case Study in

the Finance Domain

Michael Stach1, R¨udiger Pryss1, Maximilian Schnitzlein1, Tim Mohring1,

Martin Jurisch2, Manfred Reichert1

1Institute of Databases and Information Systems, Ulm University, Germany

http://www.uni-ulm.de/dbis

2AristaFlow GmbH, Germany

http://www.aristaflow.com

{michael.stach,ruediger.pryss,maximilian.schnitzlein,tim.mohring,

manfred.reichert}@uni-ulm.de

[email protected]

Abstract. The use of process management technology constitutes a

salient factor for a multitude of business domains as it particularly ad-

dresses the flexibility demands of the digital enterprise. Still, spread-

sheet applications are more likely to be used in many scenarios in which

process management technology appears to be a more appropriate solu-

tion. Especially in the context of human-centric and knowledge-intensive

processes, spreadsheets are widely used, even if more business-tailored

applications exist. For example, financial service providers, like banks

or insurers, prefer spreadsheet applications for accomplishing their daily

business. However, this kind of usage reveals drawbacks when working

collaboratively based on the same spreadsheet document. To remedy

these drawbacks, we suggest the use of spreadsheet-driven processes,

which shall combine the advantages of traditional process management

technology with the ones of spreadsheets. Using a sophisticated scenario

from the financial domain, this paper shows how spreadsheet-driven pro-

cesses improve collaborative work, as required in the context of busi-

ness processes, significantly. Moreover, a proof-of-concept prototype is

presented to evaluate the approach in practice. Altogether, first results

indicate that spreadsheet-driven processes may be a promising technical

solution for everyday business involving human resources.

Keywords: human-centric, spreadsheet-driven process, financial field

1 Introduction

During the last decade, the support of human-centric and knowledge-intensive

processes has gained increasing attention [11]. In general, corresponding pro-

cesses face unplanned and complex situations, and their enactments depends

on the expertises and skills of the stakeholders involved. In particular, an un-

manageable set of factors makes it impossible for process stakeholders to always

2 Michael Stach et. al.

foresee all details of the tasks they shall perform and coordinate with other stake-

holders. Particularly, these processes comprise mutual phases of planning work

and performing it. Usually, in these phases, spreadsheet documents are used

to support the respective planning and working tasks. In addition, spreadsheet

documents are used to coordinate the tasks of the collaborating stakeholders.

Human-centric, knowledge-intensive processes of this kind can be found in do-

mains like, for example, healthcare or finance [5].

Due to regulatory changes in the financial field [12], recently, for many ser-

vice providers (e.g., banks), the support of human-centric, knowledge-intensive

processes is increasingly demanded; e.g., the risk reporting procedure provides

a scenario in which recent regulatory changes have generated high demands for

any IT solution. More precisely, the management of human resources is partic-

ularly challenging. For example, many decisions concerned with the evaluation

of risks must be accomplished by more than two experts. To coordinate such

decision making process with the help of IT solutions, in turn, often requires a

costly adaptation of existing software systems.

In a case study that we conducted in a bank, we learned that risk reporting

procedures are still mainly managed based on spreadsheet documents. Regarding

the considered bank in particular, and financial service providers in general, the

use of spreadsheet documents poses three major advantages:

–Spreadsheet documents are easy to manage, intuitive, and well established.

–Spreadsheet documents can be easily extended.

–Spreadsheet documents provide powerful off-the-shelf features (e.g., calcula-

tion functions, chart-based data visualization).

The large-scale use of spreadsheet documents, however, reveals many draw-

backs. For example, it is a challenging endeavor for all collaborating stakeholders

to work on the same spreadsheet document concurrently without generating un-

intended side effects (e.g., a corrupt document state). More specifically, avoiding

undesired side effects must be accomplished manually, which, in turn, is an error-

prone task. To remedy this drawback, while still using the well-known spread-

sheet metaphor, we propose spreadsheet-driven processes combining spreadsheet

with process management technology. Conceptionally, spreadsheet-driven pro-

cesses aim to preserve the aforementioned advantages of spreadsheet documents

on one hand, while avoiding unintended side effects in the context of collabora-

tive work on one and the same spreadsheet document on the other. Technically,

spreadsheet-driven processes are enabled by enhancing existing process manage-

ment technology in two respects. First, we tightly integrate spreadsheet applica-

tions with a robust process engine. Second, we adjust the data handling concept

used by common process engines in order to integrate spreadsheet documents

for handling data.

In the aforementioned case study, we presented the concept of spreadsheet-

driven processes to the stakeholders involved in the risk reporting procedure. As

our basic ideas were rated very positively, we realized a proof-of-concept pro-

totype enabling spreadsheet-driven processes based on the AristaFlow Business

Lightweight Process Support with Spreadsheet-Driven Processes 3

Process Management Suite [2]. This paper reports on three aspects. First, we

present the case study, and second, we introduce the concept of spreadsheet-

driven processes, and third, we give insights into the proof-of-concept prototype.

The remainder of the paper is structured as follows: Section 2 introduces the

risk management procedure, the reporting procedure as well as the risk-bearing

capacity procedure in detail. Note that this procedure constitutes a fundamen-

tal part of the overall risk management procedure. Section 3 then introduces

the concept of spreadsheet-driven processes. The proof-of-concept prototype is

presented in Section 4. Finally, Section 5 discusses related work and Section 6

concludes the paper with a summary and outlook.

2 Risk Management Procedure

This section presents the overall risk management procedure in general as well

as its risk reporting part in particular. Note that the risk-bearing capacity pro-

cedure this work is exemplarily focusing on constitutes one crucial part of the

risk reporting. Fig. 1 illustrates the risk management procedure. In a nutshell, it

consists of two parts. The first one is risk inventory, which comprise the strate-

gical tasks, whereas the second part is risk management, which comprises the

operational tasks. In the context of risk inventory, in turn, risks (e.g., deficits)

are identified and rated, while in the context of risk management they will be

handled. To be more precise, the risk inventory part consists of activities risk de-

tection and risk rating. In turn, risk measurement,risk reporting,risk controlling,

and risk monitoring constitute the activities of the risk management procedure.

At first glance, the risk management procedure seems to be of poor complexity.

In practice, however, its handling is challenging as the involved actors need to

be coordinated. For example, for almost all activities to be performed, a binding

of duties becomes necessary. Thereby, a binding of duty entailment constraint

expresses that two independent persons shall approve an activity.

Fig. 1. Risk Management Procedure

2.1 Risk Reporting Procedure

To give an idea of the complexity of risk management [10], Fig. 2 illustrates major

parts of the risk reporting procedure. First, overall risk reporting is accomplished

quarterly. Second, it comprises five sub-procedures: management summary,risk

4 Michael Stach et. al.

metrics,risk-bearing capacity,single risks, and issue management. Ideally, the

five sub-procedures can be executed in parallel in order to minimize overall ex-

ecution time. After completing all sub-procedures, a second phase of the risk

reporting procedure, consisting of seven activities, needs to be coordinated. This

second phase starts with the assembly of a preliminary version of the risk report

1 . For this purpose, documents created by the mentioned sub-procedures are

collected and compiled to a single document 2 , i.e., the risk report. Using the

compiled report, a consultation with the risk controller takes place 3 . As an

outcome of this consultation, the risk controller decides whether or not adjust-

ments to the risk report become necessary. If adjustments are required, activity

include additions is performed 4 . If no or no more adjustments are needed, the

risk report must be discussed with a responsible board member 5 . Again, it

needs to be decided whether additional adjustments are required 6 . After the

risk report is approved by the responsible board member, it is presented to the

executive board 7 . The resulting risk report is then dispatched to a specified

list of addressees 8 . Note that Fig. 2 only reflects a simplified version of the risk

reporting procedure. In daily business, there are many other interdependencies

to be considered. Nevertheless, the presented risk reporting procedure provides

a proper basis for discussing the risk-bearing capacity procedure.

Fig. 2. Risk Reporting Procedure (in Flowchart Notation)

Lightweight Process Support with Spreadsheet-Driven Processes 5

2.2 Risk-bearing Capacity Procedure

In the context of the aforementioned case study, we learned that the risk-bearing

capacity procedure (RBCP) [6] constitutes the one of the five risk reporting sub-

procedures for which the coordination efforts between the involved actors might

be significantly decreased when providing a proper IT support. Based on Fig.

3, we illustrate the specific aspects of the RBCP that require sophisticated IT

support not existing so far:

Fig. 3. Risk-bearing Capacity Procedure (in Flowchart Notation)

–In total, the activities from five different departments (cf. Fig. 3, D1-D5)

need to be coordinated, i.e., accounting,financial controlling,risk controlling,

reporting, and accounting of leasing company. Note that the involvement of

6 Michael Stach et. al.

the leasing company requires the consideration of different organizational

scopes.

–RBCP comprises challenging data collection tasks (cf. Fig. 3, D ) involving

numerous heterogeneous IT systems. Several of these tasks, in turn, require

the use of simulation tools (cf. Fig. 3, S ). As a drawback, currently, simu-

lation results need to be manually transferred to the relevant spreadsheet.

–Several RBCP parts show variations in practice. In Fig. 3, they are repre-

sented as sub-procedure activities (e.g., create monthly report).

–Data, exchanged between departments, needs to be approved (cf. Fig. 3, C ),

necessitating costly consultation activities.

–In the current practice, spreadsheets are used to coordinate data exchange

activities between the stakeholders involved in the RBCP. In turn, this re-

sults in spreadsheet-related drawbacks SRD1-SRD5:

SRD1 Spreadsheet management (i.e., to send, receive, store spreadsheets)

is manually organized through e-mails, file sharing, or phone calls.

SRD2 A sophisticated rights management for the use of spreadsheet docu-

ments is difficult to realize.

SRD3 Manual spreadsheet management hampers fine-grained rights man-

agement that allows distinguishing rights regarding the different parts

of a spreadsheet document. In practice, such a fine-grained rights man-

agement would be highly welcome in the RBCP context.

SRD4 Though spreadsheets constitute the primary data handling instru-

ment, manual data transfer between the spreadsheets and other systems

(e.g., the simulation tool used for activity calculate value at risk) is often

required.

SRD5 Recall that the risk reporting procedure, which includes RBCP as

sub-procedure, is executed quarterly (cf. Fig. 2). In practice, the order

of the execution activities and the used spreadsheets (i.e., how many

spreadsheets are actually used) of the risk reporting procedure vary

quarterly. Therefore, users want to operate with the same and only one

spreadsheet document. To cope with multi-user scenarios in the context

of single spreadsheets, a feature must be provided that enables a parallel

use in this context. Such feature, however, cannot be easily realized using

off-the-shelf spreadsheet applications.

3 Towards Spreadsheet-Driven Processes

Section 2 has confirmed that the RBCP requires considerable coordination ef-

forts and involves many stakeholders. Furthermore, RBCP activities are mostly

executed in the same sequence each quarter of the year. Considering these two is-

sues, the use of flexible process management technology for the RBCP is promis-

ing [14]. Even the use of contemporary process management technology for the

support of risk management procedures in general, and the RBCP in particular,

however, has revealed several drawbacks as reported by the stakeholders during

our case study. To obtain deeper insights into these drawbacks, we consider Fig.

Lightweight Process Support with Spreadsheet-Driven Processes 7

4. Assume the following scenario: The RBCP shall be executed by a process

engine [15]. Then, additional information is required to transform the RBCP

to an executable process. For example, data elements need to be defined and

assigned to the activities reading or writing them. In current practice, lots of

data from different sources need to be handled. Consider the data warehouse

rectangle shown in Fig. 4. It illustrates that the different sources to be handled

lead to a massive definition of data elements and their assignments to activities.

Furthermore, for each created data element, the rights of the involved stakehold-

ers, who may operate on these data elements, need to be defined. On one hand,

the use of process management technology allows for a technically sound repre-

sentation of the RBCP. On the other, the maintenance of the aforementioned

required data elements is still complex. Taking this into account, we propose to

combine advanced process management technology with spreadsheets (cf. Fig.

4). This integration follows three goals:

1. It addresses the discussed spreadsheet-related drawbacks of the current pro-

cessing of the RBCP (cf. Section 2.2). Concerning SRD1, for example, the

spreadsheet management is automated.

2. It copes with the data handling drawbacks discussed in this section, i.e., it

addresses the scenario depicted in Fig. 4, 1 .

3. It allows users to continue working in the spreadsheet environment.

Considering these goals, the approach applies the following concept:

–Data entry as well as data retrieval are performed using spreadsheets.

–The spreadsheet management (i.e., to send, receive, store spreadsheets) is

governed through a well-defined process as specified for the RBCP.

–Data handling of any supported business process is completely managed

through one and the same spreadsheet.

From a technical perspective, the following adaptations are required when

integrating existing process management technology with spreadsheets:

1. All activities reading or writing data are assigned to a spreadsheet document

(cf. Fig. 4, 2 ). Note that this requires an enhancement of the modeling com-

ponent as the structure of the spreadsheet must be obtained automatically.

2. The process engine executing a process needs to be adjusted for the use of

spreadsheets as well. In this context, three further adaptations are required:

(a) The process engine needs to be tightly integrated with a spreadsheet

application (e.g., Microsoft Excel). For example, the process engine needs

to be able to automatically run the spreadsheet application.

(b) The process engine needs to be able to use spreadsheets for data handling

as illustrated in Fig. 4, 2 .

matically provided solely to the assigned editor (i.e., the user processing

the spreadsheet). Further, it needs to guarantee that the spreadsheet (2)

never runs into a corrupt state (e.g., through a multi-user access). Fi-

nally, (3) a sophisticated rights management (e.g., cell protection) needs

to be implemented.

8 Michael Stach et. al.

Fig. 4. Data Elements in Spreadsheet-driven Processes (in Flowchart Notation)

When following such an approach, several advantages emerge:

1. An editor has read access to the entire spreadsheet while performing any

activity. In particular, every editor can obtain all data already entered by

other editors.

2. When processing an assigned activity, an editor may implicitly obtain the

current process status (e.g., through data that has not been entered yet, but

still has to be provided).

3. When processing an assigned activity, the spreadsheet application may com-

prise additional and useful features not provided by the process engine. For

example, the spreadsheet application can be used to visualize data based on

the supported charts.

In summary, we aim at adopting modern process management technology to

enable Scenario 2 (cf. Fig. 4) as replacement of Scenario 1 (cf. Fig. 4). We de-

note processes executed according to Scenario 2 as Spreadsheet-Driven Processes.

The mentioned case study revealed that the latter will foster RBCP support in

particular and risk reporting in general.

Lightweight Process Support with Spreadsheet-Driven Processes 9

4 Proof-of-Concept Prototype

This section illustrates the proof-of-concept prototype we implemented in order

to enable the Spreadsheet-Driven Process as such as the one supporting the

RBCP. The prototype was realized with Spreadsheet Router, a software toolset

recently released by the AristaFlow Inc.. The toolset, in turn, is based on the

AristaFlow Business Process Management Suite [2]. Due to the lack of space,

only selected features of the proof-of-concept prototype are presented. Figs. 5 and

6 show selected screens of Spreadsheet Router. Fig. 5 illustrates a screen during

the creation of the spreadsheet-driven process supporting the RBCP, while Fig.

6 illustrates a screen when executing the created process. Specifically, Fig. 5

shows one of the three configuration steps required to create the spreadsheet-

driven process for the RBCP. To be more precise, the screen shows:

1 A structured activity list: Based on this list, process activities may be

created. In addition, within this screen one may obtain the entire process

view of the modeled activities (see bottom of Fig. 5).

2 Spreadsheet area: Using this area, spreadsheet parts (i.e., so-called spread-

sheet areas) of the document can be assigned to the process activities.

3 Resource assignment: Using this area, it is specified which editors get

the right (e.g., specifying roles) to perform a particular process activity; i.e.,

getting the right to access an area of the spreadsheet in the context of the

specified process activity.

Fig. 6 depicts a screen during the execution of the RBCP process. In particu-

lar, it shows a form for the activity check core capital & capital requirements (cf.

Fig. 5. Spreadsheet-driven Process Creation

10 Michael Stach et. al.

Fig. 6. Spreadsheet-driven Process Execution

Fig. 6, 1 , 2 ). Currently, this activity was processed by an editor through the

use of the spreadsheet application. If the editor wants to again change already

processed data, he or she must start the spreadsheet application again with the

button shown in Fig. 6 at position 4 . Note that in the presented case the spread-

sheet area consists of four table cells (cf. Fig. 6, 3 ). Furthermore, Spreadsheet

Router provides a process-oriented view, e.g., to monitor the current execution

status of the process (see the bottom of Fig. 6).

Overall, we realized a proof-of-concept prototype with the Spreadsheet Router

that supports all features presented in Section 3. When using the prototype in

practice, the editors demanded another feature that allows assigning process

activities to a presentation tool (e.g., Microsoft PowerPoint). Such feature would

enable them, for example, to easily create presentations for the management

board. Altogether, the presented approach offers proper IT support of the risk-

bearing capacity procedure within a bank. Currently, we realize other parts of the

risk reporting procedure as spreadsheet-driven processes. Finally, a limitation of

the prototype is discussed. Therefore, recall the discussed case study (cf. Section

2) in which we revealed five spreadsheet-related drawbacks (SRD1-SRD5). The

realized prototype provides features that address SRD1-SRD4. A feature that

addresses SRD5, in turn, is currently not provided. Therefore, we work on this

issue for the second version of the prototype.

5 Related Work

Three categories of related work need to be discussed in the context of this

paper. First, there are approaches that apply process management technology

to support activities for financial service providers. For example, [16] discusses

Lightweight Process Support with Spreadsheet-Driven Processes 11

performance issues of business processes in the context of ITIL processes, whereas

[8] deals with the re-engineering of business processes in an international bank.

Furthermore, there exist approaches that refer to financial scenarios in order

to identify the characteristics of the underlying business processes [7]. Overall,

the discussed approaches neither focus on human-centric, knowledge-intensive

processes in the financial domain nor on the support of risk reporting procedures.

Second, approaches have to be considered that deal with office automation

on one hand and spreadsheet-driven approaches on the other. Concerning the

first category, such approaches already exist for quite some time. For exam-

ple, in [3, 13] office automation approaches and their characteristics have been

introduced. In particular, these approaches focus on the dynamic changes of of-

fice environments [4]. Furthermore, these approaches also discuss the need of

workflows in the context of office automation and work distribution [9]. How-

ever, a tight integration of process management with spreadsheet technology is

not presented in more detail by these approaches. Concerning the second cate-

gory, many approaches exist in the context of information systems that apply

spreadsheet-driven approaches to support the paradigm of end-user program-

ming [1]. However, the use of spreadsheets as an advanced concept to perform

process activities as we do is not considered so far.

Third, there are commercial tools that support spreadsheet-driven processes.

Currently, the best match to this category constitutes the Microsoft Sharepoint

Portal Server, which allows defining a workflow and assigning spreadsheet doc-

uments to its activities. The goal of such workflows is to easily exchange an

document to coordinate procedures that particularly require the processing of

numerical data. However, parts of an spreadsheet cannot be directly assigned to

process activities with the standard features of the Sharepoint Portal Server.

6 Summary and Outlook

The paper presented an approach for the support of human-centric, knowledge-

intensive business processes in the field of financial services. Regarding these

processes, a variety of spreadsheet documents is used to cope with tasks and

their respective processes in everyday business. However, existing IT solutions

lack the combined support of spreadsheet technology with contemporary process

management systems as required in the context of the present scenario. We pro-

pose a novel approach that exploits the benefits of using spreadsheets to perform

process activities. Thereby, we illustrated the advantages of this approach in the

context of risk reporting procedures. The latter are crucial for many financial

service providers as regulatory requirements have been recently changed, but no

proper IT solutions exist. We further showed how the approach can be applied

to the risk-bearing capacity procedure as a fundamental pillar of risk report-

ing within a bank. Furthermore, we used the proof-of-concept prototype, which

was realized on top of the Spreadsheet Router to execute the risk-bearing capac-

ity procedure in terms of a spreadsheet-driven process. We consider the latter

processes as crucial when targeting at the support of human-centric, knowledge-