Interaction design and business-process modelling

There are many different BPM methods that have been used with varying degrees of success. Most of them are based on visual techniques, i.e. they are usually a kind of diagram. The right modelling language has to support two different aspects of business processes. Structural aspects emphasise entities and relationships within the model. The model presents what each entity looks like and what each entity does.

Behavioural aspects externalize the order in which things happen and under which conditions. This includes the matters of time, sequence and contextual scenarios.

Flow charts are among the most frequently used diagrams for process modelling.

The notation also is very popular in SE and UE (see Chapter 4). The business-process modelling notation (BPMN) is more specifically targeted towards business-process modelling. The idea behind BPMN is to provide a notation that all business people can understand and apply (Business Process Management Initiative 2008). UML is also recognized as a BPM language. Reasons for its increasing importance for proc-ess modelling are its popularity, its international acceptance and its standardization.

The popularity of UML for BPM can support the search for shared means of com-munication among stakeholders.

Most business-process notations, and BPMN is an example, have a similar struc-ture to represent the sequence of work and the decomposition of the organizational complexity (see Chapter 2). Activities, linked with each other, and decision points, providing other paths to follow, have a deterministic graph representation. They can be decomposed into other activities and these other activities can be decomposed in turn, forming a tree representation where a new level is created when motivated by the necessity to better describe what is to be done. With the introduction of an ap-propriate notation for business-process modelling, an organization has to overcome three „evils of life‟ for modelling (Holt 2005):

 Complexity: in the case that information is unstructured or the overall infor-mation architecture and relationships are very complex.

 Lack of understanding: if the source information is poorly understood, even well-working processes are not very robust in the face of change or tailoring.

 Poor communication: if process knowledge must be shared between several individuals, everyone needs to externalize their personal experience. Espe-cially where a process is a tool used in daily business, documenting all perti-nent knowledge is sometimes difficult (tacit knowledge). Moreover, very badly written text can lead to misunderstandings and ambiguity.

Although BPMN is also a widespread modelling language, it is too narrow to meet all the requirements of process modelling. Stakeholders all have a different viewpoint as to a process's requirements. In fact, within any process there will be a number of viewpoints. Accordingly, (Holt 2005) has presented seven different views that need to be considered during process modelling (see Table 13). Four of these views are realized by structural diagrams, for which BPMN has no support. The re-quirement view specifies the overall aims and is essential for validation. Require-ments need to be checked periodically, as they change over time. Stakeholders need to know if the process requirements have changed. The process-structure view speci-fies the structure of concepts and terminology used and helps to pin down the

lan-Modelling techniques

Business-process modelling and the three evils of life

Seven views of business processes

guage used. The process-content view identifies all the processes of interest for a system. For each of these processes, the view encourages the analysis of actual re-quirements and process-description breakdown. The stakeholder view identifies shareholder roles within an organization, project or system. This view presents shareholders in a classification hierarchy, which can be done in UML class dia-grams. The process-behaviour view describes the behaviour of a single process.

Each process of the process-content view has a process-behaviour view. The behav-iour view can be modelled in UML with an activity diagram. The information view is concerned with identifying the key artefacts from the system and then identifying their inter-relationships. This is to guarantee inter-process consistency in order to make sure that processes are compatible. The process-instance view ties everything together and links back, showing instances of processes and stakeholders and how they interact (Holt 2005).

Table 13: Support for important views in UML and BPMN; based on (Holt 2005)

View UML Representation BPMN Representation

Requirements Use-case Diagram: requirements shown as

use-cases, stakeholders as actors No representation: stakeholder information only found as swim lanes, no concept for requirements

Process Structure Class Diagram No representation

Process Content Class Diagram: process as classes, artefacts

as attributes; activities as operations No representation: understanding content through looking at diagram in detail

Stakeholder Class Diagram: each stakeholder shown as a

class No representation: stakeholder information only

found as swim lanes Process

Behav-iour Activity Diagram: stakeholders shown as swim lanes, activities as invocations, arte-facts as objects

Business-process diagram: stakeholders shown as swim lanes, activities as activities, artefacts as data object

Information Class Diagram: artefacts shown as classes No representation: artefacts only found as data objects on business-process diagram

Process Instance Sequence Diagram: each process shown as

a lifeline Business-process diagram: connected

sub-processes show executions in sequence

For each view, from one to several different diagrams are necessary. (Holt 2005) suggests class diagrams to model structural aspects of a process and activity dia-grams to model behavioural aspects. Activity diadia-grams are derived from flow charts and can be said to be the UML-like notation of them. Sequence and use-case grams can be used to model behavioural aspects on a higher level. Use-case dia-grams also contribute a requirements view of a process. It can be used to model the context of a system from the perspective of different stakeholders. Most process models have to contain a very large number of processes. It is therefore important to partition processes into smaller parts. When the key features of processes have to be defined, it is important to understand the activities that happen in the process. Ac-tivities are usually iterative although they may have been modelled in a linear fash-ion. Relationships and interactions between elements of a process can be shown through graphical paths in the process model.

“Though there are several process notations used in the industry, we find the basic information in business processes having to do with „who‟ will do which task „when‟

in the business process, the sequence of business tasks, and what are the inputs and outputs of a task, to be the most useful set of information for starting a user interface Structural and behavioural view

shared with other stakeholders. Concerning the UI, interaction designers must have a clear understanding of the processes of an enterprise. In many application domains, e.g. banking, the process view has significant influence on the functionality and us-ability of the software and the UI. This is especially the case with applications that directly map the nature of a process to the UI, such as form-based account or credit application processes (banking) or configuration tools for consumer products. The information buried in various BPM artefacts must therefore be visually externalized to be able to design for user experience. (Sousa et al. 2008c) accordingly argue that business processes alone are a limited representation for visualizing the information needed for UI design, because business processes (1) ignore how an activity is ac-complished, (2) do not encompass all tasks that are intrinsic to user interaction, and (3) are not detailed enough to describe individual user behaviour. Considering the importance of user interaction, business processes must therefore be aligned with the notations of SE and IxD.

Figure 20: Mapping of BPM and task model; from (Sousa et al. 2008c)

(Sousa et al. 2008a; Sousa et al. 2008b; Sousa et al. 2008c) propose task models as an intermediate modelling language that could bridge process modelling and UI development. The task model represents the tasks performed by users when interact-ing with a system. Task models are a strong representation for UI design because they contain decomposition in a hierarchical structure, which provides an overview of the user interaction. In Figure 20 the six decomposed layers of the business-process model are associated with the hierarchical levels of a task model. The asso-ciation starts with the end-to-end process layer because the business domain repre-sents the overview of the process architecture. Changing from a business perspective to a user-centred perspective, it is necessary to focus on certain aspects of user inter-action. Task models can be used as a common denominator between business proc-esses and UI design. Business procproc-esses are often an abstract representation of the business tasks. They differ from task models, which are a concrete set of tasks that help UI designers visualize what could happen during user interaction. As a result, business-process models can be used as requirements, not in direct connection with the UI design, but for the creation of task models before the UI design (Sousa et al.

2008c).

BPM and Task models for UI de-velopment