**Figure 7** represents these activities.

We are here in the typical enterprise modelling context: an instance of the migration plan corresponds to an enterprise modelling project. Obviously, the objective here being to converge towards a continuous evolution, the migration between the existing state and the first step will thus correspond to a less ambitious evolution than what classically constitutes the perimeter of a project. Nevertheless, the principle remains the same. To illustrate this, **Figure 8** presents the general principle of conceptualisation followed by enterprise modelling [30], also known as the *"sun curve"* in information systems design (1. *modelling*: passage from the reality of the existing state to its model, 2. *analysis and design*: passage from the model of the

**Figure 7.** *The activities of the migration plan level.*

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

**Figure 8.**

*The general principle of conceptualisation of enterprise modelling.*

existing state to the model of the future one and, 3. *implementation*: passage from the model of the future state to the new reality). It is easy to see the analogy with what is proposed in the migration plan.

This principle also explains why the sequence followed by this level is opposite to that of the strategic orientation level. In this one, the first step concerned the formalisation of the target, with the existing state being dealt with afterwards. This sequence makes it possible to link all this level to the strategic analysis of the company. Within the framework of the migration plan level, the existing state is processed (modelled) first. This enables the model of the first step to be developed on its representation in terms of performance from the previous level (**Figure 7**) but also from the analysis carried out on the basis of the models of the existing state (first action: current state modelling).

#### **4.3 The projects portfolio level**

As for the previous level, the two time milestones structuring this level are the current state and the first step. The difference with the previous level is that here the two milestones are expressed in the form of projects. The change of modes of expression reflects the desire to move from a static vision (the models represent the states of the system) to a dynamic vision (the actions that need to be taken to move from one state to another). That is why the projects portfolio is called "To-do" **Figure 9**, in comparison with the "To-be" of the upper level.

Moving from a model to a list of projects is not an obvious task. This is why the last activity of the migration plan was to propose an action plan. Then, this action plan is the link between the models and the projects. However, the action plan was mainly aimed at analysing what the envisaged migration entails. That is why it was not very precise in terms of timing or resources mobilised. The project portfolio level must fill this gap in the sense that all the elements that make up a real project must now be defined.

The three main activities that must be carried out within this level are as follows.

1.*Current state evaluation*. The objective of this activity is to analyse the progress and results of recent projects i.e., those belonging to the previous version of the projects portfolio. This analysis has a double purpose. Firstly, it is to verify that the projects that have just been carried out have achieved their objectives. If this is not the case, corrective or compensatory actions in the form of projects

**Figure 9.**

*The activities of the projects portfolio level.*

will have to be integrated into the new projects portfolio. This assessment reflects the fact that two successive instances of the projects portfolio are not independent. It also corresponds to some extent to the Check and Act phases of the PDCA. The second reason for this evaluation is the fact that some projects may not have been carried out within the tactical horizon of the previous project portfolio, contrary to what should have been the case. This may be due either to a decision to run a project beyond this horizon, or to the fact that a project has been postponed for various reasons. In the end, this activity makes it possible to know perfectly the state of progress decided the previous time and to take this state into account for the definition of the new projects portfolio.

	- Drawing up specifications: definition of technical specifications in relation to the models provided by the Migration plan.
	- Design or acquisition: development or purchase on the market of the solutions identified during the previous phase.

• Implementation and integration of the components developed or purchased.

The main elements to be taken into account are also standard: positioning of projects over time, conditions of precedence between projects, organisation of the company's internal resources, and triggering the involvement of external resources.

The horizon of this management is variable since it corresponds to the duration of the project concerned. It falls between two time milestones corresponding to the beginning of the project and its end. All these milestones constitute a sequence of events that set the pace of the projects portfolio's evolution (**Figure 9**).

It is important to find the best compromise between independence in the management of each project and overall coordination within the projects portfolio.

**Figure 9** shows these activities.

Finally, this level deals with project management with classical constraints and concepts. The important point is the existence of several concurrent and coordinated projects.
