Skat og billigere IT

Ovre på JP's submedie for de bemidlede, kan man idag læse overskriften "I morgen bør 4,9 mio. danskere tjekke deres skattekort"

Hvis Folketinget gerne vil have billigere IT til Skat, er sådant idioti et godt sted at starte.

I stedet for at hele befolkningen, godt pisket af medierne, overfalder Skats vakkelvorne gamle mainframe på en og samme dag, kunne Folketinget lave en lov der distribuerede belastningen ud over en hel måned, ved at vedtage at alle deadlines i forhold til skat, falder på den dag i måneden man er født.

Er du født d. 23 i en måned, skal din selvangivelse være inde før d. 23 i den relevante måned og du kan se din årsopgørelse d. 23 i en anden måned og din forskudsopgørelse på d. 23 i en tredje måned.

Det betyder ganske vidst at disse deadlines kun kan placeres i den halvdel af månederne der har 31 dage, men det er bestemt et overskueligt lovteknisk problem.

Faktisk kunne man uden større problemer sprede belastningen et lag tyndere: Din fødselsdag er din "skattedag" hvor selvangivelsen skal være afleveret og X dage senere foreligger årsopgørelsen og skattekortet til det kommende skatteår.

På den måde ville Skat få stort set jævn belastning over hele året og udrulning af nye IT systemer og store såvel som små programrettelser kunne idriftsættes, i sikker forvisning om at at man kun generer 0.3% af befolkningen per dag med problemer.

Har Skat nogensinde har bedt politikerne om en sådan lovændring ?

Hvis ja, hvorfor blev det så ikke til noget ?

Hvis nej, hvorfor ikke ? Det kan umuligt være fordi ingen i Skat har fået ideen ?

phk

Kommentarer (28)
Yoel Caspersen Blogger

Det kan ikke være Folketingets opgave at tage højde for Skats manglende evner udi implementering af effektive IT-systemer. Load balancing af mainframes hører ikke hjemme i skattelovgivningen, den er kompleks nok som den er i forvejen.

At designe et system der kan håndtere ca. 3 mio. transaktioner på en enkelt dag er hverken raketvidenskab eller synderligt dyrt, og især ikke, når størstedelen af forespørgslerne går på hentning af read-only content, som kan præ-genereres.

Det kræver dog, at Skat ansætter kompetente folk a'la dem hos Geodatastyrelsen og i øvrigt indser, at mainframes har de bedste år bag sig.

Poul-Henning Kamp Blogger

Det kan ikke være Folketingets opgave at tage højde for Skats manglende evner udi implementering af effektive IT-systemer.

I det omfang lovgivningen står i vejen er det kun Folketinget der kan fixe problemet.

At designe et system der kan håndtere ca. 3 mio. transaktioner på en enkelt dag er hverken raketvidenskab eller synderligt dyrt,

Helt korrekt, men det er stadig torskedumt at gøre det, hvis du istedet, billigere, kan sprede belastningen og riskomomenterne ud over 365 dage.

Yoel Caspersen Blogger

I det omfang lovgivningen står i vejen er det kun Folketinget der kan fixe problemet.

Det er næppe lovgivningen, der fastslår at systemet skal køre på 40 år gamle mainframes, der kun kan vedligeholdes af kustoder fra IBM. Der er mange problemer med skattelovgivningen, men de har bare ikke noget med Skats IT-problemer at gøre.

Helt korrekt, men det er stadig torskedumt at gøre det, hvis du istedet, billigere, kan sprede belastningen og riskomomenterne ud over 365 dage.

I princippet er jeg enig i, at det er en spændende tanke med individuelle "regnskabsår". I praksis er det nok bare tæt på umuligt, da stort set hele samfundet er indrettet på faste, kollektive cykler - lige fra ferieår, abonnementer og lønninger til skattebetalinger.

I Kviknet startede vi med at have rullende 30 dages afregning af abonnementer, og derved fik vi betalingerne fordelt ud over hele måneden - men det forvirrede kunderne, der var vant til konceptet med at "der er penge til den 1." (og så faktisk dagen før, så regningerne bliver betalt før lommepengene bliver hævet fra kontoen). Derfor kører vi nu abonnementer, der følger kalendermåneden.

Hvis vi opdrager hele samfundet til individuel økonomisk ansvarlighed ville det fungere fint med rullende regnskabsår, lønperioder o.l. - men for mange er det bare meget nemmere, når tingene sker samtidig for alle.

Det giver så nogle spidsbelastninger, der kan være uheldige - fx har vi også hos os nogle travle dage omkring den sidste bankdag i måneden, hvor vi opkræver betalinger for samtlige kunder.

Men at lave om på hele det system fordi Skat har svært ved at vise nogle PDF'er og HTML-sider, synes jeg virker som overkill. Desuden har Skat allerede indført et quick-fix i form af deres kø-system fra Queue-it, som til dels løser problemet en stund.

De burde dog stadig ansætte et kompetent hold af udviklere in-house, som kunne tage ansvar for at bygge et ordentligt system, i stedet for de evindelige mega-kontrakter til the usual suspects, der løser opgaven efter laveste fællesnævner.

Martin Bøgelund

Yoel kommer med rigtig mange af de gode argumenter for, at dette ikke er en vej Skat bør gå.

Noget jeg tænker er, at identifikation af brugeren er et kardinalpunkt i forslaget; Når brugeren går i gang med at logge på systemet, skal systemet afgøre om han må se sine data eller ej.
(I parantes bemærket er det i sig selv en indikation af at forslaget vil virke dumt for brugerne: Vi har dine data klar, men du må ikke se dem pga. din fødselsdag. Æv-bæv!)

Godt så, vores bruger logger ind, og fordi han er utryg ved at logge på med sit CPR-nummer, bruger han sin NemID-kode som login. Dvs. vi kan ikke skille brugere ,der ikke må se deres data endnu fra, helt ude i bruger-interface ved at tjekke de to første cifre i login. Vi er nødt til at lade ham logge ind, lave databaseopslag der mapper hans NemID-kode over til hans fødselsdag, sammenligne med dags dato, og så først herefter kan vi sige "Velkommen!", eller "Farvel, og kom igen når det bliver din tur!"

Og hele dette tjek giver kun mening den første måned efter frigivelse af data, hvor der erfaringsmæssigt er et peak i belastningen. 1-2 måneder efter åbning har dette tjek ingen relevans.

Den form for kunstigt hurlumhej giver mig en rigtig skidt mavefornemmelse mht. denne ellers meget pragmatiske løsning på et flaskehalsproblem.

Et problem der naturligvis skal løses vha teknik og design, og ikke en arbitrær opdeling af brugere i 31 kategorier, som iøvrigt ingen relevans har for skattebetaling, og ingen relevans har i 10-11 ud af årets 12 måneder.

Yoel Caspersen Blogger

Den form for kunstigt hurlumhej giver mig en rigtig skidt mavefornemmelse mht. denne ellers meget pragmatiske løsning på et flaskehalsproblem.

Et problem der naturligvis skal løses vha teknik og design, og ikke en arbitrær opdeling af brugere i 31 kategorier, som iøvrigt ingen relevans har for skattebetaling, og ingen relevans har i 10-11 ud af årets 12 måneder.

Sådan læste jeg også indlægget fra PHK først - men en nærlæsning afslører, at han faktisk vil lave en noget mere gennemgribende ændring: Vi skal have 365 kategorier i stedet for 31 (eller 1, som vi har nu).

Det er helt korrekt set, at det vil udjævne loadet - til gengæld vil det også betyde, at der ikke er nogen service-vinduer, hvor man kan indkøre et nyt system og teste det i produktionsmiljøet. Uanset hvilken dag det sker, vil det genere 0,3 % af befolkningen (og det er også ret mange!). Og da et service-vindue til den slags systemer må forventes at være større end en enkelt dag, stiger antallet af berørte borgere lineært.

365 skatteår vil nok udjævne belastningen af Skats bruger-vendte systemer, men det er en meget voldsom og gennemgribende ændring i den måde, man tænker lovgivning og skattebetaling på, og mit bud (der er 100 % baseret på mavefornemmelse) er, at gevinsten ikke står mål med indsatsen, når nu det dybereliggende problem er Skats manglende forståelse for udvikling og drift af IT-systemer, der skalerer.

I bund og grund er problemet, at det er konsekvensfrit for Skat at lade brugerne vente, når der er travlhed på linien - set fra Skats synspunkt er det jo den enkelte skatteborgers eget problem, og det skulle ikke undre mig, om man betragter kø-løsningen som en endelig løsning.

Poul-Henning Kamp Blogger

Dvs. vi kan ikke skille brugere ,der ikke må se deres data endnu fra

Du har ikke fattet hvad jeg faktisk foreslår.

Det er ikke et spørgsmål om du "må se" dine data, det er et spørgsmål om hvornår skat i det hele taget regner dem ud til at begynde med.

I stedet for at de får alle landets selvangivelser samtidig, spreder vi dem ud over hele året, så de får en jævn produktion, frem for disse kunstige myldretider.

Jonas Thomsen

I stedet for at åbne for adgangen til alle på samme tidspunkt eller at lave individuelle regnskabsår, kunne man notificere borgeren, når data er klar. Da der er tale om en stor kørsel, vil jeg forventer at vil fordele loadet over flere dage (hvis ikke uger). Hvis man yderligere forestillede sig, at man havde en push-mekanisme (en mobile app?), hvor SKAT kunne pushe resultatet til borgerens enhed, når det er klar, sker loadet jævnt i stedet for i peaks - push kunne jo fint ske i løbet af natten.

Yoel Caspersen Blogger

Det er ikke et spørgsmål om du "må se" dine data, det er et spørgsmål om hvornår skat i det hele taget regner dem ud til at begynde med.

Tanken om udjævning er interessant, så lad os tage et kig på hvordan det kunne gøres i praksis.

Første udfordring - skæringsdatoer. Hvordan skal man indføre ny skattelovgivning? Fx ændring af skattesats fra x procent til y procent.

I dag kan man vedtage, at en skatteændring gælder i indkomstår 2017 og derfor træder i kraft 1. januar 2017. Det er ens for alle, og nemt at regne med.

Lad os nu sige, at alle har individuelle skatteår - hvornår skal en ændring så træde i kraft?

Hvis ændringen træder i kraft 1. januar 2017, skal skatten (og dermed indtægten) opgøres på dagsbasis, for ellers vil man blive beskattet forkert, hvis man ikke har fødselsdag den 1. i en måned. Det medfører umiddelbart en informationsmængde, der skal behandles, med en faktor ca. 30.

Lad os i stedet sige, at ændringen træder i kraft efter indeværende skatteår - så vil der gå 365 dage, før loven er endeligt implementeret, og i den periode vil der være en stor gruppe af personer, der betaler en anden skattesats end resten, blot fordi de er født på et andet tidspunkt på året. Vil man som befolkning acceptere dette?

Er der en oplagt løsning, jeg har overset?

Yoel Caspersen Blogger

Hvorfor er der ikke det ? Der er jo ingen der har sagt at alle brugere og al trafik partout skal dirigeres til samme server ?

Men det er vel det problem, man har i dag - at systemet er en monolitisk struktur, der ikke skalerer ud, fordi alle data hentes i en mainframe.

Hvis man ændrer det setup, så brugere bliver dirigeret til forskellige servere, løser man jo allerede der problemet med at alle får deres forskudsopgørelse samme dag - eller hvad?

Simon Mikkelsen

Helt korrekt, men det er stadig torskedumt at gøre det, hvis du istedet, billigere, kan sprede belastningen og riskomomenterne ud over 365 dage.

Hvis man stod og skulle lave helt nye systemer, er det en tanke man kunne overveje. Men man kan købe mange ekstra servere og konsulenttimer til optimering for de penge det vil tage at prøve at få alt den eksisterende kode til at virke med flydende frister.

Jørgen Elgaard Larsen

Faktisk kunne man uden større problemer sprede belastningen et lag tyndere: Din fødselsdag er din "skattedag" hvor selvangivelsen skal være afleveret og X dage senere foreligger årsopgørelsen og skattekortet til det kommende skatteår

Vil det sige, at personer født den 29/2 kun skal betale skat ca. hvert fjerde år?

Nå, spøg til side.
Jeg kan som udgangpunkt godt lide idéen med at sprede belastningen ud. I hvert fald for ting som årsopgørelsen, som notorisk giver kø hvert år.

Men desværre er der for mange afhængigheder i skattelovgivningen.

Lad os sige, at man lader folk indsende selvangivelse på deres fødselsdag. Hvis vi fastholder kalenderåret som skatteår, skal man være ualmindelig rap på fingrene, hvis man har fødselsdag d. 1. januar. Til gengæld har man masser af tid, hvis man har fødselsdag i december.

Alternativt kan man lade skatteåret følge leveåret - altså fra fødselsdag til fødselsdag. Det vil så kræve, at din månedsløn tilpasses samme dag i måneden eller at du skal periodisere din løn.

Og hvad med virksomheder? Det er allerede nu bøvlet med virksomheder, der har valgt andet end kalenderår som regnskabsår. Derfor vælger mange (især mindre selskaber) at lade regnskabsåret følge kalenderåret - det gør det meget nemmere at få selskabsregnskabet og personregnskabet på plads. Jeg gruer for de diskussioner, der vil komme om regnskabsår i et anpartsselskab med flere ejere. Og i boligforeninger. Og...

Bankerne skal så også udsende årsopgørelse på forskellige dage. Det vil nok gøre deres regnskaber underholdende.

Alt dette besvær for at opnå en faktor 365 mindre belastning på systemerne.
Umiddelbart virker det som om det vil være billigere for samfundet at ofre lidt mere hardware til Skat end at gøre skattesystemet endnu mere komplekst for alle.

Dermed ikke sagt, at man ikke kunne sprede udsendelsen af årsopgørelser ud over et par uger.

Christian Nobel

Hvad nu om man drastisk simplificerede hele skattesystemet (bagsiden af den berømte serviet osv.), så ville behovet for at se forskudsopgørelsen være ret beskedent, da alle umiddelbart forstod hvad de forventes at betale i skat.

Men det kræver at politikerne begynder at tage deres arbejde alvorligt.

Bortset fra det, så er det da ikke, som Yoel også siger, raketvidenskab at servere nogle millioner PDF'er fra en webserver - KISS!

Knud Larsen

PHK har jo ret.
Men folketinget og deres håndgangne mænd i administrationen har ikke forstand på logik og fornuft. Det meste bliver smedet af jurister, der bestræber sig på at lave det så fleksibelt, at en jurist altid kan bøje loven til egen fordel.
Dette er er lodret i strid med logik og struktur, som tydeligt påpeget af direktøren for IT i dagens avis i politikken Rikke Hvilshøj.
Politikkerne og deres embedsmænd sætter en ære i at gøre det håbløst.
Alle har glemt indledningen i Jyskelov 1241. " Lov skal skrives, så hver mand kan forstå det" og fortsættelsen "’Dog er ingen lov så god at følge som sandhed’ .

Martin Bøgelund

Du har ikke fattet hvad jeg faktisk foreslår.

Hva' så, charmetrold!
:-D

Det er ikke et spørgsmål om du "må se" dine data, det er et spørgsmål om hvornår skat i det hele taget regner dem ud til at begynde med.

Så flaskehalsen er selve "den store" beregning af alle opgørelser?
Det var min opfattelse at det var brugeraktivitet inde på skat.dk, inkl. eventuelle ændringer der kræver genberegning og lagring i den underliggende database.

Iøvrigt er ægtepars og samlevendes skat filtret sammen. Skal skat ikke beregne én ægtefælles skat for at beregne den andens? Vil vi så ikke alligevel komme ud i at nogle tal er beregnet, men skal foreholdes borgeren? Eller vil du hellere bryde med princippet om at man kan se sin skat på sin "fødselsdag" i måneden?

Ebbe Hansen

behøver vel ikke omfatte et login på deres vaklende hjemmeside?
I stedet kunne en indtastning af cpr på en lidt mere stabil platform (eller måske indsendt i en mail) udløse at forskudsskema/selvangivelse/?? dukkede op i eboks når serverne fik tid.
Således kunne skat.dk nøjes med at servicere dem, der faktisk havde noget at ændre.......

Martin Bøgelund

Sådan læste jeg også indlægget fra PHK først - men en nærlæsning afslører, at han faktisk vil lave en noget mere gennemgribende ændring: Vi skal have 365 kategorier i stedet for 31 (eller 1, som vi har nu).

Så en person født 14/11 skal vente til 14/11 2017 med at få sin årsopgørelse for 2017? Eller skal (skulle) én med fødselsdag den 1/1 have sin forskudsopgørelse for 2017 allerede den 1/1 2016? Eller skal skatteåret være rullende for hver enkelt person/fødselsdato?

Jeg synes ikke forslaget bliver mere helstøbt af at sprede det ud over et år, al den stund at presset på systemet normaliseres hen over 2-3 uger.

Lovgivning og budgetter har jo også en startdato, Ved at dele budgetter op i årsklumper, bliver økonomiske tal lettere at arbejde med, selvom et "rullende" budget også kan have fordele - men så taler vi jo et helt ændret totalsetup, som heller ikke er systemmæssigt undertøttet.

Og så er vi tilbage til at vi skal i gang med store systemiske ændringer, og så er der ikke noget quick fix i det.

Martin Bøgelund

Lad os sige, at man lader folk indsende selvangivelse på deres fødselsdag. Hvis vi fastholder kalenderåret som skatteår, skal man være ualmindelig rap på fingrene, hvis man har fødselsdag d. 1. januar. Til gengæld har man masser af tid, hvis man har fødselsdag i december.

Som det er nu, er der ganske rigtigt skæringsdatoer, men det betyder jo ikke at man kun kan indtaste oplysninger dén dato - du har en periode op til. Sådan må det også tænkes at være i PHK's forslag; der åbnes op for indtastning til forskudsopgørelsen 1-2 måneder før din fødselsdato, korekkstioner til din årsopgørelse skal være foretaget 3 måneder efter din fødselsdato, osv.

Det bliver et virvar af datoer som vi ikke kan hjælpe hinanden med at huske, fordi de er individuelle, de gamle bliver forvirrede, osv. Men rent systemmæssigt og administrativt kan det sikkert bringes til at give mindst lige så god mening som det nuværende system.

Den "rullende" tankegang er faktisk meget god, hvor du ikke har én kørseldato for hele baduljen én gang om året. Finansloven vil nok lide en smule under at forventede skattebetalinger (indtægter) i gennemsnit kun dækker et halvt finansår frem, fremfor et helt. Og en stor hurdle som du selv nævner er skattelovgivning og dens ikrafttrædelsesdato.

Men hele setup'et rundt om skat og den pengestrøm det genererer, vil som sagt skulle ændres for at brikkerne i puslespillet med de rullende skatteår, skal passe sammen. Og så er det nok alligevel nemmere at skifte system...

Leif Neland

En stor del af brugerne vil kun se deres forskudsopgørelse, vil ikke rette den.

Så skat kunne sende forskudsopgørelsen til e-boks, så skulle kun de, der vil rette, logge ind hos skat.

Alternativt, kunne laves et servercluster, hvis eneste funktion var at vise den nuværende forskudsopgørelse, og de, der vil rette, skal så evt stå i kø for at få lov til det, på andre servere.

Morten Bøgh

Formuleringen er ikke god:

Det er ikke Skats mainframe, det er i det her tilfælde KMD’s. Andre dele af Skat kører på CSC’s mainframe.

Mainframes er ikke vakkelvorne: Meget andet kan man beskylde mainframe for, men i spørgsmålet om vakkelvorenhed er mainframe en robust platform med relativt stor afstand mellem hardware-introducerede fejl.

De pågældende mainframes er ikke gamle, mainframes udskiftes nogenlunde i samme takt som andre platforme.

Mainframens robusthed (og manglende vaklen) hænger sammen med arkitekturens alder, herunder dens kompatibilitet bagud og fremad. Dette indebærer at mainframe platformen meget sjældent introducerer fejl som skyldes ændringer i platformen. Hvis skattesystemet kørte under Windows (for at tage den ekstreme modsætning) så ville vi se vaklen som skyldes inkompatible versionsskift i platformen.

Mainframe har ikke så voldsomt meget med sagen at gøre: Bruger-dialogen i Skats forskudssystem kører på midrange-platforme. Mainframes bruges til det de er gode til: Nemlig core-systemet, dvs den del af systemet der håndterer pengestrømme og hvor fælles ‘commit’ mellem alle komponenter (databaser) er afgørende. Om KMD’s design af forskudssystemet helt lever op til dette, ved jeg ikke, men i de store linier må det være rigtigt.

De allerfleste banker i verden kører maninframe i deres core-system. ‘Truslen’ mod mainframe er ikke midrange og ‘skyen’, men ’ truslen' kunne være block-chain teknologier, som - i lighed med mainframe - tilbyder absolut sikkerhed vedrørende om en transaktion mellem flere parter er gennemført eller ikke er gennemført. Her burde diskussionen om mainframe befinde sig.

Alex R. Tomkiewicz

Nej-ministeriet har talt. Der er bevilget et afslag og sagen er lukket. Du skal ikke komme her med dine gode, grænsende til fremragende ideer. I ministeriet er vores motto: Der er ingen grænser for hvad man ikke kan, når man ikke vil. Vi har haft meget stor succes efter at det er blevet vores motto. Før det prøvekørte vi et værdisæt med titlen: Uden reaktion, ingen aktion. Stik modsat intentionen, satte det for meget i gang.

Med ønske om fortsat tilbagegang, ærbødigst

Nej-ministeriet.

Michael K. Jensen

Jeg forstår ikke lige problemet, der er allerede lavet noget kø system som er super godt lavet, hvor man kan se hvornår man kan komme til.
Så der er en smule ventetid!
Er der nogen der har et reelt problem med det? Der er sikkert mange ting der kan gøres bedre, men der her virker som et sted hvor tingene faktisk virker rigtig fint, hvor det ikke er nødvendigt at sætte ind med resourcer eller lave omstruktureringer.

Jeg har ventet op mod et kvarter max og med kø systemet der er indført var systemet også rimelig responsivt.

Er der et reelt problem og hvad er det.
Er det ikke bedre at bruge ressourcer på nogle reelle problemer?

Log ind eller Opret konto for at kommentere