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}@cs.vu.nl
2) University of Linz, Austria
Abstract
Task modeling plays 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 work 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 (goals, 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 based 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-to-be-designed will be incorporated). In
this important phase of design the client of design will 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 our task analysis tool EUTERPE.
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.
Keywords: GTA, Task analysis, organizational factors, high-level business goals, Groupware
Introduction
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 work
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 different
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-bedesigned and its place in the organizational environment. Components and interaction interfaces of the cooperative
work arrangement (system and organization 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 factors 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
higher-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 basis for better prototyping as it provides holistic design approach from an
organization-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 representational 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 Hierarchical
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-be-designed 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 ‘current’ 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 model (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” bears 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 mainly
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 surpassed 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 different 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 represented in
model 1, in combination with important parameters as formulated in interaction with the customer of the design (the
client).
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 to 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.
A 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 performance, 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 it 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 different working groups is drastically increasing, especially
in the area of office automation, design concepts are needed to enable efficient and powerful development of
enterprise-wide support systems. CSCW claims for these facilities in an organization-wide 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 organization and its interrelations, this work discusses explicitly the general structure of
the interactive system to-be-designed placed in the organizational environment.
Considering the entire organization
A consideration of the complex environment of an interactive 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 importance of adequate and
efficient interfaces is on hand.
External Environment with inter-connections
Organisation (enterprise) with intra-connections
Interaction
media like
paper, phone
user
user
group
Cooperative
Work
System
User Interface
user
group
User Interface
user
Application Domain
user
interface
market
in
ter
fa
ce
Network
user
Storage
Operating System
Technology
government
user
interface
Figure 1: The cooperative work system is embedded in the internal and external environment
The arrows in 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.
On the other hand interaction takes place within the organization participants via face-to-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 organization),
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 different 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 facilities.
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 stresses
the importance to take into account social science and economics in order to understand the economics consequences
of how labor is divided among jobs. Such studies include questions of wages, working conditions and contractual
agreements, cost-benefit-analysis, 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 management’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] suggests 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 aware’. 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 perspectives 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 their 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 cooperative 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 Robbins [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 having 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)
 Standardization 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, which 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
supervision).
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 constellation – 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 end.
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 groups 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
knowledge 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 interactivity 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 constructs 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-be-designed. So, the design process of cooperative work consists of more
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’ (skills, 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 an
organization-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
semi-formal 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 technology 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
essences:





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-financial 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 can 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 necessary [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 not 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 asking 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
procedural rules.
 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 execution 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 and 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 information 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-level
business processes, and their relations to other issues (e.g. higher-level business goals, upper management roles, substructures). 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
Considering 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 neglecting 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 application 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 very important even if they only insufficiently
reflect the cooperation aspects. So analysts 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, psychology, 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 might 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 practice. 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 come 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
behavior),
 what they are doing, how they are doing it and how they communicate, coordinate and collaborate (work
practice),
 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 covers:
 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,
 the 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
machines,
 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 communication.
client
users’
knowledge /
behavior
work practice
users’ knowledge
/ behavior
HCI,
ethnography
communication,
cooperation,
ethnography
work practice
task model
1
work
organisation
management, strategic
objectives, market
Information
structure
databases,
existing network,
applications
given
situation
re-design of
dimension
task model
2
work
organisation
Information
structure
interdependencies
Figure 2: The Extended GTA-Method
The task models consider also interdependencies between the different dimensions, 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 governance 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 infrastructure 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 to do the work.
 the existing information infrastructure constrains the degree of communication and cooperative work via
computer.
 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
 cooperative work systems offer more possibilities to coordinate, communicate and collaborate via the system and
with other 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 initial governance
structure, so strategic objectives as well as business 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:
a) Start with analysis 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 of the current work situation (Task model 1) as well as problems to be
improved for the future work situation.
b) 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.
c) 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-/benefitanalyses and feasibility studies.
d) 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 interactive systems, and their relationships.
Objects /
Data
responsi
bility
Time
use,
manipulate
Organisation /
Governance S.
validity
needs
validity
Workflow /
Task Structure
execute
occur at
trigger
constrain
Events
influences
has
Strategic
Objectives
produce
produce
validity
Environment
Relations
Entities, viewpoints
frame
for
Figure 3: 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 one 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-model.
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 atomic 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-SPLIT, inORSPLIT, AND-SPLIT , OR-JOIN, inOR-JOIN, and AND-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 is 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 consist 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
pre-/post-condition is according to the Workflow Management Coalition [WMC96]:
A Pre-/Post-Condition is a logical 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 is 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-/Post-Condition. A transition condition can effect
the sequence of task execution within a process whereas a Pre-/Post-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
Pre-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 Structure (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
harmoniously) 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 concepts 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 concept 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 formal
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 formal 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 authority 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 administrator 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 belong 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 process 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 collaborate 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 source 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 processes 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 ‘receiver’.
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 model 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 authority 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. Representations 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
‘type-of’ relation for decomposing functions into more specialized sub-functions, or via description of the
different functions in the organization and decomposition of the functions into more specialized sub-functions
(type-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 concept 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 qualifies 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 ethnographic 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 actors 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 hierarchy 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 constellations.
Higher-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 strategic 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 objectives.
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
the 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, modifies 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 enlarged 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
model.
The relation between objects/data and tasks enables expression of data 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 describe 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 input 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 with a way to describe relations to tasks
as:







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
Furthermore, 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 occurs 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
performance 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
start.
 forced input-output relation (forced 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 have the same architecture and are
dealt with as being equal.
Environment
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 instance of the business process ‘handling customer
complaint’.
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 circumstances in the environment can set off
changes in the internal structures of other entities.
Conclusion
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, implementations). 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 extended 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 on 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.
References:
see also: http://www.cs.vu.nl/~martijn/gta/
[Agost96]
[Diap89]
[Dix93]
[Elich93]
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-250
Dan Diaper. Task Analysis for Human-Computer-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
[Gall95]
[Green96]
[Gross95]
[Grud94]
[Hoeve96]
[IBM93]
[Johns92a]
[Joost96]
[Kuut96]
[Malo90]
[Mint83]
[Robb90]
[Schäl96]
[Schm94]
Joan Greenbaum. Back to Labor: Returning to labor process discussions in the study of work. In
Proceedings of the Conference on Computer Supported Cooperative Work, 1996. pp. 229 - 237
Tom Gross and Roland Traunmüller. Problem Dimensions in Design of CSCW Systems. DexaConference, 1995.
Jonathan Grudin. Groupware and social dynamics: eight challenges for developers. Communications of
the ACM 37(1), 92-105
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-8241-00, 1993
H. Johnson and P. Johnson. Task knowledge structures. In [Veer92] pp 3 - 26
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
- 308
Thomas W. Malone, Kevin Crowston. What 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 - 370
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 Administration: From Transaction Proceeding to
Computer Supported Cooperative Work. In The design of Computer Supported Cooperative Work and
Groupware. Elsevier Science BV, 1996. pp 349 - 368
Kjeld Schmidt. The Organization of Cooperative Work: Beyond the “Leviathan” Conception of the
Organization of Cooperative Work. In Proceedings of the Conference on Computer Supported
Cooperative Work, 1994. pp 101 - 112
[Schm96]
[Thorb97]
[Veer92]
[Veer96]
[Wino87]
[WMC96]
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
- 175
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 – Modeling
complexity. Acta Psychologica, 91, 1996, pp. 297 – 322
T. Winograd, F. Flores. Understanding Computers and Cognition. Addison-Wesley. 1987
Workflow Management Coalition. Terminology and Glossary, Document Number WFMC-TC-1011,
Brussels, June 96