DECISIONWAVE

Embedding Collaborative Decision Making into Business Processes

Christoph Krammer and Alexander M

adche

Enterprise Information Systems, University of Mannheim, Mannheim, Germany

Keywords:

Group decision support systems, GSS, Communication support system.

Abstract:

DecisionWave is a platform to allow distributed teams to jointly take decisions within business processes.

The focus of this work is to provide the conceptual architecture and a prototype for a seamless integration of

communication support for group decisions into existing business processes within operational information

systems. The DecisionWave system can then be used to document the decision process and generate tem-

plates for future decisions of the same type. Together with the architecture, we built a prototype using the

salesforce.com CRM system and the Google Wave communication infrastructure.

1 INTRODUCTION

The structuring of decision-making processes is an is-

sue each organization has to face. Despite the effort

taken to automate these processes and the informa-

tion ﬂow within them, the majority of decisions is still

taken manually with little tool support. This means

that the decision owner has the full responsibility to

ﬁnd the correct participants and information needed

to take the decision in a way that leads to success for

the organization.

This approach has several important drawbacks.

At ﬁrst the decision process is often intransparent to

others not involved in the actual decision. The only

information that is usually preserved is the decision

itself. The way that led to the decision, the infor-

mation about data taken into account or other people

who were consulted is lost. The second aspect is that

new participants of decision processes are costly to

introduce to this way of decision making. As there is

no explicit documentation of previous decision paths,

process rules have to be either explicitly formulated in

company policies or given personally from employee

to employee. Third, there is a high effort needed to

include information to support the decision. With

current systems, data needs to be manually extracted

from the system and manually sent to another person

who has to take care about the handling, visualization

and interpretation. Especially the data handling will

eventually lead to compliance problems. Whenever

data is manually taken from one system and trans-

ferred into another, e.g. E-Mail, the control over the

data is lost, security and data privacy issues arise.

Our usage example is taken from a business pro-

cess within the customer relationship management

(CRM) domain. It is a common task on the tactical

management level to discuss the sales target ﬁgures

for a given account and a given period of time. This

decision process requires at lot of data from differ-

ent systems like the CRM system itself, general sales

and product data from an enterprise resource planning

(ERP) system, additional data from an existing data

warehouse, and in some cases external data like mar-

ket forecasts from third party providers.

While models that support taking decisions as a

group already exist, they either suffer of acceptance in

practice or lack the necessary support of critical fea-

tures (Arnott and Pervan, 2005; Kaplan and Carroll,

1992). In actual group decision support systems that

are build on existing theories, seamless integration is

not of major focus (Lee, 1990).

To support decision processes within organiza-

tions, we propose a conceptual architecture that em-

beds a decision support platform – the DecisionWave

– into an operational information system (IS). The lat-

ter is thus enhanced with communication, documenta-

tion, and analysis capabilities. We focus on seamless

integration of the communication space into the exist-

ing user interface of the operational IS to simplify the

adoption of the new features and increasing produc-

tivity. In addition we present our prototype within the

salesforce CRM system where the communication in-

frastructure is based on Google Wave. With this pro-

totype we can show how decision processes can be

232

Krammer C. and Mädche A. (2010).

DECISIONWAVE - Embedding Collaborative Decision Making into Business Processes.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Artiﬁcial Intelligence and Decision Support Systems, pages

232-237

DOI: 10.5220/0002899302320237

 SciTePress

supported by adding structure and additional informa-

tion to the process. The prototype is also capable of

capturing the course of the decision process.

The remainder of this work is structured as fol-

lows: Section 2 gives an overview of theoretical work

in the area of decision-making and existing support

systems. Section 3 describes the conceptual architec-

ture of our system, the components needed, and the

integration aspect. In Section 4 we describe the pro-

totype implementation and give a distinct usage ex-

ample of the whole system. Finally, Section 5 gives a

conclusion and further research questions in regard to

our framework.

2 RELATED WORK

The model we describe here is part of the group

decision support systems (GSS) domain. A GSS

”combines communication, computing, and deci-

sion support technologies to facilitate formulation

and solution of unstructured problems by a group

of people” (DeSanctis and Gallupe, 1987). GSS

are part of the area of Decision Support Sys-

tems (DSS). Within this research ﬁeld, systems

are commonly classiﬁed by their major focus into

ﬁve categories: Communication-driven, data-driven,

document-driven, knowledge-driven, and model-

driven. In terms of scope, enterprise-wide DSS op-

pose the smaller desktop DSS (Power, 1997).

Within the GSS domain, various theories can be

applied to explain the usage of the system by its users.

The adaptive structuration theory emphasizes that the

spirit of a system – among other factors – has a strong

inﬂuence on its usage (DeSanctis and Poole, 1994).

The task/technology ﬁt theory can be applied to group

support systems in general to gain knowledge about

the technology requirements for different types of

tasks (Zigurs and Buckland, 1998). Generally it can

be stated that there is a strong relationship between

system capabilities and system survival in the GSS

area (Huber, 1984). Additionally, the Technology Ac-

ceptance Model has inﬂuenced decision support re-

searchers in their explanations of user behavior (King

and He, 2006).

Most of the theories in this area present some ar-

guments for a contingency theory of GSS, stating that

the actual beneﬁts are dependent of the environment.

Based on those theories, various studies of GSS have

been performed in the last 20 years (Fjermestdad and

Hiltz, 1998). But since its peak in 1994, the num-

ber of publications in the area of Decision Support

Systems (DSS) is falling. This was seen as an indica-

tor for the lack of practical relevance of stand-alone

DSS (Arnott and Pervan, 2005). To overcome prob-

lems like user acceptance, our approach is focused on

seamless integration.

Starting at the end of the 1980’s, several tools for

supporting communication in group processes were

proposed and scientiﬁcally examined. Examples are

the ConversationBuilder tool (Kaplan and Carroll,

1992) and SIBYL (Lee, 1990). But the focus of these

existing approaches is to support generic processes in

standalone systems, we propose an approach that is

focussing on the additional value created by integrat-

ing the GSS to an existing operational IS to support

decisions that are speciﬁc to this environment.

In practice, only basic support of group decisions

through general communication support gained wider

acceptance. While tools like groupware are offered

by a variety of different vendors, advanced tools that

support aspects of decision-making processes in par-

ticular remained small in attention (Bandyopadhyay

and Paul, 2007).

3 CONCEPTUAL

ARCHITECTURE

In Figure 1 we present the conceptual architecture of

our approach. It contains the following components:

First, the DecisionWave platform itself provides the

communication infrastructure and other services that

are needed to support the decision processes. Second,

the Operational Information System, e.g. customer

relationship management, which we presume already

existing.

This operational system serves as the entry point

for user interaction and holds business objects and

process information that may be relevant for a speciﬁc

decision task. In addition, external data & services

can be connected to the DecisionWave. As depicted,

the user interaction will only take place in the opera-

tional system, the DecisionWave platform is embed-

ded transparently.

In the following subsections, the individual com-

ponents will be explained in further detail. For the al-

ready existing components prerequisites will be given

for their integration; for the DecisionWave platform,

the major design rationale will be illustrated.

3.1 Operational Information System

The integrated decision support system we propose

is embedded into an a priori existing operational in-

formation system. This system serves three major

purposes: First it contains data management, which

DECISIONWAVE - Embedding Collaborative Decision Making into Business Processes

233

DecisionWave Platform

Operational Information System

Basic Communication Infrastructure

Connectors

User Interfaces

DecisionWave

Session

Process Management

External

Data

Data Management

External

Services

Embedded Services &

Templates

Log Analysis

Log Engine

Figure 1: Conceptual architecture of the DecisionWave platform and its integrations.

gives access to business objects that are needed dur-

ing any decision task. Second it contains some kind

of process management engine that is able to create

and maintain tasks and/or process steps that are as-

signed to individual users or groups. Third, it pro-

vides one or many user interfaces that can be extended

to include the collaboration features from the Deci-

sionWave platform (for details on this integration, see

Section 3.2).

The ﬁrst component – the data management – of

the operational IS is responsible for the storage and

access to data that is needed within the system. This

covers internal databases or other data sources that

are used by the existing parts of this systems. It also

covers the data required for the process management

module, i.e. workﬂow deﬁnitions, role assignments,

and responsibilities. The internal data is used to ini-

tialize the DecisionWave session according to a cho-

sen process template.

Process management is responsible for the assign-

ment of process steps, i.e. workﬂow or other tasks,

to individual users or groups. If a task is preclassi-

ﬁed as a decision task, the process management will

initialize a DecisionWave session to take the decision

and document the decision-making process. It also

may include some business rules to choose a template

for the decision which will determine additional par-

ticipant and data requirements for a speciﬁc decision

task. As far as needed for the integration, all relevant

aspects of the business logic are part of either the data

or process management. Interactions with other parts

of the operational system are not necessary.

Finally user interfaces are provided to give the

users access to the DecisionWave session. An opera-

tional IS may contain different user interfaces for cer-

tain types of users or display devices. The mandatory

prerequisite in terms of user interface technology is

the possibility to integrate the DecisionWave interface

needs to the operational IS seamlessly. This seamless

embedding of the decision support tool into a system

already in use removes a media break and may lower

resistances to its usage.

3.2 DecisionWave Platform

The DecisionWave platform provides the services that

are needed for the group communication and decision

support. Its foundation is the basic communication in-

frastructure that offers foundational services like mes-

sage transmission and storage. On top of these ba-

sic services, three modules are realized. The log en-

gine and log analysis modules deal with the recorded

decisions. Embedded services and templates provide

structural elements that are needed for speciﬁc types

of decisions. Finally connectors are used to include

internal and external data to the DecisionWave ses-

sion and access external services that may provide so-

lutions or support for clearly deﬁned subtasks.

The basic communication infrastructure covers all

aspects of interpersonal and group conversation. Ad-

ditionally, both synchronous and asynchronous com-

munication will be needed. In reference to existing

models of communication systems, depending on the

given task, both channels and platforms need to be

provided. A channel, e.g. instant messaging, hereby

is meant as a communication method based on the

write by many, read by few approach, a platform, e.g.

an intranet site, is following the write by few, read by

many approach (McAfee, 2006).

To store all data related to the decisions, the plat-

form has a log engine. It captures details about a de-

cision task, the communication between decision par-

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

234

ticipants, the data and services added to the process,

and the ﬁnal outcome. This data is stored in raw for-

mat for analysis. In addition, the data can be used for

later reference in case of process errors or serves as

compliant archive of decisions. The data analysis is

than carried out by the log analysis module. Target of

the log analysis phase is to extract patterns of commu-

nication, data, or services from decisions of the same

type. If patterns are found, they are transferred into a

template for this particular decision task.

The embedded services and templates engine is

then responsible for these templates. Templates can

be automatically selected by the process management

component of the operational IS when initializing a

DecisionWave or manually by a participant. Tem-

plates will contain additional participants who can be

invited to a decision, data connections to both internal

and external data sources, and predeﬁned services for

problem structuration and process decomposition.

To access both data from the operational IS, i.e.

internal data, and data from other sources, i.e. exter-

nal data, the DecisionWave platform contains connec-

tors. Connectors are interfaces to other systems that

access and visualize data. To achieve the greatest ﬂex-

ibility, a variety of data sources need to be integrable.

Additionally, external services can be included in a

decision task, e.g. to solve certain clearly deﬁned sub-

tasks. If for example complex mathematical calcula-

tions are needed within a given decision, these calcu-

lations can be done within the DecisionWave session

by calling an external service.

The connector is also used to transfer information

from the DecisionWave back to the operational infor-

mation system. The task is the bridging element be-

tween the operational system and the DecisionWave

platform and enables associating the collected data

with business processes.

4 PROTOTYPE

IMPLEMENTATION

We implemented an end-to-end scenario as a proto-

type of the DecisionWave platform with the compo-

nents mentioned earlier. This prototype will focus on

the seamless integration for the user and the complete

capturing of communication data. As perceived use-

fulness is a major factor for user acceptance of com-

munication systems, modern technologies are neces-

sary for seamless integration (Lai and Turban, 2008).

4.1 Technical Architecture

The prototype was implemented on two existing sys-

tems. The salesforce CRM software was chosen as

operational information system, Google Wave serves

as basic communication infrastructure (Google, 2010;

salesforce.com, 2010). Both were chosen because of

their rich API and extensibility. By choosing web-

based technologies both for the operational IS and the

basic communication infrastructure, the implementa-

tion time was kept to a minimum. As both systems are

available in a Software-as-a-Service delivery model,

no time was spent on support tasks like hardware

setup or software installation.

The salesforce CRM system includes the three op-

erational information system parts described in Sec-

tion 3.1: User interfaces, process management, and

data management. The data management includes

an object-relational database which can be accessed

with SOQL, which is a subset of the SQL standard.

These objects can be accessed via APIs form external

clients, which is relevant for the connector of the De-

cisionWave platform. Data objects can be extended

with custom ﬁelds or new objects can be created to

store additional data.

The process management consists of both task

management capabilities and a customizable work-

ﬂow engine. The task management component allows

to create tasks for individual users as well as group

tasks that are split and assigned to multiple users. The

workﬂow engine is able to react on system events and

create tasks for individual users or groups. The re-

sults of these tasks may then inﬂuence the workﬂow

progression.

Finally, the main user interface of salesforce CRM

is completely web-based and optimized for standard

personal computer screens. There exist additional

user interfaces, e.g. for mobile devices, but these will

not be covered in the given prototype. The user inter-

face is extendable by adding custom pages either to

existing screen layouts or by creating new screen lay-

outs with one or more pages.

The Google Wave platform forms the basic com-

munication infrastructure. Google Wave is an on-

demand collaboration infrastructure that is based on

the open-source Wave Federation Protocol (Google,

2009). It allows both synchronous and asynchronous

messaging with multiple participants. All messages

within one thread, here called Wave, can be edited by

any participant and all changes are logged for later

playback. This makes Google Wave a powerful basis

for the DecisionWave platform.

It already fulﬁlls the basic requirements of the log

engine as all data entered to the system is stored toge-

DECISIONWAVE - Embedding Collaborative Decision Making into Business Processes

235

Figure 2: Screenshot of the prototype implementation with salesforce CRM and Google Wave.

ther with metadata like author, timestamp, and mes-

sage context. The Wave Federation Protocol supports

two different ways of connectors: Robots and gad-

gets. Robots are participants of a certain Wave and

react to events. Technically, robots are web applica-

tions that are called by the Wave server if a certain

event is raised. The robot registers for certain events

when added to the Wave. Gadgets are JavaScript-

based parts that display information to the Wave’s par-

ticipants. The state of each gadget is part of the Wave,

so if any participant alters the state of the gadget, e.g.

by adding new data, this update is visible to all other

participants at once.

4.2 End-to-end Usage Scenario

We will now give a example on how the system can

be used to support an actual decision-making process.

Given the scenario from the introduction, we have a

regional sales manager who is responsible for the task

of assigning sales targets to the customers in his area.

This task was created in the salesforce CRM system.

As he cannot take this decision alone, he decides to

start a new DecisionWave session. This session is

based on a task template, in this case a general de-

cision task template as there is currently no template

for sales target decisions. The template contains a list

of default data and participants for this type of task.

The DecisionWave robot is a default participant for

all sessions. All this is done within the standard task

layout of salesforce CRM.

The regional sales manager may now add informa-

tion or statements to the session or may ask the robot

to provide additional data. The user interface for this

is shown in Figure 2. In this case, he asks the robot to

provide information about the associated account and

the overall sales targets for his region. The robot ac-

cesses the data from salesforce CRM via its connector

and contributes it to the session. Additionally, a map

is rendered showing the location of all customers in

the current region. The map also contains additional

information like the sales values from previous years.

All this data is relevant to the decision as the overall

regional targets have to be distributed to the accounts.

To provide additional insight on the customer, the

sales manager may decide to add the key account

manager to the DecisionWave. When a new partic-

ipant is invited, the robot creates a new task within

the salesforce CRM process management engine for

this participant with the same DecisionWave session

assigned. This way, the existing methods of notiﬁ-

cation can be reused when adding participants. The

key account manager may now access the session and

contribute to the discussion of the actual sales target.

After all necessary information and arguments are

entered to the session, a voting gadget can be used

by the participants to ﬁnalize the decision. After the

voting is closed, the robot may return the result to the

salesforce CRM process management triggering new

process steps that follow the sales ﬁgure determina-

tion step. The session is archived for later reference.

When several decision of the same type occurred,

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

236

a template may be created. In the given example, the

template could contain the information that the key

account manager of the customer needs to be part of

the decision. When this template exists, the robot will

invite the key account manager to the discussion at the

moment the DecisionWave session is established. In

the same way standard data can be included in tem-

plates that will be provided at the beginning of the

session.

5 SUMMARY

The DecisionWave platform supports decision-

making processes within operational information sys-

tems. It is seamlessly integrated into existing systems

and allows both efﬁcient access to various kinds of

data for running tasks and complete documentation

of decision processes for future analysis. The users

that take a group decision can access all relevant in-

formation in one place. Our approach is suitable to

overcome the difﬁculties in current decision-making

process structures.

The prototype we built realizes the architecture

on the basis of the salesforce CRM application and

Google Wave as communication infrastructure. It

provides communication support, log engine and

analysis, embedded services, and connectors. Infor-

mation from the salesforce CRM system can easily

be enriched with external services like the map ser-

vice. Our end-to-end implementation shows that the

technology to support decision processes is at hand

and the given architecture can be realized with little

time and effort.

Future research on this topic will cover two ma-

jor areas: At ﬁrst the model and the prototype will

be extended with additional methods of integrating

data and service access. For example current com-

pany news or publically available information about

ﬁnancial standings will be relevant and helpful in the

given situation. In addition, the robot will be extended

to allow more natural ways of interacting by not only

reacting to speciﬁc keywords but to commands in nat-

ural language. This would allow the participants of a

decision to access data and services in the most con-

venient way.

The second area is an evaluation of the architec-

ture using the prototype. To do this, a reference im-

plementation will be used in both a real-world case

study together with an actual salesforce CRM cus-

tomer and within lab experiments. With this data, de-

tailed analysis of decision processes can be conducted

and the automatic creation of templates can be real-

ized.

Common goal of these two areas is the extraction

of knowlegde from decision processes with decision

mining technologies. With this knowlegde, decision

processes can be further supported or – to some ex-

tend – even automated.

REFERENCES

Arnott, D. and Pervan, G. (2005). A critical analysis of deci-

sion support systems research. Journal of Information

Technology, 20(2):67–87.

Bandyopadhyay, K. and Paul, S. (2007). User acceptance of

group support systems. In Proceedings of the 9th In-

ternational Conference on Decision Support Systems,

Kolkata, India.

DeSanctis, G. and Gallupe, R. B. (1987). A foundation for

the study of group decision support systems. Manage-

ment science, 33(5):589–609.

DeSanctis, G. and Poole, M. S. (1994). Capturing the com-

plexity in advanced technology use: Adaptive struc-

turation theory. Organization science, pages 121–147.

Fjermestdad, J. and Hiltz, S. R. (1998). An assess-

ment of group support systems experimental research:

Methodology and results. Journal of Management In-

formation Systems, 15(3):7–149.

Google (2009). Google wave federation protocol over

XMPP. http://www.waveprotocol.org/draft-protocol-

specs/draft-protocol-spec.

Google (2010). Google wave API.

http://code.google.com/intl/de-DE/apis/wave/.

Huber, G. P. (1984). Issues in the design of group decision

support sytems. MIS Quarterly, 8(3):195–204.

Kaplan, S. M. and Carroll, A. M. (1992). Supporting collab-

orative processes with ConversationBuilder. Comput.

Commun., 15(8):489–501.

King, W. R. and He, J. (2006). A meta-analysis of the tech-

nology acceptance model. Information & Manage-

ment, 43(6):740–755.

Lai, L. S. L. and Turban, E. (2008). Groups formation and

operations in the web 2.0 environment and social net-

works. Group Decision and Negotiation, 17(5):387–

402.

Lee, J. (1990). SIBYL: a tool for managing group design

rationale. In Proceedings of the 1990 ACM conference

on Computer-supported cooperative work, pages 79–

92. ACM New York, NY, USA.

McAfee, A. P. (2006). Enterprise 2.0: The dawn of emer-

gent collaboration. MIT Sloan Management Review,

47(3):21.

Power, D. J. (1997). What is a DSS. The On-Line Ex-

ecutive Journal for Data-Intensive Decision Support,

1(3):223–232.

salesforce.com (2010). salesforce.com developer API.

http://wiki.developerforce.com/index.php/Integration.

Zigurs, I. and Buckland, B. K. (1998). A theory of

Task/Technology ﬁt and group support systems effec-

tiveness. MIS Quarterly, 22(3):313–334.

DECISIONWAVE - Embedding Collaborative Decision Making into Business Processes

237