process modelling from reflective practice for

Civil Engineering and Environmental Systems

ISSN: 1028-6608 (Print) 1029-0249 (Online) Journal homepage: http://www.tandfonline.com/loi/gcee20

PROCESS MODELLING FROM REFLECTIVE PRACTICE FOR ENGINEERING QUALITY DAVID BLOCKLEY To cite this article: DAVID BLOCKLEY (1999) PROCESS MODELLING FROM REFLECTIVE PRACTICE FOR ENGINEERING QUALITY, Civil Engineering and Environmental Systems, 16:4, 287-313, DOI: 10.1080/02630259908970268 To link to this article: http://dx.doi.org/10.1080/02630259908970268

Published online: 20 Sep 2007.

Submit your article to this journal

Article views: 72

View related articles

Citing articles: 10 View citing articles

Full Terms & Conditions of access and use can be found at http://www.tandfonline.com/action/journalInformation?journalCode=gcee20 Download by: [University of Bristol], [[email protected]]

Date: 26 August 2016, At: 08:26

Cibil. Eng. and Env. Sysr., Vol. 16, pp. 287-313 Reprints available directly from the publisher Photocopying permitted by license only

0 1999 OPA (Overseas Publishers Association)

N.V. Published by license under the Gordon and Breach Science Publishers imprint. Printed in Malaysia.

PROCESS MODELLING FROM REFLECTIVE PRACTICE FOR ENGINEERING QUALITY DAVID BLOCKLEY Department of Civil Engineering, Universiry

OJ

Bristol, UK

(Received J u b 1998; In final fornt January 1999) Reflective practice, as previously introduced (Schon, 1983; Dias. Blockley, 19951, is used to begin the development of a language for the modelling of processes be they physical, human or organisational. The aim is to improve the quality of both products and processes in the short term for immediate application with 'passive' data and in thc longer term for process enactment in interlintranet systems with 'active' data. One simple advantage will be improved handling of problems with often occur at the interface between difficult technical problems and human and organisational issues. The hypothesis presented is that everything is an holistic process. The theory is based o n the reflective practice loop. Attributes of process models are presented and an algorithm is given for determining them. Some suggestions for generic organisational processes are presented. The models can be used with standard project management tools if deemed necessary. The potential benefits from adopting these ideas are improved clarity of roles, clearer definitions of success, improved safety and avoidance of complex 'incubating' hazards and savings of time and money. The methods are currently being tested on a number of practical projects which will be reported in future papers. Keywords: Process; quality; risk; uncertainty; human factors

1. INTRODUCTION In previous papers (Blockley, 1992; Dias and Blockley, 1995) the concept of a 'holistic' systems approach to engineering based upon reflective practice (RP) (Schon, 1983) has been introduced. The overall purpose was to help provide an understanding of the gap between, on the one hand, the scientific and largely reductionist theoretical approach to engineering practice and, on the other, the difficulties of actual practice itself. The real world of practice seems so often to be full of

288

D.BLOCKLEY

'messy' complex interacting systems which, despite the spectacular successes of applications of engineering theory, seems at the same time to demonstrate its many inadequacies. In this paper the purpose is to develop the idea of reflective practice into the practical use of process models to improve both the quality of products and processes. The basic thrust is to begin the process of providing a common language for understanding and making decisions about systems which involve physical artefacts, human beings and organisations. One simple advantage will be an improved handling of the problems which often occur at the interface between difficult technical problems and human and organisational issues. The process of developing a common language has twin objectives. The first is in the shorter term to develop ideas, tools and techniques which will find practical applications quite soon. The second objective is to develop understanding for the longer term when shared information will be 'active' rather than 'passive' (de Bono, 1976) through interlintra net computer systems. The ideas presented here are being developed through a number of projects which will be reported in future papers. The immediate objective of this paper is to provide the background to the development ofthis common language.

2. REFLECTIVE PRACTICE (RP)

RP as previously introduced (Dias, Blocklcy, 1995) is perhaps best described by contrasting it with current scientific thinking or technical rationality (TR). TR is based on thc idea that the behaviour of the whole is explained by the separate behaviour of the parts. It is characterised by selective inattention to aspects of problems that cannot be formulated theoretically. It seeks to be practitioner independent or 'objective' so that the results are not supposed to depend upon the scientists and to be 'value free' (Blockley, 1998). The goal of modelling in TR is truth i.e., correspondence is sought between the results of the model and the behaviour of the parts of the world 'out there' being modelled. The TR approach has been spectacularly successful but limits to this approach are apparent in practice and are being discovered at a philosophical level also (Rorty, 1982). There are therefore signs that we are in the preliminary stages of a major paradigm shift

REFLECTIVE PRACTICE FOR ENGINEERING QUALITY

289

(Kuhn, 1-962).Limits to mathematics and physics arise in the form of Godel's theorems, Heisenberg's uncertainty principle and chaos theory. Selective inattention is an increasingly inappropriate way of thinking in today's complex world where aspects of sociological, political and cultural considerations may be the ones that most influence a solution to a technical/business problem. Of course in the creation of any model of any system there will be some aspects of the 'real' system not included but this is not what is meant by selective inattention. In the RP approach the reason for not including some aspect of a system is because it is not thought to be appropriate rather than because it is just to difficult to formulate. In RP, the world is seen as a system which consists of a hierarchy of many layers of interacting holons (Koestler, 1967). Each layer is a description of the system at a particular level of scope and precision. At the top are the widest ranging and vaguest descriptions and at the bottom are the most detailed and precise descriptions. Holons are both wholes and parts and each whole is more than the sum of its parts. This is characterised by the idea of an emergent property which may apply at one level of definition and which results from the cooperation of the parts. For example humans can walk and talk, which are properties which neither our subsystems (skeleton, nervous system erc.) nor our super-systems (groups, organisations etc.) have. However groups of people have properties which emerge from the group-such as 'team spirit'. It will be argued in Section 5 that holons are processes. At each hierarchical level the system is represented by a set of holons which look upward as parts of higher level systems and look downwards as wholes which are made up of sub-systems. The holons are highly interconnected and the message passing between them creates a process. The form of the interconnection is crucial for robustness. The behaviour of the system can be understood by focusing on the holons and then modelling the interactions between them at different levels in the hierarchy in order to capture the emergent properties (Argarwal, Woodman, Blockley, 1997). RP is by definition dependent both on the practitioner and context. Problem solving is seen as a process which is grounded not on truth but on dependability (Blockley, 1980) and success is the achievement of objectives obtained by a close engagement with a developing state of affairs. Correspondence with the world outside may only be approximate-the important

290

D. BLOCKLEY

characteristic is whether it is appropriate and dependable for the decisions which have to be made. There is less emphasis on prediction in RP than TR and more on managing evidence to produce effective decisions and actions. This management of evidence is a dynamic constantly changing process through which information is evaluated and decisions and actions taken.

3. THE IMPORTANCE OF PROCESS As stated in the previous section thc whole emphasis in RP is on process. Organisations that deal with difficult technical problems as part of their business, such as for example engineering companies, financial dealers and hospitals, have a particular need to ensurc that the interface between the experts and the non-experts within a process is managed well. For certain industries, such as the nuclear industry, there is a significant risk that any future failure of one of the key processes (e.g., a reactor meltdown) could be so damaging that it could be terminal for the business. The problem of dealing with low probability but very high consequence events is really one, not of predicting risk which is extremely difficult when people are an essential part of the system, but of managing the process of the taking of risk in a way which is practical, reasonable and acceptable. In this work this process is an RP process. Almost all organisations, be they businesses or public or private bodies, want to improve their cffectiveness and so a major purpose of this paper is to discuss how this might be achieved through improved control of both technical and organisational processes. Business process re-engineering is not a new idea and is being used extensively (e.g., Hammer, Champey, 1993). The idea of process as the key to understanding is familiar in information technology. In this work the purpose is to set out some of the key ideas to help manage quality in an engineering business. 4. THE HYPOTHESIS It is commonplace to think of processes and products as being quite different-on this view the process results in a product. The basic


29 1

hypothesis to be examined here is t-hat it is useful to t-hink of -everything as a holon and as a process. The world consists, on this view, of a hierarchy of interacting processes. Thus think of yourself as a holon and a process. Think of a product or an arteract as a process, think even of language in this way as a holistic process. Now in so far as everything changes through time then this hypothesis of process is clearly the case; the real question is whether it is useful or not to think in this way; i . ~ .to , identify any benefit that might accrue. The purpose of the paper is to set out the basics of this hypothesis. The benefits from taking this view will become apparent later, or not, as the hypothesis is tested in use. The basics of a theory of practical competence based on RP has been set out (Blockley, 1992). This is perhaps a good starting point for the building of a general model of process because it concerns the way in which pcople interact with the world outside of themselves (including other people). Therefore we will begin by setting out a preliminary model of human interaction and then extend it to deal with group and organisational processes and to physical processes. Firstly we should recognise that everything that we think and do depends upon our point of view which develops from our interactions with the physical and social world 'out there' in a set of reflective practice loops (RPLs). We attribute meaning to something by interpreting it in the light of our experience and education. Thus for example, engineers see problems in engineering terms, economists in economic terms etc. Social culture, or 'the way we do things around here', is an emergent property of a group which depends importantly on the world view of the members of the group, We can think of world views as a set of patterns in the brain. When we perceive (sense) sometl~inga set of messages (signals) are sent to the brain and the mind organises these messages into patterns which effectively form the 'software' of our brains. A reffective practitioner has an objective which is to produce 'something' with specific qualities'effectively and to d o it with a proper duty of care to a set of stakeholders. The 'something' will have an 'objective' existence such as the expression of a theory or a physical artefact such as a bridge. The quality of RP derives from the setting and achieving of goals or objectives which express that 'something'; in other words are fit for the purpose. In order to decide the level of that fitness for purpose we need a value system through which we express

292

D.RLOCKLEY

preferences and make choices. Values are therefore the worth we ascribe to something. The scientific idea that excellence can only be achieved through the rigorous search for truth is partial since it only the case when that is indeed the objective and truth is the only value. More generally the goal will be multi-faceted and complex and the values will be many and various. The reflective practitioner will be looking for dependable evidence concerning the information on which decisions are based. The rigour of RP derives from the way in which the objective is achieved. Quality is therefore the degree of excellence which is the state of having pre-eminence or having the highest value which can be used to evaluate the alternatives in a decision process. Models which are part of the world view but which exist 'objectively' are buill to be appropriate. If the objective is scientific truth then it is appropriate that the model is as true as it can be. If a model is absolutely true-something that is impossible to establish in the ultimate-then predictions derived from it are totally dependable (Blockley, 1980) and decisions based on those predictions can be made with total confidence. However in RP the models that are appropriate are thosc which are dependable (rather than true) and from which follow effective decisions and actions to produce the 'something' of the objective. Thus the level of appropriateness rcquired of the model depends on whether the decisions and actions that derive from the model are successful i.e., the objectives are actually reached. Of course success can only be recognised in retrospect; nevertheless it is important always to be clear what success will look like even though the definition may change through time. Learning is through a process of retrospective reflection on successes and failures to build evidential support for various theories and models. The learning process of building dependable evidence about particular models from collective experience is crucial to dependable decision making. In order to build a process model let us start with a previous suggestion that perhaps the most fundamental process of all is the Reflective Practice Loop (RPL). This process is in essence one of: world - > sense > think - > act - > world or in other words, more generally world- > perception (P)- > reflection (R)- > action (A)- > world and is shown in Figure 1. All human activities are represented in this model as a hierarchically structured set of evolutionary problem


293

FIGURE 1 The reflective practice loop.

solving processes, each of which is structured as Figure 1. We perceive a signal (visual, tactile, sound etc.) through time and process it through sensory organs (eyes, ears, the nervous system etc. in people and transducers and local processors in man made systems). This signal is then processed in reflection which will vary according to the level in the hierarchy but is essentially a decision making, problem solving internal process in a control loop with an output which is a choice of action. This output from reflection then triggers an action on the world 'out there'. The level of sophistication of the reflection varies. At low levels (e.g., in the sub-conscious mind) it can be thought of as simply a transformation of input to output. For example if temperature lowers significantly then reflection sends a signal to action to make body shiver. Thc modelling of physical processes is of this type and the Interacting Objects Process Model (IOPM) is an example of this kind of approach which has been used successfully (Blockley, 1995). At high levels the reflection consists of the conscious thinking through of the taking of a decision-it is a decision making and problem solving process

294

D.BLOCKLEY

with all of the complexities of conflicting needs, ambiguous and conflicting information elc. By this view language is the result of linkages between patterns of perceptions and patterns of audible sounds (phonemes) and visible marks or symbols (marks such as letter, numbers) and the linkages themselves are patterns. Learning from this view is the development of new patterns and new linkages between patterns. For more discussion see Blockley (1992). The RPL is a generalisation of input - > transformation - > output. In ~nathematicalterms, reflection is a many to many mapping from perception to action. We can picture this mapping as a set of functions or a set of rules. However it is recursive and layered in many levels of loops within loops. In terms of Popper's three worlds (Magee, 1978), (where world 1 is the physical world 'out there', world 2 is the world of the subjective mind and world 3 is the world of objective information) the RPL is a model of the interaction of a human (P in sensory organs and local processors, R in the mind of Popper's world 2 and A in the response of body of control signals from reflection) with the world outside of us (Popper's world 1). Particularly interesting then is the position of Popper's world 3 because it is approached through world 1 i.e., books efc., but it is not actually in world 1 since it includes fiction, but it is 'objective' because the totality is outside the mind of any single individual. The driver of the reflective process is the creative tension (Senge, 1990) between need and current state which generates an issue to be resolved or problem. Figure 2 is the standard diagram for the decision making process loop which is included here for comparison. It brings out the distinction between decision as process and the act of choosing one of the alternative solutions to the problem which leads to implementation and action. The process is cyclic because following on from an implementation immediately is a new state of affairs and hence a new problem. Figure 3 is intended as a development of Figure 2 for the RPL. Here conscious reflection is modelled as consisting of four cycles of influence (Senge, 1990). The first is the loop Need--> Creative Tension-- > Current state-- > Need which tends to generate and reinforce creative tension. Associated with that is the loop Need-> Purpose-- > Objectives-- > Need which tends to clarify the need. The third loop of creative tension-- > scenarios-- > evaluation-- > creative tension reduces creative tension by identifying what can


295

Defining the Problem Reviewing

Preparing Alternative Solutions

/'

Following up

f

11

Alternatives Evaluating

~J r nelernenting C~OL

M&ng

a choice

/

FIGURE 2 A model of the decision making process

;

Objcct~vcs Crealive

Tension

--__

---

- - - - - -Evaluation - ..- - .- - - - .-

--

FIGURE 3 Influence loops for reflective practice loop.

be done. The loop current state-- > memory-- > current state serves to keep the current state updated. These loops will all have sub-processes of reflection and together they represent a very crude and simple model of the reflective thinking process.

296

D. BLOCKLEY

The distinction between 'active' and 'passive' information is important here. The letters and words on this page are examples of passive information. They are marks on paper or on a computer disc with which we represent something in an agreed manner. An example of active information is that which is in our minds. It is dynamic and constantly changing, there are large numbers of possibilities and alternatives and it is self organising. The distinction between active and passive information is important as we are moving from a situation where present computer systems are passive information systems to one where with the introduction of inter/intra computer networks the information will become active. It is imperative therefore that thesc networks are organised such that they can bc utilised effectively.

5. THE BASIC PROCESS MODEL

If we are to think of everything as a process then we necd a generic model of a process. There are very many ways of representing a process some of which are commonplace and others less so. Examples are a simple input-transformation-output box, a flow chart, a bar chart and a critical path network. Thesc are essentially examples of passive information describing the relationships between events usually through time. Although they may be updated regularly as the models become more complex then updating becomes more difficult and resource intensive. There are now a number of process modelling computer tools such as IPSE 2.5 and its successor Processwise (Snowdon, 1990), (Warboys, Snowdon, 1998), IDEF-0, (Colquhoun et a!., 1993), R A D (Ould, 19951, Flowmap (Howard, 1992), ARIS (Scheer, 1994) elc., which are beginning to be explored for use in construction projects. As discussed in the previous section the RPL was developed through thinking about personal processes of reflective decision making. The process model being suggested here is intended as a generalisation of all of the above existing practical models with the RPL to develop a common language for human, organisational and physical processes. It includes and generalises the ideas of the interacting Objects Process Model (IOPM) which has been reported. (Argarwal, Blockley, Woodman, 1997). The interpretation of the RPL as representing the


297

interactions between an individual and the world 'out .t.here' (Poppers world I) is now replaced by a social one involving processes in and between holons in all of Popper's three worlds. Reflection in this more general model is the reflective decision making loop between players in a process containing sub-processes and includes our collective understanding of the physical world. Personal reflection occurs in Popper's world 2 (within a mind) but organisational reflection occurs in Popper's world 3 (within a group or organisation) and it is the clarity of that latter process we wish to describe and improve. Of course both the personal and social reflection processes interact with actual physical processes which occur in Popper's world 1. However we recognise that we can only model these physical processes (in world 1) through our individual subjective reflections (in world 2) and our collective objective reflections (in world 3). The model of process presented here is that of a hierarchy of RPLs each of which are interacting processes. In detail it is a generalisation of the IOPM (Argawal, Blockley, Woodman, 1997). Each RPL for each individual process is programmed inside an interacting object (10) using a series of software objects. Higher level RPLs (as 10s) in the hierarchy are made up of interacting lower level RPLs (as 10s). Each I 0 is described through a set of attributes. Some of the attributes will be the state variables of a standard simulation of a physical process as in the present IOPM. For example the position, velocity and acceleration of a mass in a dynamics problem. Others (also in the IOPM) will define the transformations of the state variables from inputs to outputs in a simulation. Still further attributes will describe the context in which a process is to be enacted (e.g.,the roles and players). All of the attributes of a process to be identified here will not be needed in all applications and some will be more important in certain applications than in others. However we should expect to consider each one for each process to establish whether it is important in the particular context of that process. Some of the attributes are shown in Figure 4a organised using the simple acronym of THE PROCESS and in Figure 4b in terms of the simple attention directors of 'who, what, what, how, why, where and when. Let us consider them and some others in a different order which reflects the RPL and in particular the reflective part of the RPL. The attributes are shown in bold type.

D.BLOCKLEY

THE PROCESS T

TRANSFORMATION, TECHNOLOGY

H

HIERARCHY, HAZARD

E

ENVIRONMENT, ETHIC

P

PLAYER, POINT OF VIEW

R

ROLE, RISK

0

OWNER, OBJECTIVES

C

CLlENT, COSTS

E

END/BEGINNTNG, EVIDENCE

S

STAKEHOLDERS, SCENARIOS

S

STATE VARLABLES, SUCCESS FIGURE 4a Some attributes of process

The first attribute is the owner of the process. This is the person or player who is responsible for its success or it is the 'thing' in which the process is 'being'. Thus the owner can be an individual, a group, an organisation or an artefact such as a piece of equipment performing a function. It is itself a process holon. The current state description is the set of parameters of the transformations within the process. For example a physical process may be modelled by y = g(x) where g are the parameters and state variables. These are t h e familiar technical parameters of loading, material properties etc. The obvious generic state descriptors in a commercial process are those of resource such as time (e.g., earliest start time), cost (e.g., %budget spent) and people. There are also the

300

D.BLOCKLEY

more difficult to identify and measure organisational parameters such as colnpany performance, ability of team etc. The responsibility of process owner either derives from a superprocess or from a need to change the current state. This produces an accountability to somc other process owner and leads lo a creative tension (Senge, 1990) between what is the desired state of the process and the current state. The taking of responsibility and being accountable implies not that one has earned the right to be right but that one has taken what precautions one can reasonably be expected to take against being wrong. The 'responsibility' of a physical object will be discussed later as a role but is essentially its function. The creative tension of a physical process is the potential field that drives the process such as gravitation or electromagnetism. If this creativc tension is clearly defined it is recognisably a 'problem'. If it is not well defined then it is more like a 'mess' (Checkland, Scholes, 1990) and, as stated earlier, more internal reflection and sub-processes are rcquired in order to make it clearer. The creative tension of a large group or whole organisation will contain much conflicting and ambiguous information and sets of values. Many sub-processes will be required to obtain clarity of purpose which will lead in turn to specific objectives which are the future desired states. The reflection process has then to identify the tasks which will transform the present state into the required state in a way which accords with the criteria that are used to make preferences-these are the values (Blockley, 1998). Various alternative tasks or sub-processes have to be considered and the consequences imagined. The processes owner will represent (model) the responsibility and consequent transformation from a point of view and will be delivering a result of the process to a client (who may actually be the process owner for internal reflection). The form of the process transformation must be appropriate in terms of complexity/simplicity and robustness. Those factors which are part of the process and those which part of the environment or context of the process must be defined. Process roles are the sets of responsibilities required to accomplish the tasks or transformations. Roles will be inhabited by players who can be people or can be things which are themselves processes. It is common to speak of roles in terms of 'wearing different hats'. Stakeholders are those players who have an interest in the process but no


30 1

direct part to play in ~ tNote . the distinction between roles and players because the way this IS done provides the basis for the distribution of power within a group or organisation. For example in a small company dominated by one person many of the higher level roles may be played by that one person. In a hierarchical organisation such as the military the players are layered very strictly whereas in an egalitarian group the roles are shared between the players in a very flat distribution. The role of an artefact or product deserves special attention because it really is a restricted case of the generic concept or role and is defined here as a set of functions (Dias, Blockley, 1994). This functionality derives from the process in which the artefact is a player. For example a designed artefact such as a bridge has a set of functions ascribed to it by the other roles. The functions ascribed to it by the designers may coincide with those ascribed by the users (carrying traffic over a canal) but other functions, such as providing temporary shelter to the homeless, may not have been in the design specification. Natural artefacts also have functions which more obviously are ascribed by roles in processes. For example the role of lake in the process of attracting tourists to a particular region may be crucial but the required attributes of the lake for that role may be diffcrcnt from those required for the role of the lake in the process of providing water as a reservoir. Thus thc role of artefacts, 'systems of artefacts and natural features have to be seen in the context of the processes of which they are deemed to be part. The transformations within a process will require information (input) which may be present in the current state description or may be required to be generated by a sub-process. In a physical process the model of the transformation will usually be an engineering science representation of the phenomenon expressed as a mathematical function or numerical scheme such as a finite element analysis. Information generated through the transformation of the input into output information tnay be passed to other processes including the client of the process. Success of the process is the controlled transformation of the input state (information) to the output state (information) or required objectives. In order to achieve this transformations in reflection then the alternative solutions to the problem scenarios need to be predicted and

302

D.BLOCKLEY

evaluated and some guarded against. Examples of the way this is done in risk assessment practice are the use of event and fault trees. The values used to evaluate the scenarios derive from the ethics within the process which in turn are those of the players which emerge into the group culture. Some scenarios are risks leading to failure and some are opportunities leading to success. In this way the reflective decision making process leads to a choice from a set of possible scenarios and hence a decision to act by the process owner (Figs. 2, 3). The consequences of these choices are continually monitored through further nested RPLs operating through time at many levels and each requiring further decisions and choices within the reflection phases. The hazards that threaten the control of the process are the 'banana skins' which need to be managed away. Evidence of hazard needs to be collected to express a degree of concern about whether at a particular time there is danger that the controlled process may become an uncontrolled process which is in a hazardous (i.e., near to failure) state. In general there are scenarios that can be anticipated and hence can be avoided. In the limit one can identify failure scenarios and estimate, by prediction, the risk that they will occur with a certain course of action-this is the function of risk analysis whether formal and quantitative or informal and qualitative and has been used with some success in the nuclear and process industries. However complex processes involving human beings present particular problems since humans have an infinite capacity to behave in unforeseen ways. In human systems there is a certain poverty of prediction and so it is important therefore to look for evidence of potential failure in the current and past state of the process. A system called MARTUN has been designed around the ideas presented here for this very purpose (Dester, Blockley, 1998). Processes which are vulnerable to small perturbations in their state resulting in failures the consequences of which are disproportionate to the perturbations lack robustness. This is a property of the connectivity of a process to other processes and is an under developed aspect of the form of process. The relationship of the simple input-transformationoutput model with the RPL is clear. A discussion of the detailed relationships with the other models, mentioned in the first paragraph of this section, is beyond the scope of this paper.


303

Notice that the attributes are distinct from the other properties of an ~rganisationsuch as power and authority. The way power is structured within an organisation is a matter of management style. Various ,tyles such as 'authoritarian' hierarchical power structures (e.g., as 'ound typically in the military) or 'egalitarian' structures (e.g.,as round ypically in Universities) can operate within what is suggested here. Whatever the style of an organisation the attributes listed here should le covered (though in practice often they are not) but the way in which lower (i.e., the capacity to influence) is distributed may be quite liffcrent in different groups. Figure 5 shows a hierarchical model of the processes and sublrocesses and roles as can be programmed with commercially available ;oftware such as Flowmap (Howard, 1992). This representation is he current state of the development of these ideas. In the software he other attributes described above and in Figure 4 may be shown >y clicking on that process to produce a table of attributive records. rhe top process in Figure 5 is a box with a name 'Process 1'. Underleath is shown the detail of 'Process 1' where two roles are needed o enact it. Role 1 is the process owner and is also responsible for 'recesses 2 and 4. Role 2 is responsible for Process 3, In this simple

Level 0 Process I

Level 1

Level 2

n

~ey:

F

FIGURE 5 The process hierarchy

Process Data file

304

D. BLOCKLEY

model process 2 may partly be an inititating process (perhaps after receiving a message from a higher level process) and process 4 may be a reporting back process (to that higher level process). Processes 2, 3 and 4 are, in turn, shown in more detail. For example Process 2 requires Roles 1; 3, 4 to enact it and of course from the higher level box Role I is the process owner. In a more detailed diagram Processes 5- 12 could be further expanded in like manner. In Figure 5 these processes are basic units of work enacted by the players taking on the roles shown. Thus, in summary, the current state of the model of process hypothesised in this paper is represented by Figure 4b and Figure 5. The link of this representation with Figure 1 and Figure 3 is that it is the reflective part of Figure 1. Future work will make this much more explicit based on a generalised version of the IOPM. At this stage it is sufficient to realise that the suggested computer model is to be used in a series of nested RPLs which recognises that the process attributes are constantly changing. The computer model can be linked with other standard project management tools (e.g., times from a critical path analysis) to provide other interpretations of the data which the decision maker needs.

6. AN ALGORITHM FOR PROCESS BUILDING So given the nature of a process model how do we actually construct one'? An algorithm for defining a process model (from the point of view of the process owner of the topmost process) is set out in Figure 6. The algorithm is a suggested way of attempting to obtain clarity in a particular project, organisation or situation where the real world may seem 'messy' and rather ill defined, as stated earlier. The idea is. to build a model by describing the processes that you see and then to alter them progressively to improve them. The method is therefore descriptive at the start but becomes prescriptive as the RPLs develop. The items d o not have to be completed in the strict order shown in Figure 6 and there will be many loops within loops in thinking about the issues involved. The algorithm is to be used for a particular process at a given level of definition and so will be used at many different levels


305

Name the Process Name the Roles. Define the overall Purpose (Vision) and define each role as a set of Responsibilities; include the Process Owner role. For a product or artefact the role is its Function. Identify the Player (Actor) for each role. Remember a player takes an active part in the process and can be a person with more lhan one role or an object with attributed roles (usually by the designer or user of the object) Identify the Client and the Stakebolden. Be clear about the Point of View of each player, stakeholder and client. Idenlify the Beginning and End of the process. Identify what is to be part of the model of the process and what is to be in the Environment (meta-system). Identify the Current State description. Identify the Objectives which are to reach a Desired State description. Identify Success as reaching objectives and avoiding failure. Identlfy the Inputs expected and the Outputs required, the Controls and Constraints. Identify the M d e l that Transforms the current state to the desired state (ie to obtain success and avoid failure) Identify the various Scenarios that result from the model of these transformations and Predict the Consequences. Identify the Hazards, consider the Risks and the Robustness (vulnerability) of the processes. Associate measures of Evidence with 14. Identify Resources required for the process. Identify the roles to be delegated as sub-processes in 2 Identify the transformations to be detailed as sub-processes in 12. and develop the next layer in process Hierarchy. FIGURE 6

An algorithm for building a process model

)f definition in differing circumstances. From experience some of the nost important practical issues are as follows. (i) Be clear that all of the players know who owns the process and who is to take part. Ask yourself who has a stakc in the process but is not a player (stakeholder)? Ask yourself of every subprocess you come across-who owns this process or who is responsible for the delivery of the success of this process? (ii) Be clear what you mean (as the process owner) by success before you starr. Discuss the notion with the players and try to obtain consensus. Where this is not practical then try to consult and obtain agreement to disagree-you take thc responsibility as the process owner and you should be sure that all those who need to know what success is, d o know (even if they d o not necessarily agree).

306

D. BLOCKLEY A process is a collection of activities that takes one or more kinds of input and creates one or more kinds of output that have value We make choices based on preferences and preferences are based on values. Values are the worth we ascribe to something. The value used in reflective practice is quality as fitness for purpose. A role is a collection of responsibilities. A responsibility is the taking of a duty of care to deliver a purpose to a client. A purpose is a declared intention. The duty of care is a responsibility to act reasonably with respect to a client. The client may be a set of constituencies, i.e. oncself, family, business client, society at large and the physical environment. The taking of responsibility implies not that one has earned the right to be right or even nearly right, but that one has taken what precautions one can reasonably be expected to take against being wrong. A player is a process that can take on a role. There are two types of players, those that have intention (i.e. people) and those that do not (i.e. artefacts and systems of artefacts). intention is the feature by which states are directed at or are about players other than themselves. Designed artefacts have an intention ascribed to them by the players (designers and users) A stale is a mode of existence and is described by attributes which are the parameters of the model of the transformation within the process from inputs to outputs. A model is a representation of the world &om a point of view and for a purpose. A stakeholder is a process that has an interest in the success or failure of the process but has no role in the process. A point of view or worldview is the way we perceive the world. It is the way we attribute meaning to something by interpreting it in the light of our experience and education. A process is a bolon i.e. it is both a part and a whole. A sub-process is either a delegated role or a more detailed transformation The owner of a sub-process is accountable to the process owner.

FIGURE 7 Some definitions.

(iii) What are the roles and are they defined? Is there a player for each one? Note that one player can take on many roles. (iv) Be clear about the basis on which you believe the process will be successful (i.e., achieve fitness for purpose with respect to that issue) - usually this grounding is dependability. For example is the clarity of definition dependable? Is the design of the solution method dependable? (v) Consider how appropriate/accurale the process is for its purpose. For example is the level of detail appropriate? Is the level of discrimination appropriate? Are the models applicable, relevant? (vj) Be clear about the extent i.e., limits and bounds of the model of the process and that they are appropriate. For example is the solution method specified appropriately? Is the clarity specified


307

with approprtate limits? Are the boundaries of the solut~on method specified appropriately? (vii) Remember that quality is fitness for purpose. Be clear about the ways in which qual~ty(Elms, 1997) is delivcred. (a) Has a hcrlcincecl consideration been given to all aspects of this issue? For example is there a lot of effort and thought being put into some aspects of the process but much less effort into other equally important aspects? (b) Are the considerations made in a consistent way? For example is chalk unwittingly being compared with cheese? (c) Are the considerations as cotnplete as they possibly can be'? Is anything important missing? For example are human factors being considered adequately'! (d) Is there sufficient cohesion? For example are their any faults? viii) Is the generic form or basic nature of the model of the problem or issuc to be resolved appropriate? Is the lcvel of abstraction and the language used appropriate? (e.g., is a natural language such as English approp;iate or should a formal language such as mathematics be used). How do the parts fit together i.e., what is the connectivity of the elcments of the model. (ix) Information is defined by process because if the input information is not in the form required then the appropriatc translbrmation cannot take place. Thus before designing any product model or database it is important to define processes of which that product or database are a part. x) Some Practical Tips (a) Always name a process using the present participle ending in 'ing' because it gives the feel of being active. For example 'doing the process', 'achieving the mission', 'procuring the raw materials' etc. (b) Remember that processes can be identified directly by looking at what actually happens and what people and systems actually do-so if you get stuck just describe what is in front of you. (c) The major problem in looking at a system which consists of an organisation or a project is to know where to start

308

D.BLOCKLEY because as you work down the hierarchy the number of processes rapidly becomes very large. Present experience suggests that it best to work sideways in by choosing a process that is at a fairly high level in the hierarchy in the area of intercst and to build the hierarchy by working top down from that point. It is probably then the best strategy to work on the attributes of one process at a time to get confidence in the methodology. (d) The use of a standard computer tool such as Flowmap (Howard, 1992) to build a process model may give a superficial impression of it being simply a flowchart. However the previous discussion should make it clear that the model is tnuch richer than a flow chart and can contain much relevant information. If it is made available on a project intranet then an immediate and obvious benefit is that all players in the processes will benefit from understanding their part in relation to other players. Of course that type of clarity can be highly beneficial and effective in improving process quality even if the information is passive. (e) In the not too distant future these models will be used not just to model processes but to enact them through an intranet. The computer itself will have a role in a process model. It will provide information to those people who need it when they need it. The process models will be linked to standard project management tools for critical path analysis etc. as well as word processors, databases and engineering software such as analysis programmes. Those companies that grasp the opportunity will have a significant compctitive edge. (0Note that risk is in the future and hazard is in the past and present. Actions are by definition in the present though decisions can be taken for enacting in the future. Hazards can therefore be managed directly but risks can only be managed indirectly. Reflection and hence choice of actions necessary to manage hazard is based on the evidence from past and present performance and from predictions of the future. If levels of evidence can be appropriately quantified (Hall, Blockley, 1998) then decisions, choices and actions can be based on objective (world 3) data.


309

7. EXAMPLES Such a method is bcing used to model organisational process models in the author's University, in the oil industry for investigating the potential of oil reservoirs (Foley, Ball, Davis, Blockley, 1997) and for investigating the use of the observational method which derives from the observational technique within geotechnics. Other applications are in coastal engineering (Hall, Davis, Blockley, 1997), in case based reasoning and in the simulation of complex non-linear physical processes (Argawai, Blockley, Woodman, 1997). It is possible to build generic process models of organisations because the top two levels of the process hierarchy of all organisations, public or private, will be common. The third level of processes will be common for classes of organisations (e.g., universities, contractors, consultants etc). At the top level of almost all organisations, whether profit or non profit making, whether private, government or institutional, will bc the process 'Aclriec.irzg the mission'. To think about this it may be instructive to explore, for your organisation, who is the process owner and what are the various process attributes that lead to success as defined earlier in the paper. It is important to be clear about the role of the proccss owner. The player taking on that role is responsible for the delivery of process success but will only be able to deliver if he/she can create a team of players who cooperate to achieve that success. Now the top process will have sub-processes which in turn have subsub-processes and they will all have owners. Thus the level of process definition tends to correspond with the company management level. The top level processes will be owned by the role of Managing Director and/or Chicf Executive. At the second level of the generic process model will be two sub-processes 'Achieving the mission of tlze core business' and 'M(~in/criningthe infrastr~tct~rre to support tlre core business'. The owner of the first may still be the M D or CE whilst the second may be owned by, say, the Finance Director or Estates Director. For example in a typical university the core business is teaching and research and the infrastructure consists of the maintenance of buildings, of financial services and registration of students etc., i.e., the University support services-these define the processes at the third level.

310

D.BLOCKLEY

As the analysis delves deeper into the hierarchy it becomcs more and more specialised and different from other similar organisations until, at the lowest levels, the processes will be unique to that organisation. A si~nilar analysis of a project will cross organisational boundaries and at the lowest levels will be unique to that project. Using this idea of hierarchy it is therefore possible to derive generic process models which can be extended downwards into specific applications. Notice that here is no implication here of a fixed set of relationships between processes. The relationships will be dynan~icallychanging through time as an organisation adapts and changes to its environment. However it is truly daunting for anyone to consider building from scratch, a process model o f a whole organisation or project in this way. There are many points of view, much ambiguity and roles may perhaps not be as clear as they should be. A two stage strategy therefore seems ro be called for. The first stage is to choose important and critical processes and concentrate on identifying and improving them first. It seems sensible to aim high in the hierarchy and work top down from there. Observe what actually happens and model it faithfully. l~nprovementssuggest themselves very rapidly and ambiguities and conflicts are clarified so one quickly moves from a model that is as it is (a description) to a new one which is improved (a prescription). The second stage of the strategy is to keep in mind how to link up the processes in an overall model of your system and to proceed with that piecemeal, building as you go. Potential generic lower processes in organisations are, for example, 'Purchasing al~dprocuringmateriuls'. 'Tendering', 'Estitnuiing', 'Setting flze budget', 'Marketing', 'Managing the Site'; the list of possible processes is extremely long. Those wishing to explore this idea should focus on areas of their organisation most in need of attention either because of existing problems or because of the potential for quality iinprovemcnt. Of course within an organisation that has a technical project as part of the business the analysis will eventually arrive at a physical process within the process model. For example, 'Monitoring the dejfectioir of a retaining wall', 'Calculatirzg the nzax~~rzur?z load carrying capacity of rr steel Universal Bean?', 'Deriving the stress I~istoryo f a pressure vessel'. So what are the properties of Figure 4 in these cases? Clearly the process owner is the player occupying that role ensuring the success of each process. In the first process it may be a site engineer, in the other processes it may be the design engineer or the stress analyst. In each case


31 1

the process wid be a sub-process of a higher level process and the owner will be delivering results to the owner of that higher process. Lower level sub-processes may by 'Tlze retaining rvtlll responding to earth pressure', 'The steel beam deflecting lirlder inzporeci load' or 'Theprcssurc vessel bel~c~ving during u reactor cycle'. The role of thc retaining wall in this process is to function as a retaining wall, the role of the steel beam is to function safely as a steel beam and the role of the pressure vessel is to function as a pressure vessel. In other words the 'responsibility' o r an artefact is the I'unctionality of the artefact as perceivcd by the designers or users (the players) in the process of the behaving of that artefact. A simple example of these ideas applied to structural analysis as a set of physical processes, ranging from a single degree of freedom system to a finite element simulation, has been given by Argawal, Blockley, Woodman. (1997) through the Interacting Objects Process Model (IOPM). Here the behaviour models of physical objects are programmed into interacting software objects which hold local information. Con~plexphysical processes such a non-linear dynamic and chaotic systems can be simulated easily. The major value of the approach hypothesised here is that the interface between human and organisational processes and physical processes is handled using the same languagc which should enable a clearer and smoother information flow. In turn the major advantage of that is the way in which success can be achieved through the management of hazards. In this context hazards are state conditions that thrcaten the success ofthe process. It is imperative that these hazards are identified and managed away. This is achieved by monitoring evidence of hazard. Evidence can be gained by prediction of future scenarios, by failure analyscs by regular inspectioil and by careful examination of 'incubating' hazard as identified by Turner and handled in MARIUN (Dester, Blockley, 1998). Practical example will be given in future papers where examples of specific process models will be presented.

8. CONCLUSIONS (1) A contribution towards the development of an engineering process modelling language based on reflective practice (RP) has becn presented.

312

D. BLOCKLEY

(2) The basic hypothesis is that we should think of everything as a 'holistic' process. (3) The attributes of the process model that should be considered have been presented. (4) An algorithm and some practical tips for building a process model have been given. (5) The potential advantages from using thc suggested approach are: -

improved clarity of roles and how they interact to reach success of the process, clearer purpose and objectives defining success, improved safety through the avoidance of hazards which may incubate into Sailure, savings in resource (time and money) with improved quality (fitness for purpose) through better project management, a language which will enable better exploitation of the 'active' information available through intralinternet communications between project managers across both organisational and geographical boundaries.

(6) Thc hypothesis is currently being tested on a number of practical examples and those tests will be reported on in future papers.

Refevences Argawal, J., Rlockley, D . I. and Woodman, hr. J. (1997) Improving Systems Dependability, Proc. Ettr. Conf: Safety and Reliabiliry, ESREL.97, Lisbon. Blockley, D. 1. (1980) The Nature of Structural Design and Safety, Ellis Horwood, Chicester. Blockley, D. I. (1992) Engineering from Reflective Practice, Res. Engnig. Design. 4 , *A.. 15-LL.

Blockley. D. 1 . (1995) Computers in Engineering Risk and Hazard management, Arcl~ivesof Con~p.Merhods in Engineering. 2(2); 67-94. Blockley, D. 1. (1998) Professional Ethics and Morals, Chapter in Health and Safety for Engineers, Barnard M (Ed.), Thomas Telford, London Checkland. P. and Scholes, J. (1990) Soft Systems Methodology in Action, Wiley, Chicester. de Bono, E. (1976) Practical Thinking, Pelican Books, London Colquhoun, G. J., Baines, R W. and Crossley, R. A. (1993) A State of the Art Review of IDEFO, 1111.J. Cornprt~erInwgrared 1!4ariufncruring, 6(4), 252- 264. Dester, W. S. and Blockley, D. 1. (1998) Managing Risk and Uncertatnty (MARIUN), submitted lo J . Coinpurer Aided Cil.il r~ndIilfrasrructrtre Enynig. Dias?W. P. S. and Blockley, D. I. (1994) The Integration of Product and Process Models for Design, Design Srudies, 15(4), October, 417-432.

REFLECT-IVE PRACTICE FOR ENGINEERING QUALITY

313

Dias, W. P. S . and Blockley, D. I. (19953 Reflective Practice 'in Engineering Design, Proc. Insm. Civ. Engng., 108, Nov, 160- 168. Elms, D. G. (1997) System Health Approach for Risk Management and Design, Int. Cot$ Struct. Safely Reli(rbility, (ICOSSAR.97, Nov, Kyoto, Japan. Foley, L., Ball, L., Davis, J. P. and Blockley, D. 1. (1997) Fuzziness, incompleteness and randomness: classification of uncertainty in reservoir appraisal, Petrole~rni Geoscirnce, 3, 203 - 209. Hall. J. and Blockley. D.1. (1998) Uncertain Inference Using Approxi~nateReasoning, I I I ~J.. Approairnatr Retrsu17i17g,19(3 -4), 247-264. Hall, J., Davis, J. P. and Blockley, D. 1. (1997) Towards Uncertainty Management for Coastal Defence Systems, 32ntl MAFF Cord: River uric1 Constal Dig., Keele Univ, July, H3.1 -H3.10. Hammer, M , and Champy, J . (1993) Reengineering the Corporation, Nicholas Brearley, London. Howard, D. (1992) An Approach to improving management performance, IEE, Etig. Mtrri. J . , London. Kuhn, T. S. (1962) The Structure of Scientific Revolutions, Univ. Chicago Press, Chicago. Koestler, A . (1967) The Ghost in the Machine, Picador, London. Magee, B. (1978) Popper, Fontana Modern Masters. Ould, M. A. (1995) Business Processes-modelling and Analysis for Reengineering and Improvement, John Wiley, London. Rorty, R. (1982) Consequences of Pragmatism, Harvester Wheatsheaf, Herts. Scheer, A. W. (1994) ARIS Toolset, h$orrnoriort Systetns, p. 19. Schon, D. (19x3) The Reflective Practitioner, Basic Books, New York. Scnge, P. (1990) The Fifth Discipline. Century Business Books, London. Snowdon, R. A. (1990) An introduction to the IPSE 2.5 Project, In: Long, F. (Ed.), Software Engineering Environments, Lecture Notes in Computer Science, p. 467, Springer Verlag, Berlin. Turner, B. A. and Pidgeon, N. F. (1997) Man Made Disasters, 2nd edn., Butterworth Heinemann. Warboys, B. C. and Snowdon, R. A. (1998) An Introduction t o Process-centred Environments, to be in 'Software Process Modelling and Technology,' Finklestein, A., Kramcr, J. and Nuseibch, B. (Eds.), Advance Software Development Series, Research Studies Press.