Designing a re‐engineering proof process architecture

Abstract

The author wishes to thank colleagues who have contributed to the ideas in this paper, in particular Tim Huckvale. The work has its roots in research undertaken by Clive Roberts (now of Co-ordination Systems Limited) and myself, which itself was based on work by Anatol Holt, to whom I extend my thanks.© Deloitte & Touche Consulting Group.A re-engineering proof process architecture 233(2) Almost as importantly, the designer needs a way of deciding what are the processes in the first place and how they fit together when the world is "running".Both of these concerns are answered by STRIM®, an approach to process design, modelling and analysis that has been developed and used in a great many situations and industries. STRIM®, as described in Ould (1995), concentrates on the first, process-level question: how can we most revealingly model a process? This paper describes how STRIM® has now been extended to cover the second question: what are the real processes and what are their dynamic relationships? I shall use the term process architecture to refer to a definition of the processes within an organization and the dynamic relationships between them. By the end of the paper I shall have given a very precise meaning to the term. Does it matter?Why is getting the process architecture right so important? There are several urgent reasons.An inappropriate division of organizational activity into processes can easily lead to unnecessarily complex designs or models. There is a lesson from software development: when we design software modules we look for high "cohesion" and low "coupling"; when modelling the real world, if we break a process into two along a natural "fault line" we will get fewer broken connections. We want to exploit any cohesion present in the real world. Our aim must be to find those natural fault lines.If re-engineering is being considered, a bad initial division can at best obscure the possibility of a radical change to a process and at worst lead to the local optimization of part-processes but overall pessimization of the total process. This is especially true if we arbitrarily break things into pieces in a sequence and call each piece a "process", something that is all too often done.People (especially those of us with software engineering backgrounds) have a natural desire to decompose a process into successively smaller subprocesses, in other words to draw up a hierarchical structure. The observation followed by STRIM® is that the world is rarely constructed in such a neat way and that the processes in an organization are more likely to be connected in a network than to be contained in one another. The danger of thinking hierarchically cannot be over-emphasized. To draw a diagram such as the one in Figure 1 is not to prepare a process architecture. Does it mean to say, as the diagram implies, that one process is the "sum" of four others? Where in the diagram are the dynamic relationships between processes represented? It is, after all, the dynamic relationships that are crucial to an understanding of h...

Modelling families of business process variants: A decomposition driven method

“…The method by Sharp and McDermott [9] -which we used as a baseline -is an exemplar of a method in this field. Another similar method is presented in [42].…”

Modeling Requirements for Value Configuration Design

“…There is some dispute whether decomposition process design is a good practice. For example Ould [7] in describing Riva as a process design methodology, specifically discourages decomposition. It is the view of this paper that decomposition is essential.…”

A framework for classifying and evaluating process architecture methods

“…But once the value of process architectures has been recognised, the next questions are as follows: what comprises an appropriate process architecture, and how are process architectures identified? These are important questions to answer correctly because, as Ould (1997) has pointed out: 'an inappropriate division of organizational activity into processes can easily lead to complex design or models', and 'a bad initial division can at best obscure the possibility of radical change to a process and at worst lead to the local optimisation of part-processes, but overall pessimisation of the total process'. But, they are also difficult questions to answer: for example, Kavakli and Loucopoulos have pointed out that 'existing approaches offer little guidance for identifying processes' (Kavakli and Loucopoulos 1999).…”

“…A number of different kinds of approaches to identifying and modelling an organisation's process architecture have been proposed, each with its own distinctive rationale. For example, Ould has proposed identifying process architectures from the 'essential entities' of a business (Ould 1997(Ould , 2000(Ould , 2005, the entities that characterise the business the organisation is in; Lunn's process architecture is based upon business processes, where a business process is a 'logical grouping of events that can be agreed as a fundamental element of a business' ; Kavakli and Loucopoulos's process architecture is organised around the goals of an organisation (Kavakli and Loucopoulos 1999); and Snowdon and Kawalek have proposed an architecture (Snowdon and Kawalek 2003) based upon Beer's Viable System ModelViable System Model (VSM) (Beer 1981).…”