Process Modelling

Historically, professionals and academics used process modelling to evaluate and optimise manufacturing operations, and determine information flows (Berki, Georgiadou & Holcombe 2004; Bernus 2003a; Noran 2004). More recently, process modelling has been used to map business processes IS interfaces (Berki, Georgiadou & Holcombe 2004; Molina et al. 2005; Naudet et al. 2010). Process modelling was widely used in EA to illustrate the organisation environment (Chatha, Ajaefobi & Weston 2007; Noran 2004; PLAIC 2001), and in ISD methodologies to elucidate data requirements for systems development (Alter & Browne 2005; Shen et al. 2004; Yourdon 1989). As discussed, process modelling formalisms were underpinned by requisite ISO guidelines. Bernus (2003a, 2003b), PLAIC (2001), and Noran (2004) have provided comprehensive examples of these standards and their application. However, confusion remains regarding the semantics of modelling methods and formalisms. For example, some literature classified process modelling as all-embracing while others categorised formalisms according to their dynamics, purpose (data or process centric), and level of integration (high-level or low- level).

The position taken herein was that process modelling covered several core formalisms that included; the IDEF series (Chatha, Ajaefobi & Weston 2007; Shen et al. 2004), petri nets (Grossman, Schrefl & Stumptner 2008; PLAIC 2001), unified modelling language (UML), data flow diagrams (DFD) (Thi & Helfert 2007), extended mark-up language (XML) (Dillon et al. 2008; Liegl 2009), and multi-level (Gelman 2005) and network (Bernus 2003b) hierarchical

models. Models were differentiated by their respective libraries (or ‘symbols’), which from a systems perspective, represented the common artefacts; system inputs and outputs, and ‘sources’ (persons, organisations, departments, and IS) (Burch 1992). Bernus (2003b) and PLAIC (2001) have compiled comprehensive lists of process modelling formalisms and their associated symbols.

Burch (1992) considered the key aspect of modelling was modularising a system (or objects) into manageable parts. The example he provided was based on manufacturing assembly lines where each component was independently developed but united by a common interface. Burch (1992, p 33) interpreted this practice as systemic modularisation, a process that ‘reduced complexity, increased simplicity and improved maintainability’. He also believed the practice would greatly benefit ISD. The modularisation supposition proposed all components within a system be identified and analysed to determine interdependencies (or common interfaces). Similarly, EA, and other like methods, decomposed organisation components to their lowest denomination (or sub-system) by abstraction using formalisms. Taking this approach, in an organisation environment, allowed each component, and component relationship, to be assessed and managed in terms of performance, efficiency, duplication, and potential change impact.

An example where process modelling has been used to identify and modularise a process activity is the ‘library loan’ example illustrated at Figure 12. In this example, a high-level process was decomposed and compartmentalised into paralleling activities. Seemingly, if a change occurred within the library loan process, the practitioner would be conscious of potential impacts on modules within that process.

Figure 12: Create a Loan Process Model (Thi & Helfert 2007, p 10)

In reality an organisation has multiple components (modules) involved in a variety of processes. Grouping the components into an ordered arrangement provided a greater insight and approach for managing the component sub- levels (or layers). For example, converting the library loan process model, shown at Figure 12, into a hierarchical function model, shown at Figure 13, enabled the ‘library loan’(0) activities to be grouped according to their sub- processes. The sub-processes have been labelled and numbered; ‘select document’(1), ‘request a loan’(2), ‘create a loan’(3), ‘reader information check’(4) and, ‘request check’(5), etc. In grouping these components the entities ‘reader’(0) and IT ‘system’(0) (or repository) were identified. Five systems were identified in the library loan example, which were labelled as sub-systems; ‘loan’(1), ‘copy’(2), ‘reservation’(3), ‘document’(4), and ‘request’(5). The researcher made the assumption that, in reality there would be multiple readers using the loan system; accordingly, the entity ‘reader’ was divided into sub-levels. Given the library loan example was a high-level process model, it would be prudent to assume that within each sub-process there would be related lower-level activities and tasks. Although these sub- levels were not reflected in the hierarchical function model, the reality was that such phenomena do exist.

Figure 13: Hierarchical Function Model

The hierarchical function model was valuable in that it indentified and grouped the library loan components and their sub-levels. However, the model failed to elicit the interfaces between the components and component sub-levels. The hierarchical network model, shown at Figure 14, provided a more accurate and dynamic perspective of the library loan process. For example, the network model identified the components process(0), reader(0), and system(0) as descriptors or high-level components (or entities) involved in the library loan process. These entities were demonstrative rather than party to the process dynamics. Put simply, the core entities of process(0), reader(0), and system(0), were components of the library loan process; however, the process dynamics or entity interfaces occurred at the entity lower-levels, i.e. sub- process, sub-system, and reader instances. The hierarchical network model was informative in representing the process dynamics, which otherwise would have remained opaque.

Figure 14: Hierarchical Network Model

Analysis of the library loan interactions can be described as follows:

0. entities reader(0), process(0) and system(0) comprise the library loan process;

1. reader(1) interacts with sub-process(1) and system(1);

2. reader(1) interfaces with sub-processes(2) and (4), and system(4); 3. sub-process(2) triggers sub-process(5) which interfaces with system(2);

and

4. sub-process(3) interfaces with system(1) etc.

Inevitably, this analysis must be repeated for all components within the library process and, moreover, analysis must be continued down through the component sub-levels. Add the fact that there maybe other entities (or parties) participating in the process and interfacing at various sub-levels, it is clear that complexity increases exponentially with the number of entity instances and sub-levels involved in the process. While the model shown at Figure 12 was an over simplification of a real phenomenon - given the example was based on one reader and one process instance, whereas in reality there would be multiple processes and other involved parties - it demonstrated the multiplicity

of interfaces and dynamics of the library loan process. The formalisms shown at Figures 13 and 14, defined and illustrated the interactions between entities and the entity sub-level. However, the models were limited in their capacity to accurately depict complex, multiple entity instances and multi-layer interdependencies. The practice of capturing and illustrating these complexities was better suited to a relational model.