Model-Based Enterprise Continuous Improvement

Abstract

The enterprise reengineering based on enterprise modelling is usually carried out within the framework of conventional projects. This leads to relatively long projects that are not compatible with a highly variable economic environment. The objective of the evolution management presented here is to use enterprise modelling and all the benefits it brings in a framework that allows for more continuous improvement than is generally observed. The proposed architecture is made up of three levels: a strategic level based on performance measurement, a tactical level that manages system migration and is based on enterprise models, and an operational level consisting of managing a portfolio of evolution projects. Together, these allow a shorter set of projects to be carried out, while remaining coherent and aligned with the company’s strategy. This approach puts enterprise modelling methods and continuous improvement/Lean management approaches into perspective, allowing complementarities and opening up interesting perspectives concerning enterprise re-engineering methods.

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, 2, 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, 7, 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, 12, 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 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.

Figure 1.

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

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.

Figure 2.

Getting closer to the needs through shorter, more numerous projects and with less break between projects.

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”. 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, 28, 29].

3.1 Evolution trajectories

The general principle is then to make the evolution of the system a process as continuous as possible. Practically, the evolution process is made up of a sequence of steps representing the evolution of the state of the system. The closer in time these steps are, the more continuous the evolution of the system will be. Two steps are specific. The first one corresponds to the state of the system at the time it is examined (t = 0). This step therefore corresponds to the current state. The second represents the state in which we would like the system to be in the future, at a time sufficiently far in the future but for which it is possible to make viable predictions about the system’s environment. We refer to this step as the target and the moment at which it corresponds as the strategic horizon. The path between the current state and the target is punctuated by intermediate states that we call steps. These steps are the moments when the environment is reassessed and the target is redefined. If the environment has not changed, the target remains the same. This is equivalent to saying that the target is the desired state in the future, assuming the environment has not changed. However, we will consider that this is not the general case. Therefore, at each step, a new target is defined. The duration between two steps is usually fixed, we call this duration strategic period. It is clear that, because the steps are intended to be moments of redefinition of the target, the strategic period will be all the shorter as the environment changes rapidly.

Figure 3 summarises these concepts.

Figure 3.

Evolution trajectories of the system and the target.

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.

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.

Figure 4.

The management levels.

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.

Figure 5.

The performance-based characterisation.

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 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.

Name of the level	Nature	Expression mode	Initial state	Final state	Horizon
Strategic orientation	Strategic	Performance	Current state (As-is)	Target (Could-be)	Strategic horizon
Migration plan	Tactical	Model	Current state (As-is)	First step (To-be)	Tactical horizon (Strategic period)
Projects portfolio	Operational	Project	Current state (As-is) / Project start	Portfolio completion / Project end	Tactical horizon / Project duration (Operational horizon)

Table 1.

Architecture and principles of the evolution management system.

4.1 The strategic orientation level

As already explained (Table 1), there is several time milestones organising this level. Upstream, there is the existing state, corresponding to the system as it is now (as-is). Downstream, there is the target that is the representation of the system as we would like it to be at the strategic horizon, assuming that no significant element of the environment would change between now and then (could-be). The target is therefore positioned at the furthest point in the future at which it is possible to make assumptions about the system. In between, steps are distributed at regular intervals (strategic period). In theory, the number of steps is equal to the strategic horizon divided by the strategic period. The steps correspond to the moments when the trajectory to be followed is questioned.

All these milestones express the system in terms of performances. As explained above, that means that the system is positioned in a performances space.

The three main activities implemented at this level are as follows.

1. Target definition. This consists in translating the “key success factors” provided by the company’s strategy into a valued technical performances vector. The nature of these performances is decided by the company itself. There is a double condition about these performances: in one hand, to be valuable on the basis of key success factors and, in another hand, to be operational enough to support the definition of change about the system.

2. Current state evaluation. This action consists of evaluating the existing situation in the same performance vector as for the target. As we are dealing here with the existing situation, this evaluation can be carried out on the basis of observations and measures. In comparison with the target definition, the distance in terms of performances can be calculated.

3. Trajectory definition (steps). On the basis of the distance value calculated in the previous action, the objective of this action is to define a steps trajectory between current state and target, knowing that there must be one step for each strategic period. The steps are expressed with the same performances vector.

Figure 6 summarises these activities.

Figure 6.

The activities of the strategic orientation level.

The definition of the trajectory and, therefore, of the steps that constitute it, is not a simple task for two main reasons. Firstly, it can be difficult to translate the key success factors, often expressed in general terms, into operational objectives i.e., objectives that are valued and translatable into actions. Secondly, the performance space is not accessible in its entirety. The reason for this could be:

• the exogeneous limitation of the level of a performance (technical, legal, etc.);

• the deadly cost of making a certain level of performance accessible;

• the fact that some performances may be opposite: seeking to increase one inevitably leads to reducing the level of another;

• the fact that some performances may rely on the same type of resources (financial or other) that are inevitably limited, this leads to finding a compromise in the distribution of this resource between the two performances.

4.2 The migration plan level

The two time milestones structuring this level are the current state and the first step. These two milestones have already been explained and are present at the level above (Figure 6). The difference with the previous level is that here they are expressed in the form of models. This transition, from an expression in terms of performances to a representation by models, corresponds to an operationalisation process i.e., a willingness to move towards a concrete vision. This is justified at the level of the first step since this will be reached and therefore corresponds to an implemented state.

It is not the purpose of this chapter to propose one enterprise modelling approach over another. There are many business modelling methods and languages available and the choice will have to be made according to the culture of the company. It is always important to cover all the views considered important in a modelling approach: processes, data, physical system, decisions, organisation, etc. To do this, it will be possible to choose languages each corresponding to one of these views or to use multi-point of view methods that already integrate several languages (GIM or CIMOSA, for example). In any case, we consider that the approach proposed here works independently of the languages chosen.

The three main activities structuring this level are as follows.

1. Current state modelling. This action consists of modelling the system in its existing situation, in terms of structure and behaviour. This action concerns the current state. Then, it is possible to use the whole set of instruments available to an analyst to build the model of an existing system: consultation of documents, analysis of computer application screens, field observations, interviews, etc. This action must be able to propose, in complement to the models themselves, an analysis of the system in terms of strengths and weaknesses.

2. First step modelling. This action consists in proposing a model of the system which, as a priority, allows to translate the level of performances defined for the first step by the upper level. This model must also take into account the shortcomings observed in the current state of the system (as-is model) and the possible evolution needs expressed by the company. In addition, the model will need to preserve the strengths identified in the previous action. Here we are in a totally different situation compared to the previous action. The modelling of the existing state was based on observation, the modelling of a future state is based on creativity. We are therefore here at the heart of the engineer’s job, which is to propose the model of a future system, based on the expression of needs and expected performances, with all the uncertainty that it entails.

3. Actions plan. The evaluation of the difference between the model of the first step and the model of the current state enables the definition of a list of actions necessary to evolve i.e., to make the system moving from its current state to the first step. The aim here is not to carry out these actions but to define them, taking into account the fact that they are interdependent. Because of this interdependence (an action needs that another one must be proceeded before, for instance) and because the resources of the company are obviously limited, these actions must be sorted in terms of priority.

Figure 7 represents these activities.

Figure 7.

The activities of the migration plan level.

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 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.

Figure 8.

The general principle of conceptualisation of enterprise modelling.

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.

Figure 9.

The activities of the projects portfolio 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 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.

2. Projects portfolio definition. This activity is central at this level as it is the one that defines the projects portfolio. This is built on the basis of the action plan provided by the higher level. It is clear that the transition from actions to projects is not based on a bijective relationship: several actions can be grouped together to form a single project and, conversely, one action can lead to several projects. The latter case is classic and corresponds to a secondary need arising from the initial project. For example, a change in a management function (initial project) leads to the need to launch a computerisation project and a project to train the managers concerned (secondary projects). The difference between the actions plan and the projects portfolio is that this level takes into account various constraints that had not been considered at the higher level: financial resources, availability of human resources, negotiation with solution providers, etc. The second element to be taken into account is the evaluation carried out by the previous activity: definition of corrective or compensatory activities and integration into the portfolio of ongoing projects. The importance of taking this assessment into account is clear: ongoing projects consume resources that will therefore be unavailable for new projects and they may constitute precedence constraints for new projects.

3. Projects planning. There are therefore as many activities as there are defined projects. The tasks to be defined and planned are standard:

   • 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.

5. Argumentation

The proposed approach highlights several aspects that contribute to the competitiveness of enterprises. The main ones are listed here. On the other hand, taking the approach to its ultimate conclusion presupposes that the company develops self-assessment capacities. We will come back to this point in the second part.

5.1 Competitive aspects

Performance evaluation. The approach emphasises the notion of performance. It is a major element to be integrated into the management of modern companies because, in order to manage their evolution, companies need to evaluate their performance level (actual state) and compare it with a projected state defined in relation to the economic environment. This expected target with performance evaluation and the path to achieve is also evoked in A3 approach of Lean when targets are evoked to allow easier projection of corrective actions. Faced with competitive pressure, many companies have moved in this direction in recent decades. Nevertheless, knowing how to measure performance and how to choose the corresponding indicators is not yet a talent that all companies still possess. This is why many methods have been proposed to help companies move in this direction [31, 32].

Industrial strategy. Talking about performance also means talking about strategy, because it is strategy that allows to clearly define the performance to be monitored. Moreover, an improvement project requires a clear definition of the target to be reached through the formulation of an industrial strategy. This first requires the development of a strategic vision/target to ensure coherence and synergy between all the improvement projects carried out. This argument is not shared by all companies. Obviously, large groups build strategic plans but many SMEs do not for many reasons [33]. Whatever the arguments, the proposed approach encourages the definition of a strategy before any intention of evolution.

Models. To propose modelling is to encourage companies to acquire the means to know themselves. Models do not bring new knowledge about the company, but they allow it to be expressed, standardised and exchanged. As mentioned in [34], to model is to externalise knowledge. Self-organising means choosing one’s trajectory and adapting accordingly; it presupposes being able to generate symbolic information, i.e. information about oneself [35, 36]. Models contribute to this. Also, pushing companies to model themselves means pushing them to know perfectly and permanently how they run and the behaviour of each of their components and to identify which part of the structure needs to be improved or changed. It means enabling them to be autonomous in managing their evolution.

Motivation. Employee motivation is linked to the significance of the work [37]. In terms of change management, this is expressed by the knowledge of the target (where the company is going) and the possibility of frequently see the results of projects. Then, proposing an approach organised in small projects that allow to reach a step of evolution, itself positioned in relation to a long-term target, allows everyone in the company to appreciate the path proposed and the results obtained. It is also important that employees be involved in the approach as much as possible, which is what continuous improvement and most enterprise modelling methods propose. Ali et al. [38] mentions the lack of training and planning as barriers to Lean projects implementation. These aspects have to be systematically taken into account in the projects portfolio.

5.2 Self-evaluation and learning capabilities

The current state (as-is) must be expressed at each level, in the three proposed forms: performances, models and ongoing projects. As the approach is presented, this expression is based on a fully-fledged activity at the three levels of evolution management, i.e. this state is reconstructed each time. This reconstruction can be carried out by the company itself or by relying on the services of an external company, which is often the case.

Pushing the logic to its ultimate conclusion means thinking in terms of internalisation and continuity.

Internalisation reflects the fact that the company must be able to do this on its own. Indeed, knowing how to evaluate its performance, model its own operations and monitor its projects are not these skills that every well-organised company should have within it? Just as it is normal for the company to turn to external service providers for design activities (because it may not have the necessary skills in IT, workstation organisation, etc.), it is also necessary for it to be able to express its current state.

Continuity is the principle that the company should not have to reconstruct its current state at each step of the process but should be able to know it at every moment. As regards the strategic orientation level, this means implementing a system of performance indicators (performance monitor) that is updated as often as possible and that can be adapted if strategic orientations require a change of indicators. For plan level migration, this means that the company has its own models and that there is someone responsible for updating them each time a change is noticed. By analogy with the technical data that the company necessarily possesses for its technical activities, this set is called organisational data here. Finally, for projects portfolio level, it means following and monitoring the evolution projects (ongoing projects portfolio), which in general is integrated into the company’s operations and does not pose any problems. These three elements are grouped together in a set entitled “Enterprise monitoring and documentation”. Finally, continuity reflects the obvious fact that in order to evolve continuously, the enterprise must be able to evaluate itself continuously.

In conclusion, the approach proposed here leads to advocate a vision of the enterprise that takes its evolution in hand and that provides itself with the means to constantly learn about and evaluate itself. In this way, the evolution management participates to the development of learning organisations [39, 40].

Figure 10 summarises this vision and shows the main activities.

Figure 10.

The organisation of evolution in the self-evaluated, learning enterprise.

5.3 Evolution management and continuous improvement

The evolution management system entails many aspects consolidating the PDCA approach, well known and used in large groups and even SMEs to sustain quality. Even though strategy, as quoted in section 5.1 is not obviously formalised by SMEs because of their dependencies to big groups, they often use and admit efficiency of PDCA vision or DMAIC (often tightly linked to project approach and can also be assimilated to PDCA cycle). Indeed, PDCA is the fundament of continuous improvement because of the value given to the “Act” step to ensure continuous action on systems to make a progress. In the vision presented here, the actions to carry out are in step “Act” of the PDCA but are no more only corrective actions after “Check” step. They represent also new proactive ideas and prospective plans to improve the whole existing projects system regarding the “output” and “knowledge” got from ongoing projects portfolio and migration plan.

The evolution management reminds the importance for the company to continually formalise and display the targeted performances. The performance objectives are tightly linked to the defined “Strategy” that can be revealed in “Plan” step of PDCA. Updating with “performance targets” planned by company strategy is the potential inducer of “could be” situations.

Concerning migration plan, PDCA and Lean highlight that, whatever modelling approach considered, the “added value” is always the main concept to undertake to keep “efficient” model with the required added values processes, the expected relevant data, the prior decisions and the accurate organisations.

To model the current state (As-is), we should remind that the use of various instruments available to an analyst to build the model as consultation of documents, analysis of computer application screens, field observations and interviews are such many elements absolutely necessary to deal with “reliable” data. From Lean point of view, any process has to be produced respecting “Jidoka” notion which means ensuring the quality “at the source”. The current state modelling is critical step that should be made as reliable as possible to avoid wasting times and retro-corrective actions. The more the system is reliably represented the better the “could be” system can be achieved in good conditions. So Jidoka, principle coming from Lean management, is an efficient support for the organisational data sustainability.

Lean practices and Continuous improvement are indubitably the result of human forces, company strategy and collective efforts. By the way, the motivation and involvement of the team project evoked previously is an important part defended by Lean and continuous improvement. Then, evolution management, if well described and explained to the team, is significantly able to strengthen the “Do” step of PDCA.

6. Conclusions

The approach presented here aims at repositioning the enterprise modelling approach in the context of continuous evolution, better able to respond to a turbulent economic environment.

Within this framework, it emerges that many tools and approaches are involved in the reengineering and improvement of companies: strategy, performance measurement, modelling, projects and the whole toolbox of Lean Management and continuous improvement. The approach presented here is an opportunity to bring these approaches closer together: strategy and performance measurement at the top level, Lean models and tools at the central level and projects at the operational level.

The ultimate goal is to take advantage of the benefits of all these approaches. For example, Lean insists on short projects, anchored in practice and part of a continuous improvement; enterprise modelling allows to document the company, to share knowledge and to propose a systemic vision.

Finally, the approach proposed here opens important perspectives concerning the integration of enterprise reengineering approaches.