2.2    VPT -- Creation of Value Across Borders

VPT is an abbreviation for "Verdiskapning på Tvers" in Norwegian, which roughly translates into "Creation of Value Across Organizational and Disciplinary Borders" in English.

2.2.1 Background and objectives

The VPT project was initiated and run during autumn 1994 as a pilot project under the auspices of the Statoil Research & Development center. The overall objective of the project was to suggest new projects that could reap the potentials of people cooperating across organizational and disciplinary borders. The project initiators had the impression that suboptimization was a problem in the organization and that a more holistic view of the business processes potentially could improve profitability.

Enterprise modeling was suggested as a means to develop a shared and holistic understanding of the main work processes. Based on the models and the knowledge held by the project participants, propositions for new projects were to be made.

The study of the VPT project was conducted as direct observation in three out of six project meetings, discussions with the project leader, document study of the project proposal and finally, investigation of the enterprise model (an artifact, Yin, 1989:94).

2.2.2 Enterprise models

A main outcome of the project was an enterprise model describing work processes, products and organizational boundaries of the Statoil corporation, from petroleum resources in reservoirs to markets for the various products. A simplified version of the final model is provided in figure 2.2. The simplifications consist of leaving out some flows, names of lower level processes, and no color encoding.
 
Figure 2.2: Enterprise model developed in the VPT project

The diagrammatic language used for modeling is described in figure 2.3. Resource refers to petroleum reservoirs in the ground. Market is a description of who buys what, i.e., a combination of customers and the products they buy. Product is the outcome of a process. Organizational boundary describes the relation between process and organizational unit responsible for the process. Flow means either information flow or material flow (liquids or gas) from one process to another. Both organizational boundaries and flow had additional color encoding, denoting specific organizational units or types of flow, respectively. Resource, market and product also had different fill colors.

Figure 2.3 Modeling language used in the VPT project
(fill color or line color in parenthesis)

The modeling language was developed more or less on the fly as a part of the project, and tailored to their particular needs. Understanding of both syntax and semantics was expected to be intuitively grasped by the project team members.

Processes were decomposed into subprocesses (only two levels, as can be seen from ). Diagrammatically, the subprocesses were written inside their associated aggregate process, together with products output from each subprocess. The market was also decomposed into submarkets according to customer and product.

When the core processes had been identified, organizational boundaries were drawn as thick lines with different colors (boundaries are not included in ). As a consequence, processes where several business units were involved or depended on each other could easily be identified as potential areas for further investigation. Those areas were candidates for cooperation across organizational boundaries.

2.2.3 The project organization

The project team was comprised of ten experienced Statoil employees. The actors had both a general overview of business areas and more specialized knowledge from specific domains. Other employees within the company were used to provide input on specific issues.

Most participants had engineering background and were selected based on their domain knowledge, not on their modeling experience. Neither time nor other resources were spent on training the team members, so modeling was performed based more or less on intuition or previous experiences (previous experiences have not been studied).

2.2.4 The enterprise modeling process

The project team did not have any explicitly agreed upon method to follow for enterprise modeling. What to do was decided more or less on an opportunistic basis and depending on the needs identified during modeling. E.g., if someone felt they had little knowledge about a particular area, a discussion was initiated, or someone were assigned responsibility for acquiring more information for the next modeling session.

An observation concerning process was the explicit recognition of modeling as a creative process. In the project proposal, one of the project objectives was to

"learn to use creative processes that support holistic thinking in the project."
The group met every 14 days for about 3 months, spending almost one day on each meeting. Most of the work related to information collection was done in periods between the meetings, while modeling was performed collectively in meetings. Results were presented and discussed during meetings. Discussions were necessary to develop a sufficiently common understanding of all model elements.

The models were printed on large A0 sheets of paper (84 cm x 118.5 cm) and used to focus discussions during meetings. The team sat around the diagrams and sketched with pencils or pointed with their fingers to argue for their views upon elements of the model. After each meeting, the models would have lots of ideas scribbled all over, and one person was responsible for updating a computer-based version drawn using the ABC Flowcharter software (MicroGrafx, 1996). Computerized tools were not used during meetings, as computers were considered to introduce "noise" in the creative modeling process.

The enterprise model from VPT became immensely popular in the organization for a period of time. About 400 copies were made and distributed to employees asking for them from all over the organization. However, they only received the models, they did not get the rationales or more extensive explanations of the diagrams (except possibly orally). Hence, they did not get the background for various abstractions or contents of the various "boxes". When the project leader asked some receivers of the model how they used the model, they answered that they used it in discussions concerning overall dependencies in the organization.

In addition to the enterprise model, a few examples were suggested to illustrate how working across organizational and disciplinary borders could improve performance as compared to traditional ways of working. The examples were also used to suggest new projects, as VPT was only a pilot.

2.2.5 Problems and particularities of VPT

One issue that was recognized as problematic concerned the division between information and matter. The model in incorporates both physical flow (both liquids and gas) and information flow. It was decided to focus on physical flow as the backbone of the model and add information flow on top. The project leader stated in retrospect that
"we started with the physical process, there were none who would quarrel over that."
Hence, it was recognized that team members disagreed upon details of the model, but disagreement was perceived to be least on material aspects (i.e., flow of material products). The alternative solution of developing different models for flow of material and information was discussed, but not pursued.

The project team also developed a product breakdown structure, showing how raw petroleum resources (the well stream) are split and transformed into more refined products. Only a few of the participants knew the complete product split in advance. The product breakdown accompanied the model in .

Another problem that was encountered during the modeling process concerned the modeling language. One of the project team members stated:

"I find it difficult to be creative using those boxes and arrows. I feel more comfortable with icons."
The person did not feel free to express what he meant using the language elements of . Instead, he suggested using the value chain as outlined in as an initial approximation and extend it as the project team developed a more sophisticated understanding. However, his objections were not considered serious enough to change the use of language.
Figure 2.4 Alternative value chain

A prominent feature of the alternative value chain is that it only describes physical artifacts (and, implicitly, their associated functionality). The model does not describe work dominated by information. In addition, it consists of only a few elements, all being familiar to the project team. However, the alternative value chain was not used extensively, as it was seen as too simplistic to be able to represent all the required processes.

One of the objectives of the project was to suggest changes for the R&D center in order to match their research portfolio to core enterprise processes. Hence, the project team tried to develop models representing work at the R&D center. This was experienced as difficult. The diagrams contained a number of activities, but there were no natural sequence, i.e., no natural flow of information or physical products. A research process was seen as an example of creative work and difficult to model.

Model accuracy was also considered problematic: Being able to represent the whole Statoil corporation on one single sheet of paper required massive abstractions. Hence, accuracy suffered, as the general situations became the norm and all exceptions were discarded. Accepting this inaccuracy was problematic for some team members.
 

The analogy between an enterprise model and a map was proposed when discussing accuracy: In e.g. orienteering maps, there are deliberate inaccuracies. The orienteering maps have a message to convey to the reader, and in order to ensure that the reader understands this message, exaggerations are used. When a steep hill is mapped, the contour lines are drawn even closer than they ought to be, to make the reader notice the hill.
An observation made concerning the practical use of models was as a means to focus discussions. Enterprise modeling enforced a structured way of thinking. The processes and the products functioned as pegs on which issues under consideration could be hung. Hence, they structured the enterprise modeling process and the related discussions.

A final observation was the number of inconsistencies and obvious incompleteness of the model, e.g., there were processes without input generating output, and information flows obviously lacking. However, this did not seem to affect the use of the model, as the human interpreters somehow filled the gaps themselves. Relationships in the diagram were assumed implicitly where lacking. It was evident that the knowledge held by each of the actors was important when discussing the models (the greater part of the knowledge was not in the model, but held by the actors).
 

Looking at the model in figure 2.2, there is not any input to the "marketing and sales" process. The model can be considered incomplete, as marketing and sales in reality rely on information from both the markets and processes.