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

Cooperative Work System

User Interface

user

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 re-design of

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(), OP, OPT()), 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