Modernisering av Lånekassens IT-systemer

Transkript

1 Modernisering av s IT-systemer Nettverksmøte 11.desember 2014 i Trondheim Helge Lysaker Løsningsarkitekt Innhold og oppdraget Litt om gjennomføring Løsninger Erfaringer 1

2 Innhold og oppdraget Litt om gjennomføring Løsninger Erfaringer Tildeler lån og stipend til kunder i utdanning Håndterer tilbakebetaling av lån En rekke ordninger for lette i tilbakebetalingen Volumer som skal håndteres aktive kunder (over 2 millioner totalt) Over saker årlig 137,9 milliarder i utlånsportefølje 30 milliarder i inn- og utbetalinger årlig søknader i ,3 millioner inn- og utbetalinger i ,7 millioner besøk på lanekassen.no og 5,7 millioner på Dine sider telefonanrop e-post til kundesenteret 299 årsverk i totalt De fleste vedtak gjøres i dag automatisert (Tildeling av støtte: 63% automatiserte vedtak) 2

3 Oppdraget -> LØFT-programmet Stortingsmelding nummer 12 ( ) Om modernisering av Statens lånekasse for utdanning. Organisasjonstilpasninger (Kjernelånekassen) Regelverksutvikling / kontrollsystem Nye arbeidsformer Ny IKT-løsning (Modulis) LØFT-programmet: Et av de største moderniseringsprosjekter som er gjennomført i offentlig sektor de siste årene 10 år oppstart i 2004 og avsluttet i (Liten leveranse til i 2015) Prosjektet har bestått av over 100 personer i de mest intensive fasene Kostnadsramme på 815 millioner kroner har bidratt med egenfinansiering på 361 millioner kroner over driftsbudsjettet. (Reduksjon av ansatte) Oppdraget: Myndighetenes krav til løsningen I utgangspunktet stilte myndighetene følgende krav til prosjektet En hovedleverandør Løpende vurdering av utsetting av tjenester Ny løsning basert på standard programvare LIS skal fases helt ut etter avsluttet prosjekt Økt selvbetjeningsgrad for kunder Opprettholde og legge til rette for en økning i automatiseringsgrad i saksbehandlingen skal ha full drift i prosjektperioden Tilpasning av regelverket til nye arbeidsformer og standard programvare Gevinstrealisering 3

4 Innhold og oppdraget Litt om gjennomføring Løsninger Erfaringer LØFT veien til målet 4

5 Innhold og oppdraget Litt om gjennomføring Løsninger Erfaringer Fra LIS til Modulis LIS Nettsøknad Dine Sider Datavare hus Manuell saksbehandling Kunde og lærested Saksautomatisering Lån Datautveksling/eksterne grensesnitt Utsendelse LIS: Stormaskin utviklet tidlig 80-tall Modulis: Tjenesteorientert arkitektur 5

6 Migreringsstrategi Fase 1 Arkitektur + 2 sakstyper Fase sakstyper Fase sakstyper Fase 3 Lånemodul Resten av sakstypene LIS - stormaskin Modulis Overordnet om løsningskomponentene Teknisk arkitektur Løsningen er modularisert og tjenesteorientert. Hovedteknologi: Microsoft Presentasjonslag P360 Nettsøknader Egenutviklet skjermbilder Forretningslag P360 Manuell saksbehandling Tjenestebuss, BizTalk Regelmotor, Inrule Tjenestekatalog med egenutviklede tjenester Periodiske jobber Datalag P360 MSSQL-databaser 6

7 Funksjonell arkitektur Gjennom forprosjektet i 2007 ble det etablert viktige funksjonelle begrep/konsepter som bidro til struktur og forenkling i gjennomføringen i prosjektet. Begrepsapparatet har vist seg robust og er implementert i løsningen Saksmodul og portal Funksjonell modulinndeling av løsningen Identifisering av s «produkter» Identifisering av behandlingsprosessene (sakstyper) og konsept for maskinell behandling av saker Overordnet informasjonsmodell/domenemodell Konsept for bruk av regelapplikasjon Strukturering av regler (Funksjonell Tjenestekatalog) Lånemodul Egenutvikle lånemodulen på.net Gjenbruk av strukturer og sentrale funksjoner fra LIS omskrevet i C# Forbedret/utvidet informasjonsmodell Innføring av nye ordninger i samband med samordning av statsbankene (månedlig forfall, forsinkelsesrenter,daglig rentebelastning osv) Migrasjonsstrategi Full produksjon i hele perioden Gradvis nedbygging av LIS gjennom trinnvis innføring av sakstyper Lånemodul til slutt Funksjonell modulinndeling av løsningen Gjennom analyse av produkter og prosesser, framkom funksjonelt systembehov Funksjonell modulinndeling viser overordnede systembehov og er ikke lik den fysiske modulinndeling, Godt kommunikasjonsverktøy og sikrer helheten i løsningen Datavarehus Datautvekslingsmodul Håndtering av henvendelser Henvendelser Utsendelsesmodul Stamdatamodul Kundedata Lærestedsdata Ordninger Dine Sider Oppgavehåndteringsmodul Oppgaver Saksautomatiseringsmodul Saker Vedtak Håndtering av manuelle saksoppgaver Regelverksmodul Regler Nettsøknader Portalrammeverk Integrasjonsrammeverk Kontrakter Arbeidsflate for læresteder Eksisterende Mottak av telefoni og e-post Dokumenthåndteringsmodul Dokumenter Lån- og stipendmodul Lån Kundereskontromodul Reskontro Hovedboksmodul Hovedbok Eksisterende Kassafonen Eksisterende Postmottak (digitalisering) Grensesnitt mot SI Kunde-, læresteds- og 3.-partsmoduler Moduler for manuell oppgavehåndtering Stamdatamoduler Sak- og regelverksmoduler Lån- og økonomimoduler Brukerdata LISgrensesnitt LIS Andre funksjonelle moduler Sikkerhetsløsning Midlertidige moduler i migrasjonsfasen eller eksisterende moduler IT drift & overvåkning Tekniske komponenter 7

8 s produkter Tildeling Tilbakebetaling har to regelverk En ordningsvariant er et «produkt» som kunden kan få. Dette oppdateres som en ytelse i Kontrakt. forvalter ca 100 ordningsvarianter (produkter) Ordninger Ordninger Ordninger Ordningsvariant Ordningsvariant Ordningsvariant Ordningsvariant Ordningsvariant Ordninger Ordninger Ordninger Ordningsvariant Ordningsvariant Ordningsvariant Ordningsvariant Grupper av ordninger, f.eks lån, stipend, rentefritak osv Varianter av ordninger, f.eks bostipend, utdanningsstipend, osv Vilkårsprøving og beregning av ytelser Identifisering av behandlingsprosessene (sakstyper) Analyse av s behandlingsprosesser Delprosesser og behandlingsrutiner Ordninger som inngår i behandlingen Kuransgrad (omfang av hel-maskinell behandling) Informasjonsbehov Resultatet av analysen Etablering av sakstyper som informasjonscontainere og for å sikre framdrift i systemet (Arbeidsflyt) En sak er i seg selv ingen historisk verdi. All rettighetsvurdering er tilknyttet ordninger og ligger i Kontrakt (Egenutviklet domenemodell) Knyttet ordninger til sakstyper Identifisering av spesielle prosessregler Identifisering av eksterne tredje-parter som leverer informasjon til prosessen har 15 sakstyper. Hver sakstype behandler flere ordninger. Eksempel på sakstype: ST01 Tildeling av studiestøtte ST04 Omgjøring av lån til stipend på bakgrunn av eksamensresultater ST07 Rentefritak i nedbetalingsperioden ST27 Ettergivelse av utdanningslån Ordning A Sakstype 1 Ordning B Ordning C 8

9 Sakstyper i Kode HV01 ST01 ST04 ST06 ST07 ST11 ST12 ST14 ST24A ST24B ST24C ST26 ST27 ST28 ST29 Tittel Henvendelse fra kunde Tildeling av lån og stipend Ligingskontroll/omgjøring Betalingsutsettelse Rentefritak på lånet Fastrente Avbrudd fastrente Renteerstatning Midlertidig oppsigelse av lånet Opphevelse av midlertidig oppsigelse Permanent overforing av kunde til SI Førstegangsbetalingsvilkår Ettergivelse av lån Innfrielse av lån Valutajustering av utbetaling Konsept for maskinell behandling av saker Datafangst Saksbehandling Effektuering Nettsøknader Fysiske brev DSF Søknad og 3.parts data Skattedirektorat Læresteder 1 2 PPI Person opplysni nger Maskinell behandling Oppretter saker Henter saksgrunnlag Kontrakt Historikk Manuell 6 saksbehandling 3 4 Bilag og konto Regelmotor Forslagsstilling Ukurante saker 5 Kurante saker Saksbehandler behandler ukuransmeldinger 7 Dokument Kontrakt (Historikk) Bilag og konto 9

10 Overordnet informasjonsmodell/domenemodell Behov for å gruppere informasjonselementene i grupper Skille s spesielle behov ut fra mer generiske strukturer Tilgjengelighet (Hvilke moduler trenger informasjonen) Sikkerhet (Hvilken informasjon er underlagt spesiell skjerming Logisk sammenheng (Hvilke data hører sammen) Opprettholde (og på sikt øke) maskinell behandling av saker = Generisk datastruktur, ligger i standardsystem = Spesiell datastruktur, egenutviklet datalager Kunde Sak og oppgaver Dokument PPI Person opplysninger Kontrakt (Historikk) Bilag og konto Læresteder Kodeverk Overordnet informasjonsmodell Aktør Sak Kontrakt Oppgjør Filial/Avdeling Aktør Konto-vilkår Kunde Lærested 3.part Sak Beslutning Kontrakt Konto Kontaktperson Bosted Kunderolle Vedtak Vedtatt ytelse Kontraktsendring Ytelse Oppsagt krav Inndekning Utbetalingsplan Nedbetalings -plan Adresse Vedtatt ytelses betingelser Ytelsesbetingelser Oppfølgingsaktivitet Betaling Samleutbetaling Samleinnbetaling Kontobevegelse Utbetaling Innbetaling Avskrivning Korreksjon Betalings-varsel Fakturalinje Samlefaktura Ytelsesstatus Omgjøring Purring Driftsavvik Renter Gebyr Oppsigelsesvarsel Resulterer i Kommunikasjon Dokument Oppgave Utdanning Søknad Tilskriftsbrev Vedtaksbrev Oppgave Studentstatus Eksamen Dialog Henvendelse Gjeldsbrev Resulterer i Utsendelse Regelverk Lærested Kampanje Forskrift Ordning Betingelse Lærestedsrolle Læresteds und.opplegg Emne 10

11 Strukturering av regler - Kjernebegreper Kurant: Saken kan behandles maskinelt. (Ingen saksbehandler) Ukurant: Saken må vurderes av en saksbehandler Forslagsstilling: Systemet forsøker å beregne ytelsene (ordningene) Ukurantmelding: Meldinger til saksbehandler fra systemet Overstyring: saksbehandler overstyrer forslaget fra regelmotoren Regelapplikasjon Høy grad av maskinell behandling av saker krever et rammeverk som støtter effektiv forvaltning (endring og videreutvikling) Viktige implementasjons-prinsipper Etablering av saksgrunnlag inn til regelbehandlingen (all informasjon inn samtidig) Beregning av kundens ytelser (ordningsvarianter) skal skje i regelmotor. Kuransbehandling skal skje i regelmotor Regelmotor kjøres alltid før effektuering. (Ikke mulig å gå utenom regelmotor før vedtak) Erfaringer gjennom prosjektet Vi ser at regelmotorer finnes i flere innpakninger og med ulik funksjonsrikdom Regelmotorer i seg selv er ikke nødvendig for å sikre kravet om skille forretningsregler fra tekniske regler Regelmotorteknologien må oppfattes som et rammeverk for utvikling Det trengs utviklere på lik linje med annen koding for å skrive og vedlikeholde regler Det er vanskelig for forretningssiden å vedlikeholde regler. Vi har valgt å la utviklere gjøre dette. Man må forstå grunnleggende databehandling for å sikre korrekthet i reglene Satser (kodeverk) som regelmotoren benytter, har vi lagt i eget domene slik at dette kan vedlikeholdes av fagfolk Store deler av annet kodeverk ser vi må vedlikeholdes av utviklere siden nye koder alltid må innføres gjennom en utviklingsprosess og formell versjonhåndtering 11

12 Kobling av regler Sakstype 1 Saksgrunnlag Behandlingsregel Tekst Ytelse Ytelse Tekst Ytelse Behandlingsregel Behandlingsregel Kurans Kontrakt (Historikk) Bilag og konto PPI Person opplysninger Dokument 12

13 13

14 14

15 Bilag Bilag Lånemodul: Løsningsvalg Siste fase i prosjektet var etablering av ny lånemodul og avslutte eksisterende løsning (LIS) Løsningsvalget for lånemodulen var ikke tatt i tidligere faser av prosjektet Alternativene som ble vurdert Egenutvikling (Modulis-alternativet) Egenutvikling på samme plattform som Modulis-Sak Plattform-modernisering med egenutvikling Flytting av eksisterende løsning, LIS, til ny Microsoft-plattform (Micro-Fokus) SI-alternativet Løsning fra Statens innkrevingssentral Lånesystem basert på standardløsning Utvikling, forvaltning og drift i regi av ekstern leverandør Modulis-alternativet ble valgt på grunn av Alternativet med lavest kostnader og risiko Liten leverandørbinding Samme tekniske plattform som Modulis sak Veletablert prosjektmodell og metodikk i Høy intern kunnskap om løsningen beholder styringen Egenutviklet lånemodul Dinesider Lånemodul Modulis sak PO Portal IB Håndtere innbetaling OK Overvåke kunde lån og konto AD Administrasjon av brukere og satser OM Omskriving av kunde og sakssystem Grensesnitt Bank SI SKD Datavarehus IK Innkreving TB Tilbakebeta ling og varsling Bilag KO Konto og kontovedlik ehold Bila g Bilag UB Håndtere utbetalinger RE Renteberegning PU Print og utsendelse SK Sikkerhet 15

16 Modulis - Oversikt 16

17 Innhold og oppdraget Litt om gjennomføring Løsninger Erfaringer Viktigste erfaringer fra utviklingsarbeidet i første forsøk (som ble avbrutt) Kostnadsrammen var for lav (Gitt i Stortingsmeldingen) Standardsystemer er ikke så fleksible som man hadde inntrykk av Regelverket kan ikke endres uten deltakelse fra myndigheter manglet nødvendig dokumentasjon på domenemodeller og informasjonsbehov Leverandøren manglet domenekunnskap var ikke forberedt på et så krevende prosjekt Vanskelig for en organisasjon å tilpasse seg nye arbeidsformer på så kort tid Dette ble det gjort noe med før andre forsøk 17

18 Viktigste erfaringer fra andre forsøk LØFT og Modulis har hatt en tydelig prioritet i organisasjonen helt fra toppledelsen. Tydelig styringsnivå hvor prosjektet har fått jobbet i fred med stabile rammer. Smidig utviklingsprosess uten en jevnt fordelt risiko og gjensidig tillit mellom partene er ikke gjennomførbart i et kunde-/leverandørforhold som ble benyttet i HL1 og HL2-1. (PS2000) Endringshåndtering i egenregi = prioritering og vedlikehold av produktkø. Selvorganiserte utviklingsteam som er fast bemannet med produkteier og funksjonelle ressurspersoner er nøkkel til høy effektivitet og god kvalitet. Produkteier må ha et sterkt eierforhold til produktkøen, og må gis myndighet til å utøve dette eierskapet. Migrasjonsplanen har vært en suksessfaktor ved at man har kunne konsentrere seg om ett og ett funksjonelt område om gangen i tydelige faser. Målet og kravet om bruk av standardsystem har vært en føring som vist seg å koste mye og som ikke lot seg realisere i det omfanget som man opprinnelig beskrev. Det er en ekstrem stor produktivitetsforskjell på flinke og dårlige utviklere. Revisjon av løsningskomponenter Erstatte Inrule med.net C#-komponenter. Tankegangen om regelkomponenter etter black-box-prinsippet er god, men man trenger ikke en regelmotor for å gjøre dette. Erstatte SSIS-kode med.net C#/Dapper-spørringer. SSISrammeverket krever egen kompetanse, som gjør at vedlikehold av disse komponentene i arkitekturen møte flaskehalser. Erstatte BizTalk med.net C#-komponenter. Flytte saksbehandlingsskjermbilder fra 360 til.net MVC. Skifte ut kodeverksmodulen. 18

19 Oppsummering: Myndighetenes krav til løsningen Kravoppfyllelse etter ferdigstilling (Intern vurdering) En hovedleverandør Løpende vurdering av utsetting av tjenester Ny løsning basert på standard programvare LIS skal fases helt ut etter avsluttet prosjekt Økt selvbetjeningsgrad for kunder Opprettholde og legge til rette for en økning i automatiseringsgrad i saksbehandlingen skal ha full drift i prosjektperioden Tilpasning av regelverket til nye arbeidsformer og standard programvare Gevinstrealisering Gartner: IT-løsning vurdert opp mot målsettinger, føringer og kriterier Vurderes ny løsning opp mot opprinnelige mål, krav og kriterier, ser vi at 10 av 12 elementer svares godt opp «skal tilpasses standardsystemer» ble forsøkt svart opp i periode 1 men det lykkes ikke Ved å løse HL3 med skreddersøm, benytter ny IT-løsningen både standardløsninger og skreddersøm Valg av løsning skulle ikke forårsake reduserte eller forsinkede gevinster. Gevinster er ikke redusert, men, ved gjennomføring som opprinnelig planlagt kunne gevinster (knyttet til løsningen) vært hentet ut tidligere IT-løsning fremstår robust og vedlikeholdbar og bør utgjøre en god plattform og et godt grunnlaget for ytterligere gevinstrealisering gjennom videre digitalisering og utvikling av funksjoner Den SOA løsninger som nå er etablert vil gi en høyere forvaltningskostnad enn den gamle løsningen. Men, den har automatisert flere manuelle oppgaver og prosessert, og den er en forutsetning for digital samhandling for å tilby gode selvbetjeningsløsninger. IT-LØSNING VURDERT OPP MOT MÅLSETTINGER, FØRINGER OG KRITERIER CONFIDENTIAL AND PROPRIETARY Gartner, Inc. and/or its affiliates. All rights reserved

20 Riksrevisjonens vurdering «Riksrevisjonen har fulgt utviklingen av moderniseringsprosjektet i Statens lånekasse for utdanning () siden På det tidspunktet ble det besluttet å avslutte det opprinnelige prosjektet og terminere kontrakten med daværende leverandør. Ved oppstart av nytt prosjekt i 2008 påla departementet å styre etter en målprioritering med kostnader og kvalitet foran tid. Prosjektavslutningen er forskjøvet flere ganger, og departementet har uttalt at dette ikke er optimalt. Kostnadsrammen på ca. 745 mill. kroner er holdt. Riksrevisjonen har gjennomført en kontroll av prosjektets styring og departementets oppfølging. Det er ikke avdekket vesentlige svakheter, feil eller mangler.» Men når alt kommer til alt Folka Interne og eksterne I programmet og utenfor Utførende og tilretteleggende Her og der rundt om i landet Gjorde at har gjennomført det (relativt sett) STØRSTE fornyingsprosjektet i offentlig sektor 20