Margunn Aanestad

Styring av informasjonsinfrastrukturer

24. oktober 2014

Komplekse systemer, kontroll og styring

• Hvordan skal man tenke omkring styring av

komplekse systemer - slik? – ”Når det er så mye usikkerhet som nå, så blir det

desto viktigere med en sterk prosjektledelse og klar ansvarsfordeling. Vi må formulere klare mål og sørge for at de avtalte milepæler nåes til fastsatt tid”.

• M.a.o: høy usikkerhet og stor endring krever mer, tettere og bedre planlegging og mer kontroll.

• Forutsetter at kontroll er mulig (og ønskelig)

2

• Er IT-prosjekter komplekse eller «bare»

kompliserte?

• Er håndtering av «IT-landskaper» en

kompleks eller komplisert oppgave?

• Er komplekse systemer styrbare? Eller bare

‘påvirkelige’? I hvor stor grad, hvordan?

3

Komplekse systemer, kontroll og styring

• Kultivering: Middelvei mellom full/ingen kontroll:

• Improvisasjon («tinkering», «bricolage»)

• Drift

(Modifisert figur fra kapittel 9 i onlline bok)

http://heim.ifi.uio.no/~oleha/Publications/bok.html

Design Improvisation Cultivation Drift No control

Complete human control Technology = material to be shaped

No human control Technology as actor (Determinism)

”Kultivering av installert base”

– Forutsetter ikke full kontroll

• Må overlate noe kontroll til ”vekstprosessen”

– Evolusjonær, ikke revolusjonær strategi

• Gradvis/inkrementell, iterativ

• Påpasselighet i prosess-styringen (være tettere på,

observere/justere, ’vanne’ og ’luke’)

– Læringsorientert

• Ikke spesifikasjonsdrevet, men læringsdrevet

• Seleksjon/valg basert på erfaring/læring

6

Strategi og styring i 4 case

• Les case-artiklene med fokus på problemet med tradisjonell styring: Hva er det som «ødelegger» forsøkene på å styre?

– Hydro: Hanseth og Braa (2000)

– Maritime Classification Co. (Rolland &Monteiro 2002)

– Northoil: Hepsø m.fl. (2009)

– Rikshospitalet (Hanseth m.fl. 2007)

• Kontrast:

– HISP (Braa et al. 2007)

– CPA (Nielsen og Aanestad 2006)

Norsk Hydro

• Etablert 1905

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

• Her: Gjødseldivisjonen – Hydro Agri Europe (i dag Yara)

– 19 produksjonssteder & 72 lokasjoner i Europa – Store oppkjøp, men “hands off” ledelse (uavhengige

nasjonale divisjoner) – 1992: Krise – besluttet seg for tettere integrasjon av

europeiske divisjoner • SAP-installasjon • Hydro Bridge som “corporate standard” 8

Fase 1: Reengineering - uten IT

• Planen var en rask integrasjon

– “Synergy between processes through global organizing”

• Mye motstand & lite resultater av forsøket

• Standardisere de heterogene IT-systemene

– Nødvendig for organisatorisk integrasjon

– HAE valgte SAP som standard ERP-system i 1994

– Implementasjon: 1995 - 1999 9

SAP

• SAP er et ERP-system (Enterprise Resource Planning)

• SAP = Systeme, Anwendungen und Produkte in der Datenverarbeitung

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

10

2: SAP-implementering

• Første trinn: – Utvikle enhetlig SAP-installasjon som støttet felles

prosesser på tvers av organisasjonen

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

integrasjon

• Plan: Pilot (Tyskland) deretter validering og utrulling av endelig versjon – Mer komplisert enn forventet

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

11

3: Fragmentering - lokale brukere involveres

• Validering av pilotversjon -> lokale brukere involvert

• Flere regionale prosjekter (ca. 100 pers. i Skandinavia )

• Fragmentering av SAP-løsningen

– Ulike nasjonale lover (revisjon, skatt, miljøvern)

– Ulike markedsmodeller og forretningskulturer

• Fra enhetlig felles system til heterogen informasjonsinfrastruktur

– Customisert for hver avdeling

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

12

4: Bedriften informasjons-infrastruktur • SAP-installasjonen i HAE måtte integreres med andre

– Olje og Gass-divisjonen m.fl. hadde sin egen SAP

• Dessuten måtte den integreres med underliggende infrastruktur og andre applikasjoner – Hydro Bridge-standarder – Lotus Notes, regneark – Notes og web-baserte grensesnitt til SAP

• Kompleks - vanskeliggjør/blokkerer dermed fremtidige

endringer: – “SAP er som sement, det er veldig fleksibelt helt til det

stivner og da er det ikke noe du kan gjøre”

13

14

Støttetjenester

Nettverk, operativsystemer, PC’er

Desktop- applikasjoner

SAP

Lotus Notes brukergrensesnitt

Web-browsere

Lotus Notes database

• Fra visjonene om et felles, delt, enhetlig (standardisert) system til en kompleks, heterogen bedrifts-infrastruktur

• “Emergent”, Ikke skapt etter overordnet design/plan - like mye formet av tilbakeslagene og det man gjorde for å håndtere dem

• 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”?

15

16

II og kompleksitet:

• Ciborra m.fl. (2000): – “From Control to Drift. The dynamics

of corporate information infrastructures”

• Bokens hovedbudskap – Tradisjonelle (kontroll-baserte)

tilnærminger for å designe/forme informasjons-infrastrukturer fungerer ikke.

– Istedet foreslås “kultivering” av installert base som generisk strategi

• Teorikapitler + case

Rolland og Monteiro (2000):

• Maritime Classification Company – 6000 ansatte, 300 kontorer i >100 land

– Sertifisering av skip m.m.

– Ikke-standardisert og papir-basert informasjonssystem

• Stormaskin-system (info om skip, eiere, sertifikater og tidligere kontroller)

• Lokale LAN, lokale databaser, epost, kommunikasjon med stormaskin-systemet

• 74 ulike papir-sjekklister

– Økt global konkurranse:

• Man ønsket bl.a. å redusere skipets tid i havn; starte kontrollen i en havn og fortsette i neste havn

• Lokale kontorer trenger tilgang til oppdatert informasjon, også underveis i kontroll-prosessen

19

• SSS (Survey Support System):

– En felles informasjons-infrastruktur for å planlegge og gjennomføre skipskontroller (surveys)

– Stort IT prosjekt, 1994-2000, ca 1 milliard NOK

– 1997: hardware, globalt WAN

– Trengte å strukturere format og standardisere terminologi

– Gradvis overgang fra papir-basert til SSS-basert arbeidspraksis (2001)

20

GSIS applications and common

Work processes

GSIS product model

Common databases

(SQL server + DOCULIVE)

Underlying infrastructure

(Win NT, TCP IP)

Wide Area Network (WAN)

Product model

Local office Local office

GSIS

applications

GSIS

applications

customer

Web-based interface

Global produktmodell:uniform (enhetlig) representasjon av skips-informasjon og kontroll-prosessene

21

Når systemet tas i bruk:

• De ”globale ambisjonene” var problematiske:

– Økning i (irrelevante) punkter/kategorier

– Ulikhet i brukerbehov førte til behov for improvisasjoner og ‘workarounds’ (legge til kategorier, endre maler)

– Systemet hadde en rigid sekvensiell logikk

• Workarounds

• Utsatte levering av ’Quick reports’ og ’Final reports’

• Skrev inn mindre info, etablerer dobbeltrutiner

• Fragmenteringen ”kryper” inn igjen

22

Metamorphosis III: Integrating a corporate-wide infrastructure and strategic

initiatives

Unintended

dependencies

with non-local

routines and

systems

Deliberate

change in the

design and

management of

GSIS

Emergent change

in the design and

management of

GSIS

Deliberate

change in

auditorsÕ practice

Emergent change

in auditorsÕ

practice

Unanticipated

outcomes

A growing amount

of work at HQ to

integrate reports

Breakdown of

the central GSIS

server

Interoperability

problems with previous

GSIS version

Implementation

of an accounting

system

Year 2000

problem with

legacy system

New version (2.0) of

GSIS to

improve reporting

Shutdown of the

Legacy System

New

ŌMaintenance

ToolsÕ at HQ

Problems with

maintaining GSIS

database.

Hiring more

people at HQ

Implementing

new version of

GSIS (2.1)

More

conservative

policies for

implementing

new IS

Back-log becomes

critically large

New version

of Windows

NT

Users saves

unfinished

reports

Submitting many

reports becomes

the norm,

not the exception

23

• Nye fix’er førte til tilleggs-kompleksitet

• Bruken genererte nye krav

• Piloter og prototyping hadde håndtert bare ”lokale” og ikke ”globale” aspekter

• Tettere integrasjon ledet til flere og større avhengigheter

• “This is a huge patchwork – where everything is connected to everything. Whenever someone tries to implement something new without looking at the whole picture we’ve to dig out the backups after a few days…”

– Project manager

24

Oppsummering MCC • Typisk eksempel på et ”vellykket” IT-prosjekt

• Ønsket om en «universell» standard møter heterogenitet mellom brukere og bruksbehov

– Tilbakeslag

• Spenning mellom ”sentral logikk” (standardisering) og ”lokal logikk” (støtte til arbeidet, fleksibilitet)

– Ulike ordningslogikker?

– Prosess hvor systemet justeres slik at dette balanseres

• «Universalisme»

– Altfor idealistisk, utopisk?

25

Hepsø, Monteiro, Rolland (2009)

• Samarbeids-løsninger i “NorthOil” gjennom tidene:

• Deling av dokumenter via filsystem (’G-drive’)

• Innføring av Lotus Notes (1990-tallet)

• Innføring av Sharepoint (2003-2008)

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

27

Bakgrunn for valg av Sharepoint NorthOil ble notert på New York Stock Exchange i 2001 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 transparens

Loven krevde systemer for internkontroll og systematisk dokumentasjon av sentrale beslutningspunkter

Loven hadde store implikasjoner for selskapenes informasjonsystemser. Man måtte kunne dokumentere historien, inkl. versjons-historikk, og forfatterskap til dokumenter.

Microsoft Sharepoint markedsført som ”SOX compliant”

28

Problem: fragmentert informasjon

29

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, bedre søkefunksjonalitet og forbedrede muligheter for å dele informasjon med eksterne samarbeidspartnere.

Vi har valgt MS Sharepoint for å overkomme den fragmenteringen som den gamle infrastrukturen har brakt oss opp i.” (IT-sjef)

30

SharePoint-visjonen

HR, Finance, etc.

Team Collaboration

Personal

Enterprise Portal

Internet Presence

Employees

Customers

Partners

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

XML Web Services

SharePoint

• Plattform for å bygge intranet/extranet/internett-løsninger

• Samarbeids-funksjonalitet

• Dokument-søk

• Person søk

• Dele dokumenter

• Blogger og wiki’er

• Publisering

• M.m. …

32

SharePoint-installasjon

• 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 av Sharepoint – Fortsatt 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”

– Bruk av Sharepoint til referater og til et mindre antall dokumenter

33

Resultat: Mer fragmentering:

34 Dette er også en historie om at naive forventninger møter mer kompleks virkelighet

Metadata-prosjekt

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

• Metadata påvirker bruksmønstre, men top-down og planlagte taksonomier er ofte for ambisiøse – Mulighet 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

• «Folksonomy» - for eksempel tagger – … er brukergenererte, dermed praksisnære, men blir

inkonsistente med overlappende kategorier

• Artikkelen foreslår: – Collaborative vocabulary = collabulary (middelvei) – 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.

• Konkret: Team med klassifiseringseksperter jobber sammen med domene-eksperter for å skape mer rike og systematisk tagging-systemer – Vokser fram som en ’folksonomy’ og har dets fordeler:

tettere på praksis og bedre kategorisering – Samtidig skjer en ”disiplinering” og standardisering på

tvers

36

Styring

• Forventninger om å kunne «rydde opp» og «få kontroll» ble ikke 100% innfridd

• Forsøkte en mer fleksibel strategi i forhold til å definere metadata i Sharepoint-løsningen

• Hanseth og Ciborra (red): “Risk, Complexity and ICT” (2007)

• Bruker samfunnsvitenskapelig ‘kompleksitetsteori’: – Ulrich Beck: ‘Risk society’

– Anthony Giddens: ‘Reflexive modernization’

• Bokens hovedbudskap – Integrasjon øker kompleksiteten som

igjen øker risikoen

• Teorikapitler + case

IT-systemer på sykehus

40

Oversikt data ved RH (eks)

Unilab (medisinsk biokjemi, immunologi, mikrobiologi)

Pasientjournalen

DocuLive Patologi

2000 2005

Skannet

Elektronisk

Papir

Sectra RIS (Radiologi)

Klinisk portal (svarrapporter)

DocuLive (tekstlige journaldokumenter)

Agfa RIS (Radiologi)

1995 2010

Miclis (mikrobiologi)

DocuLive (andre journaldokumenter, skjema, svarrapporter fra ikke-integrerte systemer)

Mars 2006

Hanseth, Jacucci, Grisot, Aanestad (2007)

• Beskriver et forsøk på å lage «Den Norske EPJ» – Feilslått som standard (men eksisterer som et produkt)

– Historien sett fra RHs perspektiv, perioden fram til 2003

• Kapitlet forteller 4 «historier» – Eskalering av prosjektomfang & kompleksitet

– Å forstyrre en ‘papir-ordning’

– (Systemintegrasjon) (se forelesing 19.9)

– Utenforliggende faktorer («politikk»)

Tidslinjen: • 92 93 94 95 96 97 98 99 00 01 02 03 04

Alp

ha

Pro

du

cts

Pro

jec

tsE

ve

nts

92 93 94 95 96 97 98 99 00 01 02 03 04

Pa

pe

r

Re

co

rd

Medina

Norwegian Consortium

Project

Distributed

Centralized

CSAM (portal)

Scanning

Rik

sh

os

pit

ale

t

DocuLive

IntEPR

GlobEPR

Globalization process

No

rwe

gia

n

Gu

ide

line

s

for c

en

traliz

ed

pa

pe

rre

co

rd

pu

blis

he

d

Alp

ha

ac

qu

ires

US

ba

se

dA

MS

No

rwe

gia

n

Hea

lthR

efo

rm

Cris

isa

t arc

hiv

e

de

pa

rtme

nt

at R

H

Pla

nn

ed

de

live

ry

of

Do

cu

Liv

e 5

.0

(an

d e

nd

of

prjc

t)

Timeline

Scand. EU Global

No

r. Co

ns

. Prjc

t

sta

rted

with

Alp

ha

an

d

Do

cu

Liv

e

• Historie 1 handler om ”eskalering” av prosjektet:

• Fem regionsykehus samarbeidet om ”den norske EPJ” – Regionsykehuset i Tromsø, Regionsykehuset i Trondheim,

Haukeland sykehus, Rikshospitalet og Ullevål sykehus

– Dette bygde på tidligere utviklingsprosjekter og løsningsforslag

• Samarbeid med Siemens som leverandør (pga. ’tyngde’) – Produkt: DocuLive EPJ

– MEDAKIS-prosjektet startet i 1996, skulle avsluttes med DocuLive versjon 5.0 i 1999

– Iterativt og brukerstyrt prosjekt, modulbasert løsning, fordeling av ansvar mellom sykehusene, læringsorientert (pilot-installasjoner)

• Siemens hadde flere andre (europeiske) EPJ-prosjekter – Harmonisering av disse ble antatt å gi gevinster – Redefinering av strategi – utvikle produktet ”IntEPR”

• ..og kjøpte seg opp i internasjonale helse-IT-firmaer – India + USA, ny redefinering – ”GlobEPR” – Inkorporering av nye arkitekturplattformer & brukerkrav

• Dvs. dette gikk fra norsk til europeisk, så til et globalt prosjekt

• Konsekvens: større og mer tungrodd prosjekt, flere krav og mer kompleks løsning – ikke realisert – ”Fighting Fire with Fire”

• Norge: – MEDAKIS som formelt prosjekt ble avsluttet i 2004 med versjon

4.7 av DocuLive – håndtert av Siemens Norge. Videreutvikling og oppfølging basert på separate kontrakter m/brukersykehusene. DocuLive brukes i region Midt-Norge.

• Historie 2 handler om overgangen fra papir- til digital journal:

• Tidligere: avdeling-arkiver, papirjournaler, egendefinerte formater.

• Ca. 1995: standardisering av skjemaer og formater, og sammen-slåing av alle avdelings-arkivene til ett arkiv for hele sykehuset.

• Digitalisering i fb. med MEDAKIS-prosjektet. DocuLive ble rullet ut etter flytting til Gaustad (2000-2001) – Men DocuLive var ikke ferdig utviklet og inneholdt ikke all informasjon, så

man måtte beholde papir-journalene.

– Papir-journalen var juridisk gyldig pasientjournal, skrev ut informasjon fra EPJ og lagret i papirjournalen for å holde den fullstendig

– DocuLive ikke egnet for utskrift + dårlige rutiner for å rydde bort duplikater – og mengden av papir økte etter at EPJ ble innført. Skanningprosjekt 2003-2005

• Konsekvens: Fikk kostnader og arbeidsbyrden med EPJ men ikke gevinstene.

• Historie 3 handler om system-integrasjon (forelesning 19.9.)

Kapitlet forteller 4 historier: (4) • Historie 4: hvordan ytre forhold former IT-strategier

• Opprettelsen av 5 helseregioner 1. januar 2002

• Før: eier av sykehusene var 19 fylkeskommuner

• De regionale helseforetakene ønsket en standardisering av IKT-løsninger pga. stordriftsfordeler (markedsmakt, sentralisert drift, opplæring osv)

• Rikshospitalet det eneste sykehuset i Region Sør som brukte DocuLive, og ønsket ”allierte” så de skal slippe å bytte journalsystem. Etter hvert - selger portal-konseptet heller enn DocuLive

• Sammenslåinger (RH + Radium i 2005) og funksjonsfordelinger

• CSAM Health skilt ut som eget selskap (AS)

• …

Etter kapitlet ble skrevet: • 1. januar 2009: Oslo Universitetssykehus ble etablert, behov for

samordning av IT-systemer (PAS/EPJ)

• Juni 2009: rapport om ”felles klinisk informasjonsgrunnlag”, skisserer ”Klinisk arbeidsflate”, basert på tjeneste-orientert arkitektur – Leverandøruavhangighet, endringsevne, viktig for overgang til prosess-

støttende systemer, kan innføres gradvis.

• Anbudsprosess, valg des. 2009 for implementasjon 1.6.2010

• Mai 2011: prosjektet terminert, tap 160 millioner (?)

• Okt. 2014: innføring av DIPS i hele OUS

48

Oppsummering • Artikkelens budskap:

– Standardisering er en måte å skape orden på, men kan aldri eliminere all uorden, bare ”flytte” rundt på den.

– Forsøk på å standardisere og integrere (”rydde opp”) førte til side-effekter, og forsøkene på å håndtere dem førte til flere side-effekter osv. -> dette kalles i artikkelen for refleksivitet

49

På tvers: ERP (SAP) i Hydro

EPJ ved Rikshospitalet

SSS i MCC

Sharepoint i NorthOil

Likheter og ulikheter mellom disse?

50

Fra Hanseth m.fl. (2006):

• “These approaches tend to overestimate the universality of work practices, thus seeking order by simplification and abstraction and putting strong emphasis on design criteria such as consistency, completeness, and nonredundancy. These are all sound engineering principles and central to modernity.” …

• “As Law (2000, p. 14) notes, “the search for system perfection is not only impossible but, more strongly, it may be self defeating.” We need to accept in our standard making that our complex worlds are populated with a multiplicity of orders that are inconsistent. We need to be able to live with such multiplicities and inconsistencies.”

Kan ‘kultivering’ fungere?

• Et pågående ‘forsøk’:

– http://www.mn.uio.no/ifi/english/research/news-and-events/events/conferences-and-seminars/iiios2014/presentations/jensen-et-al.pdf

• Annet eksempel:

– HISP (Health Information Systems Programme)

= National HIS deployment

= National start-up / pilot

= early national initiative or program-specific deployment

12

14

11

Present in over 30 countries, 10 Indian states National standard in Kenya, Ghana, Uganda, Rwanda, Liberia, Nigeria, Sierra Leone, Gambia, Zanzibar, Malawi, Zimbawe

AIM: Support local (district-level) decision making and utilization of information

Artikkel: Flexible standardization

• «Fleksibel standardisering» - er ikke det er selvmotsigelse?

– Standard: hindre avvik og variasjon

– Hvordan standardisere på en måte som kan håndtere heterogenitet (use flexibility) og fremtidig endring (change flexibility)

• Standard for data-sett (”attractor”)

– Eastern + Western Cape -> Sør-Afrika (2000)

• ”Gateways”: ulikheter mellom geografiske områder i Etiopia -> ulike løsninger

Region:

Health centre:

Zone:

Worreda/

Sub-city:

Patient /

Primary

registration:

Addis Ababa Oromia Benishangul Levels

Computer

Paper

Gateway

Uneven development of Information infrastructure in

developing countries requires flexibility in strategy:

One size doesn’t fit all - the technical solutions must be different

Standardisation must focus on data layer!!! The technical layers must be solved

through ad-hoc gateways and flexible solutions (from web to donkeys!)

Nielsen og Aanestad (2006): ’Control Devolution’ The Content Provider Access (CPA) Platform

(innholdstjenester på sms)

Telenor og Netcom lanserte i 1997 egne plattformer m/fast pris (standard sms) Begrensa bruk, høye kostnader, redaksjonelt ansvar for innhold (En historie om at suksess kan komme også uten strategisk styring) (… og en historie som viser at hva som standardiseres er viktig)

Kortnummer (til tjeneste) og fast syntaks på sms

Innholdstjenester (SMS)

• Innholdsleverandører ønsket høyere pris, integrasjon/samordning

• Operatørene: ingen strategisk interesse for å bygge felles løsning

• «Under the radar»-prosjekt m/enkeltpersoner

Manifesto for Agile Software Development

• We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

– Individuals and interactions over processes and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a plan

• That is, while there is value in the items on the right, we value the items on the left more.

Kompleksitet og styring

• Er IT-prosjekter komplekse eller «bare» kompliserte?

• Er håndtering av «IT-landskaper» en kompleks eller komplisert oppgave?

• Er komplekse systemer styrbare? Eller bare ‘påvirkelige’?

• Diskusjon:

– Når (for hva slags prosjekt) passer hvilken fremgangs-måte?

64