Business goals and task modeling – a framework and a design ...

climbmoujeanteaΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 4 χρόνια και 7 μήνες)

118 εμφανίσεις

Business goals and task modeling

a conceptual framework

Gerrit C. van der Veer 1), Maria Wimmer 2), Martijn van Welie 1)

1) Vrije Universiteit, Amsterdam, Holland

email: {gerrit,martijn}

2) University of Linz, Austria


Task modeling p
lays an important role during the first phases of design. Groupware Task Analysis (GTA) [Veer96]
provides a method for task modeling. The method makes a distinction between a model of a current work situation
(Task model 1, TM1) and a model of the future w
ork situation when the technology to be designed will be
implemented and installed (task model 2, TM2).

Both TM1 and TM2 describe the work situation in terms of different views: (a) the agents (people, organization,
machine agents, roles); (b) the work (go
als, tasks, actions, procedures); and (c) the situation (objects, environment,
history of the situation).

Each of these views allows representation of relations between different concepts that describe the task world and
work situation. GTA is developed ba
sed on a conceptual framework that has been described before, but which is still
being elaborated and expanded.

In our paper we intend to focus on the relation of the work situation to high
level business goals. This is of major
importance when the design
is proceeding from TM1 (and analysis and description of the current world) to TM2 (the
envisioning and early specification of the New World where the technology
designed will be incorporated). In
this important phase of design the client of design wi
ll bring in his requirements, which will have to feature in the
change from TM1 to TM2.

In this phase it is necessary to:

assist the client in relating his requirements to the major business goals of the client’s organization in order for the
designers to

understand the background of the requirements and their relation to high level tasks and goals.

assist the client in interpreting the designers’ early solutions (which are at a high level of task modeling) in terms
of the business goals.

Recently we have
been extending GTA to incorporate the concept of business goals, and to represent the relationship
of these goals with the task structure, as well as with the structure of organization and roles. We have also included
this concept into the model used by ou
r task analysis tool

In this paper we will elaborate on the purpose of incorporating business goals in task modeling, and show our
solution in terms of a conceptual framework.

: GTA, Task analysis, organizational factors, high
level busine
ss goals, Groupware


Groupware Task Analysis (GTA) in its initial version is a design model and method, which aims at modeling the task
domain for Groupware in respect to user interface design of these systems. It starts design from the current

situation with an emphasis on the use of ethnography in the analysis phase, and then improving the task model
iterative via enlarging the model, evaluating the improvements and doing further analysis in respect to the design
model. A weakness of this

GTA approach is that it has a limited viewpoint on the organization as it considers only a
part of the organization unit (the workplace of a group).

The importance of systems supporting coordination, collaboration and decision making between and within di
working groups is drastically increasing, especially in the area of office automation. CSCW is the paradigm claiming
for these facilities in an organization
wide environment. For the success of such systems the early stages of systems
design are of

high importance. Therefor this work discusses the general structure of the interactive system to
designed and its place in the organizational environment. Components and interaction interfaces of the cooperative
work arrangement (system and organizatio
n level) as well as interrelations between different components are made
explicit. The business process and workflow models used in Business Process Redesign/Reengineering (BPR) and
Workflow Analysis (WFA) are adapted to describe such organizational factor
s and dynamic behavior.

The extended GTA approach provides the ability to represent different kind of processes and thereby gives the
designer a better overview of the task world. Furthermore, it contains concepts to model organizational factors like
level business goals, formal and informal communication and authority structures to describe overall
dependencies and relations. It also allows representing dynamic behavior as it includes time aspects and event
occurrences. The extended GTA offers a ba
sis for better prototyping as it provides holistic design approach from an
wide point of view thereby allowing multiple views as needed in Groupware.

Groupware Task analysis with a broader perspective

Task Analysis (TA) is the investigation of

studying what people do when they carry out tasks. Doing task analysis
involves more than simply observing how people perform tasks. It also consists of developing a theory of tasks,
techniques of data collection, a method of analyzing tasks and a represe
ntational framework for constructing task
models [cf. Diap89, Johns92a]. It provides a detailed task description of an extant human
machine system, thereby
using methods like ethnography, heuristics, analytic, sociological, or psychological methods such as

Task Analysis (HTA), Task Action Grammar (TAG), Task Knowledge Structure (TKS) for gaining insight into
structuring knowledge and for describing it. It proposes recommendations for design or modification that optimize
the system to
d by projection from the task description.

Groupware Task Analysis (GTA) is derived from TA and it put the main focus on users and their workplaces, thereby
indicating three different activities as described in the following [Veer96]:

analyzing the ‘curren
t’ task situation and mapping it to task model 1

specifying a task situation for which information technology is to be designed (future task situation, task model 2)

specifying the semantics of the information technology to be designed, the conceptual mode
l (the user’s virtual
machine (UVM)) for the user interface.

There is an important difference to notice: the UVM models the detailed solution in terms of technology, whereas
task model 2 focuses on the task structure and work organization.

Design has to
start with describing the world using an organization model (task model 1) as it is basis. Initially it
seems to be an easy goal to describe the tasks as they are performed at present time. Yet, in practice, analyses show
that this “obviously easy goal” be
ars a lot of intrinsic pitfalls, obstacles and hardship. In the original attempt of GTA
knowledge concerning the task is derived from two sources:

Main insight into the task stems from the users’ knowledge as the primary source. This is an analytical way m
concerned with the task from the individual point of view.

Additional insight is gained in studying work practice within the organization unit by using ethnographic analysis
methods. In studying work practice, the concept of an individual task is sur
passed and aspects of collaboration
and group behavior are brought in.

The model of the future work situation (task model 2) is a prospective one and so directed to a future work practice
that may not yet be in use. This model might reflect a rather diffe
rent organization of the work processes, which is
quite dissimilar to the current business. Further on, additional work duties, technical and organizational constraints,
as well as the specific wishes of the clients have to be taken into consideration and
might result in novel task
organizations. In task model 2 design decisions are therefor made based on problems and conflicts re
presented in
model 1, in combination with important parameters as formulated in interaction with the customer of the design (the


GTA uses a concept of different viewpoints. The basic concept of GTA comprised the following domains:

A concept of organization of people distinguishing between actors (individual persons) and roles (classes of
actors). The organization refers t
o the relation between actors and roles in respect to task allocation and it
describes the human structure in the community of practice.

Work can be split into different tasks, whereas a task structure describes the various levels of complexity of tasks.

unit task consists of different actions, which have to be executed.

Situation describes the environment and the objects. The object description includes an analysis of the object
structure. The environment includes actors with roles, conditions for task p
erformance, relevant objects, and
artifacts like information technology that are available for subtask delegation.

To come up to the requirements for design of interactive systems, the original GTA approach may fail, because it
uses limited viewpoints as i
t considers only a part of the organization unit (the workplace of a group) and it uses less
powerful representations to model dynamic behavior. As the importance of systems supporting coordination,
collaboration and decision making between and within diff
erent working groups is drastically increasing, especially
in the area of office automation, design concepts are needed to enable efficient and powerful development of
wide support systems. CSCW claims for these facilities in an organization
e environment, but up to
now no effective approaches exist for this matter. On the other hand, one should not underestimate the influence the
early phases of analysis and design have to the success of such systems.

To get an image of the whole organizatio
n and its interrelations, this work discusses explicitly the general structure of
the interactive system to
designed placed in the organizational environment.

Considering the entire organization

A consideration of the complex environment of an interact
ive work system is helpful. Figure 1 centralizes the
interactive support system and shows its inter

and intra
connections. As can be recognized, the (user) interfaces are
the core units for communications between different environments. Therefore, the imp
ortance of adequate and
efficient interfaces is on hand.

: The cooperative work system is embedded in the internal and external environment

The arrows i
n the figure show different interaction within and between entities. For example within the system
interaction takes place between different domains (white boxes within the system). Between domains of the system
and members of the organization interaction
occurs via user interfaces. The system enables also communication with
the external environment of the organization via loosely or tightly coupled network technologies.

Organisation (enterprise) with intra

External Environment with inter





Operating System


Application Domain

User Interface





















media like
paper, phone

On the other hand interaction takes place within the organization participants via fac
face interaction, telephone,
letters, etc. not using facilities of the supporting system. Via the same media the organization members can interact
with the external environment of the organization (dotted box between external environment and organizat
namely the market (customers, competitors, banks, other organizations) and the government (authorities, lawyers,
etc.). The design of such a cooperative work system is a very complex attempt where different aspects from different
disciplines and diff
erent domains have to be brought in.

Workflow as well as Groupware concepts just considers parts of the picture: while Workflow systems focus on
organizational and task automation aspects, Groupware systems emphasize on interaction and collaboration facili
As can be recognized, neither the one nor the other concept alone satisfies the requirements for the cooperative work
system completely.

In her attempt Joan Greenbaum [cf. Gree96] uses a labor
oriented economic frame to the study of work. She stresse
the importance to take into account social science and economics in order to under
stand the economics consequences
of how labor is divided among jobs. Such studies include questions of wages, working conditions and contractual
agreements, cost
nalysis, as well as intensity of work. They also include issues of division of labor which are
essential for the complex analysis of not just work tasks or activities, but the social relations surrounding the
conditions under which people work. So, also ma
nagement’s objectives will be considered in the analysis and design
phase and there is accountability on both sides (designer as well as user). We will bear in mind these requirements
when expanding the conceptual framework.

Kjeld Schmidt [cf. Schm94] sugg
ests another approach. His focus lays on considering how multiple users work
together and articulate their individual activities. He defines this as the ‘focal issue’ of CSCW, and he points out that
the challenge is ‘to make Groupware organizationally awar
e’. In his discussion he considers interactions occurring
within firms and other corporate entities, and others which are carried out beyond the auspices of organization. With
the so
called ‘Leviathan’ approach as discussion point he defines four perspecti
ves on organization which are
relevant from the point of view of cooperative work: a) the cooperative work arrangement, b) the work organization,
c) the formal organization, and d) the firm, the network. All can be driving forces to the individuals to do t
heir work
and to fit into the governance structure of the organization.

Summing up, ‘
work is situated in an Organizational Context’

as it is pointed out in [Agos96] which means that
cooperative work is surrounded by a formal organization. To realize cooper
ative work, the underlying organizational
issues have to be mapped to the system level. To be able to do this it is necessary to have a closer look on
organization theories.

Organizational factors

In organization theory an organization is according to Rob
bins [Robb90] defined as a consciously coordinated social
entity with a relatively identifiable boundary that functions on a relatively continuous basis to achieve a common goal
or set of goals.

According to Mintzberg [Mint83] five coordinating mechanisms
seem to explain the fundamental ways in which
organizations coordinate their work. These are:

Mutual adjustment which achieves the coordination of work by the simple process of informal communication

Direct supervision that achieves the coordination by hav
ing one person take responsibility for the work of others,
issuing instructions to them and monitoring their actions.

Standardization of work processes (the contents of work are specified)

Standardization of output (results of work are specified)

zation of skills (the kind of training required to perform the work is specified)

These coordination mechanisms influence the collaboration between groups or units. Mintzberg [Mint83] also defines

views (or theories) of how the organization functions, whi
ch are:

A system of formal authority

the flow of formal power down the hierarchy in form of an organization chart
(organigram). Even though the organigram does not show informal relationships, it can represent an accurate
picture of the division of labor
. It shows at a glance (1) what positions exist in the organization, (2) how these are
grouped into units and (3) how formal authority flows among them (in effect describing the use of direct

A network of regulated flows

of production work
through the operating core, of commands and instructions
down the administrative hierarchy to control the operating core, of feedback information on results backup and of
staff information and advice feeding into decision making from the sides. This places

greater emphasis on
standardization than on direct supervision.

A system of informal communication, emphasizing the role of mutual adjustment in coordination, which is in fact
a ”sociogram”

a map of who actually communicates with whom.

A system of work

which shows that there are people in the organization cluster working together in
peer groups (not related to the hierarchy) to get their work done.

A system of ad hoc decision processes

a flow of one strategic decision, from beginning to


This organizational context contains a governing structure with a frame for each role, a defined hierarchy of
responsibility and roles, a formal job description for each role, goals and constraints. This is defined for individuals
and interacting g
roups within the organization to perform the related tasks. The organizational frame outlines a scope
for the interaction with the extern environment, which is also deduced from the strategic objectives of the
organization. The conceptual framework of GTA
comprises a description of relations between
objects/data/tasks/actors/... of the whole organization. It shows constraints of and access possibilities to resources
needed for the task execution. The organizational context gives also some reasons why users
show a special behavior
in certain task situations and therefore analysis of organizational issues enables better understanding of work.

As can be noticed considering the organizational issues in the design process gives a lot of information and

about structures, responsibilities, formal and informal communication streams and overall business goals.
The question is, why up to now this information is not born in mind in systems design, especially looking at designing
interactive systems, where int
eractivity depends upon these communication, coordination and collaboration
mechanisms. This weakness in design methods gives us the chance to start discussion in this matter.

A closer consideration of organizational factors elicits weaknesses of construc
ts or happenings of the existing
organization unit, which leads towards rethinking the business processes and tasks (BPR) [cf. Agos96, Thorb97,
Schä96], and helps improving the system to
designed. So, the design process of cooperative work consists of m
than just designing a support system

it includes design of different domains: systems (cf. Figure 1), organization
(governance structure, strategic objectives, formal and informal communications), user interfaces, ‘users’ and ‘groups
of users’ (skill
s, behavior, COP’s, work culture) and business processes (workflow).

GTA [cf. Veer96] builds upon TA and combines it with ethnographic and other methods to gain insight into different
problem domains. The problem domains as such are firstly pointed out as
‘the users’ and ‘the workplace’. In this
work we enlarge them with ‘work organization’ and ‘IT infrastructure’. Furthermore, the concept of ‘workplace’ is
expanded with Business Process Models (BPM) and Workflow Models (WFM), which put the focus of TA on a
wide point of view.

Business Process Models (BPM) and Workflow Models (WFM) have a strong relationship, but have according to
Galler [Gall95] been developed independently from each other. Whereas BPM describe the business process in a
ormal way from a general, business relevant and organizational point of view, WFM are formal and describe
workflow in much detail and in a technical way. At the beginning of a Business Process Redesign/Reengineering
(BPR) project it is not known which tech
nology would be most appropriate to support the business process.
Therefore BPM are a basis for the identification of the needed information technology.

BPR itself aims at achieving drastic improvements by redesigning the business process. Elich [Elich93]
gives five

Drastic improvements of the client orientation of the organization

by rearranging business processes

in which information and IT have a critical role

supporting a new way of organizing and working

handling of financial and non
l measures for ‘control at a distance’.

According to Joosten [Joost96], BPR is closely related to WFM, but goes somewhat further. BPR advocates a
revolutionary change of the business processes, in which the processes themselves are questioned. WFM is less

ambitious, because the business process itself is not under discussion. However, the structure and implementation of
that process is in effect redesigned. WFM is in the first place focused on the operational level of work. But since the
effects of that ca
n be significant, workflow management typically has consequences for both the tactical and the
strategic levels, so therefore there is a strong interaction between BPR and WFM.

Workflow Concepts

To understand Workflow concepts, some definitions are necess
ary [see Joost96]:

To automate a business process means to control process activities by means of electronic messages rather than
paper messages or spoken orders. These electronic messages are called work items. The automation of a business
process does no
t imply automation of the activities of which it consists. For example an important decision
making meeting is part of an automated business process if it is initiated by work items, even though the meeting
itself is a human process.

A work item represents

work to be performed, and is used to manipulate (e.g. relay, store, and schedule) that work
for the purpose of doing it later or elsewhere. A scanned image of a mortgage application form can serve as a
work item, and so can an electronic mail message aski
ng to authorize payment.

A workflow process can be defined as the automation of a business process, in whole or part, during which
documents, information or tasks are passed from one participant/role to another for action according to a set of

A Workflow Management System (WFMS) is a technological system in which workflow processes are defined,
performed, managed and monitored through the execution of software whose order of events is driven by a
workflow process definition (process exec
ution scheme). The phrase technological system refers to workflow
tools. A WFMS is used to support a workflow process, which contains technical and non
technical elements such
as people, procedures, resources etc. A WFMS assumes the availability of a data
communication infrastructure at
a workplace of individuals.

To define a workflow process means that the logic of the business process is specified, usually by means of a
graphical editor. To perform a workflow process means that the appropriate persons or

computers perform the
activities, of which a workflow process consists. To manage a workflow process means that the operations of
different workflow processes are coordinated. This means that workflow processes are started, stopped,
redirected, remodeled,

etc. To monitor a workflow process means that its status is inspected and a log of past
events is kept. The workflow process definition is a model of both the manual and automated activities of a
workflow process, which is understood both by a computer an
d by human participants.

WFMS are a kind of CSCW, which support larger groups mainly in asynchronous ways [cf. Grud94]. They are
apparently succeeding in application domains by fairly routine activities. The types of organizational processes
WFMS support,

are material (traditionally products), information (used to drive and control material processes) and
human processes (coordination of people and organizations through commitments).

Joosten [Joost96] differs between three views of WFM: process (showing in
formation on task level), definition
(processes in terms of activities, trigger, actors, information objects and resources, and their relations, and which
comes up to the workflow representation), and the organizational view (treats information that is not

related to a
specific workflow process).

Having different views

The metamodel we will work out in the next sections allows the designer a better way to describe higher
business processes, and their relations to other issues (e.g. higher
level busine
ss goals, upper management roles, sub
structures). It will allow different viewpoints (e.g. workflow, tasks, organigram, objects, data, goals) on different
abstraction levels (overview or details) and in different ways (static, dynamic). One can start from

a certain
observation point in the task world seeing the task world from the spectacles of an observer standing at the
observation point. A view focuses on different aspects on the relations between different things in the task world and
their relation to

different kind of dynamics. The dynamic can e.g. be time or moving between places. This however
requires a computer support with the ability to do consistency checking when the designer thinks it is needed.

Considering Information Infrastructure Aspects

onsidering existing applications one has to mention the design methods that are part of the conventional systems
development [Gross96]. There is an inherent weakness of such methods: they consider only functions, processes and
data in a rigid form neglecti
ng multidisciplinary design aspects and interrelations.

But nevertheless, one should not underestimate the value of conventional systems. They comprise a lot of core
information and are a valuable infrastructure for cooperation. So, they contain core appli
cation data, define
constraints on modification and access, support focal communication and coordination mechanisms, and disclose
problems in using the existing information structure.

In any case, the analysis of already existing information systems is ver
y important even if they only insufficiently
reflect the cooperation aspects. So ana
lysts may draw conclusions to the behavior of the users, better understand
dependencies and relations, or recognize accountabilities of particular users and constraints of

access to data.

Interdependencies and multidisciplinarity

Resuming the issues mentioned above, multidisciplinarity will be an unavoidable condition in design of interactive
systems. So, in the stage of analysis different disciplines such as sociology, psy
chology, ethnography, computer
science, HCI, economy, ecology are involved. It will not be possible that a design crew coming from one discipline
might comprise all the different viewpoints contributing to design of CSCW systems [cf. also Schm94, Gree96].

Furthermore, one has well to bear in mind existing interdependencies between different problem domains. An
example might be the following that one recognizes all the ways why an individual user shows a special behavior in a
certain task situation. This mi
ght result from his/her knowledge and skills, from the formal organization structure,
his/her job description and frame for the task execution, possible support mechanisms, constraints in resource access,
or from the experiences of the community of practic
e. In current literature this issue is mostly neglected.

GTA in a broader spectrum

GTA as a holistic design method for development of interactive work systems

GTA described at the beginning will now get enlarged with the requirements mentioned above to com
e up to a
holistic design method. Figure 2 shows the analysis phase of the improved GTA
method, which describes:

why the members of the organization are doing their work from the user’s point of view (users’ knowledge and

what they are doing, h
ow they are doing it and how they communicate, coordinate and collaborate (work

why they are doing it this way (work organization)

the intern and extern driving forces of the organization or the
formal framework, and

which support they get in
doing their work (information infrastructure).

Knowledge in these four problem domains can be gained via using different analysis methods of different disciplines.
Resulting from the analysis the current situation can be specified in task model 1, which co

users’ knowledge and behavior: describes the skills, explicit as well as implicit knowledge of the users; contains
the behavior of the users when they work on their tasks; and gives some reasons why people do their work from
their point of view,

task world and work practice: describes workflow, tasks, task structures, which tasks can be supported
automatically and which should be solved interactively; how the members interact with each other and with their

the work organization: contains

the governance structure; describes the strategic objectives and the organizations’
philosophy; gives reason why the members of the organization do their work (intern and extern driving forces),

the information infrastructure: describes used applications,

information systems and how the support systems are
connected; contains the data structures and access constraints of data; describes existing support systems for
collaboration and communica

: The Extended GTA

The task models consider also interdependencies between the different di
mensions, e.g.:

users’ knowledge can influence their work practices: if a user has more knowledge in the concerned
task domain
he/she can do his/her work quite different to somebody who doesn’t know so much. There are also many aspects
from the side of psychology and sociology, which can influence work practice. Somebody who gets a lot of
motivation and acknowledgement

will try to execute his/her work the best possible way and he/she will look for
improvements every time.

the work organization influences users’ behavior and knowledge because it represents the formal scope in which
the user has to operate.

The existing g
overnance structure and strategic objectives influence and constrain users’ work practices: the
organizations’ philosophy gives a scope within which the work group can interact with other groups or with the
external environment.

the existing information in
frastructure depends on work organization and vice versa: the upper management
decides about the used applications, the network. They decide about costs/benefits, financial matters, they assess
users concerning skills and knowledge and the support needed t
o do the work.

the existing information infrastructure constrains the degree of communication and cooperative work via

the existing information infrastructure influences users’ behavior, e.g. a CSCW tool allow the user quick feedback
about tasks,

or cooperation with other users on the execution of a task.

The design steps of the improved GTA (the conceptual framework of the method)

To specify the task model 2, important parameters requested by the client and the future prospective of the different

domains have to be born in mind as well. E.g.:

with training users will get better knowledge and their behavior and skills can change


existing network,


management, strategic
objectives, market





work pr慣

task model

task model





users’ knowledge

work practice




design of

cooperative work systems offer more possibilities to coordinate, communicate and collaborate via the system and
with oth
er participants of the organization. E.g. faster monitoring of snapshots of tasks in action, easier
monitoring of results and statistics, execution of common tasks

as a result of visualized problems in the analysis phase the organization may change the ini
tial governance
structure, so strategic objectives as well as busi
ness processes will get (re)defined.

Bringing together the issues worked out above the development steps of the extended Groupware Task Analysis
method comprise the following:


Start with an
alysis of the work situation in hand thereby using ethnography and other analysis methods. Analysis
is done in different problem domains as stated before and it tries to find out the different interdependencies of the
areas. The results are a description o
f the current work situation (Task model 1) as well as problems to be
improved for the future work situation.


Improve the task model by adding amendments as solutions for the recognized problems, and optimize the model.
Take into account also the requested

parameters defined by the client.


Evaluate the improvements of b) by letting the user test the changes thereby doing further observation and
analysis in the concerned problem domains as stated in a), validating the model, thereby using also cost
analyses and feasibility studies.


Iterate between b) and c) to get a design model of the future work situation satisfying all parties of the project
(client, users, managers, designers).

After the last iteration in the design phase, detail specification,
prototyping and finally implementation can start using
the description of the desired future situation (the task model 2). One has to note that after implementation there is a
change of view: for all further improvements from now the old task model 2 will
develop into the new task model 1.

The conceptual framework for the task models describing different
work situations

The Entity Relationship Diagram (ERD) in Figure 3 shows the different viewpoints or entities, which have to be
considered in designing int
eractive systems, and their relationships.

Organisation /
Governance S.
Workflow /
Task Structure
Objects /
occur at
Entities, viewpoints

: The conceptual framework of GTA with WFA

In the following the different entities of the ERD are explained, their relations to other entities and sub
entities are
described, and some comparison with the GTA approach is made.

Workflow / Task Structure

In WFA the concept of activities is used. According to Joosten [Joost96] an activity is a collection of events released
by a single actor in a single span
of time. An activity may be a manual activity not supported via the system or a
workflow activity with automation support.

Both the responsibility and performance of a complex task can be allocated to several different roles. In the workflow
world only on
e role is responsible for one specific activity. If not, the activity has to be split into two or more
activities. An activity can be seen as a middle or low level task in the GTA

There are relations between higher
level business processes, subtasks
, and unit tasks, which describe communication
and dependencies between tasks at the same and on different levels (hierarchy). Subtasks can be split into other
subtasks or into unit tasks, which are at the bottom level of decomposition. They consist of ato
mic actions. These
actions describe activities like using, modifying, creating, doing something with physical or non
physical objects.

To describe the static behavior WFA models causal dependencies as triggers like: SEQ, LOOP, OR
JOIN. The control structures in WFA are more influenced
by programming languages than the constructors in GTA, since a workflow model will be the basis for something,
which will be implemented.

In GTA constructors are used
to describe the relation between a task and its subtasks. The constructors will describe a

plan or scheme, in which order and under which conditions the subtasks are performed. The set of constructors is
domain dependent. The analyst has to find out what i
s the most suitable set of constructors in a certain situation. Dix
[cf. Dix93] describes the ways to model a task structure via constructors as follows: fixed sequence (SEQ), optional
task (OR, CHOICE(<LIST>), OP, OPT(<LIST>)), waiting for events (COND),
cycles (LOOP), time sharing (SIM,
PAR), discretionary (SET), mixtures.

During the design process the designer specifies the processes and main tasks in more detail. This can consist of
specifying subtasks to each main task in the process. It can also consi
st of changing some of the relations between the
tasks in the process or adding new ones (redesign). Each task in a workflow process can be further refined in a tree,
another workflow graph or both. This enables a top
down way of decomposition and results
in optimization of the
execution scheme.

Considering one task at a certain level, this task has several attributes. Some of them are special characteristics of the
task, others evolve resulting from the different relations the task has to other tasks, but
also to other entities. For
example, every task can have pre
, transition, and post
conditions. The distinction between transition condition and
condition is according to the Workflow Management Coalition [WMC96]:

A Pre
Condition is a logic
al expression, which may be evaluated by a workflow engine to decide whether a
process instance or activity within a process instance may be started/terminated. Synonyms are entry/exit criteria and
activity start/termination rules.

A Transition Condition i
s a logical expression, which may be evaluated by a workflow engine to decide the sequence
of activity execution within a process. Synonyms are Navigation Rule, Routing Condition, Process Rule, Transition
Rule, Business Process Rule and Conditional Routing

We need a clear distinction between transition condition and Pre
Condition. A transition condition can effect
the sequence of task execution within a process whereas a Pre
Condition cannot. The transition conditions
decide whether you should

choose a task as the next task to perform. Once a task has been selected for execution the
Condition can be evaluated. A false value of the Pre
Condition can have the implications that we have to wait
before the task can be executed. This can lead to
an exception event which results from a certain time
out has expired
because of the task couldn’t start execute.

The relation to roles, goals, objects/data, events, time and environment are worked out in the concerned entities.

Organization / Governance S
tructure (role hierarchy)

In organization theory an organization is [cf. Robb90] defined as a consciously coordinated social entity, with a
relatively identifiable boundary, that functions on a relatively continuous basis (group working together
ly) to achieve a common goal or set of goals.

According to Workflow Management Coalition [WMC96], an organizational model is defined as a model, which
represents organizational entities/units and their relationships. Such a model normally incorporates conc
epts such as
hierarchy, authority, responsibilities and attributes associated with an organizational role.

One of the goals of CSCW is to improve the communication, collaboration and coordination of work of groups and
between groups. The organizational con
cept of this work elaborates on these viewpoints. The three c’s express
relations between roles, tasks, strategic objectives, and objects. There are different theories about coordination, e.g.
Mintzberg’s five coordination mechanisms [cf. Mint83], Winograd

and Flores' theories [Wino87] or Malones
[Malo90] theory how interdependencies play an important role in coordination. To describe the vertical
decomposition of an organization it is essential to describe who has authority over whom, e.g. that has the for
right to act or command others to act. This can be shown in a hierarchy over the different positions in the
organization. A role can have authority (an individual’s capacity to influence) over different other roles, and this
authority can depend on for
mal context of work, on governance structures, and on informal rules (COP’s, work
cultures) [cf. Robb90]).

The three main sources of power are hierarchical authority, control of resources, and network centrality. Even if a
role doesn’t have formal authori
ty over another role it is still possible that it can delegate tasks to this role e.g. a
senior expert can delegate simpler tasks to junior employees. A role can allocate objects to roles so that the others can
perform their tasks e.g. the system administr
ator can give a certain disk space to a student at the University.

In order to coordinate the work in an organization it is important to express which roles perform a certain task and
which roles are responsible for it. The responsibility of a task can bel
ong to a role different from the role peforming
the task. On the other hand, several roles can be authorized to perform a task, which gives a role the possibility to
delegate a task to another role, which is also authorized for that task. The selection pro
cess of performers is further
elaborated in Kappel [1994].

To be able to describe the flow of work and information in the organization it is important to have a clear picture of
how different roles, organizational groups, and organizational units collabor
ate with each other. E.g. two roles are
editing the same document at the same time (they are collaborating via performing the same task and using the same
object). A communication process can according to Eco[] be seen as the passing of a signal from a sou
rce through a
transmitter along a channel to a destination. A communication act can be modeled as a relation between the sender,
the receiver, the message and the medium through which the message is communicated. In our project we modeled
communication pro
cesses as a task, where you use a certain object as a medium. The message can be an object (e.g.
an email). The performer of the task is the sender of the message and the receiver of the message is a role, which is
related to the task by a relation like ‘r

The organizational concept used in WFA describes the formal organization. The organization concept in GTA is less
formal and broader since it describes the human structure in the community of practice. It includes both a formal
organizational mod
el and an informal organizational model, which describes the real actual situation in the
organization. For example, GTA represents Mintzberg’s five different views on organizations as follows:

The system of formal authority is described as hierarchical au
thority relations between different types of
employees or as decomposition into sub
units and departments.

The flow of regulated activities is mapped in some kind of workflow notation.

Describing a flow of informal communication in GTA can be harder. Repr
esentations to describe different kind of
communications are under development in GTA.

A system of work constellations can either be defined via roles for each function in the organization and using the
of’ relation for decomposing functions into mor
e specialized sub
functions, or via description of the
different functions in the organization and decomposition of the functions into more specialized sub
of hierarchy of roles).

An ad
hoc decision process involves several different roles

and tasks, which is not represented in GTA or WFA.

The role concept in GTA is more informal and captures more organizational aspects of roles than the different role
concepts in WFA, which focus on the activities, which are performed by the role, formal
knowledge/skills and other
tangible attributes. The role concept in GTA is thus broader. In principle it includes WFA Role plus WFA Position
plus organizational aspects.

In WFA the actor concept has higher importance than it has in GTA whereas the role con
cept has higher importance
in GTA. As roles are stakeholders for individuals (actors), and we are elaborating on a meta level, in this work only
roles are considered according to the GTA concept.

A role is in principle defined by the set of tasks it qualif
ies for, performs, or is responsible for. This set of tasks is not
static but depends on the situation. An actor with a certain role cannot in certain situations at the same time perform
the task and give the permission to perform the task.

An ethnographi
c study in Dutch social security office [Hoeve96] revealed that in a certain situation a second person
was needed to conform important decisions. The second person normally performed identical roles as the first person,
but was in this case chosen because
there was no relation to the applicant concerned. Here, in the actual situation of a
certain request this person acted in a different role. One of the characteristics of GTA is that you can model informal
roles, which result from the work practice. Two act
ors having exactly the same formal role can split the tasks between
them according to a mutual agreement. This concept is also taken from GTA.

Strategic Objectives / Goals

As each organization has its strategic objectives, these effect the behavior of the
organization members, and this
implies effects to the task world. The strategic objectives can be decomposed into different goals, which are related to
tasks, roles, and which have certain validity.

In GTA tasks have a goal, too. Since we have a task hiera
rchy we must also have a goal hierarchy. On the other hand,
description of business processes on a higher level implies describing complex relations between goals and tasks,
which was yet not realized in GTA. Our conceptual framework enables this constella

level business goals are strongly related to the environment of the organization. Actions taking place in
external organizations related to the own organization (e.g. clients, banks, and competitors) can have enormous
influence to the strateg
ic objectives of the organization. E.g. if the government vote for a rise of tax for a certain legal
form like the concerned organization has, the upper management of the organization will eventually switch to another
legal form, or reset some strategic ob

Objects / Data

An object is [see Joost96] defined as a concept, abstraction or thing with crisp boundaries and meaning for the
problem at hand. The concept resource is also used. It is defined as something that can be used at any time. Some of
he objects and all actors can be resources.

Objects are used and affected in tasks. Some examples

describing also the relations

are: carriers for message
triggering, each task can use, modify and create certain objects, each role and actor uses, modifi
es and possess certain
objects. Objects also have a time relation, e.g. certain validity.

Furthermore, data can be seen as abstract objects, but one has to consider the specific behavior or constraints. So, this
concept of abstract objects has to be enlarg
ed with a data flow model to represent how data is passed between
different tasks, and how the properties of this data are changed, which is realized in the ER diagram of the data

The relation between objects/data and tasks enables expression of da
ta flow and control flow in one graphical
representation. This is realized with data connectors in WFA. A connector is something, which connects tasks with
each other. There are two kinds of connectors: control and data connectors. Control connectors descr
ibe the flow of
control between two tasks whereas data connectors describe the flow of data between two tasks [cf. IBM[93]). Each
task has one input and one output data container. A data connector is a mapping between the output container of a
task and inp
ut container of another task.

Objects/data are in the ownership of one or more roles or other organization units. Therefore, access control has to be
included in the model of objects/data. An access control model describes this kind of constraints, which
is also
realized in the control connector concept.

Time and Events

The workflow model should have a time dimension, which can be represented by a time axis in a diagram. In our
conceptual framework it is described in the time entity and it provides GTA wit
h a way to describe relations to tasks

the normal time required to complete the task

the deadline of the task, a certain time within the task must be completed

time dependencies

time frequencies

time triggering

time conditions

time delays


the time aspect is related to objects/data in their validity conditions. According to Joosten [Joost96] a
workflow event is something that happens (occurs) at a point in time. An activity and a task can be associated by any
time span whereas an event occu
rs at one specific instant in time.

Since we are combining concepts from different worlds it is important to distinguish between GTA
events and
workflow events. An event can occur due to the completion of a task. A certain condition occurs during the
rmance of a task. A particular condition occurs in the environment, e.g. a certain time has expired, or something
happens originating from the outside world (e.g. a telephone call, receiving a mail).

The difference to WFA events is that GTA
events can take

some time whereas a workflow event occurs at a point in
time. A GTA
event is often used to specify the actions taken by the computer system. These actions can of course
take some time. As a consequence of the occurrence of an event some other activity may

take place, this is called
triggering [Joost96]. Relations of forced execution are the following:

forced causal precedence (forced control connectors): the termination of one task causes (triggers) another task to

forced input
output relation (for
ced data connectors): this type of trigger is a relation between the environment
and a task.

reactions on conditions in the environment (e.g. time conditions) and external events: event handlers.

A way to describe exceptions and the actions to be taken if

they occur is useful: exceptions can be modeled as a kind
of events. Exception events are rare circumstances which don’t occur rather frequently and which are impossible to
predict when they occur. Therefore, exception handling and external triggering hav
e the same architecture and are
dealt with as being equal.


The environment describes objects, roles, and events, which are defined outside the organization. An example for an
external event is that the event ‘customer complaint’ activates an in
stance of the business process ‘handling customer

So, the main influence of the environment is that it produces events

some predictable, some not

which trigger
tasks within the workflow. Furthermore, events like change of certain circumsta
nces in the environment can set off
changes in the internal structures of other entities.


Summing up, the improved GTA approach describes the organizational complex for which a cooperative work
system will be designed. Thereby it maps different

entities like workflow, organigram, strategic objectives, data and
objects. Furthermore, it allows description of dynamic behavior via including time aspects and events.

The task model serves as a basis for design (detail specification, prototypes, imple
mentations). On the other hand,
prototypes and implementation offer the possibilities to test the improvements of the model in real environment by
letting the concerned users work and experiment on the prototyped part of the model.

The advantages of extend
ed GTA are twofold: the approach describe the organization from a holistic point of view
thereby using advanced methods for gaining knowledge in different problem domains and considering different areas.
Furthermore, it integrates users, managers, and so o
n in the design process thereby letting them test and elaborate on
prototypes, scenarios, and design fragments, which result in better user acceptance and shorter introduction and
training periods in the later stages of systems design.


see also


Alessandra Agostini, Giorgio de Michelis, Maria A. Grasso, Wolfgang Prinz, Anja Syri. Contexts,
Work Processes, and Workspaces. In CSCW: The Journal of Collaborative Computing, vol 5, 1996,
pp. 223


Dan Diaper. Task Analysis for Human
Interaction. Ellis Horwood Ltd., 1989.


A. Dix, J. Finlay, G. Abowd, R. Beale. Human
Computer Interaction, Prentice Hall Europe, 1993


J.H. Elich (ed.). Themanummer: Business Process Redesign.
Management and Informatie. Samsom
BedrijfsInformatie B.V., 3 edition, December 1993



Joan Greenbaum. Back to Labor: Returning to labor process discussions in the study of work. In
Proceedings of the Conference on Computer Supported Cooper
ative Work, 1996. pp. 229



Tom Gross and Roland Traunmüller. Problem Dimensions in Design of CSCW Systems. Dexa
Conference, 1995.


Jonathan Grudin. Groupware and social dynamics: eight challenges for developers. Communications of

ACM 37(1), 92


M. Hoeve, B. Lenting, G.C. van der Veer. Modeling Complex Work Systems

Methods meets Reality,
Department of Computer Science, Vrije University, The Netherlands, 1996


IBM. FlowMark

modeling workflow version 2.1, IBM
, Document No. SH19
00, 1993


H. Johnson and P. Johnson. Task knowledge structures. In [Veer92] pp 3



S. Joosten. A conceptual framework for WFMS, submitted to ACM Transaction of Information
Systems, University of Twente, 1996


Kari Kuutti. Coping with active subjects: the emergence of CSCW from IS and HCI traditions. In The
design of Computer Supported Cooperative Work and Groupware. Elsevier Science BV, 1996. pp 287



Thomas W. Malone, Kevin Crowston. Wha
t is coordination theory and how can it help design
cooperative work systems?. In Proceedings of the Conference on Computer Supported Cooperative
Work, 1990. pp 357



Henry Minzberg. Chapter 1: Foundations of Organizational Design, Structures
in fives: designing
effective organizations, Prentice
Hall, Englewood Cliffs, 1983


S. Robbins. Organization Theory

Structure Design and Applications, Prentice
Hall, Englewood
Cliffs, 1990


Thomas Schäl. Information Systems in Public Adm
inistration: From Transaction Proceeding to
Computer Supported Cooperative Work. In The design of Computer Supported Cooperative Work and
Groupware. Elsevier Science BV, 1996. pp 349



Kjeld Schmidt. The Organization of Cooperative Work: Beyon
d the “Leviathan” Conception of the
Organization of Cooperative Work. In Proceedings of the Conference on Computer Supported
Cooperative Work, 1994. pp 101



Kjeld Schmidt, Tom Rodden. Putting it all Together: Requirements for a CSCW Platform.

In The
design of Computer Supported Cooperative Work and Groupware. Elsevier Science BV, 1996. pp 157



Daniel Thorberg. Integrating Workflow Analysis into Groupware Task Analysis. Master Thesis,
University of Amsterdam and Linköping, 1997


Gerrit C. van der Veer, Sebastiano Bagnara, Gerard A.M. Kempen. Cognitive Ergonomics:
Contributions from Experimental Psychology. Elsevier Science Publishers B.V., North
Holland, 1992.


G.C. van der Veer, B.F. Lenting, and B.A.J. Bergevoet.

GTA: Groupware Task Analysis

complexity. Acta Psychologica, 91, 1996, pp. 297



T. Winograd, F. Flores. Understanding Computers and Cognition. Addison
Wesley. 1987


Workflow Management Coalition. Terminology and Glossary, Do
cument Number WFMC
Brussels, June 96