Information Technology Reference
In-Depth Information
Step 1: Highlight reference points that are bounded to time. Such reference points are the variables Con-
nection, Participation, DataInput, DataOutput, Event, Recurrence, Tool and TimeNote.
Connection and Participation: It may be the case that there are links identified to persons or roles
whose To-do lists were not gathered in the elicitation phase (compare with Fig.2). This is an indi-
cation for the designer that not all process participants were considered in the ascertainment of
the process.
DataInput, DataOutput and Events: A question that need to be answered by the designer is if
events, such as “send document x to person B” and “receive document x from person A” are con-
sidered in the process models as operations. The overall question to be answered in the first step is
for what purpose is the process model designed. If it is designed to illustrate the actual process as
perceived by the process members, than events as illustrated in the example may be integrated as
operations (particularly if the event of person B “receive document x from person A” triggers the
process of person B). If the process model is designed as a basis for the implementation of a work-
flow system, then such events may not be considered in the process model, as in a workflow
systems all data material is available for process participants.
Step 2: Aggregation of tasks. If the level of abstraction considered by the designer is identical to the ab-
straction level of the original To-do's, then there might be detailed operations across process
views (e.g.”Writing on PhD thesis”, ”Exchange with mentor”, “Enrolling in creative writing
workshop”) less detailed operations probably implicitly subsuming the detailed operations (e.g.
“Elaboration of PhD thesis”). In such a case the designer has to decide if, e.g. such creative tasks
should all be considered in the process model. An option for the designer is use by default the
higher level task and to additionally consider these detailed operations that were (n/2+1)-times
mentioned across process views (n=number of process participants).
Step 3: Set order of execution. Transfer explicit time notes mentioned in the To-do list and transform them
into concrete date and time. Estimate the duration of the operation. If there is no explicit time note
mentioned for a particular To-do, then first check time notes of reference points in To-do lists of
other process members. Choose these time notes as support to set a concrete date and time and
consider at the same time already set time specifications of other To-do's in the list. The sequential
ordering of the To-do's in the list should be reflected in the time stamps. If necessary, the designer
may also consider Comments for specifying time and date of operations, or directly contact the re-
spective process member.
Connection and participation: Adjust time stamps according to connection and participation hints.
A connection considers work- or data transfer to another process member. Participation considers
operations that are collectively performed (e.g. meetings).
Recurrence of tasks. If there are hints that a tasks is executed several times (loop) then the de-
signer has to decide if the loop is considered in the log as loop or if each execution of the opera-
tion is captured as a particular step in the process model.
Step 4: Check the agent of the task. If there are indications that an operation is delegated to another
process participant, than the operations are still considered as operations of the delegator. In the
field “Agent” the name of the delegatee is entered. The tasks of the delegatee remain as tasks of
the process member in his or her process view log.
Step 5: Set number of process instances (cases). The number of process instances in a process view is
determined by the number of the decision paths. If there are > 1 decisions, the product of the deci-
sion paths determines the maximum number of process instances. So, if there is decision n includ-
ing m paths and decision d including e paths considered in one process view, than the designer
needs to build a maximum of m x e process instances.
Step 6: Explicate conditions and rules. Particular decision paths must not or cannot be considered in the
same process instance. Therefore, rules for joining decision paths (if decision ≥ 1) need to be
defined. The designer keeps overview when the operations are organized into operations that are
always executed and operations that are only executed if a particular condition occurs. Thus, the
designer obtains “operation blocks” that can be merged into one process instance by considering
merging rules and condition.
