BRsys – en påminnelse om et utdatert anskaffelsesregime

[Redaksjonen.]

BRsys – en påminnelse om et utdatert anskaffelsesregime

[Gjest Bruker-245639]

Takk!

 

Og få inn krav om at koden skal være fri og åpen.

[Henry Kleive]

Gode innspill ! Nå som BR reg må moderniseres, kanskje de kan invitere inn andre statlige/kommunale instanser og bygge en felles "bunnpanne" - infrastruktur - for en fremtidsrettet, moderne IT forvaltning?

[siDDis]

Bra med gode innspill. Offentlige bruker altfor mye penger på IT-systemer, og får altfor lite igjen. Det skyldes som regel at feil kompetanse tar beslutninger.

[Anders Jensen]

Gode innspill ! Nå som BR reg må moderniseres, kanskje de kan invitere inn andre statlige/kommunale instanser og bygge en felles "bunnpanne" - infrastruktur - for en fremtidsrettet, moderne IT forvaltning?

 

Det burde definitivt være en innsats for å samle offentlige IT systemer på felles... La oss kalle det _plattform_?!

 

Det er jo helt bak mål at alle skal sitte på sin egen datahall eller leie rack/hw hos en tredjepart. Samtidig er det ikke greit å lempe det ut i skya heller. I allefall ikke enda, kanskje aldri for noen etater.

[siDDis]

JA, spesielt kommunene burde slutte å drive sin egen IT avdeling, med egne fagsystemer. For å si det sånn, Stavanger kommune har titalls forskjellige fagsystemer for bare automasjon som alle skal løse samme problem som resten av Norge. Det er ikke Stavanger kommune sin feil, men loven for offentlig innkjøp som fordyrer og kompliserer dette. Resultatet er at det trengt flere ganger flere ansatte enn nødvendig. Og det er 1 kommune.

[DiamantGrevling]

Jeg er ikke noen systemutvikler, så kan ikke så så mye om artikkelforfatternes kommentarer om hvordan systemutvikling bør gjennomføres på generell basis. Jeg har likevel et inntrykk av at de ikke har satt seg tilstrekkelig inn i hva BRsys skal være og hvordan Brreg faktisk er bygget opp, herunder hvordan de forskjellige registrene (og systeme) henger sammen.

 

En av grunnene til mitt inntrykk er illustrasjonen som forfatterne bruker. De ser ut til å forstå at Brreg egen illustrasjon av "spagettien" viser de systemene som Brreg bruker i dag. Så hopper forfatterne til at dette enkelt kan deles opp i tolv forskjellige prosesser, slik at det egentlig ikke er spagetti. Her mener jeg forfatterne gjør en feil, da det ikke er snakk om enkeltprosesser mellom de forskjeligge systemene. Brregs illustrasjon viser kun i grove trekk hvilke koblinger systemene har mot hverandre, men dette innebærer mange flere prosesser enn forfatterne forenkler det til. Nå har forfatterne mer kunnskap om systemutvikling enn meg, så jeg er åpen for at denne forenklingen ikke svekker deres øvrige argumentasjon. Som et utgangspunkt blir jeg likevel skeptisk til deres forståelse når det gjør en så grov forenkling.

 

I alle tilfeller er det flere grunnleggende trekk ved de fleste registrene som vil gå igjen, slik som håndtering av innkommende saker og brev ut fra registrene. Videre vil det for registrering av informasjon og kontroll av denne være mange likheter. De fleste registrene registrere personer og opplysninger knytter til dem. Bør en ikke da gjenbruke Hvis det for eksempel blir endring i lovgivningen for personnummer, er det ikke da enklere at denne endringen kan gjøres i et system, i stedet for i mange forskjellige system? Det samme kan også gjelde ved endring i arkivloven, offentlighetsloven og en rekke andre lover som berører flere av registrene.

 

Slik jeg forstår forfatterne mener det at dette burde være løse gjennom flere små prosjekter (for hvert enkelt register?) Kan en ikke da støte på problemet at nye og gamle systemer ikke fungerer sammen? Som Brreg selv påpeker er enkelt av systemene over 25 år gamle. Jeg er åpen for at ved god planlegging kan dette kanskje unngås, men det høres ut som ekstraarbeid.

[Christin Gorman]

Veldig glad for denne kommentaren - det er nok mange som tenker som deg. Det er helt klart mange fellestrekk mellom forskjellige registere og tjenester. En søknad kommer inn, den skal saksbehandles, vedtas, brev skal generes og ting skal arkiveres. Det er lett å tenke seg at man kan lage et fint gjenbrukbart system for alle registre. Dette er det også veldig mange som har laget slike løsninger. Erfaringene fra disse er dessverre dårlige. Ta Altinn sin skjemamotor for eksempel. Her var tanken at man kunne lage en gjenbrukbar skjemaplattform, som alle offentlige etater skulle bruke for datainnsamling. Jeg jobbet for ikke lenge siden med å lage en ny elektronisk søknadsløsning statlig Bostøtte. Det første vi måtte gjøre var å se om vi kunne bruke Altinn sin plattform for dette. Men det måtte vi raskt slå fra oss, ettersom det å bruke Altinn ville innebære mye mer jobb, pluss at vi ikke ville være istand til å gjøre løsningen brukervennlig nok. Vi endte med å lage løsningen selv helt fra scratch. Den kostet mindre enn 30 millioner og vant prisen for årets digitale tjeneste.

Dette er bare ett enkelt eksempel. Det viser igjen og igjen at disse "one-size-fits-all" løsningene i praksis fører til systemer som både er komplekse å forvalte i tillegg til å være utrolig lite brukervennlige - har du noen gang vært i kontakt med offentlig byråkrati og fått inntrykk av at saksbehandleren ikke skjønner seg på din situasjon? At skjemaene og det du må fylle ut ikke er hensiktsmessig i forhold til akkurat ditt problem? "Alt-i-ett"-løsninger fører nesten per definisjon til slike situasjoner, ettersom de ikke er laget for å ivareta spesifikke brukerbehov, men heller å løse "alle problemer" på generelt grunnlag.

 

(Jeg er forresten enig i at diagrammet med prosesser og registre ikke er spesielt seriøst. Fra min side var den litt ment som en subtil kritikk av diagrammene presentert i den originale artikkelen. Spagetti-diagrammet presentert var åpenbart en ren karikatur og ganske useriøs - opplevde jeg.)

 

Håper dette var et oppklarende svar, og igjen takk for veldig bra spørsmål

-Christin Gorman

[Ola Thoresen]

Slik jeg forstår forfatterne mener det at dette burde være løse gjennom flere små prosjekter (for hvert enkelt register?) Kan en ikke da støte på problemet at nye og gamle systemer ikke fungerer sammen? Som Brreg selv påpeker er enkelt av systemene over 25 år gamle. Jeg er åpen for at ved god planlegging kan dette kanskje unngås, men det høres ut som ekstraarbeid.

 

Hovedpoenger her er vel å tenke litt mer "unix"-tankegang. Mange små, (forholdsvis) enkle prosesser, som gjør én enkelt "operasjon", og som kan snakke med hverandre gjennom (forholdsvis) enkle APIer.

 

Problemet med sånne gigantprosjekter er jo at de veldig ofte gaper over så mye av gangen at de ikke vet hvor de skal starte, og at det blir umulig å sette i drift enkelt-elementer før ALT er på plass, og dermed tar det fryktelig lang tid før man begynner å høste noen fordeler - og ofte vil tiden ha løpt fra deg innen du kommer så langt.

 

Ofte kan det være ekstremt mye å hente på selv veldig små forbedringer av deler av en prosess.

I mange tilfeller i dag er det jo sånn at den "digitaliseringen" som har blitt gjort med sånne prosesser er at man i stedet for å fylle ut et papirskjema og sende i posten, så har det blitt laget en PDF-utgave av nøyaktig det samme skjemaet, som så kan fylles ut på på "søkerens" PC, og lagres og sendes som epost.

Deretter printes skjemaet så ut av mottaker-enden, for at infoen så skal tastes inn i et nytt saksbehandlings-system, og "originalen" lagres i et arkiv.

 

Når man planlegger å fornye dette systeme, så lager man seg en grandios plan, som omfatter digitalt arkivsystem, nytt saksbehandlingssystem, ny frontend for innsending av skjemaer (som skal være så fleksibel at den fungerer for alle tenkelige nye skjemaer) osv.

Dermed blir det dyrt, det tar ufattelig lang tid, og koster enormt med ressurser å planlegge og designe løsningen fordi alt må være perfekt fra starten. Og du sparer ingenting i noen ende før både saksbehandlere og arkiver er konvertert til ny løsning.

 

Men det man _egentlig_ kan begynne med er f.eks. i avsender-enden. Lag en ny (html) versjon av et skjerma, med litt intelligens, sånn at kun relevante felter blir synlige for brukeren. Forhåndsutfyll all info man allerede "vet" (brukerne er jo gjerne logget inn på ett eller annet vis, så du _vet_ navn, adresse, fødselsdato osv. Og _trenger_ du egentlig den informasjonen for å behandle saken?).

 

La gjerne skjemaet generere en PDF til saksbehandlerne i første omgang, hvis de foretrekker det, men allerede her har du spart mange årsverk totalt for dem som fyller ut skjemaene, ved å forenkle utfyllingsprosessen. Så kan prosessen med inntasting i sakssystem og akrivering fungere som i dag.

 

Så tar man ett og ett skjema, og gjør samme jobb. Her er det selvsagt kode som kan gjenbrukes, og kanskje ser man at noen skjemaer kan slås sammen, eller noen bør splittes opp, eller det kan gjøres andre forbedringer samtidig. Men ikke overtenk dette skrittet.

 

Skritt tre - endre infoen som sendes til saksbehandlere, sånn at de får raskere tak i den viktigste informasjonen, og kjapt kan legge den inn i sakssystemet. Send gjerne fortsatt en PDF til arkivet. Dagens PDFer er jo ikke nødvendigvis strukturert sånn at de er enklest mulig å behandle. Ofte er det flere sider og deler som bare skal fylles ut hvisomatte, dersomatte. Ofte er det felter som er for små til å få plass til all relevant info, og det må legges inn egne vedlegg. Med et "smartere" skjema i utgangspunktet kan man rimelig enkelt sørge for at det viktigste kommer først, og blir mest tydelig. Og alt som ikke er relevant heller ikke er med.

 

Skritt tre - lag en connector til sakssystemet som dytter info inn der. Det er sikkert et gammelt system, men det _er_ en database i bunnen et sted. Lag det enkelt, så i alle fall grunnleggende info om saken er kommer på på plass automatisk, og så kan saksbehandler evt. supplere med mer info fra eposten hvis det er komplisert å få inn alt via bakdørene.

Juster litt på skjema-innsendingen, så den legger ved en form for strukturerte data når man trykker "Send inn", så slipper du å parse en PDF eller epost.

 

Ingenting av dette koster milliarder i utvikling. Og det vil spare både "søkere" og "saksbehandlere" for masse, masse tid.

 

SÅ kan du begynne å se på nye arkivsystemer og sakssystemer. Og når et nytt arkivsystem begynner å komme på plass, så er det ganske enkelt å tilpasse den prosessen som sender PDF så den fungerer mot det nye arkivsystemet.

Og siden du allerede har en connector som legger info inn i det gamle sakssystemet, og dataene du får fra "søkeren" er strukturerte, så er det mye enklere å fôre dem rett inn via det nye, flotte APIet.

[Bolson]

... snip

Det er en del problemer med din fremgansmåte/tankerekke.

 

De første er at funksjonaliteten i dagens system allerede er langt forbi det du presenterer. Data flyttes elektronisk via skjema alt i dag. Så å etablere noe som har mindre funksjonalitet er ikke en mulighet.

 

Skjemadelen er allerede for en stor del intelligent og forhåndsutfyller. F.eks når jeg skal registrere i enhetsregisteret så hentes all informasjon knyttet til personer om jeg taster inn førdselsnummer.

 

Hovedproblemet slik jeg ser det er faktisk grunnmuren, dvs database og den nærmeste grunnmuren rundt (databaseapplikasjonene) er bygd med et verktøy som nærmer seg "end of life".

 

Problemet er altså at man skal erstatte et modent system med forholdsvis omfattende funksjonalitet - og som faktisk har kommet langt forbi pdf-skjemaet med et nytt system. Ikke fordi systemet ikke virker (det virker relativt sett bra), men fordi det faktisk begynner å gå på sikkerheten løs. Da er jeg langt fra sikker på at man kan tenke fullt så trinnvis. 

 

Jeg er på ingen måte uenig deler av kritikken som er kommet, selv om jeg nok tror den delvis bommer på målet. Men på generelt grunnlag er den korrekt.

 

Dog, det som forundrer meg mest, er at ingen faktisk kommenterer det viktigste punktet i kommentaren - nemlig hvor "håpløst" anskaffelsesreglementer er. Jeg er nemlig overbevist om at endres anskaffelsesreglementet for IT-prosjekter mot utviklingsprosjekter og innovasjon og åpner for større bruk av forenkla prosedyrer - da vil endring i hvordan man utvikler IT i det offentlige komme raskt. Taler tildels av egen erfaring, har de siste to årene vurdert flere mulige anbud hvor det "samarbeidet" jeg fungerer i trolig kunne levert rimeligste og mest innovative løsningen - men formalia etc har hindret oss.

[Gjest Bruker-245639]

Slik jeg kjenner det offentlige som bruker så ville jeg gjerne sett mer fokus på informasjonsflyt mellom de forksjellige fagsystemene. Da vil jeg tro at en måtte begynne med å bygge små komponenter som var veldig flnike på sin ting. Og så måtte en endre lovverk og forskrifter for å tillate og påby informasjonsflyt mellom disse. Oppå der kan en så bygge hva en vil av skjema og rapporter.

 

Da har en UNIX og DB tankeganger forent, og jeg tror at vi vil ha bygget seg ut av et hjørne og inn for fremtiden. Og som jeg skrev først i tråden, sørg for at all koden som skrives er fri og åpen og lagres i en github.

[Civilix]

(...)Det første vi måtte gjøre var å se om vi kunne bruke Altinn sin plattform for dette. Men det måtte vi raskt slå fra oss, ettersom det å bruke Altinn ville innebære mye mer jobb, pluss at vi ikke ville være istand til å gjøre løsningen brukervennlig nok.(...)

Som bruker har jeg et veldig godt forhold til altinn, så hadde vært interessant å hører mer om hvordan det hindret brukervennligheten.

 

Synes for så vidt også at "det ville innebære mer jobb" er ett veldig dårlig argument, selvfølgelig er det mer jobb når man kan ha systemer som integreres med andre.

[Christin Gorman]

i den elektroniske søknaden for Bostøtte integrerte vi med ID-porten, folkeregisteret, skatt, nav, matrikkelen, kontaktregisteret og ePhorte. Med "det ville innebære mer jobb", så mener jeg ikke at vi kuttet ned på integrasjonene. De måtte vi ha med. Men å gjøre alt vi hadde gjort, MED Altinn sin skjemamotor, det tror jeg neppe hadde vært mulig. Skjemaene til Altinn fungerer - ingen tvil om det. Men jeg vil si at vår løsning var enda mer brukervennlig. Jeg nevnte allerede at vi vant Difi sin Årets digitale tjeneste, men vi vant også prisen "Merket for god design". Det å ha full frihet til å lage akkurat det som er best for akkurat det bruksmønsteret man skal støtte, gjør det mye lettere å lage gode brukervennlige løsninger.

[Kimble]

 

Slik jeg forstår forfatterne mener det at dette burde være løse gjennom flere små prosjekter (for hvert enkelt register?) Kan en ikke da støte på problemet at nye og gamle systemer ikke fungerer sammen? Som Brreg selv påpeker er enkelt av systemene over 25 år gamle. Jeg er åpen for at ved god planlegging kan dette kanskje unngås, men det høres ut som ekstraarbeid.

 

Hovedpoenger her er vel å tenke litt mer "unix"-tankegang. Mange små, (forholdsvis) enkle prosesser, som gjør én enkelt "operasjon", og som kan snakke med hverandre gjennom (forholdsvis) enkle APIer.

 

Problemet med sånne gigantprosjekter er jo at de veldig ofte gaper over så mye av gangen at de ikke vet hvor de skal starte, og at det blir umulig å sette i drift enkelt-elementer før ALT er på plass, og dermed tar det fryktelig lang tid før man begynner å høste noen fordeler - og ofte vil tiden ha løpt fra deg innen du kommer så langt.

 

Ofte kan det være ekstremt mye å hente på selv veldig små forbedringer av deler av en prosess.

I mange tilfeller i dag er det jo sånn at den "digitaliseringen" som har blitt gjort med sånne prosesser er at man i stedet for å fylle ut et papirskjema og sende i posten, så har det blitt laget en PDF-utgave av nøyaktig det samme skjemaet, som så kan fylles ut på på "søkerens" PC, og lagres og sendes som epost.

Deretter printes skjemaet så ut av mottaker-enden, for at infoen så skal tastes inn i et nytt saksbehandlings-system, og "originalen" lagres i et arkiv.

 

Når man planlegger å fornye dette systeme, så lager man seg en grandios plan, som omfatter digitalt arkivsystem, nytt saksbehandlingssystem, ny frontend for innsending av skjemaer (som skal være så fleksibel at den fungerer for alle tenkelige nye skjemaer) osv.

Dermed blir det dyrt, det tar ufattelig lang tid, og koster enormt med ressurser å planlegge og designe løsningen fordi alt må være perfekt fra starten. Og du sparer ingenting i noen ende før både saksbehandlere og arkiver er konvertert til ny løsning.

 

Men det man _egentlig_ kan begynne med er f.eks. i avsender-enden. Lag en ny (html) versjon av et skjerma, med litt intelligens, sånn at kun relevante felter blir synlige for brukeren. Forhåndsutfyll all info man allerede "vet" (brukerne er jo gjerne logget inn på ett eller annet vis, så du _vet_ navn, adresse, fødselsdato osv. Og _trenger_ du egentlig den informasjonen for å behandle saken?).

 

La gjerne skjemaet generere en PDF til saksbehandlerne i første omgang, hvis de foretrekker det, men allerede her har du spart mange årsverk totalt for dem som fyller ut skjemaene, ved å forenkle utfyllingsprosessen. Så kan prosessen med inntasting i sakssystem og akrivering fungere som i dag.

 

Så tar man ett og ett skjema, og gjør samme jobb. Her er det selvsagt kode som kan gjenbrukes, og kanskje ser man at noen skjemaer kan slås sammen, eller noen bør splittes opp, eller det kan gjøres andre forbedringer samtidig. Men ikke overtenk dette skrittet.

 

Skritt tre - endre infoen som sendes til saksbehandlere, sånn at de får raskere tak i den viktigste informasjonen, og kjapt kan legge den inn i sakssystemet. Send gjerne fortsatt en PDF til arkivet. Dagens PDFer er jo ikke nødvendigvis strukturert sånn at de er enklest mulig å behandle. Ofte er det flere sider og deler som bare skal fylles ut hvisomatte, dersomatte. Ofte er det felter som er for små til å få plass til all relevant info, og det må legges inn egne vedlegg. Med et "smartere" skjema i utgangspunktet kan man rimelig enkelt sørge for at det viktigste kommer først, og blir mest tydelig. Og alt som ikke er relevant heller ikke er med.

 

Skritt tre - lag en connector til sakssystemet som dytter info inn der. Det er sikkert et gammelt system, men det _er_ en database i bunnen et sted. Lag det enkelt, så i alle fall grunnleggende info om saken er kommer på på plass automatisk, og så kan saksbehandler evt. supplere med mer info fra eposten hvis det er komplisert å få inn alt via bakdørene.

Juster litt på skjema-innsendingen, så den legger ved en form for strukturerte data når man trykker "Send inn", så slipper du å parse en PDF eller epost.

 

Ingenting av dette koster milliarder i utvikling. Og det vil spare både "søkere" og "saksbehandlere" for masse, masse tid.

 

SÅ kan du begynne å se på nye arkivsystemer og sakssystemer. Og når et nytt arkivsystem begynner å komme på plass, så er det ganske enkelt å tilpasse den prosessen som sender PDF så den fungerer mot det nye arkivsystemet.

Og siden du allerede har en connector som legger info inn i det gamle sakssystemet, og dataene du får fra "søkeren" er strukturerte, så er det mye enklere å fôre dem rett inn via det nye, flotte APIet.

Jeg kunne ikke vært mer enig! Ved å erstatte alle disse gammeldagse papirskjemaene med intelligente varianter oppnår man mindre irriterte brukere og færre unødvendige runddanser i byråkratiet pga. fullstendig unødvendige feil.

[Kimble]

Personlig skulle jeg gjerne sett at man brukte 1.2 mrd på å fjerne / forenkle skjema, prosesser, lover og forskrifter. I dag bruker vi så hinsides mye tid og penger på å skape digitale varianter av prosesser fra steinalderen. Først når man er sikker på at man ikke kan gjøre disse tingene enklere bør man begynne å implementere digitale prosesser rundt dette. 

[Espen Sjøvoll]

I alle tilfeller er det flere grunnleggende trekk ved de fleste registrene som vil gå igjen, slik som håndtering av innkommende saker og brev ut fra registrene. Videre vil det for registrering av informasjon og kontroll av denne være mange likheter. De fleste registrene registrere personer og opplysninger knytter til dem. Bør en ikke da gjenbruke Hvis det for eksempel blir endring i lovgivningen for personnummer, er det ikke da enklere at denne endringen kan gjøres i et system, i stedet for i mange forskjellige system? Det samme kan også gjelde ved endring i arkivloven, offentlighetsloven og en rekke andre lover som berører flere av registrene.

 

 

Jeg kjenner ikke til disse registrene, men kan på generelt grunnlag og som produkteier i et team som jobber med bl.a. felleskomponenter si at det er mulig å lage dette og håndtere det effektivt, men det er noen forutsetninger:

1. Felles dataregistre. Det er ganske bred enighet om at data bør hentes fra én plass fremfor å replikeres så lenge det er hensiktsmessig. Det er funksjonaliteten som er utfordringen.

2. Behovene må være tilnærmet like. Innlogging kan være et eksempel på en felleskomponent fordi denne funksjonen typisk kan støtte flere typer pålogging. Behovene er like fordi man i alle tilfeller trenger å få logget sikkert på og av. Men et arkiv er ikke bare et arkiv i alle tilfeller. Ett system kan ha behov for enkle data, et annet kan ha behov for å lagre spesielle filer, et annet system kan ha behov for en helt annen filstruktur osv, og utfordringene står i kø med en gang noen skal gjøre en endring i fellessystemet. Det er da "spaghettien" blir uhåndterbar. Det kan godt hende at "håndtering av innkommende saker og brev ut fra registrene" er gode eksempler på fellesløsninger, men alt er avhengig av behovene hos bruker og saksbehandler. En god utprøving av dette vil gi deg svar på hvor gjenbrukbart dette er mellom produktene.

3. Minimumsløsning. Man kan ende opp med en minimumsløsning i de tilfellene der det er sprikende behov mellom de systemene som skal bruke fellesløsningen, men her vil man til en viss grad også støte på utfordringer der endringer på arkitekturen må ta høyde for påvirkningen og ringvirkningene i de tilknyttede systemene. Det er også en løsning å kopiere kode, der fellesløsningen eller siste utviklede løsning presenterer en slags "beste praksis" som gjør at man raskere kommer i gang og står fritt til å gjøre de nødvendige endringene for sitt system uten at det påvirker andre.

4. Kompetansedeling. Uansett hvor mye eller lite man blir enig om å bruke av felleskomponenter eller kode er det viktig at kompetansen deles mellom de systemansvarlige. Å lære av hverandres kode, forstå hvordan og hvorfor ting virker som de gjør, hvorfor endringer gjøres, lære av hvordan vi jobber sammen osv. er essensielt for å holde orden i "spaghettien".