**3.2 Management levels**

On the basis of the trajectory of the system as we have just defined it, several levels of management can be envisaged.

The first one corresponds to the control of the path between the current state and the target. The target is a state envisaged at long term, based on the analysis of the environment and the company's major orientations with a significant degree of uncertainty. The concept of target is close to other concepts such as vision, mission or values which are the core elements of a strategic organisational foundation [19]. Therefore, it corresponds to a strategic level.

**Figure 3.** *Evolution trajectories of the system and the target.*

#### *Lean Manufacturing*

As much as the target is considered to be generally unreachable, step 1 must be reached (there is no questioning planned before step 1). The management of the evolution between the current state and step 1 must therefore make it possible to precisely define the state of the system at step 1. This level is therefore considered tactical.

The level that has just been presented makes it possible to define towards which state the system must evolve, but it does not manage the actions to be implemented to do so. Therefore, a third level, concerned by concrete action, is necessary. This level is operational.

**Figure 4** shows these three levels and the processes that they manage. Considering the role that they play in the approach, the current state is called *As-is*, the first step *To-be* and the target *Could-be*.

#### **3.3 Formalisation modes**

The states identified by the approach can be formalised in different ways. Three forms are envisaged: performance, model and project.

*Performance*. A system can only be seen as a source of performance. Once the set of performances of interest to the company has been defined, the system and its evolution will be characterised through these performances. The state of the system can therefore be considered to change each time a performance changes in value. Thus, the state of the system is characterised by the value of its performance vector. The evolution then becomes a trajectory in a performance space, the significant points of this evolution being the states of interest. The performance can be observed in the case of an existing system or targeted in the case of a future system. **Figure 5** illustrates this approach.

*Model*. The most classic way to represent a system is to make a model of it. The notion of model is very broad and the definition of this term changes according to the domains. In engineering, a model represents the structure or behaviour of a system and is intended either to understand and evaluate the system when it exists

**Figure 5.** *The performance-based characterisation.*

**Figure 4.**

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

or to characterise it in order to design it. A model is based on a language. It can be formal, semi-formal or informal. A formal language is based on a mathematical formulation, whether continuous (system of differential equations for example) or logical (discrete event systems for example). At the other end of the spectrum (informal models), we can find models that are only drawings. A shop layout is an example of this. In between are semi-formal languages i.e., languages that have syntax and lead to less interpretation than natural languages but are not executable. This is the domain of enterprise modelling. The latter proposes a set of approaches and graphical languages that allow the system to be observed from several points of view. These languages include the IDEF suite, the business process modelling languages (BPMN, ...), the GRAI method, CIMOSA, etc. The aim here is not to define the language to be used, this depends on the objectives of the company and its culture. Finally, we should not forget simulation, which is quite similar to enterprise modelling but which proposes executable models.

*Project*. A final way of understanding the system is through the projects it undergoes. This way, less classical than the two previous ones, insists on the fact that an evolving system is the object of projects that act on it and that, therefore, the evolution of the system is characterised by the projects that allow it. Within this framework, future projects can be envisaged to support a targeted evolution and current projects can be analysed to understand the evolution in progress. Finally, looking at the projects means observing the evolution of the system in an operational way.

The three approaches are complementary. Seeing the system through its performances consists in considering it as a black box and in valuing the exchanges it implements. The model approach allows on the one hand to open the black box to observe the structure and, on the other hand, to observe the dynamics of the system (synchrony). Finally, the vision by project focuses on a diachronic approach by analysing the actions that lead the system to evolve.

#### **4. The evolution management system**

The general architecture of the evolution management system is based on the elements of conceptualisation presented by the previous chapter. It is structured on three levels.

The first level, entitled "*Strategic orientation*", is intended to propose a path leading from the current state (as-is) to the target (could-be) over the strategic horizon. This path is made up of regular steps. The strategic orientation level is expressed in terms of performances for two reasons. Firstly, given its nature, it makes it easier to link it to the strategy of the company. Secondly, because the target and all the steps following the first one will not be reached a priori, it saves an unnecessary effort of formalisation. The result of this level is a level of performances for each step.

The second level is called "*Migration plan*". Its objective is to express the path from the current state (as-is) to the first step (to-be) over the tactical horizon (that is equal to the strategic period – **Figure 3**). Knowing that this step must be reached, a modelling action deserves to be carried out. Therefore, this level works on the basis of models. This level leads to the definition of the models of the first step and of the set of actions to be implemented to reach it.

The third level is called "*Projects portfolio*". On the basis of the migration plan defined at the level above, the objective of this level is to define the projects operationally and to ensure the management of the entire projects' portfolio (over the tactical horizon) and all projects individually (over the project duration).

**Table 1** shows the overall picture.


#### **Table 1.**

*Architecture and principles of the evolution management system.*
