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 flow 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
find 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 first 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 figures
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 - Artificial Intelligence and Decision Support Systems, pages
232-237
DOI: 10.5220/0002899302320237
Copyright
c
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 field, systems
are commonly classified by their major focus into
five 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
influence on its usage (DeSanctis and Poole, 1994).
The task/technology fit 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 influenced 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 benefits 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 scientifically 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 specific 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 specific
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 first 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. workflow definitions, 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. workflow or other tasks,
to individual users or groups. If a task is preclassi-
fied 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 specific 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 specific 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 defined 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 final 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 predefined 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 flex-
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 defined 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 fields or new objects can be created to
store additional data.
The process management consists of both task
management capabilities and a customizable work-
flow 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
workflow engine is able to react on system events and
create tasks for individual users or groups. The re-
sults of these tasks may then influence the workflow
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 fulfills 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 notifi-
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 finalize 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 figure 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 efficient 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 difficulties 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 first 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
financial 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 specific 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 fit and group support systems effec-
tiveness. MIS Quarterly, 22(3):313–334.
DECISIONWAVE - Embedding Collaborative Decision Making into Business Processes
237