1.885 sider: Her er kravspecifikationen for Skats fejlslagne EFI-system

Jeg er helt enig - 1.900 sider er i bedste fald kun til overskrifterne for hvert enkelt udviklingstrin indenfor hvert enkelt emne. Som eksempel kan jeg oplyse at kravspec'en til vores landmine detektor projekt fylder ca det dobbelte - og dette projekt koster 1/100 del af EFI og er langt mindre kompliceret. Vi snakker sørme så meget om hvor gode vi er til at forstå og bruge it - men det kniber sandelig med at oversætte ønskerne til faktuel data som kan benyttes til andet end øregas

de baserede det på en Service Bus arkitektur og fejlede deraf. Kun Event Bus (dumb pipes, intelligent endpoints) kan skalere til deres behov (tænk patch udrulning med en giiiga database i midten med aktive data, der skal migreres ved hver udrulning)

Jeg synes at huske at have læst i en anden tråd herinde, at der var ca. 200 nye tilføjelser til disse regler om året. Og aldrig nogen gamle regler som helt bliver fjernet, for i fortiden gælder de gamle regler stadig.

Kombinationsmulighederne er derfor astronomiske.

En ny regel pr. arbejdsdag i snit i al fremtid gør sådan et system umuligt at implementere.

Kald det juridisk denial-of-service.

Velsagtens også umuligt for mennesker at administrere 100% korrekt i alle tilfælde. Og når fejl opdages i en manuel proces, laves afgørelserne bare om pr. sag manuelt fordi nogen brokker sig i enkeltsager. Det er ikke muligt for et program. Her skal alle tests virke efter hver ændring.

Jeg er ikke sikker på sådan et system overhovedet kan lade sig gøre at implementere og vedligeholde - ikke engang i udviklingstiden.

Skattelovgivningen er jo udformet af vores Folketing, det er et pragtfuldt værk som vore ledere har udbygget igennem generationer, og der er tænkt over hver eneste lille detalje. F.eks. er millimeterretfærdighed indbygget som en af grundpillerne under alle de tusinder af paragraffer. Det bør omtales med respekt. Det er Danmarks stolthed, og faktisk alt for smukt til at det kan implementeres af almindelige programmører - der skal genier til! Glem bare alt om at ændre et komma i dette pragtværk - det er perfekt og evigt.

Det er også derfor den nye sundhedsplatform er håbløs og crasher!

Det betyder, at ansatte i en intern udviklingsorganisation ville have samme problem med manglende domæne-viden.

Jeg har ikke læst på EFI udbuddet, men de andre udbud fra Skat som jeg har været med i, fylder med bilag mere end 1.900 sider. Jeg ville nærmere sige omkring 10.000 -> 20.000 sider, men jeg ved det ikke for udbuddet var i 3 store flyttekasser med fyldte ringbind og ingen læste alt.

Og det som funktionelt skulle laves i ”det nye udbud” skulle matche det som ”man havde i dag”.

Sidste gang fik jeg løn (af en byder) for at læse de mange sider indenfor mit område og denne gang er det så uden løn – så det springer jeg over :-)

I mine øjne var ”det helt sort” at man gik efter en samlet løsning – med samtlige gældsformer/inddrivelse i et hug! Man burde havde lavet et skalerbart system hvori man udtog højest 10 gældsformer/inddrivelse ud af de ca. 400 gældsformer som der er i dag.

Derpå kunne man løbende tilslutte nye/ændrede gældsformer som ”bølger”.

Det er jo helt hen i skoven – at forstille sig et lovgivningsstop i den periode et EFI-system implementeres, men hvordan skal det ellers ske? Hvis politikkerne via deres ændrede skattelovgivning hele tiden ”flytter målstregen” på den funktionalitet som er aftestet og klar til produktion?

Problemet er bare, at det lyder udbuddet ikke på. Det lyder på et samlet system – med alle gældformer.

Herefter ”klapper man hælene sammen” og siger javel for du vinder ingen udbud på, at tilbyde noget andet end det udbuddet lyder på.

Og det var måske her man skulle starte – med IT kompetencer ansat i Skats udbudsafdeling?

Nu er det vigtig at huske på, at dette var et nyt område, som skulle it-understøttes. Det betyder, at ansatte i en intern udviklingsorganisation ville have samme problem med manglende domæne-viden. Reelt er problemet, at viden om den konkrete forvaltning af lov-komplekset var delt ud på mange forskellige personer (og lur mig om, der ikke også var forskellige måder at forvalte den samme lov på). Så første skridt i en digitalisering bør være at lave en samlet beskrivelse af forvaltningen. Hvis loven er passende stor er dette reelt en uoverkommelig opgave, da man skal identificere alle mulige situationer.

Så vi ender nok i den sædvanlige situation - gennemfør det i små overkommelige bidder - find de overskuelige tilfælde, digitaliser, få erfaring, brug erfaringen til at forstå mere komplicerede tilfælde - og gentag

Husk på at skattelovgivningen er så kompleks, at selv folk hos SKAT ikke altid selv kan forstå den og anvende den korrekt.

Denne skattesænkning giver den klart største besparelse i kroner og øre for dem i de største boliger/de rigeste.

En af de store tanker omkring "konkurrenceevnen" og "globaliseringen" er at alle lönninger skal presses ned til Nul og alle offentlige sociale sikkerhedsnet fjernes så "vi", d.v.s. KUN lönmodtagere kan få lov til at konkurrere på lige fod med 3'die verdens lön- og arbejdsforhold.

Det er jo så lidt muggent, hvis man også samtidigt gerne vil tage 1'ste verdens gebyrer, skatter, afgifter og priser for alting. Pengene skal jo komme et sted fra. Derfor puster man bevidst en boligboble op.

Midlerne kommer dermed ikke fra forbedrede lönninger, de kommer fra lån, gäld, primärt i boliger. "Väksten" stopper når boligerne ikke kan belånes yderligere, for eksempel hvis prisen på boliger ikke stiger. Derfor skal renten ned, beskatningen skal ned, vi skal have slappere kreditvurderinger, der skal "liberaliseres" så hvem som helst kan låne til hvad som helst og vi skal have placeret statskassen som bagstopper for den private gäld så ingen nogensinde behöver at tvivle om der er en god ide at låne penge ud, "tillid" tror jeg man kalder det.

Det er meget påfaldende at hver gang boligmarkedet kölede af i nullerne, så kom der lige en lånemulighed til for at hjälpe "väksten" på vej. Vi ser med boligbeskatningen at man er fanget mellem to onder, skatten kan ikke stige fordi så falder prisen på boliger, men, man kan heller ikke tillade at lave en reform der afspejler markedet fordi det ville give faldende indtägter til staten. Ingen kan låne mere, fordi alle er maxet ud, "väksten" er stendöd og vil våre det indtil gälden er afskrevet, men hvis det sker dör bankerne.

Selvskabte problemer er altid nästen ulöselige fordi begyndelsen på lösningen kräver at man ändrer sin måde at opfatte verden på - og så lige nu, hvor man er helt perfekt og verdens bedste til alting og kan köbe hele verden (på kredit, men det täller jo også lidt).

Så i stedet for pröver man at få regeringstiden til at gå med lidt klyt og småfusk indtil det hele er "oppositionens" problem og alting gentager sig.

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

Opgaven burde nok have været beskrevet på langt færre sider, og så kunne man i iterationer undervejs i projektet detailbeskrive del-opgaverne.

Øh, jeg tror ikke rigtig du forstår kompleksiteten af det her. Hvad systemet sådan skal kunne, altså hvordan ser 'forretnings processerne' og usecases ud, der skal understøttes og implementeres ud, står jo ikke beskrevet i de her dokumenter.

De krav der er specificeret og som skal besvares, er sådan noget mere generelt.

Hvad der faktisk skal implementeres er som jeg forstår det beskrevet i Skats Metadata Repository. (Se appendix 22).

// Jesper

Nej og har du læst lovgivning den skal overholde? Tilføj x antal hundrede sider....

Husk på at skattelovgivningen er så kompleks, at selv folk hos SKAT ikke altid selv kan forstå den og anvende den korrekt.

Enig !!!

Jeg så helst at SKAT ansatte en IT-udviklingsafdeling som fik opgaven at lave EFI ..

med alle de milliarder det koster at udvikle ku man snildt ansætte en hel masse som kunne få en grundig domæneviden..

Det her er vel bare det oprindelige udbud. Så det er jo ikke nødvendigvis, hvad der faktisk kom til at ske.

Men der er da sådan umiddelbart et par ting der springer i øjnene når man skimmer dokumenterne igennem.

1. Der er lagt op til at det er SKAT's projekt, og at 'leverandørene' er underleverandører.

2. Kvalitetsstyring er kun specificeret på leverandør niveau. Det vil sige at der er ikke beskrevet en kvalitetsstyrings model på tværs af 'projekter leveret af forskellige leverandører', altså 'SKAT's' egen kvalitets styring er ikke beskrevet, ud over den organisatoriske forankring. Det lugter lidt af at koordineringen mellem del projekter kommer så højt op i hierarkiet, at der er en fare for at den mere tekniske og praktiske koordinering ikke kommer til at ske. Og at der derfor er en fare for at delprojekter derfor ikke kommer til at 'passe sammen'.

3. Der er pænt strenge begrænsninger på i forhold til hvor meget leverandørerne kan trække på ekspertviden hos SKAT. Og set i lyset af hvordan vi har fået beskrevet at kompleksiteten viste sig at være væsentlig større end først antaget så ja er det da bekymrende.

Tja ja...

// Jesper

Dette er bare endnu et eksempel, hvor man tydelig kan se, at man ikke "bare" kan kalde på konsulenter. Mange steder kræves der simpelthen en domæne viden af udviklerne, og arkitekterne, som ikke bare kan opnås via en kravspec, men igennem et langt forløb i en branche. At man ansætter konsulenthuse til at løse opgavnerne istedet for at opbygge egen viden, er, for mig at se, en af de væsenlige årsager til de mange fejlslagende offentlige it projekter.

Når man læser artiklen, får man næste lyst til at spørge, om det er den rigtige kravsspecifikation, I har fået udleveret. Men som systemet virker er det jo den rigtige.

Også hjælper ingen teknisk analyse, fordi det er en bevist handling (læs ”Mørkelygten” af Jesper Tynell) fra de ansvarlige (Anders Fogh, Lars Løkke, Claus Hjort, Kristian Jensen) at få skrevet et dokument, der sikrede at skattesystemet crashede på et eller andet tidspunkt. Når noget er crashet, er man jo nød til at lave det om.

Tag det lidt mere simple skatteproblem med boligskatten. Før Fogh/Løkke/Hjort/Jensen fremturede med deres ”skattestop på boliger”, havde man synsmænd til at gå rundt og vurdere, de klager der kom over værdisætningen af deres bolig. Disse synsmænd var lokale og kunne derfor tage alle de ting med i betragtning, der skulle tages med. Derfor var deres vurderingere præcise. De var ulønnede og dermed billige. Altså et billigt, præcist og effektivt system.

Disse synsmænd blev nedlagt i forbindelse med ”skattestoppet på boliger”, da der jo ikke var brug for dem, da skatten en gang for alle var blevet fastsat. Det selvom det ville være helt gratis at have dem til at stå stand by, til man på et eller andet tidspunkt igen ville få brug for at få vurderet boligpriser. Systemet kortsluttet og crashet.

I disse dage bruges det så til at sænke skatteprocenten på boliger til de facto 0,48%. (http://finans.dk/live/opinion/ECE9074509/faktorernes-orden-er-ligegyldig-dog-ikke-i-regeringens-boligskatteudspil/?ctxref=ext). Dette begrundes i at men vil sikre sig mod usikre vurderinger. Lige præcist det resultat man fik ud af at nædlægge synsmandsordningen.

Denne skattesænkning giver den klart største besparelse i kroner og øre for dem i de største boliger/de rigeste. Det drejer sig om 100-vis af kroner for den fattige boligejer og 1000-vis af kroner for den enkelte rige og mia. for fælleskassen. (Hvis det nu var det politiske program man havde lagt frem var det en ærlig sag, men det er det som bekendt ikke.)

Derfor kommer man ike nogle vegne med/det giver ikke nogen mening at lave en teknisk analyse af kravspescifikationen til skattesystemet. Det er et politisk problem.

Jeg vil sige, at det netop er med til at gøre det svært. Med 1885 sider "klarlægning" tror jeg ikke, at der er nogle enkeltpersoner, der kan overskue, hvad løsningen skal gøre.

har du læst den ? jeg har ikke...

så reelt set ved vi ikke om kravspec egentlig er fin nok

Start med at lave en analyse af den eksisterende arbejdsbyrde.

Find de top 1% af opgaver der tager flest mandetimer at udføre.

Beskriv disse opgaver som processer i form af input og output - hvor kommer dataen fra, og hvordan skal dataen se ud når den forlader processen, præcis som det fungerer i dag. Sæt enginiørerne sammen med den eller de personer der tidligere har varetaget processen, og lad dem sammen komme frem til en forbedret process, i stedet for at levere en kravsspecifikation, der ikke kan omdannes til et computerprogram, fordi den er beskrevet på en unaturligt kompleks facon der forsøger at redegøre alle både gyldige og ikke gyldige scenarier. De folk der førhen har stået for opgaven er nu kun nødt til at håndtere de obskure scenarier som er unødvendigt svære at programmere sig ud af, samt er sjældne og ikke bør være en del af første iteration.

Automatiser opgaverne.

Gentag processen.

De offentlige institutioner bliver ved med gang på gang at automatisere alting på én gang. De prøver at erstatte alt for mange systemer og tiltag på en gang, og de benytter sig ikke af de ressourcer de allerede har, i form af folk der har arbejdet med de eksisterende processer de sidste 30+ år.

I stedet bør de fokusere på at automatisere og effiktivisere de processer der eksisterer allerede, og som gradvist vil forbedre det eksisterende system, i stedet for at prøve at erstatte det.

Med et system der opbygges modulært og i mindre bidder vil de i langt større grad opleve en mængde af små success historier, hver gang et nyt initiativ resulterer i en reducering af den eksisterende arbejdsbyrde, i stedet for store og katastrofale investeringer der vokser sig ud af proportioner og ender med at fylde kistebunden hos KMD, CSC, osv.

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

Jeg vil sige, at det netop er med til at gøre det svært. Med 1885 sider "klarlægning" tror jeg ikke, at der er nogle enkeltpersoner, der kan overskue, hvad løsningen skal gøre.

Opgaven burde nok have været beskrevet på langt færre sider, og så kunne man i iterationer undervejs i projektet detailbeskrive del-opgaverne.

Mon ikke det er her, det kniber?

Jo måske, men med 1885 sider må det da være lykkedes at forklare hvordan pengene flyder rundt og reglerne omkring det.

jeg nægter at tro på at man ikke undervejs har kunnet spørge de relevante mennesker om ting som mangler i kravspec (hvis det alligevel er tilfældet, så kan jeg godt se hvorfor det hele falder sammen)

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

Hvis alle processer i systemet er klarlagt og forståelige, så kan det ikke være svært at implementere ...

kan der være tale om et af følgende:

• inkompetence hos leverandøren ?
• for få midler eller tid til at færdiggøre projektet ?
• at kunden (SKAT) ændre krav undervejs ?
• at kunden (SKAT) ikke vidste præcis hvad de ville have ?

... indtil lovgivningen er klargjort hertil.

Så længe man har en kompleks lovgivning vil IT-systemer have det meget svært ved at håndtere alle tænkelige usecases og fejl vil helt sikkert opstå. At man udvikler på en ny og mere agil måde, vil ikke afhjælpe kompleksiteten, selvom det helt sikkert vil hjælpe en hel del.

Selv en amatør virker det tydeligt ud fra de i artiklen refererede eksempler, at det må være et meget svært system at få skruet sammen på forsvarlig måde. Det rejser så det nye spørgsmål, hvem det er, der har bildt ledelsen og politikerne ind, at det kunne lade sig gøre?