Infight om Skats nye inddrivelsessystem: Er et næsten færdigt it-system godt nok?

Illustration: Henning Mølsted
Det er en gyser at læse Rigsrevisionens rapport om udviklingen af nye gældsinddrivelsessystem, PSRM, anfører kritikerne. Rapporten konkluderer, at der er fejl og driftsproblemer med systemet. Skatteministeriet og udviklerne fastslår, at PSRM er færdigt og virker.

ANALYSE. Kan man bygge et kritisk it-system som det nye inddrivelsessystem, der skal kradse gæld ind automatisk til det offentlige fra borgere og virksomheder, som en app og melde klar til drift, når den er næsten-færdig, men dog mangler væsentlig funktionalitet for at levere den helt rigtige præstation?

Spørgsmålet er et centralt omdrejningspunkt i den kritik, som Rigsrevisionen i sidste uge udgav i en ny beretning, der kulegraver udviklingen af det nye inddrivelsessystem, PSRM - Public Sector Revenue Management.

Systemet skal efterfølge det skandaleramte EFI-system, der blev lukket ned i forhold til automatiseret inddrivelse i 2015.

En beretning, der ifølge ifølge kritikerne er rystende læsning, og som i hvert fald vidner om, at den endegyldige idriftsættelse af PSRM med en fuldt digitaliseret og i overvejende grad automatiseret gældsinddrivelse tegner særdeles gyseragtig - for ikke at sige, at projektet sammenlagt er nær ved at udvikle sig til en ny offentlig it-skandale.

Rigsrevisionen: PSRM kan ikke levere fuld inddrivelse

Helt basalt konkluderer Rigsrevisionen, at PSRM ikke på undersøgelsestidspunktet i starten af 2019 havde den funktionalitet, der var nødvendig for at kunne understøtte alle inddrivelsens processer.

Blandt andet halter det med at kunne foretage udlæg - dvs. tvangssælge værdier - og modregne f.eks. i børnechecken. Medio 2019 er det fortsat under afklaring, hvor stort et omfang resten af udviklingen omfatter - og økonomien forbundet hermed, fremgår det.

Læser man nærmere ned i rapporten, er der rettere tale om, at Skatteministeriet ikke kan dokumentere godt nok, at PSRM er færdigudviklet i en grad, så systemet kan understøtte opgaven med at kradse gæld ind fra fordringshaverne hos bl.a. kommuner, politi og trafikselskaber.

Samme gennemgang viser også, at Skatteministeriet arbejder med nedbrydning af påkrævet funktionalitet i use cases og features. Problemet er, at backloggen til systemet ifølge Skatteministeriet stadig omfatter en række nødvendige features og use cases, som altså ikke er færdigudviklede.

De overordnede processer til inddrivelsen foreligger der færdigudviklet funktionalitet til. Men det er ikke tydeligt, om ‘al nødvendig funktionalitet til inddrivelsens processer’ er færdige.

Det er altså for uklart, om de manglende features kan undværes.

Det kan de godt, lød det fra tidligere skatteminister Karsten Lauritzen (V) i et interview med Version2 i fredags. Han forsvarer systemudviklingen med, at den foregår agilt - underforstået, at man ikke har til hensigt at sætte et komplet færdigudviklet system i drift i et big bang, som det f.eks. skete med Digital Tinglysning, Sundhedsplatformen og andre store it-projekter.

Læs også: Tidligere skatteminister afviser kritik af gælds-system: »Rigsrevisionens faglighed er overraskende lav«

Kan et stort skattesystem udvikles som en app?

Projektmodellen med agil udvikling kendes fra appudvikling som f.eks. Danske Banks Mobilepay, som fik et halvt år og ikke en dag længere til at udvikle første version til at sætte i drift. Efterfølgende features opnår brugerne ved at opdatere appen - eller systemsoftwaren - når en ny version er klar.

Karsten Lauritzen - og efter alt at dømme skatteforvaltningen - tror på denne moderne udviklingsmetode, som er højt besunget blandt mange af nutidens it-konsulenter. Hvor delvist færdigt altså er færdigt nok til at sætte i drift.

Tilbage i februar i år gik samme Karsten Lauritzen således også ud med en melding om at »sidste del af nyt gældsinddrivelsessystem nu [er] udviklet«. Her fremgik det også, at langt de fleste og vigtigste funktioner var færdige.

Andre vil mene, at sådan kan man ikke udvikle et stort, kritisk it-system, som skal håndtere en helt central opgave i et velfærdssamfund; nemlig at kunne kradse penge ind med magt, hvis borgere eller virksomheder ikke betale f.eks. deres skattegæld, renovation eller bøder.

Her må systemet være helt færdigt, alle delkomponenter må hænge sammen, det må være testet af - og det må have bevist, at det kan løse problemet. Nemlig at kradse gæld ind.

Der mangler dokumentation for status

En meget central del af kritikken fra Rigsrevisionen går på, at Skatteministeriet ikke har dokumentation for, at de tusindvis af user stories og funktionaliteter leverer en grad af sammenhæng, så man opnår en automatisering i inddrivelsen, som er det helt grundlæggende formål med PSRM.

Et centralt spørgsmål er altså ikke bare, om udviklingsmetoden er for risikabel til et kritisk system som PSRM, men om det overhovedet fungerer, selv nu hvor det skulle være færdigt.

Desuden er der påvist fejl når man har afprøvet forskellige funktionaliteter. Det gælder eksempelvis udlæg, hvortil der er udviklet basal funktionalitet. Problemet er bare, at den ifølge beretningen viser fejl, når forvaltningen forsøger at automatisere processerne.

En af de allerførste fordringshavere, der fik gældsinddrivelse gennemført på PSRM, nemlig DR, har således oplevet en række fejl, som betød, at der var uoverensstemmelser i afstemningen i hhv. DRs system og PSRM.

Også redskabet modregning, der anvendes til at hente gæld inden udbetaling, har krævet fejlrettelser og desuden kan funktionaliteten ifølge Rigsrevisionen kun anvendes i overskydende skat.

Der er både ligheder og forskelle til EFI

Umiddelbart kunne det se ud, som om Skatteministeriet er ved at gentage skandalen med EFI, der heller aldrig kom til at levere den lovede automatiserede inddrivelse.

Der er lighedspunkter, men der er bestemt også forskelle. Heldigvis.

For begge systemer anvendtes og anvendes ordlyden, at der er grundlæggende fejl af funktionel, teknisk og datamæssig karakter, men hvor disse fejl i EFI betød, at systemet ikke kunne levere lovlig inddrivelse, så fremgår det af beretningen om PSRM, at inddrivelsen vil ske lovligt.

Begge systemer blev ramt af forsinkelser i udviklingen. EFI-systemet var forsinket ad flere gange i over ti år, og PSRM skulle have været klar til fuldstændig idriftsættelse i 2018, men det blev udskudt til i år, og nu tegner alt til, at det først kommer i drift til næste år eller senere.

PSRM er ganske vist ifølge Skatteministeriet bygget færdigt, og helt usædvanligt har softwarehuset bag systemet, Netcompany, været ude og stemme i:

»Jeg kan bare sige, at fra den stol, jeg sidder i, virker vores system,« har direktøren i Netcomany, André Rogaczewski, sagt til DR.

Funktionsdygtigt - i det små og enkle

PSRM har ikke desto mindre endnu kun bevist at kunne håndtere automatiseret inddrivelse for et meget lille antal gældssager. Og det er måske en af de største røde advarselslamper, der blinker: Fungerer systemet i full scala og kan det betjene 800 offentlige kreditorer samtidig?

Kun tre fordringshavere, nemlig DR, Movia og Arrive er koblet på - og de har relativt få og ukomplicerede gældssager.

Der mangler altså volumen - og desuden er PSRM ifølge Rigsrevisionen ikke engang testet til de store mængder sager, som det skal kunne håndtere i fremtiden.

Så uanset om man hælder mest til skatteforvaltningen og Karsten Lauritzen, der anfører, at systemet fungerer tilstrækkeligt og understøtter den grad af automatiseret inddrivelse, som man har forventet - eller om man mener at de angivne fejl og selve systemudviklingen er forkert, så mangler PSRM altså at bevise, at systemet kan løse opgaven, nemlig at håndtere de mange gældssager - der er tale om flere millioner årligt - som skal tikke ind til behandling fra 800 offentlige kreditorer.

Imens vokser gælden til det offentlige til nu svimlende 118 mia. kroner. Ud over de 1,1 milliarder kroner, som er afsat til at udvikle det nye system.

Måske den største udfordring: at sætte stikkene i it-kassen

Parallelt med hele ovenstående gennemgang af udfordringer med selve systemudviklingen - altså it-kassen, om man vil - er der også alvorlige problemer med at få sat stik i kassen. At få koblet 800 offentlige kreditorer på PSRM. De skal sende data ind i en ganske bestemt kvalitet og format for, at systemet kan håndtere gældsinddrivelsen korrekte.

Det kræver dyr tilpasning af debitorsystemer f.eks. i kommunerne, og selv når systemerne er tilpasset og opkoblingen gennemført, så kan der opstå problemer. Det viser erfaringer fra DR, som oplyser, at selv efter 4 måneders ‘reel drift’, hvor gældssager sendes ind i PSRM, så betragter medievirksomheden sig endnu ikke som værende fuldt og endeligt tilsluttet.

Der sker fejl, og der er driftsforstyrrelser, som giver problemer med at sende fordringerne ind i PSRM og med at få underretninger retur.

Det er ikke kun DR, der har problemer.

Kun 3 ud af 17 offentlige kreditorer, der var planlagt til opstart i 2018, er sat i søen. Et sigende eksempel er opstarten af Skatteministeriets eget system, Kobra, der er udskudt fem gange, hvilket også får Rigsrevisionen til at kommentere, at der ikke har været et godt nok »grundlag til at vurdere, hvordan tilslutningen kommer til at fungere, selv om der er tale om ministeriets eget system«.

Med andre ord: Det peger i retning af, at det bliver endnu mere usikkert, om planen holder for eksterne offentlige kreditorer som Rigspolitiet, kommunerne og a-kasserne.

Problemet er ikke at skaffe sig overblik over typen af opgaver, der skal løses for at koble de mange kreditorer på. Dér, hvor Skatteministeriets indsats halter, er i forhold til at vurdere opgavernes omfang og det forventede tidsforbrug med at koble de eksterne systemer på.

Derfor frygter revisionen, at vi kan nå langt ind i 2020 og måske endda længere ud i fremtiden, inden de mange kreditorer er koblet på.

Vurderet sammenlagt på omfanget af drifts- og funktionsproblemer, den manglende test og den haltende opkobling af kreditorer virker det rimeligt, når kritikerne er bekymrede for, om vi står foran alt for mange års ekstra bøvl og ballade - og i værste fald en ny offentlig it-skandale - forud for, at de mange milliarder i gæld kan hentes hjem igen til statskassen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anne-Marie Krogsbøll

En meget central del af kritikken fra Rigsrevisionen går på, at Skatteministeriet ikke har dokumentation for, at de tusindvis af user stories og funktionaliteter leverer den grad af sammenhæng, så man opnår den automatisering i inddrivelsen, som er det helt grundlæggende formål med PSRM.​"

Er det ikke samme problematik som med EFI - at man insisterer på at tage sætte et system igang (dvs. indrette inddrivelsen efter det -i EFI fyre medarbejdere), inden man ved, om det overhovedet fungerer?

"Projektmodellen med agil udvikling kendes fra appudvikling som f.eks. Danske Banks Mobilepay, som fik et halvt år og ikke en dag længere til at udvikle første version til at sætte i drift. Efterfølgende features opnår brugerne ved at opdatere appen, når der er en ny version.
Karsten Lauritzen - og efter alt at dømme skatteforvaltningen - tror på denne moderne udviklingsmetode, som er højt besunget blandt mange af nutidens it-konsulenter. Hvor delvist færdigt altså er færdigt nok til at sætte i drift."

Hvordan afgør man så om en udviklingsproces er fejlet? Kan den så overhovedet gøre det - eller har man bare defineret opgaven, så man altid kan påstå, at man har løst den, uanset hvordan virkeligheden ser ud?

Fungerer systemet i full scala og kan det betjene 800 offentlige kreditorer samtidig?"

Et ret væsentligt kriterium at opfylde, inden man som Netcompany konkluderer, at systemet fungerer som det skal, forekommer det mig.

118 milliarder! Og der er én faktor, som man faktisk kunne styre, i det man - så vidt jeg har forstået - har forbudt kommunerne selv at inddrive gælden. Hvorfor?

Jeg begynder at frygte, at vi står med en ny EFI-sag. Et system, som aldrig kommer til at fungere, hvor statens tilgodehavender bare vokser og vokser, for til sidst at blive umulige at inddrive. Det mindste man kunne gøre var da at gøre det lovligt for kommunerne at inddrive gælden.

Er der nogen i systemet, som i virkeligheden arbejder målrettet på at undergrave skattevæsnet fuldstændigt - at det ikke er meningen, at det nogensinde SKAL komme til at fungere? Hvor mange politikere og topembedsmænd skylder mon det offentlige store beløb?

  • 2
  • 8
Jonas Høgh

Projektmodellen med agil udvikling kendes fra appudvikling som f.eks. Danske Banks Mobilepay, som fik et halvt år og ikke en dag længere til at udvikle første version til at sætte i drift. Efterfølgende features opnår brugerne ved at opdatere appen - eller systemsoftwaren, når en ny version er klar.

Karsten Lauritzen - og efter alt at dømme skatteforvaltningen - tror på denne moderne udviklingsmetode, som er højt besunget blandt mange af nutidens it-konsulenter. Hvor delvist færdigt altså er færdigt nok til at sætte i drift.

Må jeg i al beskedenhed anbefale skribenten at læse op på hvad Agile er, i stedet for at give metoden skylden for samtlige dårligdomme i projektet? Ovenstående karakteristik er ikke engang forkert.

  • 10
  • 0
Denny Christensen

PSRM udvikles efter en metode, hvor de færdige dele af løsningen sættes i anvendelse.

Udover at forskellig lovgivning om fordringer jeg ikke ved noget om giver rework, så har løsningen vist at den kan inddrive penge for de tilsluttede instanser.

Så må tesen være at løsningen virker og inddrivelse er lovlig.

Efterhånden som flere gældstyper kobles på og de interne regler justeres, eks. at samme person har et maks beløb om måneden der kan inddrives, så opnåes større dækning.

Om det nogen sinde bliver 100 pct kommer an på så meget, eks. om det kan betale sig overhovedet, om lovgivningen er for umulig, og hvordan samfundet udvikler sig.

Tilbage er et residual som så kan opkræves manuelt.

Set udefra og med beskeden viden om PSRM synes jeg egentlig at det går ganske godt.

  • 9
  • 1
Jørn Wildt

Uanset om man er for eller imod agile, så syntes jeg er der noget som halter hvis man vælger en løsning, hvor man løbende sætter nye områder i drift - nemlig hvad man gør med de områder som endnu ikke er implementeret.

Havde det være ny funktionalitet vil det have været fint - systemet ville kunne, dag for dag, mere end det kunne før, og kunden vil få løst flere og flere opgaver på en bedre måde end før.

Men nu er det jo en gen-implementering af et eksisterende system, hvor det lader til at man allerede har lukket det tidligere system? Som jeg hører det, så må kommunerne fx ikke inddrive gæld - uagtet at man har erstattet deres inddrivelse med et system, som helt bevidst ikke er færdig fra dag ét.

Hvis man vælger en metodik med at sætte en delvist implementeret løsning i drift som erstatning for et eksisterende system - hvor er så planen for at håndtere alle de features som endnu ikke er implementeret, men til gengæld sløjfet fra det gamle system?

Det lyder som en dårlig blanding af "big bang" og "agile" - man fjerner det gamle system i et "big bang" ... men gennemfører det nye system "agile" og delvist step-for-step.

Hvis det er korrekt, så lyder det sgu' ikke særligt smart?

  • 4
  • 6
Frank Jumppanen Andersen

de ting man ikke sætter i drift kører som hidtil - indtil lovgrundlaget er ensrettet og evt. manglende features tilføjet. Enkelt.

Langt LANGT bedre at gå i luften og så bygge på. Så ved man at kernen virker - selvom den måske skal skaleres. Og giver TID til ensretning af øvrige fødesystemer

  • 9
  • 0
Anne-Marie Krogsbøll

Denne diskussion lyder som en af den type, hvor kun tiden kan vise, hvem der har ret. Hvor lang tid er det rimeligt at give projektet, inden dommen falder? 1 år? 5 år? 15 år?

Kan vi få et bud fra begge sider på, hvornår Version2 med rimelighed skal lave den opfølgende status, som fælder dom over, om der er styr på projektet og håb i sigte eller ej?

  • 2
  • 0
Denny Christensen

2030? Samtidig med at vi har reduceret CO2 udledning med 70 pct?

IT løsningen kan være super, men måske blot 100 tilsluttede instanser - er det så en succes?
Alle mulige kandidater er tilsluttet, der opkræves 80 pct af fordringerne - fejl i løsningen eller er det fordi dem der skylder ikke KAN betale?

I min verden er det en succes at noget inddrives, i det hele taget.
For hver ny fordring type/instans der kommer med hvor penge kan indrives er det en succes.
Hvis systemet kan hjælpe til med at konstatere at en fordring må opgives, evt understøtte en borger i gældssanering, er det en succes.

Ikke at jeg er en happy-go-lucky type, men fordi EFI fejlede stort og der ingen mennesker er tilbage i SKAT til at inddrive. Så vil al inddrivelse være en succes for mig.

  • 3
  • 1
Knud Larsen

Forkert. Systemet virker ikke - det er stærkt forsinket det fører til urimelige ågerrenter på borgerne uden grund. Der er i 4 år ikke kommet nogen rykkere for påstået skyld - noget som borgerne slet ikke er klar over - i det mindste højest har en mistanke om.
Påstået gæld fra Skattstyrelsen baseres på fup og svindel - styrelsen kan slet finde ud af at opgøre det rigtigt, og så kan Gældsstyrelsen bare køre en damptromle henover borgerne - dette er stærkt uretfærdigt og ikke en retsstat værdigt.
se
http://skat-uret.dk/nyheder/2014-efi-skattekonto-it-system.aspx
og en konkret sag - det er f....... uhyggeligt
mere end 14 ministre har aldrig gjort noget ved det og forstår næppe baggrunden - de næget i hvert fald alle at gøre noget. Vi mangler en forfatningsdomstol.

http://skat-uret.dk/ret/2019-skats-fup-og-svindel-2-ontranet.aspx

  • 2
  • 7
Jesper Frimann

Langt LANGT bedre at gå i luften og så bygge på. Så ved man at kernen virker - selvom den måske skal skaleres. Og giver TID til ensretning af øvrige fødesystemer


Du læste godt afsnittet om svartider ?
Du læste godt om manglende samarbejde med 'kunderne' ?
Du læste godt om mængden af fejl ?

Det hænger jo ikke så godt sammen med agil udvikling.

// Jesper

  • 5
  • 1
Frank Jumppanen Andersen

Du læste godt afsnittet om svartider ?
Du læste godt om manglende samarbejde med 'kunderne' ?
Du læste godt om mængden af fejl ?


Ja - og ja - og ja.

Svartider: Start småt og skaler når der er behov. Det kan stort set alle moderne systemer. Ligeledes kan du som udvikler umuligt forestille dig hvilke brugsmønstre der kommer, så der skal også laves målrettet optimering. Helt normalt...

Samarbejde: Alle kunderne SKAL bruge det nye centrale system - men alle kunderne har i dag egne skræddersyede løsninger - og modsætter sig al ensretning. Helt normalt... Frem med pisken og høst effektiviseringsgevinsten længere fremme.

Fejl: Igen - start med kernen - ret fejlene dér, så dén er stabil. 'Fejl' som skyldes specifikke kundebehov - er ikke fejl. Enten manglende feature - som laves nor den spcifikke kunde kommer til i køen - eller (oftest) manglende data disciplin på fødedata fra kunden (som nævnt: kunderne har nedprioriteret nødvendige tilpasninger).

...sådan er det ofte - og det BØR naturligvis håndteres gennem klar kommunikation og forventningsafstemning.

  • 1
  • 3
Jesper Frimann

Svartider: Start småt og skaler når der er behov. Det kan stort set alle moderne systemer. Ligeledes kan du som udvikler umuligt forestille dig hvilke brugsmønstre der kommer, så der skal også laves målrettet optimering. Helt normalt...


Øh ? Det lyder lidt som et 'Famous Last words' quote. Hvis du oprindeligt har skulle have svartider på Max et sekund, og nu har svartider i nærheden af 2 minutter, så er det ikke.. BAU. De gange jeg har været med til at lave rootcause analyser på lignende problemer på store systemer, der er det ikke noget man gør for sjov.

Samarbejde: Alle kunderne SKAL bruge det nye centrale system - men alle kunderne har i dag egne skræddersyede løsninger - og modsætter sig al ensretning. Helt normalt... Frem med pisken og høst effektiviseringsgevinsten længere fremme.


Igen så er det et produkt af kommunal selvbestemmelse, sådan er det bare, det er et vilkår. Og det er en problematik, der har været kendt lige siden starten af projektet. At ændre grænseflade specifikationerne for et system der er i produktion og er igang med at onboarde kunder, således at allerede onboardede kunder får fejl, er ikke agil udvikling det er bare dumt.

Fejl: Igen - start med kernen - ret fejlene dér, så dén er stabil. 'Fejl' som skyldes specifikke kundebehov - er ikke fejl. Enten manglende feature - som laves nor den spcifikke kunde kommer til i køen - eller (oftest) manglende data disciplin på fødedata fra kunden (som nævnt: kunderne har nedprioriteret nødvendige tilpasninger).


Igen har du ikke læst rapporten. Der introduceres en fejl i August i en ny release, som så først rettes i December. Det er sku ikke agilt.

// Jesper

  • 5
  • 0
Jan Rouvillain

Systemet omfatter 800 integrationer og endnu flere forskellige arter af bøder og inddrivelser, som hver har sine regler og procedurer. Dertil kommer håndteringen af udlæg. Kan det overhovedet centraliseres?
Og så bliver det en pengemaskine for Netcompany i vedligehold, fordi cirkulærer og love introducerer nye bøder og eliminerer ældre inddrivelser.

  • 3
  • 0
Log ind eller Opret konto for at kommentere