Capturing and Describing Activity Structures

There are several techniques available to describe business processes such as, for example, sequence diagrams of the Unified Modelling Lan- guage (UML; eg. Booch et al, 1999) and data flow diagrams of Structured analysis (Yourdon, 1989). To describe business processes we propose to use Action diagrams of the SIMM family of methods (Goldkuhl, 1992; 1993), due to insufficient semantics in other approaches.

In Action diagrams different activities of a business process and how these activities are related to each other are explicitly described. Actions performed by human actors as well as information system ac- tions are considered. Note that Action diagrams describe types of activi- ties, and not the actual occurrences. Action diagrams can be used to de- scribe material flow and information flow within a business process; see Fig 6-6.

Information (oral or written) action object.

Material action object. Information flow (communica- tion).

Material flow.

Activity [Performer] _{Activity with named performer.}

Fig 6-6: Basic notation used for activities, action objects and flows in Action dia-

grams.

Material and information (as action objects) are described and re- lated to activities as prerequisites (input) or results (output). One impor- tant notational feature is that Action diagrams describe the performer of each activity; i.e. what actor/actor group (actor role) or which IS that is supposed to perform the particular activity.

In addition to the basic notation for action objects shown in Fig 6-6, it is possible to, as shown in Fig 6-7, distinguish between:

! Encapsulated information (i.e. not directly readable by hu- mans),

! Stores of action objects (used when activities add action objects to already existing quantities), and

! Knowledge (i.e. not externalized information that exists within some human actors mind)

Some activities (in Action diagrams) are delineated to be interac- tive with several performers, e.g. [Customer  Salesman  System]. In- teractive activities might be one-way [A  B] (from one performer to an- other) or two-way [A  B] (a dialogue between performers), see Fig 6-8. The two-way interaction is the most common one but one-way interac- tion is typically the case with, for example, reports and orders.

Encapsulated information.

Store of action objects. Applicable to both information and material.

Knowledge, which has not been externalised. Non-action. An action object that is the re- sult of an omitted action (i.e. an omission).

Fig 6-7: Special notation used for encapsulated information, stored action objects,

knowledge, and non-action in Action diagrams.

In addition to performers, the physical location where an activity is to be performed can be shown in Action diagrams by adding an asterisk and the name of the location after the performer list (see Fig 6-8).

Delivery [System  Deliverer  Customer] * Warehouse

Goods Inventory

list

Activity with several performers, named location and resulting action objects.

Fig 6-8: Notation used to show several performers and activity location in Action dia-

grams.

One important aspect of Action diagrams is their semantic power to describe action logic (see Fig 6-9). It is possible to describe sequential ordering of activities (i.e. the flow aspect), alternative activities (decision points), conjunctive activities (combinations), triggering (initiation) of activities (by time or communication), interruption of activities (by time or communication), contingent activities (i.e. activities occurring only sometimes), condition for activities, and parallel activities.

Ordered sequence of activities with ac- tion object as result and prerequisite respectively.

Suppressed action object. To be used only if the meaning is clear from the context, to increase readability. Ordered sequence of activities with no intermediate action objects.

OR OR Alternative. AND AND Conjunction. IF Condition WHEN Condition

Condition for action or action object. Often used in combination with alterna- tives and combinations.

POSS Occasional action or action object

(‘POSS’ is an abbreviation of ‘possibly’) Activity triggered by communication.

Point in time Activity triggered by time.

Activity interrupted by communication.

Point in time Activity interrupted by time.

Parallel activities.

Fig 6-9: Basic notation to describe action logic in Action Diagrams.

A contextual descriptive approach is to be preferred when working with Action diagrams. Each Action diagram describes a business context within a business process. Different Action diagrams are related to each

see Fig 6-10). The demarcations of each Action diagram (i.e. business context) are arbitrary; thus, an analyst is free to choose appropriate boundaries for each described context.

Sequential connector to/from another Action diagram. The Ref. Code of the connected diagram is shown in the circle. Hierarchical connector to another Action diagram that shows a decomposition of the connected activity. Fig 6-10: Connectors used in Action Diagrams.

Action diagrams make it possible to model and design the business and its information systems as an integrated whole. The actions of dif- ferent performers – human actors and/or information systems (internal and/or external to the organization) – are described as a whole. Action diagrams can thus be used to identify and delimit IS action. Such actions are described as integral parts of the business process. To say that IS actions are derived from the business process design is one way to put it. That business process design includes design of IS actions is equally cor- rect. This counts for both interactive IS action (performed together with a user) and automatic IS action (performed by the computerized IS it- self). The Action diagrams also show activities performed as a conse- quence of IS action. These IS-related actions form what we call usage situations, which can be classified as (1) interactive, (2) automatic, or (3) consequential (cf. chapter 3), and are used as a basis for delineating In- teractive and Automatic usage Situation Proposals (see section 6.5).

Fig 6-11 and Fig 6-12 show examples of Action diagrams describing two connected business contexts. The first diagram (PurInq, see Fig 6-11) describes how feasibility checking of raw material is performed at The Paper Mill. Feasibility checking is performed to ensure that enough raw material is either in stock or ordered before an enquiry or order from a customer is acknowledged. The second diagram (PurAck, see Fig 6-12) describes how purchase order acknowledgements from suppliers, and deliveries, are received and registered. In addition, the second dia- gram also shows an activity ‘Move raw material’ that might occur when receiving raw material, but which might well occur in isolation. This ex- emplifies the freedom to choose arbitrary boundaries for business con- texts during analysis.

ACTION DIAGRAM

Series

The Paper Mill

Creator PÅ Date 21.4.99 Version 1 Ref. Code PurInq

Concerns: Purchase – Feasibility (material)

PO Feasibility check (material) [Buyer  MA]

Incoming raw material Prognoses Inquiries Ack. cust. orders Stock quantities Purchase orders Purch. order acks. OrdInq _OrdOrd Feasibility answer (material) OrdInq OrdOrd Req. material

quantity _{Lack of raw} material Prod-A PurSto OR New inquiry New order OR

Raw material purchasing [Buyer  MA] Purchase orders Supplier info. Purchase order [Supplier]

New purch. order

acknowledgement Invoice

PurAck PurInv PurAck Purchase

ACTION DIAGRAM

Series

The Paper Mill

Creator PÅ Date 21.4.99 Version 1 Ref. Code PurAck

Concerns: Purchase – Customer order acknowledgement

PurInq

New purch. order acknowledgement PurInq Purch. order acks. Incoming raw material Purchase orders Consignment note

Register purchase order acknowledgement [Buyer  MA]

Register delivery [Receiver  MA]

Put raw material into warehouse [Receiver]

Stock quantities

Move raw material [Receiver  MA]

Stock quantities Raw material WHEN Warehouse needs to be restructured Purch. order acks.