Hvorfor gik det så galt med IT-projektet for de nye ejendomsvurderinger?

12 comments

1. Andre folks penge, thats why..

2. Mit bedste bud. 1: Vi har et afverdens mest komplicerede skattesystemer. 2: Ejendomsvurderinger er ikke baseret på fakta. De er vurderet på skøn. Hvis vi blev beskattet af avancen på boligsalg, så ville der være være data at fastsætte beskatningen af

3. > 40% medarbejder omsætning de sidste 2 år.

   Dette er lidt misvisende. Tallet inkluderer folk der skiftede kontor og eftersom der var en organisationsændring i ICE og UFST i 2020 og 2021 så er tallet meget mindre

   Jeg kan ikke kommentere omkring de scopeændringer der har været over de sidste 9 år, men jeg ved at når polittikere designer systemer uden at have IT folk tilstede, ender du med et kravspec der er næsten umuligt at inplementere

4. Nu har jeg ikke fulgt dette project, men generelt så sker disse ting på grund af for dårligt forarbejde og/eller Project Scope Creep (https://www.projectpractical.com/project-scope-creep/) (undskyld ved ikke hvad det hedder på dansk).

   Man skal ikke lade eksterne konsulenter være projekt ansvarlige, de har ingen interesse i at få projeketer afsluttet. Jeg snakker ikke om IT Konsulenter, men om management konsulenter.

5. Det offentlige elsker vandfaldsmodellen til IT-projekter fordi det minder om udviklingen af så meget andet. Hvis man f.eks. skal bygge et hus eller lægge en ny jernbane, så laver man alt planlægningen først, så designet, og så implementerer man først når man er sikker. Det vil ikke give mening at bygge én væg af huset og så først derefter tage stilling til hvad der skal ske nu.

   Men vandfaldsmodellen er ikke god til andet end små IT-projekter. Den blev oprindeligt foreslået som en dårlig måde at arbejde på, da man ikke kan tage højde for ændringer undervejs.
   Det vil sige at hvis du er i gang med at kode, og opdager at noget du har planlagt slet ikke fungerer, så er du enten nødt til bare at gøre det alligevel, eller stoppe hele projektet og gå tilbage til en ny stor analysefase.
   Typisk bruges iterative/agile metoder i stedet til IT, hvor man bevæger sig flere gange rundt i faserne, og udvikler én del af programmet af gangen. Og hvis det skulle være problemer eller ændringer i samfundet, er det lettere at inkorporere dem i det næste runde man tager.
   Men det offentlige er ikke så glad for den slags metoder da det gør det meget sværere at sige præcist hvornår man er færdig og hvad det vil koste.

   Og til den sidste del, er der altid en sammenhæng mellem forsinkelser og medarbejderrotation. Igen er det et problem med det offentliges syn på IT som værende det samme som alle mulige andre projekter: Hvis 1 mand kan grave et hul på en uge, kan 3 mand gøre det på 2 dage, og 10 mand kan være færdige inden frokost.
   Men den går ikke i projekter der kræver høj teknisk indsigt i planlægningen, designet, og processen (som f.eks. IT-projekter). Hver gang du hiver en ny person ind skal de bringes “up to speed” og du har yderligere kompliceret kommunikationskanalerne mellem projektets medlemmer. Frederick Brooks er kendt for at sige at “what one programmer can do in one month, two programmers can do in two months” og “adding manpower to a late project makes it later”.
   Så den klassiske idé om at smide flere folk efter et projekt der er forsinket, fungerer ikke med IT. Det samme problem opstår hvis folk forlader (eller bliver smidt ud af) projektet undervejs.

6. Jeg har ikke været med i projektet, men har set på det fra sidelinjen. Du finder aldrig en enkelt forklaring på hvad der er sket. Mange ting er gået galt – noget som burde være forudset og håndteret politisk inden projektet startede (fx at vi har både grundskyld og ejendomsskat – grundskyld er super svært at beregne fordi der sælges meget få grunde), noget skyldes dårlig eksekvering (ingen samlet leverandør som kan tvinges til at levere produktet ift kontrakt, hyperkomplekst arkitektur- og lovgivningsarbejde) og andet som sker når man har været igang med et projekt så længe med så meget bevågenhed (kompetencer forsvinder, nye krav kommer ind, teknologien indhenter dig).

   Nu siger du til en skoleopgave. Se evt på professor Bent Flybjergs artikler om hvorfor megaprojekter fejler. De rammer meget godt nogle af de generiske årsager – og er skrevet på letforståeligt engelsk.

7. Jeg tror de har jagtet det perfekte system, og det findes ikke.
   Vurderingerne vil aldrig være korrekte, men kan man jo ikke stille sig tilfreds med.

8. Prøv at se om du kan få fat på Søren Lauesen eller Erik Frøkjær – send dem en email

9. Ulykken startede da Anders Fogh indførte skatte stoppet i 2000, som betød at ejendomskatten ikke skulle regulers mere, og det gamle system med ejendomsvurderinger udført af mæglere blevet udfaset.
   I samme periode blev skatte kontoerene overført fra kommunerne, og centraliseret. Antallet af ansatte blev reduceret, og opgaverne er ændret fra sagsbehandling af den enkelte borger, til at deffinere regler i et IT system.

   Daværende overvismand Peter Birch Sørensen sagde i 2009, at skattestoppet, der fastfrøs ejendomsværdiskatten – ikke bare i procent, men i kroner og øre – var en del af forklaringen på, at det danske ejendomsmarked gik langt mere amok end i andre lande.

   https://da.wikipedia.org/wiki/Skattestoppet

   På et tidpunkt finder man ud af at vi ikke kan leve med 20 år gamle ejendoms vurderinger.

   Så får man den ide at man må kunne lave et ekspert system der kan udregne ejendomsværdien ud fra salg i området, og data i BBR.

   Det var dømt til at mislykkedes.

   Det var bedre hvis man havde beholdt ejendomsmæglernes vurderinger, og så langsomt have bygget et ekspert system på til beslutnings understyttelse.

10. Du kunne evt perspektivere lidt til zillow’s ejendomsvurderings-bommert.

    Det var dog hovedsageligt et teknisk problem, men samtidig et ledelsesproblem, da der måtte have siddet nogle udviklere derinde, som godt vidste det ville gå galt, men ikke kunne få det igennem til de øvre lag.

11. Rent teknisk er problemet at man vil op til flere ting i projektet. Projektet skal:

    * Strømligne dataindsamling til projektet
    * Ved hjælp af en statistisk model udregne ejendomspriser
    * Bygge front-end til sagsbehandling
    * Bygge en GIS løsning også til sagsbehandling
    * Integrerer sagsbehandling med et eller andet KMD journaliseringsprodukt jeg har glemt navnet på
    * Indvoldvering af aftagerne af projektet

    Det lyder jo egentlig fint nok, men det er det offentlige, så:

    —

    **Strømligne dataindsamling til projektet**

    Det skulle være ligetil. Ca 30 datakilder fodrer projektet, så det er ETL, data ind fra flere kilder, jævnfør som samlet kilde. Det er fint, rent teknisk ville det nok være lettest med en service til hver kilde i et generelt programmeringssprøg (python, java, c#, osv.) der fodrer en central source-of-truth server.

    Den løsning der endte med at blive valgt var at have et 30 mand stærkt kontor der ved hjælp at softwareløsningen / programmet SAS (nok bedst kendt for at være et lidt ældre statistisk værktøj) og ikke mindre end fire progressive SQL databaser. Så du har data ind -> server 1 -> server 2 -> server 3 osv. Hvis du ikke er så bevændt indenfor softwareløsninger så lad mig fortælle dig: Det er en dårlig løsning.

    Dertil er mange af kilderne super ringe. BBR-registret f.eks. er ofte fejlbehæftet og mængden af felter og kvaliteten af data varierer fra kommune til kommune. I f.eks. Rudersdal kommune skal du angive præcist hvor mange toiletter du har, 1, 2, 3, 4 osv, men i Læso kommune kan du angive 1, 2 eller flere. Fun fact: Databaser er nærmest allergiske overfor sådan noget, og der er tusindvis af datapunkter. En del data findes ikke for nogle ejendomme og hvad gør man så? En ejendom der har været solgt 5 gange de sidste 20 år har nok ikke 0 toiletter.

    I bund og grund er Danmark nok ikke datamodne til at lave den her slags projekt, og vi var slet slet ikke datamodne da projektet startede i 2012.

    —

    **Ved hjælp af en statistisk model udregne ejendomspriser**

    Brug en statistisk model til at udregne prisen på et hus baseret på 100k parametre. Fint, det er nemt nok. Men hvis du ikke må bruge deep learning, men kun modeller hvor du 100% kan forklare hvad der foregår så bliver det noget mere besværligt.

    Oveni det er den statistiske løsning lavet som et batch program, det vil sige du fodre programmet med ejendomsdata for 1 million parcelhuse og historisk data for salg og priser, badeværelser, rotter på loftet, osv og så går programmet i gang med at regne ud hvad dit hus er værd. Men hvad nu hvis du bor i et område hvor huse ikke bliver solgt så tit? Hvad nu hvis du har en landejendom? Hvordan prissætter man en skov? En masse problemer man har forsøgt at løse med en computer hvor man i programmet nok skulle have sagt “der er 1000 enkeltstående ejendomme der skal regnes en pris på en hånden”.

    Det havde været og er en fin løsning.

    Men

    og det er det store men

    Skat på ejendomme i Kongeriget Danmark er baseret på to beløb. Prisen på huset, bygningen, dine mursten, og prisen på din grund. For parcelhuse er det fint, de bliver altid solgt sammen. Det betyder til gengæld også at der er en milliard edge cases: Hus på fremmed grund, dvs. du ejer huset, men ikke grunden; ejerlejligheder og andelsboliger, hvor grunden der ligger under bygningen aldrig bliver solgt. For ejerlejligheder er det kun enkelte lejligheder der bliver solgt, aldrig grunden eller fællesbygningen (facaden f.eks. tilhører ejerforeningen), og for andelsboliger bliver boligen aldrig solgt, du køber et andelsbevis og bliver anvist en bolig i foreningen. Det betyder at sidst grunden har været til salg for rigtig mange foreninger var i 30’erne eller 50’erne så det kan din statistiske model ikke bruge til noget.

    En del ejendomme har også fællesarealer som ikke bliver solgt, men har en værdi.

    Men hvorfor er det et problem? Jo ser du, Programmet der laver Ejendomsvurderinger skal følge en lov, og den lov siger at vurderinger skal laves på baggrund af mursten og jord. Ekstra fun fact: Den lov er blevet forfattet af programmet og leveret til folketinget, hvilket vil sige programmet har selv skrevet en lov der i praksis er meget svær at putte i praksis.

    og så lige en sidste ting: Den statistiske model der laver ting i batches? Det er rigtigt fint, men noget der ligner 4 år inde i projektet blev det besluttet at man skulle kunne lave spotberegninger på huse så en sagsbehandler kunne lave en ændring, hvis f.eks data var noget rod, og så re-beregnen en ejendomsværdi. I stedet for nogen satte sig ned og tænkte sig rigtig godt om, så blev det besluttet af man “bare” laver en mini-batch-beregning. Tid fra en sagsbehandler klikker “beregn” og har de nye tal? 15-20 minutter.

    —
    **Bygge front-end til sagsbehandling**

    Nok den mindst problemfyldte del af projektet. Altså udover der var tre frontends i gang der blev bygget forskellige steder, med to forskellige programmeringssprog og uden der rigtigt blev snakket sammen. Det største problem her er ledelse: De folk der skulle bestemme, sætte retning og inddrage *stakeholders* er uduelige og ved ikke noget om software. Der er *apparatchiks*, de er folk der kan finde ud af at lave powerpoint og udfylde sygedage i SAP.

    Det minder mig om en person / gruppe der ikke blev spugt: Sagsbehandlerne. I stedet for at inddrage dem så tidligt i processen som muligt blev de aller nådist udlånt fra Vurderingsstyrelsen i meget korte perioder. De stalker der i sidste ende kommer til at blive udsat for det makværk der er dette projekt blev ikke spurgt om hvad der gav mening af have i et program for hvad der er deres ekspertområde.

    En af de andre frontends der blev bygget på var en GIS løsning lidt ala skråfoto. Det er egentlig en god ide, men hvorfor det skulle gøres seperat fra det andet frontendprojekt er lidt sært. I et projekt hvor de fleste teams var 15-20 personer var de 3.

    —

    **Integrerer sagsbehandling med et eller andet KMD journaliseringsprodukt jeg har glemt navnet på**

    Alt data og alt behandling skal per lov journaliseres så man kan få aktindsigt. Det er i hvert fald teorien. 30 personer hvoraf 10 af dem var amerikanske konsuleter i USA arbejdede på at få det her KMDprodukt til at makke ret.

    Jeg forstår den dag idag ikke hvorfor hvad der i princippet er en read only append only database er *så* svært, men hvad ved jeg.

    De flinkeste, mest rolige person var i øvrigt i det her team.

    —

    Ledelsesmæssigt er projektet noget rod. Kontorchefer er i bund og grund glorificerede sekraterer, men de andre ledende skikkelser, Product Owners, Project Manager, Arkitekter, Togarkitekter, Scrum Masters og hvad der ellers er af titler formåeded ikke meget andet end at holde utroligt mange møder om hvordan det gik.

    For hver person der laver software i projektet er der mindst en person der ikke gør. Der er 20-30 arkitekter på projektet. Der bliver ansat folk der ikke ved noget om software til at styre det. Der bliver ansat folk der ikke ved hvad de skal lave på projektet.

    Det gik altid ad helvede til, men hvis du på et møde sagde det gik ad helvede til blev du mobbet til at sige det nok skulle gå. Jeg spurgte en gang hvad der ville ske når nu vi ikke nåede den kommende deadline, en deadline sat af Folketinget i øvrigt, og fik at vide det *skulle* vi (vi nåede det ikke).

    Der er sikkert 1000 ting jeg har lykkeligt glemt. Hvis jeg til sidst skulle beskrive projektet med et ord er det “Agilefall”.

12. Fordi effektivitet og den offentlige sektor ikke går hånd i hånd, og konsulenter vil da bare trække det ud i langdrag det jo fast arbejde for dem i den periode