The project is the natural setting for enterprise modeling in
Tema. Enterprise modeling is not envisioned as a continuous effort
going on for a long period of time. It is more likely to be used as a means
to develop some other artifact. This view is a natural consequence of a
leaning towards a constructivistic worldview: Enterprise models do not
represent an objective, invariable organizational reality, and the perspective
taken in this thesis is not the "enterprise models as corporate memory"
view held by some proponents (e.g., Prytz, 1995). Seeing enterprise modeling
as dominantly a sense-making process also encourages modeling as an activity
(i.e., to use the metaphor of corporate memory, "enterprise modeling as
corporate memorizer" is more appropriate, in the sense that enterprise
modeling is a means to construct the "memory" of organizational reality).
|The technology strategy project represents a typical setting of enterprise modeling according to Tema: In order to develop and disseminate the technology strategy, they also developed and disseminated enterprise models. Hence, enterprise models were not seen as ends by themselves, rather they were means to meet other objectives.|
A fundamental decision made in Tema is to stress flexibility at the expense of efficiency and predefined support, i.e., to adhere to a non-presumptionistic stance as stated above.
The immediate consequences of a non-presumptionistic stance on the set
of rules for Tema depend on the phase. In the development phase,
Tema advocates a pool of techniques instead of a predefined,
all-encompassing method for enterprise modeling. By a pool of
techniques is meant a pre-selected set of relatively simple approaches
to investigation of problems of limited extent and complexity. That a technique
is simple implies that it consumes little resources and time to master
(although it may require some effort to apply in a specific situation).
Each technique contributes to solving a particular problem or illuminating
a certain aspect, and careful selection of techniques may provide a powerful
"tool box" for approaching seemingly complex problem situations. Applying
the taxonomy of work from section 3.6 on techniques in general, one may
say that with a technique, the form of the product is known but
not the contents.
|Brainstorming is proposed as a technique in the pool. The outcome of a brainstorming might be a set of ideas on a whiteboard (the form of the outcome), even though one can not tell in advance what the ideas are about (the contents).|
An all-encompassing method for enterprise modeling would be stated in terms of a series of steps leading from a perceived problem situation to meeting the objective. Although a method might be iterated, the steps are usually not considered as self-contained and interchangeable.
A set of rules will then provide guidelines for why applying what technique when, in addition to guidelines for other activities that have to be carried out both in the development and dissemination phase.
Turning to the dissemination phase, the immediate consequence of a non-presump-tionistic stance is that even if a few constraints on the dissemination process (in terms of required dissemination activities) are posed, there are no fixed sequence of steps that are assumed to be adequate in all situations.
The empirical studies indicated that project groups may be able to create informal modeling languages on their own as a part of the modeling process, tailored to the specific needs in their project (assertion 13). Consequently, Tema makes as few presumptions as possible about features of the languages. This is also consistent with a claim made by Singh and Lewis (1995:6):
"In any case, the best choice of modeling technique for any organization is the practice most familiar to its teams."If the project group are acquainted with a language in advance, it would be appropriate to use concepts from this language as long as it has expressive power to represent the required phenomena.
|In the strategy project, the work groups decided to describe Statoil's
strengths, weaknesses, opportunities and threats
as a part of the enterprise models. The language concepts were tailored
to their needs.
In the PA30 project, bombs and clouds were used to denote perceived problems and opportunities at the process plant. This was considered highly successful by the project group, and represents the most important information in their enterprise model (as it was used to propose changes at the plant). The process and product aspects played the role of structural background against which the problems and opportunities could be discussed.
A non-presumptionistic approach is feasible when the purpose of enterprise modeling is human sense-making (category I) and not what may be referred to as computer sense-making (category II and III). Hence, proposing to create modeling languages as part of the modeling effort is a direct consequence of the decision made in section 1.2.2 concerning what support: The focus of Tema is human sense-making. Frameworks with a wider variety of purposes may not go for the solution outlined here.
However, in order to develop a modeling language, the modeling group must be aware of the possibilities. They must have an idea what to "choose" from. Choice of language elements is also influenced by the techniques proposed to be a part of the pool of techniques discussed above.
An aspect of any modeling language is the medium used for representation of the artifacts. In Tema, a fundamental decision is to separate between what is the primary medium in the development phase and in the dissemination phase. In the development phase, paper (or equivalents like whiteboard or blackboard) is the primary medium (assertion 12). In the dissemination phase, the primary medium is digital. Hence, paper variants of models may have reduced quality as compared to the original variant. Choosing a digital medium enables a more effective communication process for dissemination of models (depending on the audience's competence in using the medium, assertion 25). Paper is considered to encourage one-way communication with little feedback.
Seeing enterprise models as structuring devices (assertion 16) that may assist the actors as they attempt to make sense of the overall enterprise, guide them to information or to other actors (assertion 18) imposes other requirements on models than seeing them as knowledge bases for querying about all kinds of information regarding the enterprise (as some other frameworks for enterprise modeling do, e.g., TOVE and Enterprise, see chapter 5).