**1. Introduction**

Since the 1970s, enterprise modelling has developed into an effective methodological source for improving business performance. Some of the proposed approaches simply provide a modelling language but others also present an implementation method. It appears that these methods adopt a classic project approach that leads to long and costly projects. Moreover, in the context of a rapidly changing economic environment, these approaches lack responsiveness. Faced with this, continuous improvement is pushing towards shorter projects that come from the field and are part of a permanent movement of evolution.

With this perspective in mind, the objective of this chapter is to show how enterprise modelling can be encapsulated in a continuous evolution approach of a strategic nature, the ultimate goal being to take advantage of the expressiveness and systemic approach of enterprise modelling while being part of a fluid and reactive evolution context.

The outline of this chapter is as follows. Section 2 will present the problem statement by insisting on the inadequacy of project-based approaches in a context of a changing environment. Section 3 gives elements of conceptualisation, on the one hand, on the evolving system itself and, on the other hand, on the system for

managing this evolution. Section 4 will present the evolution management system in detail. Section 5 will give the main elements that argue in favour of such an approach. Section 6 will conclude the chapter.

#### **2. Problem statement**

Over the last few decades, enterprise modelling has provided a methodological set of tools for engineering and, more often, re-engineering organisations. Little by little, this scientific field has emerged as an effective methodological source for improving business performance [1–3]. Developments took place in several stages [4, 5]. After having proposed many modelling languages in the 70s and 80s, this field then sought to make these languages work together to obtain integrated methods (such as CIMOSA or GIM) with a large modelling coverage in order to approach companies in the most systemic way possible [6–8]. This work made it possible to define fairly stable modelling domains, often identified as views or points of view: informational view, process view, decisional view, etc. The next step consisted in organising all this input by analysing on the one hand the components of these methods and their organisation (GERAM) [9, 10] and on the other hand on the nature of the concepts handled. This last point was based on approaches such as meta-modelling and ontologies and had as a practical field of application the translation of inter-language models and the development of a Unified Enterprise Modelling Language (UEML) [11–13]. From a theoretical point of view, this point allowed the identification of the major concepts to be retained in enterprise modelling as well as the way to formalise and express them. Finally, it must be stressed that enterprise modelling corresponds well to current trends that advocate the use of models in engineering such as Model-Driven Architecture (MDA) [14, 15] in software engineering or all the approaches referenced under the term Model-Based Systems Engineering (MBSE) [16].

Applications of enterprise modelling methods show that they lend themselves well to project-based approaches. Project management in companies has grasped big attention since many decades to provide new insights to the practitioners. Early investigation through case studies in [17] provides a cross analysis between project management and the interest of Lean thinking. A key element in combining lean approach to project is "Planning and control by objectives" with fixed and accepted key dates. Then, the commitment and motivation from the team was quoted as leading to successful final project. This link requires precise organisation and timing, time and resources. A complete project of this type takes place over several months and can take up to one year.

It is emphasised in [18] that the efficient resources management is becoming a major challenge in the current context of volatility, uncertainty, complexity and ambiguity. In order to efficiently manage its resources, companies need to manage and deliver projects on time, on budget, inside the scope and in accordance with the quality requirements agreed with the customer. We are therefore faced with the two classic problems of this type of approach.

The first problem concerns the evolution of the environment, and therefore of the specifications, during the project. Like any project, a reengineering project using enterprise modelling is based on initial specifications and objectives. Even if it is possible to make these evolve during the project, it is more comfortable and efficient to ensure that they remain fixed for the duration of the project. In the end, a project-based approach is easier to implement in a stable context ensuring that the specifications do not change significantly during the project.

The second problem concerns the necessary breaks between projects. These are necessary for several reasons. Firstly, a re-engineering project is sufficiently intrusive

#### *Model-Based Enterprise Continuous Improvement DOI: http://dx.doi.org/10.5772/intechopen.96856*

and impacting that the system under consideration needs to "rest" between projects i.e., to return to a nominal regime during which the project results will be integrated into the day-to-day running of the company. Secondly, as this type of project requires a financial and time investment, this effort cannot last indefinitely. The break thus enables the company to reconstitute its resources before considering another project. Generally speaking, it can be envisaged that the return on investment must be sufficient before considering another project. In the end, since the break is necessary, the project will be all the more profitable if requirements do not change too quickly during the break. This brings back to the necessary stability of the environment.

In conclusion, the major problem is the stability of the environment. The project approach is difficult to apply in a turbulent context. **Figure 1** summarises these points.

The answer to this problem is therefore to reduce these two durations: project duration and the duration of break between projects. The solution is to move towards less ambitious and more targeted projects, even if it means multiplying them. A less ambitious project can be carried out more quickly. Because it is shorter, there is less risk of a gap between specifications and results. A less ambitious project also requires fewer resources, which makes it easier to make it profitable. Finally, a less ambitious project has less impact on the entire structure, which makes it easier to integrate the results in nominal mode. These last two points thus limit the need for break between projects. **Figure 2** shows how shorter but more numerous projects, with shorter breaks between projects, can make it easier to meet the company's expectations.

This orientation leads to a more continuous evolution of the system. Therefore, we are approaching methods referred to as continuous improvement. In [19] it is reminded that project management model suggests to systematically "address the actions and solutions to be implemented in order to keep, in the long run, the continuous improvement of the project management processes in the organization".

#### **Figure 1.**

*The problems issued from a project-based approach in a turbulent environment.*

The DMAIC (define, measure, analyse, improve, control) is also sustained as being a cycle for conjoint continuous improvement framework [20]. The DMAIC methodology is seen as last generation of improvement approaches, adding concepts, methods, tools and removing limitations identified [21]. The model based on DMAIC allowed identifying company's main project management problems and associated causes and the selection of the causes to be first addressed [19]. It is closely linked to PDCA approach evoked further.

This field, which has a very strong intersection with Lean management [22, 23], proposes a philosophy and a set of methods that provide tools for improvement actions. The Lean thinking is a way of focusing on value from customer point of view and making people contributing to the improvement to ensure the quality at the source. When the actions carried out with Lean practices such as Value Stream Mapping, Kaizen, A3 approach are examined, it effectively shows that they are less ambitious and more focused on a specific problem. Starting from problems in the field and involving various company members, they generally focus on the physical system (in the industrial case) or, more generally, on the value-added process to get as much exhaustive vision of the flow as possible and to analyse operational dysfunctions. The analyses of the added value activities should and must be at the heart of the focus that leads to less interest in infrastructural items such as the information system.

In addition, they offer more problem-solving tools than enterprise modelling. Conversely, this results in a weaker systemic vision than with enterprise modelling (how do all these actions fit into a coherent whole?). Similarly, it presents very few representation tools unlike enterprise modelling. Only Value Stream Mapping (VSM) can be considered as a modelling language. As quoted in [24], VSM is a powerful tool of representation found as being able to eliminate Muda, bottlenecks across production line. The value stream mapping uses current state map to record current state of production line before implementation of improvements. Indeed, the VSM contains a specific pictograms code to represent steps of the flow along the considered scope (from suppliers to customers) with different technical data at each activity represented. The information and physical flows are modelled to visualise the flow progression and detect "bottleneck resources" that deserves attention and corrective actions. By the way, VSM modelling is also significantly interesting tool to perceive the durations of the added value actions and the waste undergone in the different steps because of storages, quality rate and processing times. VSM was efficiently proved to be interesting in the modelling production flow of an aeronautic company to improve the productivity and deliveries costs dropped by 50% [25].

Generally speaking, what most characterises continuous improvement is the continuous aspect of the actions carried out, as the name suggests. Here, there is no project with a beginning and an end, but a continuous improvement process, conceptualised in particular by the Plan-Do-Check-Act cycle (PDCA) which is a control framework for executing a series of activities for continuous improvement of processes, originally developed in the field of manufacturing [26].

Finally, the approach presented in this chapter aims to move towards an approach of continuous evolution of the system under consideration, while retaining the advantages of modelling as proposed by enterprise modelling. To avoid confusion with continuous improvement, the approach is referred to here as evolution management.

#### **3. Conceptualisation**

Several aspects concerning conceptualization are presented in this part. Firstly, the notion of evolution trajectory makes it possible to implement the conclusions of the previous part. Then, several levels of management are proposed to manage the evolution trajectory of the system. Finally, several ways of formalising the system are presented [27–29].
