Styring av informasjonsinfrastrukturer

Transkript

1 Margunn Aanestad Styring av informasjonsinfrastrukturer 24. oktober 2014

2 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

3 Komplekse systemer, kontroll 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? I hvor stor grad, hvordan? 3

4 Kultivering: Middelvei mellom full/ingen kontroll: Improvisasjon («tinkering», «bricolage») Drift Design Improvisation Cultivation Drift No control Complete human control Technology = material to be shaped No human control Technology as actor (Determinism) (Modifisert figur fra kapittel 9 i onlline bok)

5 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 6

7 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)

8 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

9 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:

10 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

11 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

12 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

13 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 Lotus Notes brukergrensesnitt Lotus Notes database Web-browsere SAP Desktopapplikasjoner Nettverk, operativsystemer, PC er Støttetjenester 14

15 Fra visjonene om et felles, delt, enhetlig (standardisert) system til en kompleks, heterogen bedriftsinfrastruktur 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 16

17 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

18

19 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 stormaskinsystemet 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

20 SSS (Survey Support System): En felles informasjons-infrastruktur for å planlegge og gjennomføre skipskontroller (surveys) Stort IT prosjekt, , 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

21 Global produktmodell:uniform (enhetlig) representasjon av skips-informasjon og kontroll-prosessene GSIS applications and common Work processes Local office Local office GSIS product model Common databases (SQL server + DOCULIVE) Underlying infrastructure (Win NT, TCP IP) GSIS applications Product model GSIS applications Wide Area Network (WAN) Web-based interface customer 21

22 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

23 Unintended dependencies with non-local routines and systems Deliberate change in the design and management of GSIS Metamorphosis III: Integrating a corporate-wide infrastructure and strategic initiatives New version of Windows NT New version (2.0) of GSIS to improve reporting Implementation of an accounting system Year 2000 problem with legacy system Emergent change in the design and management of GSIS Hiring more people at HQ More conservative policies for implementing new IS Shutdown of the Legacy System Implementing new version of GSIS (2.1) New ŌMaintenance Tools Õat HQ Deliberate change in auditorsõpractice Emergent change in auditorsõ practice Submitting many reports becomes the norm, not the exception Users saves unfinished reports Unanticipated outcomes A growing amount of work at HQ to integrate reports Breakdown of the central GSIS server Problems with maintaining GSIS database. Interoperability problems with previous GSIS version Back-log becomes critically large 23

24 Nye fix er førte til tilleggskompleksitet 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

25 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

26

27 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 ( ) Microsoft SharePoint ( ): intensjonen var å integrere sømløst ulike relevante informasjons-kilder for optimalisering av produksjonen 27

28 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

29 Problem: fragmentert informasjon 29

30 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

31 SharePoint-visjonen Customers Partners Internet Presence Employees Enterprise Portal XML Web Services HR, Finance, etc. Team Collaboration Business Applications (BEA, Matrix, custom...) Personal

32 SharePoint Plattform for å bygge intranet/extranet/internettløsninger Samarbeids-funksjonalitet Dokument-søk Person søk Dele dokumenter Blogger og wiki er Publisering M.m. 32

33 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

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

35 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

36 «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

37 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

38

39 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

40 IT-systemer på sykehus 40

41 Oversikt data ved RH (eks) Elektronisk Skannet Papir Mars DocuLive (tekstlige journaldokumenter) Pasientjournalen DocuLive (andre journaldokumenter, skjema, svarrapporter fra ikke-integrerte systemer) Klinisk portal (svarrapporter) Unilab (medisinsk biokjemi, immunologi, mikrobiologi) DocuLive Patologi Sectra RIS (Radiologi) Agfa RIS (Radiologi) Miclis (mikrobiologi)

42 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»)

43 Rikshospitalet Alpha Products Events Paper Record Projects Norwegian Guidelines for centralized paper record published Nor. Cons. Prjct started with Alpha and DocuLive Planned delivery of DocuLive 5.0 (and end of prjct) Alpha acquires US based AMS Norwegian Health Reform Crisis at archive department at RH Tidslinjen: Timeline DocuLive IntEPR GlobEPR Globalization process Scand. EU Global Norwegian Consortium Project Medina CSAM (portal) Scanning Distributed Centralized

44 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)

45 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.

46 Historie 2 handler om overgangen fra papir- til digital journal: Tidligere: avdeling-arkiver, papirjournaler, egendefinerte formater. Ca. 1995: standardisering av skjemaer og formater, og sammenslå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 ( ) 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 Konsekvens: Fikk kostnader og arbeidsbyrden med EPJ men ikke gevinstene. Historie 3 handler om system-integrasjon (forelesning 19.9.)

47 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)

48 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 prosessstøttende systemer, kan innføres gradvis. Anbudsprosess, valg des for implementasjon Mai 2011: prosjektet terminert, tap 160 millioner (?) Okt. 2014: innføring av DIPS i hele OUS 48

49 Artikkelens budskap: Oppsummering 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

50 ERP (SAP) i Hydro EPJ ved Rikshospitalet SSS i MCC Sharepoint i NorthOil På tvers: Likheter og ulikheter mellom disse? 50

51 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.

52 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.

53 Kan kultivering fungere? Et pågående forsøk : Annet eksempel: HISP (Health Information Systems Programme)

54 Present in over 30 countries, 10 Indian states National standard in Kenya, Ghana, Uganda, Rwanda, Liberia, Nigeria, Sierra Leone, Gambia, Zanzibar, Malawi, Zimbawe = National HIS deployment = National start-up / pilot = early national initiative or program-specific deployment

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

56 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

57

58 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!) Levels Addis Ababa Oromia Benishangul Region: Zone: Worreda/ Sub-city: Health centre: Patient / Primary registration: Computer Gateway Paper

59

60 Nielsen og Aanestad (2006): Control Devolution The Content Provider Access (CPA) Platform (innholdstjenester på sms) Kortnummer (til tjeneste) og fast syntaks 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)

61 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

62

63 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.

64 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