The setting of each technique is assumed to be a project meeting in the enterprise model development phase, as outlined in chapter 8.
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.
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).
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.
|Statements can be either negative or positive. A positive statement asserts that something is, while a negative statement asserts that something is not.|
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."
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).
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.
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.
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.
"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.
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.
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 "
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.
"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).
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).
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 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.
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.
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."
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.
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.
OPPO assessments are not considered to be absolutely necessary in Tema, but are claimed to be highly effective and versatile.
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.
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.
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.
" 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:
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):
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.
"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.
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 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).
"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:
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 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.
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
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.
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.
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.