initially by the change vision holders is non-operational, we call it objective. The way it is formulated can not be established through appropriate actions under ...
A way-of-working for change processes Colette Rolland Professor in Computer Science, Selmin Nurcan and Georges Grosz Assistant Professors, Centre de Recherche en Informatique, University Paris 1-PanthéonSorbonne, France. Centre de Recherche en Informatique Université Paris 1 - Panthéon - Sorbonne e-mail : (rolland, nurcan, grosz)@univ-paris1.fr Introduction This paper presents a way-of-working to support the process of change from current business processes to new business processes in an organisation. The need for change is stated as a vision. The change process is about transforming the vision into a new organisation model. Many informations of different types will be captured and manipulated during the change process. The way-ofworking we propose identifies four key elements of the product (the desired output) manipulated during the change process : 1. The goal set represents the objectives assigned to the new system. 2. The organisation model set represents the plan(s) to meet objectives. 3. The scenario set illustrates how an organisation model achieves the goals. 4. The deliberation set regulates the process by providing a mechanism for organising the issues that arise in the change process, the answers provided and their rationale. We look at the change process as a decision making process and recognise five major types of decisions that we describe in the following. Organising and guiding the change process The five decision classes 1. Acquiring goals in their contexts. The change process is driven by the goals for change. Goals are high level objectives of the business organisation. They capture the reason why a change has to be performed and why a new system is needed. Goals guide decisions at various levels during the change process. A goal as expressed initially by the change vision holders is non-operational, we call it objective. The way it is formulated can not be established through appropriate actions under the control of one or several agents. For instance, «any book request has to be eventually satisfied» is an objective in the context of a library system. Decisions for acquiring, situating and classifying objectives have to be made during the change process. They result in the creation and description of objectives in the goal set. 2. Operationalising goals. We propose to distinguish objectives and operationalised goals. As opposed to an objective, an operationalised goal is an objective which can be fulfilled through operations performance. An operationalised goal can be formulated in terms of objects, actions, state transitions, events available to some agent in the organisation. For instance, «limit the borrowing period» is an operationalised goal which is fulfilled by state transitions such as : «Return book» and «Fine late borrower».
The new system must satisfy operationalised goals and satisfyce objectives. Decisions have to be made in order to reduce objectives into operationalised goals. We call this reduction process operationalisation. Operationalisation is the process of successively refining non-operational goals with enough detail so that their sub-goals have an operational definition. Operationalising decisions are not trivial. Several operationalisations can implement the same objective. In some way, the best operationalisation decision has to be made. Operationalisation decisions lead to the creation of operationalised goals in the goal set. 3. Generating organisation models. Organisation models implement operationalised goals. They are expressed in terms of objects, events, actions, and the like. Several organisation models can implement the same operationalised goal, just like several alternative programs can implement the same specification. The decisions for generating organisation model are not trivial and again there is a need for deciding which is the «best» organisation model implementing the operationalised goal. Those decisions lead to introduce organisation models in the organisation model set. 4. Validating organisation models through scenarios. The description of actions, events, state transitions and objects resulting of «generating organisation models» do not guarantee that the operationalised goals obtained by decisions of the operationalising goal class will be met. We propose to use scenarios for validation purposes. 5. Setting and resolving issues. The change process goes on through dialogues between the change engineers, the vision holders and the stakeholders involved in project. It can be viewed as an iterative process of discovering (or creating) issues and resolving them. As a matter of fact, the issue set facilitates the feedback mechanism that supports the exchange and arguments of view points, ideas, concerns, etc.. of the participants involved in the change process. Decisions have to be made to identify issues and arguments in order to rationally resolve them. Decisions of this class manipulate the deliberation set in the product. Organising the change process Decisions of the five classes are not made in a linear fashion during the change process but are intertwined. Setting an issue may occur at any moment in the process ; resolving this issue through discussion and argumentation does not necessarily immediately follow its setting. Obviously, there is a logical order to be followed between some decisions. For example, an operationalisation decision can not be made if the corresponding acquiring decision has not been made. But it would too restrictive to force, for example, all acquiring typed decisions to be made before making any operationalisation decision. In order to provide flexibility in the decision making process, we propose a spiral process model for change engineering which leads to an incremental production of the product (goals, organisation models, scenarios, and deliberation set). As illustrated below, the angular dimension shows the degree of completeness achieved by the current process for change. The radial dimension shows the progress that has been achieved .
The spiral view of the change process
As we mentioned before, there exists an ordering constraint between decisions of the four decision classes (acquiring - operationalising - generating - validating). Integrating this constraint in the visualisation of the spiral view of the change process results in a hierarchy of spirals as shown in the following diagram. The hierarchy of plans reflects the logical ordering constraint of the identified decision classes. Every spire in a plan might have several spires in the descendant plan which represent the succeeding steps of decisions of a class X performed as sons of the same father decision of class Y. The hierarchy of plans models the ordering constraint, the spiral movement means a relaxed completeness constraint on decisions made.
Acquiring goals
Level 1
Operationalizing
Level 2
goals Generating design models
Level 3
Level 4
Validating design models
The spiral view of the change process integrated in the hierarchy of decision classes Guiding the change process We stem from the need for guidance and heuristics based advices for initially capturing goals and discovering organisational models which meet these goals throughout goal operationalisation and scenario based validation (1 & 2 & 3 & 4). Our ultimate goal is to provide prescriptive advice to the practitioner in the form of goal identification heuristics, reusable patterns for goal decomposition and refinement and a set of recurring questions to guide the change process. The entire way-of-working should be based on a library of method chunks. We propose a situation and intention based description of prescriptive guidelines that we call method chunks. An intention can be fulfilled in different ways depending on the situation being considered. A method chunk is organised around the notion of context as a pair situation-intention and tells us how to proceed in this situation to fulfil the intention (5 & 6). The structure of a method chunk reflects our contextual view of the change process, i.e. both situation and intention driven. Any time a change engineer is faced to a given situation to which he/she looks with a certain intention/goal in mind, the library of method chunks should provide the appropriated guideline. As a matter of fact, it exists some steps during the performance of the change process which are grounded on knowledge (7). There is first, heuristical knowledge which partly constitutes the know-how of change engineers. Secondly, an engineer may try to reuse knowledge independent of any particular domain but specific to change engineering. Finally, when an engineer has to solve a new design problem, he/she could structure his/her reasoning by looking for alternative ways to solve the problem or by decomposing the problem into smaller problems. This type of knowledge is fully generic and not tailored to change engineering. Decision making might require emergence of ideas, exploration of choices, argumentation of various alternatives and perhaps deliberation among the stakeholders involved in the process. The generic guidance takes these aspects into account. The corresponding method chunk is applicable in situations where the two other types of guidelines do not hold. We identified thus three different types of guiding knowledge : domain specific knowledge, change specific knowledge and generic knowledge (8). Those are associated to three sets of method chunks stored in a library in order to provide guidance during the change process performance. The three sets correspond to three types of guidance which can be related to the levels of abstraction introduced below. Process meta-model Process model (way-of-working) Process
Generic guidance Change specific guidance Domain specific guidance
Relationship between the different types of guidance and the abstraction levels We have developed a software environment called « MENTOR» (9) for providing guidance as explained above. The library of method chunks is progressively extended as our experience in performing change processes develops. Conclusion To sum up, the process model of change suggests an incremental production of the product (the new organisation model among other things) through cooperative decision making. It has two major advantages : it makes change traceable and it helps stakeholders in the change process to share awareness by making the product under construction being discussed, visible and explicit. The suggested way-of-working makes the change process iterative as described by the spiral movement in the hierarchy of decision classes. In addition, the sequencing of steps is not fixed a priori. Steps are dynamically following one the other. The dynamicity is brought by the structure of method chunks describing the guidelines for change processes. In fact, the underlying contextual view allows the change engineers to switch from one context to another depending on new happened situations and changes in his/hers intentions. This approach is currently being applied in the context of the ESPRIT project ELEKTRA (10) for reorganising electricity companies and designing new organisational structure meeting the EEC new requirements. This work is partly supported by the EEC through the ESPRIT project ELEKTRA (N° 22927) in the context of the framework 4 programme References (1) Dowson, M., Fernstrom, C., "Towards requirements for Enactment Mechanisms", in Proceedings of the 2th European Workshop on Software Process Technology, 1994. (2) Potts, C., "A Generic Model for Representing Design Methods ", in Proceedings of the 11th International Conference on Software Engineering, 1989. (3) Anton, A., "Goal-Based Requirements Analysis", in Proceedings of the International Conference on Requirements Engineering, ICRE '96, IEEE, Colorado Springs, Colorado USA, 1996. (4) Rolland C., "Understanding and Guiding Requirements Engineering Processes", invited talk, IFIP World Congress, Camberra, Australia, 1996. (5) Rolland, C., Souveyet, C., Moreno, M., "An Approach for Defining Ways-of-Working", in Information Systems Journal, Vol. 20, No 4,1995. (6) Nurcan, S., Rolland, C., "Meta-modelling for Cooperative Processes", in Proceedings of the 7th EuropeanJapanese Conference in Information Modelling and Knowledge Bases, Toulouse, France, 1997. (7) Rolland, C., Prakash N., "Reusable Process Chunks", in Proceedings of the International Conference on Databases and Expert Systems Applications, DEXA'93, Prague, 1993. (8) Rolland, C., Nurcan, S., Grosz, G. , "Guiding the participative design process ", in Proceedings of the Association for Information Systems 1997 Americas Conference, Indianapolis, Indiana, 1997. (9) Si-Said S., Rolland C., Grosz G. : «Mentor : a Computer Aided Requirements Engineering Environment », in Proceedings of the 8th CAiSE Conference Challenges In Modern Information Systems, Heraklion, Crete, Greece, May 96. (10) ELEKTRA consortium, " Electrical Enterprise Knowledge for Transforming Application ", The ELEKTRA project programme, 1996.
CRI 0/5/84 00:00 Commentaire: : ELEKTRA is an ESPRIT project (N° 22927) founded by the EEC in the context of the framework 4 programme
