Modelling Process Flow in Complex Systems

0 downloads 0 Views 3MB Size Report
An Activity – results from the completion of a set of Tasks by a set of Agents .... that there are no default semantics in this type of modelling, which means you can.
CAMBRENSIS

Modelling Process Flow in Complex Systems

MODELLING, MONITORING, MANIPULATING AND MANAGING? DAVID SLATER

MODELLING, MONITORING, MANIPULATING AND MANAGING COMPLEX SYSTEMS D S AVID LATER

ABSTRACT Engineers need to model / simulate systems to test out designs and ensure they work, preferably before they fail in practice (now an old fashioned way of improving system design!).This is even more the case these days as systems get more and more complex and operate in a more risky but more risk averse environment. Increasingly they are mixtures of sophisticated components, human operators and artificial intelligence, so it becomes an impossible task in system design, to calculate, predict and allow for every situation and variation that will be encountered in real world operating conditions. Reality is too difficult, often counter intuitive and legally too late. So if it is too difficult to model component by component, we need other ways of making the problem tractable because the answers required are becoming more and more important. One approach is to model just the functions needed to perform the tasks designed for the system as abstract entities, at the level of detail required for analysing that particular operation. It must of course, be capable of being developed, or abstracted to different levels of detail and also to be able to show all the other functions with which the prime function needs to interact to perform successfully. This 3D world of functions is then a model of what is happening as a network of interactions. The status and effect of these interactions can be teased out qualitatively for a particular snapshot of how a system performs in achieving that action, or how these interactions develop in a sequence of actions or steps to execute a process. Thus the model is simulating the interactions and interdependencies that emerge in a more realistic operating environment of a wide range of influences and interacting functions. Since these interactions inevitably vary in practice reflecting real life compromises and unforeseen developments, the effects of these variations also need to be simulated. There are a number of current approaches to modelling processes and each has its strengths and limitations. This note suggests that by utilizing in turn, the methodology which addresses a certain concept most promisingly and then combining them using a Metamodel (BPDM), a better more useful and complete schema for managing processes in general, can be assembled.

2 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

It proposes to utilize BPMN for the overall framework and the choreography of tasks required from different components, individuals, agents and organizations to deliver the outcome of the process successfully. For individual tasks, instantiations of the FRAM (a development of SADT) is proposed to map the activities involved/ required. Here the messages from the BPMN flowchart are essentially the links /Aspects to the functions required for the tasks. If we employ the FRAM function description, the BPMN Pools house the functions needed to supply the resources and meet the preconditions required. The BPMN event time line provides the time link and the operation of the function is then “controlled” by the metamodel “choreography”. As these functions can be linked as Bayesian Belief Nets (Rees, Comer), probabilities of successful outcomes can be predicted form measures of “availability” of background resources, etc. These can also be obtained directly from external (real and real time) sensors. Having a time line and choreography then allows the BBN steps to be combined dynamically (DBBN’s) to give a visual simulation of the progress of the process. All this has been demonstrated in 2D, as time slices using standard Functional Resonance, and Business process Notation modelling software. Modelling the functions as nodes and interactions as Bayesian dependencies allows the quantification of probabilities of outcomes for predictive purposes. But this universe of interactivity needs a more useful, useable, versatile way of visualising/ interrogating its behaviour; it needs 3D, dynamic simulation. (Minority Report)Virtual Reality games software would seem to be an ideal candidate for achieving this. It is worth exploring if and how the new SpatialOS platform could facilitate this. Key words – BPDM, BPMN, Bayesian, Dependency Models, FRAM

INTRODUCTION We live in a world of ever increasing complexity and interdependence. Just one example is the currently fashionable Internet of Things (IOT). When dealing with systems that have to operate in this seemingly infinitely coupled environment, we often need a model to try and understand what is happening; besides the obvious designed perturbations we could initiate unilaterally. But most models are at best snapshots in time. The real world is a constantly changing, evolving dynamic network of influences. These are naturally variable and the random combination of actual as opposed to expected effects, can cause unexpected emergent behaviours that are not necessarily desired, or appreciated, by designers and operators of such systems. So the question is how can we usefully and realistically (not just theoretically), model this world wide web of interactions, This must not only give a true static representation of what is happening instantaneously, but be able to predict the full sequence of events that is often necessary for successful outcomes of these activities. Most people would agree that the above is self-evident, but the challenge is now to define what we mean by each of the terms casually mentioned above; and how to achieve this desired result in practice. The first requirement therefore is to define a common understanding of all these above terms in this particular context. We need an Ontology.

3 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

SEMANTICS AND ONTOLOGY – NOMENCLATURE An ontology (according to Wikipedia) is a formal naming and definition of the types, properties, and interrelationships of the entities that really or fundamentally exist for a particular domain of discourse. For our purposes, for the sake of argument, we can define:

A Process – as a sequence of activities needed to produce a desired outcome



An Activity – results from the completion of a set of Tasks by a set of Agents



An Agent can initiate a specific group of Tasks



Tasks are performed by the interactions of a number of functions



Functions can be defined to different levels of detail from sub functions to components.



An Event can occur as the outcome of a step. Task, activity or process



A step in the process or an instantiation is a time snapshot of these functions interacting

There are, in addition hierarchies implied in this classification of -

Functional Abstraction –or Levels of detail

-

Time of occurrence in the sequence

So we can now apply this taxonomy to describe formally to the sequence of interactions required for the process to complete successfully

INHERENT PROBLEMS WITH THIS APPROACH Historically, the modelling of such sequences have been employed to ascertain why processes do not behave as envisaged – (i.e. fail). The focus has been driven by an approach to systems which relies on their reliability or “safety” (sometimes referred to as a SAFETY I approach).Nowadays there is more interest in understanding how the system manages to work in practice and the resilience needed to ensure its successful operation (now referred to as SAFETY II). In the first approach, system behaviour models were built using cause consequence, Fault Trees and Event trees, “Bow Ties” and Barriers, etc. These methodologies are useful forensically to discover what went wrong after the event, when the sequence and interactions and interdependencies can be dissected out of accident data. But for proactive prediction of systems’ behaviour, particularly when actual processes do not always behave exactly as planned sequences of well-ordered events, they are not much help. In real systems, naturally variable interactions can cause interrupted sequences to produce emergent behaviours to surface unexpectedly, So to model such real world processes (a priori), to check, edit, resolve issues, a designer needs more. This note attempts to set out an approach utilising and combining a number of established methodologies to achieve this aim.

THE METHODS There are a number of existing tools and methodologies that we propose to build on to achieve the overall objective. This section sets out the various features we intend to incorporate into the framework. 4 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Many methods exist for sketch out how a process is supposed to work, Process Flow Diagrams, Flow Charts, Gannt Charts to show what the expected sequence of events is supposed to be, . They can even pinpoint the critical interactions that need to happen, when. Functional interactions can be displayed and analysed as static diagrams and the probability and extent of their effects se interdependencies can be predicted (Bayesian Belief nets).What we lack is a way of bringing all this together in one consistent approach. The methods we wish to build on and propose for consideration are:1. Process Flow utilising a BPMN approach 2. 3D interactions of functions from SADT 3. Interdependence and variability of functional interactions from FRAM 4. Levels of abstraction and Hierarchies of influences from Accimaps 5. Agent identification and combination – Patriarca, Rasmussen? 6. Probability of effect – BBN 7. Identification of resonances in FRAM functions – Patriarca (Monte Carlo) 8. Sequencing, visualisation - FMV Hill and BPMN 9. Dynamic development – DBBN 10. Performance prediction – Resilience Matrices – Albery For linking these different methods together we propose to utilise the “Common Standard for data exchange and Modelling” (BPMDN)

BUSINESS PROCESS DEFINITION METAMODELING (BPDM) “The Business Process Definition Metamodel, (BPDM), is a standard definition of concepts used to express business process models (a metamodel), adopted by the OMG (Object Management Group). Metamodels define concepts, relationships, and semantics for exchange of user models between different modeling tools. The exchange format is defined by XSD (XML Schema) and XMI (XML for Metadata Interchange), a specification for transformation of OMG metamodels to XML” (Wiki). In the next sections we look at each of these approaches we will attempt to link together in turn.

BUSINESS PROCESS MODELLING NOTATION (BPMN) Burnap et al (ref) have produced a graphical implementation of the Object Management Group’s, (OMG) BPMN process flow modelling approach. It builds on BPMN 2.0 which has features “that include     

Aligning BPMN with the business process definition metamodel BPDM to form a single consistent language. Enabling the exchange of business process models and their diagram layouts among process modelling tools to preserve semantic integrity. Expanding BPMN to allow model orchestrations and choreographies as standalone or integrated models. Supporting the display and interchange of different perspectives on a model that allow a user to focus on specific concerns. Serializing BPMN and providing XML schemes for model transformation and to extend BPMN towards business modelling and executive decision support.”

5 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

This approach defines a process that includes Events, Tasks, Activities, Gateways and Connections, see below. Task

A task is a unit of work – the job to be performed. It is an atomic activity within a process flow.

But one of the crucial features we can utilize is that all the detailed resources that are needed in any Task can be found in a common “pool”. The BPMN methodology then links these items together in the way necessary to make the process work. The structural elements include the selection of symbols set out below. The first constrains the timing of the process (Start, Stop), which consists of a sequence of tasks and activities, controlled by Gateways and connected with flow arrows

Fig. 1 – BPMN Symbols for constructing a Process Flow Scheme

These symbols then define a “timeline” initiated with event symbols and defining tasks and decision points in a flow chart. (See example below)

Fig. 2 – A simple BPMN flow scheme

In the BPMN approach, the above figure represents a “swim lane” down which a process proceeds.

6 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

SWIM LANES The second crucial attribute of this approach is that the modelling allows for interaction between parallel processes in the same “pool” but in separate swim lanes. (see example below)

Fig. 3 – Parallel Processes in their “Swim Lanes”

COLLABORATION But in practice these lanes (sub processes?) are not occurring in isolation, they are in the same pool. This means that we need to define ways of linking these various activities and tasks across the lane boundaries. In BPMN this requires a further detailing of these lanes as a “collaboration” diagram. In BPDM terms so it can be choreographed. This is achieved using Connections, carrying information or rules between activities. An example given in BPMN tutorials is the Pizza collaboration, shown below

7 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Fig. 4 – Processes “collaborating” across swim lanes.

The tutorial text emphasises that:“Note that there are no default semantics in this type of modelling, which means you can model collaboration diagrams to show the interaction between business partners, but also zoom into one company, modelling the interaction between different departments, teams or even single workers and software systems in collaboration diagrams. It is totally up to the purpose of the model and therefore a decision the modeller has to make, whether a collaboration diagram with different pools is useful, or whether one should stick to one pool with different lanes, as shown in the previous example”.

DEPENDENCY MODELLING The successful completion of any particular task can “depend” upon any number of factors and influences. It is thus in Bayesian terms, a conditional probability. There is an open group standard that sets out a methodology to develop and link “dependency” models for individual, or a sequence of tasks and activities. It can be applied to any complex system such as an organization, a company, a project, a machine, a doctrine, a diagnostic, a government, a charity, a business model, or a village fête. Since there is no word that adequately covers all these types of systems, we will use enterprise.

8 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

We won't call it a system since that could mean the computer used to do the dependency modelling. The principle behind dependency modelling is that ideally the analyst should not have to work out all the things that could go wrong with his enterprise. Instead, the analyst’s responsibility should be limited to providing a sufficiently accurate model of the enterprise. While we can't totally achieve that ideal, dependency modelling and the tools that support it go a long way towards it. So, in dependency modelling we build an abstract model of the enterprise. To give the flavour at the slight risk of getting ahead of ourselves, here is a simple model of some of the entities found in a home together with their inter-dependencies. The goal is a properly functioning household, labelled home OK.

Fig. 5 – The demonstration iDEPEND model from the Open Group Standard

This means that a prediction of the successful completion of an overall BPMN flow conditional on all the interactions specified can be made quantitatively. A good example is in the modelling of fire and explosion “barriers” (or tasks that need to be completed successfully to implement a safety system) for offshore oil and gas installations. But we can look in more detail at the TASKS.

THE FUNCTIONS NEEDED TO PERFORM THESE TASKS To develop / detail better, the modelling of the tasks, we can use an extension of the successful software tool SADT. Structured analysis and design technique is systems engineering and software engineering methodology for describing systems as a hierarchy of functions. (and is the basis of a structured analysis modelling language). The building block (the function) is represented as a black box with four types of interactions, which processes its inputs with controls and mechanisms to produce outputs. (see below).

9 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Fig. 6 – The SADT Building Block

This fits very well the way a Task is modelled in the BPMN schema. This is easily crosslinked with connections and also the function itself can be decomposed into sub functions (Maria).

Fig. 7 – How SADT models Functions within Functions

The classifications of the interacting influences into controls and mechanisms, as in the original SADT can further be extended. An example of such an extension is the Functional Resonance Analysis Method FRAM. Here just as in the BPMN black box and in the SADT boxes the function is only defined in terms of what the function, which the box represents, is supposed to produce, the output, not the detailed mechanics of how it is produced. The inputs into a SADT box are defined as interdependent. Aspects required by the function, which the FRAM box represents, are produced by other functions. These inputs, which are also called Aspects (Hollnagel, 2014) or that which the function needs to function, can include inputs, preconditions, resources, controls and time constraints as required (Figure 4).

10 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

The classifications of the interacting influences into controls and mechanisms, as in the original SADT can further be extended. An example of such an extension is the Functional Resonance Analysis Method FRAM. Here just as in the BPMN black box and in the SADT boxes the function is only defined in terms of what the function, which the box represents, is supposed to produce, the output, not the detailed mechanics of how it is produced. The inputs into a SADT box are defined as interdependent. Aspects required by the function, which the FRAM box represents, are produced by other functions. These inputs, which are also called Aspects (Hollnagel, 2014) or that which the function needs to function, can include inputs, preconditions, resources, controls and time constraints as required (Figure 4).

Fig. 8 - A FRAM Function “Box”.

Also, these FRAM functions can be easily transposed (automatically) into BBN’s. Time

Control

T

Input

Activity/ function

I

Output

C

P

O

Function

R

Precondition

Output

Resources (execution Conditions)

Control

Resources

Time Input

Precondition

Fig. 9 – FRAM Function to BBN for BBN system analysis. (Adapted from Slater, 2013)

These BBN’s can then be quantified by the Open Group software tool. IDepend (ref) (see below) The output is the same as for the Barrier example given earlier, except that we now have a structured way of identifying and specifying the aspects, influences and interactions required by the BPMN connections. 11 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Fig. 10 – The iDEPEND BBN of the FRAM Function (The “Barrier”)

The FRAM function is essentially a dependency model of how an output of a function depends on the influences of its aspects and thus is directly transposable into the iDEPEND equivalent model above. If there are values for the probabilities of the statuses of these aspects than a conditional probability of the output can be calculated. An example is shown below of the oil and gas safety barriers working successfully

Fig. 11 - Predicted probability of safety system performing successfully rom the barrier BBN

12 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

A shown below, BBN’s of more complex systems can readily by constructed and evaluated this way.

Fig. 12 – One of the more complex BBN’s from the CATS Report (Ale et al)

THE OVERALL FRAMEWORK Having identified and described the constituent components, we can now start assembling the overall framework. First define the “system”. Here we need the metamodel (BPDM) to structure the business process we are interested in, semantically using a consistent ontology. Layers, Agents, processes, activities, tasks, components, down to the BPMN “atomic” level. The BPMN approach defines well the processes and how they fit together, choreographed and coordinated in the system space (or Pool). Because we have the option of drilling down into sub processes and components, the swim lanes should be visualised as three dimensional offering an additional depth of interaction for a better analysis. It also visualises graphically, the flow of the process through this 3D space as a function of time. Into this Pool then go all Fig. 13 – FRAM functions within FRAM functions the functions and influences (aspects) which can affect the outcome of any processes happening in the system, planned 13 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

or unplanned (emergent resonances in FRAM terms).PMN is then used to set up the event sequence together with all the relevant swim lanes and “background” functions which bring in external influences across the swim lanes

Fig. 14 – The workspace from the FMV (Rees)

Each function is then defined with all its aspects. It is proposed to utilise the FRAM Model Visualiser (Rees et al) to accomplish this.(Figure 14 above) It is proposed to define the Tasks, or activities in the BPMN sequence as (high level) “Functions” using the FRAM approach. This allows specific sub tasks to be modelled as instantiations in which a number of links have to be made between functions depending on the aspects defined for that step; it also allows the aspect links to find their own targets anywhere in the system where there is a common aspect. This allows links to be made deliberately or inadvertently as emergent behaviours, between any functions in the system with common (uniquely specified) aspects as a task is executed as a system “instantiation”. The

Fig. 15 – External Feed Dialogue Box for iDEPEND

14 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

preconditions and resources are quite straightforward in that they identify where they can find the status of these support needs which we have defined as success dependent aspects. In the FRAM/iDEPEND solution; external sensors can be used to input these status probabilities from sensors. Or they can be estimated or pre-set from input dialogue sliders

Fig. 16 – Manual probability iDEPEND dialogue box

The Output probabilities can then be displayed on a FRAM instantiation as below (Bellini)

Fig. 17 – Screenshot from the FRAM modelling work screen from Project RESOLUTE

This allows tracing of critical paths, links etc. needed to make the Process work (see Below But this display also allows us to drill down to the underlying functions and across “swim Lanes” to different Agents etc. 15 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Fig. 18 – An abstraction hierarchical scheme for implementing FRAM in FRAM from Riccardo

But the overall flow scheme, task definitions and interrelationships are as defined by the BPMN conventions (see below) as Functions/ Tasks in ordered “Swim Lanes”.

Fig. 19 – A BPMN flow scheme using FRAM descriptions of Tasks.in “Swim Lanes”

16 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

This in a three dimensional view of interactions can be regarded as representing the plan view or the horizontal plane. The figure below from Riccardo et al. shows how the Agent approach can be used to structure the elevation or vertical plane of interactions.

Fig. 20 – A BPMN using FRAM tasks identified with specific Functions and subfunctions - Riccardo

These two planes can now be combined to create a three dimensional space for interactions to take place across both swim lane and abstraction levels. But we can extend this by using the x axis to represent a point at which the horizontal and vertical relationships can be displayed as a two dimensional step or instantiation. Thus this combined BPMN/FRAM/BBN approach, does offer a new perspective on the way in which to structure our model and visualise the individual time steps. Combining both the swim lane and the abstraction level hierarchies allows the other two aspect categories of the FRAM representation to be exploited systematically. Time and Control can now be developed and utilised formally to define process development. The Control aspect has two now possible modes of operation. 

The first is in the Choreography (messages) that are a feature of BPMN interactions between swim lanes. Background sources of these messages can be preprogramed to update the status of these messages as the control(s) on the function.  The second is similar in that it changes the control aspect status but it utilises event milestones as (status changing) decision points, such as gateways where control actions can be specified and enacted as emergent (not preprogramed) statuses. These then send this new status of the control aspect to the function at that point in the sequence The Time Aspect is even more interesting. In normal FRAM analysis, the time aspect is recognised as crucial, in that a function can:17 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

   

Start too early or late or not at all Not function long enough, or too long, Function too fast or too slow Cumulative use can deplete resources Precondition

Input

Output

Task 1

Control Start

Precondition

Resource

Input

T1

T3

T2

Precondition

Input

T = 5 secs

Control

Control

Time T6

Resource

T7

T8

Precondition

Output

Task 2

Output

Task 3

Control

Time

Resource

Time

Resource

Output

Task 4

Input

Control

Time

Fig. 21 – A BPMN Time line used to implement the Control and Time FRAM Aspects

The Event line and milestones offers a way of playing through the sequence of tasks needed for a process (see Clayton Tunnel Disaster example below), providing a temporal discipline

Fig. 22 – The Clayton Tunnel control process with the timeline showing clearly conflict between theory and practice

18 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

so that emergent behaviours can emerge and be identified As Is rather than As Imagined (Figure Below)

The Timeline can also label the FRAM instantiations / BBN as Time steps essentially converting the static BBN’s into Dynamic BBN’s (below)

Fig. 23 – BBN’s as Time slices which could be prompted by a BPMN timeline

DYNAMIC BAYESIAN BELIEF NETS (FROM ALE ET AL) “A DBBN consists of a sequence of sub-models (static BBNs), each representing the system at a particular point in time (time slice). The arcs between slices are drawn from the left to the right reflecting the flow of time, from the past to the future. For practical proof of concept purposes it is assumed that each time the BBN has the same structure.

Fig. 24 – Dynamic BBN updating possible by using the iDEPEND software 19 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Moreover, it is assumed that the state of any system described by a DBBN satisfies the first order Markov property, which says that the state of a system at time t depends only on its immediate past, i.e. the state of the system at time t-1. If these two conditions are satisfied, then the dynamic system can be represented by two successive time-slices, as in figure 25”.

Fig. 25 – The “emergent” structures of BBN’s obeying Markov’s rule

Each time-slice of a DBBN is in fact a static BBN on its own. So if we can model our process as a sequence of time slices, each of which is a swim lane / abstraction level two dimensional plane, the emergent behaviours develop in three dimensions.

Time Slices in FMV

Figure 26. - The 3D FMVBPMN BBN Time Tunnel

This additional ability to quantitatively model the development in space and time of BPMN process flow schemes now enables us to show how

20 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

      

Perturbations can be timed (out, in, too early too late, etc.) against a real elapsed time monitor. (Process clock?) The BBN’s of the FRAM instantiatiations of Tasks can be labelled as real elapsed time steps and stored sequentially Thus the Tasks involved can then be linked in an emergent sequence as a Dynamic BBN(ref) This can respond to real background sensor data in real time, or This can be displayed as a visual animation aid to (developing) situation management. It can be a valuable aid to management of “normal” business processes It can be particularly valuable in emergency response and condition (healthcare and machinery) condition monitoring.

SIMULATION AND VISUALISATION The development of the FRAM Model Visualiser (Rees) opened up the range of applications and users of the FRAM approach to modelling complex systems (i.e. involving real people as well as physical components). In the same way, BPMN offers a more consistent and disciplined approach to setting out and analysing / optimising business processes. BPMN again uses a high level description of the “Tasks” involved only being interested in their successful outcomes rather than physical components. Bayesian Belief Net modelling of what these tasks depend on then allows the linking of these Tasks and the prediction of the success or otherwise of the process. (BPMN/BBN). But this relies on predetermined structures and system behaviours which may not actually reflect reality. Detailing the structure of the individual Tasks and their non-linear interdependencies using the non-predetermined 3D FRAM approach then allows specific instantiations to be constructed in which behaviours “emerge”. FRAM functions substituted for Tasks can still be processed as BBN dependency models and their probabilities of successful operation estimated / quantified. It also allows the development of dynamic BBN sequences which may or may not reflect initial ideas of how they should behave. This can now be displayed as visual sequences in a modified FRAM Visualiser to demonstrate the inner workings and perhaps unexpected complications from theoretical (as imagined) compared to what would actually happen (as is).

APPLICATION AND DISCUSSION So how would this work in practice? An interesting case to try it out on would be the prescription dispensing example from Hollnagel. In his book Hollnagel uses it as a failure incident analysis example, but it sets out the issues involved and a procedure we can adopt as our test case. (ref) 21 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

In a SAFETY II world we could equally well look at it as an opportunity to design a process from scratch to achieve the result required successfully. (With sufficient resilience to absorb and deal with the vagaries of real life pressures pharmacists have to deal with).

THE EVENT On a busy January afternoon, a customer at a local Pharmacy in Sweden handed in several prescriptions, including one for a cough medicine for her daughter. On returning home she realised that she had been given a prescription lotion for a skin condition treatment. The case was duly reported and thoroughly investigated (and all the usual lessons were learned? What were they?). These types of investigations are usually aimed at finding out what went wrong; where did the fault lie? Who was to blame? What was the (ROOT) Cause of the Failure? One could “diagnose” – come to a conclusion/ hypothesis to test – that the wrong drug can be handed out if the Pharmacist inadvertently picks up the wrong drug and the subsequent procedures to check its correctness fail. We can model this as a fault tree which then shows that this was the case (What you look for is what you get?) and in fact both errors were made in this case. But what if we are more interested in how this process has worked successfully and satisfactorily. Yet was overstretched in this particular case. To do this we need a model that enables us to probe both the way in which individual steps are normally completed successfully but also that we have no issue.

MODELLING THE PROCESS INVOLVED Using our protocols, the first requirement is to identify the entities needed to carry out the process and park them in our “Pool”.

THE “POOL” There needs to be -

A function (F1) which hands in the prescriptions to start the process. A function (F2) to register the prescription as received. This prompts the pharmacist to fetch that drug from the store (F3) This function (F3) has several subfunctions that need to be available Check the prescription against the drug label (F4); Issue the right drug (F5)

The pharmacist then also needs functions to check the correctness of the drug he receives (F6) -

Check name and identification (F7) Check dose and recipient status.(F8)

There then needs to be a dialogue (two way) to verify these details (F9) (F10) The final function (F11) is the issuing/ hand over to complete the process of picking up a prescription. Each of these functions when exercised (executed?) can complete a task. THE SWIM LANES We need one for each “Agent”, say:-.

22 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

   

The Customer (s) The Pharmacist The computer The environment?

These Agents then exercise their functions in a sequence that is defined by the Process.

THE PROCESS 1. The first step or event is the handing in of the prescription which triggers the process, (T=0 ) 2. The second event is the pharmacist receiving and checking the prescription and registering its receipt on the computer. 3. The computer then will access the patient details, dose, etc. This will also guide the Pharmacist in the drawing of the right drug by 4. Checking the barcode and 5. Checking the dose and form is appropriate The final steps constitute the handover 6. A dialogue checking the recipient is the right recipient 7. has understood the dose, etc.; and 8. is aware of details and confirmed that this is the drug expected/ prescribed. The final step, is;9. the physical handover completes the process.

Figure 27 – The Prescription Procedure modelled in BPMN

We can now employ the BPMN ideas and notation to sketch out the steps that need to be taken in what order in a predetermined, linear sequence of steps. So Step 1 initiates the process with the customer handing in the prescription to be filled. In a SAFETY II analysis we would also be looking at how the process copes if the Agents did not stick strictly to the script. We could use something like a RESOP (an extension of the classic HAZOP procedure (refs)) to probe what happens if there is no actual or the incorrect prescription

23 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

handed in. Is it possible and what are the consequences of handing in too many prescriptions, too many customers at once, and so on? In Step 2 the pharmacist initiates the checking procedure with the computer. What happens if the computer is down, offline? Even worse is the prospect of a software glitch giving the wrong answers? We can take this down to the final dialogue, where we might worry that misunderstandings are always possible due to language, diction, culture, etc.? These are real possibilities, although they may not affect this particular step. For example, could the effect of the congestion of customers in step 1 cause the dialogue step 5 to be rushed and key details missed? So even this superficial examination of the process shows that neat linear sequences are not always sufficient and we need the facility to explore nonlinear interactions and emergent behaviours which can develop unexpectedly down the process chain and emerge due to unexpected combinations of natural variabilities in these interactions which we have to expect in the real world. Thus we need to model these tasks in a way that allows this behaviour to be picked up. That is precisely what the Functional Resonance Analysis Methodology is designed to accomplish. So we can replace the BPMN Tasks with FRAM functions and do the same RESOP to pick up the issues (Figure 28)

Figure 28. The Swim lanes with FRAM functions

24 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

THE TIME SLICES (INSTANTIATIONS ) Using the FMV software, we can create a picture of all the interactions at a particular time step.

Figure 29 – The instantiation or Time Slice for a BPMN Step This picture is then ideal to tease out the issues that inherent variability in the interdependencies can cause issues. Often this is done by inspection (Hollnagel) although a more formal record from a RESOP (ref) can also be used to generate a semi empirical Resilience Matrix (Ref) A version of the current FMV also allows us to examine and display indications of the effects of this “variability” of the interacting aspects. (Slater, 2015)The model is processed allowing 3 states, Too high (red), too low (green) and within acceptable limits (buff), in each of the time and quanta dimensions. Default values for Human, Technological and Organisational variability probabilities are built in, but like all the inputs to the model, can be readily customised and “what if” tested. (Shown in Figure 30 below) Additionally we can automatically build the BBN behind the system and look at predicted success and inferred Cost Effectiveness of changes, at least relatively accurately. The complexity of the BBN shown below (Figure 31), reflects the intricate pattern of interactions needed in real life between these “simple” functions. Constructing this without the essential FRAM functions as building blocks would require significantly more effort.

25 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Figurer 30 – FRAM functions displaying RAG bands

We can thus generate a BBN for each of the time slices in the sequence. Note the structure of the next BBN depends only on what instantiation has emerged in the last step (the Markow criterion). So the way in which the BBN’s evolve dynamically from step to step is not predetermined and cannot be predicted a priori. If these variabilities can be described by standard distributions, then a MonteCarlo methodology can be employed to pinpoint those that are critical “Resonances”. These are often unexpected and thus need the ability of this approach to model and probe these important nonlinear and non-sequential interactions (Black Swans) that inevitably occur in practice.

26 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

Figure 31 – The BBN generated automatically from the FMV instantiation

27 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

CONCLUSIONS The development of the FRAM Model Visualiser (Rees) opened up the range of applications and users of the FRAM approach to modelling complex systems (i.e. involving real people as well as physical components). In the same way, BPMN offers a more consistent and disciplined approach to setting out and analysing / optimising business processes. BPMN again uses a high level description of the “Tasks” involved only being interested in their successful outcomes rather than physical components. Bayesian Belief Net modelling of what these tasks depend on then allows the linking of these Tasks and the prediction of the success or otherwise of the process. (BPMN/BBN). But this relies on predetermined structures and system behaviours which may not actually reflect reality. Detailing the structure of the individual Tasks and their non-linear interdependencies using the non-predetermined 3D FRAM approach then allows specific instantiations to be constructed in which behaviours “emerge”. FRAM functions substituted for Tasks can still be processed as BBN dependency models and their probabilities of successful operation estimated / quantified. It also allows the development of dynamic BBN sequences which may or may not reflect initial ideas of how they should behave. This can now be displayed as visual sequences in a modified FRAM Visualiser to demonstrate the inner workings and perhaps unexpected complications from theoretical (as imagined) compared to what would actually happen (as is). It does seem that the BPMDN metadata standard behind the common XML based programming of proven BPMN, BBN and FRAM software tools would allow a simple combination of these approaches into a much more powerful methodology for assessing the viability of real business processes. Furthermore the models when established could be used to monitor and manage these processes in real time. Lastly the models could use proactively to predict behaviours in hypothetical or to inform unexpected or emergency situations. DS 22/2/2017

28 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017

REFERENCES Hollnagel, E. (2004) “Barriers and Accident Prevention”, Ashgate Press, Hudson, P, (2010) Safety Science: It is not Rocket Science, It is much harder, oratie Technical University Delft, 24 September 2010 http://repository.tudelft.nl/view/ir/uuid:993726a8-d94f-41a9-b94b-47841a729934/ Slater, D. (2012) “Risk Assessment from the Top”, The Chemical Engineer, February, pp 4042 Hollnagel, E. (2014) “Safety–I and Safety– II,”, Ashgate Press. Slater, et al. (2005) “Quantification of Occupational Risk Exposures” Ministry of Labour and Social Affairs (SZW), The Netherlands. Hollnagel, E. (2012) “FRAM: the Functional Resonance Analysis Method”. Ashgate Press Hill, R. (2014) “FMV- The FRAM Model Visualiser” Download from http://functionalresonance.com/tools-visualisation/fram-visualisation.html Slater, D. (2014) “Quantitative Variability – Expressing Uncertainty in Operation”. Cambrensis Ltd. Slater, D. (2014) “Bhopal, A Tragedy of Unintended Consequences” The Chemical Engineer, Dec. pp34-38

29 FRAMBBNBPMN1.0

© Cambrensis Ltd. 2017