Forelesing 5 i INF3290Forelesing 5 i INF3290Case 3 og 4g

19. september 201119. september 2011Margunn Aanestad

1

Case 3 og 4Case 3 og 4 

• Hydro Agri Europe– Ole Hanseth og Kristin Braa (2000): ”Who’s in g ( )Control? Designers, managers – or technology? Infrastructures at Norsk Hydro”y

• ”NorthOil”Vid H E i M i K R ll d– Vidar Hepsø, Eric Monteiro og Knut Rolland (2009): ”Ecologies of e‐Infrastructures”

2

3

Norsk HydroNorsk Hydro• Etablert 1905• Etablert 1905

– “Norsk Hydro‐Elektriske Kvælstof Aktieselskab”– Gjødsel, lettmetall, olje & gass

• Her: Gjødseldivisjonen – Hydro Agri Europe (Yara)– 19 produksjonssteder & 72 lokasjoner i Europap j j p

• Store oppkjøp, men “hands off” ledelse (uavhengige nasjonaledivisjoner)divisjoner)

• 1992: Krise – besluttet seg for tettere integrasjon av europeiskedivisjonerdivisjoner– SAP‐installasjon– Hydro Bridge som “corporate standard”

4

BridgeBridge

• De første PC’ene kom i 1983 (olje/gass‐divisjonen), deretter filservere, PC‐LAN, j )nettverks‐OS… (Novell‐server 1987)

• Standarder for dokument maler disk• Standarder for dokument‐maler, disk‐partisjoner, back‐up‐rutiner osv.

• 1992: erkjente at fragmenteringen av IT‐systemer var et stort hinder for integrasjon avsystemer var et stort hinder for integrasjon av selskapet – startet Bridge‐prosjektet

5

Bridge en konsern standardBridge – en konsern‐standard

• Fokus på desktop‐applikasjoner: Valg mellom Microsoft og Lotus‐produkter – Lotus valgt, skulle foretrekkes der Lotus SmartSuite hadde løsninger

– Microsoft fortsatt brukt ved spesielle behov (Excel, Word)

• Bridge anerkjent som konsern‐standard i 1994• Implementering: ’som å åpne Pandoras eske’

– Script for konsistent installasjon utviklet, men man støtte p j , øpå problemer med ikke‐standardisert underliggende infrastruktur (OS, LAN, HW)

6

… 

• Standarden ble ’løsere’, og ble brukt ulikt av ulike deler av organisasjonen

• Ulike prosesser/resultat:– Olje/gass: tidlig, fortsatt mye bruk av MS– Gjødsel: tidlig, brukte allerede Lotus– Lettmetall: langsom, motstandg ,

• E‐post vanskelig, pga. ulikheter i krav fra eksterne partnerepartnere

• Support av Bridge, opplæring, vedlikehold, brukerstøtte osvbrukerstøtte osv.

7

D kt

Lotus Notes brukergrensesnitt Web‐browsere

Desktop‐applikasjoner

SAPLotus Notes database

Nettverk, operativsystemer, PC’er

Støttetjenester

8

Fase 1: Reengineering uten ITFase 1: Reengineering ‐ uten IT

• Planen var en rask integrasjon– “Synergy between processes through global organizing”

• Mye motstand i organisasjonen, lite resultater avforsøket

• Man oppdaget at det fantes svært heterogene IT‐t b l tt t å t d di ( å d tsystemer og besluttet å standardisere (anså det som

nødvendig for å få til organisatorisk integrasjon)• HAE valgte SAP som standard ERP system i 1994• HAE valgte SAP som standard ERP‐system i 1994• Implementasjon startet 1995 og skulle avsluttes 1999

9

SAPSAP

• SAP er et ERP‐system (Enterprise Resource Planning)g)

• SAP = Systeme, Anwendungen und Produkte in der Datenverarbeitungder Datenverarbeitung

• SAP er modulbasert, og leverer systemer for for eksempel regnskap og økonomi, salg og distribusjon, innkjøp og lagerstyring logistikk,distribusjon, innkjøp og lagerstyring logistikk, vedlikehold, produksjon og personalbehandlingpersonalbehandling. 

10

2: SAP implementering2: SAP‐implementering• Første trinn:• Første trinn: 

– Utvikling av felles enhetlig SAP‐installasjon som støttetfelles prosesser på tvers av organisasjonenp p g j

• Andre trinn: – Dette skulle igjen skape grunnlag for tettere integrasjon

• Plan: Pilot (Tyskland) deretter validering og roll‐out avendelig versjon

Mer komplisert enn forventet pilot krevde 3 mnd med– Mer komplisert enn forventet – pilot krevde 3 mnd med massiv support,  mer enn 1000 “issues” identifisert,  ikkealle rettet opp i endelig impl.‐versjon

• Men vellykket: Ledelsen fikk sterkere kontroll vha. SAP på den re‐engineeringen som de ikke hadde klart utenITIT

11

3: Fragmentering ‐ lokale brukereinvolveres

• Etablere felles tjenester:j– SDC – Single Distribution Center,  etabl. 1997 i Paris. Oppgave: 

håndtere transaksjoner mellom markeds‐ og produksjonsenhetene. Men hadde ingen ansatte var kun ‘logisk’ nødvendig pga SAP‐Men hadde ingen ansatte, var kun  logisk  nødvendig pga. SAP‐softwarens arkitektur. 

• Validering: Lokale brukere ble involvert (flere regionaleprosjekter, ca 100 personer i skandinavisk prosjekt)

• Fragmentering av SAP‐løsningenUlike nasjonale lo er (re isjon skatt miljø ern)– Ulike nasjonale lover (revisjon, skatt, miljøvern)

– Ulike markedsmodeller og forretningskulturer• Fra enhetlig felles system til heterogeng y g

informasjonsinfrastruktur– Customisert for hver avdeling

• SAP: de lokale avdelingenes allierte (mot ledelsens prosjekt)12

4: Bedriften informasjons infrastruktur4: Bedriften informasjons‐infrastruktur• SAP‐installasjonen i HAE måtte integreres med andre(Olje og Gass‐divisjonen m fl hadde sin egen SAP)(Olje og Gass divisjonen m.fl. hadde sin egen SAP)

• Dessuten måtte den integreres med underliggendeinfrastruktur og andre applikasjoner

H d id d d– Hydro Bridge‐standarder– Lotus Notes, regneark– Notes og web‐baserte grensesnitt til SAPg g

• Resultat: “Matrise‐formet” informasjonsinfrastruktur• Ikke skapt etter overordnet design/plan, men “emergent”“emergent”– (Emergent = Noe som oppstår eller dukker opp)

• Kompleks ‐ vanskeliggjør/blokkerer dermed fremtidigeKompleks vanskeliggjør/blokkerer dermed fremtidigeendringer:– “SAP er som sement, det er veldig fleksibelt helt til detstivner og da er det ikke noe du kan gjøre”stivner og da er det ikke noe du kan gjøre

13

OppsummeringOppsummering• Fra visjonene om et felles, delt, enhetlig system tilen kompleks, heterogen bedrifts‐infrastruktur

• Ref tittel på kapitlet: “Who is in control?  Designers, Managers – or Technology?”– Først – SAP er toppledelsens allierte– Deretter: De lokale divisjonenes allierte– Så: blokkere endringer – SAP “styrer selv”?– Selvforsterkende vekst i kompleksitet, ‐ nårinformasjonsinfrastrukturen blir omfattende (dvs. 

) å å (vellykket) blir den for kompleks å håndtere (dvs. mislykket)

14

15

Case 4: NorthOilCase 4: NorthOil

16

Litt historieLitt historie

• 1958: Norges Geologiske Undersøkelser (NGU): – man «kan se bort fra muligheten for at det skulle gfinnes kull, olje eller svovel på kontinentalsokkelen langs den norske kyst». g y

• Ekofisk (et av verdens største oljefelt) ble funnet sommeren 1969 av Philips Petroleumsommeren 1969 av Philips Petroleum

• Farouk Al‐Kasim m.fl. anbefalte i 1971 etablering av Statoil, Oljedirektoratet– Statoil opprettet i 1972Statoil opprettet i 1972

17

IT løsningerIT‐løsninger

• Eric Monteiro og Vidar Hepsø: “Information infrastructure formation: Seize the day”:– 1992‐1998: etablering av Lotus Notes‐basert II 

– Sentralisering (SData) og k lid ikonsolidering

– Notes‐strategi: ‘Epost m/vedlegg’ (Memo IBM)(Memo, IBM)

• Kapittel fra boka “From Control to D ift” (2000) OUPDrift”, (2000), OUP. 

18

Økologier av infrastrukturerØkologier av infrastrukturer

• Vidar Hepsø, Eric Monteiro, og Knut Rolland: ”Ecologies of e‐infrastructures” (2009):g ( )– Historisk blikk på samarbeids‐løsninger i “NorthOil”NorthOil

– Microsoft SharePoint (2003 – 2008): intensjonen var å integrere sømløst ulike relevantevar å integrere sømløst ulike relevante informasjons‐kilder for optimalisering av produksjonenproduksjonen

19

BakgrunnBakgrunn NorthOil ble notert på New York Stock Exchange i 2001p g I juli 2002 ble The Sarbanes‐Oxley Act (SOX) vedtatt (US føderal lov, etter Enron‐skandalen i 2001) Mål: forbedre pålitelighet av finansiell rapportering, innføre regnskaps‐standarder. Øke sporbarhet, ansvarsforhold og transparensp

Loven krevde systemer for internkontroll og systematiskdokumentasjon av sentrale beslutningspunkter

L h dd t i lik j f l k Loven hadde store implikasjoner for selskapenes informasjonsystemser. Man måtte kunne dokumentere historien, inkl. versjons‐historikk, og forfatterskap til , j , g pdokumenter. 

Microsoft Sharepoint markedsført som ”SOX compliant”

20

• ”Økologi”‐metaforen: langtids evolusjonlangtids evolusjon, biodiversitet, sammenhenger/synergier

• ”Økologien” av samarbeidsløsninger i ø gNorthOil:– Deling av dokumenter via 

filsystem (’G‐drive’)– Innføring av Lotus Notes 

(1990‐tallet)(1990‐tallet)– Innføring av Sharepoint

(2003‐2008)

21

(Logistics)

22

Samarbeid mellom ulike grupper:Samarbeid mellom ulike grupper: Reservoar‐ingeniører Reservoar ingeniører Brønn‐ingeniører Produksjons‐ingeniørerj g Onshore og offshore

H d k i i ikk l Sh i Hovedperspektivet i artikkelen: Sharepoint som et arbeidsredskap for produksjonsingeniører Helhetlig og historiske beskrivelser av brønnens produksjong g ø p j Hyppig koordinering og revisjon av produksjonsparametre Utfordrende å verifisere hva som er siste versjon av dokumentene Må ta i betraktning mer enn en brønn andre brønner i samme Må ta i betraktning mer enn en brønn; andre brønner i samme reservoar påvirker trykk og flow‐forholdene

23

Smartboard drawing with pressures, zones and faults

24

25

Mange informasjonssystemerMange informasjonssystemer• STRUKTURERTE DATA:• STRUKTURERTE DATA:• Sanntidsdata fra sensornettverk• Historisk informasjon (logger, rapporter osv.)

• Hovedbrønner (tradisjonelle fra plattformer) og  satellitt‐brønner(subsea‐installasjoner)( j )– Spesifikke verkøty trengtes for å beregne satellitt‐brønnenes produksjon– Eksporterer til Excel‐ark og lignende og beregner (makroer/ActiveX), 

importere tilbake til produksjonsystem. 

• USTRUKTURERTE DATA:• Andre historiske brønndata ble ofte brukt til endringer avAndre, historiske brønndata ble ofte brukt til endringer av 

produksjonsparametre, disse fantes flere steder:  ”G‐disken” (Word‐dokumenter på felles filserver) Siden 1990‐tallet i Lotus Notes database (delvis) Siden 1990 tallet i Lotus Notes database (delvis) Etter 2005: Skulle lagres i Sharepoint

26

27 28

Information infrastructural tools in contextInformation infrastructural tools in contextDiscipline specific IT‐

systems, models and 

Local line organizationand management

representations

Historical and field‐specific 

information and i f fl

Control room practices Corporate requirements

info flows 

offshoreCorporate requirementsand initiatives

Infrastructure

Photos by Øyvind Hagen / StatoilHydro29

Hvorfor SharePoint?Hvorfor SharePoint?”Domino/Notes infrastukturen er for dårlig integrert og det er et spesielt behov for bedre, mer integrerte verktøy, som sikrer god sporbarhet til informasjon, y g p jbedre søkefunksjonalitet og forbedrede muligheter for å dele informasjon med eksterne jsamarbeidspartnere. Vi har valgt MS Sharepoint for å overkomme denVi har valgt MS Sharepoint for å overkomme den fragmenteringen som den gamle infrastrukturen har brakt oss opp i.” (IT‐sjef)brakt oss opp i.       (IT sjef)

30

SharePoint-visjonen

Customers

Internet Presence

Employees

Partners

HR Finance etc

Enterprise Portal

XML Web Services

HR, Finance, etc.

Team Collaboration

Business Applications(BEA, Matrix, custom . . .)

Personal

SharePointSharePoint

• Plattform for å bygge intranet/extranet/internett‐lløsninger

• Samarbeids‐funksjonalitet• Dokument‐søkDokument søk• Person søk• Dele dokumenter• Blogger og wiki’er• Publisering

M• M.m. …

32

SharePoint installasjonSharePoint‐installasjon

Sh i (’ f h b ’ i l j d li• Sharepoint (’out of the box’‐implementasjon, dvs. lite spesialtilpasning, ’customisering’)

• Excel‐ark med makroer var sentrale, men dokumenter med makroer kunne ikke lagres i første versjon avmed makroer kunne ikke lagres i første versjon av Sharepoint– Fortsatt bruk av Notes‐databasenFortsatt bruk av Notes‐databasen– Fortsatt bruk av felles filserver

• ”G‐disken er et godt alternativ, fordi vi vet at den alltid vil være der”g– Bruk av Sharepoint til referater og til et mindre antall dokumenter

33

Resultat: Mer fragmentering:Resultat: Mer fragmentering:

34

Metadata prosjektMetadata‐prosjekt

å• Man ønsket å definere en metadata‐taksonomi, dvs. regler for å sikre lik klassifisering av dokumenter på tvers av enheter og felt (’lisenser’)tvers av enheter og felt ( lisenser ). – Tagge dokumenter + søke/filtrere

• Metadata påvirker bruksmønstre men top down og• Metadata påvirker bruksmønstre, men top‐down og planlagte taksonomier er ofte for ambisiøse– Mulighet for ikke relevante kategorierMulighet for ikke relevante kategorier– Øker sjansen for feilkategorisering samtidig som systemet og brukerne forventer et ”perfekt system”

• Opportunistisk bruk (brukere valget første og beste kategori), feilaktig forståelse av begrepene osv.

35

Metadata prosjektMetadata‐prosjektF lk i b k t k i bli i k i t t• Folksonomier er brukergenererte, praksis nære men blir inkonsistente med overlappende kategorier 

• Artikkelen foreslår:  C ll b ti b l ll b l– Collaborative vocabulary = collabulary

– Den gyldne middelvei , mellom: • top‐down/pre‐definerte taksonomier• bottom‐up/emergent ’folksonomy’botto up/e e ge t o so o y

– DVS: Start med et sett av begreper, legg til bruker‐definerte tags, inkluder disse i standard‐sett dersom de blir mye brukt, jevnlig revisjon av taksonomien.

K k t T d kl ifi i k t j bb d• Konkret: Team med klassifiseringseksperter jobber sammen med domenekjente for å skape mer rike og systematisk tagging systemer– Vokser fram som en ’folksonomy’ og har dets fordeler: tettere på praksis og 

bedre kategoriseringbedre kategorisering– Samtidig skjer en ”disiplinering” og standardisering på tvers– Tettere link til praksis gjør at en raskere kan endre klassifikasjons‐systemene

36

På tvers:På tvers:ERP (SAP) i HydroyEPJ ved Rikshospitalet SSS i MCC SSS i MCC Sharepoint i NorthOil p

Likheter og ulikheter mellom disse?

37

OppsummeringOppsummering

• Hva karakteriserer informasjonsinfrastrukturer:– Enabling

Shared– Shared– Open– Heterogeneousg– Standardized– Evolving– Installed base

• Styring: mellom top‐down/kontroll og bottom‐up/laissez faire: k lti i i t ll t bkultivering av installert base

38