The main objective of the project was to create a software tool that would enable any employee (and in particular, decision makers) in the company to investigate relationships between elements of the production chain and consequences of strategic decisions through active experimentation with a simulation model of the Statoil gas business: What happens if we introduce another pipeline between two production units? What if we increase the capacity of a processing plant? What if we introduce another gas storage? Hence, the objective of the project was to create an environment for enterprise modeling, and not enterprise models per se.
A main source of inspiration was the off-the-shelf simulation game SimCity (Maxis, 1996). In SimCity, the player is a city mayor and makes decisions regarding where to locate factories, power plants, police stations, houses, roads, etc. in a city. City income is generated from taxes and invested by the mayor. A set of predefined (but implicit) rules govern behavior of inhabitants of the city: If the mayor collects too much tax, people move and total taxes go down. If she collects too little, there are problems financing public services, like police, fire departments, etc. The underlying rules controlling behavior emerge to the player while playing the game.
The idea of the Gazz project was to develop a similar game for Statoil's gas business. The player could locate various constructs, like reservoirs, production platforms, pipelines, processing plants, etc., and afterwards run simulations showing the dynamics of selected variables, e.g., economic income or production volumes. The purpose was to initiate creative and strategic thinking, and function as a basis for strategic discussions within the company. Hence, even if the game was based on simulation and computation, the stress was put on being a tool for understanding both static and dynamic aspects of the gas value chain. One of the project team members stated:
"We are not going to make a system that do the thinking for people. We are going to get people on the track of something."Investigation of the project is based on observation (taking part in 9 out of 11 project meetings), studies of project documentation (minutes from meetings, foil copies, an evaluation report) and experience with the Gazz modeling tool (being an artifact, Yin, 1989:94). A students project extending the initial version to handle methanol production and sales in addition to gas (PS, 1995) was also looked into.
The modeling language available to the modeler (the player) comprised physical elements of the production chain. Each element had a set of predefined attributes associated. Attributes were mainly related to physical capacities and economy (initial investments and operating costs) and could be adjusted by the modeler. Figure 2.6 provides a sample snapshot from the modeling tool interface. The vertical bar at the far left contains all main elements:
Each element in the model had a parameter sheet associated, with predefined default values. In this way, simulation could start with as little effort as possible. Each simulation could be saved as a scenario and compared to other scenarios to see how strategic decisions would influence the overall gas value chain. The behavior of enterprise models created in Gazz is deterministic, i.e., with an identical initial state and a given stimuli one will always get identical response. Hence, the game metaphor was not exploited to the fullest extent (there were no random events).
Requirements to user competence depend upon intentions of playing the game. If the purpose is to uncover the underlying rules of the game, accurate knowledge of cost parameters and capacities is not vital. Hence, one may experiment with various values and learn about qualitative properties of the models. However, if the player wants to compute correct quantitative values, detailed knowledge of actual parameters is required. The original purpose of Gazz was the qualitative aspect, i.e., to make sense of the underlying rules, not necessarily compute accurate values.
Another observation is that enterprise modeling in the Gazz project in effect was divided between the project team and the end user (the player): The project team developed a tailored, restricted language for the end user to utilize when modeling. The language was tailored in the sense that elements of the language are well known, concrete objects to anyone working in the petroleum business (e.g., platform, pipeline, processing plant). It was also restricted, as the different element types and their attributes were defined in advance, they could not be extended. The end users were only allowed to change parameter values, not add element types or parameters.
The project team used several concrete examples in their internal discussions. The examples illustrated different scenarios in which holistic thinking improved the overall solution as compared to sub-optimizing alternatives.