Dagens tema Systemutvikling og omstilling i praksis. Noen eksempler på IKT og omstillingsprosjekter i staten Forelesning i FINF 4001, 24. august 2010 Felt for signatur(enhet, navn og tittel) 3 eksempler: Skatt, Samordnet opptak, Lånekassa Teoretiske og faglige perspektiver på informasjonssystemer og systemutvikling Mål, rammer, aktører, omgivelser Perspektiver og tenkemåter Systemutvikling eller organisasjonsutvikling Forholdet mellom IKT-politikk og systemutviklingsfag Litteratur Avison & Fitzgerald, Information Systems, Kap. 1-7 Dahlbom og Mathiassen, kap. 3-6 Jansen & Schartum 2008, kap. 5-7 3 cases gjennomgås Skatteetaten, Flid-prosjektet Samordnet opptak Lånekassa Forskjeller mht Størrelse utbredelse Profesjonell organisasjon Antall og type brukere Rammer og policy Skatteetaten langsiktige strategier FLID-prosjektet: Folkeregister og ligningskontor Innføring av Data Første gang ligningskontorene fikk effektivt saksbehandlingsverktøy lokalt Fase Periode Hensikt Oppgave LSP: Langsiktig systemplanlegging 1983-85 Kartlegging av behov for økt bruk av edb i hele Skatteetaten, og utarbeiding av en samlet strategi/plan for dette. FLID-prosjektet: Utvikling og utprøving. FLID-prosjektet: Gjennomføring Omstillingsoppfølging 1986-91 Utvikling og utprøving av egnede edb- og organisasjonsløsninger for likningskontor og folkeregisterkontor, samt utarbeiding av en samlet prosjektplan for gjennomføringen. 1991-94 Gjennomføring av edb-anskaffelse og innføring og omstilling av alle landets likningskontor og folkeregisterkontor. 1994-96 Videre oppfølging i linjeorganisasjonen av den planlagte omstillingen ved kontorene for å sikre at den blir fullført og at gevinstene blir sikret. FLID: Del av et større utviklingsog omstillingsprogram 1982-96 Startet som teknologiutvikling, resulterte i Forenklet ligning og verdiorientert arbeid (regelendringer og org. omstilling) Skifte i fokus (målformulering) fra rasjonalisering/effektivisering til informatisering : Bedre tjenester (økt kompetanse) og økt kvalitet (gevinstrealisering på flere plan) Prosjektet ble gjennomført i tett samarbeid med arbeidstagerorganisasjonene 20 % av budsjettet til bl.a. kompetanseheving FLID: Del av et større utviklingsog omstillingsprogram 1982-96 I FLID-arbeidet ble det lagt stor vekt på å utvikle en prosjektorganisasjon og prosjektlederkompetanse i etaten I tillegg til innføring av edb, skulle prosjektet omfatte en gjennomgripende fornyelse av forvaltningsområdet (i tråd med fornyelsesprogrammet Den Nye Staten ) Prosjektet resulterte i en omfattende reorganisering av Skatteetaten 1
Skatteetaten som godt eksempel Lånekassa retter seg mot kundene Klarer å møte store utfordringer Omfattende regelendringer skal iverksettes og testes hvert år Samtidig utvikles tjenestene i tråd med rådende IKT-politikk IT-arbeidet er solid forankret i SU- og OU-fagene Relativt konservativ strategi, velprøvd teknologi Gjør mye riktig Jf. Statskonsults FASIT -prosjekt, midt på 90-tallet Dog noen anmerkninger fra Riksrevisjonen om saksbehandlingskvaliteten og prioriteringer ganske nylig Har utviklet en svært omfattende IT-organisasjon Kanskje ikke noe som alle etater har mulighet for å kopiere? Blir etaten i for stor grad styrt av teknologers verdensbilde? 1994 Maskinell søknadsbehandling, men papirbasert søknad 2000 Pilotprosjekt for elektronisk søknad ved Høgskolen i Gjøvik Piloten basert på spesialiserte PC-kiosker (pga av sikkerhet) 2004/2005 Første elektroniske løsning, med sikkerhetsløsning basert på Buypass, tippekortet 2008/2009 Sikkerhetsløsning integrert med Altinn/MinSide Verdikjeden i Lånekassen Noen momenter fra Lånekassa Papir eller selvbetjening Søknad Annen datafangst: - læresteder - andre tredjeparter Behandling Vedtak/ gjeldsbrev Valgfri signatur: - elektronisk - papir Utbetaling til bankkonto Endret kundeopplevelse Elektroniske kommunikasjon Kunden opplever bare å forholdes seg til Lånekassa, (før var også både lærestedet og banken en del av runddansen hvert semester) Stor vekt på datafangsten Innhenting av opplysninger fra ulike hold Det ble behov for konkrete lovhjemler for innhentingen Særskilte krav til sikkerhetsløsninger Spesielt det å signere gjeldsbrev, krever både høyt sikkerhetsnivå og en notariusfunksjon (tredjepartsverifisering) Selvbetjeningsløsningen passer for størstedelen av sakene, men en del unntak tas (delvis) manuelt Samordna opptak - fra kaos til automatisert opptak Den norske opptakstradisjonen er basert på desentrale opptak En rent sentralisert opptaksfunksjon ikke politisk mulig eller ønsket Behov for å forene lærestedenes autonomi og en lokal behandling med visse nasjonale målsetninger: Oversikt og styrbarhet Effektivisering, unngå unødig dobbeltarbeid Unngå overbooking, at studentene som har de beste karakterene legger beslag på alle studieplassene helt til kabalen faller på plass, mens andre som også er kvalifiserte venter i uvisshet Samordna opptak - fra kaos til automatisert opptak Tekniske hovedutfordringer Fleksibilitet i saksbehandlertildeling Koding av opptaksregelverk (kompetanseregler, rangeringsregler) delautomatisering ti i av saksbehandling Koding og automatisert beregning og kontroll av elektroniske vitnemål fra videregående skole EFN kapittel 6: Mange interessante refleksjoner, les! Systemutvikling som skapte et eget opptaksfag Systemets ubønnhørlighet mindre rom for skjønn Hvor står vi veien videre Visjonen om papirløst, fullautomatisert og løpende opptak, sikker autentisering 2
Samordna opptak: Grunnmodellen omfatter saksbehandlingssystemer ved lærestedene, SO-basen, registreringsbasen med mer Lokalt opptaks System (FS) Lokalt opptaks System (FS) UNINETT Lokalt opptaks System (MSTAS) SO sentraldatabase, Registreringsdatabasen, Nasjonal vitnemålsdatabase Universitetet i Oslo 13 Generelt om informasjonssystemer (IS) IS karakteristika Menneskelig konstruksjon Knyttet til bestemt(e) arbeidsoppgave(r) Eies av en organisasjon i forandring, og ofte mange interessenter t med ulike krav Ulike motivasjoner for utvikling av IKT-baserte IS Rasjonalisering/effektivisering, bedre tjenester, økt kvalitet, omorganisering, strategisk bruk (forme adferd) Automatisering av beslutninger, beslutningstøtte, ledelsesinformasjon, standardisering av saksbehandling Avison & Fitzgerald, IS development Overblikk og temaer (kap. 1-9 ) Kap. 1-3 : Forstå IS, omgivelser og kontekst Introduksjon og kritikk av livsyklusmodellene Kap. 4-9 Temaer i IS utvikling Organisatoriske temaer Modellering Prosess-, data, og objekt-modellering Programvareutvikling Konstruksjon, evolusjonær utvikling, prototyping vevutvikling.. Menneskeperspektiver Brukere og brukerdeltaking, kunnskapsforvaltning mm Ekstern utvikling: kjøp av standardpakker, utskilling, mm 15 Teknikker og verktøy (Kap 10-18) Holistiske analyseteknikker Rike bilder, rot-definisjoner Data (modellerings-) teknikker (Entity-Relationship etc.) Prosess (modellering-) teknikker: Dataflyt, beslutningstabeller, tilstandsdiagrammer Objekt-orienterte modellering /teknikker OOA&D, UML & Use cases Teknikker for å analysere organisatoriske og menneskelige faktorer Kritisk suksess-faktorer, risiko-analyse, SWOT Verktøy Metodologier og rammeverk (kap. 19-25) Hva er en metodologi ( metodikk ) En samling av prosedyrer, metoder, teknikker og dokumentasjonsstøtte som skal bistå systemutviklere i å planlegge, gjennomføre, kontrollere og evaluere arbeidet... Den vil omfatte faser og retningslinjer for valg av teknikker og verktøy.. Prosess-orienterte, for eksempel Strukturert analyse (SA) Blandete metoder (eks SSADM, både SA og datamodellering) Metodologier og rammeverk (kap. 19-25) Objekt-orienterte metodologier Mathiassen OOA&D RUP (rational unified process) Use cases &UML(U (Unified modelling language) Smidige metoder (agile development) Lite formalisering og dokumentasjon Holde tidsfrister gjennom timeboxing Bruke tid og krefter der det trengs, ikke kvele kreativitet osv. Scrum, RAD, XP, Web-dev. Menneske- og organisasjonsorienterte metodologier Sosio-teknisk tilnærming/ethics, Soft System methodology 3
Systemer, perspektiver og tenkemåter Systemer (Dahlbom og Mathiassen, kap. 3-6) Teknologi, data, informasjon og kunnskap Rasjonell versus romantisk tenkemåte Systemutvikling: utforming og realisering (development) Konstruksjon (spesifikasjonsstyrt), evolusjon (skrittvis, prøving og feiling), intervensjon (problem- og konflikt-orientert, provokasjoner og sammenbrudd som fremgangsmåter) Den skandinaviske skole (mer om den på et senere lysark) Systemkvalitet (kap. 7-9) Artefakters kvalitet er ikke uavhengig av kontekst Kultur & estetikk, makt & politikk Ulike grunnleggende tenkemåter Hard systems thinking Utgangspunktet er Descartes mekanistisk systemforståelse Klar, eksakt og sann representasjon av verden Verden er stabil Reduksjonisme, gjentagbarhet/ forkastbarhet Soft systems thinking Utgangspunkt i organisk, dialektisk forståelse av virkeligheten Verden må forstås som helheter kan bare beskrives ved fortolkning Virkeligheten er i stadig forandring uforutsigbar Ulike grunnleggende tenkemåter Hard systems thinking Verden oppfattes som en maskin - f eks. som byråkratier med formell arbeidsdeling og styring Alle egenskaper i systemets øvre/abstrakte lag finnes også som representasjoner i de mer maskinnære detaljene Den logiske, analytisk tenkende maskin (Babbage, Turing, von Newman) Soft systems thinking Organisasjoner koordineres ved uformell, direkte interaksjon mellom medlemmene I systemets høyere (mer abstrakte) lag, vil det kunne fremkomme nye egenskaper som man ikke kan finne igjen i detaljlagene Datamaskinen som medium for menneskelig samhandling Forståelse av organisasjonen: Maskin eller kultur? Byråkratiet Nøyaktig beskrivelse av arbeidsoppgaver Organisasjon som optimal algoritme Stabile omgivelser Rasjonalitet og effektivitet Entydige mål Forutsigbarhet lav usikkerhet Organismen Dynamisk samspill med omgivelsene må ofte respondere på endring Forandring skaper usikkerhet Liten grad av formalisering Samspill mellom relativt selvstendige enheter Tette nettverk uformelle strukturer kan ha mye å si Sosio-teknisk systemutvikling ( den skandiaviske skolen ) Røtter bl.a. fra samarbeid mellom fagbevegelse og informatikere på 1970-tallet Bekymring for at effektiviserende systemer overkjørte arbeiderne Krav til å involvere bedriftens medbestemmelsesapparat i arbeid med systemer for planlegging og gjennomføring av arbeidet inn i arbeidsmiljøloven av 1977 Brukere = ansatte ( bruker = tjenestemottaker vanligere i dag?) Likestiller tekniske og sosiale sider ved systemene Kompromisser mellom interesser i en organisasjon Systemutvikling skal også omfatte organisasjonsutvikling og læring Tradisjonell SU fokuserer problemet men glemmer ofte brukssituasjonene Virkeligheten Problemområdet: Formål/oppgave, eksempel: - Økonomistyring - Studentregistrering Modell av virkeligheten Anvendelsesområdet: Del av brukerorganisasjonen, eks: Økonomiavd., eller selvbetjening Studentenes egen hverdag 4
Systemutvikling og livssyklus faser i systemutviklingsarbeidet Forstudie - Foranalyse : Problem og mulighetsanalyse - avdekke problemer mm Systemavgrensning og behovsanalyse Se systemet utenfra og klarlegge behov og rammer : tekniske, organisatoriske, økonomiske, juridiske, sikkerhet Systemanalyse -> kravspesifikasjon Systemutforming : (design/konstruere) Systemutvikling og livssyklus faser i systemutviklingsarbeidet Realisering og implementasjon Bruk/Drift Videreutvikling og endring Avvikling Vi sier så langt ingenting om hvordan de ulike faser skal utføres (metoder, verktøy), hvilke rekkefølge, iterasjoner mm Hvorfor ulike metodologier Utviklingsmodeller Målet for et SU-prosjekt vil være svært forskjellig Konstruksjonsprosess, OU-prosess, ledelsesstyrt (politisk) prosess Egenskaper ved det ferdige system er forskjellig Eks. database, vev-tjeneste, transaksonssystem Ulike rammebetingelsene rundt utvikling av systemet Tekniske, organisatoriske, økonomiske, juridiske,.. SU-prosjektet organiseres på ulike måter Top-down, Bottom-up Spesialiststyrt vs. brukerstyrt ( og hvem er egentlig bruker?) Også referert til som prosessmodell for programvareutvikling Handler om å styre utviklingsprosessen, sikre at den kommer i mål Mer overordnet styringsperspektiv enn de ulike konkrete metodene for analyse og konstruksjon etc. Fokusere på hva som skal gjøres i de ulike delene / fasene og hvor lenge det skal gjøres Ulike avveininger bak valg av utviklingsmodell Budsjett, tidsplan og avhengighet til andre/eksterne aktiviteter Holde ønsker og ambisjoner i tømme, eller ta inn nye ideer og mulige forbedringer underveis? Hvor mye av omgivelsene er kjente/ukjente? Utviklingsmodeller Enkel livssyklus : Fossefallsmodellen En utviklingsmodell beskriver Hvilke faser utviklingen består av Hvilken rekkefølge fasene skal komme i Etablerer kit kriterieri for overgang fra en fase til neste (dvs. inngangskriterier og avslutningskriterier for de ulike fasene) Kriteriene kan blant annet omfatte produksjon av dokumentasjon, akseptansetesting av kjørbar programvare, formelle beslutninger som skal treffes av styringsgruppe etc. Representerer ulike tilnærminger til systemutvikling Grunnleggende tenkesett (à la Aristoteles vs. Platon eller Descartes vs. Hume etc., eller kanskje TV-serien Hjernevask ) Hvilken vekt som legges på forskjellige hensyn: Måloppnåelse, brukermedvirking/demokrati, tilpasning til organiseringen 5
Spiralmodellen Forsøk på å kombinere evolusjonær tankegang og konstruksjonstenkning Fokus på risiko og reduksjon av risiko Utvikling oppdelt i sykler, = iterasjoner i spiralen Målsetning (hva skal oppnås f.eks. funksjonalitet, ytelse, etc.) Alternative måter å realisere løsning for dette (utvikle, kjøpe, etc.) Identifisere begrensningene (kostnad, grensesnitt, etc.) Forholdsvis bundet prosess: Et fossefall som er krøllet sammen? Agil utvikling timeboxing Faser i Systemutviklingsarbeidet (SU) den organisatoriske siden (OU) Problemidentifisering og problemanalyse (diagnose): Fastsette mål for endringsarbeidet Klarlegge endringsbehov Beskrive (utforme) organisatoriske endringer Nye rutiner, prosedyrer, ansvars- og beslutningsstrukturer etc. Beskrive opplæringsbehov Realisere og gjennomføre endringene Opplæring, motivasjon,.. Igangsette ny organisasjonsform Analyse og design henger sammen Faser i SU rettslige aspekter Nye behov og krav vil ofte framkomme under design (og under realisering /implementasjon) Behov for og konsekvenser av organisatorisk endring Læring (i alle faser av arbeidet) er en viktig del av SU-aktivitetene Omgivelsene og rammebetingelsene forandrer seg ofte (praktisk talt alltid) underveis Systemutvikling er ikke kun utvikling av det tekniske system, men like mye endring av ikke-teknologiske organisatoriske forhold 35 Endringer i regelverket kan være en begrunnelse for et SU-prosjekt Pensjonsreformen, Nye barnebidragsregler, individuell plan for hjelpetrengende med sammensatte medisinske og sosiale behov Endringer i regelverket kan være en nødvendig og planlagt del av et SU-forløp (men ikke hovedbegrunnelsen) Lånekasse-prosjektet, delvis også skatteprosjektene Endringer i regelverket kan komme som en (utilsiktet?) konsekvens av SU-prosjektet Brukermedvirkning som (begrenset) rettighet 6
Ulike syn og perspektiver på utvikling av informasjonssystemet Konstruksjonsprosess Utvikle et ny teknisk løsning, som et verktøy. (f eks. implementere en endring i regelverket) Teknisk k og organisatorisk i forandringsprosess Studentweb, elektronisk ligning, Lånekassa web-baserte søknadsbehandlersystem Erkjennelsesprosess Analyse av organisasjonen: f eks. SAP-prosjekter, ligningsetatens FLID-prosjekt, innføring av kundestøttesystemer i bedrifter Forskjeller også i ulike tjenestemottakeres forventninger (Studenter i dag ville synes tidlig 90-talls giro-køer var håpløse, pensjonister likte dårlig å ikke få utbetalingsbekreftelse i posten ) Nyttig(?) øvelse Les beskrivelsen av de 3 casene, Schartum og Jansen kap. 5-7 I hvor stor grad referer disse beskrivelsene til gjeldende (eller tidligere) IKT-politikk og forvaltningspolitikk? Beskrivelsen av casene tar i stor grad opp teoretiske og faglige betrakninger om IS og systemutvikling IKT-politikken er i relativt liten grad synliggjort, men man kan nok si den svever over vannene, som en ikke særlig tydelig uttrykt premiss 7