GENERAL ARTICLES

 

Supporting business process design through a business fractal approach

 

 

A. van Rensburg¹

Department of Industrial Engineering University of Stellenbosch. antonie@sun.ac.za

 

 

---

ABSTRACT

The role and position of business process management in an organisation depends on the value it contributes to the organisation's sustainability. Business process design ensures that the conceptual business process strategy is translated into appropriate user requirements and functional requirements, and is ultimately implemented through some kind of enabling mechanism. In reality, business process design proves, at best, to be difficult when capturing and translating the complexity of business systems. In this paper, the concept of a business fractal is introduced to demonstrate an alternative way of doing business process design.

---

OPSOMMING

Die rol en posisie van besigheidsprosesbestuur hang af van die waardetoevoeging van besigheidsprosesbestuur tot die uitvoerbaarheid van die organisasie. Dit is in die belang van die ontwerp van die besigheidsproses dat die besigheidstrategie omskryf word in die gebruikersbehoeftestellings en funksionelestellings, en geïmplementeer word in die fisiese uitvoering van die besigheidsproses, hetsy deur 'n rekenaarstelsel of deur besigheidsprosedures. Dit is egter in realiteit baie moeilik om strategie af te wentel na implementeringsprosedures as gevolg van die kompleksiteit van besigheidsprosesse. In hierdie artikel word die konsep van 'n besigheidsfraktaal bekend gestel as 'n alternatiewe manier om besigheidsproses ontwerp te doen.

---

 

 

1 INTRODUCTION

For an organisation to survive, it relies on its 'memory'. This organisational 'memory' forms through the interaction and collective knowledge repository of its workers. It preserves a past, but it is also current; and it allows thinking about, and response to, future challenges. The way business process management (BPM) relies on this 'memory' has a profound impact on the performance of the organisation. The role and position of BPM in an organisation depends on the value it contributes to the sustainability of the organisation. BPM should ensure that business strategy is appropriately translated through good design into operational workflow practices. In this context, BPM will ensure that operational activities are aligned to tactical policies and objectives, supporting the business strategy.

Business process design forms one of the key mechanisms to extract organisational 'memory' in order to codify and implement it through BPM solutions. If the business process design approach falters, or is not done well, the whole BPM exercise suffers - and as a result, the anticipated return on investment is never achieved. Many managers can testify to initiatives that went wrong because initial business processes were not correctly understood, formulated, or communicated through the business process design initiative.

Many methods and techniques exist to assist the business analyst in the design process - for example, the structured design and analysis technique, integrated definition language (IDEF), Petri Nets, and object oriented modelling [15]. In recent years, modelling methods such as unified modelling language (UML) [10] and the business process execution language (BPEL) [13] have gained popularity in the information technology domains as preferred methods for modelling and designing business processes. In this paper, the assumption is made that business process design should start with the translation of business process complexity, rather than trying to start with functional specifications on a UML or BPEL level - in which case design modelling methods such as IDEF become more applicable to providing form and function to the business process design.

The purpose of this paper is to introduce a business fractal approach to the design of business processes, based on the concept of the fractal, introduced by Benoit Mandelbrot forty years ago [6]. To explain this approach, a number of topics are presented in the paper. 'Introduction to business fractals' covers the basic overview and components of business fractals. A business fractal models two sides of a complex business process: one through a static dimension, and the second through a dynamic dimension. In the section headed 'Static dimension', the basic pattern and the content of the business fractal are discussed. The section headed 'Dynamic dimension' deals with the memory and volatility of business fractals as they are used to understand the dynamic behaviour of business processes. In 'Case study application', a case study is presented to demonstrate how business process design is done through this approach. The 'Conclusion' paragraph ends the paper on the use of business fractals as a business process design approach.

 

2 INTRODUCTION TO BUSINESS FRACTALS

A business system is a living 'organism', responsible for supporting the organisation's mandate and vision. It forms a complex interaction between 'man', 'machine', and 'money' [3]. To manage this complexity, organisations make use of various types of scientific models as decision support mechanisms. Scientific models can be defined as abstract representations of reality, based on scientific rules to reduce the complexity of problem situations. Within these models, the business analyst tries to eliminate those real-world details that do not influence the relevant goals of the problem. Therefore, a model reveals what its creator believes is important to solve the problem - in this case, designing the business process. According to Curtis et al. [1], this insight and understanding into the problem form the basic building blocks of a suitable model to study the system. In his research work, Dijsktra [2] discovered that the idea of structuring problems through models was not futile. He found that in many natural instances that an observer might describe as chaotic and random, there are patterns that can be described by some kind of mathematical formula.

As stated in the introduction, many modelling methodologies used in business process design try to structure the models of the business system so that certain techniques can be used to analyse, design, and optimise the business process. Unfortunately, it is not easy to find these design solutions: the closer the observer looks at the real world, the more its complexity is revealed [4]. In Van Rensburg's [15] PhD thesis, the research hypothesis was proved that business problems contain organised patterns that are part of larger business systems. Applying this logic to the modelling and design of business processes, it can be stated that business processes contain organised patterns of business activities. Using this approach, fractals can be used to understand the complexity of a business system, and hence its associated business processes and appropriate designs.

A fractal is defined as a shape that can be broken into smaller parts, each echoing the whole [6]. Mandelbrot maintains that pictures are undervalued in science, due in part to the 200-year legacy of the French mathematicians Lagrange and Laplace, who laboured to reduce all logical thinking to formulae and carefully-chosen words [6]. As such, most of his fractal work results in visual representations of fractal geometry shapes.

Van Rensburg [9] extends the definition and visualisation of fractals to that of a business fractal: defining the business fractal as a shape that echoes the business system as a whole, which can be broken into smaller parts. According to Frizelle [3], complexity can only effectively be addressed in a business system if the static and dynamic behaviours are separated from each other in the design or redesign of the system. Applying this to Mandelbrot's fractal definition, a business fractal can be described as a function of pattern, content, memory, and volatility [16]. This means that the pattern and content deal with the understanding of the static dimension, while memory and volatility describe the dynamic dimension.

Business Fractal = f(pattern, content, memory, volatility)

 

3 BUSINESS FRACTAL'S STATIC DIMENSION

In this part of the paper, the business fractal's static dimension is described: first the pattern, and then the content view.

3.1 The pattern

In its most elementary state, the business fractal pattern defines the static description of a business process through the relationships of people, process, customer, resource, and alignment objects. This means that the business analyst defines and models any business processes on any hierarchical level of abstraction in the same manner, through the same pattern and its objects. In its meta model, the objects and object relationships cover all stakeholders ('people'), anyone receiving benefit from the process ('customers'), balance sheet items being used by the process ('resources'), and any policies, measurements, or targets to align the business process ('alignment') [15].

A number of views can be used to understand the business fractal pattern: a 'functional view', a 'relational view', and a 'value proposition view'. Each of these views creates a different perspective on the objects and their respective relationships. Some organisations insist on additional views, such as the 'value chain view', to complete these views and provide alignment to popular modelling approaches such as Porter's value chain [7]. To accommodate these reference model views, a fourth view is created, the 'reference model view'.

The functional view creates an hierarchical description of the business system, showing recursive decompositions of the same object patterns. From a practical perspective, a functional modelling approach such as IDEF0 [5] provides a thorough modelling technique to create models for this view. However, the paradigm shift for the business analyst is to realise and apply hierarchical decomposition or recursive modelling to any of the object types - whether they be people, customer, resource, alignment, or process objects. (Refer to Van Rensburg [9] for a detailed explanation of building fractals and business fractals.)

In the relational view the business analyst studies the multidimensional relationships between the pattern objects, and tries to visualise and answer questions such as 'Which process touches which customer through what delivery channels involving which stakeholders?' This ensures a streamlining of the business process design across all the potentially important relationships that may exist in the business system.

The third view of the pattern is the value proposition view. This view stores end-to-end business processes in a process library, using the notation of value propositions as a reference catalogue for finding business processes. This view is important, as it is imperative for the business analyst to understand the impact of variation in the business system. This is created through the different configurations of business units, market segments, product groupings, and delivery channels, as they have a direct impact on business process variations. Another import concept that directly supports the service oriented architecture (SOA) concept is to classify the different pattern objects according to how they are shared in the business system, or dedicated to a specific configuration, or deployed as a federal process in the business system. With more than fifteen years' experience in business process design, it is the opinion of the author that this view forms the pivot role in the static design of business processes. Modelling in this view can be supported primarily by the IDEF3 modelling technique. If the business analyst starts with the IDEFO technique in the functional view, translation to IDEF3 is relatively straightforward.

In Van Rensburg [17], it was demonstrated that a combination of the above three views can be used to define specific user-required views. In this particular exercise a 'value chain view' was required to support the popular Porter's value chain [7] models. This might also be extended to any of the popular reference model views, such as the SCOR, VCOR, APQC, ITIL, COBIT, or eTOM models. For this purpose, a user-defined view - the 'reference model view' - is created to satisfy specific reference model requirements. The generic principle for constructing this view is that objects and object relationships are classified according to a reference model, allowing this view to adapt to any defined reference model [17].

3.2 The content

The second part of the static dimension of a business fractal deals with the content of the business system. In this definition, the content of the business system includes (but is not limited to) any objects that may bring richness to the pattern description of the business process. From experience, it can be shown that most business process design projects differ with regard to the required richness (dimensions) of the business process design. For example, creating the strategy for a national import/export process requires different content than that for the design of call centre processes. In the case of the former, richness is required from an international standards and legislation perspective, while the latter case requires richness on the competency profiles of call centre agents.

In understanding and defining the business process, it is important to realise that these objects are as much a part of the business process as the business process pattern itself. It is thus important to understand where these dimensions fit into the business fractal itself, as well as how they contribute to the effectiveness and efficiency of business processes. From a modelling technique perspective, a data modelling technique such as IDEF1X provides an easy translation from IDEF0 into modelling the applicable content of the business process, paving the way for the creation of a data cube on the objects for investigation purposes.

 

4 BUSINESS FRACTALS' DYNAMIC DIMENSION

Business fractal dynamics deal with the memory and volatility of the business system under study. Understanding the dynamic behaviour of the business system provides the means to create a business process design that replicates the actual behaviour of the business system over time.

4.1 The memory

To model the memory component of the business process, statistics are collected from the actual business system in order to create stochastic models. By using techniques such as simulation modelling from the field of operations research, these stochastic models can be combined with the business fractal patterns to model real-world behaviour. Thus the business analyst is able to capture real-world behaviour through statistical distributions, to model resource impact and events as they occur through the business process over time. Modelling techniques for this component depend on the discrete event simulation modelling toolset being used. Some toolsets such as Witness enable direct translation from IDEF3; others, such as the ARIS toolset, have an add-on tool that translates event-driven process chains (EPCs) into simulation models. In this case it really depends on what the business analyst wants to model; and it will in any case require a translation of the business process design into a simulation model specification.

4.2 The volatility

A business process depends on a number of critical success factors, many being managed through different policy decisions. In reality these factors are interdependent, operate in a non-linear fashion, or take place in a non-instantaneous fashion [12]. Adding these power law behaviours to the model might show some unexpected results from a business process design perspective. For example, it might be that the forecast workload capacities to support the design are not sufficient: they are hidden in the pattern, only becoming visible in a dynamic simulation. Dealing with this power law behaviour forms the 'volatility' part of the business fractal. Modelling techniques for this fall squarely into the domain of business dynamics and of systems thinking and its associated modelling languages. If the business analyst uses a good functional modelling technique such as IDEF0, a relatively easy translation from the pattern (the 'functional view') can be made to the volatility view of the business fractal.

 

5 A CASE STUDY EXAMPLE

To demonstrate the use of the business fractal approach in designing a business process, the following example is used and explained through the approach discussed earlier in this paper.

The case study covers the credit card application process in a bank. The objective of this exercise is to design and optimise a business process for applying for a credit card at a bank. In this example, information has been extracted by the business analyst from existing systems as a source of work flow knowledge about the process (Table 1 ).

5.1 Defining the pattern

The first step in the process is to create a pattern for the credit card application process. Figure 1 contains the picture of the simplest fractal pattern of this process, showing the core objects and their relationships.

 

 

For the purpose of this exercise, the business analyst creates the following functional views from the fractal: a) organisation chart, b) function tree, c) product and service catalogue, d) channel structure, and e) customer segmentation. (See Figures 2a and 2b.)

In the definition of the 'value proposition view', the business analyst decides to scope and focus on the following business process configuration:

a) Only the credit card product

b) Only the 'apply' service for the credit card product

c) Only for general banking customers

d) Only for the branch channel.

Figure 3 shows two process flows: the left hand side shows the event process chain (EPC) flow, and the right hand side shows the workflow process extracted from event logs (Table 1) using the process mining method [14].

 

 

5.2 Defining the content

To support the pattern of the process, the business analyst creates a content cube from the existing process information [8,18]. It was decided not to refine the cube's hierarchies or dimensions according to data mining techniques, but rather to use the existing dimensions and hierarchies as extracted from the process event log file in Table 1. The table below shows the content pivot for the count of all documents per process task per role player.

From this content, the business analyst can see that the credit clerk interacts most with the process steps, and also deals with the greatest number of documents in the end-to-end process.

Drill-down on this information shows which types of documents the credit clerk deals with, as well as the number of occurrences in the process steps.

 

 

 

 

5.3 Understanding the memory

Using the business process model (Figure 3) as well as calculated stochastic models from the real world transactions, a simulation model is constructed [9]. Using discrete event simulation software, the designed business process is simulated to study the impact of the business process with real world events over a specific time period. Figure 4 shows the translated process model in the simulation software; Figure 5 shows results from the simulation run.

From this it can be seen that the value-added time spent on the process is only 25 per cent (230 minutes) of the total cycle time (954 minutes). A serious bottleneck issue is apparent from the fact that the credit clerk resource is being used for 99 per cent of all the available time.

5.4 Modelling the volatility

The discrete simulation proved that the design of the workflow for credit card applications is feasible based on past history, and should be sufficient in the future. It was determined from the model that the credit clerk job capacity creates the biggest risk of bottlenecks in the system due to the number of documents that need to be processed by this job. A digital documentation project will only be implemented in 12 months' time, so re-engineering of the job is not feasible at this point. However, management decided to test a variable capacity strategy for dealing with the identified bottleneck. This capacity strategy is based on signing an outsourcing agreement with a personnel agency to supply contractors for the job as application volumes rise, or, conversely, firing these contractors as volumes drop.

 

 

Focusing on the application processing process and the recruitment and appointment process of contractors, the following business dynamic model is created (Figure 6) [11].

 

 

 

In this model, two feed-back loops are created. First, the more applications there are to be processed, the lower the credit clerk's productivity drops (Figure 6). Second, the number of applications informs the hiring/firing decision, which in turn provides more capacity to the processing task in the process via the recruiting process. Simulation of this dynamic behaviour yields the volatility graph in Figure 7. It shows that management will not be able to balance the number of applications with the number of staff hired/fired to provide adequate capacity. This is due to the multiple feedback loops in the process, as well as the time-lag between required capacity and available capacity. This forces management to rethink their tactics for managing variable workloads in this process.

 

6 CONCLUSION

Managers as decision-makers are always seeking new ways to support their decision-making processes at an acceptable level of risk. Typically, the level of risk in a business process can only be determined by understanding and studying the behaviour of the business process, either from historical observations or from simulated experiments. It has been found that traditional design approaches for creating business process specifications may not always cover all the inherent behaviours of the business system. Using the business fractal approach, the business analyst tries to develop more realistic models in order to understand the static and dynamic dimensions of the business process.

The practical application and implication of the business fractal is to provide a way to design business process models that model real-world business processes at an acceptably accurate level for decision-making. It is an alternative approach to modelling, although its different components are not new. The intended value of this is to equip the business analyst with a toolkit to enable the understanding of business process complexity, so that effective decision-making can take place through proper business process design.

During the process of decision-making and design, the designer or decision-maker needs to consider the practical considerations - time, money, and applicable accuracy levels - when solving problems. Although this paper demonstrates the complete approach, certain methods may be omitted during the design process to satisfy stakeholder requirements.

 

REFERENCES

[1] Curtis, B., Kellner, M.I. & Over, J. 1992. Process modelling, in Communications of the ACM, 35(9), pp. 75-90.         [ Links ]

[2] Dijkstra, E. 1979. Programming considered as a human activity, in Classics in software engineering. Yourdon Press, New York.         [ Links ]

[3] Frizelle, G. 1998. The management of complexity in manufacturing. Business Intelligence Limited, London.         [ Links ]

[4] Harry, M. 1990. Information and management systems: Concepts and applications, Pitman Publishing.         [ Links ]

[5] Integrated Definition Language, http://www.idef.com.         [ Links ]

[6] Mandelbrot, B.B. & Hudson, R.L. 2004. The misbehaviour of markets. Basic Books, New York.         [ Links ] [7] Porter, M. 1980. Competitive strategy. Free Press, New York.         [ Links ]

[8] Putler, D.S. & Krider, R.E. 2012. Customer and business analytics, applied data mining for business decision making using R. CRC Press.         [ Links ]

[9] Robinson, S. 2004. Simulation: The practice of model development and use. Wiley & Sons.         [ Links ]

[10] Rumbaugh, J., Jacobson, I. & Booch, G. 2004. The Unified Modeling Language Reference Manual, 2^nd edition. Addison-Wesley Object Technology.         [ Links ]

[11] Sterman, J. 2000. Business dynamics: Systems thinking for a complex world. McGraw-Hill.         [ Links ]

[12] Sterman, J. 2002. Systems dynamics: Systems thinking and modeling for a complex world, Internal Symposium, Massachusetts Institute of Technology Engineering Systems Division.         [ Links ]

[13] Van der Aalst, W.M.P. 2009. Business Process Execution Language, Encyclopedia of Database Systems, pp.288-289, Springer US.         [ Links ]

[14] Van der Aalst, W.M.P. 2011. Process mining: Discovery, conformance and enhancement of business processes. Springer, Berlin.         [ Links ]

[15] Van Rensburg, A. 1996. An open solution methodology to problem solving. PhD Thesis, University of Pretoria, South Africa.         [ Links ]

[16] Van Rensburg, A. 2006. Enabling business process outsourcing with business fractals, EUROMA Moving Up on the Value Chain, pp 1161-1170.         [ Links ]

[17] Van Rensburg, A. 2007. The value chain as an operations reference model, Philippine Industrial Engineering Journal, 4 (1).         [ Links ]

[18] Zhao, Y. 2013. R and Data Mining - Examples and case studies. Elsevier.         [ Links ]

 

 

1 The author is an extra-ordinary senior lecturer at the Department of Industrial Engineering, Stellenbosch University