Content uploaded by Vidar Hepsø
Author content
All content in this area was uploaded by Vidar Hepsø
Content may be subject to copyright.
The Social Construction and
Visualisation of
a
New Norwegian
Offshore Installation
Vidar Heps0
Statoil Research Centre, Trondheim, Norway
vihe@statoil.no
Abstract: This paper exemplifies how to make aggregated descriptions or requirements
of work processes to serve as references or resources for future situated actions in the
operations of a new oil installation It describes a joint organisational and IT-development
process of a CSCW-application that supports personel in their daily preparations for
operations. The paper discusses how the organisational members themselves were
empowered to describe the proper format of representation, with activities, products,
roles,
responsibilities and co-ordination mechanisms in general.
Introduction
An important research issue in CSCW has been to study how collaborative systems
can be instrumental in reducing the complexity of co-ordinating co-operative
activities often individually conducted but yet interdependent (Schmidt, 1996).
CSCW as a field has also been devoted to exploring how computer based systems
can improve the ability of co-operating actors in articulating their activities
(Winograd 1994, Malone 1995) To develop and implement reasonable conceptual
and structural units to express activities, tasks, interdependence and responsibilities
in a flexible and well-integrated manner has been a challenge The problem has
often been that the underlying protocol has been too rigid, not accessible or not
modifiable These protocols have therefore not been able to handle situated actions
(Suchman 1987; 1994, Randall 1995b) and the flexibility and unpredictability of
real life practice.
109
J Hughes el al. (eds),
Proceedings
of
the
Fifth
European Conference
on Computer
Supported
Cooperative
Work,
109-124.
© 1997 Khmer
Academic
Publishers.
Printed in the Netherlands.
110
Nome
is a new oil
production ship being
put
into operations
by
Statoil1
in mid
1997.
This
new
installation
is
different from former permanent concrete
and
steel
constructed giants that
up to now
mainly have inhabited
the
Norwegian
Continental
Shelf.
Nome
has a
very lean organisation, about
1/3
compared
to its
older counterparts Still,
it is the
same functions (production
of
oil)
and
these must
be more efficient
in
Nome
The
Nome onshore support organisation
is
placed
in
Northern Norway, Harstad
In
addition, Nome needs technical support from
centralised Statoil units
in
Stavanger, Trondheim
and
Bergen (500-1100
km
away),
and external vendor support
on
production
and
maintenance from both inside
and
outside
of
Norway.
In
order
to
achieve their goals Nome will have
to
challenge
present work practice
and
develop
new
ways
of
working,
not
only
on the
boat
itself, but
also with regard
to
onshore-offshore co-operation inside Statoil
and
through vendor co-operation outside Statoil.
The
newly employed Nome people
have diverse operational backgrounds from other parts
of the
company
and are
bringing their
old
experience
and
expertise with them into
the new
installation This
past experience
is
vital. However,
it is
important
to
reflect upon
how
Nome
can
improve present practice,
and
there must
be
developed contexts where
new
communities
of
practice
in
Nome
can
discuss
a
potentially
new
practice
In
essence, Nome will have
to
create
a new
operational reality based
on the
potential
and restraints
in
their business context
The new
"Nome reality" will cover more
formal aspects
as
procedures, structures
and
more informal aspects like informal
work patterns, culture
and
attitudes
In this paper
we try to
show
how it is
possible
to
make formal aggregated
descriptions
or
requirements
to
serve
as
references
or
resources
for
future situated
actions
in
operations
A
flowchart method
is
used
for the
purpose
of
planning
the
operational phase
of the
Nome installation, enabling
the
organisational members
themselves
to
describe
the
proper format
of
representation, activities, products,
roles,
responsibilities
and
co-ordination mechanisms
in
general
In
viewing
the
development
of
"structure"
as an
organisational development
or
empowerment
process,
we try to
avoid falling into
the
many traps
of
formal
and
rigid
representations
of
work-flow.
We
will focus
on the
social construction
of
the
new
work processes Further,
how
this organisational development process
was
combined with
the
design
and
implementation
of a
CSCW-application that
supports Nome personel
in
their daily preparations
for
operations. This integrated
approach
can be
seen
as the
process
of
change
of an
organisation,
in
which
organisation
and
technology
are
designed
and
developed jointly
in a
task-
and
need- oriented
way by the
members affected'
e g the
organisational members
affected consider
the
existing problems, search
and
evaluate
the
problems' causes,
and consider measures
to
solve
the
problems (Hartmann,
1994 in Wulf,
1995).
Some features
of the
application will
be
presented including some preliminary
conclusions
on how
this work
has
helped Nome
in
achieving their business
objectives.
Statoil
is the
state
oil
company of Norway Primary activities
are
exploration
of new oil and gas
fields,
operation
and
maintenance
of a
number
of
offshore
oil and gas
production installations, operation
and
maintenance
of
refineries, transportation, marketing
and
distribution
of
intermediate
and end
products
Ill
The Construction of Nome Work Processes
This R&D-project that started in December 1995 had the following scope'
• To help Nome develop their most important work processes in
operations, by acting as facilitators in the Nome organisation, i e.
providing a method for describing work processes and perform
process support during an organisational development process
• Develop a groupware application that would be used as an
operative enterprise model, including an overall description of
Nomes main work processes and products and, down to the daily
checklists in operations, in order to develop some shared
representations of Nomes operating philosophy
As a consequence of the scope, we were to help Nome develop scenarios for
how to use CSCW-applications in operations (groupware and desk top
conferencing systems). For the Nome personel the challenge have been how the
development of a future operational structure or practice can be an organisational
development process where the organisational members themselves describe the
ideal "to be"-situation in operations. In February 1996 we arranged a workshop
with Nome personnel, both managers and operators/technicians. The idea was to
make them reflect on their work processes, start discussing what had been already
described so far in an operating philosophy document, and identify their most
important work processes. We used considerable time to discuss what a work
process was Here we followed a pragmatic BPR-definition (Hammer and Champy,
1993) and defined work processes as a collection of activities that takes one or
more kinds of input and creates an output that is of value to a customer. The main
challenge was to discuss which of the processes did not have any proper products
and customers and question if Nome had to do these activities at all. This
discussion went on beyond that meeting, through the winter of 1996 at all levels in
the Nome organisation, and the end result was an overall enterprise model2 with
the following processes.
Nome has three main physical processes, with defined products There is an oil
reservoir, with special characteristics that contains oil with specific properties.
Nome has a production and injection system that offer you possibilities and
restraints based on its technical construction. There is also a product shipment
process since Nome must export the oil that has been processed onboard to a
market These three main physical processes are the main conditions the Nome
organisation must operate under and comprises their value chain In order to
An enterprise model is defined as a model of what the enterprise intends to accomplish and how, and is a way of
understanding complex social organisation by constructing models (Rumbaugh 1993) Nome defined an
enterprise model as a model of what they want to accomplish and how to function when in operations It contains
basic elements and necessary decomposition of activities, roles and specifies information requirements to
activities
112
Grey > Subprocess/
activity
End product
Intermediate product
Wiite
operate the physical processes in the most effective manner, Nome personnel
developed 16 main work processes. These processes are: operations, maintenance,
modifications, technical support, accomodation (on board), logistics, marine
operations, emergency preparedness, human resource, finance, quality, reservoir
management, health, environment and safety (HES) and procurement, to mention
the most important This model had its weaknesses which we will return to later,
but it enabled the organisation to consolidate on the most important business
objectives
For each of these work processes Nome personel were chosen as process
owners The role of a Nome process owner was to involve other people in the
Nome organisation in order to describe the defined process. The people that were
chosen came from different levels in the organisation, from supervisors to
operators and technicians. However, some supervisors were not "ripe enough" for
the idea. When picking out people we wanted the process owner to be a person
that would be working with the process in operations, who would know the
process and who had basic communication and
facilitator skills When these persons were chosen we
helped them in the process of establishing a facilitator
role for their process We taught them some basic
facilitator skills, how to create involvement, how to
use problem solving techniques and gave them a basic
introduction to our methodology
The methodology is very simple, based on
simplified flowchart symbols and has been used in
Norwegian work research in different versions since
the late 1960's (Thorsrud, 1969). They grey box
(figure 1) signifies the activities within a process (e g.
within maintenance to create a work order) There are
products associated with the processes. For maintenance the end product is
technical condition re-established, while an intermediate product can be a created
work order Linked to products and processes you have information requirements,
e g. to the sub process create work order one information requirement is access to
the plant management system. Finally, there are also dependencies between
processes and products on different scales that can be addressed by using arrows
between the objects Some small changes were done compared to old flowchart
symbols to indicate that we did not deal with technical systems here
These symbols were then combined in order to create the Nome work
processes An example from maintenance shows this more in detail The first
sketches were made on paper in groups. The typical situation like eg,
maintenance, was that the process owner gathered 5-6 of
his
or her people in a full
day workshop to design the overall maintenance process. Here they would discuss
activities, roles, products and dependencies using the above methodology.
Researchers participated as facilitators and assisted when needed Our job was to
follow up the defined processowners, check if they did the work that they
committed themselves to, and help them in their own processes and workshops
Information
requirements
-"- Dependencies/relations
Figure 1. Description of
flowchart symbols
113
We also reviewed the maps to make sure that the processes were not duplicated,
and that dependencies between different processes were taken care of.
Some guiding principles were developed The Statoil division which Nome
belongs to is ISO-certified and the quality system that Nome is part of
will
in most
cases describe work processes good enough for Nome's purpose In cases where
Nome will have to work differently or deviate from the ISO-standard, this will
have to be described in more detail This meant that Nome should use flowcharts
in cases where they felt that going through the work process roles and
responsibilities could give them substantial improvements in performance. Nome
personel decided to describe tasks that they knew they would have problems with
based on earlier experiences, e.g communication onshore-offshore The
constructed maintenance process (figure 2) shows some of the features described.
Figure 2 Flowchart of Nome maintenance work process (principal sketch, simplified)
We will not elaborate this process chart in detail, but describe some important
aspects of it, to illustrate our approach as an organisational development process
The traditional way of describing maintenance in the oil industry is to write a
procedure that regulates activities, and many of these activities must be based on
strict procedures because accidents can have disastrous effects on people onboard
the installation and on the environment. Described here are different roles in the
Nome organisation that take part in the maintenance process, from the different
levels offshore to technical support onshore The more the arrows and the sub
processes passes over the lines, the more bureacratic the process becomes In order
114
to avoid bureaucracy in the maintenance process, Nome decided that most of the
maintenance should de done by the shift teams and operations and maintenance
teams,
with minimum interference from others In the maintenance process, to
write, wait and approve work orders requires considerable time This has to do
with the health hazard, since you must control what kinds of work is conducted at
different locations on the installation However, Nome has taken measures to
reduce their maintenance work orders by 75%, by differentiating between different
kinds of work orders. Much of the maintenance work is rather simple (with no
potential hazard) and can be done by the teams without work orders To be able to
do so they had to design teams based on system responsibilities that can
self-organise, instead of having a traditional disciplinary responsibility. Specific
technicians are given the responsibility to both operate and maintain their defined
technical systems and within that area they have large autonomy The rest 25% of
work orders that is hazardous or requires more skilled expertise must follow an
approval process and involve the control room on the installation and platform
management It took several discussions and iterations before the process found its
final form
The first process maps were written on paper, but as the charts became more
and more described as "finished" by the Nome people, the map was re-drawn in
LOTUS FREELANCE GRAPHICS (graphical slide presentation tool) and
incorporated in a LOTUS NOTES release 3 discussion database (either by us or by
process owners). A simple graphical editor was chosen to avoid creating too
detailed maps. All maps should be confined within one presentation slide (see
figure 2) and cover the overall description of the process. The further discussion
would continue in the group informally When the maps became digitalised it was
possible to create improvement proposals in the NOTES database to every
process. Now, process owners could follow up each others work more simply, and
it became easier to see duplicated work and dependencies that were created Most
Nome personnel had used NOTES before in their former jobs and engineers and
technicians were relatively eager to use the discussion database. The use of
discussion databases was also a strategic decision in order to let Nome personnel
become familiar with electronic work, something they expected they would benefit
from when in operations.
The Groupware Application
A basic premise for the project was to be able to help Nome personel visualise
what a potentially new organisation could look like, and help them to develop
shared representations of such a new organisation. They wanted a Nome overall
enterprise model, a Nome workspace with an intuitive interface to enable Nome
people not only to find the information they need in their daily work, but also to
develop a coherent understanding of what Nome is and its basic work processes.
The intention was that the organisation should co-evolve together with the
groupware application. Processowners and helpers felt that the old release 3 Notes
l
115
database could not do this properly The representations that we called work
process charts or maps (figure 2) were incorporated in a LOTUS NOTES release 4
database Through the use of hypertext/media and "hotspots" we made links to
information and additional computer systems needed in the work processes (since
Nome personnel themselves defined information requirements connected to
activities in their development of the process charts) The point of entry of the
application is a graphical presentation of the overall Nome enterprise model, from
there you can click further down to the different work processes like maintenance
(previously seen in figure 2) The representation of the maintenance process has a
number of "hot spots" with hyperlinks (figure 3). The flowchart itself may not
always give enough information regarding the process. You can see what is hidden
behind the boxes by clicking further down to a more detailed textual description of
the box, start up the plant maintenance computer system, access Statoil
ISO-procedures that regulate maintenance and read electronic copies of
operational manuals, access vendor information on WWW, select small unfinished
maintenance jobs, and write improvement proposals to any of the work processes
Figure
3 A
detail of the maintenance work
process,
where you
can open
more
detailed
information about work orders in
Nome,
read Statoil ISO-procedures on work
orders,
open
the plant management system and write improvement proposals related
to
work orders
116
The CSCW-design and Implementation Process
Our design strategy was to start with an existing system like LOTUS NOTES, to
be able to evaluate the use of the system under real working conditions and see
how the system could improve Nome's work processes along the way, and train
for operations. We decided to use Statoil's existing computer network
infrastructure to minimise technical support during the prototyping process.
NOTES is the groupware standard of the corporation and is widely used in
Statoil, we therefore chose NOTES as the platform. NOTES Release 4 had the
necessary technical flexibility we needed. Nome was appointed a pilot by Statoil
general management and Statoil Data (Statoil's IT-division) made available the
necessary technical infrastructure (NOTES release 4, test servers), NOTES R 4
programming or coding skills and technical support along the way.
The design process closely coincides with a co-operative and constructive
design philosophy (Klockner, 1995) and participatory design (Schuler, 1993).
Evolutionary prototyping approaches presume close connections to participant
situations of use (Schuler 1993, KlOckner 1995). A preliminary groupware
prototype in release 3 of NOTES was used from the start by the process owners
and a core of their helpers. NOTES release 4 was installed in May 1996 and as
much as possible of the activities in preparations for operations were done via the
application, even though it was run in a test environment. Since we were using
standardised software we felt it was our responsibility to tell the users about the
potential of the technology by developing user scenarios. In what possible
directions could the new development move? It was the strategy to view the
groupware application as an "actor" or "actant" with specific values and
perspectives in the process (Latour 1987). Reflection is important when dealing
with standardised groupware, since LOTUS NOTES must be regarded as a
socially shaped technology. Both database structure and the metaphors of paper
based work flow gives NOTES both potentials and restraints in use. Reflection on
these issues was necessary for Nome in order to avoid seeing LOTUS NOTES as
objective and fixed. Any software technology will have embedded categories
whether implicit or explicit, and the aim was to discover, discuss and even accept
the limits of these categories. In order to reduce the importance of the embedded
NOTES categories, we tried to design new categories together with the Nome
organisation, using flowchart symbols that they were familiar with. These are also
categories but are understood by technicians/engineers and make a chaotic social
world understandable for them This is an issue we will re-visit later in the paper
In the Nome case we spent considerable time on fieldwork, to become
acquainted with the Nome people in their own environment. Here we used short
ethnographic fieldworks (Hughes 1995, Randall 1995a; 1995b), workshops with
users,
debnefings and prototyping as methods However, as a contrast to
traditional descriptive ethnography, this was also an interventionist project,
because in Nome we worked as mediators (Okamura et al., 1994)
117
In May 1996 with the introduction of NOTES release 4 Nome had the overall
structure of the application, with the main work processes. We gradually
increased the number of users as Nome recruited new personnel. Changes and
improvements in the application were handled during our weekly fieldworks in
the Nome organisation. Larger changes in the functionality were discussed with
the process owners in summit meetings. Daily support and small changes were
handled informally either via our fieldwork or via the "hot" telephone line directly
to our programmer. The process owners continued to design the flowcharts in
LOTUS FREELANCE GRAPHICS. The old release 3 database was incorporated
as a module in the release 4 NOTES application. Process owners could detail their
maps as they were used to do. When they were finished, they flagged them ready
for transfer. They were imported as bitmaps in the presentation module as a part
of the enterprise model. When this was done the processowner or a helper could
write textual descriptions and link up ISO-procedures to each "hot spot" (or box
defined in the process chart).
From any work process it was possible to create improvement proposals, via a
button at each process chart. Anybody in Nome could give comments to any
process or sub-process. It became the responsibility of each process owner to
enter the improvement proposal module to track proposals regarding his/her
process, and on a regular basis discuss these proposals together with helpers or
other people in the Nome organisation that it might be of interest
to.
The process
owner could dismiss the proposal or implement it directly if it was a small
change, e.g. change in text. If the proposal was complicated and had
consequences for other processes, as the work order example mentioned earlier, it
had to be discussed by management or with other process owners before it could
be implemented. When the process maps had to be changed, the process owner
made the changes in the discussion database module and the programmer
re-imported a new revised bitmap into the presentation module. Improvement
proposals became the first attempt to create a system for continuous improvement
in Nome.
In the fall of 1996, Nome gradually took over more and more of the
responsibility, both for the development and improvement of the work processes
and the maintenance or development of the CSCW-application. A group of
super-users in Nome operations were coached to perform simple maintenance and
improvements on the application. At the end of December 1996 the research
project came to an end and we withdrew, enabling Nome to take full
responsibility of the further development themselves, together with Statoil Data.
A critical reflection on the CSCW-design and
implementation process
In the world of engineers and technicians
flowcharts
are a well-known technique to
describe "system" phenomena and dependencies Over the years this has been a
fruitful method to understand the composition and decomposition of technical
118
systems. There are a number of problems associated with using this machine like
metaphor to understand organisational phenomena Lucy Suchman (1994, 188)
claims that the inscriptions of formal representations of action in technical systems
transforms the debate more clearly into a contest in how our relations to each other
are ordered and by whom, and that those who are committed to an reproduction of
an established institutional order might try to replace the contested moral ground
of organisational commitment and accountability with a scheme of standardised,
universalistic categories, administered through technologies implemented on the
desktop In his answer to Suchman, Terry Winograd (Winograd, 1994) regarding
the critique of speech act theory and THE COORDINATOR, says that no
systematic account can fully capture the richness of mental life, social interaction,
and he claims that the guiding question is not if you have taken account of all
human behaviour, but if you can design to augment peoples capacity to act
We share Winograds pragmatic position, since the main objective was to enable
a flexible structure that was effective for co-ordination within Nome However, the
following structure became as Winograd states (Winograd 1994, 195) not an
imposition of control for authoritarian motives but a necessity for continued
operation, and the question was not whether to impose standardised regimes, but
how to do it appropriately In a potentially hazardous environment like an oil
installation this structure is necessary for continued operation. We also argue that
using or imposing one system of categorisation does not necessarily displace other
possible constructions of the situation Flowchart representations can be used to
pinpoint important issues in the preparation for operations in Nome, but other
aspects must be brought forward in the process of reflection and fieldwork to
cover other issues that this rationale does not envision The post-modern stance of
Gareth Morgan (Morgan, 1986) is important here, that seeing the phenomena from
different perspectives will improve the understanding of the whole A structural
and rationalistic perspective will give a partial but important picture, and human
resource, political and cultural perspectives makes it possible to understand the
setting as a social system, with communities of practice, local knowledge and
inevitable power struggles We need to do as Thomas Malone (Malone, 1995)
argues, learn the art of applying categories well, avoid rigid devotion to a
particular set of
categories,
and find and support useful patterns of interaction
Both Winograd and Suchman agree in their discussion on the fact that
organisational design succeeds when it is grounded in the context and experience
of those who live in the situation. Most engineers and technicians do not have
sophisticated knowledge and vocabulary to address organisational phenomena in
sociological or anthropological terms. If the people themselves should create the
workplace in which they will be working in the future, as is the case in Nome, they
need a "practical" method that makes sense based on their prior understanding of
the world The flowchart with its weaknesses at least enables them to talk about
organisational problems, roles, responsibilities, apparently irrational phenomena,
relations between phenomena and discuss what measures can be taken to improve
the situation This use of "black boxes" becomes useful as what Gregory Bateson
(Bateson, 1972) called "heuristic devices" It is not necessary to know the exact
119
content of
a
black box to have a pragmatic discussion of relations of "black boxes"
at a more aggregated level Even though people interpret the "black boxes"
differently this is less of
a
problem when people come from a relatively joint Statoil
culture and have been working with the same things in operations for years To
describe, discuss the boxes and their content in new communities of practice
enables a better understanding of a new potential operational practice.
As an industrial anthropologist I see the apparent easiness in the use of "black
boxes"
It takes for granted the notion of a systematic world with formal, rational
and structural perspectives of enterprises as techno-economic systems per se.
Organisations not only consist of identifiable system relations, objects that can be
decomposed or substituted, logistic systems and workflow. There is a possibility
that too much focus on these issues will set frames for a "machine"-like perspective
on the world, where the latest fashion depicts the enterprise as a computer like
construction A major problem of such an understanding of the organisation is that
the social system tends to become a "remaining factor" It views the social aspects
as "what is left", that could be put on top of the rational process in terms of
"criterias for success", when all the formal objectives, roles and responsibilities
have been settled
A rational perspective does not address how people in the organisation adjust,
interpret and behave in daily working situations, what Erving Goffman (Goffman,
1961) titled "secondary adjustments" as a response to the formal requirements of
officials and supervisors This rational approach is useless to describe the
development of local knowledge and the importance of communities of practice
As a consequence, it does not show vital social processes in the organisation like,
informal networks, team building processes, intuition, learning and motivational
processes It therefore ignores tacit knowledge and work as a social activity, with
its focus on workflow instead of "the flow of work" To understand the work
context then becomes of decicive importance, and deals with aspects
complementary to the process perspective (Randall, 1995a, 1995b).
Since the Nome organisation was in preparations for operations it was very
difficult to do a traditional workplace study and study Nome people in their real
setting in operations However, we have conducted several shorter ethnographic
studies before on older oil installations (Borstad 1993, Heps0 1997) so we have a
rather clear picture of the "flow of work". The fieldwork that was conducted in
the Nome organisation one or two days every week from February to December
1996,
could only indicate how Nome functioned in its present preparations for
operations
In order to start the discussion on the future organisation of Nome in operations
we chose to use flowchart symbols to describe social phenomena since this was a
way of representing organisational issues that the people in the Nome organisation
both understood and found constructive. Before the project started we discussed
some overall requirements with Nome management and operators/technicians We
agreed to stick to the following premises and address these issues continually
throughout the process if and when they were broken:
120
• Nome wants to remove as many of the detailed procedures as
possible that regulate work offshore, standard Statoil ISO-
procedures that only give minimal requirements will be enough
• Nome have competent personnel on all levels that are eager to take
responsibility, supervision is not an issue
• We will not tell competent people how to do the work they are
skilled to do As a consequence, we make aggregated descriptions
of work flow, and do not go into details
• Automation no, quality of working life yes ..
To summarise, the aim was to make aggregated descriptions or requirements,
and the flowcharts were looked upon as resources for future situated actions in
operations, a general reference for orientation purposes and self organisation In
order to open the "black boxes", we stressed the other aspects through our
participation as mediators in the process description workshops, via informal
discussions with groups and members during our fieldwork days in the Nome
organisation An example of this can be that one of us asks what does this box
contain, like the box "create work order" on figure 2 and 3. The context is an
informal discussion with a Nome process owner and four of his helpers. The start
of
a
dialogue on this issue went like this'
Anthropologist
"Take
a look at
the "create work
order"
sub-process. I
know
from past
fieldwoiks I have conducted that the "bureaucracy" with work orders
take considerable
ume.
You have said that Nome will try to reduce the
number of work
orders
with
75%
How do you
plan
to do
this when you
are in operation, since both
you
and
me
know that it is easy
to
fall back
on old practice ?"
Process
owner:
"You have seen our critenas
to
differentiate between work
orders,
they
are fairly clear However,
I do
agree that
we
have
to do
something more
than just
define
these
critenas,
these things will not happen
by
themselves."
Anthropologist'
"How do
you plan
to do
this?"
Process
owner.
"Good question
i We
have already taken measures
to
present this
way of
thinking
during our
presentation
to new
recruited Nome people Another
idea
is to
live
by
and learn from
the usage
of these principles during our
commissioning phase I think this
is
the only
way we
can make Nome
personnel understand what this really
is
about."
Process owner (Addressing his four colleagues)
"I
want
you
to help
me
plan
how we
can take steps
to live by
these principles before
we come
into operations"
In similar situations the dialogue that developed by discussing the content of the
boxes,
enabled them to discuss roles and responsibilities In essence, it helped the
groups to reflect upon their culture and what should be Nome's "rules of the game"
but not to describe in detail how the work should be done. Our combined focus on
formalism and dialogue uses a double level language (Robinson, 1991) There was
a restrictive formalism in flowcharts and computer representations. Understanding,
interpretations and changing items at the formal level were mediated by
121
conversations on a cultural level, giving power and meaning to the formal
representations We agree with Mike Robinson (Robinson, 1991) that computer
support is valuable in so far as it facilitates the separation between the formal and
the cultural.
It becomes very difficult to describe the methodology that has been employed
here If we are to take Davenports (Davenport, 1993) definition of process design
it will match our work fairly well A holistic approach that looks at most
dimensions of an organisation's activities, take steps to design the future, envision
new work strategies, do the actual process design activity and lastly take part in
the implementation of the change with all its complex, technological, human and
organisational consequences However, our approach also deviates from that of
BPR. We use the concepts of BPR when we talk about defining the value adding
processes of the Nome organisation Processes, value chains, products and work
flow are definitely terms associated with BPR. In order to problematise BPR as a
systematic solution to business problems we have coupled it with ethnographic
descriptions and a constructive evolutionary design Through dialogue and via the
reflective process we have opened the "black boxes" and tried to address the issues
that in most BPR-methodology is considered a remaining factor. To delineate and
say what is a value adding process is not a simple issue as we have discussed. We
have not focused on measurement in
itself,
since we believe that this would restrict
the internal process in Nome The interventionist perspective employed here is not
special for BPR, but has a long tradition in the action research schools of
organisational theory (Argyris 1978, Schein 1987, Whyte 1991).
What Has Nome Learned so Far: the Use of the Work Processes and
the CSCW-application?
Nome has up to March 1997 had almost a years' experience with the design of
work processes and the incorporated versions of the flowcharts in the NOTES
application Nome is not in production yet and we can only speculate on future
usage in operations However, some preliminary conclusions can be made on how
the use of this application changed their ideas on how they plan to operate the
installation and how it has eased their work in preparations for operations Around
90 of totally 110 in the Nome organisation have up to now been defined as users
One important observation is that it is the people in operations offshore that has
found most use of the application, and less the staff support units onshore This is
mainly because of a need for detailed asyncronous communication offshore. Status
information must be shared between weekly arriving and departing personnel as
well as between day and night shifts.
The timing was perfect since they needed a systematic approach to co-ordinate
many ongoing activities that had just started Managers and process owners in
operations/maintenance discovered benefits in using the application in their
preparations This does not only cover the flow charts themselves, but very much
how you can link up information to the process maps The operation manuals of
122
starting and shutting down the technical systems have been incorporated into the
application, these have always been paper based up to now. Another problem has
been the version handling of these and other procedures, now there are only one
electronic copy that is always updated Other procedures related to operations that
used to be in different NOTES databases are linked up, which indicates that the
workers do not need to spend time finding this information Finding the right
information has become an increasing problem in Statoil, with over 3000 NOTES
databases The idea implemented here has been to describe the formal process and
then link up the information needed to perform that job and let the process owner
have the responsibility of updating and improving the links. As a consequence
other computer systems (the plant maintenance system, the technical information
system and vendor information on WWW) are linked up via the Nome NOTES
application
On the lowest level in the organisation, checklists for the maintenance of the
technical systems are also incorporated in the application These weekly check lists
that regulate what technical systems should be maintained, by whom, at what time
interval, and with a short description of the work
itself,
was not intended to be a
part of the application in the first place When using the application the Nome
personnel found new potential functionality that created larger dependency.
We have discovered that the application is highly important for training the
newly employed personnel. The simple symbols in the enterprise model from
bottom to top enable the newcomers to understand more of the ideal Nome model
of operations. The alternative would have been an operational philosophy
document or a set of procedures. Although the graphics is fancy for a newcomer,
the super user finds them increasingly boring to use He or she wants to go directly
into the sub-process they need in their daily work To be able to do this we have
developed a separate collapsible view without graphics However, the superuser
also uses the graphics when he/she enters a process not known in detail. The
technician would use the graphic navigator to go to the financing process and the
budgeting sub-process
This CSCW-application is therefore conceived by Nome as a navigation device,
a superstructure or an information and communication backbone that Nome people
can use in their daily work and for orienting themselves in relations to a number of
another computer systems and NOTES databases Nome personnel do not
interpret the application to be a work flow system, even though some flowchart
symbols have been used They see it as a structured way of representing work
processes, representations or resources made available that up to now have been
hidden in paper based strategies and procedures In our case we tried to align
interested people in the organisation from the very start, via strong and committed
management support, and devoted process owners. Finally, the Nome personnel
themselves designed their processes The evolutionary development of the
application created dependencies in the Nome organisation, since it became their
preparations for operations project. With respect to ISO and Norwegian petroleum
authorities inspections they are dependent on this application to show how they
will operate A preliminary conclusion is that Nome has gradually taken over the
123
application and Nome operations offshore will not function without the
application Nome has also incorporated the application in their process for
continous improvement.
In Statoil we have been trying to build rigorous enterprise models for years,
with complicated modelling tools. Very few have been used by the organisational
members themselves (Christensen, 1995). What has made Nome different is that
we have used simple standardised technology already in use in Nome operations
We have tried to build a collective representation of Nome's operational model
based on input from the Nome organisation, a model of their own construction
Hopefully this will enable Nome to develop some shared representations of their
future operational practice, and that the use of the application perhaps will be less
important when they have internalised these representations in operations. This is
not because of the application alone, but would be the consequence of a larger
organisational development process
Acknowledgements
I am indebted to my colleagues at the Co-ordination Technology Department at
Statoil R&D who have through years of
fieldwork
developed the methodology that
made this work possible. In this project I thank Lars Thuestad, Arnstein J Borstad,
Jan Onarheim, Geir Jarle Strom, John Olav Midtlyng and Johnny Litzheim in
particular. Thanks to the visions and persistence of Nome operators/technicians
and managers. Tor Hoas, Terje Tellefsen, Wiggo Lonoy, Knut Ystgard, Steinar
Helle, Leif Belaska, Marta Vabe and others Finally, thanks also to Statoil Data
who set up the necessary LOTUS NOTES R4-infrastructure and made this project
possible.
References
Argyris, C. and Scbon, D. (1978): Organizational
Learning:
A Theory of Action Perspective,
Reading, Mass.
Bateson, G. (1973) Steps to an Ecology of
Mind,
Ballantine Books, New York.
Borstad, A.J., Heps0, V., Onarheim, J., Tvedte, B. Aune, A..B. and Engelsen, K. (1993):
"Experience Transfer in Statoil",
Proceedings
of IPCC93-IEEE
International Professional
Communication
Conference,
October
1993,
Philadelphia PA., IEEE.
Christensen, L. C, Johansen, B. W , Midjo, N., Onarheim, J., Syvertsen, T G , and Totland, T ,
(1995):
"Enterprise Modeling - Practices and Perspectives",
Proceedings
of the
Ninth
Annual
ASME
Engineering Database
Symposium,
Boston, Mass.
Davenport, T. H. (1993): Process Innovation: Reengineering Work Through Information
Tecnology,
Harvard Business Press, Boston, Mass.
Goffman, E
(1961):
Asylums,
Anchor Books, New York
Hammer, M. and Champy, J. (1993):
Re-engineering
the
Corporation:
A
Manifesto
for Business
Revolutions,
Nicholas Bealey Publishing, New Work.
124
Heps0, V. (1997): "CSCW-Design and Implementation of Experience Transfer in Organisa-
tional Networks", in: Mambrey, P., Paetau, M., Pnnz, W.,
Wulf,
V., Self
Organization:
A
Challenge
to
CSCW,
forthcoming.
Hughes, J., King, V., Rodden, T. and Anderson, H. (1995): "The Role of Ethnography in
Interactive Systems Design",
Interactions,
Vol 11.2, April.
Klockner, K., Mambrey, P., Sohlenkamp, M., Pnnz W., Fuchs, L., Kolvenbach, S.,Pankoke-
Babatz, U. and Syri, A. (1995): "POLITeam: Bridging the Gap between Bonn and Berlin for
and with the Users",
Proceedings
of the ECSCW
95,
Kluwer Academic Publishers.
Latour, B. (1987): Science in Action: How to Follow Scientists and Engineers Through
Society, Harvard University Press, Cambridge.
Malone, T
W.
(1995)- "Commentary on Suchman Article and Winograd Response", in
CSCW,
vol.
3, No 1.
Morgan, G (1986). Images of
Organisations,
Sage, Beverly Hills
Okamura, K., Fujimoto, M., Orlikowski W.,J. and Yates J., (1994): "Helping CSCW Appli-
cations Succeed: The Role of Mediators in the Context of
Use",
Proceedings of CSCW 94,
ACM Press, New York.
Randall, D W. (1995a). "A Comment on Lucy Suchman's: Do Categories Have Politics",
CSCW,
vol 3, No I.
Randall, D.W., Rouncefield, M. and Hughes, J. A. (1995b): "Chalk and Cheese: BPR and
ethnomethodologically informed ethnography in CSCW", in
Proceedings
of the
ECSCW
95,
Kluwer Academic Publishers.
Robinson, M. (1991) "Double-Level Languages and Co-operative Working" Al & Society 5
34-60
Rumbaugh, J. (1993) "Objects in the Constitution-Enterprise Modeling", Journal
on
Object-
Oriented
Programming,
pp 18-24, January.
Schmidt, K and Simone, C. (1996). "Coordination Mechanisms. Towards a Conceptual
Foundation of
CSCW
System Design",
CSCW,
vol 5, No 2/3
Schein, E.H. (1987): The Clinical Perspective in Fieldwork, Sage Qualitative Research
Methods Series No 5 Sage, Ca.
Schuler, D. and Namioka, A. (eds) (1993): Participatory Design: principles and practice,
Hillsdale New Jersey NJ.
Suchman, L. (1987): Plans and
Situated
Actions.
The
Problem
of
Human-machine
Communi-
cation, Cambridge University Press Cambridge.
Suchman, L., (1994): Do Cathegories have Politics,
CSCW,
vol 2, No 3
Thorsrud, E. and Emery, F. (1969): Form and
Content
in Industrial
Democracy,
Tavistock,
London,
Whyte, W. F. (ed) (1991):
Participatory
Action Research, Sage Ca.
Winograd, T. (1994): "Categories, Disciplins and Social Coordination",
CSCW,
vol 2, No 3.
Wulf V. and Rohde M. (1995): "Towards an Integrated Organization and Technology
Development", in Proceedings of the Symposium on
Designing Interactive
Systems,
ACM-
Press,
New York.
