Current ERP systems are typically designed for single users who
interact with a business system in order to perform one predefined activity. However, in
reality more people are involved in performing one task. Since Baan is working on Task
Modeling as user interface development and runtime environment, there is also the need to
look ahead and make the environment suitable for multiple users. This section describes a
set of ERP-specific Computer Supported Cooperative Work requirements for the Task Modeling
architecture.
Synchronous interactions must be supported. In ERP systems there is already an
asynchronous facility for multiple users who are cooperating: Workflow. To make ERP
systems really multi user enabled, you also need to cover synchronous interactions.
Users must be able to communicate 'informally' about a 'shared object'.
A shared object in an ERP environment can be anything from Sales Order to Purchase
Order and Warehouse Inventory. The users act on these objects via a task, which can be
shared with other users. In order to communicate about these shared objects the user
interface must support the ability to communicate easily and 'informally'.
Specific Widgets are needed to help the users in communicating about a
shared object and to be aware of each other's actions. When two users are working
remotely on the same attributes of an object, they need to be aware of the actions of the
other users. Since both users do not have the same screen in front of them, we need to use
WYSIWISY (What You See Is What I Show You), also known as relaxed WYSIWIS (What You See Is
What I See). In order to still see where the other user has the focus on, specific widgets
are needed (e.g., semantic Telepointers, highlighting of activated text fields).
The Communication about the shared objects should takes place via a
separate communication channel, depending on the software possibilities on the user's
clients. This channel can be anything from telephone to video conference. For the
generation of the user interface, it is very difficult to know beforehand what the
communication channel will be, since not all clients use the same software. Therefore, the
task model should not determine the communication channel itself, but will use existing
external applications for communication (e.g., e-mail, chat programs, video conferencing
programs) The users then need to choose the communication channel depending on the
client's possibilities.
Initially, only a maximum of two users should be involved in a
cooperative session. In the current ERP system, communication via the system is very
limited. A maximum of two users involved in one cooperative task is already a large
improvement. Therefore, we do not need to consider more than two users. This however, does
not limit the amount of cooperative tasks one user can be involved in. E.g., a Sales
Representative can cooperate with a Customer, but when a certain question arises about the
Inventory, the Sales Representative can contact a Warehouse person and have a separate
cooperative task with him.
Once a cooperative session is started, the identification of the other
users must be provided. In ERP systems, a lot of information is legally sensitive and
often limited to certain roles. Next to the fact that the system will recognise the users,
it is also necessary and important that each user is aware of the identity of the other
cooperation participant and is able to limit the available data for that other user.
There must be a strict separation of public and private elements. It
is important for users of cooperative tasks to be able to limit or expand the public data
that might be shared with the other. The granularity of the information that can be made
public or private can differ, but the minimum must be based on the level of one attribute
of a Business Object or one method trigger, because the smallest unit in task modeling is
also on that level.
In case of data sharing and data hiding, flexibility is desirable to
change access rights for data in order to transform public data into private data and vice
versa. It is very difficult to know in advance what information may be shared or must
be kept private for every cooperative session. Of course, there is information limited to
certain roles, but in non-routine situations people might decide that someone else could
see more or less than 'normal'. Therefor, it would be nice if the access rights for data
during a cooperative session can be changed in a flexible manner when necessary.
It is important to note that only 'senders' of a shared object can
determine what is public and private. The 'receiver' is dependent on what a sender of the
information is 'willing' to give. Thus it would be nice if senders should be able to
over-rule access rights and make public what can be shared. A sender can set the following
settings on attribute and method trigger level for a receiver:
- not shared with receiver
- shared
- output only: receiver can only see an attribute or method trigger
- editable: receiver can edit an attribute or trigger a method
The Task Modeling environment must be made
suitable for multiple users cooperating on shared objects. In continuation of the
separation of interaction semantics, presentation and application logic, the cooperation
features should be captured in a separate layer in the Task Modeling architecture. Based
on the thesis of Brinley Smith[1995] we identify the need of three models to support
cooperation in the architecture: Access Control, Policy Nodes and Roles.
Access Control. In the Access Control Editor one can indicate
whether a task may be shared and if so, how it is shared (editable or output only). These
sharing properties have direct consequences on the user interface presentation of the
different users. If, for example, one user has access to all the information of a task,
and the other user can access only a part of this information, the user interfaces are not
similar. However, both users are interacting on this shared task. The Access Control
properties need to be coupled to the Presentation Components in the UI manager of the Task
Interpreter.
Policy Nodes. Next to presentation
issues, also the interaction with the application contains cooperative aspects. The
question is what to do when multiple people are triggering one method? In such a case, the
input of the users must be interpreted before a method in the application logic can be
called. An example is a situation where multiple users can vote for one certain type of
pizza to be ordered. Depending on what the 'majority' chooses, the correct type of pizza
will be ordered. For this, simple rules in the "If <trigger> then
<response>"style can be used. Triggers can either be selective (based on user
role) or consensus (based on (relative) number of users selecting it). For this type of
functionality, policy nodes are coupled to the task nodes representing the trigger.
When this task is triggered, the policy node determines what information is passed to the
application logic.
Roles. Modeling the roles has a direct relation with the Access
Control and the Policy Nodes. For the Access Control, the role indicates what part of the
information is available. The relation with the Policy Nodes is that the roles of the
users involved in a cooperative session are used in the interpretation of triggers before
the method in the application is called. In the Role Modeller the developer indicates what
roles are involved in the cooperative tasks: names, types of users, etc.
Architecture. The cooperative features need to be incorporated
in the architectural design of the Task Modeling environment. The architecture needs to be
extended with Access Control, Policy Nodes and Roles. These aspects have a direct relation
with the Presentation Components, which are based on the task model leaf nodes. At
development time the task models should be used to indicate what the access rights and
input interpretations are. At runtime, this information must be used as filter between the
UI manager and the Presentation Components.
Gareth Brinley Smith (1995). A Shared Object Layer to Support Cooperative User
Interfaces, Computing Department, Lancaster University, UK.
Richard Michael Bentley (1994), Supporting Multi-User Interface Development for
Cooperative Systems, Department of Computing, Lancaster University, England.
Paterṇ F., Mancini C., Meniconi S. (1997), ConcurTaskTrees: A Diagrammatic
Notation for Specifying Task Models, Proceedings Interact '97, Chapman&Hall,
pp.362-369
