A fractal enterprise model and its application for business development

Abstract

This paper suggests a new type of enterprise models called fractal enterprise models (FEM), with accompanying methodological support for their design. FEM shows interconnections between the business processes in an enterprise by connecting them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (employees, business process definitions, etc.). A FEM model is built by using two types of patterns called archetypes: a process-assets archetype that connects a process with assets used in it, and an asset-processes archetype that connects an asset with processes aimed to manage this asset (e.g., hiring people, or servicing machinery). Alternating these patterns creates a fractal structure that makes relationships between various parts of the enterprise explicit. FEM can be used for different purposes, including finding a majority of the processes in an enterprise and planning business change or radical transformation. Besides discussing FEM and areas of its usage, the paper presents results from a completed project in order to test the practical usefulness of FEM and its related methodological support.

1 Introduction

1.1 Motivation

For many projects related to business processes, it is important to find all, or at least a major part, of the business processes that exist in a given organization/enterprise. This is not a trivial issue as only the most visible processes catch the attention of management and consultants. These processes represent the tip of the iceberg of what actually exists in the enterprise in half-documented, or in totally undocumented, form (tacit knowledge).

We, ourselves, experienced the difficulties in finding all the processes in an organization when working on a project examining process-orientation in a non-profit organization [4]. The project included building a business process support system, and it was important to see what processes could or should be supported by the system. We partially solved the problem by going through all departments, interviewing people about what kind of tasks they completed and the inputs they received from other departments, what kind of results they produced, and where these were delivered. From the information obtained, we were able to connect the tasks executed in various processes to each other and get a list of process candidates to be supported by a system.

The approach taken in the project was tedious; besides, it did not guarantee that all processes were found. In fact, at a later stage of working with the organization, we found other processes that were overlooked in the initial study. Thus, the question arose whether there is a way of discovering processes more effectively, ensuring that a majority of the processes is identified.

The task of process-orientation in an organization/enterprise by introducing a process support system is not the only task that requires finding all or a major part of the processes in an organization. Any major organizational change directed at identifying and/or solving a problem, or expanding or optimizing the business may require discovering all processes, or a major part of them, related to a specific area. It may not be enough just to investigate one or several main processes belonging to the area of intervention, as the intervention may require adjustments in other parts of the enterprise in question. The latter is a well-known fact in systems dynamics (SD), see, for example, Jackson [33]. In a classical example from SD, optimizing a sales process may result in losing customers if the processes related to the delivery of goods and services are not adjusted on time. Initially, the optimized sales process may result in increasing the number of customers. However, if other processes are not adjusted at the same time, delivery delays may follow which, in turn, may result in losing customers.

The example above illustrates that even when only one process is being redesigned, it is important to find out other processes that could be affected by changes in the given one. Furthermore, the processes affected can be in an entirely different area than the one being changed. For example, changes in the sales process may require changes in the service process to cover the demands from a larger customer base, and changes in recruiting and training of service personnel as a consequence. In addition to finding all processes, or the processes related to the area of intervention, an organizational change project may require understanding the connection between the processes that may be affected by the intervention. Thus, the problem above can be formulated as:

Finding all or a majority of processes in an organization, or all or a majority of processes that can be affected by an intervention in a specific area

needs to be complemented by

... and establishing connections between these processes that could help in identifying a problem and/or planning an intervention

To the best of our knowledge, the academic and practical literature does not include a description of an effective procedure that can help in solving the two parts of the problem above.¹ Suggesting such a procedure is the focus of the research project, the preliminary results of which are presented in this paper.

1.2 Overview of the solution

Our solution is based on the approach from [11] that considers a Business Process Instance (BPI) as a respondent system [39] created by an enterprise/organization in reaction to some (business) situation. After the situation has been resolved, the BPI is disbanded. For the BPI to achieve its set goal, the enterprise transfers some of its assets (e.g., people, infrastructure, equipment, etc.) to this system. To work smoothly over a long period of time, the enterprise needs to have appropriate assets ready to be deployed when the next situation triggers a new BPI. The assets need to be acquired and maintained all the time to avoid the depletion, for example due to people leaving the organization or equipment becoming old. Therefore, the enterprise/organization needs to have specialized processes aimed at maintaining the quantity and quality of its assets on the right level, e.g., processes of recruiting employees, purchasing equipment, training employees, and servicing equipment.

Based on the deliberations above, we suggest the following recursive procedure for discovering processes in an organization with the starting point being the visible part of the “process iceberg,” i.e., the so-called primary processes. Here, as primary we count processes that deliver value for which some of the enterprise’s external stakeholders are ready to pay, e.g., customers of a private enterprise, or a local government paying for services provided to the public. Typical examples of primary processes are hard (e.g., a computer) or soft (e.g., a software system) product manufacturing, or service delivery (e.g., an educational process at a university). After the primary processes are identified, one proceeds with identifying assets that are needed to execute the primary processes. Each asset type requires a package of so-called supporting processes to have the corresponding assets in “working order” waiting to be deployed in the BPIs of the primary process. A typical example of supporting processes is human resources (HR) processes (e.g., hiring or retiring members of staff), which ensure that the enterprise has the right people engaged in its primary processes.

To make the suggested procedure of process discovery more systematic, we introduce two types of archetypes, or patterns, to follow when moving from primary processes to supporting processes:

• Process-assets archetypes (patterns) that help to identify what assets are needed for a particular process, especially for a primary process from which we start discovering the rest of the processes.

• Asset-processes archetypes (patterns) that help to identify supporting processes that are needed to have each type of asset ready and available for deployment.

Having these archetypes/patterns helps to discover the process structure of an enterprise starting from the primary process and recursively applying archetypes in the following manner:

“a primary process –(process-assets archetype)$\rightarrow$ its assets –(asset-processes archetype)$\rightarrow$ processes for each assets –(process-assets archetype)$\rightarrow$ assets for each process $\rightarrow$ ...”.

As a result, we not only discover processes that exist in the enterprise, but also indirect relationships between them, i.e., relationships through the assets. We call the outlined above procedure unfolding procedure. This procedure produces a potentially infinite tree with a repeating pattern of structures.² The nodes of the tree alternate between processes and assets, where the edges lead from a process to the assets it needs, or from an asset to processes aimed at maintaining this asset in “working order.” This tree represents a kind of process architecture [26] of the organization in question.

Infinite structures that are obtained through a recursive application of the same pattern are known in the scientific literature as fractal structures [46]. By analogy, we refer to the tree produced through the unfolding procedure as a fractal enterprise model (FEM). Even though the repetition in FEM exists only on the level of abstract archetypes, and not on the level of processes and assets themselves, we have chosen the term based on the following two reasons. Firstly, it highlights the recursive nature of the unfolding procedure. Secondly, and more importantly, the term fractal has already been used by others in a similar meaning both in academic [58] and practical [30] literature. By using the term fractal, we not only highlight the recursive nature of our model, but also explicitly position our work into an emerging field of research and practice.

When using the word enterprise in the term fractal enterprise model, we do not intend to limit the usage of the new modeling technique to for-profit organizations only. We believe it is applicable to any kind of organization that provides products and services to a wider circle of people or other organizations. We consider as an enterprise any organization in which the operational activities are financed by external stakeholders, i.e., people or other organizations outside the enterprise itself. An enterprise can, for example, be a private company that receives payment for its operational activities from the customers, a head office of an interest organization that receives fees from the members of this organization, or a public office that receives funding from the taxpaying citizens or residents.

As with any model, our FEM is an idealization and abstraction from some details of reality. Therefore, we do not consider a FEM as a universal enterprise model suitable for any possible purpose. The initial motivation for designing FEM was looking for an answer to the first part of the problem posed in Sect. 1.1 (i.e., finding all or a majority of business processes). However, the resulting model turns out to be of a more general nature, and it could be used for dealing with the second part of the task (i.e., establishing connections between the processes found), as well as for solving other problems discussed in this paper.³

The main goal of this paper is to describe the FEM model and provide accompanying methodological support for building FEM for a particular organization and purpose. The methodological support consists of an unfolding procedure based on process-assets and asset-processes archetypes. After introducing FEM and its related methodological support, we discuss its usability for solving practical problems. To test the practical usefulness of the model, we created and evaluated a FEM model for educational activities of a university. We started from one of the primary processes of the university domain—teaching—and discovered the processes connected to it via recursive applications of the unfolding procedure outlined above. The case was chosen because of the authors’ own experience with this process as well as easy access to the expertise of a university department. The chosen case does not mean that the procedure is applicable only to the academic world. When presenting the archetypes, we offer examples from other domains as well.

The research presented in this paper utilized the design science (DS) paradigm [13, 29]. The goal of DS research is finding and testing a generic solution [13] or artifact [29] for a class of practical problems. The FEM and the methodological support suggested in this paper constitute DS artifacts for solving the problem discussed in Sect. 1.1. Though most of the concepts used in building this artifact are not new, the artifact itself, which is the main contribution of the paper, as a whole, is new and original. In addition, we are not aware of any research work specifically devoted to finding answers to the questions above. So our solution, even if not perfect, can be used in practice until a better one can be found.

1.3 The background and structure of the paper

This paper is based on an experience report Elias et al. [22] presented at the working conference for Business Process Modeling, Development and Support in 2014 (BPMDS 2014). The current paper has a more theoretical nature than the experience report, the latter being used in the paper to validate and illustrate our line of thought and findings. The experience report [22], in turn, has been built on ideas presented at the conference on Practice of Enterprise Modeling in 2012 (PoEM 2012), see [14]. Therefore, the current paper could also be considered as a substantial extension and revision of Bider et al. [14] based on the experience reported in [22]. In the current paper, the fractal model, first suggested in [14], has been improved by adding more details to the archetypes. Besides the model improvement, this paper includes a review of related literature, and an extended discussion on the usability of FEM.⁴

The rest of the paper is structured in the following way. In Sect. 2, we provide an overview of literature from relevant academic fields. In Sect. 3, we describe the research method and background on which our solution has been built. In Sect. 4, we describe FEM in more detail. In Sect. 5, we discuss the potential areas of usability for FEM. In Sect. 6, we test FEM in a case by applying the archetypes defined in Sect. 4 to unfold parts of the process structure of the Department of Computer and Systems Sciences of Stockholm University. In Sect. 7, we compare our approach for defining relationships between the processes with the works of others reviewed in Sect. 2. In Sect. 8, we discuss open issues. Section 9 summarizes the results achieved so far and outlines plans for the future.

2 State of the art

There are several academic fields that are related to the research reported in this paper including research on process architecture, enterprise modeling frameworks focusing on resources and processes, and fractal models of an enterprise. In the subsequent subsections, we will provide a short overview of these fields. In this section we do not focus on comparing FEM with the works of others, leaving such comparisons for Sect. 8 where we also present a framework developed to this end.

2.1 Business process architecture

An enterprise architecture specifies the “essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change” [21]. An enterprise architecture can, in turn, consist of a business architecture, an application architecture, a data architecture, and a technical architecture, as in The Open Group Architecture Framework (TOGAF) [64].

In the business part of enterprise architecture, the focus is often on the business processes [57, 60]. These business processes can, in turn, be organized in what is sometimes called a business process architecture [26, 37]. Such an architecture consists of a number of process models, specifying which business processes exist in an organization, how each of them starts and ends, and the relationships between them [18]. By using a business process architecture, an organization can design consistent and integrated business processes. Dijkman et al. [18] have identified five design approaches for business process architectures, such as goal-based, action-based, object-based, reference-based, and function-based approaches, which briefly will be described below.

The goal-based approaches for business process architectures use a goal structure as the base, and from this structure the business process architecture is derived [41]. That is, first, a number of business goals and their relationships are specified, often in a hierarchy, and then, based on the goals, business processes are identified. Thereby, these business processes in the business process architecture can be related to the goals of an organization. An example of a goal-based approach relating goals and processes can be found in [48, 56], aiming at organizational change.

The action-based approaches assume that the interaction between a consumer/customer and a provider can be described as an action loop, consisting of a pattern of phases that need to be carried out in order to finalize an interaction [17, 42]. These patterns and their phases can be used as a base for identifying business processes in a business process architecture.

The object-based approaches for business process architectures start by specifying business objects and their relationships in a business [26]. This results in an object structure, often called a conceptual model. Based on the object structure, business processes can be identified, for example by elaborating which operations can be carried out on the objects, and then design business processes to support these operations. Certain kinds of objects, such as an order or a referral, can also be used to identify business processes. These kinds of objects work as cases or as flow objects in a business process, and the business process can be seen as managing these objects, which change states during the execution of the business process.

The reference-based approaches [24, 60] use a reference framework consisting of a number of specified and related business processes, such as the SAP reference model [16], and the MIT Process Handbook [44]. Based on such reference frameworks, which themselves can be interpreted as business process architectures, a process architecture framework for an organization can be designed.

Finally, in the function-based approaches, the business processes are identified based on the business functions in an organization [60].

Dijkman et al. [18] also specify a number of relationship types between business processes in business process architectures, such as decomposition, which is a part of relationship; specialization, which is an ISA relationship or generalization–specialization relationship; a trigger relationship, which means that one business process triggers another; and a use relationship, which mean that one business process provides services used by another.

An approach to business process architecture that includes a procedure to identifying processes is suggested in [19]. It is based on initially organizing processes according to case types and business functions. Large processes can then be decomposed using guidelines that take into account logical separation in time and space, transactional states, as well as several other aspects.

2.2 Enterprise modeling frameworks focusing on resources and processes

Two approaches that propose general frameworks for enterprise modeling with a focus on resources (called assets in FEM) and their transformations in business processes are those by Alter [2] and Osterwalder [49]. Alter [2] proposed the notion of work system as a unit of analysis for reasoning about systems in organizations, thereby using business processes as the central component. A work system is a system in which human participants and machines carry out work (processes and activities) using information, technology, and other resources in order to produce products and services for customers. In most business organizations, there are work systems that procure materials from suppliers, produce products and services, deliver products to customers, attract and retain customers, manage after sales services, hire employees, as well as perform many other functions.

Osterwalder [49] has developed an ontology for business models, which provides a conceptual basis for the business models of organizations. Based on the ontology, Osterwalder and Pigneur [50] have developed a strategic management and entrepreneurial tool, called the Business Model Canvas (BMC), which is intended to support people in describing, analyzing, designing, and inventing business models. BMC offers a visualization of the key elements of a business model in the form of a canvas, including customer-oriented components as well as resource oriented ones. The elements of BMC comprise value propositions, customers, customer relationships, channels, revenue streams, key resources, key activities, partners, and cost structure. Comparing the BMC with the work system framework proposed by Alter [2], it can be noted that many of the elements overlap. However, BMC is specifically tailored for modeling value generation in business networks, while the work system framework can be applied in many different contexts, e.g., for modeling information systems, service systems or value chains. In this paper, BMC and the work system framework are used as a basis for the process-assets archetypes, in the sense that their components provide a set of generic assets that are required for main processes as well as supporting processes.

BMC and the work system framework offer a helicopter view on the processes in and across organizations as well as their relationships to resources and partners. Other frameworks go into greater detail on the interplay between processes and resources, e.g., the REA ontology. The Resource–Event–Agent (REA) ontology was originally formulated in [45] and developed further in a series of publications, e.g., [32]. The ontology is based on the core concepts of resources, events, and agents. Originating in accounting, it also carries the underlying principle of duality in resource transfers between agents, expressing that an agent offers a resource only when expecting to receive another resource in return. The same duality holds for production processes, in which a resource can be produced or improved only if other resources are used or consumed. These observations form the basis for the value chain modeling using REA, which in its most basic form depicts processes in an organization and the flows of resources between them [20]. The REA value chains have many similarities to the FEM models proposed in this paper. However, the latter are more expressive than REA value chains, as they make explicit the kinds of relationships between processes and resources through the notion of archetype. Furthermore, FEM offers an associated methodological support for discovering processes, while REA value chains only provide a language for representing process and resource flows.

2.3 Fractal enterprise models

Analyses of enterprises based on the idea of fractality have been conducted by several researchers and practitioners, e.g., [30, 47, 55, 58]. Their approaches differ from that of ours, which comes as no surprise as there is no accepted definition of what fractals mean with respect to the enterprise world. In essence, fractals are a high-level abstract idea of an infinite structure obtained by recursive application of the same pattern. Dependent on the perspective chosen for the modeling of a real life phenomenon, this pattern will be different for different modelers. Below, we shortly summarize the works on fractal structures in enterprise modeling, and show the difference between them and our approach.

The book by Hoverstadt [30] used the viable system model (VSM) to present the fractal structure of the enterprise via the system–subsystem relationships. Subsystems are considered as having the same structure and generic organizational characteristics as the system in which they are enclosed. The resulting structure helps to analyze whether there is a balance between the subsystems. Though our goals are somewhat similar to those of Hoverstadt [30], we use an entirely different approach to enterprise modeling, instead of system–subsystem relationships, we interleave processes and assets when building an enterprise model.

Another approach to the analysis of enterprise models based on the idea of fractality can be found in [58]. The idea is to find fractal structures in an enterprise model built when using a general modeling technique. Sandkuhl and Kirikova [58] analyzed two such enterprise models in order to find fractals in it. The results were mixed with some fractals being found, but with the suspicion that many others were not detected, as they were not explicitly represented in the models analyzed. The approach in [58] radically differs from that of ours. We have a hypothesis of a particular fractal structure to be found when analyzing an enterprise, while [58] was attempting to find any type of fractal structure based on the generic characteristics of organizational fractals.

Mercedes Canavesio and Martinez [47] presented a conceptual model for analyzing a fractal company aiming at supporting a high degree of flexibility to react and adapt quickly to environmental changes. Main concepts included project, resource, goal, actor, plan, and relationships thereof. The approach by Mercedes Canavesio and Martinez [47] differs from ours in the kind of fractals used for enterprise modeling. Fractals by Mercedes Canavesio and Martinez [47] concerned the detailed structure of business processes instances, while we are looking at the relationships between different processes (and between processes and assets).

The focus on process organization when applying fractal principles can be found in [55]. The author is using a pattern of sense-and-respond processes on different organizational levels each consisting of the same pattern: requirement, execution, and delivery. The difference between our approach and that of Ramanathan [55] is the same as we have discussed above. Ramanathan [55] is looking at the details of individual process instances, while we are trying to capture general relationships between different processes. Moreover, the idea of a recursive organization is also relevant for service systems, which recursively can be decomposed into constituent service systems [43], although the idea of recursivity is not further elaborated in this work.

The work by Hoverstadt [30] more than any other works reviewed in this section highlights the idea of recursivity when using the term fractal, and thus we consider it as the most distinguished in the emerging field of the fractal enterprise modeling/architecture. This comes as no surprise, as this work was based on the VSM model by Beer [9]. The model presents the structure of a viable enterprise, i.e., an enterprise capable of adapting itself to changes in its business environment. According to the Ashby law [6], the complexity of the structure of a system capable of adapting to the environment needs to match the complexity of the environment by having the same number of internal states as the environment. To achieve viability, VSM suggests a system being constructed as a collection of semi-autonomous components (units) placed on different levels denoted as System 1, 2, 3, 4, 5. Each component interacts with only part of the business environment and is responsible for adaptation to changes in this part. Having all parts of the environment covered by such components produces a viable system that satisfies the Ashby law in an effective way. Furthermore, each component may also recursively be viewed as a viable system which ensures viability when a system is relatively large, e.g., an international corporation.

From the discussion, the term fractal enterprise/organization as defined by Hoverstadt [30] is used to provide a way to achieve viability/adaptability. Though the motive for building our FEM was different, we believe that FEM can also help in achieving viability/adaptability, which is discussed in Sect. 8.

3 The research approach and background

3.1 The research approach

The development of our fractal model follows the pattern of design science (DS) research [8, 29, 52], which seeks new solutions for problems known or unknown [3]. To count as a DS solution, it should be of a generic nature, i.e., applicable not only to one unique situation, but to a class of similar situations, cf. Principle 1 of [62]. DS research can be considered as an activity aimed at generating and testing hypotheses for future adoption by practice [13]. Therefore, implementation and verification of a generic solution [13] or artifact [52] in at least one situation, is a critical part of DS, usually referred to as demonstration or proof of concept [52].

Design science, as a way of generating and testing hypotheses for generic solutions, requires researchers to act in two different worlds: (a) the real world of specific situations, problems and solutions in local practices, and (b) the abstract world of generic situations, problems and solutions [13]. Design science does not impose any particular order of movement in the two worlds. A researcher can start with a specific problem in a specific situation, find a solution for it (situation to-be that solved the problem), and then generalize all three parts of his/her test case: situation, problem, and solution. Classification of the ways of working in this manner is presented in [3]. The researcher can also start from the other end—with finding a generic solution for a known generic problem and then try to find and implement a test case for its demonstration.

This research was initiated by a practical problem encountered in the consulting practice of the first author related to business process analysis projects, namely “how to find all processes in the given organization, using minimal resources.” This problem did not have a satisfactory solution and was handled in a relatively ad hoc way, with a risk of missing some important processes that are in place without people in the organization being aware of their existence. During the research project, the problem, as discussed in Sect. 1.1, was extended to:

Finding all or a majority of processes in an organization, or all or a majority of processes that can be affected by an intervention in a specific area and establishing connections between these processes that could help in identifying a problem and/or planning an intervention, while using a minimum of resources

In this paper, we propose a solution in the form of a new type of enterprise models called fractal enterprise models (FEMs) as well as methodology support for designing FEMs. The key requirement for FEMs is that they should be perceived as useful for practical tasks by the people who participate in the processes in an organization, and management who is responsible for detecting and solving organizational problems and/or using new opportunities appearing in the market. The key requirement for the methodology support is that it should enable designers to build FEMs with relatively few resources. The proposed solution is evaluated with regard to these two requirements by means of a case study in a higher education setting, see Sect. 6. This case study can also be viewed as a demonstration showing the feasibility of the proposed solution.

The knowledge for this solution is based on the following:

• Own practical consulting experience in the area of business processes

• Own work devoted to considering business processes from a system perspective [11]

• Existing literature related to fractal models and process architecture reviewed in Sect. 2.

3.2 The background: business processes from a systems perspective

The notion of business process can be considered from different perspectives. It can be treated as a flow of activities or operations, i.e., workflow view, or as a communication between people engaged in collaborative effects, to name a few possible views. In this paper, we view business processes from a systems perspective as suggested in [11].⁵ Under a systems perspective, we consider presenting a phenomenon, e.g., a business process in our case, as a complex system interacting with its environment.

The most straightforward way of considering a business process from a system perspective that we found is by applying the idea of systems coupling diagram suggested by Lawson [39]. A generic case of using such diagrams is shown in Fig. 1. In this figure, the vertical double line represents the border between the system of interest (SI)—to the right of the border, and its environment—to the left of the border. When SI detects a situation in the environment that needs some reaction, it creates a so-called respondent system (RS) to deal with the situation. The RS is built from the assets that SI already has. Some of these assets are people, others are of equipment type, stills others are control elements, e.g., policy documents, that define the behavior of the respondent system. Lawson [39] defines a control element as an asset that directs the respondent system when it operates and differentiate it from other assets by using black dots (see Fig. 1).

As an example, consider a situation when a country/state is an SI (system of interest). SI detects a suspicious movement of the enemy on its border, which is a situation. It forms a special army unit to deal with the situation, which is an RS (respondent system), and sends it to the border. This unit can be comprised from the existing military units, or by calling reservists. Military codes, engagement rules, etc. serve here as control elements. The enemy either withdraws, or is beaten by the RS; after that the RS can be disbanded, and the reservists can go home.

Fig. 1

System coupling diagrams from [39]

The term Business Process (BP), as used in the research and practical literature, encompasses two distinct concepts Business Process Instance (BPI) and Business Process Type (BPT). A BPI (in some works referred to as case or run) is a business situation being handled according to some common procedure. A BPT refers to all BPIs (in the past, present and future) aimed at dealing with a given type of business situation. For example, a sales process (type) represents BPIs aimed at dealing with a situation of appearing of potential customer. It is also worth mentioning that in the literature devoted to BP, the term business process is often used without a qualifier (type orinstance), the supposition being that the qualifier can be understood from the context. To avoid any misunderstanding, we use term business process without a qualifier only in the meaning of business process type, using the abbreviation BPI for referring to business process instances. This is because the rest of this paper, starting with Sect. 4, is focused on process types, rather thanprocess instances.

From the systems perspective defined above, a BPI can be considered as a temporal (respondent) system created by the organization/enterprise to deal with a certain situation. The situation can be of an expected (often occurring) type, like a customer placing an order, or an exceptional one. To deal with repeatedly appearing situations of a given type effectively, an enterprise creates templates for dealing with the majority of known types of situations. Such a template is known under different names, like project template, business process definition, process description and business process model. We will refer to it as EXecution Template (EXT). An EXT may exist in different forms, e.g., as tacit knowledge, i.e., in the heads of people working with a given process, or in an explicit form, e.g., employee’s handbooks or position descriptions, or process diagram. It may also be built into the hardware and/or software used to control, or support the given process. From the point of view of systems coupling diagrams (see Fig. 1), EXT is a control element as it defines/directs the operational behavior of a BPI which we regard as a kind of RS.

In the definition above, we take a very broad view on business processes, which might differ from narrow views that only deal with processes that have a highly strict control flow of activities. In our perspective, two conditions need to be satisfied for considering a process as belonging to the business process category. Firstly, it should represent a repeating activity that engages people,⁶ and secondly, there should be a kind of template that is used when initiating and executing each instance as a reaction to a business situation of the given type. The template can exist in different forms. It can be defined as a very detailed workflow diagram that determines the activities to be executed and their order, or as a number of forms to fill out, as in case or adaptive case management [12, 63]. In such a broad view, projects of the same kind completed by a company engaged in a project-oriented business, e.g., construction, or software development, are also considered as BPIs for which there normally exist templates, e.g., activities flow descriptions and standard Gantt diagrams. However, one-time only projects are not considered in this paper as BP and are thus outside the scope of this paper.

As a kind of RS, BPI needs to receive some assets to effectively deal with the situation. Such assets (tangible and intangible) can include:

• People with their knowledge and practical experiences, etc.

• Physical artifacts—computers, telephone lines, and production lines.

• Organizational artifacts—departments, teams, networks, and roles.

• Knowledge in explicit and tacit forms:

  • $\bullet$ Explicit knowledge—information artifacts—policy documents, manuals, written instruction, etc.

  • $\bullet$ Tacit knowledge—knowledge that is imprinted in people’s heads, e.g., organizational culture and tacit execution rules for executing instances of a given process

Note that assets here are not regarded in purely mechanical terms. All “soft” assets, like sense of common goals, capability to collaborate, and shared vision, are considered as belonging to the organizational assets. Note also that organizational artifacts include not only the artifacts related to the functional organizational structure, but any kind of project teams are considered as organizational artifacts.

A BPI as a respondent system is created as a response on a situation that has been detected. Its purpose is to handle the situation with assets that it has to its disposal. With such a definition, the task of detecting the situation and allocating specific assets is left outside the BPI. Discussing the mechanisms of detecting the situations and controlling BPIs after their creation lies outside the scope of this paper, see, however, the notion of sensors suggested in [11] as a mechanism for detecting situations that require the invocation of BPIs.

Between the processes and assets, there are various kinds of relationships. On the one hand, assets are used inside BPIs when they are started. On the other hand, BPIs can change assets. Some business processes are explicitly aimed at changing assets. For example, the business process of hiring employees is aimed at increasing the human asset in size, while training of employees is aimed at improving the quality of the human asset. Other business processes modify assets even when they are not explicitly aimed at assets management. For example, people participating in a particular process acquire experience, which changes the quality of the human asset. Sometimes, this change can be far greater than the one achieved by training. Other assets that can change while employees participate in a business process include attitudes and beliefs toward other assets engaged in the process, e.g., equipment, management, EXT, etc. Note that expressions like “an asset is used in a process” or a process is “using an asset” above have a broad meaning. Namely, they mean that BPIs of the given process type cannot run without such an asset being at their disposal.

From the discussion above, it follows that there can be a duality in the relationships between a process and an asset. An asset can be “used” in BPIs of the given process type and at the same time be changed during its usage in an important aspect that increases its value. Whether only one or both relationships—“used in” and “changed by”–are to be represented (if both exist) in a model depends on the purpose of the model. Other issues of multiple relationships between process and assets are discussed in Sect. 4.5.

4 A fractal enterprise model (FEM)

4.1 The structure of the model

Our fractal enterprise model (FEM) includes three types of elements: business processes (more exactly, business process types), assets, and relationships between them, see Fig. 2 in which a fragment of a model is presented.⁷ Graphically, a process is represented by an oval, an asset is represented by a rectangle (box), while a relationship between a process and an asset is represented by an arrow. We differentiate two types of relationships in the fractal model. One type represents a relationship of a process “using” an asset; in this case, the arrow points from the asset to the process and has a solid line. The other type represents a relationship of a process changing the asset; in this case the arrow points from the process to the asset and has a dashed line. These two types of relationships allow tying up processes and assets in a directed graph.

Fig. 2

A fragment of a fractal enterprise model from Sect. 6

In FEM, a label inside the oval names the given process, and a label inside the rectangle names the given asset. Arrows are also labeled to show the type of relationships between the processes and assets.

A label on an arrow pointing from an asset to a process identifies the role the given asset plays in the process, for example, workforce, equipment, etc. A label of an arrow pointing from a process to an asset identifies the way in which the process affects (i.e., change) the asset. In FEM, an asset is considered as a pool of entities capable of playing the given roles in the given processes. Labels leading into assets from supporting processes reflect the way the pool is affected, for example, a label acquire identifies that the process can/should increase the pool size.

As it will be shown in Sect. 6, the same asset can be used in two different processes playing the same or different roles in them, which is reflected by labels on the corresponding arrows. It is also possible that the same asset can be used for more than one role in the same process; in this case, there can be more than one arrow between the asset and the process, but with different labels. Similarly, the same process could affect different assets, each in the same or in different ways, which is represented by the corresponding labels on the arrows. Also, it is possible that the same process affects the same asset in different ways, which is represented by having two or more arrows from the process to the asset, each with its own label.

In FEM, different styles can be used for borders of ovals, rectangles and arrows to group together different kinds of processes, assets, and/or relationships between them. Such styles can include using dashed or double lines, or lines of different thickness, or colored lines and/or shapes. Example of using styles will be presented in the next sections.

Labels inside ovals, which represent processes, and rectangles, which represent assets, are not standardized. They can be set according to the terminology accepted in the given domain, or be specific for a given organization. Labels on arrows, which represent the relationships between processes and assets, however, can be standardized. This is done by using a relatively abstract set of relationships, like workforce and acquire, which are clarified by the domain- and context-specific labels inside ovals and rectangles. Standardization improves the understandability and interoperability of the models.

To make the work of building a fractal model more systematic we introduce archetypes (or patterns) for fragments from which a particular model can be built. An archetype is a template defined as a fragment of a model where labels inside ovals (processes) and rectangles (assets) are omitted, but arrows are marked, see, for example, Fig. 3. Instantiating an archetype, means putting the fragment inside the model and labeling ovals and rectangles; it is also possible to add elements absent in the archetype, or omit some elements that are present in the archetype.

We introduce two types of archetypes, process-assets archetypes and asset-processes archetypes. A process-assets archetype represents which kind of assets that can be used in a given category of processes. An asset-processes archetype shows which kinds of processes are aimed at changing the given category of assets.

Note that the fractal model does not represent direct relationships between business processes, such as generalization or composition. On the level of abstraction accepted for the fractal model, a process with all its possible subprocesses is considered as one business process.

4.2 The generic archetype

We define several process-assets archetypes, starting with a generic archetype that shows asset types that can be used in any kind of processes. The generic process-assets archetype is presented in Fig. 3. It has a process symbol (oval) as its root and shows which type of assets can be used in a process via labels on the arrows going from rectangles to the oval. We identify the following assets for the generic archetype:

• 1. Workforce—people trained and qualified for employment in the process. Examples: workers at the conveyor belt, physicians, researchers.

• 2. EXT —process execution template. This can, for example, be: a software development methodology accepted in a software vendor company; product design for a manufacturer; technological process design, also for a product manufacturer; description of the service delivery procedure, e.g., a process map for a service company. As discussed in Sect. 3, EXT represents the control elements type of assets. Note that here EXT refers only to the knowledge in its explicit form, other parts of EXT, for example tacit knowledge of workers, are incorporated in other type of assets, e.g., workforce. Note also that EXT does not need to be in a form of a procedure or algorithm. For example, a policy document on equal opportunities in recruitment of staff is regarded as an EXT for the recruitment process. In addition, this document could be used as an EXT for developing an execution template for the recruitment process. The same consideration concerns a value proposition asset, for example, in the form of a statement on what kind of value a customer gets from a given service. This asset can be used as an EXT for the service delivery process, and as an EXT for developing the service process itself. In the same way, the value proposition for a product could be used as an EXT in the product development process (e.g., the product should include certain functionality), and in the technology development process (e.g., high quality, or low cost of production).

• 3. Partner—an agent, external to the given organization, who participates in the process. This, for example, can be a supplier of parts in a manufacturing process; a lab that completes medical tests on behalf of a hospital. Partners can be other enterprises or individuals, e.g., retired workers that can be hired in case there is a lack of a skilled workforce for a particular process instance.

• 4. Stock—a stock of materials or parts that are used in the process. This, for example, can be: office products, e.g., paper, pens, printer cartridges, in any office, or spare parts for a car repair shop. A stock needs to be represented in FEM only if the organization itself maintains the stock, and does not directly get materials or parts from the supplier for each process instance. In the latter case, it is enough to represent a supplier as a partner.

• 5. Technical and Informational Infrastructure—equipment required for executing the process. This, for example, can be: a production line, computer, communication line, building, software system.

• 6. Organizational Infrastructure—a unit of organization that participates in the process. This, for example, can be: sales department, software development team.

• 7. Means of Payment—any kind of monetary fund that is needed to pay participating stakeholders, e.g., suppliers if such payment is considered as part of the process. We use a double line border for presenting this asset to show that it belongs to the monetary assets. This might be convenient for finding all places in FEM where money is involved.

Fig. 3

The process-assets archetype for generic process

Fig. 4

The process-assets archetype for primary processes

Fig. 5

An example of instantiation of the process-assets archetype for primary processes

Below we provide some additional clarification on the list of assets above.

• The order in which the asset types are listed is arbitrary and does not reflect the importance of assets of a given type, all of them are equally important.

• There is no limitation to how many assets of a given type (connected by an arrow with a given label) could be connected to a given process. For example, there can be several different categories of people participating in the process and several types of suppliers.

• Our notion of asset does not coincide with the one accepted in the world of finance [23]. Except the stock, technical infrastructure and means of payment, all assets listed above belong to the category of so-called intangible assets of the finance world. Intangible assets usually lack physical substance and their value is difficult to calculate in financial terms. Technical infrastructure belongs to the category of fixed (i.e., aimed at long term usage) tangible assets. Stocks and means of payments belong to the category of current tangible assets.

• The following two types of assets—workforce and partners—belong to the category that we call stakeholders. We differentiate them by the role they play in business processes. The workforce directly participates in the process instances and receives compensation for their participation (e.g., in the form of salary). Partners provide the processes with resources needed for process instances to run smoothly, e.g., electricity (power provider), materials, parts, advice. We use diamonds at a starting point of arrows to differentiate stakeholders from other types of assets. This is useful when considering other processes related to stakeholders.

• As discussed in Sect. 3, organizational knowledge is an important asset that is needed for running any business. However, we do not include it in the generic process archetype as such, as this asset is incorporated in other types of assets present in the archetype. Explicit knowledge related to running BPIs is included in EXT (#2 in the list above). Tacit knowledge is included in Workforce (#1 in the list above), as we consider workforce not as a collection of people, but as trained and experienced workers that have knowledge on how to execute the BPIs in which they participate. Some knowledge can be embedded in assets of the type Technical and Informational Infrastructure (#5 in the list above). For example, a software system aimed at supporting people in executing BPIs of the given process type embeds operational knowledge about this process. Also, we do not require that a list of assets included in the generic archetype cover all kinds of organizational knowledge. Specific types of such knowledge can be included when the generic archetype is being specialized. Some examples of such specializations are presented in the next subsections.

4.3 The primary process-assets archetype

We define a primary process as a process that (a) delivers value to some of the enterprise’s external stakeholders (b) for which the same or other external stakeholders are willing to pay. Typical examples of primary processes are: delivery of goods from the stock, product manufacturing on demand and service delivery. A primary process in our model may or may not be the one that creates the value delivered to a stakeholder. In case of the service delivery, a primary process also creates the value. In case of delivering manufactured products from the stock, the manufacturing process, which actually creates value, in our classification, is considered as a supporting process. Note also, that value creation could be spread through the chain of processes. For example, for innovative products, the product design process is the one that creates most of the value.

Our definition of the term primary, sometimes called main or core, is not be the same as those of others [27, 59]. For example, we consider as primary processes neither sales nor marketing processes, nor product development processes in a product manufacturing company. Our definition of the primary also does not correspond to the one of Porter [53], who distinguishes between primary—value creating—processes and supporting processes.

The notion of primary process as a value delivery process is introduced in order to define a root (or several roots) from which to recursively discover other processes. This notion does not represent the importance of these kind of processes against the supporting processes. It is essential that both conditions, (a) value delivery, and (b) payment, are satisfied for a process to be considered as primary. For example, a marketing or sales process can provide “educational” value to some organizations by informing them about a specific class of products or services of which they previously had no knowledge. However, as the enterprise is not getting paid for such an “educational” service, we do not consider the processes providing them as primary.

As already discussed in Sect. 1, when using the term enterprise in FEM, we mean not only for-profit organizations, but also non-for-profit ones and public offices. As far as primary processes are concerned, a difference between for-profit organizations and others is that for the former, normally, a customer both receives value and pays for it, but for the latter, receiving value and paying stakeholders may differ.

The archetype for the primary process is presented in Fig. 4; it is obtained by specialization of the generic archetype from Fig. 3. By specialization, we mean adding new assets types to an already introduced archetype. In the case of the archetype of the primary process in Fig. 4, it differs from Fig. 3 by the presence of an additional asset, namely:

• 8. Beneficiary—an organization or person that receives some value from the process, for which the beneficiary or somebody else is ready to pay. A typical beneficiary is a customer⁸ who buys goods and/or services and pays for them. There can be more than one beneficiary in a given process. A beneficiary is also considered to be a stakeholder of the process, which is shown by the diamond as the starting point of the arrow connecting the beneficiary to the process in Fig. 4.

Instantiation of an archetype is done by inserting labels inside the oval and rectangles. As there can be more than one asset of the same type used in the given process, instantiation can also result in adding more rectangles by “multiplying” some relationships between the process and assets it uses. This is different from specialization, which adds new types of relationships between a prototypical process and its assets.⁹

Figure 5 is an example of an instantiation of the archetype from Fig. 4 for an on-demand-based manufacturing process. Note that this instantiation has been built for the purpose of illustration only; it does not show the full complexity of the process-assets, as there can be many assets of each given type. The instantiation has been done based on our understanding of the structure of a modern enterprise acquired partly from our own consulting practice, partly from the existing body of literature.¹⁰

Fig. 6

Asset-processes archetype

Fig. 7

An example of instantiation of the asset-processes archetype

4.4 The asset-processes archetype

In Sects. 4.2 and 4.3, we introduced eight types of assets that are needed to ensure that BPIs of a primary process run smoothly and with required frequency. Each asset type requires a package of supporting processes to ensure that it is ready to be employed in BPIs of the primary process. We present this package as consisting of three types of processes connected to the life cycle of each individual asset (see Fig. 6):

• 1. Acquire—processes that result in the enterprise acquiring a new asset of a given type. The essence of this process depends on the type of asset, the type of the process(es) in which the asset is used and the type of the enterprise. For a product-oriented enterprise, acquiring new customers (beneficiary) is done through marketing and sales processes. Acquiring skilled work force is a task completed by a recruiting process. Acquiring a new EXT for a product-oriented enterprise is a task for a new product and new technological process development.

• 2. Maintain—processes that help to keep existing assets in the right shape to be employable in the BPIs of a given type. For customers, it could be customer relationship management (CRM) processes. For workforce, it could be training. For EXT, it could be product and process improvement. For technical infrastructure, it could be service.

• 3. Retire —processes that phase out assets that no longer can be used in the intended process. For customers, it could be canceling a contract with a customer that is no longer profitable. For EXTs, it could be phasing out a product that no longer satisfies the customer’s needs. For the workforce, it could be actual retirement.

An instantiation of the asset-processes archetype is done by putting labels in the rectangle and ovals of the archetype. An example of instantiation of the asset-processes archetype for asset customers from Fig. 5 is presented in Fig. 7. As with Fig. 5, Fig. 7 is just an illustration; the actual fragment of the FEM related to customers might be much more complex. As can be seen from this example, there can be two or more processes attached to an asset with the same label. Both marketing and sales are aimed at bringing more customers to the company, marketing by attracting potential customers, sales by making a potential customer to a real one by, e.g., signing a contract.

Fig. 8

Extending FEM—example

4.5 Unfolding the fractal structure of the enterprise

Based on the archetypes introduced in the previous sections, we suggest the following procedure of finding processes that exist in an organization.

• 1. We start with the primary processes, i.e., the processes of which, usually, people working in the organization are well aware, as they are essential for the cash flow.

• 2. For each primary process, assets that are needed for its regular execution are listed by following the primary process-assets archetype from Fig. 4. In this way, we get a root (or roots if there is more than one primary process of interest) of a FEM tree to expand in the subsequent steps.

• 3. For each asset identified earlier, we identify processes aimed at acquiring, maintaining and retiring the given asset according to the asset-processes archetype from Fig. 6. This will expand the already built FEM tree (or forest) with new “leaves”. For example, by attaching the fragment from Fig. 7 to the FEM from Fig. 5, we arrive at an extended FEM presented in Fig. 8.

• 4. For each supporting process identified in 3, we identify assets that are needed for its execution. This can be done by using the generic process-assets archetype to find assets that are applicable to any kind of processes. After all assets that are prescribed by the generic archetype are found, an attempt is made to find assets specific for the given process type (not prescribed by the generic archetype). This can be done by asking questions, such as “what else is needed to run the instances of this process type?”. For some supporting processes, however, it is possible to define specific archetypes, which will be done in the next section.

• 5. Go to step 3 for the next level of expansion, or stop if the so far built FEM is adequate for the purpose for which the model is being built.

The above procedure begins with a primary process for building a FEM. However, this starting point is not mandatory. One can start at any place in a model and expand it down and/or up. For example, one can start with a particular asset, e.g., employees, and find all supporting processes for it. The starting point and decision where to stop depends on the purpose for which the model is being built. To find all, or a majority, of the processes in the given organization, one can use the 5-step procedure defined above. To identify problems related to the quantity and quality of workforce asset, it might be enough to find and make an overhaul of all processes related to this particular asset.

There are other issues that can affect what the final FEM model would look like. One of them is the granularity of the model. For example, having a supplier of some materials or parts can be presented in two ways. The first one is having a stock of parts which is maintained by special processes of purchasing them from the supplier. The second way is by just having a supplier as a partner in the process. Which alternative to choose depends on the purpose of modeling. For example, if we want to investigate all processes related to stocks of materials or parts, we need to have stocks explicitly defined in the model. If, on the other hand, we are interested in processes related to management of partners, we can skip stock assets and represent suppliers directly as partners in the respective processes, independently of whether the stocks exist in reality or not.

Using the unfolding procedure as above, we, potentially, can get an infinite tree. As the idea of having such a tree contradicts common sense, there should be some natural stopping points. We see several stopping points that harness the growth of the tree, beside the stops influenced by the purpose of modeling which may not require expansion beyond the area of interest. Examples of such stopping points are as follows:

Fig. 9

Process-assets archetype for acquiring stakeholders

• Some processes, e.g., maintenance of infrastructure, can be outsourced to a partner. In this case, the maintenance process subtree of FEM can be represented in a simplified form, having only one asset connected to the process—partner who takes care of all work to be done in the process.

• Some processes can share assets, e.g., workforce or EXT. For example, recruiting of staff can be done according to a generic procedure (i.e., EXT) independent from for which processes the employees are recruited.

• Some processes can be of dual purpose and thus can be placed in several places of the model. For example, the consulting business of a software vendor can be considered as both a primary process, as it generates revenues, and as a customer maintenance process as it helps to ensure the customers’ continuing usage of the software products. Another example, if a primary process directly brings money to the company, e.g., order delivery that includes charging and accepting fee, this process will appear as a supporting process of type acquire for the asset monetary funds, see Sect. 4.7 for a graphical presentation of this case. More examples on dual-purpose processes and assets see in Sect. 6.4. Dual usage of processes and assets means that the result of the unfolding procedure is neither tree, nor a forest but a directed graph of generic type.

• Some supporting processes may not exist in the organization in the sense that the needs for starting a process instance arise rarely and are handled in an ad hoc manner. For example, a small start-up may not have any routines of hiring people until it gets bigger.

4.6 Archetypes for supporting processes

In the same way as we have done for primary processes, we can specialize the generic process-assets archetype from Fig. 3 for supporting processes. This is difficult (if ever possible) to do in a general manner, thus the specialization is done separately for each type of asset. In Fig. 9, we represent an archetype for a process of acquiring stakeholders, e.g., customers. This archetype can be applied to any acquire process that is related to an asset that in its own turn is connected by an arrow with a diamond starting point to some process. An example of a place in Fig. 8 where the acquire stakeholders archetype can be applied is the Sales process, which is an acquire process for customers—stakeholders of a primary process. It can also be applied for acquiring other stakeholders, e.g., recruiting employees, or finding suppliers.

As follows from Fig. 9, the archetype of acquiring stakeholders has two additional placeholders for assets beyond the ones that already exist in the generic archetype from Fig. 3:

• Attraction—For a customer, for example, it could be a value proposition, i.e., a statement of benefits that a customer will get by acquiring certain products and/or services. For recruiting staff it could be salary and other benefits that an employee receives. There can be more than one parameter in the attraction, each of which can be represented by a different asset connected by the attraction arrow to the process. For example, beside a competitive salary, an environment with a modern technical and information infrastructure can be considered as an asset for recruiting talents. The latter is an example of the same asset serving multiple purposes in the enterprise, which is reflected in FEM by having it in several places of the processes-assets structure. Another example, as was already mentioned in Sect. 4.2, asset value proposition as a statement of benefits for the customer can be used as an EXT in the product/service development process, and/or as EXT for the service delivery process.

• Reputation—is evidence that the attraction has been verified by experience, for example, by others who already are, or have been stakeholders of the given type. We mark this asset with a dashed border to differentiate it from other asset types. We refer to such assets as experience-based data on enterprise functioning. Reputation is not the only asset that is of the experience-based data type. Experience-based data, for example, could also be used as an asset for business process improvement, which in FEM terms is considered as a maintenance process for EXT (EXecution Template). In this case, the experience-based data is equivalent to process performance measurements.

An example of using the acquire stakeholders archetype is presented in the Sect. 6. We believe that it is possible to define other archetypes for supporting processes, but this task is beyond the scope of this paper.

4.7 Layout of the model

If we strictly follow the unfolding procedure from Sect. 4.5, we will get a layout where the arrows always point upwards, i.e., from assets to a process that uses them, or from the supporting processes to the assets they are aimed at managing. This type of layout is not mandatory; it is possible to draw an arrow that points downwards, for example, from the process to an asset it manages. Suppose we have a primary process that includes receiving payment for goods or services delivered. Besides considering it as a primary process that satisfies the beneficiary(ies), this process functions as a supporting process of acquiring monetary funds. The situation can be represented in two ways as shown in Fig. 10. On the left-hand side, all arrows point upwards; on the right-hand side, the arrow to the monetary fund points downwards. Which layout to choose depends on the model’s purpose and which one is easier to understand. For example, if monetary funds are the focus, then the left-hand layout is more suitable than the right-hand one. If the processes are the focus, then the right-hand layout could be more suitable.

Fig. 10

Different layouts for the same fragment of the model

Fig. 11

Two alternatives of layout for a multipurpose asset

We can mix upwards and downwards arrows even when defining archetypes. For example, we could add an additional monetary asset to the primary process archetype of Fig. 4, which would concern getting payment from a beneficiary. Note, however, that it is not mandatory that the payments are formally coming from each primary process. For example, the customer may pay for a service through subscriptions fee, which will be part of the customer management rather than the primary process of service delivery.

Another problem that arises when deciding on the layout is that the same element of a model, i.e., a process or asset, may be used in several places. This problem is illustrated in Fig. 11 where asset Office is used in two processes, one as an infrastructure that supports process p1, the other one—as an attraction for recruiting workforce. The meaning of the second usage is the office building being very modern and convenient, which may attract the potential candidates to accept a position in such an office. Figure 11 shows two alternative layouts for such a model. In the left-hand layout the office rectangle is connected to both processes. In the right-hand layout there are two rectangles that represent the office asset, but they are connected by a dotted double arrow that shows that these two rectangles represent the same asset. We consider the second alternative to be preferable, especially if the model development is supported by some computerized tool. In the latter case the dashed arrows can be shown on demand and not be present all the time.

4.8 FM meta-model

In this subsection, we summarize the material presented in Sect. 4 by drawing a simplified meta-model of FEM. The overall structure of FEM graphs can be represented by Fig. 12, in which nodes are represented by rectangles, relationships—by open arrows, labels on the relationships—by ovals. In addition elements of the graph can be specialized which is shown via arrows. Note that the diagram on Fig. 12 does not follow any standard notation for representing conceptual models, but can easily be converted, for example to an UML class diagram. Note also that the nodes of the FEM graphs are labeled, which is not represented in the meta-model as there are no constraints on choosing labels of the nodes.

Fig. 12

Meta-model of FEM graph

We do not present a meta-model of an archetype in a separate diagram, as it has the same structure as a FEM graph except that its nodes are not labeled. A node of a FEM graph satisfies an archetype if its neighborhood can be “obtained” by assigning labels to the nodes.¹¹ Archetypes can be arranged in a hierarchy through specialization, where specialization is done by extending a more general archetype. The hierarchy of the archetypes defined in this paper can be represented in the following way:

• Archetype

  • Generic process-assets archetype

    • Primary process-assets archetype

    • Acquiring stakeholders archetype

  • Asset-processes archetype

The notions introduced in this section can be formalized, but this task is beyond the scope of this paper.

5 Envisioned areas of usage for fractal enterprise models

Below, we list several practical areas where a model connecting all processes and assets in an enterprise and a procedure for building such a model could be useful. This list is not complete, and new areas can be added to it, some of which are discussed in Sect. 8. Also, the order in which the areas are listed is arbitrary and does not represent any kind of priority.

• 1. Producing a list of, if not all, then the majority of BPs existing in an organization. Such a list can be used, for example, for deciding which processes will be supported by a new software system. This usage was one of the practical motivations for the current research, as discussed in Sect. 1.1. Such a list could also be used as a basis for prioritizing the processes when planning organizational change. In the latter case, the relationships between the processes via assets could be of help, as prioritizing a process without paying attention to its connected processes may result in the failure of the project (see discussion below).

• 2. As help in strategic planning for finding out all branches of the processes-assets tree that require adjustments. For example, when sales plans a new campaign that will bring new customers, all assets required by the corresponding primary process should be adjusted to satisfy the larger number of customers. This includes workforce, suppliers, infrastructure, etc. The calculation itself can be done with one of the known methods, e.g., SD [33]. This issue has already been discussed in Sect. 1.1.

• 3. To prevent “organizational cancer”. The term has been introduced in [30], p 57, to describe a situation when a supporting process starts behaving as though it were a primary one disturbing the balance of the organizational structure. This is typical for IT departments that may start finding external “customers” for software developed for the internal needs. Placing each process on the FEM map will make the goal of each process explicit. Processes that have been identified as pure supporting processes should focus on internal needs and are not allowed to attract external customers, at least until the decision of converting them to primary processes has been taken (see the next item in this list).

• 4. As help in radically changing the direction. When all supporting processes are mapped in a tree, it will be easier for the enterprise to change its business activity by picking up some supporting processes and converting them to primary ones, while making appropriate adjustments to the tree. For example, a product manufacturing company could decide to become an engineering company. Such a decision can be made when manufacturing becomes unprofitable, while the company still has a very strong engineering department. An example of such a transformation is described in [30], p. 74. Another example comes from the experience of the first author who worked for an US company that made such a transformation twice. The first transformation was from being a software consulting business to a software product vendor when the consulting business could not accommodate the existing workforce. The second transformation was the reverse of the first one; when a market for their line of products suddenly collapsed, the company went back to consultancy. The authors have a separate paper devoted to this issue [28], which presents the models of transformations above.

• 5. To help in designing supporting process via pointing out all places where a given asset is, or might be, used. As already discussed, many assets have multiple purposes, which require special consideration when designing processes to manage these assets. Missing some purposes may result in the asset management processes producing an asset that does not suit some of the purposes. The latter creates a risk that the enterprise as a whole will not function satisfactorily. In more detail, this topic is covered in the next section devoted to testing FEM.

6 Testing FEM: building a fractal enterprise model for university teaching

To test whether a FEM can be built and be useful, we completed a small scale project of building a FEM for the department of the Computer and Systems Sciences of Stockholm University in which all authors worked at that time. The research goals of the project were: (1) to test whether such a model can be built with relatively few resources, and (2) whether it would be considered useful by the people who work in the organization, including managers and teachers. Both goals are connected to the problem of creating an effective procedure discussed in Sect. 1.1. The first goal is related to efficiency, the second one—to the quality of results. When testing usefulness, we concentrated on area 5 from the previous section (dual use of assets and their supporting processes).

In the subsequent sections we give the details of the project, discuss the resulting FEM, and the opinions on its usability from the potential stakeholders.

Fig. 13

The root fragment from which we started unfolding FEM

6.1 Project context

The context of the project was as follows:

• Organization. The project was completed in the department of Computer and Systems Sciences (DSV). DSV belongs to the Faculty of Social Sciences at Stockholm University (SU) and carries out all types of academic activities, i.e., undergraduate and postgraduate teaching with about 5700 students, and research. It runs bachelor, master, and doctoral programs in the fields of Computer Science and Information Systems. It has about 280 staff members including teachers/researchers and administrative personnel. The primary business of DSV is teaching and research. The focus of this study was on teaching as a core business performed in the department. Thus we started from teaching and learning as a primary business process which aggregated all processes linked to delivering knowledge to students. They included teaching, examining and graduation. In the project, we also investigated other business processes that are vital for the successful execution of the primary business process.

• Team. The project involved two professional groups: business domain experts and enterprise modeling experts. The group business domain experts included senior staff from both teaching and administrative units, such as the director of studies, director of finance and administration, head of one academic unit, IT director, and senior lecturers, some of them coordinators of several academic programs. The group enterprise modeling experts consisted of the authors of this paper.

• Tool. To build a model, we used a graphical tool called Insightmaker [25]. Insightmaker is designed to support building system dynamics and agent-based models and run simulations. We have chosen this tool because it supports the graphical shapes needed for FEM, and it has several additional features that we found useful, such as folders, ghosts and stories. The folders feature allows wrapping a part of the model and making it foldable/expandable. The ghosts feature allows creating an alias to a shape and using it instead of the shape in a different place; it also provides a simple way of finding the source for a ghost. The ghosts feature solves the layout problem for multipurpose assets and processes discussed in Sect. 4.7. The stories feature permits creating a scenario of unfolding the model in a stepwise way, which we found convenient for presenting a model to the domain experts.

6.2 Project execution

The project consisted of two phases:

• 1. Building a fractal enterprise model related to the educational activity of the department

• 2. Evaluation of the results

The model was built based on the procedure from Sect. 4.5 starting from the fragment in Fig. 13 that has Teaching & Learning process as a root; this fragment was drafted based on our own knowledge of the domain. When unfolding the processes-assets structure further, we used semi-structured interviews and document analysis. We interviewed nine business domain experts, starting with the director of studies who was the main senior person responsible for ensuring the successful execution of the teaching and learning process. Based on the initial interviews, the list of interviewees was extended to the operational staff by obtaining the names of people involved in supporting processes. Thus, the “unfolding” of the interviewees followed the same principle as unfolding the processes-assets structure.

Gathering input from the operational staff who perform the actual activities in various business processes, directly or indirectly related to teaching and learning, increased our understanding of the details of these processes. This understanding was complemented via document analysis. The list of documents for analysis was obtained by explicitly asking for relevant documents during the interviews. The interviews protocols and documents were then analyzed and used for building the FEM described in the next section.

The evaluation of the model was done by presenting the model to our business domain experts (both teachers and administrative staff), and conducting interviews with them. The model was presented to each domain expert individually using the stories feature of Insightmaker. The presentation consisted of demonstrating the model to an expert according to the unfolding procedure from Sect. 4.5. The story started with identifying the assets needed by the primary process, in this case teaching and learning, and then continued through the steps of identifying acquire, maintain and retire processes for individual assets. Upon finishing the demonstration with a domain expert, a semi-structured interview was conducted with him/her using an open-ended questionnaire to guide the interview. The results of these interviews are summarized in Sect. 6.4

6.3 FEM model for teaching and learning

The core part of the FEM model for teaching and learning is shown in Fig. 14. Actually, we worked with a more extended root, depicted in Fig. 13, but we present here only the activities more directly related to teaching and learning as such.¹² We omit financial consideration (e.g., payments received from the Swedish government), office and teaching facilities (rooms for teaching), partners, and some other parts of the model. However, we believe that the remaining part is sufficient to demonstrate the usefulness of the model with respect to the fifth area defined in Sect. 5—discovering and managing multi-purposed assets.

The model depicted in Fig. 13 has a high level of granularity. In it, the primary process teaching and learning represents everything related to teaching and learning, including students following a program from course to course, and teachers giving a course in a particular subject. The latter includes individual teaching and learning activities, like lectures, tutorials, workshops, laboratories, project assignments, and examinations. To successfully run the process of teaching and learning, the following assets are of primary importance: students, lectures, programs and instructional materials and e-learning platform. These need to be synchronized with each other so that the students’ level of preparedness and aspirations are in synch with the programs, and the teachers are able to successfully teach the programs using modern tools. Achieving such synchronization will result in positive experiences of the stakeholders participating in the process. The latter can serve as an asset for some of the supporting processes. In Fig. 14, we depict one such asset as the student’s general opinion on the educational process in the department (the rightmost asset attached to the primary process in Fig. 14). If needed, the teachers’ opinion could be introduced as well. In addition, the general opinion of students could be split into opinions on different issues—teachers, content of the programs and courses, and e-learning platform.

On the next levels of Fig. 14, we present some of the supporting processes aimed at managing the assets needed for teaching and learning. We are not listing all processes here, focusing only on the assets with multiple purposes. The latter are introduced in the Insightmaker diagram using ghosts. A ghost has the same label as the source asset or process, but has a lighter filling color, than the one used in the source shape.

Fig. 14

FEM for teaching and learning

6.4 Dual use of assets and supporting processes

As can be seen from Fig. 14, several assets are of multi-purpose type, for example:

• The e-learning platform’s main usage is in the teaching and learning process itself. However, it is also used in the process of instructional materials development which is an acquire process for another asset used in the primary process of teaching and learning. In addition, the e-learning platform can serve as an attraction to attract students to enroll in the department’s programs, which makes it an asset for the marketing process. The latter, in turn, is an acquire process for the asset students needed for the primary process.

• Assetprograms and instructional materials function as EXT (EXecution Template) for the primary process teaching and learning. At the same time it functions as an attraction of having attractive programs and high quality teaching materials in the marketing process, which, as already mentioned above, is an acquire process for asset students.

• The main usage of the asset lecturers is in the primary process teaching and learning. At the same time, the lecturers, more precisely their credentials, such as full professors or Nobel Laureates, can be used as an attraction in the marketing process.

Identifying the multi-purpose assets is of importance for designing business processes aimed at managing these assets. To highlight this importance, we use the ghost processes attached to the multipurpose assets. For example, in Fig. 14, the process develop and deploy e-learning platform is repeated three times. This stresses the fact that the platform should not only be adjusted to presenting the teaching materials to the students. It needs to be convenient for the teachers to plan the courses and develop these materials without using intermediaries, or any kind of coding. At the same time, the platform also needs to have a modern look and feel to be able to function as an attraction. Considering all three purposes simultaneously will set a number of conflicting requirements on the platform, and thus on the process of acquiring it (independently of whether the platform is to be internally developed or externally procured).

Currently, the e-learning platform employed in our department functions more or less satisfactorily in the process of teaching/learning. It is not sufficiently good for course development, and it is not good enough to be used for attracting students. This needs to be addressed in the processes of acquiring, maintaining and retiring of the e-learning platform.

In the model presented in Fig. 14, students are represented only as an asset for the teaching/learning process, though they undergo changes that, for example, make them more suitable as workforce for employment. This fact is not represented in the model due to it being developed for the university only; thus, the model does not include processes that lie outside the university. However, if a university has a policy of recruiting its staff from its own graduates, the teaching learning process can be also considered as a kind of acquire process for its workforce asset.

6.5 Evaluation of the model

As already mentioned in the beginning of Sect. 6, the research goal of the project was to answer the following two questions: (1) to test whether a FEM model can be built with relatively few resources, and (2) whether it would be considered useful by the people who work in the organization. In the subsections below, we present our answers on these two questions. Question 1 was answered based on our reflections after completing the project. The answer to question 2 was obtained by demonstrating the model to our domain experts and interviewing them immediately afterward according to the plan presented in Sect. 6.2.

6.5.1 Reflections from the project

Building a FEM model for the educational process in the department consisted of two main phases: investigation of sources and the actual building of a fractal enterprise model. Our reflections on these two phases are as follows:

• 1. Investigation of sources was the most difficult part. It was completed through interviews and document analysis. We interviewed nine business domain experts and each interview took approximately 1 h. The analysis of the interviews took an additional 24 h. The analysis of documents took approximately 20 h. The investigation and modeling phases were iterative. During the modeling we also performed some follow-up interviews for further clarification, which took at least 1 h. In total, interviews, analysis of the interviews and document analysis took approximately 80 h in a span of 2 months.

• 2. Applying the principles from Sect. 4 to build a model for education was relatively easy and straightforward compared to conducting interviews. This took approximately 40 h. The work was guided by archetypes previously developed in [14]. The major complications at this stage were when we needed to adapt the archetypes from [14]. Using Insightmaker as a modeling tool greatly facilitated our work. In particular, the ghost feature was of much help in avoiding intersections of the arrows. The ghost feature was also convenient for highlighting the presence of multipurpose assets when demonstrating the model to the domain experts. Another convenient feature when presenting the model to the domain experts was the storytelling.

On the whole, it was not particularly difficult to identify the major business processes and assets related to teaching and learning processes and present them in the model to provide a holistic view on business processes in the department. However, it was difficult to understand some of the processes and assets that could be of importance. One of the processes that we could not fully understand was the process for acquiring “alumni society.” Despite the fact that the department makes use of the alumni society as an asset for marketing, it was not clear how, by whom and when the asset is created and maintained in the department. This issue requires further investigations with business domain experts. Another part of the educational process that has not been captured in the model concerns finances. It is very specific for Sweden, and it is undergoing constant changes, which was one of the reasons we decided not to investigate this part in detail.

From our experience, building a FEM model as such does not require extensive resources. However, the initial effort of understanding, to a sufficient degree, how a particular enterprise operates may require both time and experience of communicating with domain experts.¹³ Once one understands sufficiently the operation of the enterprise in question, the actual application of the archetypes to build a FEM is relatively fast and straightforward.¹⁴

6.5.2 Feedback from the domain experts

The interviews with our nine business domain experts, which directly followed the presentation of FEM, showed that our model for educational activity was well understood and appreciated by them. More specifically, there was good consensus for the following questions:

• Whether it is important to make explicit all purposes of all processes in the department. The results showed that 100 % (5 experts agreed and 4 strongly agreed) of the business domain experts agreed that it was important to make explicit all purposes of all processes in the department.

• Whether the FEM model could be useful for explicating business processes and their interconnection. The results showed that 100 % agreed that the FEM model was useful for explicating processes and their associated purposes.

• Whether a visual diagram that shows how all processes in the department are interconnected could be useful for business planning and development. The results showed that eight experts agreed (5 agreed and 3 strongly agreed) that a visual diagram that showed all processes in the department and their interconnection would be useful for business planning and development; one expert was not sure. When asked why he was not sure, the expert said he could only be sure after applying the diagram to practical business development.

• Whether a visual diagram in the form of FEM could be useful for business planning and development. The results showed that 8 experts agreed (5 agreed, 3 strongly agreed) that the presented way of depicting business process interconnections was useful for business planning and development; again, one expert was not sure. Similarly, when asked why he was not sure, the expert said he would be sure after applying the diagram in practice.

As multipurposeness of the assets and processes was the focus of our test, we also asked the experts (informally) whether they knew about the cases of multipurposeness of assets/processes presented in our FEM. Most of them knew about these cases, which came as no surprise as the model was built based on the information they provided. However, all of them agreed that having these facts in an explicit graphical form offered several benefits. In our view, the fact that the information revealed by the model already existed in the tacit form does not diminish the value of the model. Actually, one of the aims of enterprise modeling is to gather tacit knowledge spread all across the organization and present it in an explicit form understandable for all stakeholders. It looks like the experts we interviewed agreed with this view.

7 Comparison with other business process architectures

A FEM model only includes resource-based relationships between processes. In contrast, most process architectures include additional relationships, such as trigger, flow, specialization and composition relationships, as defined by Dijkman et al. [18]. A FEM model can, thus, be viewed as a partial process architecture that includes all (or the major part of) the processes in an organization but can be complemented with additional process relationships.

In this section, FEM is compared and contrasted with a number of other business process architectures. The comparison is based on three orthogonal dimensions of model dependency, process relationship type, and domain dependency, which are explained below.

Several business process architectures require an existing model on which the architecture can be based, i.e., they are model dependent. Examples of these are goal-based architectures [18], such as Antón et al. [5]. Koubarakis and Plexousakis [36], and Lee [41]; they all require an existing goal model to which the processes can be related. Other examples are function-based architectures [18] that build on a model of a function hierarchy, e.g., [1, 60]. FEM, in contrast, is not model dependent, as having a model on which FEM is based is not required.

The types of process relationships that may associate processes vary between business process architectures. Generalization and composition relationships occur in several architectures, e.g., the MIT Process Handbook [44]. Another relationship is that of triggering, which specifies that one process may trigger the execution of another process; this relationship is common in action-based architectures [18], e.g., [7, 34]. FEM is based on indirect relationships between processes mediated by objects according to the proposed archetypes. In this sense, FEM is close to object-based business process architectures [18], but while these can include any kinds of objects, FEM is solely concerned with assets. Therefore, we can consider FEM as belonging to the class of object-based business process architectures.

Most business process architectures are domain independent in the sense that they are not restricted to any particular industry branch, such as car manufacturing or health care. However, there are architectures that include domain-specific processes, e.g., the MIT Process Handbook. FEM is domain independent.

The relationships between processes in FEM can be expressed in different architecture languages. In this paper, we have not pursued this issue and only used an informal diagramming technique. However, an interesting direction for further work would be to investigate how an enterprise architecture language, such as ArchiMate [40] that offers a broad range of process associations, can be used for expressing these relationships.

Finally, to the best of our knowledge, there does not exist much work on procedures identifying processes and their relationships. In the works that exist, e.g., [19] mentioned in Sect. 2.1, the main efforts are aimed at designing a well-organized process architecture, while FEM primarily aims at analyzing an organization and discovering its existing processes, documented as well as undocumented ones.

8 Open issues

In this section, we identify and discuss open issues related to FEM and the unfolding procedure that can serve as a basis for planning future research.

8.1 Limited validation

The case presented in Sect. 6 constitutes only a limited validation of FEM and the methodological support for building FEM. The limitations concern several perspectives, e.g., only one case has been investigated and only in relation to one area of the envisaged usage (area 5 from the list in Sect. 5—multipurposeness of assets). We continue working on validation trying to investigate more cases and in relation to other areas from the list in Sect. 5. In relation to area 2 (strategic change of direction), we have investigated how FEM can help in changing a business model as a reaction to a problem or new opportunity in the market. During this investigation [28], we analyzed one case of business model transformation and built high-level FEM models for an organization before and after the transformation. We consider the example as generalizable to a transformation model where a primary process becomes a supporting process. We continue working in this direction looking for other patterns of business model transformations.

In another study, we used the ideas from FEM to solve a practical task that lies outside the areas listed in Sect. 5. The task consisted of systematizing process documentation (e.g., process maps) obtained from multiple BPM projects in an ad hoc manner. A simplified FEM was built to arrange the documents related to the primary and supporting processes identified during the investigation [35].

8.2 Limitations of the methodology support

The methodological support for building FEMs presented in this paper is limited to a general procedure described in Sect. 4.5 (unfolding procedure) and a number of archetypes that could be used in this procedure. Currently, it does not include a set of rules for how to produce an instantiation starting at a certain node of an already built fragment. The archetypes themselves show “what to look for” but not “how to do it”. Whether it is possible to extend the methodological support for the procedure is an open question. Most probably, some heuristic guidelines can be produced to cover the limitation at a later stage. As far as the set of archetypes is concerned, we believe that it can be extended through specialization; this is one issue that we plan to investigate in future research.

For now, the limitation above sets some constraints on who can use our solution. We believe that what is already developed could be sufficient for an experienced business analyst, but not for a novice. Note that FEM with the unfolding procedure is not unique in this respect. Many known techniques for enterprise modeling are born in this way, including the popular business model canvas [50].

8.3 Dissemination and adoption

Design science research cannot on its own generate enough test cases for statistical validation of an artefact/solution. This can only be done by the industry adopting the solution. The latter requires dissemination of results among practitioners and devising a strategy to this end. Such a strategy should identify a group of specialists to target, and channels through which to transfer information about the new solution.

According to the classical works on the adoption and diffusion of innovations [54], successful adoption requires reaching a critical mass of adopters. To ensure that a critical mass is reached in the most effective way, efforts need to be concentrated where the negative feedback can be minimized, and the positive feedback maximized, which should be observed when defining the targeted group. A natural group for adopting our solution is management consultants. However, traditional management consultants use well-known methods and might not be interested in anything new and non-traditional. Promoting our solution among them has a risk of being rejected and receiving negative feedback. Therefore, a more promising group to target is management consultants already using non-traditional methods, especially those that are based on systems theory, like casual loops diagrams, stock and flow diagrams and VSM (viable systems model), as these methods and our FEM have the same roots.

As the target group is small relative to all management consultants, and is spread all over the world, an appropriate channel to reach them without spending too many resources is via social media, using virtual groups that unite enthusiasts of non-traditional methods. Therefore we use a LinkedIn group related to non-traditional methods, for example, Systems Thinking World [10] that has over 20,000 members and Viable System Model [51] that has over 800 members. Dissemination consists of (1) participating in the group discussions, (2) publishing information about our research papers and slides of presentation so that they are available to the group members, (3) referring to these materials in the discussions and private communications where appropriate.

So far, our efforts have produced some results of which we are aware. For example, our ideas as published in [14] were presented to the members of SCiO (Systems and Cybernetics in Organizations) society [61] at one of their development days, in connection to which a kind of extended conceptual map of the FEM model has been created [38]. We plan to continue our dissemination efforts through social media using already established channels and finding new ones.

8.4 “Reversed” archetypes

As defined now, the unfolding procedure allows moving only in one direction, i.e., from a process to its assets and then to the processes that support these assets. This constitutes no hindrance if we start from the top, i.e., one of the primary processes. However, if the process or an asset of interest is in the middle of the tree and we want to know all assets/processes around it without starting from the top, the unfolding procedure will be insufficient. The question arises whether it is possible to define archetypes that allow moving in the opposite direction, i.e., from an asset to all processes that use it, or from a process to all assets it supports. Such archetypes cannot be obtained by “reversing” the currently defined ones, thus a special investigation should be made to define them. This investigation lies in our nearest plans for the future. Currently, it is not clear how many reverse archetypes can be defined, though their existence can be demonstrated with the following example. Consider an asset A used as an execution template (e.g., a process diagram) for a business process P, which means that A “hangs” on EXT relationship between P and A. Then it is possible that this asset can be used in at least two other places of the FEM model:

• As educational material for training personnel (to be) engaged in process P, thus functioning as an asset to the process of acquiring/maintaining a workforce for this process;

• As design specification for building a software system to support process P, thus functioning as an asset for the process of acquiring/maintaining infrastructure for this process.

8.5 Formalization

In this paper, FEM is defined and discussed on the conceptual level and in an informal way. This is sufficient for the goal of testing the usefulness of the new modeling language. As it seems that FEMs might be useful for practice, formalizing FEM becomes an important topic on the research agenda. Formalization can be done according to the following scheme. FEM is defined as a directed graph with two types of nodes, processes and assets, where nodes of one type are connected to the nodes of another type with a number of relationships. For such a graph to be considered as a valid FEM, a neighborhood of each node should satisfy a number of constraints in the form of patterns that correspond to our archetypes. Though the task of formalization is beyond the scope of this paper, Sect. 4.8 makes the first step in this direction presenting a draft of a FEM meta-model.

8.6 Using FEM for achieving viability/adaptability

As discussed in Sect. 2.3, a fractal organization as defined by [30] can be considered as a tool for achieving viability/adaptability in the dynamic environment of today. Though the motivation for designing FEM was different, we believe that when built, it can be used for the same purpose. Various processes discovered with the unfolding procedure are connected to different parts of the external and/or internal environment of the enterprise. If participants of these processes are entrusted to watch and report on changes in their parts of the environment, it could create a set of effective sensors in the sense of [11] covering all aspects of the enterprise environment. Connecting these sensors to firing adaptation processes will close the “adaptation loop”. As an example of the above, assume that the recruiting process shows that it becomes difficult to recruit skilled workforce for a primary process. This can prompt an investigative process to find out the reason for these difficulties. It could be that nobody is willing to learn such skills any more, or the competitors are expanding and offer better conditions (e.g., salary), or the enterprise reputation as a good place of work has been shattered. Based on the result of the investigation, appropriate changes can be made in HR processes themselves or in completely different parts of the enterprise.¹⁵

8.7 Strengths and limitations of FEM in discovering processes

As discussed in Sect. 1.1, one of the motivations for developing FEM and the unfolding procedure was a problem of identifying all processes in an organization, and their relationships, in an effective way. The resulting procedure is aimed at finding the processes connected to the primary ones via assets. The effectiveness of using the procedure, naturally, depends on the experience of a business analyst who uses it. An experienced business analyst might be able to find a large number of processes using this procedure including the ones that can be found by other methods. This especially concerns supporting processes defined in [53] that could be found by listing all assets and then looking for supporting processes for each of the assets. Using the unfolding procedure can also help to discover processes connected through the value chain [53]. For example, if process $P_{1}$ produces parts A to be used in process $P_{2}$ and there is a stock where these parts are stored, then a connection between these two processes can be established as $P_{2 }$uses A as an asset of type stock, and $P_{1}$ functions as an acquire process for this asset.

However, as any other method of discovering processes and connections between them, the unfolding procedure has its own limitations. For example, it does not help in finding:

• Primary processes

• Subprocesses of a given process. For example, if process $P_{1}$ produces parts that are used directly in process $P_{2}$ without going to a stock, then the connection between these processes cannot be discovered through the unfolding procedure

• Adaptation processes discussed in the previous subsection. These might be better to discover following a VSM view on an organization [9].

Another kind of relationship that FEM does not represent is relationships between EXTs of the generalization–specialization type, especially if they are presented in the form of process models. However, it might be possible to include such relationship indirectly via a generalized EXT (process model) serving as an asset for acquiring and maintaining a specialized EXT.

The limitations as above means that for some practical tasks there may be a need to use several frameworks, which brings forward a question of tying FEM with other frameworks. An interesting approach toward such integration is presented in the conceptual model by [38].

9 Concluding remarks

Patrick Hoverstadt in his paper “Why Business should take Enterprise Architecture seriously” [31] highlights “the need for an architectural model that provides business leaders with a model of the enterprise that they can genuinely use to understand how it operates”. Until this happens, the Enterprise Architecture field will not be taken by business leaders as seriously as it should. The most popular model notations, be it from the field of Enterprise Architecture or Business Process Management, so far, have not been able to satisfy this need. Patrick Hoverstadt’s own suggestion, tested in his management consulting practice, is a model based on Stafford Beer’s Viable System Model (VSM). We believe that the fractal enterprise model suggested in this paper could also satisfy the need identified by Patrick Hoverstadt, at least partially.

The main arguments for the potential usefulness of FEM for business development is its relative simplicity combined with a sufficient expressive power to present interconnections between different components of the enterprise architecture, i.e., business processes and assets. The model shows dependencies between the components on the same and different levels, while it also identifies the usage of each component in several places of the enterprise architecture. All this creates a holistic view of the enterprise functioning. An additional advantage of FEM is a possibility of building a model with the requested granularity so that the modeling technique can be used for both strategy and operational business development. Also, there is no requirement to have the full model before it can be used. It is possible to start at any place of interest and unfold the fractal structure down and/or up from this place. According to the test reported in Sect. 6, domain experts have no problem in understanding FEM and its potential advantages. They also believe that FEM could be useful for business development.

Summing up our experience, the FEM appears to have good potential, but there is a need for more testing and further development of the model and the unfolding procedure as discussed in the previous section. There is also a need to have a graphical tool dedicated to building fractal enterprise models. Though Insightmaker proved to be satisfactory for limited testing, it is a tool developed for a completely different purpose, and thus it cannot be fully adjusted for FEM.