A Methodological Framework for Understanding IS ... - CiteSeerX

A Methodological Framework for Understanding IS Adaptation through Enterprise Change1 Camille Salinesi, Jaana Wäyrynen [email protected] Centre de Recherche en Informatique Université Paris 1 – Sorbonne 90, rue de Tolbiac, 75013 Paris – France

Abstract. Enterprise change calls for Information System adaptation. In both academy and practice, BP modeling and re-engineering has been recognized as an effective way to enlighten the adaptations required on IS when the enterprise changes. However, in industrial scale projects BP Models are large and complex. This hinders the understanding of the required BPs in the light of the current ones. This paper draws from our experience with an actual change project that this issue can be dealt with by abstracting BP models. The paper proposes a methodological framework organizing analysis into several levels. At the highest level, the framework proposes to use an abstract formalism called MAP, which helps synthesizing BP goals and strategies Our expectation is that MAP facilitates analysis of change with traditional BP models. A process is also proposed to conduct the analysis of BP change and IS adaptation starting with MAP. The resulting method was applied in an industrial case study and the framework criticized. The lessons learned from this experiment are fourfold: (i) the methodological framework is effective although it needs more explicit links between models, (ii) the understanding and organization of BP models is made easier by the usage of the more abstract MAP models, (iii) modeling with MAP helps making more complete BP models, and (iv) the multiplication of models in an IS adaptation project burdens the complexity of their management.

1. Introduction According to [Nosek90] 50% of the Information Systems (IS) lifecycle costs are incurred after initial development. There is a variety of Information System evolutions responsible for these costs. Among them, adaptation occurs because of changes that are external to the Information System. Very frequently, enterprise changes call for IS adaptations, so that one of the major IS quality, namely fitness for use [Potts97], can be maintained. Several methods exists to analyze the IS adaptations required in the context of enterprise change [Bubenko98] [Jacobson94] [Freeman91]. We believe these methods have some common characteristics: (i) they assume the rationale for IS adaptation is to be found in contextual forces relating to the enterprise change, (ii) they differentiate the current situation from the future one, (iii) they exploit different modeling techniques to describe the required business models and IS, and (iv) they assume a limited scale of the studied change or adaptation. Many methods use BP (BP) modeling techniques prior to IS design. In such methods, BP models synthesize the context of use of IS. Understanding the future BPs helps better eliciting the requirements for the future IS, and thus guide its design. Although effective, these approaches suffer efficiency issues. Indeed, BP models tend to be complex [Fathee98]: they detail the business at the risk of hindering some of their important aspects such as the business goals and strategies. Besides, non-standard BPs often make the structure of the BP models even more complex. Experience shows that this is part of the reason why understanding the transition to the future BPs and Information System is long and difficult [Giaglis99]. We propose to facilitate this activity by focusing on BP goals and strategies prior to details such as who does what, when, how and in which sequence. In terms of organization, we also propose to exploit the complementarity of modeling techniques. MAP, a goal modeling technique integrating the concept of strategy, supports the former. A methodological framework for enterprise change based IS adaptation supports the latter. The methodological framework provides an organized picture of the models used in an IS adaptation project. Two hypotheses are made: a) the project is driven by the study of gaps between the current and the future situation and b) the need for a change of the IS, of the enterprise’s organization, or of its BPs, etc can be found in the context of their environment. The approach proposed has therefore the following characteristics: • A specific modeling technique can be used to understand change at multiple levels, e.g. IS, BPs, business goals, etc. The framework uses MAP to model the enterprise's business goals. MAP indicates how BP goals are achieved with strategies and details it by refinement. There is no imposed modeling techniques at the 1

This paper was partly funded by France Télécom R&D

1

[A Methodological Framework for Understanding IS Adaptation through E

other levels (the reader interested in this topic can refer to [Antón94], [Jacobson90] or [Jaeschke93]). However, the framework assumes that MAP and BP models can play a complementary role in change analysis and IS adaptation. • Change is studied under the form of gaps between models specifying actual and future situations in the same level. Three collections of models are used: the As-Is models specify actual phenomena, To-Be models specify the future situation, and gap models specify changes, without assumption on how or when they should be implemented (the way change is implemented may affect the successfulness of the change project [Nanda96],it is thus important but out of the scope of this paper). • The rationale for the gap models specified at some level stands in change forces issued from an upper level. Therefore, the approach uses a top-down strategy. In this paper, the gaps between As-Is and To-Be models are rationalized by the gaps at the upper level. Other change forces such as market tension, enterprises evolutions such as merges or take-overs, technology evolution, etc, can also be considered, but this paper provides no systematic way to handle them. The improvements expected from such an approach are globally: more synthetic models of the BPs, facilitated identification of the gaps between As-Is and To-Be BP models, and better organization of the models. Our program to evaluate these improvements has started by an industrial experiment that showed the effectiveness of using the MAP and gap models in an actual project of IS adaptation in the context of the internationalization of a French credit company [Rolland02]. This paper reports the critical application of the complementary use of MAP and BP models to analyze change, as suggested by the methodological framework. The case study is the one of the re-organization of SCS, a Swedish repair workshop, and adaptation of its IS. The purpose is to draw from this qualitative evaluation lessons on the approach effectiveness and to raise efficiency issues. The actual efficiency of the approach will be evaluated later on in a series of quantitative evaluations. The next section, presents an overview of the proposed methodological framework, and introduces how the critics was achieved during the case study. Section 3 reports the process followed in the SCS case study of IS adaptation with the methodological Framework. Section 4 presents the critics raised and lessons learned during the case study. On-going research activities are synthesized in the concluding section.

2. The methodological framework for enterprise change based IS adaptation This section presents an overview of the methodological framework, presents the MAP meta-model and the BP modeling technique used during the case study, namely EBML. The last subsection defines the approach taken to evaluate the framework. 2.1 Overview of the methodological framework The purpose of the framework is to provide an integrated understanding of the complementary roles played by IS analysis and design, BP modeling, and enterprise goal modeling in the scope of studying the impact of enterprise change on IS. Its theoretical foundation lies in Lewis’s three-step model of change [Lewis98]. According to Lewis's three steps model enterprise change creates a movement from an existing situation to a new one. The model indicates that change is about de-freezing the current situation of the enterprise, implementing change, then re-freezing the enterprise in a stabilized situation consistent with its desired form. While change is being implemented, the enterprise passes through a collection of different liquefied or transient states [Conradi94] [Nanda96]. In a similar way, our change framework assumes a discontinuous perception of change. The enterprise and IS are not considered as perpetually changing, but seen as in a sequence of stable situations alternated by change achievements. This is shown in Figure 1 where As-Is and To-Be models are differentiated from Liquefied models. As-Is and To-Be models can be specified using the same concepts or meta-models [Jackson95]. However, whereas As-Is models describe indicative properties, i.e. perceived phenomena of the current situation (before de-freezing), the purpose of To-Be models is to describe optative properties of phenomena as they are foreseen in a future situation (as desired after re-freezing). Specifying the liquefied models is useful to ensure a correct transition from the current situation to the future situation [Nanda96]. However, to implement this transition it is necessary to understand the difference between the As-Is and To-Be. We propose to describe these in Gap models. Such gap models propose a collection of gaps which, assuming that change is not large scale or radical, specify transformations to apply to parts of the As-Is models to obtain the corresponding To-Be models. A typology of gaps is proposed in [Rolland02] to guide the specification of such models.

Enterprise's Environment Business Goals Forces

Business Processes

As-Is

Gaps

Interaction To-Be Individual

Liquefied

Fig. 1. Basic building block of the change framework

The literature provides a wide range of levels at which specify the As-Is models, To-Be models and Gap models. Depending on the concern, one can for instance differentiate the individual level to study the internal properties of the enterprise’s actors, from the interaction level at which the primary concern is the interface between actors, or the differentiate BP level to focus on the flows and organization of activities from a business goal level to understand the enterprise’s goal implemented in BPs. Different formalisms can be used to focus on each level. For example, Entity/Relationship models, Object Oriented diagrams, State-Transition diagrams, are often used to specify individually the internal properties of an Information System and other kinds of actors at the corresponding level. The interface between actors can be modeled at the interaction level with Message Sequence Charts, Use Cases, or Scenarios. As Figure 1 shows, the framework’s basic building block applies at any of these levels. The literature quotes different reasons for undertaking enterprise change and IS adaptation: aspirations [Lodin98], motors of change [Ven95], opportunities [Yu99], sources of change [Weinrich93], etc. These change forces result from ‘abnormal’ situations (issues, problems) resulting from a mismatch between the enterprise’s goals, its BPs, its IS and/or its environment. Change forces are a source for new requirements calling for change facilitators. Gap modeling is proposed as one of these. To summarize, the framework has six main characteristics: • it integrates multiple perspectives provided by different modeling techniques, • it organizes analysis according to levels of abstraction, • it proposes to use MAP at the enterprise goal level, • it uses a discrete definition of time and differentiates As-Is, To-Be and liquefied situations, • it uses gap models to specify the difference between As-Is and To-Be, and • it defines change forces as driving change. In the remainder, we will focus on two 'upper' levels of the framework, namely the BP level, and the business goal level. At the BP level, models define the sequencing of events occurring in a business. The business goal level focuses on the purpose and rationale of BPs. The framework suggests to use MAP at the former level, whereas it should be possible to use any BP meta-model - EBML in our case study. The next two sub-sections respectively introduce the concepts used in MAP and EBML. 2.2 MAP The purpose of a Map is to identify business goals and how these goals are achieved. An intention is a goal that can be achieved by the performance of a process, and a strategy is an approach, a manner to achieve an intention. A Map is represented as a graph whose nodes are called intentions and edges strategies. The Map meta-model in Figure 2 shows that Maps can be spliced into sections. Any section is an aggregate of a target intention, a strategy and a source intention. Sections identify which strategy to use when one wants to achieve the target intention. The source intention of a section identifies which intention should already have been achieved to go for the section’s target intention with the section’s strategy. It can therefore be considered as a pre-condition. The ordering of intentions through connected sections doesn’t identify a strict sequence. As long a section’s pre-condition holds, its target intention can be achieved. Achieving the intentions of a Map is therefore done in a non-deterministic – but not unconstrained - order. Any section in a Map can itself be described with a Map. This is done through refinement, as the ‘refined by’ relationship of the meta-model shows. Maps can thus be defined at different levels with refinement links

3


between them. However, a Map can refine several sections. This results in a net of refinement links between Maps. For consistency reasons, this net should not contain any loop path. The MAP key concepts and their inter-relationships are shown in the meta-model illustrated in Figure 2. The meta-model is defined in standard UML. in

1

Map 0..*

Path

Thread

Bundle

2..*

Section

1 refined by 0..* source 1

0..*

target

1

Intention

Strategy

0..*

Start

Stop

1

1

Fig. 2. The MAP meta-model

A path is a subset of a Map’s sections respecting the Map definition (i.e. a complete graph of sections including one start intention and a stop intention). Sections can thus be refined by Map paths. Two or more sections can identify exclusive or complementary strategies to achieve a single intention. In the former case they are grouped in a bundle, in the latter case they are in a thread. Thread sections can have different source intentions whereas bundled sections have the same source intention. However, in both case all the sections of the group (whether thread or bundle) have the same target intention. 2.3 EBML EBML is a method for describing BP models with the aim of defining IS system requirements. The EBML key concepts and their inter-relationships are shown in the meta-model presented in Figure 3. The meta-model is defined in standard UML. inherits 0..1

A bstract process

1..* com posed_of

1..*

P rocess D etailed process

3..* 1..*

P rocess elem ent

0..1 includes

P rocess node

S im ple process node 1

1

is_end_of 0..*

P rocess sequence

0..*

B ranching process node start_of

Fig. 3. The EBML BP meta-model

An EBML model contains processes describing the sequencing of events that occur in a business. EBML processes are either abstract or detailed. They are composed by a set of process elements ordered with sequences and branching positioned between a start node and end node. Abstract processes cannot be instantiated, i.e. they do not exist in reality but are useful to define inheritance hierarchies. Indeed, the elements of an abstract process are inherited by its sub-processes. Process elements in a process can be abstract, in which case the process can be abstract itself. A detailed process can inherit its contents from an abstract process. This holds for sequence, branching, as well as for simple process nodes such as: message sending or reception, manual or automated activities performed by actors, waiting states, and timer start or expiration.

2.3 Approach taken to evaluate the Framework Several evaluation frameworks have been developed to provide a basis for studying, analysing and comparing different modeling techniques. For example, the four process perspectives by [Curtis92], and the framework for evaluating BPM and ISM techniques proposed by [Giaglis99]. These were adapted to define criteria for the evaluation of three main hypotheses:  H1: the proposed methodological framework is effective,  H2: the understanding and organization of BP models can be facilitated by the usage of the more abstract MAP modeling technique,  H3: modeling with MAP helps making more complete BP models. Six criteria were defined to evaluate our three hypotheses:  C1. Perspective enlargement: if the introduction of a high level business modeling technique makes the business intentions explicit, then it shall enlarge the process view.  C2. Facilitation: if a model with a simple semantic is used as a starting point, then it shall make it easier to understand the other models.  C3. Model management: if a top-down way of working provides the business rationale for the BPs, then the intentional elements shall be associated to their corresponding operational elements.  C4. Integration: if the modeling techniques used integrate common information elements, such as aspects of why and how, then some level of integration shall be demonstrated.  C5. Time saving: if a modeling technique based on simple constructs is used, then time shall be saved when developing models.  C6. Fitness enabler: if changes external to the Information System are taken into account, then a more effective analysis of the actual system requirements shall be enabled. Certainly, there are other aspects of interest, but we have chosen to restrict the observations with respect to the hypotheses initially made. The experiment was undertaken in co-operation with two experimenters: a MAP specialist and an EBML specialist. At each step of the case study, the list of criteria was used to trigger discussion about the validity of the framework. The evaluation was qualitative and subjective. The lessons learned from the case study introduced in the next section take this into account. In particular they identify specific ways of further investigating the observations made.

3. The Stockholm Central Service (SCS) case study This section briefly overviews the case study with: a short presentation of the SCS company, an abstract of the framework-enabled process applied to analyze change and IS adaptation in this company, and examples of the results obtained during the case study. 3.1 Overview of the SCS company Stockholm Central Service (SCS) is a Swedish company offering overhaul and reparation services of home electronics. In 2001 a decision to re-organize was made in order to solve a number of issues relating to the company’s productivity. The project to change SCS business was undertaken with the aim of improving competitiveness, suppress insufficient response times to customers, and find an appropriate organization of the work structure. The approach initially taken was based on BP modeling. BP models were developed with EBML [Pettersson01] to understand the current business, situate the issues, identify opportunities for change, design the BP models to implement in the future, and locate the impact on the company's IS design. Once the aforementioned activities completed, specifying new requirements for the future IS from BP models was rather straightforward. However, several difficulties were encountered during this initial experience: process models were large and complex, they contained many details making their reading difficult. This made difficult the search of the changes to report on the EBML specifications. Besides, it was difficult to emphasize the gaps between the EBML specifications for the current and future BPs. This was not only due to the complexity of the models, but also because the models didn't differentiate the stable elements of the business (such as important business intentions), from elements more likely to change (such as the different way of working of business actors).

5


3.2 The process applied during the case study A re-play was undertaken based on a combined usage of MAP and EBML as prescribed by the framework. The process chosen had three objectives: (i) make the business intentions explicit with Maps, (ii) facilitate the organization of the models by relating Maps to BPs , and (iii) facilitate the identification the gaps between the As-Is and To-Be models. As Figure 4 shows, a spiral model [Boehm76] was used to define this process. At each of the two levels the process is incremental: each spiral turn in the process complements the output resulting of previous turns. The angular dimension of the spiral represents the stage of process completeness whereas the radial dimension of the spiral indicates the progress in the production of increments. Gap Analysis

Sections Marking

Section Refinement MAP level Gap Analysis

Process model Integration

Process model Production EBML level

Fig. 4. Overview of the process applied during the case study

Figure 4 shows that a turn of the spiral at the MAP level is due to section refinement. It is only when no further refinement is needed that movement from the MAP to the lower EBML level occurred. In other words, the movement between levels resulted from a decision related to every section in a Map: either the To-Be section was understood enough to move to the EBML level or it required further intention-driven analysis at the MAP level. The latter necessitated a new intentional turn to refine sections whereas the former generated a spiral turn at the lower level of the hierarchy. Thus this movement established a dynamic link between sections at the MAP level and the corresponding fragments at the EBML level. A detailed description of SCS and the initial EBML change project, of the gap analysis process, and of the SCS Map models can respectively be found in [Pettersson01], [Rolland 02], and [Salinesi01]. The following reports some of the gaps discovered with Maps and their impact on the EBML BP models. 3.3 Examples of results By integrating the Map model and adapting the hierarchical spiral model proposed as the way-of-working with the gap analysis presented in [Rolland02], we were able to align BP adaptation to SCS’s intentions changes. About 20 Maps were developed in the case study (the experimenters evaluated that a full scale analysis would have brought about the triple). For the sake of space, all Maps are not reported here but interested readers can refer to [Salinesi01]. An illustrative example of MAP gaps as well as their impact on a corresponding EBML model is presented below. The example represents the Map stating how to Manage the customer relationship by processing the customer service requests at SCS, and the EBML process model Reparation.

Start

without apparatus at the customer

Estimate the cost of reparation service

by mail by customer deposition

by delivery of units

by SCS picking-up apparatus

by customer refusal by examination of apparatus

immediately by prerequisite testing

Stock apparatus

by several phases, without testing

Execute reparation

by replacement of apparatus

by delivery of unit

by deposition at the customer

by customer withdrawal

by mailing

by disposal

Stop

Fig. 5. The As-Is Map Manage the customer relationship by processing the customer service requests at SCS

The Map in Figure 5 identifies that in the current situation, processing customer service requests involves ‘estimating the cost of a reparation service’, ‘stocking apparatus’ and ‘executing reparation’, which correspond to the three intentions in the Map. There are four different ways of ‘receiving an apparatus’, each relating to different types of stock located in different places at SCS. Therefore, stocking can be done following one of the four corresponding strategies. A reparation cost estimation achieved for apparatus not stocked is either done ‘at the customer’s’ or done ‘without the apparatus’ at hand. These are the cases for SCS external home service and routine issues solved by telephone. In all other cases the ‘cost estimation’ is done with the apparatus at SCS, which can take place either before the reparation starts, during the reparation or after the reparation is finished. Reparation is achieved independently from cost estimation. Any apparatus in the stock can be repaired either ‘immediately’, ‘preceded by tests’, or ‘in several phases without tests’. After a reparation is finished, the apparatus are put back in stock. The service ends up either by returning the apparatus in ways corresponding to the four ways of reception, or by customer refusal. If the customer refuses the quotation although the apparatus has already been repaired, it is either disposed or returned to the customer. Figure 6 illustrates the As-Is EBML process Reparation. Due to readability reasons, the labels for each process entity were changed to numbers. The process elements corresponding to the Map are described below. 2.1.1 Reparation process (TV, Camera & Other apparatus) SoS

SoS

Engineer

20.4

20.2

20.3

20.1 non-terminé

aucune devis AND aucune enreg.de status AND aucune enreg. de signature

aucune enreg. de signature AND aucune enreg.de status aucune devis SoS

SoS

Devis

SoS

Devis

Start

1

2

3

5

4

6

7

8

aucune enreg .de status

12

11

10

9

13

15

14

17

devis approuvé

18

19

Besoin de commander des pièces

aucune enreg. de signature

20 terminé

aucune erreur découvert, le test est refait SoS

eurreur périodique (Télé)

4.1

4.2

4.3

4.4

devis non-approuvé: eurreur découvert OR cassez l ’appareil aucune eurreur découvert, stop test

SoS

4.5

4.6

4.7

4.8

4.9

4.10

4.11

Commande de l ’ordre

16

Commande de l ’ordre

18.1

18.2

18.3

délivreur (service externe)

39

33 SoS

21

22

SoS

23

signature non-fait

SoS

24

25

service non-externe

SoS

26

Contact clientèle

devis approuvé OR retour sans mesure AND service non-externe

Devis

41

revendeur OR fournisseur AND téle

42

43

client privé

44

45

46

47

service externe

34

27

40

service externe (Télé)

devis non-approuvé: retour sans mesure

Contact clientèle

35

36

37

38

Devis

si la signature est fait avant

28

29

30

devis approuvé OR retour sans mesure AND service externe

31 cassez l ’appareil

Revendeur OR fournisseur AND autre appareil

32 client privé (pour poster) délivreur de clients directs

48

49

51

Fig. 6. The As-Is EBML process model representing Reparation

For the sake of space, Figure 6 only visualizes the control flow of the reparation process, i.e. the ordering of messages received and sent (which represents the interaction with other actors and processes), and the ordering of the process activities. More specifically, the SCS reparation process is characterized by three types of

7


reparations indicated by the three different process sequences following the first decision point (no. 4 in the Figure). They correspond to the three strategies to achieve the Map intention Execute a reparation in Figure 5. The reparation activity is then followed by a number of messages, activities and other decision points. These put conditions on whether the responsible engineer has made a quotation, signed and updated the status of the service order in the IS or not. Depending on the engineer, this routine is not done at different points in time This is indicated in the As-Is EBML model by the loop from decision point 20 to box 3 . The EBML process model in Figure 6 corresponds to the 3 strategies to achieve the intention Execute a reparation in the Map model. Therefore, any gap on this intention or on one of these strategies can have an impact on the BP. The gaps between the As-Is Map of Figure 5 and the corresponding To-Be Map (shown in Figure 7) are identified in Table 1. The table defines gaps on intentions and strategies. Different kinds of operation scan be applied on these [Rolland02]: merging, splitting, adding or removing an intention or a strategy, or changing the source or target of a strategy. Gaps are thus organized accordingly in the table. Operator Intention Strategy 1. Estimate the 1. without apparatus and at the customer into without stocking Merge cost of a reparation service and Execute a reparation into Repair an apparatus

Split

Chang e origin

Remov e Add

2. by delivery of units and by customer deposition into collective stocking 3. by mail, by SCS picking-up apparatus and by customer deposition into individual stocking 4. immediately, by prerequisite testing, by several phases without testing and by replacement of an apparatus into by prerequisite quotation 5. by delivery of unit and by customer withdrawal into collective stocking 6. by mail, by delivery to customer and by customer withdrawal into individual stocking

1. Stock an apparatus into Receive an Apparatus and Return an apparatus 1. by disposal source intention to Repair an apparatus 2. without stocking target intention to Receive apparatus 3. collective stocking target intention to Receive apparatus 4. individual stocking target intention to Receive apparatus 5. without stocking target intention to Return apparatus 6. collective stocking target intention to Return apparatus 7. individual stocking target intention to Return apparatus 1. by examination of an apparatus 2. by customer refusal 1. by invoice

Table 1. Example of gaps found on the Map Manage the customer relationship by processing the customer service requests at SCS

Table 1 shows that each of the As-Is Map intentions have been either merged or split. This relatively radical change is due to the underlying requirement to strengthen the process-oriented organization [Davenport00] [Hammer96] at SCS. More specifically, in order to change the current focus on separate functions such as stocking and repairing towards a process-oriented organization, the intention Stock an apparatus was split into two new intentions, Receive and Return an apparatus. This split was also a result of the need to change radically from ineffective stocking strategies to more rationale ones. Furthermore, the As-Is Map defined cost estimation and execution in two individual intentions: Execute a reparation and Estimate the cost of a reparation service. The corresponding BPs were indeed separate, and as a result the customer could reject a quotation although the reparation was already started or even finished. Merging these intentions into Repair an apparatus identifies the interdependency of the two. The underlying decision was to merge the corresponding BPs instead of keeping them independent. Therefore, the strategy by prerequisite quotation was introduced as the only strategy to achieve this intention. This gap identifies that the underlying To-Be process should avoid the ill-defined ordering of reparation and quotation handling, which caused interrupted and in the end costly reparations. The impact of these gaps on the changes to perform on the current BP is multiple. First, two well delineated fragments of process should be defined, one for quotation and the other for reparation. Second, the links between those should be changed : there should not be any loop from the latter to the former, and there should be no way to reach the latter without passing by the former. In order to comply with the previously identified gaps, two steps were taken to define the future strategies for reception and return of apparatus. Firstly, the ineffective strategies for stocking apparatus were merged into the strategies collective, individual and without stocking. In the second step, their origins were changed in order to correspond to the new intentions as indicated in table 1. Another important aspect of the gaps reported here is the introduction of the termination strategy by invoice. Indeed, it appeared that in the current situations not all reparations ended up in a payment. On the contrary, the To-Be Map identifies that if the customer rejects the quotation, then no repair is achieved and no payment is

required. If the quotation is accepted and the reparation is realized, then the invoice should be delivered. The underlying BP should reflect these constraints by tightening the links between these three aspects of the business. by collective stocking Start

without stocking Receive an apparatus

by individual stocking

by prerequisite quotation

without prerequisite quotation by collective stocking Return an apparatus

Repair an apparatus without stocking by individual stocking

by invoicing

by disposal of apparatus

Stop

Fig. 7. The To-Be Map Manage the customer relationship by processing the customer service requests at SCS

The impact of the gaps found at the Map level onto the BP level is multiple. For example, the merge of the intention Estimate the cost of a reparation service with Execute a reparation into the new intention Repair an apparatus, and the introduction of the new strategy by prerequisite quotation in the Map model caused the removal of 7 decision points, 4 send messages and 1 whole process sequence. By removing the decision points (no. 4, 4.3, 4.5, 5, 10, 20.1, 20.3 in Figure 6), the send messages (no. 4.4, 4.6, 20.4, 22) and the process sequence (no. < 25; 26; 27; 28; 29; 30; 31; 32>) the processes for quotation handling and reparation respectively became strictly sequential: the Map strategy by prerequisite quotation now requires a quotation before the reparation can take place. This allows consistent quotation handling and eliminates interrupted reparation processes due to customer quotation refusal. Most of the gaps reported here had not been identified in the initial case study. This has an impact on the enterprise organization, but also on the design of the IS required to support the BPs. While analyzing gaps and looking for their impact on BPs, critics were raised. The next sections sums up our findings in terms of lessons learned about the framework validity, and need for further investigation.

4. Lessons learned from the case study The analysis is based on the evaluation criteria used to criticize the application of the framework during the case study. The conclusion made for each of the six chosen criteria is reported in the corresponding next subsection. 4.1 Perspective enlargement The comparison of the represented level of abstraction reveals that Maps are adequate for reasoning about the business level. They help exploring the business space and making the business vision explicit. In SCS, Maps helped understanding the business intentions, which were recognized in EBML but were not as clearly stated. By clearly defining the objectives, the Maps helped completing the BPs. As a result, the initial focus on stocking apparatus enlarged to a wider vision of the entire order process. In other words, reasoning about the higher business level widened the focus, helped stating the SCS business objectives, strengthened the process view, and helped making the EBML processes more complete. The same was observed in a former industrial project, in which the Map/gap approach was applied to understand required IS adaptations [Rolland02]. 4.2 Facilitation In contrast to the difficulties encountered when directly specifying the To-Be EBML models to search for IS requirements, the Map models appeared easy to read and to analyze. Due to their complexity and level of detail, the EBML models made it more difficult to analyze the current situation and look for changes. For example, analyzing the “big picture” of a collection of related processes in EBML required not only the analysis of individual and detailed process models, but also the analysis and structuring of many separate models. In Maps,

9


it is easier to get a general overview, without developing many models. Again, this confirms our former observations. To give an order of magnitude, the models and schemas representing the information system, composed 2000 screens and 150 relational tables with about 40 attributes per table. In contrast, the top-level Map included 5 intentions and 13 strategies [Rolland02]. 4.3 Model management The case study showed that a top-down way of working where the business goal level is considered first provides the business rationale for models on the operational level of BP model description. For example, by the application of the refinement mechanism proposed by the hierarchical spiral model for gap analysis we could associate the section with fragments in the corresponding BP, the EBML process Reparation. Thus, the framework seems to be able to facilitate the management of models on different levels. However, one can argue that model management was made easier because the As-Is EBML process models already existed. Besides, the experience shows that MAP and EBML can be effectively used together, but the use of MAP with another process modeling languages could not be as effective. Managing Maps in addition to the other existing models, could thus become more difficult. We believe that this difficulty can be overcome by a careful management of the links between models. 4.4 Integration Maps define business intentions and the ways to achieve them. Different ways of working can be represented by associating strategies to each intention. On the contrary, in EBML the modeling objective is to describe the dynamics of businesses in processes. This include different ways of working represented by interleaved fragments of BPs. Once again, the level of complexity may have increased since more models need to be linked to each other. However, the intentions in Maps and process names could naturally be assimilated, and strategies could be linked to process fragments. These two elements of integration facilitated the analysis of BPs based on the selection of well identified business intentions and strategies. 4.5 Time saving The time taken to construct and develop Maps was considerably short compared to EBML modeling. This observation is based on the modeling of a set of high-level Maps, including a maximum of three levels of refinement. All together this took about five workdays. To model the corresponding BPs originally took about double the time. The case study showed that although time consuming, Map modeling was significantly faster than BP modeling. Besides, in terms of the amount of knowledge and understanding of the business gained, Maps appeared to be superior to the EBML expert. Therefore, BP modeling time could be saved if Maps are developed first. We believe this observation needs further quantitative evaluation. In particular, the overall amount of time and knowledge gained by the combined use of Map and EBML could be evaluated in an empirical study. 4.6 Fitness enabler The case study showed that, compared to a pure BP modeling approach, Maps help making more rationale and creative design decisions by helping to initially avoid unnecessary details, such as technical details of the IS, as proposed by the framework. This finding coincides with Giaglis’s argument [Giaglis99b] that one way to achieve IS fitness for use, is to guide high-level IS design by BP modeling and leave the technical details of IS design and implementation as consequences of BP change decisions. Giaglis shows that this approach has two advantages: • it ensures that the focus on the alignment of organizational and IS structures is always maintained, thereby allowing business managers to assess the organizational impact of structural and informational changes in an integrated fashion, and • it drives the complexity of designing detailed IS structures out of the process change endeavor, thereby allowing decision-makers to concentrate on organizational rather than technical factors when designing and evaluating changes[Giaglis99b].

4.7 Summary of the lessons learned The lessons learned from the SCS case study can be summed up as follows: (i) the proposed methodological Framework is effective, although some aspects must be improved; for example a collection of relationships between levels might help guiding gap analysis, (ii) the understanding and organization of BP models is facilitated by the usage of the more abstract Map models focusing on business intentions; the time saved and amount of knowledge gained must however be demonstrated by a series of empirical evaluations, (iii) modeling with Map helps making more complete BP models, but the efficiency of Map modeling for BP models completion should however be compared to other approaches. The approach taken for the case study contains some inherent drawbacks that must be made explicit to put our lessons learned in perspective. First, the case study was based on known facts about SCS. The company did not take part in the Map modeling phase. This, of course, impacts our findings regarding the amount of knowledge gained and time spared by using Maps before modeling BPs. We believe our claims can be, at least in part, substantiated by an experiment in which our approach is applied independently from the traditional BP modeling approach. As to the methodological framework itself, the definitions of the As-Is, Liquefied and To-Be models are still only grounded on theory, even though it is a traditional approach to perceive change (even in the industry). The question whether the corresponding situations occur might however be raised. To this point in our research program, we have not been able to find a suitable alternative definition of enterprise change and IS adaptation. An interesting angle to our findings is that EBML models were to a large extent absorbed in the definition of individual IS functions and requirements for the IS itself. The case study revealed that this phenomenon, called “reductionism” [Giaglis99], tended to be overcome by Maps which helped stressing the understanding of the actual business prior to making design decisions about the IS. The case study also revealed that although BP modeling could gain from higher level models such as Maps, there was no actual synergy between the two approaches. [Warboys94] argues that it is essential if one aims at a “synergy effect” to use different modeling techniques in integration. We believe such an integration could be obtained by introducing in the framework a collection of formal links between the models used at different levels. Formally defined between the meta-models, these links might for example guide the discovery of inconsistencies, or help systematizing the research of the impact of gaps found at one level on the models at a lower level. Contradictions to the hypotheses were also found during the case study. First, the framework assumes a topdown analysis strategy. However, the experimenters found it difficult to put in practice the idealistic view of a fully top-down process. They started by describing Maps at intermediate level before going onto a higher level. Different levels of refinement were treated in parallel, making the consistency between level sometimes difficult to maintain. This issue should be solved by more guidance of the initial Map development, for example, our experiences with industrial project showed that patterns could be re-used n high level Maps. In addition, we found that BP modelers had some problems with understanding the non-deterministic ordering of intentions in Maps. This conflicts with the facilitation criterion (C2), since this caused problem with readability at the beginning of the experiment. This can be explained by the dominance of a culture of deterministic process modeling techniques based on descriptions of process elements put into sequence. Our experience showed us that people more used to thinking in term of intentions had less difficulty to understand how to use Maps. Therefore, we believe this issue can be solved by increasing the public awareness of the intention-oriented paradigm. In an actual project, training and case studies development can be a first step in this direction.

5. Conclusions The challenge of the enterprise change–based IS adaptation framework is to bring business intention design, BP design and IS design together without adding to the already high complexity of each individual approach. The approach taken is the one of a decomposition of the problems into levels of analysis. At each level, two time horizons are considered, and the gaps between models specifying these looked for. Such an approach has two main advantages: • it ensures that a focus on the alignment of business intentions and strategies, business processes, and IS structures is always maintained, thereby allowing business managers to assess the organizational impact of structural and informational changes in an integrated fashion, and • it drives the complexity of designing detailed IS structures out of the process change endeavour, thereby allowing decision-makers to concentrate on organizational rather than technical factors when designing and evaluating changes. [Giaglis99b]

11


A method based on the proposed framework was experimented with the re-organization of Stockholm Central Service (SCS), a Swedish company offering overhaul and reparation services for home electronics. The need to change the company was caused by competitiveness issues, insufficient response times to customers, and an inappropriate working organization. The approach adopted was based on MAP models, EBML BP modeling, and gap analysis. The originality of the approach stands in the abstraction of business intentions and strategies prior to detailed BP modeling. While achieving the activities of modeling the business intentions, the current BPs, and the gaps with the corresponding To-Be models, observations were made to criticize the proposed framework. The critics related to six criteria chosen to confirm, invalidate and put in perspective issues about the hypotheses made on the framework. The case study gave some interesting clues about the effectiveness of the framework. For example, it showed that a better knowledge of the problem domain could be gained by modeling at the goal level, and that the resulting BPs could be more complete, hence the designed IS more adequate to its future use. These findings are however still very subjective and need to be confirmed, for example by empirical experiments comparing intention modeling with MAP and other approaches. Besides, several difficulties were encountered during the SCS experiment: the integration between multiple models is not clear, reasoning about intentions and strategies is less easy than reasoning about sequential processes, adopting at once a top-down attitude is not as easy as the framework and process used might let the user think. Several threads have been undertaken in our research program to better consider these issues. They include in particular the development of a typology of links between MAP and BP modeling techniques, and the creation of training material to guide the process and undertake further experiments.

References [Anton94] Antón A., McCracken M., Potts, C.: Goal Decomposition and Scenario Analysis in BP Reenginering. In: Wijers, G. et al.: (Eds.). Proceedings, Conference on Advanced Information System Engineering, CAiSE '94, Utrecht. LNCS 811, pp. 94-104, Springer-Verlag, Berlin, June 1994. [Boehm76] Boehm, B.: Software Engineering. In IEEE Transactions on Computers, Vol. C-25, No. 12, 1976. [Bubenko98] Bubenko J., Brash D., Stirna J.: EKD User Guide, Elektra Electrical Enterprise Knowledge. Department of Systems and Computer Science, University of Stockholm/Royal Institute of Technology, Sweden 1998. [Conradi94] Conradi R., Fernstrom C., Fuggetta A. : Concepts for evolving software processes. In A. Finkelstein, J. Kramer, and B. Nuseibeh, editors, Software Process Modeling and Technology, pages 9--31. 1994 [Curtis92] Curtis W., Kellner M. I., Over J.: Process Modeling. Communications of the ACM, 35, 9, USA 1992. [Davenport 00] Davenport, T. H.: Mission Critical. Harvard College, USA 2000. [Fathee98] Fathee M.M., Redd R., Gorgas D., Modarres B.. The Effect of Complexity on BP Reegineering: Values and Limitations of Modeling and Simulation Technologies. Proc. Of the 1998 Winter Simulation Conference. D.J. Meideros, E.F. Watson, J.S. Carson, M.S. Manivannan (eds). 1998. [Freeman91] Freeman M., Layzell P.: A Meta-Model of Information Systems to Support Reverse Engineering. Information and Software Technology, 36 (5), pp. 238-294. 1991. [Giaglis99] Giaglis G. M.: On the integrated Design and Evaluation of BPs and Information Systems. Communications of the Association for Information Systems, Volume 1, Article. Department of Information Systems and Computing, Brunel University, UK, June 1999. [Giaglis99b] Giaglis G. M.: A Taxonomy of BP Modeling and Information Systems Modeling Techniques. Department of Information Systems and Computing, Brunel University, UK 1999. [Hammer96] Hammer, M. Beyond Reengineering. Harper Collins Publishers, USA 1996. [Jackson95] Jackson M.: Software Requirements and Specifications. Addison-Wesley, 1995. [Jacobson94]Jacobson, I., Ericsson, M., Jacobson, A: The Object Advantage: BP Reengineering With Object Technology. Addison Wesley, Wokingham, 1994. [Jaeschke93] Jaeschke P., Oberweis A., and Stucky W.: Deriving Complex Structured Object Types for BP Modeling. In P. Loucopoulos, editor, Proceedings of the 13th International Conference on the EntityRelationship Approach, Lecture Notes in Computer Science, pages 28--45, Springer-Verlag, Manchester, United Kingdom, December 1993. [Lewis98] Lewis P., Goodman S., Fandt P.: Challenges in the 21st Century Management. South-Western, 1998. [Liles96] Liles D. H. and Presley A.: Enterprise Modeling within an Enterprise Engineering Framework. In Charnes, J.M Morrice, D.J Brunner, D.T, and Swain, J.J (Eds). Proceedings of the 1996 Winter Simulation Conference, San Diego, California, USA. December 1996. [Lodin98] Lodin S.: Intrusion Detection Product Evaluation Criteria.http://citeseer.nj.nec.com/lodin98intrusion.html, 1998. [Nanda96] Nanda A.: Implementing Organizational Change. Internal Report. Harvard Business School. USA 1996. [Nosek90] Nosek J.T and Palvia P.: Software Maintenance Management: Changes in the Last Decade. In: Journal of Software Maintenance, Vol. 2, No. 3, p. 157-174, 1990. [Pettersson01] Pettersson P. and Wäyrynen J.: Verksamhetsmodellering med EBML. Department of Computer and Systems Science, University of Stockholm/Royal Institute of Technology, Master Thesis, Sweden 2001. [Pettersson01b] Pettersson P. and Wäyrynen J.: Verksamhetsöversikt – Stockholm Central Service AB. Department of Computer and Systems Science, University of Stockholm/Royal Institute of Technology, Internal report, Sweden 2001.

[Potts97] Potts C.: Fitness for Use: The System Quality that Matters Most. REFSQ'97: Third Int.Workshop on Requirements Engineering: Foundation for Software Quality. Barcelona, Spain: June, 1997. [Rolland98] Rolland C.: A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE’98, B. Lecture Notes in Computer Science 1413, Pernici, C. Thanos (Eds), Springer. Pisa, Italy. June 1998. [Rolland02] Rolland C. and Salinesi C.: Business Driven Software Adaptation: An Industrial Experience. Submitted to RE’02, Tenth International Conference on Requirements Engineering, Sept 2002. [Salinesi01] Salinesi C. and Wäyrynen J.: Business Maps Presentation of Concepts and Illustration with the Stockholm Central Service (SCS) Case Study. FTR&D internal report, project ”Objectifs d’Entreprise et Système d’Information – Réflexion Conceptuelle et Cadre Méthodologique pour l’Analyse de Changement”, France 2001. [Ven95] van de Ven A., Poole M.S.: Explaining Development and Change in Organizations. Academy of Management Review (20:3), 1995, pp. 510-540. [Warboys94] Warboys B.: Reflections on the relationship between BPR and Software Process Modeling. Informatics Process Group (IPG), Department of Computer Science, University of Manchester, UK 1994. [Weinrich93] Weinrich, H. & Koontz, H. : Management: A Global Perspective, McGraw-Hill, 1993. [Yu99] Yu E.: Strategic Modeling for Enterprise Integration. Proceedings 14 th World Congress of the International Federation of Automatic Control, July 5-9, 1999, Beijing, China.

13
