9.2    Outline of the Pool of Techniques

Each technique is presented according to the same scheme: First, a brief outline of the technique is provided, followed by an example of how it was or could have been used (mostly taken from the technology strategy project). Each section is closed by reflections upon the role and importance of the technique as a part of the pool.

The setting of each technique is assumed to be a project meeting in the enterprise model development phase, as outlined in chapter 8.

9.2.1    Brainstorming

Brainstorming is a widely known and used technique for creation of a number of concepts associated with a specific theme.

Overview of brainstorming

Although there are a number of variants, the core of every brainstorming approach is to arrive at a set of concepts from a general theme or question. Laird (1978:142) points out that a success criterion is to avoid discussions or critique concerning content during creative generation of ideas. It may be tempting to argue against or question the meaning of a term proposed by other participants, but the session leader ought to ensure that the creative process does not halt or break down.

There is no required input or preparations to a brainstorming session, except for the general theme. The output of a brainstorming session is a set of concepts that someone somehow associate with the theme. The terms that have been proposed usually have to be discussed in plenary after a brainstorming session in order to investigate more closely or explain what was meant (this post-processing can be viewed as a sense-making process). New terms may be added during post-processing.

An example of usage

Brainstorming was used successfully in the strategy project. An illustrative example of usage occurred in WS2. The 34 participants wanted to discuss drivers related to the development and use of technology in the oil and gas business. One of the participants, a trained facilitator, suggested brainstorming. Hence, the theme was "technology drivers in oil and gas business".

In addition to the facilitator, a scribe was appointed. In order for all actors to participate, the facilitator proposed taking turns around the table. Each participant was allowed to propose maximum three drivers and then call for the actor at the right-hand side to propose more drivers. They went three rounds around the table and closed the session by allowing all actors to contribute freely.

Terms were written on large Post-It notes and hung on the wall for all participants to see. All in all, 103 technology drivers were proposed. The terms were then discussed briefly one by one before categorizing them (see section 9.2.3 on concept clustering).

The role and importance of brainstorming in Tema

Brainstorming is the most unrestricted and creative activity of Tema, and can be seen as complementary to more rational deduction of concepts. The resulting concepts may in a sense be seen as input to other techniques.

Brainstorming may be particularly useful in a modeling session when the communities of knowing have strong and conflicting perspectives, as it transcends the rationality of a single community of knowing. Consequently, brainstorming is considered a prime technique in the pool.

9.2.2    Term characterization

The purpose of term characterization is to make terms meaningful by describing them in various ways. Term characterization is proposed as an alternative to definitions.

Overview of term characterization

A term characteristic is a set of statements that each partially convey the meaning of a term. The statements may take many forms:
Statements can be either negative or positive. A positive statement asserts that something is, while a negative statement asserts that something is not
To describe the term technology as a tool is a positive statement, while stating that technology does not have feelings is a negative statement.
A weakness compared to traditional definitions might be that a list of characteristics will be more voluminous than a definition. However, when using a medium like World Wide Web, lists of characteristics may be hidden from the user until explicitly requested. Hence, they will not force increased amounts of information on the user.

An example of usage

Term characterization is not a technique that has been observed working, but is proposed as a practical approach to face the problems of defining a terminology as observed in TEK-S. Hence, the example used here is hypothetical.

An example from the technology strategy project is the term core competence. Core competence was defined by the process group as

"combinations of different technologies, skills, work processes, synergies and attitudes that together represent Statoil's unique traits and that provide Statoil with competitive advantages."
Figure 9.1: Sample term characterization of "core competence"

Recall that definitions were developed to answer the call for unambiguous understanding of important terms. Observations from the project indicate that usage of the term core competence was not significantly more precise after the definition had been developed (assertion 11).

Term characterization of core competence might have resulted in figure 9.1. The last bullet is taken from the strategy project, as they used the metaphor of a taxi driver to see the difference between basic competence and core competence (see section 6.6.4 for discussion of metaphors).

The role and importance of term characterization in Tema

A characterization is more powerful than a definition as it may also describe the context in which a term is used. The meaning of a term or a phrase has been argued for as being context sensitive and more or less local to a community of knowing. Perceived meaning is also depending on the audience's pre-understanding, and a term characteristic offers more flexibility when attempting to make sense of the term.

Term characterization may also have the property of handling disagreement more elegantly than definitions (if that is considered preferable compared to resolving the disagreement).

The importance of term characterization as a technique depends upon the state of the perspectives that are involved. If the term already is established as a part of the perspective of a community of knowing, the importance may be less than if distinct communities of knowing who all uses the term may seek to come to agreement or if the term is new within the perspective.

9.2.3    Concept clustering

Concept clustering is to create categories from an initially unstructured set of concepts, resulting in a number of labeled groups with concepts as elements. One purpose is to reduce the number of concepts, another is to understand the concepts better.

Overview of concept clustering

Singh (1994) refers to similar artifacts as affinity diagrams, indicating that concept clustering in a sense is to group concepts that have a small conceptual distance (i.e., have some resemblance).

The project group must have visual access to all concepts simultaneously and be encouraged to create categories based on their perception of resemblance between concepts. What constitutes resemblance between concepts is difficult to assess in general, but one advice is to seek categories that are established in the business domain or within the company (i.e., a part of the professional language).

Irrespective of the categories that are created, one ought to at least briefly discuss why the categories have been created, i.e., the underlying rules, properties, prototypes, etc. that have been used for introducing distinctions. Time-consuming controversies over categories and obviously artificial categories may be expected. Allowing concepts to belong to several categories simultaneously may reduce the conflict.

An example of usage

Concept clustering was observed in the strategy project, proceeding brainstorming on technology drivers. The facilitator encouraged the project group to propose categories based on the concepts written on the Post-It notes. At first, actors were a bit reluctant, but when they grasped the essence of the technique, the first categories came quite naturally (e.g., natural conditions as a category with deep waters and small fields as technology drivers). When a category was proposed, a sheet from the flip-over was hung on the wall with the name of the category, and Post-It notes with concepts belonging to the category were moved to the flip-over sheet. Figure 9.2 illustrates a small portion of what was developed in the strategy project.
Figure 9.2: Sample categories from the strategy project

The outcome of concept clustering of technology drivers was 13 categories, each having from 2 to 16 elements. Most of the categories had around 8 concepts, and some of the concepts belonged to several categories.

An observation was that in order to handle all elements, one have to connive at minor inconsistencies or allow obvious inaccuracies at times. Otherwise, disagreements over clustering of concepts might have consumed far too much time. The final few categories tended to be artificial and were created just to allocate the last concepts. The rules used in concept clustering were not discussed.

The role and importance of concept clustering in TEMA

Concept clustering corresponds to Lakoff's (1987) notion of categorization. According to Lakoff (ibid.:5),
"Categorization is not a matter to be taken lightly. There is nothing more basic than categorization to our thought, perception, action, and speech. Every time we see something as a kind of thing, for example, a tree, we are categorizing."
Lakoff (ibid.:xiv) warns against the objectivistic stance that categories are inherent constructs of the world, incorporating all phenomena that have some specific set of properties in common. In his view, categories are not given by nature, and they are also based on prototypes and a host of other mechanisms for associating concepts with categories. Categorization will not be discussed in more detail, except for pointing out that constructing them is not necessarily easy, and there is no single "correct" set of a categories to choose from.

Categorization is fundamental in any perspective making process, as it restricts the way phenomena are perceived. In the Universe of Research, the use of the OPPO approach to structure discussions and presentations in this thesis have also made reality look like being comprised of objectives, products, processes and organizations.

9.2.4.    Dependency analysis

The purpose of dependency analysis is to investigate how various concepts are related and influence each other. A prerequisite is a set of concepts, and output is a dependency diagram or matrix.

Overview of dependency analysis

There are several variants of dependency analysis, but the main idea is to describe how one phenomenon is or may be influenced by other phenomena (positively or negatively). Dependencies are depicted as arrows from one element to another element in dependency diagrams, and may be annotated by plus or minus signs for positive or negative covariance, respectively.

Senge (1991, 1994) refers to dependency diagrams as causal loop diagrams, as they describe cause-and-effect relationships. Causal loop diagrams are fundamental to the whole discipline of system dynamics as discussed in section 4.9. Although the system dynamics community focus mostly on computer simulation (translating the causal loop diagrams into a set of differential equations, i.e., transforming from qualitative relationships to quantitative relationships), dependency analysis is considered to be most valuable as a qualitative tool with the perspective on enterprise modeling taken in this thesis.

A fundamental claim made by Senge (1991:81) is that dynamics of reality are best represented in terms of causal loops, i.e., as phenomena being mutually interdependent instead of linear cause-and-effect. Most systems are perceived to be controlled by feedback. Hence, dependency diagrams may often exhibit loops. Guidelines for performing a dependency analysis can be found in (Senge et al., 1994:178).

Boland and Tenkasi (1995) refer to similar diagrams as cognitive maps and argue for their usefulness as boundary objects. Singh (1994) refers to the same artifact as an interrelationship digraph. Hence, the technique has many proponents and is widely used.

An example of usage

Dependency analysis was not observed in the strategy project (nor in any of the other projects), but problem situations were observed where the technique might have been useful. An example is the discussion of technology drivers: Among the 103 different technology drivers, there were a lot of interdependencies.

Figure 9.3 provides a dependency diagram including a few of the technology drivers as it could have been developed in the strategy project. Starting with one of the concepts, one may produce a story line out of the diagram:

"If the water is deep in allotted areas, we do not have sufficient technology. Without sufficient technology, we extract little oil. When we extract little oil, the amount of oil produced – and sold – is low. When the amount of oil is low, our income is low. When our income is low, we have no money to invest. With little money to invest, we can do no research. Without research, we do not improve technology. And so on…"
Figure 9.3: Example of dependency diagram of a few technology drivers (technology drivers are boldface)

Creating dependency maps is not simple, although reading them is. One problem is to find appropriate concepts. A guideline is to look for concepts that can be considered levels, i.e., that can increase and decrease.

The role and importance of dependency analysis in Tema

Eden (1992:261) discusses the role of cognitive maps as devices for reflection upon and actual change of the modelers understanding of some phenomenon. The act of articulating both concepts and perceived relationships is described as a
"cathartic experience which provides 'added value' because it changes thinking"
Eden's views are consistent with the hermeneutic stance that the interpreter's horizon is changed by interpretation. Dependency diagrams hence play a role in perspective making. Also, Boland and Tenkasi (1995:362) argue for cognitive maps as boundary objects, playing a role in perspective taking.

Still, dependency analysis as a technique is not considered absolutely vital in Tema, as other techniques also involve similar activities (e.g., QFD).

9.2.5    Quality Function Deployment (QFD)

QFD is a technique aimed at ensuring quality in product development by focusing on customer requirements. However, the technique can be adapted for other purposes as well.

Overview of QFD

QFD (Hauser and Clausing, 1988; Nilsson, 1989) is essentially a technique for decomposition of objectives and products to meet the requirements of a customer: What are their requirements (our objectives) and how do we meet them? figure 9.4 provides an illustration of a generic QFD diagram, or house of quality, as it also has been denoted (Hauser and Clausing, 1988:63).
Figure 9.4: Overview of a generic Quality Function Deployment diagram

Input to a QFD analysis is a number of high level requirements or objectives, the Whats. These are met by a number of Hows and can be argued for according to a number of Whys. The Hows can be interdependent, giving rise to considerations in the "roof" of the house. The Whats and Hows are dependent to various degrees. The How muchs can be used to specify relative importance of various factors. When a set of Whats have been sought met by a set of Hows, the Hows can become Whats in another QFD diagram.

QFD has been reported used within a number of disciplines, like organizational design (Christensen, 1993:78ff), concurrent engineering (Carter and Baker, 1992:62; Singh, 1993) and requirements engineering (but then under the name Software Quality Deployment – SQD, according to Hofmann, 1993:35).

An example of usage

Deliberate use of QFD has not been observed in any of the empirical studies. The assessment of problems and potentials of QFD is based on observations from TEK-S of activities that closely resemble the technique, in addition to personal experience.

In the technology strategy project, all the work groups made assessments of technological challenges to the corporation. The challenges had to be met by technological solutions. The challenges and solutions were ordered in a matrix being a simplified version of the house of quality in Figure 9.4 (only Whats and Hows, and with challenges as Whats and solutions as Hows).

In a meeting later in the development process, one of the process group members exclaimed with a sudden enlightenment:

"But this is a Quality Function Deployment matrix!"
Hence, the QFD technique probably could have been employed in the strategy project to create some of the intermediate artifacts.

The role and importance of QFD in Tema

An original purpose of QFD was to bring various disciplines together in the development of products. Hauser and Clausing (1988:63) state that (italics added)
"The foundation of the house of quality is the belief that products should be designed to reflect customers' desires and tastes – so marketing people, design engineers, and manufacturing staff must work closely together from the time a product is first conceived."
The objective is clearly to involve disparate communities of knowing with their different perspectives in a process of perspective making and perspective taking for construction of an artifact. This artifact might as well be an enterprise model.

QFD is not an imperative part of Tema, although it is a technique that might be effective when breakdown of requirements, objectives, etc. is required.

9.2.6    Deployment Flow Charting

Deployment Flow Charting is a process mapping technique focusing on relationships between roles, activities, products and time. The technique is included here as an example of what a project group might develop as a modeling language. Other examples can be found in the empirical studies (chapters 2 and 6)

Overview of Deployment Flow Charting

Even if Tema prescribes that the project group must develop their own languages for enterprise modeling, they still need to be familiar with a few modeling techniques. They must be aware of some of the possibilities. Deployment Flow Charting is one out of a vast number of techniques for activity mapping. Johansson et al. (1993:209ff) present a number of related techniques.

Singh and Lewis (1995:6) report on successful application in creating large (8 feet by 30 feet) process maps on a wall and allowing actors to communicate using the maps to focus discussions.

The main idea of Deployment Flow Charting is to describe activities and find dependencies between them, either in time or between roles. As will be evident from the example below, strong dependencies between roles (e.g., frequent communication or passing of products) or actors waiting for work (e.g., a serial work process instead of a parallel) are immediately visible on the charts.

An example of usage

Deployment Flow Charting was not observed in any of the empirical studies, but the models created in VPT, PA30 and to some degree in TEK-S bears some resemblance to the charts. To illustrate a potential use, an alternative representation of the first steps of the project plan is outlined in figure 9.5.
Figure 9.5: Example of a Deployment Flow Chart of the strategy project

The plan can be read as follows (names of activities and products are left out due to the size of chart, and the plan is simplified compared to what might have been developed in a real setting):

"The BoT develop a mandate and hand it over to the project group. The project group develop a plan for how to carry out the project, and pass it on to the work groups (so they can start working) and to the BoT for sanctioning. The work groups develop propositions for parts of their assignment and send it to both chief engineers and the project group for comments."

The role and importance of Deployment Flow Charting in Tema

The type of models exemplified by can be found in most empirical studies, and represents the core of the enterprise modeling activity. It is the top-level artifact used for structuring and integration of subsidiary artifacts.

Creation or selection of a modeling language tailored to the purpose of the enterprise modeling project is seen as vital to Tema, and the role of the models as structuring devices has been discussed previously.

However, before creating models in line with Deployment Flow Charts, the project group must have a profound understanding of the domain that is modeled. To construct this understanding is the purpose of techniques like brainstorming, term characterization, dependency analysis and QFD.

9.2.7    OPPO assessments

The purpose of an OPPO assessment is to analyze a task in order to make it simpler to understand and perform.

Overview of OPPO assessments

The OPPO concept is a core element of the Caesar approach to enterprise modeling (section 5.2.4), and has also been used extensively to structure this thesis. In brief, an OPPO assessment is a decomposition of a task into four constituents: OPPO assessments can be applied to a wide range of phenomena, even to analyze itself as a technique. The normative process of OPPO assessment is mainly given by the OPPO sequence: Start with the overall objective, discuss what has to be produced to meet the objective, then the work processes required to produce the product, and finally the organization required to carry it out. However, in practice there are a number of variables that are more or less fixed. E.g., the project group that are to carry out the process can be given. A more iterative and flexible assessment is recommended and necessary.

An example of usage

Thinking in terms of OPPO has not been observed in any of the empirical studies. However, both personal experience (in this research project and as a way to organize meetings) and other accounts of successful use exist (e.g., Christiansen, 1993:64ff). It also ensures that at least these four aspects are discussed properly (in addition to other aspects, whenever appropriate).
Figure 9.6: Example of an OPPO assessment

A plausible OPPO assessment of developing definitions in the strategy project could be as in figure 9.6. To perform an OPPO assessment is experienced to be relatively simple, although reaching agreement upon the contents may not be.

The role and importance of OPPO assessments in Tema

OPPO assessment is in a sense a general-purpose technique that can be applied in a variety of situations requiring an analytical approach. The main role is as an analytical device – a standardized way of systematic inquiry into reality. For particular purposes, it may be extended by more dimensions than the four predefined, but the elegance of the technique lies in the simplicity.

OPPO assessments are not considered to be absolutely necessary in Tema, but are claimed to be highly effective and versatile.

9.2.8    Model explanation

The purpose of creating model explanations is to guide the audience stepwise through an enterprise model and thereby improve their understanding of the model.

Overview of model explanations

The dissemination phase of an enterprise modeling project involves presentation of models. Presentation involves displaying the model to an audience and recapitulating the main elements of the model. The recapitulation plays at least two roles: It provides the audience with a coherent description or story concerning the elements of the model (the model is attributed a sequence), and it conveys additional information that is not available in the model. By model explanation is here meant the description of the model provided to the audience in textual form.

Actors presenting artifacts (e.g., enterprise models) to an audience either prepare a speech in advance or are so well acquainted with the artifact that they easily can account for the meaning. Hence, the explanations called for are already present – either prepared in advance or easily available from the experienced actor. The additional work involved in creating explanations to accompany Web versions of models is assumed to be acceptable.

In a Web version of an enterprise model, the textual explanation can be linked in as a separate document that can be accessed from the model. The explanation may refer back to the model elements. The textual explanation ought to be brief – the main point is not to incorporate extensive amounts of information in one document, but to create a coherent, alternative account of the model. More detailed information can be linked into the textual description, creating more logical layers of explanation (utilizing the medium in a better way than providing one all-encompassing explanation).

Another property of the explanation is that it ought to be visible together with the model, i.e., that reading the model and the explanation can be done simultaneously. A solution is to present the information in two windows and enable rapid switching.

Finally, including the explanation in a Web version of the enterprise model also allows for the author of the explanation to be available for further clarification or discussion. This is may be accomplished either through email or a dedicated Intranet-based discussion group.

An example of usage

Incorporation of explanations into the enterprise models have not been observed in any of the empirical studies. However, this is also the main rationale for including explanations in the pool of techniques: The empirical studies show that the models are simple, while the presentations of them can be extensive. The models were used to structure the presentation, and the main information intended to be communicated was in the oral presentation itself.

A plausible first-level explanation of the gas infrastructure model from the technology strategy project (M3) is provided in figure 9.7. Terms in italics are linked to more extensive and concrete information, to other enterprise models, to exceptions, or to stories that outline an issue in more detail. The above explanation is a brief, coherent description that provide an overall account of the gas production chain. More fragmentary information can be associated with the elements of the model or the explanation, when required.

Figure 9.7: Explanation of enterprise model of gas production (M3)

The role and importance of model explanations in Tema

The role of explanations in general presentations is to make the audience understand the message. The role of explanations in Tema is to ease the perspective taking process by accompanying boundary objects with artifacts that provide sequence and additional relationships in the sense-making process.

Explanations are a central part of Tema, and as explanations already exist when the enterprise models are disseminated, the additional effort of including a simple explanation is assumed to be negligible.

9.2.9    Construction of narratives

The main purpose of constructing narratives is their value as devices for sense-making (Weick, 1995:61). The presentation of narratives is based on Bal's (1985) narratology.

Overview of narratives

The purpose of the current presentation is to point out frequent constituents of a narrative. The purpose is not to attempt to provide a cookbook for how to create narratives. That is neither generally possible, according to Bal (ibid.:7, italics added):
"…these processes are not to be confused with the author's activity – it is both impossible and useless to generalize about the latter."
Hence, the focus here is the more modest mission of outlining a few elements that ought to be included in a narrative.

What constitutes a narrative is easy to recognize, but hard to define. Bal (ibid.:8) presents three ideal characteristics of a narrative text:

  • Two roles can be identified (the narrator telling the story, and an actor being involved in the action).
  • Three layers may be identified – the text, the story and the fabula.
  • The contents of the narrative text is a series of connected events caused or experienced by actors.
  • The layer most relevant to Tema is the fabula – the series of logically and chronologically related events perceived to exist in the factual or fictitious world envisioned by the narrator. The elements of the fabula are events, actors, time and location. Bal (ibid.:42) argues for the importance of time and location in narratives. Time is related to the sequence of events – a chronological arrangement making the contents meaningful to the reader. Weick (1995:129) also stresses sequence (italics added):
    "Sequencing is a powerful heuristic for sensemaking. Because the essence of storytelling is sequencing, it is not surprising that stories are powerful standalone contents for sensemaking." Location is important due to a perceived naturalness of spatial thinking, for imagination of a scene where events take place. Narratives may concern both the Universe of Production (making sense of the domain that is modeled) and the Universe of Modeling (making sense of the modeling effort). Both types of narratives may be recorded and made available to the audience.

    An example of usage

    In the technology strategy project, a number of narratives were created. The Web version of the strategy included a set of examples of how core competencies and technological excellence provided competitive advantages to the company in given situations. Most of these examples were narratives in the sense discussed above.

    Without going in detail, one of the narratives provided a rather heroic account of how Statoil had saved another company from hostile take-over. Statoil was invited to take over the company due to perceived high ethical standards and technological expertise, after a series of events (being somewhat dramatic). The time frame was short – only a few months – and the location is also outlined in the example.

    Although the narratives were included in the Web version of the strategy document, they were not integrated with models or other elements. They were provided "a la carte" – from a menu that was available as a fixed element of all Web pages.

    The role and importance of narratives

    The role of narratives in Tema is as a complement to enterprise models, intended to ease the sense-making process by making elements or aspects of a model more meaningful to the reader.

    The value of narratives is argued for by many authors, including Boland and Tenkasi (1995), Brown and Duguid (1992), and Weick (1995). Narratives are constructed and told independently of Tema, and the important step is to record and use the narratives at least within, but also outside of the community in which is was developed (i.e., in perspective taking as well as perspective making).

    9.2.10    Construction of metaphors

    The purposes of constructing metaphors in Tema are to ease understanding of aspects of the enterprise that is modeled, and to actively explore reality by exploiting the generative power of metaphors (Alvesson, 1993:116).

    Overview of metaphors

    The essence of metaphor is, according to Ricoeur (1978:138), that
    "a word receives a metaphorical meaning in specific contexts within which they are opposed to other words taken literally; this shift in meaning results mainly from a clash between literal meanings, which excludes literal use of the word in question."
    The word that is sought explained by attributing metaphorical meaning is referred to as the principal subject, while the word that is taken literally is called the modifier. From Ricoeur's notion of metaphor one may conclude that the most prominent difference between a principal subject and a modifier is that they are not identical, i.e., being in effect equivalent to what was claimed to be the most prominent characteristic of a model (section 3.3.1). The resemblance between metaphors and models is also noticed by Alvesson (1993:116), stating that formal models can be seen as metaphors.

    For a metaphor to be successful, both the modifier and the relationship between the modifier and the principal subject must make sense (Alvesson, ibid.:119, refers to this relationship as the metaphor). Making sense of the modifier is required in order to gain anything at all from constructing the metaphor. Alvesson (ibid.) is particularly concerned with the lack of focus on the problems associated with modifiers that are too broad to ensure a similar interpretation of the principal subject and proposes the use of second-order metaphors (i.e., metaphors that explain metaphors) in order to narrow the meaning of the original modifier.

    The meaning attributed to the relationship between the modifier and the principal subject is of equal importance. Metaphors function both through highlighting and hiding (Lakoff and Johnson, 1980:10ff). The highlighting part of a metaphor concerns the aspects that are perceived to be similar to the principal subject and the modifier, while the hiding part includes the aspects that are neglected due to perceived inconsistency. By necessity, there have to be hidden aspects in a metaphor, otherwise the principal subject and the modifier would be the same.

    How to create successful metaphors is not attempted prescribed in general, but paying attention to the issues discussed above leads to the following advice:

    Mark and Mambrey (1997), reporting on use of metaphors in the design and introduction of a groupware system, point out that successful selection of metaphors depends upon the users' experience with the modifier, and that with innovative systems, one may experience difficulties in finding an appropriate modifier. This supports the first advice above.

    An example of usage

    The explicit construction and use of metaphors in practice were reported in section 6.6.4 when discussing observations from the technology strategy project. The metaphor "Statoil is a taxi driver" as a means to make sense of the term core competence is an illustrative example of the principles discussed above.

    Taxi driver, being the modifier of the metaphor, was a well known concept to all actors that were intended to be involved in the discussion of core competencies (all actors most probably had extensive experience as taxi customers).

    The aspect that was highlighted when using the metaphor was the concept of core competence, i.e., what does core competence mean to Statoil and to a taxi driver (assuming these to be similar). Aspects that were clearly hidden include the actual core competencies (Statoil does not benefit directly from knowing the city very well or where taxi customers usually are) and other traits, like the driver's weight, hair color, hobbies, drinking habits, etc. Still, if the generative power of metaphors were to be exploited, these aspects could have been highlighted as well.

    Another noteworthy characteristic is that the relationship between Statoil and taxi driver may be open to too many or too few interpretations as compared to the intended ones, i.e., the metaphor might either evoke the "wrong" similarities or make no sense at all. Hence, an explanation of the intended highlighted aspect would be appropriate.

    The role and importance of metaphors

    The role of metaphors in Tema is both to explain and to explore alternative meaning. The explanatory role ought to make perfect sense to the reader, although the explorative might not. Recall that Tema is primarily intended to support modeling of domains that are not well known, i.e., where the constructive, sense-making nature of modeling is more dominant than representation. When modeling is sense-making, the generative power of metaphors may be helpful. Weick (1995:36) stresses the creative, constructive nature of sense-making as well as the interpretive, supporting the call for creativity in modeling. Checkland and Scholes (1990:32) also encourage the deliberate use of metaphors to free thinking as a part of SSM.

    The importance of metaphors in Tema is not equal to brainstorming, diagramming techniques, explanations or reflection, but is still believed to be able contribute significantly to the sense-making process. Recognizing that metaphors are created and used independently of Tema, taking the step to a more systematic exploitation seems reasonable.

    9.2.11    Group reflection

    The purpose of group reflection in Tema is to be able to improve practice and learn from experiences. Reflection becomes vital in a modeling approach that does not prescribe a fixed sequence of steps.

    Overview of group reflection

    Tema prescribes a semi-structured pool of techniques as the means to perform enterprise modeling. Project groups must consequently become competent both in applying the individual techniques and in judging when to use each of them.

    However, in addition to performing the actual enterprise modeling, the project group ought to reflect upon their use of Tema. Figure 9.8 illustrates three levels of activities related to enterprise modeling. The idea is adapted from Engelbart's (1991) discussion on organizational improvement.

    Figure 9.8: Reflection in enterprise modeling

    Activity A in represents the enterprise modeling process, i.e., using appropriate techniques to make sense of the enterprise, to construct models, and to disseminate them to the enterprise audience.

    Activity B involves reflection upon activity A. That is, reflection upon the modeling process in order to learn, improve, correct errors, change, or extend the framework with new techniques, etc.

    Activity C is reflection upon reflection: How do the project group learn from or improve the way they do enterprise modeling? The effect of activity C is improved ways to improve enterprise modeling, e.g., more effective techniques for reflection.

    Taking reflection upon one's own modeling process seriously represents a new danger to the modelers: It means questioning the constraints of the project. In the ideal situation, there is no need to question how the process is carried out. The project group produce the deliverables and reach their goals without dead ends or doubt. However, reflection is necessary when Tema breaks down, i.e., when Tema is insufficient to meet the objectives of enterprise modeling (e.g., if factors outside the scope of this thesis may dominate modeling). Knowing when to work and when to reflect cannot be decided in advance and must be up to the discretion of the project group.

    An example of usage

    Group reflection was not observed as a planned, deliberate activity in any of the empirical studies, but occurred occasionally and more unintended.

    In TEK-S, the M2 method used for developing the strategy was often questioned, particularly when some of the WG actors experienced problems with doing work the way it was planned. This questioning involved reflection upon how to work. However, as the time available to create the strategy was limited, time for proper group reflection upon the method was not allocated.

    Another example from TEK-S was the incidence reported on page , where an actor removed the words key, core, etc., receiving applause from his colleagues. This is an example of how frustration has built up as a consequence of not questioning the actual need for these subtle distinctions in their language. The example also illustrates how lack of reflection might result in more frustration than necessary.

    A final example of the need for reflection can be found in the PA30 project. Initially, the project group intended to set aside one day per week for project administration. However, the day was used differently (Christensen et al., 1995: 1178, italics added):

    "Wednesdays were kept free of interviews. The purpose of this was to summarize the week so far, plan the work for the following week, and discuss upcoming issues in the project. Some days worked according to this intention, but most of the time were used to reflect on the mapping process, questioning the project, method, interview techniques etc. The importance of this was acknowledged…"
    Hence, the need for reflection upon enterprise modeling surfaced naturally in PA30, although it was not intended to be that way. Tema prescribes reflection in groups to be an intended and natural part of enterprise modeling.

    The role and importance of group reflection

    One of the roles that reflection play in Tema is bracketing of assumptions within a community of knowing and thereby improving the perspective making process. Another role is to decide upon what techniques to use in various situations.

    Reflection is considered essential to Tema and is a prerequisite for using the framework at all. Being designed to rely on few assumptions (to retain a high degree of flexibility) leaves many decisions open to the discretion of the user.