Reorganizing an Enterprise Thanks to its Information System

Jolita Ralyté

, Wanda Opprecht

and Michel Léonard

Institute of Information Service Science, University of Geneva, Carouge, Switzerland

Ensemble Hospitalier de la Côte, Morges, Switzerland

Keywords: Information System Evolution, IS Evolution Steering, Enterprise Reorganization, IS Steering Model.

Abstract: Enterprise Information System (IS) is often reduced to a position to solve problems, most often administrative

ones, by means of informatics. This paper considers another point of view of IS utility where it creates new

opportunities and greatly expands the means to deal with complex change situations. The case studied in this

paper is the enterprise reorganization. This exploratory research reveals the role of IS in such a critical

situation. It unearths key IS modeling and architecture principles and discovers knowledge and methods of

reasoning required to support IS evolution as an underlying way to the enterprise reorganization. It concludes

with the emergence of a new research area: the Computer Aided Information Steering.

1 INTRODUCTION

Enterprise reorganization is a challenging

transformation that has to take into account various

modifications in human activities, business processes

and areas of responsibility. It generally involves a

large amount of people at different accountability,

decision and operational levels. It has to deal with

various risks like inconsistency of activities and

responsibilities, non-compliance with the regulatory

body and finally a total failure. It can even be

considered as terrifying because of a high level of

uncertainty that enterprise steering officers have to

face (Opprecht et al., 2014) and the risks it implies

(Sherer and Alter, 2004). However, today’s

enterprises are facing more and more frequent

transformations (Rouse, 2005), which makes this

topic particularly relevant.

There are many studies concerning enterprise

reorganization, notably in the economy and

management fields, like the one by Chandler (1962)

recognized as fundamental. Other works investigate

consequences of enterprise reorganization on its

Information System (IS) (Huang and Gao, 2005), or

in the contrary, Information Technology (IT)

influence on organizational environments (Cruz-

Cunha, 2010; Rouse, 2005). Many related works have

been published in the domains of Business/IT

alignment (e.g. Henderson and Venkatraman, 1993;

Thevenet and Salinesi, 2007; Ullah and Lai, 2013),

Business Process Reengineering (Barrios and

Nurcan, 2004) and Enterprise Architecture (Aier et

al., 2011; Greefhorst and Proper, 2011). They provide

means for describing As-Is and To-Be states of

enterprises and of their information systems. Besides,

a few publications analyze the application of

enterprise models for engineering enterprise

transformation (e.g. Aier and Gleichauf, 2010; Aier et

al., 2011; Buckl et al., 2009).

Enterprise reorganization is inevitably inter-

related with the evolution of its IS. There are many

works in the domain of IS evolution, most of them

based on the usage of models (e.g. Aboulsamh and

Davies, 2011; Pons and Kutsche, 1999; Ralyté et al.,

2010), but, at the best of our knowledge, there is no

study about the prominent role that IS can play in the

enterprise reorganization process. This is the

exploration topic of our paper. In particular, we

introduce an approach for IS evolution steering as a

means for addressing complex and often critical

situations of enterprise reorganization. We argue that

enterprise IS should be considered as a pivotal value

to enterprise reorganization.

2 RESEARCH SITUATION

To present our research situation, we first consider a

typical scenario of enterprise reorganization where an

initial organization (AS-IS organization) has to be

transformed into the targeted one (TO-BE

organization). Then, we argue that this scenario

Ralyté, J., Opprecht, W. and Léonard, M.

Reorganizing an Enterprise Thanks to its Information System.

In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 2, pages 567-574

ISBN: 978-989-758-187-8

567

undervalues the role of enterprise IS in the

reorganization process, and we claim that an

approach for IS evolution steering would be a

valuable support for this process.

2.1 A Simple Reorganization Scenario

A typical enterprise reorganization scenario can be

summarized in six steps:

1. Initiative, which consists in identifying a myriad

of situations revealing the inadequacies of the

AS-IS organization.

2. Motivation, having as objectives to gather

enough information demonstrating that local

improvements are insufficient to efficiently face

these situations, and to push to undertake a

reorganization process.

3. Design, where objectives of the reorganization

are specified and the TO-BE organization is

designed.

4. Impact Estimation, that aims to assess the

impact of the TO-BE organization on the

enterprise, its pertinence and feasibility.

5. Decision, where three possibilities are

considered: (1) to abandon the reorganization,

(2) to modify reorganization intentions and re-

design the TO-BE organization, which means to

go back to the design step, or (3) to launch the

reorganization process.

6. Implementation, which initiates the

reorganization process, providing that such

decision was taken in the fifth step. It includes

the reorganization management and

implementation inside the entire enterprise.

Generally the first five steps are under the

strategic responsibility of the enterprise, while the

sixth one is under the strategic control, which can be

more or less effective and efficient. A major

difference between the first five steps and the sixth

one is very well known in the classical management

culture – it represents the difference between the

strategic level and the operational level. However, the

success of the reorganization process depends on this

sixth step. Any major failure happening during this

step could create a disastrous situation with important

strategic consequences for the enterprise.

2.2 Information System – A Pivotal

Value to Enterprise Reorganization

Within the scenario presented above, the IS domain

does not take part efficiently in any strategic

discussion within the reorganization itself and even

within the reorganization processes. Its role is

recognized only in the sixth step, where it has to

transform the initial information system, called ASIS-

IS, into another information system, called TOBE-IS

and whose design has to be deduced from the TO-BE

organization. Given the importance of information

systems for most of the enterprise activities, this

scenario seems to be no more relevant to efficiently

account for generic situations of reorganization. The

following situations constitute evidences to support

this claim.

2.2.1 Issues of ASIS-IS Transformation into

TOBE-IS

All the IS specialists know that legacy IS

transformation is very complex. In the case of

reorganization, the TOBE-IS cannot be created from

scratch. An important amount of data stored in the

ASIS-IS must also belong to the TOBE-IS. The

analysis of strategic TOBE-IS objectives (Pons and

Kutsche, 1999) and continuous dialog between the

enterprise steering actors and the IS steering actors

appear to be essential, however not sufficient.

Strategic objectives are not precise enough to work at

the level of IS – to consider its data structure,

processing and integrity rules. Furthermore, such a

transformation usually induce a re-design of the IS

architecture, and so open another important space of

design and strategic decisions named enterprise

architecture (Greefhorst and Proper, 2011).

Therefore, IS transformation taken globally is a risky

operation inside the reorganization process. It can

lead to a major strategic failure, e.g. some enterprise

actors in the TO-BE organization could have to face

inefficient TOBE-IS interfaces and not be able to

complete their tasks and responsibilities.

2.2.2 Transition from ASIS-IS to TOBE-IS

Once the strategic decision to move in the TO-BE

organization is taken, all its actors must be able to

work with the corresponding TOBE-IS. It means that

this decision must be taken only with the agreement

of the IS steering officers. Furthermore, there is

always a period where ASIS-IS and TOBE-IS are

both operational but only ASIS-IS is active. The

consequence for the IS steering officers is to be able

to maintain both systems. Once the decision to

activate TOBE-IS is taken, ASIS-IS cannot be

deactivated completely because it contains

information (data) and data processing operations,

which continue to be useful even if they belong to the

AS-IS organization. So, the IS steering actors must be

able to maintain active certain parts of the ASIS-IS,

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

568

and a number of people in the enterprise should be

able to work in both organizations: the AS-IS

organization for former business activities and the

TO-BE organization for the new ones. This overlap

between ASIS-IS and TOBE-IS is crucial for the

enterprise to ensure business continuity despite of the

reorganization.

2.2.3 Exhaustive Strategic Information from

Enterprise IS

While executing the first two strategic steps of the

aforementioned reorganization scenario the

enterprise reorganization steering actors have to deal

with many uncertainties that can be reduced if the

necessary and complete information is available for

them. A large part of the necessary information can

be found in the enterprise IS, which supports most of

the enterprise activities within the AS-IS

organization. Even if the informational field covered

by the IS is not complete for taking decisions of

reorganization, inside this field, the information is

exhaustive and accurate. Notably, it includes: all the

information about data, business processes and

persons working with the IS; for each person, her

informational space and processes she contributes;

and the structure of the IS (its conceptual model).

The 3rd and 4th steps of the reorganization

scenario can also be supported by the IS domain if the

strategic discussions take into account IS

potentialities. These steps are the good time to design

the TOBE-IS, which must correspond to the intended

TO-BE organization. Then, by comparing ASIS-IS

and TOBE-IS it is possible to identify precisely the

impact of the reorganization on the actors and their

activities and responsibilities.

The IS domain can also support the 5th

reorganization step. Once the direction of the

reorganization is determined, actors responsible for

its steering will have to pilot the reorganization

management process. Based on the inputs given by

the IS domain, this process can be decomposed into

partial reorganizations. In this way, the enterprise

reorganization steering actors would take decisions

concerning only partial reorganization, which is much

more manageable. Our suggestion for this step is to

adopt an exploratory approach, which interweaves

enterprise reorganization decisions with the IS

evolution steering.

3 IS EVOLUTION STEERING

In order to understand the role of the IS domain

inside the enterprise reorganization domain and to

capitalize on, we need an informational bedrock

containing all accurate and complete information on

how enterprise IS supports its activities. Inspired by

(Le Dinh, 2006), we build such a bedrock as an

information system called ISIS – Informational

Steering Information System. Enterprise IS and ISIS

are not at the same level. IS is at the operational level,

where actors (IS users) can query/create/

delete/modify objects of IS classes, and

trigger/control/stop operations on these objects

according to their access rights. ISIS is at the IS

steering level, where actors (IS steering officers) can

query/create/delete/modify the design of classes,

operations on these classes, integrity rules, processes,

and access rights. In the next sections we present the

schema of ISIS and how it is used in IS evolution

steering.

3.1 IS Steering Model (IS-SM)

The proposed ISIS model, called Information System

Steering Model (IS-SM), is restricted to the

information, which can be extracted from the

enterprise IS in a generic way. Thus, it does not

pretend to contain all the information that an

enterprise can possess. But for the reorganizational

purpose, it contains organizational information, such

as organizational units, which may be decomposed

into smaller ones in a vertical way or in a transversal

way, positions in organizational units, persons’

assignments to one or several positions, their

responsibility over different information elements,

etc. The (simplified) model of IS-SM is given in

figure 1. It is composed of three main parts: activity,

information, and regulatory.

The activity part considers, on the one hand, all

relations between actors and the information system

of the enterprise, and, on the other hand, actors’

positions inside the organization. Its main element is

activity, which can be composed of other activities,

and participates in one or several business processes.

Persons can perform an activity only if they are

assigned to positions, which are in charge of it.

Another important concept of IS-SM is business rule

that controls the execution of activities and business

processes and is dependent on the enterprise business

model.

The IS-SM information part reflects the

traditional IS concepts such as class, operation,

integrity rule, and their interrelations.

The IS-SM regulatory part describes knowledge

about laws, policies and regulations that are

independent of the enterprise organization but

Reorganizing an Enterprise Thanks to its Information System

569

Figure 1: Simplified Information System Steering Model (IS-SM).

necessary to design its information system. This

knowledge is described in terms of regulatory

elements that can be a regulatory concept, regulatory

role or regulatory rule. The elements of the two other

parts of the model can be dependent on these

regulatory elements. For instance, internal regulation

policies, laws and international regulatory

instruments impose the organization to have some

positions, activities and business rules, and to store

and process particular data, i.e. to contain appropriate

classes, operations and integrity rules implemented in

its IS. Generally, this regulatory part is not made

explicit in the traditional IS. However, it is very

important for the IS steering officers to trace every

regulatory element inside the IS. In case of its change

(e.g. a change of a law), a compliant IS evolution

must be triggered, and so this trace is necessary for

steering the evolution process with efficiency and

assurance.

The main interrelations between the activity part

and the information part are formed on the role

concept. A role is associated, on one side, to one or

several activities, and, on the other side, to one or

more classes/operations. So, the activities related to a

role have the right accesses to the classes and

operations associated to this role, and, consequently,

the persons, who may perform these activities, also.

Other interrelations concern business rules (from the

activity part) and integrity rules (from the information

part). Association is established between a business

rule and an integrity rule if the later was created from

the former.

The interrelations between the activity and

information parts on one hand and the regulatory part

on the other hand are formed on the following

elements: event, business process, position, business

rule, role, class, operation, and integrity rule. An

interrelation is made between those elements and the

elements of the regulatory part, if they are created

from the last ones.

The last difficulty to surmount is to consider that

in general an enterprise has several information

systems, more or less independent of each other. So,

IS-SM must include the concept of IS, and all the

elements of its informational part must be associated

with the IS where they are present. Furthermore, a lot

of services can be built upon an IS, and IS-SM must

take them into account. Indeed, IS and service

concepts are defined in IS-SM but are not shown in

Figure 1 for readability purposes.

To conclude, we argue that such informational

bedrock is feasible, because the system supporting

enterprise IS contains all the required information.

3.2 Measuring IS Evolution Impacts

At each increment of ASIS-IS evolution towards

TOBE-IS, the IS evolution steering officer has to take

important decisions that could have more or less

important impact on the TOBE-IS and therefore on

the TO-BE organization. The uncertainty level, that

she has to face, can be reduced by providing

appropriate information to observe IS changes, to

understand their impacts, and to identify potential

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

570

risks. This information can be obtained from the IS-

SM but has to be reduced to the only information

space involved in the evolution at hand. For this

purpose, we assume that responsibility is a key

concept for the impact analysis of an evolution.

Inspired by (Feltus et al., 2011; Khadraoui and Feltus,

2012), we define responsibility as a set of ISIS

instances from IS-SM representing accountabilities

and capabilities of an actor to perform a task – her

impact on the information (Ispace) and the regulatory

(Rspace) elements.

3.2.1 Information Space (Ispace)

The information space of an IS-SM activity part

element x (i.e. role, person, position, and activity),

retrieved from IS-SM and denoted Ispace(x),

represents the space of information accountability

and capability of x. It is formally defined as a

powerset Ispace(x)=<Cl(x), Op(x), IR(x)> where the

set of classes Cl(x), the set of operations Op(x) and

the set of integrity rules IR(x) are accessible from x in

IS-SM (i.e. can be obtained by join, selection and

projection operations). The part of IS-SM that allows

to retrieve Ispace(x) is shown in figure 2.

Figure 2: The part of IS-SM allowing to retrieve the Ispace

of a role / activity / position / person.

For example, the Ispace of a role r is defined as

Ispace(r)=<Cl(r), Op(r), IR(r)>. Here, Cl(r)

represents the set of classes that r can access (with the

primitive methods: read, create, update, enable,

disable), and, therefore, for which r carries

accountability (probably shared with other roles) and

holds capability to execute methods on these classes.

Op(r) represents the set of operations that can be

executed by the role r, and for which r carries

accountability and holds the necessary capability.

Finally, IR(r) contains integrity rules accessible to r

via the methods of the classes in Cl(r) of its Ispace.

Therefore, r carries accountability to validate these

rules when this validation is not completely

automatized and holds capability for that.

The Ispace of a person p, Ispace(p), represents the

information elements (classes, operations and

integrity rules) that p needs to access in order to

perform the activities related to her position(s). In the

course of evolution, when a person leaves the

organization, her information knowledge should be

identified and transferred. On the opposite, when a

person enters the organization, she should be trained

to use this information. It is defined by the union of

the Ispace of each of its roles in the organization.

3.2.2 Regulatory Space (Rspace)

The regulatory space of an IS-SM activity part

element x (i.e. role, person, position, and activity),

denoted Rspace(x), represents the space of regulatory

accountability and capability of x, composed of

concepts, regulatory rules and regulatory roles of the

regulatory part of IS-SM (see Figure 1), which are

accessible from x. For example, if the Rspace of a

person p, Rspace(p), includes a regulatory role rr,

then p has compliance responsibility with rr, and

possesses the capability to play this role, i.e. the

required knowledge and proficiencies.

3.2.3 Roles of Ispace and Rspace

The Ispace and Rspace defined systematically on the

ISIS-IS and the TOBE-IS allow to measure the delta

of the IS evolution from information and regulatory

points of view respectively. They allow determining

how the work environment will change for each actor

of the organization. For example, some persons could

be granted with new responsibilities (i.e. creating,

deleting, modifying objects) over an existing or

newly created information space, for which they did

not have access before. This situation arises questions

such as: “are these persons ready to assume these new

responsibilities?” or “do they have appropriate

capabilities?” Creation of a new information space

could also require creation of new roles, positions and

activities. All these changes at IS level must be

decided at the enterprise steering level. However, the

information necessary to support the decision taking

is accessible at the IS level.

3.3 Principles of IS Evolution

The subject of IS evolution is to transform a schema

into another schema IS

, and to transform IS

objects into IS

objects. We propose to approach it

from the point of view of ISIS, whose schema is

represented by IS-SM. For the sake of clarity, at the

ISIS level we call a class, element, and its objects,

instances, while, at the IS level, we keep the standard

terminology of class and object.

Reorganizing an Enterprise Thanks to its Information System

571

3.3.1 IS Evolution Primitives

Since IS-SM, the ISIS schema, is built only by means

of existentially dependencies, the starting point of the

evolution domain is very simple. It is a list of atomic

primitives: create, enable, disable, abort and delete an

instance of any IS-SM element. Because of this

simplicity, we consider that the schema of the IS

steered by ISIS is also built by using only existential

dependencies. Notice that an instance/object is

existentially dependent on its element/class.

These primitives induce to the following states of

an instance (and also object): created, enabled,

disabled, and deleted. depicts the generic life cycle of

an instance/object.

Figure 3: The lifecycle of an instance of any element from

IS-SM.

A created instance/object exists but is not yet

useful. For instance, a created integrity rule cannot yet

be validated because some of its validation processes

are not yet designed or implemented. A created

instance/object can be aborted and so becomes deleted,

or be enabled and so becomes useful, e.g. an enabled

instance of an Operation can now be executed. A

disabled instance/object is accessible only by other

disabled instances/objects, except for query, where all

instances/objects can access it. For example, a disabled

instance of the element Class, which is a class at the IS

level, means that it is always possible to query its

objects, and it is possible to create and delete its objects

only through disabled operations. A deleted instance

disappears definitively. If a created/enabled

instance/object is dependent on another

instance/object, then this one is created/enabled. All

the instances/objects, which are existentially

dependent on a disabled/deleted instance/object are

disabled/deleted.

3.3.2 Evolution Effects

An evolution primitive cannot be isolated only to its

main concern, element or instance. It has effects on

other parts in ISIS and IS, horizontally and vertically.

Horizontal effects can be specified through patterns

formally describing all the interrelations between

elements or instances themselves. For example, if an

instance cl of the element Class in ISIS is disabled,

then all the instances op of the element Operation

associated to cl must be disabled, because they cannot

be performed in the corresponding IS without

processing cl objects. Vertical effects are deduced

from conformity rules between instances and objects.

For example, if cl is disabled in ISIS, then all its

objects must be disabled in any IS where cl is a class.

Every primitive becomes robust if it implements all

its horizontal and vertical effects. Indeed it depends

on two main properties: (1) the whole IS schema

(including static, dynamic and integrity rule

perspectives) must be easily evolvable, (2) the IT

system supporting the IS (e.g. a database management

system) must provide an efficient set of evolution

primitives (Andany et al., 1991).

3.3.3 Composite Evolution Primitives

The above-mentioned atomic primitives are actually too

primitive and the evolution steering managers need to

have more sophisticate operations to be efficient. They

are built by composing atomic primitives; so they are

called composite primitives. For example, a composite

primitive cp1 allowing to replace an activity of a person

by a new one would include three atomic primitives: p1

disables the affectation of the old activity to the person,

p2 affects a new activity to the person, and p3 activates

this affectation. Like atomic primitives, composite

primitives induce horizontal and vertical effects caused

by the atomic primitives they include. They are robust if

they take into account all these effects. Below in this

paper, all primitives are considered as robust.

3.3.4 Managerial Effects

The managerial effects consider the efficiency of IS

at the human level. Most of them can be detected

automatically, but the evolution managers have to

decide if the proposed evolution has a harmful effect

or not on the enterprise activities. If yes, they must

decide to give up the evolution or to continue it

nevertheless. If no, they are reassured in the validity

of the evolution. Managerial patterns will bring out

these managerial effects. Primitives, which take into

account these managerial effects, are called smart

primitives. Below, all primitives are smart.

For example, the change of a person’s activity a1

into a2 has a managerial effect – the evolution

managers must be sure that this person was not the

last person to be in charge of a1 and also if the

workload of the remaining persons in charge of a1

will not become too heavy. Another example would

be the situation of a class without any role associated

to it because its utility is no more obvious.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

572

4 FROM IS EVOLUTION TO

REORGANIZATION

The enterprise reorganization process is larger than an

IS evolution because it implies changes at

organizational level for several organizational units.

For example, it can include the creation of new

positions, new assignments of actors to positions and

to activities, introduction of new business rules, etc.

We explore now how to consider enterprise

reorganization from the IS point of view. Even if it is

not sufficient to encompass all the reorganization

problems, it can offer not only accurate information

but also a method to conduct this complex and

delicate process. Pursuing this aim, we propose, in the

preparation step, to decompose reorganization into

several evolutions and to analyze the interactions

between the management of reorganization and the

management of these evolutions. It is sure that

impacts and managerial effects have an important role

to play in this decomposition process. Then, the

supervision step plans processing of these evolutions.

Some of them can be launched in parallel, while other

in sequence. But this plan must be scalable depending

on the results of evolutions in progress or finished. It

is important that these results are communicated to

the supervision as soon as possible to adjust the plan

of evolution processing. Next, the coordination step

decides the moment to launch evolutions, depending

on the results achieved, or to abandon an evolution

partially or totally. The supervision and coordination

steps are continuously in alert because they must

always choose the good path, especially taking into

account information coming from evolution

processing. Figure 4 depicts the lifecycles of

processing enterprise reorganization and IS evolution

with their coordination.

Inside the reorganization process, there is a

critical situation, which can be hidden by the efforts

to develop the TO-BE organization and its TOBE-IS,

the legacy business processes. These processes are

legitimate in the AS-IS organization, but due to the

reorganization they become legacy, for instance, due

to the introduction of new business or regulatory

rules. In particular, their operations become outdated

in the TO-BE organization and their instances in the

ISIS become disabled. However, at the moment when

they are disabled, some of them are still underway.

Moreover, there are several situations, especially in

public administration and contract management,

where it is impossible to stop them. They must

continue to deal with their current issues inside the

AS-IS frame of rules. Our proposal contains

intrinsically a response to surmount this situation of

legacy processes, by means of disabling instances in

ISIS and objects in TOBE-IS. In this way, these

processes, their operations and the rules to validate

become disabled ISIS instances. So, they do not

belong to the TOBE-IS and consequently to

Figure 4: Coordination of the reorganization lifecycle with

the IS evolution lifecycle.

the TO-BE organization. But, even after the

reorganization, they can perform their current issues

in the AS-IS organization until their end. It remains

to manage actors who must be able to work again in

the frame of AS-IS, while working every day in the

frame of TO-BE.

The reorganization scenario presented in section 2

raises up crucial questions for the reorganization

process. This intelligence must be kept in our approach

centered on ISIS. Indeed, this scenario faces critical

situations that are not dissolved due to ISIS, because

enterprise reorganization is not only a question of IS.

The deep change is in the method to manage the

reorganization process at the enterprise level. The TO-

BE organization must have its TOBE-IS as soon as it

exists. The reorganization domain shows the necessity

for an enterprise to have an accurate ISIS. It must be

implemented in a complete environment, which we call

Computer Aided Information Steering Environment

(CAISE), to deal with strategic developments. Due to

information, with its central place in any enterprise, due

to IS, there in no more reason to separate business

strategic and IS activities. They must be interwoven. In

the case of enterprise reorganization, we observe that the

sequential way of the typical scenario is not adequate

with the use of ISIS.

5 CONCLUSIONS

In this exploratory paper, we argue that the IS

Reorganizing an Enterprise Thanks to its Information System

573

domain, and in particular IS evolution steering, has to

play an important role in any enterprise

reorganization and at each step of the reorganization

process. Indeed, reorganizing an enterprise inevitably

implies more or less important changes in its IS,

which have to be implemented to make this

reorganization possible. Identifying and simulating

these changes at IS level allows to understand how

the organization itself will change and to assess its

feasibility and risks. But, to take this responsibility,

the IS domain must provide clear, complete, and

rigorous information models that can evolve in a

consistent way. For this purpose, we propose an IS

evolution steering approach based on the construction

of ISIS (i.e. informational steering IS) founded on IS-

SM (i.e. IS steering model). For IS steering, IS-SM

allows to specify a complete information model of

ASIS-IS and to design the TOBE-IS. For the

reorganization steering, it allows to have

continuously a complete and accurate situation of the

enterprise at the informational level. We complete our

approach with the notion Ispace/Rspace that helps to

measure the impact of IS evolution on the enterprise

organization from informational and regulatory

points of view, and facilitates the decision making at

enterprise steering level knowing that most of the

reorganization/evolution decisions cannot be

reversed.

REFERENCES

Aboulsamh, M., Davies, J., 2011. Towards a model-driven

approach to information system evolution. In W.W.

Song et al (eds.), Information Systems Development, pp.

269-280, Springer.

Aier, S., Gleichauf, B., 2010. Application of Enterprise

Models for Engineering Enterprise Transformation.

Enterprise Modelling and Information Systems

Architectures, 5(1): 56-72.

Aier, S., Buckl, S., Gleichauf, B., Matthes, F., Schweda,

C.M., Winter, R., 2011. Towards a more integrated EA

planning: Linking transformation planning with

evolutionary change. In 4th Int. Workshop on

Enterprise Modelling and Information Systems

Architectures: Concepts and Applications (EMISA

2011), Hamburg (Germany), pp. 23–36.

Aier, S., Fischer, C., Winter, R., 2011. Construction and

Evaluation of a Meta-Model for Enterprise Architecture

Design Principles. In Proc. of Wirtschaftsinformatik, p.

637-644.

Andany, J., Léonard, M., Palisser, C., 1991. Management

of Evolution in Databases. In Proc. of VLDB 1991.

Barrios, J., Nurcan, S., 2004. Model Driven Architectures

for Enterprise Information Systems. In A. Persson and

J. Stirna (eds.), CAiSE 2004, LNCS, vol. 3084, pp. 3–

19. Springer.

Buckl, S., Ernst, A.M., Matthes, F., Schweda, C.M. 2009.

An Information Model for Managed Application

Landscape Evolution. Journal of Enterprise

Architecture, 5(1): 12-26.

Chandler, A.D.Jr. 1962. Strategy and Enterprise: Chapters

in the History of the American Industrial Enterprise.

MIT Bradford.

Cruz-Cunha, M.M. (ed.), 2010. Enterprise Information

Systems for Business Integration in SMEs:

Technological, Organizational, and Social

Dimensions. IGI Global.

Feltus, C., Petit, M., Dubois, E., 2011. ReMoLa:

Responsibility Model Language to Align Access Rights

with Business Process Requirements. In Proc. of RCIS

2011, pp. 1–6.

Greefhorst, D., Proper, E., 2011. Architecture Principles -

The Cornerstones of Enterprise Architecture. The

Enterprise Engineering Series 4, Springer.

Henderson, J.C., Venkatraman, N., 1993. Strategic

Alignment: Leveraging Information Technology for

Transforming Organizations. IBM Systems Journal, 32

(1): 4–16.

Huang, X., Gao, Y., 2005. Enterprise Reorganization and

Information System Integration. Construction

Machinery and Equipment, 2005-06.

Khadraoui, A., Feltus, C., 2012. Service specification and

service compliance: How to consider the responsibility

dimension? Journal of Service Science Research, 4(1),

123–142.

Le Dinh, T., 2006. Towards a New Infrastructure

Supporting Interoperability of Information Systems in

Development: the Information System upon

Information Systems. In Interoperability of Enterprise

Software and Applications, pp. 385-396. Springer.

Opprecht, W., Ralyté, J., Léonard, M., 2014. Towards a

Framework for Enterprise Information System

Evolution Steering. In U. Frank et al. (eds.), PoEM

2014

, LNBIP 197, pp. 118–132. Springer.

Pons, C., Kutsche, R-D., 1999. Model evolution and system

evolution. In V Congreso Argentino de Ciencias de la

Computación La Plata (Argentina).

Ralyté, J., Arni-Bloch, N., Léonard, M., 2010. Information

Systems Evolution: A Process Model for Integrating

New Services. In Proceedings of the 16th Americas

Conference on Information Systems - AMCIS 2010.

Rouse, W.B., 2005. A Theory of Enterprise

Transformation. Systems Engineering, 8(4): 279-295.

Sherer, S.A., Alter, S., 2004. Information system risks and

risk factors: are they mostly about information systems.

Communications of the AIS, 14(2): 29–64.

Thevenet, L-H., Salinesi, C., 2007. Aligning IS to

Organization's Strategy: The InStAl Method. In J.

Krogstie et al. (esd.), CAiSE 2007, LNCS 4495, pp.

203-217, Springer.

Ullah, A., Lai, R., 2013. A Systematic Review of Business

and Information Technology Alignment. ACM

Transactions on Management Information Systems,

4(1): 1–30.

ICEIS 2016 - 18th International Conference on Enterprise Information Systems

574