PID 2015 Ejendomsvurderingsprojekt

Projektinitieringsdokument (PID)
Ejendomsvurderingsprojektet – it-sy-
stem til understøttelse af de nye ejen-
domsvurderinger
12. maj 2015
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen

Produkt: PID, ver. 2.2
Indhold
1 STAMDATA ............................................................................................ 2
2 FORRETNINGENS FORMÅL MED PROJEKTET .............................................. 2
3 SCOPE OG AFGRÆNSNINGER .................................................................. 7
4 MÅL OG SUCCESKRITERIER ..................................................................... 8
5 ØKONOMISKE HOVEDTAL OG FINANSIERING ............................................ 10
6 GEVINSTER ......................................................................................... 12
7 TEKNISK LØSNING ................................................................................ 14
8 LEVERANCER ..................................................................................... 20
9 ORGANISERING ................................................................................... 21
10 TILRETTELÆGGELSE OG TIDSPLAN......................................................... 24
11 KVALITET ............................................................................................ 31
12 RISICI ................................................................................................. 34
13 INFORMATIONSSIKKERHED ................................................................... 35
14 INTERESSENTER.................................................................................. 37
15 KOMMUNIKATION ................................................................................. 40
16 TOLERANCER ...................................................................................... 40
17 RAPPORTERINGSKRAV ......................................................................... 41
18 REVISIONSHISTORIK ............................................................................. 42
19 BILAG ................................................................................................. 42
20 PRODUKTBILAG C: RISIKOREGISTER ....................................................... 43
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [1]

1 Stamdata
Stamdata
Projektnavn Ejendomsvurderingsprojektet - it-system til understøttelse af de nye
ejendomsvurderinger
Journalnummer 15-0693366
Projektleder Steen Larsen
Projektets primære formål Kvalitetsløft
Nuværende fase Analysefasen.
Finansministeriet har givet dispensation til, at risikovurderingen i IT-pro-
jektrådet gennemføres i august efter udsendelsen af udbudsbekendtgø-
relse, men inden udlevering af udbudsmaterialet, hvilket betyder, at
kravspecifikationen påbegyndes inden projektet er risikovurderet.
Finansministeriet har endvidere givet dispensation til, at SKM kan gen-
nemføre et udbud med forbehold for de bevilligende myndigheders god-
kendelse. IT-projektet skal forelægges Finansudvalget inden kontraktun-
derskrivelse.
2 Forretningens formål med projektet

Ejendomsvurderingerne anvendes primært som beskatningsgrundlag for ejendomsskatter, der
genererer et årligt provenu til det offentlige på ca. 40 mia. kr. It-systemet skal være med til at
fastholde og sikre provenuet, der udgør en væsentlig del af finansieringen af velfærdssamfun-
det.
2.1 Den nuværende situation (baggrund)

Rigsrevisionen har med Beretning om den offentlige ejendomsvurdering fra august 2013 udtalt
kritik af Skatteministeriets forvaltning af ejendomsvurderingerne.
Regeringen nedsatte på baggrund heraf et uafhængigt ekspertudvalg, der havde til formål at
komme med anbefalinger til, hvordan kvaliteten i ejendomsvurderingerne kunne forbedres.
Ekspertudvalget præsenterede i sin rapport fra september 20141 blandt andet en prototype til
en vurderingsmodel for ejerboliger, en andelsmodel for grunde og en række principper for den
fremtidige vurdering af erhvervsejendomme og landbrug/skovbrug. Udvalget pegede endvi-
dere på, at datakvaliteten på en række centrale områder bør forbedres, og at der bør etable-
res forbedrede og mere effektive klageprocesser, der også kan imødekomme et forøget antal
klager.
Udvalget anbefalede endvidere, at vurderingsprocesserne fremadrettet så vidt muligt bør være

maskinelle og automatiserede.
Regeringen etablerede med afsæt i Ekspertudvalgets anbefalinger et nyt Implementeringscen-

ter for Ejendomsvurderinger (ICE), der har fået til opgave at udvikle et nyt, samlet ejendoms-
vurderingssystem2 – herunder et nyt it-system – så der kan udsendes nye vurderinger af ejer-
boliger i 2018 og af erhvervsejendomme og landbrug/skovbrug i 2019.stat
Denne PID omhandler udviklingen af det nye it-system, der skal understøtte udarbejdelsen af
ejendomsvurderingerne og den efterfølgende klagebehandling.
1
Forbedring af ejendomsvurderingen. Resultater og anbefalinger fra regeringens eksterne ekspertudvalg.
September 2014.
2
Med ’ejendomsvurderingssystem’ refereres til det samlede administrationsområde for de nye ejendoms-
vurderinger, som omfatter datagrundlag, vurderingsmodeller, processer og organisation samt it-system
mv. It-systemet udgør dermed kun en del af ’ejendomsvurderingssystemet’.

De nuværende it-systemer til ejendomsvurdering udgør et komplekst og forældet systemkom-
pleks baseret på diverse knopskydninger af it-systemer leveret af bl.a. KMD, IBM og CSC. De
ældste dele af systemerne er fra 1960-1970’erne. Et detaljeret systemdiagram for de nuvæ-
rende it-systemer på ejendomsvurderingsområdet ses i figur 2.1. Systemerne indeholder ikke
funktionalitet, der kan understøtte standardiserede, gennemsigtige og automatiserede vurde-
rings- og klageprocesser.
Figur 2.1. Systemdiagram for ejendomsvurderingsområdet
FTPSVUR-IBMSalgListeSend
UkendtVUREvsvurderingsoplysningerårListeSend
Salg - Ug entlig
SLUT
UkendtVUREvsvurderingsoplysningermdlListeSend
BBR VUR/ESR (Kommuner)

H322 (Kvartalsvis salg) / H352 (Parametre)Kompetance
UdlandFritidEjendo Center SKAT
mMultiHent
FTPSVUR-IBMkvtsalgListeSend Forskud
Internt_KMD
H352 Korrektioner mv.
SVU R IBM (Batch) H351 - GRUS, Analyse
FTPVUREjermatrikler
vurderingerListeSend
OIS H322 - Ugentlig salg (FTP) - H328 Årlig BBR - H356 Vurd.Stat.
UkendtVURForslag Send
XVU R328 - Fuld kopi af BBR (Årligt)
FTPSVUR-IBMForslagListeSend
FTPSVUR-IBMEjermatriklerListeSend
H351/H352 - Arbejdskopi 3*årligt
FTPVURGrundværdierListeSend FTPSVUR-CSC
Salg ListeSend
UkendtVURBBR-oplysninger FTPVURBbr-oplysning erListeSend
XVU R351 - H352 - Forslag mv. (14)
ListeModtag
L/GRUS Tabel. FTPSVUR-CSC
VUR (SKAT) GrundværdierListeSend
UkendtVURGrund
UkendtVURBBR-Forsvar værdiområderListeSend
oplysningerListeModtag
EjendomEjerSkift
eMultiHent Beregning af SVU R CSC
SKAT-BBR- Priser & faktorer EjendomplysningHent
Stamdata Analyse filer - til Tele billeder,Værdi for std. Ejend.
Danmarks
Opslag
Statestik
EjendomsHandelSamlingHent
EjendomSøg
UkendtSVUR-CSCSalgListeHent
FTPSKAT -GISOmrådeoplListeModtag UkendtSVUR-CSCVurd
ListeSend DataWarehus
Anvender
Korrektioner, priser
Ting lysning TAF E
Vurdering scenter
Salg - Daglig
TastSelvBorger - CSC
TastSelvBorgerApplication
Udskrivning af vurd. medd. (PDF)

GIS (SKAT)
FTPSVUR-CSCPriserListeSend
Ejendomsvurderingssystemet
Geo Data
Styrelsen
FTPSKAT -GISKortListeHent
Der er et tæt samspil mellem de tre hovedsystemer på området, jf. figur 2.2. De tre hovedsy-
stemer er udviklet af tre forskellige eksterne leverandører i form af CSC, KMD og IBM, der
også hver især vedligeholder systemerne. Det er derfor også de tre eksterne leverandører, der
har indsigten i systemernes opbygning og funktionalitet, mens SKATs viden herom er meget
begrænset. SKAT har derfor i dag en meget stor afhængighed af leverandørerne, der yderli-
gere forstærkes af, at det er tre uafhængige parter, der skal koordineres med ved ændringer.
Det er forholdsvis dyrt at foretage ændringer af systemerne.

Figur 2.2. Ovedrordnet rollefordeling
2.2 Formålet med projektets løsning og bidrag til strategiske mål

Projektets primære formål er at udvikle et nyt it-system, som kan understøtte standardiserede
og automatiserede vurderings- og klageprocesser og dermed bidrage til at sikre et kvalitetsløft
af ejendomsvurderingen. Udviklingen af et nyt it-system udgør således én af hovedleveran-
cerne i udviklingen af et nyt, samlet ejendomsvurderingssystem, der skal genskabe tilliden til
den offentlige ejendomsvurdering og dermed bidrage til at sikre et årligt skatteprovenu på ca.
40 mia. kr.
Der forventes i 2016 at blive fremsat et lovforslag om det nye, samlede ejendomsvurderings-
system, og projektet vil (sekundært) have til formål at implementere den nye lovgivning.
Et nyt it-system er en forudsætning for at udvikle et nyt ejendomsvurderingssystem, der er

enkelt, gennemskueligt og omkostningseffektivt, og projektet skal dermed udvikle et it-sy-
stem, der kan understøtte:
1. Den daglige drift med gennemførelse af ejendomsvurderinger samt den efterfølgende

håndtering af klager
2. De vurderings- og datamodeller, som de fremtidige ejendomsvurderinger baseres på
3. Ledelsesrapportering, sagsstyring, dokumentation og sporbarhed mv.
Forbedring af datakvaliteten og indsamling af data, fastlæggelse af de kommende vurderings-

modeller, etablering af den fremtidige driftsorganisation med tilhørende processer samt udar-
bejdelse af lovforslag indgår ikke i it-projektet.
Der er som anført væsentlige udfordringer ved det eksisterende it-vurderingssystem, der er
stærkt forældet og komplekst på grund af mange års løbende tilretninger. Hertil kommer, at
klageprocessen er utilstrækkeligt systemunderstøttet med unødvendigt mange manuelle ruti-
ner, der vanskeliggør en effektiv klagehåndtering og dermed håndtering af de forøgede klage-
mængder, der må forventes i forbindelse med idriftsættelsen af det nye system og genopta-
gelsen af borgernes klageadgang.

Strategien for tilvejebringelse af det nye it-system har været, at det som udgangspunkt skal
udvikles agilt via en K03-kontrakt med en ekstern leverandør, dog kombineret med en forud-
gående teknisk prototyping, der har skullet bidrage til en afklaring af, om egenudvikling er et
alternativ til anvendelse af en ekstern leverandør.
Den 1. marts 2015 iværksatte ICE derfor efter planen et intensivt forløb med teknisk prototy-
ping. Udviklingsenheden har i foråret 2015 gennemført et vellykket prototyping-forløb, og sty-
regruppen for ICE har derfor besluttet, at it-projektet mest hensigtsmæssigt kan gennemføres
som egenudvikling med udbud af afgrænsede funktionaliteter. Der henvises nærmere til afsnit
10.1 om udbudsstrategi.
2.3 Den fremtidige situation efter indførelse af løsningen

Det nye system skal medvirke til, at der genetableres tillid til den offentlige ejendomsvurde-
ring.
Systemet vil med en væsentlig grad af automatik i vurderingerne samtidigt sikre, at flest mu-
lige vurderinger kan foretages uden manuel sagsbehandling, herunder korrektioner til de mo-
delberegnede vurderinger.
Nedenstående figur 2.3 viser et procesoverblik for den fremtidige ejendomsvurdering og kla-
gebehandling, som det nye it-system skal understøtte.
Figur 2.3. Overblik over hoved- og delprocesser i den fremtidige ejendomsvurdering
De primære slutbrugere er sagsbehandlerne i SKAT og Skatteankestyrelsen (herefter SANST).

Sagsbehandlerne får et nyt it-system, som sikrer regelbaserede og systemunderstøttede pro-
cesser med støtteværktøjer i form af fx GIS-baserede teknologier o.l. til at kunne basere deres
vurderingsfaglige skøn på. Det sikrer gennemsigtighed og ensartethed i vurderingerne. Det
gør det endvidere muligt enkelt og effektivt at foretage vurderinger af det betydelige antal
ejendomme, der som følge af fx for få salg i nærområdet, atypiske karakteristika mv. forven-
tes ikke at kunne vurderes rent maskinelt.
I forbindelse med udformningen af behov til det kommende it-system er der foretaget en
række forretningsmæssige og juridiske afklaringer med det formål at forbedre sagsbehandlin-
gen i de manuelle sager så borgerne i stigende grad oplever at få grundig information, når
SKAT formidler vurderingsmeddelelser og i øvrigt kommunikerer med borgere om ejendoms-
vurdering. Det kommende it-system skal understøtte sagsbehandlingen, så det sikres at sags-
behandling såvel som kommunikation overholder gældende regler for begrundede afgørelser
og kommunikerer i et klart og enkelt sprog.

Forenkling og standardisering af processerne med regelbaseret systemunderstøttelse af den
manuelle sagsbehandling skal sikre ensartet sagsbehandling og lighed for loven uanset, hvor i
landet man bor eller hvilken type ejendom man ejer. Systemet forventes at resultere i en
mere ressourceeffektiv sagsbehandling dels på grund af de optimerede processer og dels på
grund af udvidet anvendelse af støtteværktøjer til at understøtte de manuelle skøn.
I projektets løbetid er der planlagt store ændringer i grunddataregistrene på ejendomsområ-

det hos andre myndigheder, herunder etablering af en fællesoffentlig datafordeler. Det nye
vurderingssystem skal – når systerme idriftsættes – integreres med dette nye systemland-
skab.
2.4 Situationen hvis projektet ikke gennemføres (business as usual)

Udviklingen af it-systemet udgør én af de centrale leverancer i et nyt, samlet ejendomsvurde-
ringssystem, som skal genskabe tilliden til ejendomsvurderingerne og sikre, at der kan opkræ-
ves et skatteprovenu på ca. 40 mia. kr.
Såfremt der ikke udvikles et nyt it-system, vil det ikke være muligt at udvikle og implemen-
tere standardiserede og automatiserede vurderings- og klageprocesser, som kan sikre en en-
kel og gennemsigtighed sagsbehandling. Dette kan have endog meget betydelige økonomiske
konsekvenser.
Deloitte har tidligere estimeret det fremtidige ressourceforbrug for vurdering af ejerboliger til
650-1.400 årsværk og den efterfølgende klagebehandling til 400-1.300 årsværk svarende til
en årlig samlet udgift på 0,6-1,7 mia. kr.3 Beregningen tager udgangspunkt i, at SKAT skal fo-
retage 120.000-350.000 manuelle sagsbehandlinger, og at mellem 6-20 pct. af borgerne ef-
terfølgende klager over deres vurdering.
Det er lagt til grund for beregningerne, at der gennemføres en række tiltag, der reducerer res-
sourceforbruget. Gennemføres der ikke sådanne reducerende tiltag, vurderer Deloitte, at det i
værste fald kan betyde, at der skal anvendes op mod 7.500 årsværk til at vurdere ejendomme
og behandle klager.
Et væsentligt tiltag til at reducere ressourceforbruget er, at der etableres en effektiv system-
understøttelse af vurderings- og klageprocesserne, og at kvaliteten og gennemsigtigheden i
sagsbehandlingen herved samtidig forøges, så antallet af klager minimeres.
Endelig vil omlægningen af systemlandskabet på ejendomsområdet hos andre myndigheder

indebære, at de nuværende vurderingssystemer ikke umiddelbart kan hente de nødvendige
data fra 2017 og derfor ikke vil kunne levere ejendomsvurderinger.
Konsekvensen heraf er, at dele af provenuet fra ejendomsskatterne på ca. 40 mia. kr. risikerer
at gå tabt eller komme under pres.
2.5 Alternative løsningsscenarier

2.5.1 Videreudvikling af eksisterende systemer
Det er overvejet, om en videreudvikling af den eksisterende systemunderstøttelse vil kunne
skabe det nødvendige kvalitetsløft og fremtidssikring. Videreudvikling vurderes ikke som et re-
elt alternativ til udvikling af et nyt it-system. Det nuværende system er således stærkt foræl-
det og komplekst, og det vurderes derfor ikke muligt at videreudvikle det til at understøtte til-
strækkeligt standardiserede og automatiserede vurderings- og klageprocesser samt skabe den
fornødne gennemskuelighed og transparens i vurderingsgrundlag såvel som sagsbehandling
for borgerne. Desuden må det – hvis det reelt var muligt – i lyset af erfaringerne med de eksi-
sterende leverandører på området forventes at blive meget dyrt, ligesom det vil indebære en
3Afrapportering. Fremtidigt administrationsgrundlag for værdiansættelse af ejendomme. Sammenfatning.

Deloitte, september 2014.

meget kompliceret udviklingsproces, der involverer tre selvstændige, eksterne leverandører.
Der henvises også til det ovenfor under pkt. 2.1 anførte om de nuværende systemer.
2.5.2 Tilpasning af standardrammesystemer

Det er overvejet, om den fremtidige it-understøttelse af de nye ejendomsvurderinger kan un-
derstøttes via anvendelsen af standardrammesystemer.
Deloitte Consulting har gennemført en analyse af en lang række standardrammesystemer for

ICE, som peger på, at der til den centrale funktionsunderstøttelse bør foretages et teknologi-
valg, som understøtter en stor grad af fleksibilitet.4 Deloitte konkluderer således, at ”på bag-
grund af analysens resultater og under hensyntagen til ICE programmets udviklingsstrategi
vurderes det, at der bør foretages et teknologivalg, som understøtter stor fleksibilitet og tager
udgangspunkt i ICE programmets udviklingskompetence. Intet standard rammesystem vil
passe ideelt til forretningsbehovene i ICE programmet og agilitet skal vægtes højt taget i be-
tragtning, at ICE programmet endnu er tidligt i kravafklaringsforløbet.”
Skatteministeriet har på den baggrund vurderet, at standardrammesystemer ikke er en reali-

stisk mulighed for udvikling af et nyt ejendomsvurderingssystem. Det skyldes, at den tilpas-
ning, der skal foretages af standardrammesystemerne for, at de kan opfylde de forretnings-
mæssige behov i ejendomsvurderingen, vil være så stor, at nyudvikling er mere hensigtsmæs-
sig.
3 Scope og afgrænsninger
Projektets scope er afgrænset til udvikling af et nyt it-system, der skal understøtte udarbejdel-
sen af de nye ejendomsvurderinger gennem systemunderstøttelse af standardiserede og for-
enklede processer med vægt på størst mulig automatisering. It-systemet skal således kunne
håndtere de maskinelt beregnede ejendomsværdier og understøtte automatisering af den ma-
nuelle ejendomsvurdering og klagebehandling.
Systemet skal således understøtte vurderingsprocesserne og videreformidle vurderingerne til

skatteberegningssystemerne, herunder de kommunale beregningssystemer, understøtte kla-
gebehandlingen i SANST med sikring af inddragelse af oprindeligt vurderingsgrundlag og vi-
densdeling (inden for lovens rammer) mellem SKAT og SANST og endelig understøtte dialogen
med borgere og virksomheder.
Forbedring af datakvaliteten og indsamling af data, fastlæggelse af de kommende vurderings-

modeller, etablering af den fremtidige driftsorganisation, standardisering og forenkling af pro-
cesserne samt udarbejdelse af lovforslag indgår ikke i projektet, jf. nedenfor.
Udenfor scope (afgrænsning) Begrundelse for afgræsning

Lovgivning Lovgivningsprocessen er normalt ikke en del af et it-
Projektet omfatter ikke udarbejdelsen af den nye lovgiv- udviklingsprojekt.
ning på området.
Lovgivningen udgør dog den vigtigste eksterne afhængig-

hed for projektet, fordi den kan have stor betydning for
projektets tidsplan, omfang, risici samt økonomi mv.
Data og vurderingsmodeller Datamodellen og de statistiske og økonomiske esti-
Etablering og kvalitetssikring af ejendomsvurderingernes meringsmodeller udvikles selvstændigt og skal lø-
datagrundlag, udarbejdelsen af de statistiske og økono- bende udvikles. De udgør derfor ikke en del af it-sy-
miske estimeringsmodeller samt konsekvensberegninger stemet, men it-systemet skal modtage og udstille be-
mv. regninger og data fra estimeringsmodellerne for
sagsbehandlerne. It-systemet skal dog kunne hånd-
tere en dialog med borgere og virksomheder, herun-
der om berigtigelse af data.
4
Vurderingssystemet. Scenarier til brug for afklaring af teknologivalg. Deloitte. Februar 2015.

Driftsorganisation og processer Fastlæggelsen af den fremtidige driftsorganisation
Design af den fremtidige driftsorganisation og forret- og de tilhørende processer for udarbejdelsen af vur-
ningsprocesser for udarbejdelsen af ejendomsvurderin- deringer er ikke en naturlig del af it-projektet og fast-
ger og den efterfølgende klagebehandling er ikke omfat- lægges i særskilt projekt.
tet af projektet.
Kampagne for ny ejendomsvurdering Landsdækkende kampagneaktiviteter planlægges og
Kommunikationsstrategi og -plan for den kommunika- gennemføres i samarbejdet med kommunikationsen-
tion, herunder kampagneaktiviteter, der lancere og bi- heder i Skatteministeriet og SKAT, der ikke indgår i it-
drage til ejernes tillid til det nye ejendomsvurderingssy- projektet.
stem, er ikke omfattet af projektet.
Staten og kommunerne - beregning og opkrævning af Ansvaret for beregning og opkrævning af statslige
ejendomsskatter. ejendomsskatter ligger i SKATs afdeling for afreg-
Projektet leverer et system, der understøtter levering af ning, hvor også systemunderstøttelsen (SLUT-kom-
vurderinger til skattesystemerne, som beregner ejen- plekset og EVS) er forankret. Projektet ændrer ikke
domsværdiskat og den kommunale grundskyld og dæk- ved denne fordeling.
ningsafgift. Systemet understøtter derimod ikke selve be-
regningen, der foretages i andre it-systemer, og der kan Tilsvarende ligger ansvaret for beregning og opkræv-
derfor være behov for systemtilretninger uden for pro- ning af kommunale ejendomsskatter hos kommu-
jektet, herunder i kommunale systemer. nerne, hvor også systemunderstøttelsen (ESR) er for-
ankret. Projektet ændrer ikke ved denne fordeling, li-
gesom ansvaret for tilretning af de kommunale sy-
stemer, fortsat påhviler kommunerne.
4 Mål og succeskriterier
Det primære mål for ICE programmet og dermed også for it-projektet er at ”Genskabe tillid til
de offentlige ejendomsvurderinger” ved, at ”SKAT og –klagesystemet leverer retvisende og
ensartede vurderinger, der sikrer beskatningsgrundlaget og samtidigt opleves som gennem-
skuelige og velbegrundede af ejendomsejerne”.
Målene for it-projektet er anført nedenfor med tilhørende beskrivelse og succeskriterier. Må-
lene støtter alle op om ICE’s målsætning med udviklingen af et nyt it-system, som er, at der
skal udvikles en ”automatiseret og standardiseret sagsbehandling med effektiv systemunder-
støttelse for alle ejendoms-, vurderings- og sagstyper.” Målhierarkiet for det samlede program
(ICE) fremgår af vedlagte bilag x.
Det skal understreges at arbejdet med etablering af nyt ejendomsvurderingssystem – og her-

under en ny systemunderstøttelse – er en stor og kompleks opgave. Udgangspunktet er, at
tilliden til det eksisterende ejendomsvurderingssystem er væk, og at det bl.a. som følge heraf
må forventes, at der vil komme et større antal klager, når det nye ejendomsvurderingssystem
sættes i drift.
Bemærk, at der vil blive arbejdet videre med præcisering af succeskriterier i forbindelse med
arbejdet med implementeringsstrategi og –plan.
Projektets mål Beskrivelse Succeskriterier

Transparent vurderings- Al data anvendt ved vurdering af den Færre genoptagelser og klager (over tid) på
grundlag enkelte ejendom er automatisk og digi- grund af fejl i vurderingsgrundlag. Der opstil-
talt udstillet til sagsbehandlere og ejen- les absolutte og relative mål for forbedringer
domsejere i henholdsvis ejendomsvur- over tid i forhold til det initiale niveau ved de
deringssystemet og på SKAT.dk første vurdering i det nye system i henholds-
vis 2017 og 2018.
Systemet sikrer automatisk og løbende
simultan opdatering af data til model- Tidskrav fra opdatering af eksterne kildedata
beregning, manuelle vurderinger. til anvendelse i systemerne.
For at understøtte bedst mulig data- Brugertilfredshed (ejendomsejere) stigende

kvalitet forventes it-projektet at etab- overtid fra et initialt niveau, der vil være på-
virket af udfordringer med datakvaliteten.

lere en deklarationsproces på rigtighe- Brugertilfredshed (sagsbehandlere) stigende
den af data overfor ejendomsejer én overtid fra et initialt niveau, der vil være på-
gang pr. ejendomsvurdering. virket af udfordringer med datakvaliteten.
Da datakvalitet er en stor udfordringer,

arbejdes der også med datakvalitet
uden for it-projektet.
Konsistente og gennem- Systemet skal være enkelt at anvende Færre genoptagelser og klager over tid som
skuelige vurderinger ba- og sikre transparent og regelbaseret følge af vurderingsfejl og manglende forstå-
seret på transparent, re- procesunderstøttelse for alle ejen- else og accept af vurderingerne.
gelbaseret og systemun- doms-, vurderings- og sagstyper, uan-
derstøttet metodevalg set om vurderingen er modelbaseret Der skal opstilles absolutte og relative mål
og maskinel eller manuel. for forbedringer over tid i forhold til initialt
niveau, hvor vi forventer flere end i dag.
Reduceret tidsforbrug ved manuel sagbe-

handling pr. type (absolut og relativt krav)
forbedring målt efter opstart, hvor der initialt
forventes større tidsforbrug i en indkørings-
fase.
Færre fejl Færre fejl som følge af transparent vur- Færre genoptagelser og klager1, der kan hen-
deringsgrundlag, brugervenligt system føres til fejl.
med transparent, regelbaseret og sy-
stemunderstøttet metodevalg. Der skal opstilles absolutte og relative mål
for forbedringer over tid i forhold til initialt
niveau, hvor vi forventer flere end i dag på
grund af forventet generelt højere antal kla-
ger.
Fokus på vurdering Systemet og de nye processer skal sikre Færre genoptagelsessager og klager som
fokus på vurdering fremfor etablering følge af vurderingsfejl.
af vurderingsgrundlag og administra-
tion.
Veldokumenteret sags- Systemet skal uanset vurderingsme- Færre klager (absolut og relativt over tid i
behandling tode sikre konsistente, velbegrundede forhold til initialt niveau)).
og dokumenterede vurderinger.
Kundetilfredshedsmålinger (ejendomsejere)
Det skal bemærkes, at det kan blive stigning over tid i forhold til det initiale ni-
svært at sikre dokumentationen af kla- veau ved udsendelse af de første vurderin-
gebehandling, der sker uden for SANST ger.
i nævn og ved domstole.
Lighed for loven Gennem konsistente og gennemsigtige Færre genoptagelser og klager (over tid jf.
vurderinger baseret på et transparent ovenfor).
vurderingsgrundlag og fastlagte meto-
devalg og nødvendig genoptagelse af Reduceret tidsforbrug ved manuel sagbe-
sager af egen drift efter manuel sags- handling pr. type (absolut og relativt krav).
behandling og afgørelser hos klage-
myndigheden med betydning for andre
ejendomme.
Effektiv håndtering af Effektiv proces- og systemunderstøt- Brugertilfredshed (ejendomsejere) på min x%

borgerdialog telse skal sikre nem og effektiv adgang ved kontakt om berigtigelse eller tilføjelse af
til kommunikation mellem ejendoms- faktuelle oplysninger.
ejere, SKAT og SANST både ved databe-
rigtigelse og –tilføjelse, sagsbehandling Brugertilfredshed på X% efter indgivelse af
og klagehåndtering. klager.
Tidsforbrug på håndtering af borgerhenven-

delse ekskl. klager på (gennemsnitlig X min
(effektiv), svartid (kalendertid på max Y).

Tidsforbrug på håndtering af klager på (gen-
nemsnitlig X min (effektiv), svartid (kalender-
tid på max Y).
Brugervenligt og effek- Systemet er nemt og effektivt for både Høj brugertilfredshed (x%) hos både medar-
tivt ejendomsvurderings- medarbejdere og ejendomsejere og bejdere og ejendomsejere for den sidste ka-
set-up for både medar- sikrer en hurtig og nem indlæringspro- tegori forbedring over tid.
bejdere og ejendoms- ces for nye medarbejdere.
ejere. Hurtig indkøring af nye medarbejdere – mål
for, hvor hurtigt 100% standard-produktivitet
skal opnås fra ansættelsestidspunkt.
Lavt uddannelsesbehov (x-timer pr. medar-

bejder giver y% på tilfredsmåling på tilstræk-
kelig uddannelse).
Korte sagsbehandlingstider (effektivt og ka-

lendertid) (absolutte og relative mål skal fast-
sættes)
Vidensdeling på tværs af Det skal sikres, at SKAT og SANST har Færre fejl ved klagebehandling i SANST
SKAT og SANST. adgang til samme vurderingsgrundlag,
værktøjer, sagsbehandlingshistorik, Kortere sagsbehandlingstid i SANST
vurderingsbegrundelser og afgørelser,
hvor juridisk muligt og under hensyn til Færre fejl ved sagsbehandling i SKAT (som
nødvendig myndighedsadskillelse. følge af manglende inddragelse af afgørelser
fra klagemyndigheden).
Efffektiv ressource- og Ledelsen vil kunne benytte det nye sy- Mål for ressourceforbrug (absolut og relativt
sagsstyring. stem som et ressource- og opgaveplan- samt på sags- og ejendomstyper)
lægningsværktøj samt sikre sagsstyring
og opfølgning på medarbejder- og sags- Positiv udvikling af medarbejderperformance
typeniveau. over årene (færre fejl og hurtigere sagsbe-
handling)
Nemt at vedligeholde sy- Der skal løbende foretages usability Hurtigere fejlrettelse og tilpasning til æn-
stemet, og at tilpasse det tests af systemet, og det skal sikres, at drede behov
til nye og ændrede be- systemet er nemt at vedligeholde, og
hov at det enkelt og hurtigt kan ændres og (Mål skal identificeres og indarbejdes i den
opdateres til nye og ændrede krav. kommende SLA mellem SKAT Ejendom og
SKAT IT hhv SANST og SKAT IT)
5 Økonomiske hovedtal og finansiering

5.1 Fravalg af den statslige businesscase model og faseopdeling af it-
projektet
Udviklingsteamet i ICE har gennemført et vellykket prototyping-forløb, og på den baggrund har
styregruppen for ICE tiltrådt, at det nye it-system til understøttelse af standardiserede og auto-
matiserede vurderings- og klageprocesser gennemføres som agil egenudvikling kombineret med
udbud af afgrænsede funktionaliteter. Der henvises til afsnit 10.1 om udbudsstrategi, hvor bag-
grunden for valget af leverancestrategi nærmere er beskrevet.
Ved skønnet over de forventede udgifter til udviklingen af det nye it-system er det lagt til grund,
at videreudvikling af de eksisterende systemer eller tilpasning af rammesystemer ikke er et reelt
alternativ til udvikling af et nyt it-system. Det er nærmere beskrevet ovenfor i afsnit 2.4 og 2.5.
Det betyder også, at det ikke er fundet relevant at udarbejdet et 0-scenarie.
Da it-projektet således primært forventes at blive gennemført som agil egenudvikling, hvor der
vil være overlap mellem anskaffelsesfasen og gennemførelsesfasen, er det endvidere ikke fundet
relevant at anvende den normale faseopdeling i projektinitieringsdokumentet.

Endelig er det fravalgt at bruge den statslige businesscase model. Dette er begrundet i, at der
er tale om et projekt, hvis hovedformål er et kvalitetsløft, der skal medvirke til at genskabe
tilliden til ejendomsvurderingerne og sikre et provenu på ca. 40 mia. kr. I lyset heraf er det
således ikke en mulighed ikke at udvikle et nyt it-system.
Fravalget er også begrundet i, at det kommende it-system blandt andet er et nyt sagsbehand-
lingssystem, der skal erstatte et ældre system, og hvor en videreudvikling af det ældre it-system
ikke vurderes som et reelt alternativ til udvikling af et nyt it-system
Endelig er det på nuværende tidspunkt ikke muligt mere præcist at skønne over de kommende
udgifter til sagsbehandling af manuelle vurderinger og klagesager. Disse vurderinger vil tidligst
kunne foretages frem mod udarbejdelse af det endelige lovforslag ultimo 2015.
5.2 Budget
Budgettet er udarbejdet på baggrund af konkrete skøn over de enkelte poster. Der knytter sig
fortsat en usikkerhed hertil som følge af, at de samlede krav til systemet endnu ikke er speci-
ficeret fuldt ud.
Det samlede udgiftsbaserede budget for egenudvikling et vist i nedenstående tabel.
De forventede udgifter til egenudvikling af det nye it-system skal ses i relation til, at systemet
skal medvirke til at sikre det offentliges indtægter fra grund- og ejendomsbeskatning på op
mod 40 mia. kr. årligt.
Udgiftsbaseret budget
Mio. kr., 2015-priser 2015 2016 2017 2018 I alt
Årsværk 3,3 13,8 13,8 6,9 37,7
Hardware og licenser 1,2 3,4 3,4 3,4 11,5
Konsulenter 0,6 6,2 6,2 0,7 13,7
Risikopulje 0,0 0,0 0,0 6,3 6,3
I alt 5,2 23,4 23,4 17,3 69,3
Risikopuljen udgør 10 pct. af de samlede budgetterede udviklingsudgifter. Puljen er fastsat

med udgangspunkt i, at det samlede udgiftsbudget er fastsat efter konkrete vurderinger af de
enkelte poster sammenholdt med Deloittes vurdering af udgifter til risikopulje ved et K03-ud-
bud.
Deloitte Consulting har tidligere skønnet, at de forventede samlede udgifter ved et K03-udbud
vil udgøre i alt 350 mio. kr. inkl. renter og bemanding af ICE til understøttelse af it-udviklings-
arbejdet i gennemførelsesfasen. Heraf udgør risikopuljen udgør 60 mio. kr. svarende til 20 pct.
af det ikke-risikojusterede udgiftsskøn.
Det omkostningsbaserede budget er i vist i nedenstående tabel.
Omkostningsbaseret budget
Mio. kr., 2015-pri-
2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 I alt
ser
Aktiverbare pro-
jektudgifter, af- 0,0 0,0 3,2 6,5 6,4 6,4 6,4 6,4 6,4 6,4 3,2 51,4
skrivninger
Ikke-aktiverbare
1,2 3,4 3,4 9,7 0,0 0,0 0,0 0,0 0,0 0,0 0,0 17,8
projektudgifter
I alt eks. Renter 1,2 3,4 6,6 12,9 6,4 6,4 6,4 6,4 6,4 6,4 3,2 69,3
Renter 0,2 1,2 1,2 2,3 2,0 1,7 1,4 1,1 0,8 0,4 0,2 12,6
I alt 1,4 4,6 7,9 15,3 8,5 8,2 7,8 7,5 7,2 6,8 3,3 81,8
Note: Risikopuljen på 6,3 mio. kr., jf. tabel 5.1, indgår i ’Ikke-aktiverbare projektudgifter’ på i alt 7,9 mio. kr. for 2018.
Skal risikopuljen udmøntes, vil det formentlig vedrøre aktiviteter, der skal aktiveres.
Finansieringen af de samlede udgifter på 81,8 mio. kr. skal afklares nærmere.

Det forventes, at de fremtidige årlige udgifter til drift af it-systemet kan holdes inden for en
ramme på op mod 7 mio. kr., svarene til maksimalt 10 pct. af udviklingsomkostningerne op-
gjort udgiftsbaseret, men da driftsopgaven evt. skal sendes i udbud5, knytter der sig en usik-
kerhed til de fremtidige driftsudgifter. Finansieringen af de årlige driftsudgifter skal afklares
nærmere.
6 Gevinster
Det primære formål med it-projektet er et kvalitetsløft med henblik på at ”genskabe tilliden til
de offentlige ejendomsvurderinger”, jf. afsnit 2, så der fortsat er et grundlag for at kunne op-
kræve ejendomsskatter, som i dag samlet set udgør ca. 40 mia. kr. årligt.
6.1 Strategi for gevinstrealisering

Der knytter sig en lang række klare gevinster til det nye it-system, jf. figur 6.1 nedenfor, som
skal understøtte, at tilliden til ejendomsvurderingerne genskabes. ICE har i forbindelse med
kravstillelsen til det nye it-system og udviklingen af de tekniske funktionaliteter og systemets
arkitektur et dedikeret fokus på realiseringen af disse gevinster. Desuden vil ICE særskilt via
bl.a. uddannelse og oplæring samt udarbejdelsen af retningslinjer og vejledninger fokusere på
gevinstrealiseringen i forbindelse med idriftsættelsen af det nye it-system i SKAT og SANST.
Udfordringen for dette projekt er, at klagesystemet vil blive udsat for et meget stort antal kla-
gesager med tilhørende pres på det nye ejendomsvurderingssystem, hvis det ikke lykkes at
genskabe tilliden til ejendomsvurderingerne. I yderste konsekvens kan den manglende tillid få
provenumæssige konsekvenser.
Gevinstrealiseringen er forankret dels som en integreret del af arbejdet i ICE, dels i modtager-
organisationen hos henholdsvis SKAT (SKAT Ejendom) og SANST (Vurderingsafdelingen).
Figur 6.1. Gevinstdiagram for udvikling og implementering af nyt it-system
5 Det er uafklaret, i hvilket omfang driftsopgaven sendes i udbud.

6.2 Effektiviseringsgevinster
Som ovenfor anført er projektets primære formål ikke effektivisering, men kvalitetsløft. Der er
dog et betydeligt, men endnu ikke kvantificeret potentiale for at øge den fremtidige produkti-
vitet knyttet til vurdering og klagehåndtering via en effektiv systemunderstøttelse af arbejds-
gangene. Produktivitetsstigningen vil – som følge af det forventede omfang af manuel sagsbe-
handling og en betydelig klagetilgang – i første omgang kunne modvirke ophobningen af sags-
pukler samt medvirke til at fastholde acceptable sagsbehandlingstider. Hertil kommer, at de
løbende udgifter til drift og vedligeholdelse må forventes at blive mindre ved et nyt og mo-
derne it-system.
Ge- Risikojusteret Beskrivelse

vinst Gevinstejer værdi i mio.
ID kr.
1 Sanne Kjær (SKAT Ejendom) og N/A Øget produktivitet i vurderings- og klage-
Anette Hummelshøj (Skattean- processen og effektiv ressource- og sags-
kestyrelsen) styring som følge af, at processerne auto-
matiseres og standardiseres via en mo-
derne systemunderstøttelse, herunder via
et digitalt understøttet informationsgrund-
lag og støtteværktøjer (eksempelvis GIS-
værktøjer).
Realiseringen af denne gevinst forventes

ikke umiddelbart at give anledning til be-
sparelser, men derimod til at imødegå
yderligere opbygning af sagspukler.
2 Jan Topp. (SKAT IT) N/A Mindre ressourceforbrug til drift og vedli-
geholdelse af et moderne og agilt it-sy-
stem.
6.3 Ikke-økonomiske gevinster

De ikke-økonomiske gevinster fremgår af gevinstdiagrammet ovenfor og er listet nedenfor.
Gevinst Gevinst Gevinstejer

Gevinstnavn Enhed
ID
3 Forbedret accept af ejendomsvur- Niveau-interval Forbedret accept Sanne Kjær, SKAT
deringer fra ejendomsejere og (ejendomsejere) Ejendom
overtid forbedret kundetilfreds- og højere kunde-
hed tilfredshed over
tid1 (ejendoms-
ejere)
4 Forbedret accept af klageafgørel- Niveau-interval Forbedret accept Anette Hummelshøj,
ser og overtid forbedret kundetil- og højere kunde- SANST
fredshed tilfredshed over
tid1 (ejendoms-
ejere)
5 Overholdelse af svartider Dage Overholdelse af Sanne Kjær, SKAT
svarfrister Ejendom
Anette Hummelshøj,
SANST
6 Høj medarbejdertilfredshed i både Niveau-interval Tilfredse og der- Sanne Kjær, SKAT
SKAT og SANST med forventelig Anette Hummelshøj,
mere effektive og SANST
mindre syge
medarbejdere
7 Færre genoptagelsessager Antal Færre genopta- Sanne Kjær, SKAT
gelsessager over
tid som følge af
færre fejl

Gevinst Gevinst Gevinstejer
Gevinstnavn Enhed
ID
8 Færre klager Antal Færre klager Sanne Kjær, SKAT
(over tid) som Anette Hummelshøj,
følge af konsi- SANST
stente, gennem-
skuelige og vel-
dokumenterede
ejendomsvurde-
ringer
9 Kortere sagsbehandlingstider Minutter (ef- Kortere sagsbe- Anette Hummelshøj,
fektivt), dage handlingstid som SANST
(kalendertids- følge af digitalt Sanne Kjær, SKAT
mæssigt) understøttet vur-
deringsgrundlag,
regelbaseret og
systemunderstøt-
tet ejendomsvur-
dering med
bedre støtte-
værktøjer til vur-
deringen
7 Teknisk løsning
7.1 Markedsundersøgelse
Der henvises til afsnit 2.5 om alternative løsninger.
7.2 Teknisk løsning

7.2.1 Applikations-teknologier
ICE har valgt en basisteknologi baseret på Oracle JVM suppleret med relevante (open source)
pakker og biblioteker. Denne danner grundlaget for udvikling af kernefunktionaliteten i syste-
met. Kernefunktionaliteten er pt. suppleret med et specialiseret produkt til geografisk visuali-
sering af værdiansættelserne (GIS). De valgte teknologier har været afprøvet med succes i
projektets prototypeforløb i foråret 2015.
Ud over kernefunktionalitet og GIS forventer ICE at genanvende en række funktionelle kompo-

nenter, som allerede indgår i SKATs eksisterende landskab fx Den Centrale Sikkerhedsløsning
(DCS), single sign on for medarbejdere (Active Directory), udsendelse af vurderingsmeddelel-
ser (Aftale & Distribution) og præsentationslag (Skattemappen). Disse er kortlagt indledende
nedenfor under 7.2.2 Integrationer.
Fælles for disse komponenter er at genanvendelse beror på en konkret vurdering af, hvorvidt
en genanvendelse simplificerer udviklingen af it-systemet. Disse analyser er endnu ikke fær-
diggjorte, men indgår i afklaringsarbejdet i udviklingsforløbet i ICE.
7.2.2 Applikations-arkitektur
På baggrund af den gennemførte prototype og supplerende analyser har ICE udarbejdet en
foreløbig arkitektur for it-systemet. Arkitekturen afspejler de indledende analyser af, hvilke for-
retningsprocesser systemet skal understøtte, hvilke brugergrupper systemet skal anvendes af
samt databehov og integrationer til modtagesystemer.
Afklaring af integrationer til SKATs systemer samt af datakilder/-modtagere videreudvikles lø-

bende og parallelt med, at de funktionelle krav detaljeres. Den endelige arkitektur for it-syste-
met vil således først være på plads, når funktionaliteten er fuldt afdækket i det agile udvik-
lingsforløb.

Figur 7.1. Systemarkitektur version 1.0
Note: Inst1-6 og GIS1-2 er server instanser enten fysiske eller virtuelle.
Den tekniske udvikling af applikationen er baseret på en microservice arkitektur. Disse mi-

croservices benyttes af en responsive one-page applikation, som afvikles i en moderne Java-
script Virtual Machine (JVM). Som udgangspunkt vil microservices generelt blive udviklet mod
Oracle JVM, men nogle services, som fx beslutningsstøtteberegninger til sagsbehandlere, vil
muligvis med fordel kunne udvikles som R scripts og udstilles som microservices med API efter
samme model. Denne tilgang betyder, at applikationens klienter er afskærmet fra det under-
liggende teknologivalg, der følgelig kan vælges efter en “best for the job” ideologi – i modsæt-
ning til en monolitisk arkitektur, hvor alt er lavet i samme kodebase og ikke kan ændres efter-
følgende.
Resultatet af denne udviklingsstrategi vil blive et større antal microservices. Det endelige antal
kendes ikke på nuværende tidspunkt.
7.2.3 Service Discovery

Styringen af det store antal microservices er automatiseret i den skitserede arkitektur. Alle
services er registreret i Consul, og Consulservere og -agenter kører på alle relevante maski-
ner. Serviceklienter spørger således efter en given service og får et svar tilbage med, hvor
denne findes. Dette svar caches på klienten og i tilfælde af, at en service ikke svarer, laves et
nyt lookup, og det nye svar caches. Consul vil samtidig registrere en advarsel om, at en ser-
vice ikke svarer, og man kan så etablere en automatisk genstart af servicen, der herefter mel-
der sig ind som aktiv igen.
7.2.4 Skalerbarhed
Kommunikationen med services foregår via REST (HATEOAS), og services indeholder således
intet state og kan skalere horisontalt. Set i forhold til “the scale cube” 6, fokuseres der på X
(kloning) og Y (funktions opdeling) akse skalering, da det ikke umiddelbart vurderes, at data-
mængderne bliver så store, at der er behov for Z akse skalering (data partitionering).
6 http://microservices.io/articles/scalecube.html

Figur 7.2. Y-akse skalering
Alle services bygges til at kunne afvikles på redundant hardware, så hardware fejl ikke påvir-
ker applikationens tilgængelighed. Det formodes på nuværende tidspunkt, at der køres i et en-
kelt hostingcenter, hvilket potentielt indebærer, at driften vil være sårbar over for fejl, der på-
virker et helt center, som fx brand eller netværks problemer. Arkitekturen understøtter dog
fuldt ud redundante driftscentre, såfremt der er behov for dette.
ICE arbejder pt. på at afklare, om udviklingsmiljøet og det efterfølgende driftsmiljø kan driftes
i en cloud løsning – ideelt set hos en best-of-breed international leverandør. Det er dog ikke
afklaret, hvorvidt en løsning hos fx Amazon kan anvendes. Spørgsmålet afhænger bl.a. af,
hvorvidt it-systemet er omfattet af krigsreglen. Spørgsmålet skal afklares nærmere, og ICE er
i dialog med Datatilsynet herom.
7.2.5 Logning og overvågning

Logning foregår i Splunk Enterprise, der via Splunk forwarders på alle servere, aggregerer log-
filer fra alle applikationer og systemer. Alle requests fra klienten får en header med et unikt
callid, der propageres videre til alle efterfølgende kald, og logges med dette samt den indlog-
gede brugers id. Selve kaldet logges også, så man altid vil kunne trace en bestemt brugers
kald og efterfølgende afledte kald, og hvilken information kaldet indeholdte, fx et specifikt
ejendomsid. Splunk har mulighed for at lave dashboards og alarmer, og alarmer kan fx opsæt-
tes, hvis der søges på ejendomsid’er, der er på en VIP-liste. Ligeledes vil Splunk blive benyttet
til at alarmere, hvis en server er ved at løbe tør for ressourcer, eller hvis svartider degenererer
til et forudbestemt niveau. Mulighederne for at lave dashboards og rapporter er næsten uen-
delige, når logfiler korreleres på tværs af fysiske instanser og funktionalitet.
7.2.6 Sikkerhed
Udover logning hardnes alle servere, så fx kun 3 login forsøg er tilladt, og kun nødvendige ser-
vices kører. Derudover vil der blive installeret IDS (Intrusion Detection System) på alle ser-
vere, og al installation vil foregå automatisk via Ansible. Dette betyder, at hvis der er mistanke
om, at en server er kompromitteret (Rootkit eller lignende), kan den reinstalleres hurtigt og
sikkert. Servere vil være Linux eller FreeBSD, der kører i run level 3, evt. med en jumphost
kørende OpenBSD som adgang til administration af servere. Administrationsadgang til servere

vil ske via VPN (IPSEC), og forbindelse til SKATs interne systemer via en dedikeret forbindelse
fra hostingcenter til SKAT’s router. Hvis det er AWS, der bruges som hosting, vil det fx være
AWS Direct Connect og VPC (Virtual Private Cloud). Firewall åbninger laves, så kun de nødven-
dige adgange er åbne for relevante brugere, typisk port 443 (HTTPS).
7.2.7 Versionering af services

Alle services vil være versionerede, så man i kortere perioder kan køre med mere end én ver-
sion. Dette vil minimere risikoen for problemer i forbindelse med opdatering af en service, fx
vil en serviceopdatering med ’breaking changes’ ikke nødvendigvis kræve en samtidig opdate-
ring af klienten. Ved servicekald sættes den ønskede version i Accept headeren, så klienten
bestemmer, hvilken serviceversion den ønsker at bruge.
Indtil der opstår behov for at anvende API kald til ICE services fra andre brugere end ICE kli-
enter, er der ikke behov for at vedligeholde gamle versioner i længere tid. I udgangspunktet
vedligeholdes gamle versioner af services derfor ikke og disse holdes kun i produktion i 3 må-
neder, inden for hvilken periode ICE vil have rig mulighed for at opgradere de berørte klienter.
Denne politik evalueres senest i forbindelse med ibrugtagning af systemet, idet det skal sikres,
at historiske afgørelser kan genberegnes.
7.2.8 Asynkrone services

Nogle services, specielt mod end-points, der ikke garanterer tilstrækkelig høj oppetid, vil blive
lavet som asynkrone services via en kø i et redundant setup. Dette kunne fx være aflevering
af data til ESR, eller synkronisering af data tilbage til datakilder, hvor transaktioner enten ikke
må fejle, eller systemerne er vurderet til at være for ustabile til et synkront setup. Der kan
også vise sig performancemæssige grunde til en asynkron løsning, eller et ønske om at lave
en ’circuit breaker’ uden at miste transaktioner for at undgå overload af back-end systemer
med begrænsede ressourcer.
7.3 Integrationer
ICE har gennemført en indledende kortlægning af nødvendige integrationer til det nye it-system,
som er illustreret i tabellerne nedenfor. Den indledende oversigt over integrationer skal kvalifi-
ceres yderligere i forbindelse med afdækning af forretningskrav og udarbejdelse af løsningsde-
sign som del af det agile udviklingsforløb. Arbejdet med at kvalificere systemets integrations-
punkter er igangsat med fokus på de højst prioriterede systemer.
7.3.1 Integrationer til SKAT systemer

De væsentligste SKAT-systemer/singletons, som det nye it-system skal integrere med fremgår
af nedenstående tabel.
Prioritet System Beskrivelse

2 SLUT I SLUT beregnes og opkræves almindelig indkomstskat på baggrund af en skattepligtig ind-
komst. Det nye system skal levere ejendomsvurderingsoplysninger til brug for skattebereg-
ningen.
2 Forskud Forskud omfatter en række systemer, hvis formål er at lave forskudsskatteberegningen. Det
nye system skal levere ejendomsvurderingsoplysninger til brug for forskudsskatteberegnin-
gen.
1 EVS EVS beregner ejendomsværdiskatten givet informationer om person og virksomhed. Leverer
ejendomsværdiskattebeløbet til SLUT.
1 CAPTIA CAPTIA benyttes alene til dokumenthåndtering og journalisering. Det er endnu ikke afgjort
om det nye system skal benytte CAPTIA som dokumentsilo.
2 A&D I Aftale & Distribution håndteres kommunikation fra SKAT til borgere og virksomheder. Det
nye system skal benytte A&D ved al skriftlig kommunikation med borgere og virksomheder.
3 DW Det nye system skal periodisk overføre relevante data til DataWarehouse.
1 DCS Det Centrale Sikkerhedsløsning tilbyder fælles login-faciliteter samt propagering af roller og
rettigheder på tværs af SKATs arkitektur.
3 NTSE Ny Tast Selv Erhverv modtager virksomheders indberetninger af en række afgifter og øvrige
indberetninger. Virksomhederne kan efterfølgende se tidligere indberetninger og bl.a. også
rekvirere importspecifikationer i systemet.

Som anført ovenfor evalueres niveauet for funktionel integration til fx SKATs eksisterende jour-
nalsystem CAPTIA og DCS i forbindelse med udarbejdelse af løsningsdesign.
Integrationer til SKATs systemer anvender som udgangspunkt eksisterende SOAP interfaces.
Alternativt overføres større datamængder fx til DataWarehouse via periodisk filoverførsel.
7.3.2 Integrationer til eksterne systemer

Ud over integrationer til modtagesystemer internt i SKAT er der identificeret nedenstående eks-
terne systemer, som det nye it-system skal integrere til.
Prioritet System Beskrivelse

1 ESR + Ejendoms Stam Registret er et landsdækkende register, der indeholder oplysninger om bl.a.
nyt ESR kommunale ejendomsskatter og ejendomsbidrag. ESR er under udfasning i regi af KL/KOM-
BIT, og KOMBIT er i færd med at etablere en erstatning for ESR til beregning af kommunale
ejendomsskatter. Det nye system skal aflevere data om bl.a. grundværdier til ESR eller til
Datafordeleren, når denne er idriftsat.
3 Danmarks Danmarks Statistik står for produktion og formidling af officielle statistikker om danske
Statistik samfundsforhold. Det nye system skal periodisk levere relevante data til Danmarks Stati-
stik.
ESR eller dettes afløser er en væsentlig modtager af data fra det nye it-system. ICE er i dialog
med KOMBIT om specifikationen af det ny ESR for at sikre sammenhæng imellem tidsplaner og
krav imellem projekterne. For at imødegå risikoen forbundet med forsinkelse af udfasningen af
ESR, arbejder ICE med afdækning af interfaces til både det eksisterende ESR og det fremtidige
KOMBIT system.
7.3.3 Integrationer til kildesystemer

Der er etableret et antal separate projekter i regi af Datakontoret i ICE med henblik på at iden-
tificere databehov samt tilvejebringe og kvalitetssikre data til brug for ICE. Disse projekter er
tæt forbundne med udviklingen af statistiske beregningsmodeller, som er den primære kravstil-
ler til data på nuværende tidspunkt. Data- og modelprojekterne er ikke omfattet af denne PID,
jf. afsnit 3. På nuværende tidspunkt er identificeret nedenstående registre, som ICE skal impor-
tere data fra.
System Beskrivelse
ES Erhvervssystemet indeholder alle stamdata om og entydig identifikation af alle danske virksomheder,
samt oplysninger om disses skatte- og afgiftsadministrative registreringsforhold. Det nye it-system skal
hente oplysninger i ES om hovedaktionærer (eller anden med bestemmende indflydelse) samt bran-
chekoder.
CSR-P Centrale Skatteyder Register - Persondelen indeholder et basisregister over personoplysninger. Det
nye ejendomsvurderingssystem skal hente oplysninger i CSR-P om hvem, der bor på givne adresser.
TAFE I Tinglysning Af Fast Ejendom håndteres tinglysningsafgift. Det nye ejendomsvurderingssystem skal
hente oplysninger om ejendomshandler/overdragelser i TAFE.
Datafor- Den fællesoffentlige Datafordeler skal distribuere grunddata fra registrene til både offentlige og pri-
deler vate brugere af grunddata. Det er forventningen, at det nye ejendomsvurderingssystem skal hente ma-
trikel-, ejerforholds- og BBR-informationer til brug for vurderingsopgaven. Den fællesoffentlige Data-
fordeler udstiller endvidere ejendomsvurderingsoplysninger leveret af det nye ejendomsvurderingssy-
stem.
ESR + Ejendoms Stam Registret er et landsdækkende register, der indeholder oplysninger om bl.a. kommu-
nyt ESR nale ejendomsskatter og ejendomsbidrag. Det nye ejendomsvurderingssystem skal hente oplysninger
om basisår, fritagelser samt ændringer i dækningsafgift fra ESR. ESR er under udfasning i regi af
KL/KOMBIT med henblik på at Datafordeleren overtager opgaven med at udstille disse oplysninger. ICE
afdækker både ESR og Datafordeleren.
Geodata Geodata leverer geografiske grunddata til det nye ejendomsvurderingssystem.
DKjord Den fællesoffentlige jordforureningsdatabase DKjord skal levere information om jordforurening til det
nye ejendomsvurderingssystem.
Plansy- PlansystemDK indeholder planer efter planloven. Det er kommunerne og staten, der indberetter pla-
stemDK nerne i PlansystemDK. Det nye ejendomsvurderingssystem skal hente informationer om varslede plan-
ændringer.

Øvrige Der er en række datakilder, der vil kunne være interessante i forhold til den nye ejendomsvurderingsop-
gave, fx Sekretariatet for Energieffektive Bygninger (energimærkning af ejendomme), Centralt Husdyrs-
brugs Register (dyrehold/-enheder), Det Generelle Landbrugsregister (miljøgodkendelser), Boligporta-
ler/Mæglere (udbudspriser) og Banker/Realkreditinstitutter (vurderingspriser). Hvilke datakilder, der vil
være nødvendige, afhænger af den politiske aftale om den kommende vurderingsordning.
Etablering af integrationer til kildedata og dataimport sker i regi af Datakontoret i ICE som en
del af et separat projekt, der ligger uden for denne PID. Data stilles til rådighed for it-systemet
direkte i databaseform, hvorfor den oprindelige kilde til data, samt alle opgaver vedrørende
verifikation, transformation, versionering osv. ligger uden for projektet. Teknologi og kompo-
nenter til dataimport indgår derfor heller ikke i arkitekturen.
Den fællesoffentlige Datafordeler er både en datakilde for Datakontoret i ICE og en datamodta-

ger fra det nye it-system. ICE er i løbende dialog med Digitaliseringsstyrelsen om datafordeleren
for at sikre sammenhæng imellem tidsplanerne i projekterne. For at imødegå risikoen forbundet
med forsinkelse af datafordeleren arbejder Datakontoret i ICE med afdækning af alternativsce-
narier i fx i form af etablering af interfaces til eksisterende systemer.
7.4 Test
7.4.1 Generelt
ICE har valgt en teststrategi baseret på størst mulig automatisering under forudsætning af, at
de automatiserede test er til at vedligeholde. Automatiske tests på unit og specielt serviceni-
veau er derfor udgangspunktet ud fra de nedenfor givende retningslinjer. Automatiske tests på
GUI niveau vil blive etableret i den udstrækning, det er meningsfuldt.
Brugertest eller manuel UI test vil blive specificeret af en testmanager og udført af et testteam
bestående af sagsbehandlere fra henholdsvis SKAT og Skatteankestyrelsen. Herudover vil for-
retnings-og procesanalytikerne bistå med specifikation af test og afvikling.
7.4.2 Unit testing

Unit testing er en automatiseret test på mindste enhed af kode. Unit testing gennemføres for
algoritmer samt andre udvalgte og afgrænsede områder, hvor det vurderes, at dette tilfører
værdi. Unit testing benyttes kun på udvalgte områder, idet værdien af denne type af test vur-
deres som begrænset.7 Eftersom udviklingsstrategien baseres på udvikling af services af be-
grænset omfang (microservices) afløses unit testing således i vidt omfang af Service testing.
7.4.3 Service testing

Service testing er en test af, at et veldefineret REST API fungerer som forventet. Testen fore-
går altså på det niveau, som klienten ser, så det er helheden af funktionaliteten der testes, og
ikke de enkelte funktioner, der måtte indgå i kaldet. Udover test af, at servicen lever op til
kravspecifikationen opnås derved sikkerhed for, at klienten ikke ødelægges, når der gennem-
føres ændringer i en service. Hovedparten af de automatiserede tests vil blive udført som ser-
vice tests.
7.4.4 UI testing
UI testning er en test af brugergrænsefladens funktioner og brugervenlighed. Hovedvægten af
testressourcerne i ICE vil blive dedikeret til brugerfladen. Dette giver den bedste verifikation
af, at produktet lever op til kravene. Testene heraf er derfor altafgørende for succes. Test af
brugerfladen er samtidig vanskelig at automatisere, da selv små ændringer vil kræve et stort
vedligeholdelsesarbejde på automatiserede testscripts. Samtidig giver en automatiseret test af
brugerfladen ingen verifikation af, om designet og workflow er hensigtsmæssigt.
7
For nærmere se http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Derfor vil ICE benytte en kombination af automatiserede og manuelle brugertests af brugerfla-
den, så alle elementer evalueres samlet. Testen gennemføres af en testteam, der overvåges af
en testmanager og en UX ekspert.
7.4.4.1 Automatisk
Den automatiske test af brugerfladen forventes at komme til at bestå af gennemløb af nogle
ofte brugte scenarier for at få et pejlemærke for, om det giver mening at ulejlige testteamet.
De automatiske tests vil blive lavet i Selenium eller lignende værktøjer.
7.4.4.2 Manuel
Testmanageren vil beskrive de testforløb, der skal gennemgås af testteamet. Under test ind-
rapporteres afvigelser eller uhensigtsmæssigheder til testmanageren, der vurderer disse. Hvis
det er nødvendigt, opretter testmanageren en fejlrapport til udviklingsteamet. Disse tests gen-
nemføres så ofte, som testmanageren vurderer det nødvendigt. I forbindelse med disse tests
vil en UX ekspert også deltage for at observere brugermønstre og hermed identificere uhen-
sigtsmæssigheder i designet og/eller workflowet. UX ekspertens findings vil også give anled-
ning til ændringsønsker, der skal udføres af udviklingsteamet.
8 Leverancer
8.1 Leverancer og afhængigheder
Projektets hovedleverancer er ny samlet it-understøttelse af det nye
ejendomsvurderingssystem. Den nye it-løsning vil have snitflader til mange interne og eksterne
systemer, jf. figur 2.1 og 2.2. Igangsættelsen af it-udviklingen og planlægningen heraf er
afhængig af den igangværende kravspecifikation af it-systemet, der gennemføres i regi af et
andet projekt i ICE, som først forventes endeligt at kunne afsluttes i forlængelse af en politisk
aftale om ny lovgivning i foråret 2016 samt resultaterne fra model- og dataprojekterne.
Projektets samlede leverance vil blive leveret i et antal delleverancer med henblik på løbende at
levere ny funktionalitet, som understøtter arbejdet hen imod forberedelse og udsendelse af
ejendomsvurderingen i 2018 hhv. 2019. Første leverance forventes derfor at skulle være klar i
1. kvartal 2017. En leverance, der skal understøtte de første vurderinger i det nye
ejendomsvurderingssystem pr. 1. oktober 2017, herunder berigtigelsen af data med tilhørende
dialog med ejendomsejerne.
Projektets leveranceplan nedenfor reflekterer den valgte agile udviklingsstrategi, der kan
håndtere den parallelle forretningsafklaring og den overordnede tidsplan beskrevet i henholdsvis
afsnit 10.2 og 10.5.
Leverancer med milepæle før september 2015 vedrører forberedende udviklingsaktiviteter, som
er nødvendige for at kunne igangsætte udviklingsarbejdet umiddelbart efter projektet har været
forelagt Finansudvalget. Den første af forberedelsesfaserne, prototype-forløbet, er gennemført,
som grundlag for at gå videre med den valgte egenudviklingsstrategi. Den anden
forberedelsefase, der løber indtil godkendelse i Finansudvalget, skal sikre yderligere afklaringer
frem mod opstart af den egentlige udvikling.
Leverancebeskrivelse Leveringstidspunkt
Forberedelse, Prototype
fase 1
Etablering af fysiske miljøer og drift af prototype 31.05.15
Prototype, metodeudvikling 31.05.15
(gennemført 01-05.15)
Prototype, demo 28.04.15
(Gennemført)
Prototype, erfaringsopsamling 31.05.15
Forberedelse, Erfaringsopsamling til egenudvikling
fase 2

Leverancebeskrivelse Leveringstidspunkt
Forberedelse af egenudvikling, herunder organisatorisk set-up, skabelo- 30.06.15
ner, samarbejdsaftaler (kravstillelsesprojektet, model-og dataprojek-
terne i ICE)
GIS anvendelse: arkitektur, system løsning og evt. udbud 30.06.15
Overordnet Enterprise Arkitektur, herunder data formater og snitflader 15.09.15
til modeller
Release planlægning til release train* 1 30.06.15
System arkitektur til release train 1 30.06.15
Enterprise arkitektur til release train 1, herunder grænseflader til it-sy- 30.06.15
stemer og dataleverandører
Estimering af ressource-forbrug til hele systemet med afsæt i release 1 15.09.15
Etablering af fysisk miljø (udvikling- og testmiljø) 30.09.15
Sikkerhed, herunder juridiske afklaringer i fht persondataloven og krigs- 30.09.15
reglen
Release planlægning til release train 2 30.09.15
Enterprise arkitektur til release train 2 30.09.15
Release train 1, sprint 1 til x 30.09.15
Egenudvikling
Udbud af hosting miljø 15.11.15
Enterprise arkitektur til release train 3 15.12.15
Release planlægning til release train 3 15.12.15
Samlet estimering af ressourceforbrug til hele systemet med afsæt i re- 31.12.15
lease 1 og 2
Design og implementering af støtteværktøjer release train 2, sprint 1 til 15.12.15
x
Design og implementering af støtteværktøjer release train 3, sprint 1 til 15.03.16
x
… Forberedelse og afvikling af release trains* fortsætter med løbende
tilpasning af krav, prioritering og ressourcer, hvor muligt og nødven-
digt…
Etablering af fysisk miljø og drift til endelig produktion 31.03.17
1. produktionsrelease: kommunikation med ejer, manuel sagsbehand- 31.03.17
ling af ejerboliger og –grunde
2. produktionsrelease: 1. modelvurdering af ejerboliger og –grunde 01.10.17
3. produktionsrelease: klagebehandling ejerboliger og –grunde samt 31.03.18
ejerkommunikation og manuel sagsbehandling af erhverv, land- og
skovbrug
4. produktionsrelease: 1. modelvurdering af erhverv, land- og skovbrug 01.10.18
5. produktionsrelease: klagebehandling af af erhverv, land- og skovbrug 31.03.19
Koordinering af grænseflader (systemgrænseflader) Løbende til projektets
afslutning
Note: (*) I henhold til den valgte agile udviklingsstrategi udvikles og testes sammenhængende funktionsdele: i form af
release trains, der er opdelt i enkeltstående sprints.
9 Organisering
9.1 Projektorganisation
Systemudviklingsprojektet er et projekt under ICE programmet og dermed underlagt den sty-
ring, der er aftalt her. De konkrete projekter og organisering heraf vil udvikle sig over pro-
grammets levetid, og nedenfor fremgår derfor den samlede projektorganisering af ICE for
2015, hvoraf systemudviklingsprojektet (fremhævet med rød) udgør ét af de centrale projek-
ter. ICE programmet er forankret som en selvstændig programorganisation i Skatteministeriet

med fuldt allokerede ressourcer og en styregruppe bestående af ledende medarbejdere fra
henholdsvis Skatteministeriet, SKAT og Skatteankestyrelsen (SANST).
Figur 9.1. Projektorganisering for ICE
Styregruppe
Reference- Program-
gruppe leder
PMO
Projekt-
Stab
styring
Kontor
Modeller Data Jura Processer System
Ansvarlige
k ontorchefer
Projekter
Forbedret
Modeller for Modeller for Lovforslag Etablering af Vurdering og
datagrundlag Data- System-
ejerboliger erhverv og og aftale- drifts- klage-
og dataind- infrastruktur håndtering udvikling og it
og -grunde -grunde samling grundlag organisation
Projek t-
deltagere
Opbygning Juridiske og
Udvikling af Udvikling af Forbedret SKAT System-
af ETL og forretnings-
modeller modeller datagrundlag organisation udvikling
database afklaringer
Delprojekter
Baggrunds- Pilot på Dataind- SANST Håndtering af

IT
materiale erhvervsdata samling organisation mellem-
periode
Baggrunds- Prototyping 1
materiale
9.2 Styregruppe
Ansvaret for den overordnede fremdrift og styring af projektarbejdet med etableringen af et
nyt ejendomsvurderingssystem – herunder det nye it-system – er forankret i styregruppen.
Styregruppen består af afdelingschefer fra Skatteministeriets departement, direktører fra
SKAT samt direktøren for Skatteankestyrelsen. Afdelingschefen for koncernstyring i Skattemi-
nisteriets departement er formand for styregruppen. På møderne deltager ligeledes program-
chefen og kontorchefen for Jura og Stab samt øvrige fagkontorchefer efter behov.
Styregruppeformand / projektejer Afdelingschef, Andreas Berggreen Skatteministeriets departement

Styregruppemedlem Afdelingschef, Birgitte Christensen Skatteministeriets departement
Styregruppemedlem Afdelingschef, Jakob Hald Skatteministeriets departement
Styregruppemedlem Direktør for SKAT, Jesper Rønnow Si-
SKAT
monsen
Styregruppemedlem Underdirektør for Ejendomsvurdering,
SKAT
Sanne Kjær
Styregruppemedlem Direktør, Annette Hummelshøj Skatteankestyrelsen
Styregruppemedlem Afdelingschef, Pernille Møller Tronborg Skatteankestyrelsen
Programleder Programchef, Kristian Hertz ICE
Styregruppen har til opgave at afklare de væsentligste mandater, blandt andet ved at træffe
beslutninger om centrale forhold i programmet, herunder fx norm for ejendomsvurdering, mo-
deller for it-understøttelse, klagestruktur mv. Derudover skal styregruppen mobilisere de for-
nødne ressourcer i deres respektive organisationer med henblik på at sikre fremdrift i det
samlede program. For at understøtte dette arbejde forelægges styregruppen løbende status-
rapporteringer for fremdriften i programmet.

9.3 Projektleder og projektgruppe
Der er etableret en projektgruppe for it-projektet med deltagelse af medarbejdere fra Syskon-
toret, Proceskontoret og Datakontoret i ICE. Kontorchef Steen Larsen (Systemkontoret) og
kontorchef Lotte Bomgaard (Proceskontoret) er ansvarlige for projektet. Steen Larsen er sam-
tidig projektleder.
Rolle Navn og enhed Ressource Kompetencer

Projektleder Steen Larsen Fuld tid Projektledelse og systemud-
vikling
Product Owner Mette Kellman Hansen Fuld tid Forretningsanalyse
SCRUM Master Søren Rindal Nielsen Fuld tid It-udvikling og programme-
ring
Projektdeltager Kevin Flaherty Fuld tid It-udvikling og programme-
ring
Projektdeltager Jonas Green Fuld tid It-udvikling og programme-
ring
Projektdeltager David Flygenrig Nielsen Fuld tid It-udvikling og programme-
ring
Projektdeltager Thomas Engelschmidt Fuld tid It-udvikling og programme-
ring
Projektdeltager Kevin Ilcmann Jørgensen Fuld tid It-udvikling og programme-
ring
Projektdeltager NN Fuld tid It-udvikling og programme-
ring
ring
ring
Projektdeltager Casper Clausen Fuld tid Enterprise Arkitektur
Projektdeltager NN Fuld tid Devops
Projektdeltager NN Fuld tid Devops
Projektdeltager Janne Larsen Fuld tid Procesanalytiker og test
Testmanager NN Fuld tid Testmanager
Testmanager NN Fuld tid Testmanager
Projektdeltager NN Fuld tid Automatisk testspecialist
Projektdeltager NN Fuld tid Dataarkitekt
Projektdeltager NN Fuld tid Dataarkitekt
Det er aftalt med henholdsvis SKAT og SANST, at de stiller sagsbehandlere til rådighed for
test. Det endelige omfang skal fastlægges, og er ikke medtaget i tabellen.
Med henblik på at sikre den fornødne forretningsmæssige viden og et tilstrækkeligt tempo i de

forretningsmæssige og tekniske afklaringer undervejs i udviklingsprocessen etableres et tvær-
gående Product Owner Panel (POP) med deltagelse af medarbejdere med specialistviden, der
deltager efter behov. POP mødes efter behov og kan indkaldes af Product Owner med kort var-
sel. Product Owner kan desuden til enhver tid vælge af eskalere større eller principielle afkla-
ringer til programchefen og relevante kontorchefer.
9.4 Driftsansvarlige
Den endelige organisering af driften skal afklares nærmere som en del af etableringen af den
fremtidige driftsorganisation. På nuværende tidspunkt vurderes nedenstående at blive drifts-
ansvarlige for systemet.

Rolle Navn og titel Enhed
Systemejer (forretning) Direktør for it, Jan Topp Ras- SKAT IT
mussen
Platformsejer (teknisk drift) Direktør for it, Jan Topp Ras- SKAT IT
mussen
Procesejer – vurdering Kontorchef Jørgen Wissing, SKAT
SKAT UDV
Procesejer – klager Direktør, Annette Hummelshøj Skatteankestyrelsen
Der er aftalt en tæt dialog med SKAT Ejendom, der er ansvarlig for sagsbehandling i forbin-
delse med ejendomsvurderingen, SKAT UDV, der er ansvarlig for ejendomsvurderingsproces-
sen i SKAT og Vurderingsafdelingen i SANST, der er ansvarlig for klager over ejendomsvurde-
ringen.
10 Tilrettelæggelse og tidsplan
10.1 Udbudsstrategi
ICE har arbejdet efter en strategi for tilvejebringelse af det nye it-system, hvor det som ud-
gangspunkt har skullet udvikles agilt via udbud af en K03-kontrakt med en ekstern leverandør,
dog kombineret med en forudgående teknisk prototyping, der, udover at bidrage til forret-
ningsmæssige og tekniske afklaringer, skulle bidrage til afklaring af, om egenudvikling er et
alternativ til anvendelse af en ekstern leverandør.
ICE har i marts og april 2015 gennemført et vellykket prototyping-forløb. På denne baggrund
har styregruppen for ICE besluttet, at it-projektet mest hensigtsmæssigt kan gennemføres
som egenudvikling med udbud af afgrænsede funktionaliteter.
10.1.1 Udvikling af prototypen

Inden arbejdet med prototyping kunne igangsættes har det været en central forudsætning at
ICE kunne rekruttere og opbygge et selvstændigt udviklingsteam med højt specialiserede
kompetencer og viden. Dette er lykkedes, og ICE har ansat en erfaren it-udviklingschef for sy-
stemkontoret og 7 udviklere.
Den 1. marts 2015 iværksatte ICE derfor efter planen og med udgangspunkt i den af styre-
gruppen for ICE valgte strategi et intensivt forløb med teknisk prototyping. Styregruppen har
ved valg af strategien for den tekniske prototyping prioriteret tre succeskriterier.
For det første skulle ICE demonstrere, at udviklingsteamet er i stand til at understøtte et agilt
udviklingsforløb med såvel bemanding, metodeapparat og rettidige afklaringer af forretnings-
mæssige problemstillinger.
For det andet skulle udviklingsteamet vise, at det kan levere kode i tilstrækkelig kvalitet og
tempo, som understøtter de forretningsmæssige krav (processer, brugervenlighed, logning,
historik og afskærmning mv.).
For det tredje skulle udviklingsteamet endelig demonstrere evnen til at integrere vurderingssy-
stemets centrale komponenter (data, model, workflow) i en sammenhængende løsning for en
hovedproces (‘enkeltejendomsvurdering’).
Systemkontoret i ICE har i uge 18 – efter et knap 2 måneders forløb og på godt 20 effektive
arbejdsdage – gennemført en demonstration af den udviklede prototype, der omfattede føl-
gende:
1. En gennemgang af den valgte microservice arkitektur

2. En gennemgang af agil udvikling med SCRUM som proces
3. En demonstration af en integration mellem data og GIS

4. En gennemgang af selve vurderingssystemet (brugergrænsefladen) for den valgte manu-
elle delproces for ’enkeltejendomsvurdering’, der var udviklet
5. En gennemgang af logsystemet og de muligheder det giver for overvågning, rapportering
og alarmering
6. En demonstration af det valgte SCRUM værktøj og en gennemgang af, hvad SCRUM er.
ICE har på baggrund af de opstillede succeskriterier og det faktiske resultat vurderet, at proto-
typingen er forløbet vellykket og har ført til et tilfredsstillende resultat.
Det er således for det første lykkedes at opbygge et udviklerteam med højt specialiserede
kompetencer og en stor erfaring, som i forløbet har demonstreret, at det kan arbejde agilt og
samarbejde med forretningsafklaringsprojektet for at sikre, at der leveres rettidige afklaringer
af forretningsmæssige problemstillinger i forhold til at sikre fremdrift i it-udviklingen. IT-udvik-
lingsprojektet har i det løbende arbejde demonstreret, at det samarbejder godt internt med de
andre kontorer i ICE.
Demonstrationen af prototypen demonstrerede for det andet, at udviklerteamet på meget kort

tid har været i stand til at udvikle dels en brugergrænseflade for en manuel vurderingsproces,
som er brugervenlig og enkel, dels har udviklet en række generelle funktionaliteter i form af
log-in, logning, sagskø mv.
Demonstrationen har endelig for det tredje vist, at udviklerteamet har formået at bygge væ-
sentlige integrationer mellem data og GIS-teknologi, som understøtter et effektivt workflow
for den valgte manuelle delproces for ’enkeltejendomsvurdering’, da systemet bl.a. viser ejen-
dommenes og naboernes beliggenhed på et kort, streetview mv.
10.1.2 Valg af leverancemodel

ICE vurderer på baggrund af det gennemførte prototyping forløb, at den helt afgørende faktor
for at sikre en succesfuld udvikling af et nyt it-system, der har den fornødne kvalitet og funkti-
onalitet og som leveres til tiden, er, at udviklingen sker i tæt samspil mellem forretningen og
it. Det er således ikke udviklingen af selve den tekniske funktionalitet, der udgør den væsent-
ligste udfordring for et vellykket resultat. Derimod viser erfaringen – bl.a. fra en lang række af
SKATs tidligere it-projekter – at det er kritisk, at den nødvendige forretningsviden er tæt kob-
let med it-udviklingen, og at forretningen hurtigt er i stand til at levere forretningsmæssige og
juridiske afklaringer og omsætte disse til konkrete krav, der skal udvikles.
Denne forudsætning er vanskelig at realisere i et rent udbudsscenarie, da afstanden mellem

forretningen og kravstilleren på den ene side og it-leverandøren på den anden side bliver for
stor, og da den forretningsmæssige kompetence derfor som en konsekvens heraf over tid bli-
ver opbygget hos leverandøren.
Det vurderes derfor, at det centrale for at udvikle det nye it-system er, at den forretnings-
mæssige viden fastholdes i ICE, og at it-udviklingen i projektet sker i tæt samspil mellem for-
retningen og projektet. Dette taler for, at ansvaret for udviklingen af og kontrollen med it-sy-
stemet placeres i ICE. Det er dog ikke nødvendigvis afgørende, at alle it-komponenter udvikles
af projektet selv, og der kan givetvis ske en outsourcing af udviklingen af afgrænsede funktio-
naliteter og/eller insources eksterne udviklere, så længe ICE fastholder en tæt styring og kon-
trol med it-udviklingen. ICE har dog som led i prototyping forløbet opbygget en erfaren og
specialiseret udviklingskapacitet, og det er derfor naturligt, at de centrale dele af it-systemet
udvikles in-house.
Det vurderes således ikke at være et spørgsmål om enten at tilvejebringe it-systemet via et
udbud eller egenudvikle det fuldt ud. Den mest hensigtsmæssige og realiserbare model for til-
vejebringelse af det nye it-system vurderes derimod at være at kombinere egenudvikling med
udbud af afgrænsede funktionaliteter. Begrundelserne for den valgte leverancestrategi gen-
nemgås nærmere nedenfor.
10.1.2.1 Scope
Det implementeringsforberedende arbejde i ICE er tilrettelagt agilt og iterativt, hvilket inde-
bærer, at lovgivning, processer, vurderingsmodeller og forretningskrav udvikles parallelt med

it-systemet. Den agile tilrettelæggelse af arbejdet sker både af hensyn til den fastlagte tids-
plan, men også af hensyn til, at det vurderes at være den mest hensigtsmæssige tilgang i for-
hold til at sikre, at den lov som fremsættes for Folketinget efterfølgende lader sig administrere
i praksis.
Der udestår fortsat væsentlige forretnings- og modelmæssige afklaringer og det endelige

scope for det nye it-system vil derfor også tidligst ligge fast, når Folketinget har vedtaget en
ny vurderingslov, som først forventes at ske i foråret 2016. Det vil som følge heraf være van-
skeligt at udforme en kravspecifikation for det samlede system og et tilstrækkeligt detaljeret
udbudsmateriale til gennemførelsen af et K03-udbud, som ifølge tidsplanen vil skulle offentlig-
gøres allerede den 1. juli 2015. Offentliggørelsen af et utilstrækkeligt udbudsmateriale vil in-
debære, at en ekstern leverandør vil have vanskeligt ved at udforme et præcist tilbud, som ef-
terfølgende lader sig omsætte i praksis, ligesom leverandøren må forventes at ville tage en
væsentlig risikopræmie.
Det vil endvidere være en særskilt udfordring at udbyde et it-system offentligt, hvor kravspe-
cifikation viser skitsen til det nye ejendomsvurderingssystem, inden der er indgået en politisk
aftale om rammerne for det nye ejendomsvurderingssystem.
Derimod vurderes en egenudvikling af systemet kombineret med afgrænsende udbud at un-

derstøtte den nødvendige agilitet i projektet, da de nødvendige forretningsmæssige og tekni-
ske afklaringer og den detaljerede kravspecifikation af it-systemet kan ske løbende over de
kommende år i en tæt og iterativ proces mellem proceskonsulenter, jurister, modelfolk og it-
udviklere. Prototype-forløbet har således demonstreret, at det er helt centralt, at der eksiste-
rer et tæt samspil mellem forretningen og it, der muliggør, at der hele tiden kan foretages æn-
dringer i kravspecificeringen – bl.a. i takt med den løbende modeludvikling – og at ændrin-
gerne hurtigt kan omsættes til konkrete krav til udviklerne af systemet.
Som et led i afklaringsprocessen vil der desuden løbende kunne identificeres afgrænsende
funktionaliteter i systemet, som kan udbydes og leveres af eksterne leverandører. Skattemini-
steriet har bl.a. i den forbindelse igangsat et arbejde med udbud af en generel rammeaftale
vedrørende bistand til it-udvikling. Rammeaftalen vil også kunne anvendes af ICE. Rammeaf-
talen vil gøre det muligt for projektet at reagere hurtigt på opståede behov for ekstern bi-
stand. Rammeaftalen vil fx kunne anvendes til outsourcing af integrationer.
10.1.2.2 Tid
Den foreslåede leverancemodel har den helt centrale fordel, at it-udviklingen vil kunne påbe-
gyndes langt tidligere sammenlignet med gennemførelsen af et K03-udbud. Et K03-udbud vil
således tidligt kunne afsluttes i slutningen af 2015, hvorefter der vil skulle ske en række tekni-
ske og forretningsmæssige afklaringer sammen med den valgte leverandør. Selve it-udviklin-
gen vil derfor først reelt kunne igangsættes i 1. kvartal af 2016, hvilket alene vil give den eks-
terne leverandør ca. 1 år til at udvikle systemet. Dette vurderes at være en endog meget
stram tidsplan, som nødvendigvis vil indebære betydelige risici for forsinkelser.
Egenudvikling forventes derimod allerede at kunne påbegyndes i september 2015, når it-pro-
jektet har været forelagt Statens IT-projektråd og FiU. Dette vil i sig selv give et ekstra ½ år
til udvikling, ligesom udviklingsteamet frem til den egentlige udviklingsfase grundigt vil kunne
forberede it-udviklingen og foretage de nødvendige tekniske og arkitekturmæssige afklaringer
samt bistå med input til de forretningsmæssige afklaringer og kravspecifikationen. Dette vur-
deres at være en realistisk og mindre risikofyldt tidsplan.
10.1.2.3 Økonomi
De samlede omkostninger ved egenudvikling kombineret med udbud vurderes at blive væsent-
lig lavere sammenlignet med tilvejebringelsen af systemet via et K03-udbud. Det skønnes så-
ledes, at de samlede omkostninger til egenudvikling af it-systemet vil udgøre i størrelsesorde-
nen 81,8 mio. kr. (inkl. renter og risikopulje) over hele udviklingsperioden, jf. afsnit 5. Skøn-
net er dog fortsat behæftet med en vis usikkerhed.
Til sammenligning har Deloitte tidligere skønnet, at de samlede omkostninger ved et K03-ud-
bud til udvikling af et tilsvarende it-system vil udgøre i størrelsesordenen 350 mio. kr. Dette
bud er dog også usikkert, da de endelige udgifter fx vil afhænge af detaljeringsgraden af krav-
specifikationen.

Den store prisforskel vurderes bl.a. at kunne henføres til, at leverandøren vil have behov for at
tage en risikopræmie, og at der til et rent udbudsscenarie knytter sig meget væsentlige trans-
aktionsomkostninger, som ikke opstår i samme omfang, når udviklingen hovedsageligt sker
internt.
10.1.2.4 Kvalitet
Prototype-forløbet har demonstreret, at det på relativ kort tid har været muligt at udvikle en
moderne brugergrænseflade med anvendelsen af bl.a. GIS-teknologi, der kan understøtte
sagsbehandlingen, og det er forventningen, at den valgte arkitektur i form af bl.a. microser-
vices og reactive single page webfront, vil kunne sikre, at der udvikles et it-system, som kan
understøtte en enkel og effektiv sagsbehandling. Desuden vil den valgte arkitektur sikre, at
der kan skaleres horisontalt, så eventuelle belastningsproblemer altid vil kunne løses med flere
serverinstanser, jf. afsnit 7.
10.2 Udviklingsstrategi
ICE har valgt en agil udviklingsstrategi baseret på SCRUM. Den agile tilgang indebærer at it-
systemet udvikles i et iterativt forløb i et tæt samarbejde mellem den pågående forretnings-
analyse og udviklingsteamet. Således indgår proces- og forretningsanalytikere direkte i udvik-
lingsteamet i forbindelse med teamets leveranceforløb (delivery sprints), hvor de løbende af-
klarer og raffinerer kravene til løsningen. Når den pågældende leverance er komplet afløses de
pågældende proces- og forretningsanalytikere af andre analytikere, som har analyseret den
næste leverance til bunds. Dette sikrer, at udviklerteamet understøttes tæt af den bedste for-
retningsviden projektet råder over, samtidig med at næste leverancer forberedes. Udviklings-
modellen er illustreret i figuren nedenfor.
Figur 10.1. Udviklingsmodel
I det enkelte delivery sprint fokuseres på at lave hele vertikale løsninger for de user stories,
som indgår i sprinten. Et team leverer således den fulde funktionalitet i stedet for fx at lade

separate teams udvikle hvert lag i arktiekturen for sig. Derved reduceres risikoen for fejl som
følge af parallel udvikling og overleveringer.
Backlog, sprintlog og fremdrift registereres elektronisk i VersionOne, således at projektet lø-

bende kan følge op på leverancer og fremdrift i forhold til plan og kan prioritere på basis af
data i real-time.
Indledningsvist arbejdes i sprints af 2 ugers varighed. Dette evalueres løbende og varigheden

justeres hvis der viser sig et behov (kaizen). Den enkelte sprint styres efter følgende format:
1. Initiel sprint planlægning.
2. Daglige standup møder
3. Demo
4. Retrospective (efter afslutning)
Sigtet med retrospective er at evaluere forløbet og identificere effektiviseringspotentiale og eli-

minere spildtid (muda) fremadrettet.
Al udvikling (kompilering) og deployering af kode til udviklings-, test og præproduktions mil-

jøer er automatiseret via GO (Thoughtworks) Continuous Delivery server. Dette setup sikrer at
al kode kvalitetssikres inden det deployeres og eliminerer risikoen for manuelle håndteringsfejl
i forbindelse med udrulning af nye kodeversioner. Endvidere sikrer metoden, at der altid kan
rulles tilbage til en tidligere kodeversion. Automatiseringen af deployment sammenholdt med
den agile tilgang til udviklingen indebærer at kode kontinuerligt deployeres. Mindre releases er
i sig selv mindre risikable end store og i tilfælde af fejl kan disse hurtigere identificeres og ret-
tes.
Etablering af servere i udviklings-, test- og præproduktionsmiljøer er ligeledes automatiseret

vha. Ansible. Dette sikrer ligeledes imod manuelle fejl, ligesom etablering og reinstallation af
servereer meget lidt ressourcekrævende.
Før den endelige idriftsættelse af systemet (’go-live’) vil der skulle synkroniseres data fra
samtlige relevante datakilder, hvilket vil foregå i samarbejde mellem Datakontoret og System-
kontoret, hvor Datakontoret er ansvarligt for fremskaffelse af data, mens Systemkontoret sør-
ger for at deploye i et redundant setup med high availability. Med henblik på at sikre de nød-
vendige afklaringer samt en hensigtsmæssig opbygning af den database, som systemet vil
trække fra, allokeres i hele udviklingsfasen en række dedikerede dataarkitekter fra Datakonto-
ret til it-projektet.
10.3 Implementeringsstrategi og forandringsledelse

Strategien for implementering og forandringsledelse, herunder idriftsættelse af systemet, ud-
dannelse af sagsbehandlere samt kommunikation er endnu ikke fastlagt. Dette forventes først
at ske i løbet af efteråret 2015.
Udgangspunktet for strategien er imidlertid, at det ikke kun er et nyt it-system, der skal im-
plementeres, men også et helt nyt ejendomsvurderingssystem, hvor en stor del af vurderin-
gerne er baseret på modelberegnede værdier og nye data mv. Strategien for implementering
og idriftsættelsen af det nye it-system kan derfor heller ikke ske isoleret, men skal udformes i
tæt sammenhæng med de øvrige projekter i ICE, herunder de nye vurderingsmodeller og
etableringen af driftsorganisationen.
Der eksisterer en brændende platform for implementeringen af det nye it-system (og det nye
ejendomsvurderingssystem generelt), da tilliden til det gamle system er undermineret. Det er
dog afgørende at være opmærksom på, at de medarbejdere, der skal overtage systemet i
SKAT fortsat kan have en ’loyalitet’ over for det gamle system og kan have følt sig ramt på de-
res faglighed i forbindelse med den megen offentlige kritik, der har været af systemet. Når der
hertil lægges, at medarbejderne med det nye ejendomsvurderingssystem dels skal til at fore-

tage vurderingerne på en helt ny måde og ved anvendelsen af nye metoder og et nyt it-sy-
stem, dels har en høj aldersprofil8, bliver det en betydelig opgave at gennemføre den forestå-
ende forandring og implementere systemet.
For at sikre en effektiv implementering er det for det første centralt at visionen om, at det nye
ejendomsvurderingssystem skal genskabe tilliden til ejendomsvurderingerne også gøres til
medarbejdernes og ledernes i SKAT og Skatteankestyrelsens vision. Visionen skal således gen-
nemsyre arbejdet med forandringsledelsen og den tilhørende implementering. Tilliden skal
genskabes og et af målene (se kapitel 4 og 6) er derfor, at medarbejderne i SKAT og Skatte-
ankestyrelsen ikke kun skal lave nogle præcise og veldokumenterede ejendomsvurderinger og
en korrekt klagebehandling, de skal også være stolte over at arbejde med ejendomsvurderin-
ger (målt gennem høj medarbejdertilfredshed) og fortælle, at de er stolte af det, de laver.
For det andet vurderes det centralt, at der sikres en modtagerparathed hos SKAT og Skattean-
kestyrelsen i den forstand, at ledere og medarbejdere ikke kommer til at opleve, at ICE leve-
rer et helt nyt ejendomsvurderingssystem, som er udviklet uafhængigt af de ledere og medar-
bejdere, som efterfølgende skal anvende det. Det er således helt afgørende, at ICE involverer
og inddrager den viden og erfaring, der er opbygget i de to organisationer i udviklingen af det
nye system.
Dette søges håndteret ved, at der etableres et tæt og løbende samarbejde mellem ICE på den
ene side og SKAT og SANST på den anden side samt sker en fælles afstemning af den løbende
kommunikation i de to institutioner. Dialogen og samarbejdet skal ikke kun foregå på styre-
gruppeniveau, men også være en integreret del af det daglige udviklingsarbejde. For at sikre
en tæt integration er der derfor også indstationeret medarbejdere fra SKAT og SANST i ICE,
der kravstiller til det nye system, og som desuden vil skulle deltage i de SCRUM-teams, der
udvikler systemet. Herudover er det aftalt, at testteamet skal bemandes af sagsbehandlere fra
modtagerorganisationerne. Den løbende inddragelse skal sikre, at der løbende kan ske en for-
ventningsafstemning og kvalitetssikring i forhold til it-systemet samt understøtte, at de med-
arbejdere, der deltager i udviklingsarbejdet bliver ’ambassadører’ for det nye system. Målet er
at de ’gamle’ medarbejdere i de nye driftsorganisationer kan se og mærke, at det nye system
er lavet til dem og er baseret på deres behov for it-understøttelse vurderingsarbejdet og kla-
gebehandlingen.
For det tredje skal det ved fastlæggelse af strategien for forandringsledelse ikke undervurde-
res, at den nye tilgang til ejendomsvurdering med en høj grad af modelbaserede vurderinger
vil komme til at udfordre mange af de eksisterende medarbejderne, der vil opleve de nye vur-
deringsmetoder som en desavouering af den måde, de har arbejdet på i rigtig mange år. X
pct. af medarbejderne i SKAT været der i mere end [XX/20 år] og samtidigt har xx pct. af
medarbejderne været der mindre end ét år. Der skal derfor tages højde for, at der ikke vil
være mange medarbejdere, hvis nogen – ud over dem, der deltager i udviklingsarbejdet – der
kan fungere som faglige fyrtårne. Der vil derfor både skulle arbejdes med en bottom-up og en
top-down tilgang til sikring af den nødvendige forandringsledelse.
Løbende kommunikation og fejring af også de mindre succeser og opfyldelse af delmål for de i

kapitel 6 beskrevne gevinster bliver derfor afgørende for at fastholde, at den nye metode er
den rigtige vej – også selvom der kan komme et betydeligt antal klager efter de første vurde-
ringer i 2018.
Endelig skal det for det fjerde sikres, at der i god tid før idriftsættelsen sker en fokuseret ind-
sats på at uddanne og oplære sagsbehandlerne i SKAT og Skatteankestyrelsen i det nye it-sy-
stems funktioner og støtteværktøjer. Tilbagemeldingerne fra testerne fra SKAT og Skatteanke-
styrelsen vil være afgørende ved fastlæggelse af den endelige uddannelsesstrategi.
8
x% af medarbejderne er over 50 år og har været der i mere end y år

10.4 Kriterier for overdragelse af leverancer fra projekt til forretning
Kriterierne for overdragelse af it-projektets leverancer – og de nært tilknyttede leverancer
vedrørende forretningen – er oplistet nedenfor.
Ansvarlig for overdra-

Overtagelseskriterium Beskrivelse Overdrages til gelse
1. Driftsorganisation klar Driftsorganisationerne i SKAT Ejendom Proceskontoret i ICE
SKAT Ejendom og SANST SANST Ejendomsvurde-
er etableret/tilpasset or- ring
ganisatorisk og uddannet
2 Forvaltningsorganisation Forretningsforvaltning SKAT SKAT UDV Proceskontoret i ICE
(forretning) klar og SANST er tilpasset organi- SANST Ejendomsvurde-
satorisk og uddannet ring
3 Forvaltningsorganisation It-forvaltningsorganisationen SKAT IT Systemkontoret i ICE
(it) klar i SKAT er tilpasset organisato-
risk og uddannet
4. Driftsdokumentation ud- Beredskabsplan/ SLA/ Sy- Systemejer Systemkontoret og Data-
arbejdet og godkendt stemdokumentation udar- Platformsejer kontoret i ICE
bejdet og godkendt Hos SKAT IT
5. SLA mellem proces- og Beredskabsplan/ SLA/ Sy- Systemejer, SKAT IT, og Proces-, System- og Data-
systemejer samt med leve- stemdokumentation udar- procesejer, SKAT UDV kontorerne i ICE
randører godkendt bejdet og godkendt
6. Procesdokumentation Procesdokumentation Procesejere SKAT, UDV Proceskontoret i ICE
udarbejdet og godkendt med tilhørende forret- og SANST
ningsregler, arbejdsbe-
skrivelse mm udarbejdet,
godkendt og overdraget
7. Kendte fejl og ændrin- Fastlæggelse af ”Work Processejere hos SKAT Proces- og systemkonto-
ger dokumenteret Around” samt afhjælp- og SANST rerne i ICE
ningsplan for kendte fejl
ved idriftsættelse skal
være udarbejdet.
Kendte ændringer samt
plan for udvikling og
idriftsættelse skal være
udarbejdet.
10.5 Tidsplan
Tidsplanen for systemudviklingsprojektet nedenfor er udarbejdet med afsæt i en række cen-
trale milepæle for hele ICE programmet. Den tilhørende leveranceplan ses i kapitel 8, mens
milepæle og projektplan for hele programmet ses i Bilag XX, mens projektplanen for it-projek-
tet ses i Bilag yy.
Tidsplan Måldato
Forberedelse fase 1: prototyping 31.05.15
Forberedelse fase 2: erfaringsopsamling 30.09.15
Beslutning om egenudvikling - aktstykke til FiU 30.09.15
Vedtagelse af lovforslag Forår 16
1. Produktionsrelease: kommunikation med ejer og manuel sagsbehandling af
31.03.17
ejerboliger og –grunde
2. Produktionsrelease: 1. modelvurdering af ejerboliger og –grunde 01.10.17
3. Produktionsrelease: klagebehandling ejerboliger og –grunde samt ejerkom- 31.03.18
munikation og manuel sagsbehandling af erhvervsejendomme, -grunde, land-
og skovbrug
4. Produktionsrelease: 1. modelvurdering af erhvervsejendomme, -grunde, 01.10.18
land- og skovbrug
5. Produktionsrelease: klagebehandling af erhverv, land- og skovbrug 31.03.19

Som følge af sin høje kompleksitet og mange afhængigheder eksempelvis til modeludvikling
og lovgivningsarbejde er systemudviklingsprojektet forbundet med risiko for forsinkelser, der
søges mitigeret via en agil udviklingsmetode, effektiv ressourceallokering samt stram projekt-
styring. Samlet set vurderes tidsplanen derfor realistisk.
11 Kvalitet
Formålet med dette kapitel er, at sikre en konsolideret kvalitetsplan i forbindelse med udviklin-
gen af it-systemet.
Kvalitetsplanen skal anvendes som et styringsværktøj, der gør at it-projektet løbende kontrol-
lerer og afdækker eventuelle svagheder i kvaliteten og aktivt kan handle, for dermed at øge
projektets succes.
Et konstant fokus på kvalitet forhindrer større tilbageløb og medvirker til, at projektet leveres
til tiden, inden for budgettets ramme og med den nødvendige funktionalitet til at møde bruge-
rens behov.
11.1 Kvalitetsplanlægning
It udviklingsprojektet har en stor afhængighed til de øvrige projekter i den programorganisa-
tion det tilhører.
Kvaliteten i den endelige udviklede it-løsning beror på rettidig kravstillelse og på kvaliteten af

disse krav. Kvaliteten af krav skal være høj både i forhold til deres faktiske indhold og i forhold
til at de er tilstrækkeligt holistiske, så den samlede mængde krav tilsammen harmonerer og
giver et tilstrækkeligt grundlag for det nye vurderingssystem. Disse opgaver ligger uden for
selve it-projektet.
Derfor er en stor mængde krav til kvalitetsplanlægning placeret uden for selve it udviklings-
projektet, men manglende kvalitet i disse led, gør it udviklingsprojektet sårbart.
Leverance/produkt Kvalitetskrav Kvalitetsaktivitet Kontroldato Ansvar

Plan. Det er en kri- Planlægningen vil Review af om pla- Løbende Projektstyringsen-
tisk succesfaktor, at kunne siges at være nerne har den hed og Product Ow-
projektet gennem- af god kvalitet, når nødvendige detal- ner Panelet (POP)*
føres til tiden, så en projektdeltagerne i jeringsgrad og
effektiv og omhyg- god tid er informeret præcision og af-
gelig planlægning er om og forstår ar- spejler status i
essentiel bejdsopgavers om- projektet
fang og tidsmæssige
udstrækning.
Juridiske produkter, At juridiske produkter Reviews og god- Løbende jfr. tids- Jurakontoret
herunder ny lov om er i overensstem- kendelser ifm. af- planen i kap. 8. Fx
ejendomsvurdering melse med loven og klaringer af kon- når udkast til lov
at systemtilpasnin- krete problemstil- om ny ejendoms-
gerne ligeledes er i linger. Dertil kom- vurdering sendes i
overensstemmelse mer ekstern hø- høring december
hermed. ringsproces 2015.
Procesbeskrivelse Alle processer skal Workshops med Alle processer er Proceskontoret
for ejendomsvurde- dokumenteres i et relevante parter udarbejdet til 1. juli
ring og klagehånd- processtyringsværk- Løbende reviews i 2015 i et accepta-
tering tøj. - Internt i belt niveau.
ICE
Processerne skal - SKAT Efter aftale med
være beskrevet på et UDV og SKAT UDV får de
tilstrækkelig niveau SKAT løbende materialet
som sikrer: Ejendom til orientering
- at afledte behov er - SANST
forståelige

- at afledte behov kan
prioriteres
Beskrivelse af den Alle krav til funktiona- Gennem verifice- Løbende under Proceskontoret
ønskede funktionalitet skal omsættes til ring og test i et sprints. (med bistand fra de
litet (systemkrav) user stories og doku- SCRUM-baseret øvrige kontorer)
menteres i projektets udviklingsforløb Plan for løbende
SCRUM værktøj. review fastlæg-
Med review af fag- gelse i forberedel-
Userstories dækker ligt ansvarlige i ICE sesperioden frem
de behov som forret- og hos SKAT og mod egenudvikling.
ningen har identifice- SANST
ret og sikrer, at lov- Der har været gen-
givning og norm Sparring og review nemført workshop
(fremadrettet) over- af eksterne konsu- med afklaring af
holdes. lenter forventninger til
Userstories skal for- beskrivelserne 30.
midle krav og behov Godkendelse i pro- april 2015. Disse
til løsninger på en en- jektorganisation. indarbejdes ved
tydig og forståelig udarbejdelse af
måde og skal inde- skabeloner til krav-
holde accepttestkrite- stillelse.
rier.
Prioritering af ud- Prioriteringen af og Panelmøder hver Løbende POP (med bistand af
viklingsønsker dermed rækkefølgen uge med fast dags- alle relevante vi-
på udvikling foretages orden og beman- denspersoner)
decentralt i et tvær- det med viden og
fagligt panel (POP)*, beslutningskraft.
der tilsammen sikrer,
at det altid er det
mest værdiskabende
funktionalitet, der pri-
oriteres højst.
Testaktiviteter og At testaktiviteterne Aftalte tests plan- I hver af de aftalte Proceskontoret, i
forløb afdækker om krav er lægges og gen- sprints som en del praksis Test Mana-
opfyldt og om syste- nemføres kvalifice- af agilt udviklings- ger (med bistand fra
mets funktionaliteter ret forløb- på relevant Product Owner og
er klar til ibrugtagning testniveau i hver Scrum Master).
Se også afsnit 7.4: interaktion dvs.:
”Test”  Komponent-
test
 Integrations-
test
 Systemtest
 Accepttest
Gennemførelse af
regressionstests ift.
tidligere udviklede
komponenter.
Dette vil være et
led i det sidste
sprint inden idrift-
sættelse af ny
funktionalitet.
Godkendelses-akti- At funktionaliteten Fastlæggelse af Før ibrugtagning af POP og Product Ow-
viteter svarer til forretnin- præcise overdra- hovedleverancer – ner (med bistand fra
gens behov, ønskede gelseskrav fokus på samlet ac- alle øvrige kontorer)
brugervenlighed, sik- cepttest og inte-
kerhed og perfor- Rapporteringskrav grationstests.
mance
Leverandørstyring At eventuelle eks- Løbende opfølg- Løbende Systemkontoret og
terne leverandører og ning på issues Projektstyring (med
konsulenter samt de

interne udviklere le- Eskalering af afvi- bistand fra ansvar-
verer inden for aftalt gelser i projektor- lige for funktions-
tid (sprints), økonomi ganisationen områder)
og kvalitet
Ændringshåndte- At ændringer og prio- Faste procedurer Løbende POP (med bistand
ring riteringer under for ændringshånd- fra Product Owner)
sprints altid vurderes tering
for deres konsekvens
for projektets tid,
økonomi og kvalitet
Interessenthåndte- At projektets interes- Kommunikations- Ca. 2 mdr. før Projektstyringsen-
ring senter er hørt og for- plan og interes- ikrafttrædelsesda- heden og Proces-
ventningsafstemt i sentanalyse re- toer for hovedleve- kontoret
hele projektperioden viewes af projekt- rancer
inkl. realiseringsfasen organisationen og
projektejer
Note: (*) Product Owner Panel (POP) er et tværfagligt prioriterings- og beslutningsorgan, jf. afsnit 9.3, der skal støtte
Product Owner med henblik på til enhver tid at afdække hvilke udviklingsopgaver, der har højest prioritet. Panelet etable-
res formelt i den igangværende forberedelse af egenudvikling.
11.2 Kvalitetskontrol
11.2.1 Intern kontrol
Projektet gennemføres i et agilt forløb (SCRUM), hvor der indbygget i konceptet er følgende
kvalitetsfremmende foranstaltninger:
 Daglig fælles gennemgang af arbejdsopgaver i udviklingsteamet (daily scrum meeting)

 Kort udviklingsperiode (2-4 uger), hvor en afgrænset funktionalitet færdigudvikles, gen-
nemtestes og demonstreres og godkendes af udpegede personer uden for udviklingstea-
met
 Løbende regressionstest af samspil hver gang en ny afgrænset funktionalitet færdigudvik-
les.
Der vil løbende foregå internt peer review af koden, ligesom større arkitektur beslutninger dis-
kuteres og evalueres i teamet. Større beslutninger vil typisk foregå via et POC (Proof Of Con-
cept) projekt, hvor det kan evalueres i praksis om en beslutning er praktisk gennemførlig, og
giver de forventede benefits.
I forbindelse med automatiserede builds køres en lint’er (eller static analyzer), der vil kunne
advare om duplikeret kode, ikke idiomatisk kode, for store funktioner etc. Sådanne tools kan
typisk udvides med ny funktionalitet, hvis der ønskes metrikker for ting, der ikke er dækket i
standard versionen.
Der vil jævnligt blive udført sikkerheds scanninger ved brug af tools som OpenVas eller Nes-
sus, der kan rapportere om systemet er sårbart, fx overfor specifikke angreb mod de versioner
af web eller proxy servere der benyttes, ligesom der laves automatiske port scanninger etc.
11.2.2 Ekstern kontrol

Det vil blive gennemført halvårlige reviews af et internationalt konsulentfirma, der er ledende
inden for den valgte teknologi og arkitektur. Dette vil inkludere kode og løsningsevaluering
samt mere generel sparring om arkitektur og teknologi. Hvert review vil blive afrapporteret i
en rapport, der beskriver projektets tilstand og indeholder forslag til forbedringer.
Det overvejes herudover at gennemføre sikkerhedsreview med bistand fra en ekstern partner,
der kan foretage penetrationstest af systemet ca. et halvt år før go-live og igen ca. 2 måneder
før, hvis der identificeres væsentlige problemer. Herefter vil der kunne gennemføres et review
1 gang om året, når systemet er i drift.

11.3 Kvalitetssikring
Ansvar / aktør Kvalitetssikringsrolle Forventet dato for kvalitetssikring
Digitaliseringsstyrelsen Eksternt review (forud for indmelding til  Maj/juni 2015
Statens IT-projektråd)
Statens IT-projektråd Risikovurdering af PID på grundlag af obli-  Maj/juni 2015
gatoriske dokumenter, der knytter sig til
den fællesstatslige it-projektmodel.
Styregruppe Overordnet ansvar for beslutninger. Skal  Løbende på styregruppemøder, der
sikre projektets kvalitet, fremdrift og suc- afholdes hver 14. dag
ces.
Programledelse Ansvar for den løbende kontrol af og rap-  Ugentlige møder
portering ift. projektets kvalitet, fremdrift
og succes til styregruppen
Projektets kvalitetsansvarlige Ansvar for, at der indkaldes til review af le-  Ved projektets kontrolpunkter
(Proceskontoret) verancer  Løbende
Udarbejdelse af kvalitetskontrolplaner i
samarbejde med kvalitetsinspektør
12 Risici
12.1 Risikoprofil
It-projektet vurderes overordnet set at have en høj risiko som følge af projektets kompleksitet
samt de afhængigheder og den ambitiøse tidsplan, som projektet er underlagt.
It-projektet indgår således som en del af et overordnet program, der skal tilvejebringe den
fornødne lovgivning, datagrundlag, modeludvikling, procesafklaringer mv. inden for en meget
ambitiøs tidsplan. Der er væsentlige interne afhængigheder mellem programmets projekter og
udviklingsaktiviteter, som indebærer en risiko for forsinkelser. Eksempelvis forudsætter sy-
stemudviklingen – det gælder både egenudvikling og outsourcing – en række juridiske og for-
retningsmæssige afklaringer, der som følge af tidsplanen må ske parallelt med it-udviklingen,
som er afgørende for, at systemet kan udvikles med den rette funktionalitet og adressere de
nødvendige behov. Tilsvarende er it-projektet også underlagt en del af de politiske risici, her-
under fx et ændret politisk mandat, der generelt er forbundet med lovgivningsarbejde. Endelig
indebærer valget af en egenudviklingsstrategi, at rekrutteringen og fastholdelsen af de nød-
vendige kompetencer in-house bliver en kritisk parameter, som det er væsentligt løbende at
have stort fokus på.
Derudover er der en række eksterne risici, der påvirker projektets generelle risikoprofil. Ek-
sempelvis må der påregnes væsentlige afhængigheder til datakilder og distributionssystemer,
fx BBR-registret og datafordeleren. Såfremt adgangen eller udviklingen heraf forsinkes eller
kompliceres vil det ligeledes påvirke projektets risikoprofil. Tilsvarende vil der ligeledes være
væsentlige afhængigheder og risici forbundet til de eksisterende systemer i SKAT og Skattean-
kestyrelsen, der skal bidrage til udviklingen og vurderingssystemet.
Se særskilt bilag med risikoregister.
Risikostyring
Projektet referer til programledelsen vedrørende styring og risikovurdering. Samlet set består
risikostyringen af tre roller:
 Risikoejer - har beslutningskompetencen for risikoens håndtering
 Risikoansvarlig - har faglig viden inden for det område risikoen vedrører
 PMO-funktion – faciliterer og bidrager til risikoprocessen
Proces for identificering af risici

Projektledelsen og PMO-funktion er ansvarlige for systematisk at gennemgå projektet med
henblik på identificering af risici. Alle projektdeltagere er ansvarlige for løbende at identificere
og rapportere risici i forbindelse med den daglige opgaveløsning. I den løbende dialog med de

vigtigste eksterne interessenter i og uden for SKAT (jf. afsnit om interessenter) vil disse blive
bedt om at oplyse, om de har kendskab til risici, der er relevante at håndtere i projektet. Når
en risiko er identificeret, udpeger projektledelsen en risikoansvarlig og en risikoejer.
Bearbejdning og håndtering
Den risikoansvarlige skal i samarbejde med PMO-funktion analysere risikoen. På baggrund af
konsekvensanalysen udarbejdes en afdæmpnings- eller beredskabsplan, der beskriver,
hvordan den enkelte risiko kan adresseres, for om muligt at eliminere eller begrænse
sandsynligheden for at risikoen indtræder, eller for at begrænse effekt/konsekvens.
Den risikoansvarlige indstiller til risikoejer, hvordan risikoen skal bearbejdes. Når planen er
lagt, er det den risikoansvarlige der har ansvaret for at planen bliver indarbejdet i projektets
samlede tidsplan, samt at aktiviteterne udføres.
Registrering
Projektets risici registreres i risikoregisteret. Risikoregisteret er et fælles dokument i projektet,
hvilket betyder, at alle har adgang hertil. Det er PMO-funktion, der har ansvaret for at ajourføre
og vedligeholde registeret.
Advarselssignaler
Projektet har defineret nogle advarselssignaler, der giver anledning til forøget opmærksomhed
i projektet (højt antal af nye risici, indtrufne risici siden sidst, ændringer i risicis værdier, tiden
for vigtig risiko er nær). PMO-funktion er ansvarlig for at gøre projektledelsen opmærksom på
registrerede advarselssignaler.
Rapportering til styregruppen

Der rapporteres til programledelsen og styregruppe ca. én gang månedligt, hvor programledel-
sen og styregruppen bliver præsenteret for projektets 5 væsentligste risici i en grafisk form,
hvoraf risikoens aktuelle værdi og udvikling fremgår. Derudover udvælger projektledelsen ef-
ter behov et antal af de mest aktuelle risici til behandling i programledelsen.
13 Informationssikkerhed
It-projektet gennemføres i regi af ICE, som hører under Skatteministeriets departement. It-
projektet er derfor omfattet af de politikker og retningslinjer for informationssikkerhed som
gælder i Skatteministeriets koncern. ICE er i færd med at etablere en intern informationssik-
kerhedsorganisation i overensstemmelse med disse retningslinjer.
Som del af denne etablering har ICE udpeget en informationssikkerhedsansvarlig, som har det
overordnede ansvar for informationssikkerhed i ICE, herunder det overordnede ansvar for in-
formationssikkerheden i it-projektet.
Herudover skal rollerne som henholdsvis dataansvarlig og én eller flere systemansvarlige be-
sættes.
I nedenstående figur vises sikkerhedsorganisationen i ICE, der har reference til kontoret for
Service og Sikkerhed, som varetager sikkerhedsfunktionen i departementet. Kontoret fører til-
syn med ICE, herunder med it-projektet.
Figur 13.1. Sikkerhedsorganisation i ICE

Roller pr. kontor
Service og
Sikkerhed
System
Model
Rolle Opgaver
Data
ICE
• Overordnet ansvarlig for informationssikkerhed
Sikkerhedsansvarlig Informations-
i ICE
sikkerheds
• Koordinerer informationssikkerhed i ICE
ansvarlig
• Udmønter standarder, politikker og instrukser
• Ansvarlig for at politikker og standarder
Systemansvarlig Systemansvarlig X X X implementeres i ETL-, beregnings- eller
systemløsning
• Ansvarlig for at sikkerhedsklassificere data,
godkende anvendelse af og adgang til data
• Stiller krav til sikkerhedsniveau for adgang til
Dataansvarlig Dataansvarlig X
data
• Håndterer kontakt til dataejere og anmeldelser til
Datatilsynet
13.1 Sikkerhedsmæssig risikovurdering

I forbindelse med etablering af systemudviklingsmiljøet i ICE har projektet gennemført en risi-
kovurdering i overensstemmelse med de retningsliner, som gælder i Skatteministeriets kon-
cern. Risikovurderingen konkluderer, at udviklingsmiljøet indeholder data af begrænset føl-
somhed og udelukkende anvendes af en begrænset kreds af projektdeltagere. Vurderingen an-
viser endvidere en række tekniske og organisatoriske foranstaltninger, herunder anvendelse af
stærk kryptering i forbindelse med adgang, lukning af alle unødvendige services og porte, sty-
ring af adgangsrettigheder, samt indsamling af logdata og løbende gennemgang af disse. Her-
ved etableres et samlet sikkerhedsniveau som er acceptabelt under hensyntagen til det vurde-
rede følsomhedsniveau for systemudviklingsmiljøet.
Informationssikkerhedsorganisationen i ICE har, når denne er fuldt etableret, til opgave at
evaluere denne analyse og anbefale eventuelle supplerende tiltag. Herefter påhviler det infor-
mationssikkerhedsorganisationen i ICE at evaluere sikkerheden i og omkring systemudvik-
lingsmiljøet periodisk samt i tilfælde af overførsel af nye data til miljøet.
I forbindelse med udarbejdelse af løsningsdesign til it-systemet stilles krav til informationssik-
kerhed i systemet, såvel teknisk sikkerhed som logning og brugerstyring. Udarbejdelse af
disse krav forestås af ICEs sikkerhedsorganisation med udgangspunkt i SKATs standarder,
men specifikationen tilpasses de data, som systemet skal behandle og de konkrete forret-
ningsprocesser, som systemet skal understøtte. Krav til informationssikkerhed er allerede ind-
tænkt i det grundlæggende design for den prototype ICE har udarbejdet.
Informationssikkerhedsorganisationen i ICE skal godkende løsningsdesignet, inden dette im-
plementeres og skal ligeledes godkende delleverancer inden disse tages i drift.
13.2 Konsekvensvurdering for privatlivet

ICE har gennemført en indledende analyse af konsekvenserne for privatlivet, hvis hovedkon-
klusioner gennemgås nedenfor.
Systemudviklingsmiljøet indeholder pt. ikke information, som direkte vedrører personer, men
udelukkende fysiske forhold ved ejendomme, og disse data er i vidt omfang allerede offentlig-
gjorte. Konsekvenserne ved misbrug af data fra udviklingsmiljøet vurderes derfor som stærkt
begrænsede.
ICE planlægger kun begrænset omfang egen indsamling af data til brug i udviklingsmiljøet.
Disse data har form af mægler/vurderingssagkyndiges skøn over værdien af udvalgte ejen-
domme foretaget ”fra kantstenen”. Disse indsamlede oplysninger har en skønsmæssig karak-
ter og vedrører endvidere et meget begrænset antal ejendomme. Derudover planlægges ind-

samling af rentabilitetsoplysninger fra professionelle udlejere. Da alle indsamlede data har ka-
rakter af ejendomsinformationer vurderes det, at en krænkelse af privatlivets fred vil have in-
gen eller ubetydelige konsekvenser.
Data opbevares i et centralt udviklingsmiljø, som kun kan tilgås af en lille kreds af udviklere,
hvilket bidrager til at begrænse risikoen i denne fase.
Resultatet af denne vurdering er, at den samlede konsekvensvurdering for projektet på nuvæ-
rende stade er lav.
I forbindelse med det videre arbejde forventes det, at systemudviklingsmiljøet vil komme til at
indeholde navne og CPR-numre på ejendommes ejere. Når disse data overflyttes til systemud-
viklingsmiljøet øges konsekvensscoren til mellem, idet den samlede konsekvensscore af pro-
jektet når 20. Med de tekniske tiltag opridset ovenfor under 13.1, samt supplerende kontroller
i form af instrukser til medarbejdere, tvungen kompleksitet i passwords, databehandleraftaler
med driftsleverandør og løbende kontroller af informationssikkerhedsorganisationen i ICE, vur-
deres det, at de risici der relaterer sig til konsekvenser for privatlivet kan håndteres tilfreds-
stillende.
Arbejdet med specifikation og design af it-systemet pågår pt. I forbindelse med formulering af
krav til systemet vil der blive gennemført en løbende konsekvensvurdering for privatlivet.
Dette arbejde forestås af den informationssikkerhedsansvarlige i ICE. Konsekvensvurderingen
fremlægges for projektets styregruppe i forbindelse med godkendelse af idriftsættelse af hver
delleverance i løsningen.
14 Interessenter
Projektets vigtigste interessenter fremgår af tabellerne nedenfor. Yderligere interessenter er
defineret særskilt. Projektet arbejder fokuseret med en interessenthåndtering.
Af nenestående tabel fremgår de vigtigste eksterne interessenter.
Priori- Vigtigste eksterne inte- Område af projektet Betydning for pro-

Holdning til projektet og
tet ressenter / målgruppe med særlig interesse jektet og evt. tiltag
mulig reaktion
til håndtering
1 Medarbejdere og ledelse  Brugervenlighed i det Stor interesse i realise-  Afgørende betyd-
i SKAT og SANST nye system og de til- ring af projektets ver- ning for realisering
hørende processer, sion, mål og gevinster af projektets vision
 Det nye vurderingsset- Ønsker et bedre vurder- – brugerne skal
up med udvidet mo- ingsset-up med tilhø- tage det nye sy-
delbaseret vurdering rende system- og proces- stem til sig
 Opfyldelse af projek- understøttelse, der giver  Inddragelse i alle
tets mål og realisering bedre vurderingsgrund- projektets faser
af de planlagte gevin- lag, mere tid til faglig  Tæt dialog og sam-
ster (se kap. 4 og 6) vurdering, mulighed for arbejde omkring
 Gennemførsel af forbedre kvalitet i vurderin- den nødvendige
andringsledelse og im- gen. forandringsledelse
plementering Samtidigt kan der for-  Deltagelse i pro-
 Rapportering og res- ventes (sagsbehandlere) jektets styre-
sourcestyring en vis modstand og skep- gruppe
 Nemt at vedligeholde sis i forhold til det nye
systemet, og at til- system med modelbase-
passe det til nye og rede vurderinger og
ændrede behov større transparens i for-
hold til den enkeltes per-
formance, ligesom pro-
jektets forventede effek-
tivitetsgevinster kan give
frygt for konsekvenserne
heraf for dem selv og de-
res kollegaer.

mulig reaktion
til håndtering
Nervøse for at blive lagt
ned af klager over de nye
ejendomsvurderinger.
2 Private boligejere og  Fokus på vurdering af Kritisk/skeptisk, afven-  Afgørende for rea-
ejere af erhvervsejen- egen ejendom og skat- tende med risiko for et lisering af projek-
domme (og interesse or- temæssig konsekvens. stort antal klager i for- tets vision, det er
ganisationer)  Kommunikation af længelse af de nye vur- ejendomsejernes
ejendomsvurdering og deringer tillid til vurderin-
vurderingsgrundlag gerne, der skal
 Adgang til korrektion genskabes
af vurderingsgrundlag  Håndteres via ef-
 Særligt interesseret i fektiv kommunika-
at få nedsat vurdering tion både generelt
gennem klage. i medierne (hånd-
teres via ICE pro-
grammet) og di-
rekte i forbindelse
med sikring af kor-
rekt vurderings-
grundlag og efter-
følgende transpa-
rent og velbegrun-
det ejendomsvur-
dering og informa-
tion om klagemu-
ligheder – fokus på
genskabelse af til-
lid og minimering
af klager.
 Inddragelse lø-
bende i projektets
arbejde via spørge-
panel
3 Regeringen (ØU)  At projektet leverer til  At projektet leverer til  Skal godkende
tiden tiden med tilstrække- grundlaget (lovgiv-
 At vurderingerne ac- lig kvalitet ningen og bereg-
cepteres af ejendoms- ningsmodeller) for
ejerne, så disse ikke det nye system
lægger klagesystemet  Løbende inddra-
ned og vurderingerne gelse via ØU
kan anvendes som
grundlag for opkræv-
ning af ejendoms- og
grundskatter
4 Kommunerne/KL  Anvender vurderingen  Vil være meget foku-  Dataleverandør,
som grundlag for op- serede på, at SKAT le- håndteres af Data-
krævning af grund- verer beskatnings- kontoret under ICE
skyld og ønsker bud- grundlag til tiden og i i samarbejde med
getsikkerhed – der pt. høj kvalitet Systemkontoret
trues af genoptagelser  Kan have den hold-  Ejer af en række
og lang sagsbehand- ning, at kommunerne vigtige systemsnit-
lingstid på klagesager. ikke har grundlag for flade, hvor det er
 Fokus på økonomisk at kunne administrere afgørende med
konsekvens af kla- grundskatteloftsreg- tæt koordinering
gerne og på, at det lerne og samarbejde
nye vurderingssystem  Kan have modsatret-
skal sikre et stabilt be- tede behov og interes-
skatningsgrundlag. ser i en række grund-
data fx BBR-oplysnin-
ger og lokalplaner,

mulig reaktion
til håndtering
 Fokus på systemløs- hvor de er ansvarlige
ninger, der giver sam- for opdatering som er
menhæng mellem tidskrævende og dyr,
kommunernes og men afgørende for
SKATs systemer og muligheden for at
processer (herunder sikre kvaliteten af vur-
administration af deringerne.
grundskatteloft, be-
regning af grundskyld,
adgang til og anven-
delse af fx BBR-data)
5 Digitaliseringsstyrelsen  Datamodel Interesserede i samar-  Tæt dialog med
 Integration til Datafor- bejde henblik på at sikre
deler og udstilling af koordinering af
vurderingsoplysninger tidsplaner m.v.
heri
Af nenestående tabel fremgår de vigtigste interne interessenter.
Priori- Vigtigste interne interes- Område af projek- Betydning for projektet

Holdning til projektet
tet senter / målgruppe tet med særlig in- og evt. tiltag til håndte-
og mulig reaktion
teresse ring
1 Styregruppen  At projektet le- Tror på at projektet kan  Afgørende for at sikre
verer til tiden i lykkes i en kombination mandat og rammer
tilstrækkelig af egenudvikling og ud- for gennemførsel af
kvalitet til at un- bud af afgrænsetfunkti- projektet
derstøtte reali- onalitet  Kommunikation om
seringen af pro- fremdrift og løbende
grammet vision demonstration af sy-
stemet skal betrygge
og sikre rettidig invol-
vering
2 Projekt: juridiske og for-  At systemet ud- Forventer at projektet  Afgørende med så
retningsmæssige afklarin- vikles så lovgiv- sikrer en fremtidsikret korrekt og præcis
ger ningen er over- og fremsynet systemun- kravstillelse som mu-
holdt derstøttelse med opfyl- ligt for at undgå fejl-
 At de forret- des af de forretnings- udvikling og tilbageløb
ningsmæssige mæssige krav via løsnin-  Fokus på opstart af
krav til system- ger udviklet i tæt dialog tæt og åbent samar-
udviklingen op- mellem systemydvik- bejde allerede ved
fyldes lingsprojektet og den kravformulering og
forretningsmæssige fortsættelse heraf
kravstillelse inkl. udveksling af pro-
ces- og forretnings-
analytikere mellem de
to projekter
3 Dataprojekterne i ICE  Datamodel Forventer tæt samar-  Afgørende med tæt
 Datainfrastruk- bejde om at lykkes med samarbejde og koordi-
tur forbedret og transpa- nering
 Datakvalitet rent dataanvendelse i
det nye system
4 Modeludviklingsprojek-  Modelintegra- Forventer at resultatet  Afgørende med tæt
terne i ICE tion at det store modelud- samarbejde og koordi-
 Deltagelse i udviklingsarbejdet under- nering
vikling af støtte- støttes af effektivt sy-
værktøjer stem til videreprocesse-
ring af modelresulta-
terne. Ønsker at bistå

med viden fra modelud-
viklingsarbejdet ved ud-
vikling af støtte- og kon-
trolværktøjer til den
manuelle kontrol og
vurdering.
15 Kommunikation
Kommunikation i forbindelse med it-projektet er en integreret del af kommunikationen for det
samlede ICE-program. Udgangspunktet er, at det ikke kun er et nyt it-system, der skal imple-
menteres, men et helt nyt ejendomsvurderingssystem, hvor en stor del af vurderingerne base-
res på modelberegnede værdier og en ny lovgivning. Det er derfor valgt ikke at udarbejde en
selvstændig kommunikationsplan knyttet til it-systemudviklingen.
Strategi for den nødvendige forandringsledelse og herunder implementering, uddannelse og

kommunikation er endnu ikke fastlagt, men planlagt til efteråret 2015, jf. afsnit 10.3 ovenfor.
Den overordnede kommunikationsstrategi for ICE vil skulle koordineres med behovene for for-
andringsledelse og den tilhørende kommunikation i SKAT og Skatteankestyrelsen.
I afsnit 3 om scope og afgrænsninger er det anført, at kampagnen om de nye ejendomsvurde-

ringer ligger udenfor scope, og at der vil blive planlagt og gennemført landsdækkende kam-
pagneaktiviteter i samarbejde med kommunikationsenheder i Skatteministeriet og SKAT, der
ikke indgår i it-projektet.
Endelig er kommunikation også medtaget som et element i afsnit 4 om mål og succeskriterier,

hvor der blandt andet er sat fokus på en effektiv håndtering af borgerdialogen og transparente
og gennemskuelige vurderingsmeddelelser. Dette afspejler sig også i afsnit 14 om interessen-
ter, hvor et særligt fokusområde er kommunikation med boligejere og ejere af erhvervsejen-
domme.
16 Tolerancer
Efter et indledende forløb med udvikling af en prototype af it-systemet har styregruppen for
ICE besluttet, at it-projektet mest hensigtsmæssigt kan gennemføres som egenudvikling med
udbud af afgrænsede funktionaliteter.
Da it-projektet primært forventes at blive gennemført som egenudvikling, kan den normale fa-
seinddeling i projektinitieringsdokumentet ikke anvendes på samme måde som i et it-projekt,
der helt eller delvist sendes i EU-udbud. Der udmeldes derfor udelukkende ét budget og en
tidsplan for gennemførselsfasen, hvor det konkrete it-system udvikles. Budgettet er fordelt
hen over gennemførelsesfasens år.
Toleranceområde Råderum for projektleder

Projektudgifter: Projektets samlede budget og budgettet for hvert år: Ingen tolerance.
Allokering af budget mellem it-projektet og øvrige områder i ICE samt inden for den
samlede projektperiode: Programchefen kan efter drøftelser med projektlederen og
kontorcheferne i ICE disponere over det godkendte budget for såvel it-projektet som
den øvrige del af ICE, så længe det ikke påvirker det overordnede budget for ICE som
helhed.
Programchefen for ICE og afdelingschefen for koncernstyring kan disponere igangsæt-
telse af opgaver på op til 500.000 kr., mens opgaver herudover forudsætter forelæg-
gelse for departementschefen.
Interne ressourcer: Projektets samlede ressourcetræk og ressourcetrækket for hvert år: Ingen tolerance.
Allokering af ressourcer mellem it-projektet og øvrige områder i ICE samt inden for den
samlede projektperiode: Programchefen kan efter drøftelser med projektlederen og
kontorcheferne i ICE frit disponere de godkendte ressourcer for såvel it-projektet som

den øvrige del af ICE, så længe det ikke påvirker det overordnede ressourcebudget for
ICE som helhed.
Tid: Leverancer, der er nødvendige for at sikre, at vurderingen i 2018 og 2019 kan gennem-
føres: Ingen tolerance.
Øvrige leverancer uden større, forretningsmæssige konsekvenser og inden for budget
og kvalitet: Programchefen kan efter drøftelse med projektlederen og relevante kontor-
chefer i ICE ændre i rækkefølge eller leveringstidspunkt for leverancer.
Kvalitet: Kvaliteten af leverancer, der påvirker præcisionen af vurderingen i 2018 og 2019: Ingen
tolerance.
Øvrig kvalitet: Programchefen kan godkende ændringer uden større forretningsmæssig
konsekvens og uden væsentlig påvirkning af budget/tid.
Afvigelser og ændringer Styregruppen orienteres om vigtige afgivelser og ændringer, der ligger inden for pro-
godkendes af: gramchefens tolerancer.
Afvigelser/ændringer, der påvirker projektets overordnede budget, skal godkendes af
departementschefen efter indstilling fra styregruppen. Styregruppeformanden kan god-
kende eventuelle ekstrabevillinger, der ikke kan afvente departementschefens godken-
delse.
17 Rapporteringskrav
Rapport/produkt Modtager Formål Frekvens
Statusrapportering på it- Programledelsen Følge op på status Ugentligt.

projektet for it-projektet,
drøfte væsentligste
udeståender og af-
klaringer samt koor-
dinere centrale leve-
rancer.
Statusrapportering på it- Styregruppe Følge op på status Hver anden uge.
projektet for it-projektet.
Ressourceallokering Programledelsen Vurdering af de til- Ca. hver anden uge.
gængelige ressour-
cer.
Risikovurdering Programledelsen og styre- Identificere og vur- Ca. én gang månedlig
gruppen dere relevante risici
med henblik på at
drøfte og igangsætte
eventuelle mitige-
rende og korrige-
rende handlinger.
Halvårlig afrapportering Statens IT-projektråd Orientering om frem- Marts og september
drift og udvikling i
projektets risikoprofil
Orienterende aktstykker Folketingets Finansudvalg Orientering om pro- Orientering ifm. overgang
Afhænger af de forventede jektets fremdrift til drift samt projektstatus
udviklingsomkostninger til samt økonomiske di- i øvrigt.
it-projektet. spositioner.
Orientering om projektets
drift og effekter ca. et år
efter overgang til drift.
Projektafslutningsrapport Styregruppe Give styregruppen et Ved afslutning af projek-

grundlag for at be- tet.
slutte, om projektet
skal afsluttes.
Statens IT-projektråd Skal deklarere over Sker gennem den halvår-

for IT-projektrådet, lige statusrapportering,

at projektet er afslut- hvor der ved projektafslut-
tet. ningen statusrapporteres
for sidste gang.
Slutevaluering Statens IT-projektråd For at skabe åbenhed Ved afslutning af projek-
om såvel statslige tet.
myndigheders som
it-leverandøres erfa- Slutevalueringen er et
ringer med projekt- skema til at samle op på
samarbejdet gen- erfaringerne fra de gen-
nemføres en evalue- nemførte it-projekter, så
ring, der offentliggø- kunde-leverandør-samar-
res. bejdet fremadrettet styr-
kes.
18 Revisionshistorik
Revisions- Version Ændringer Ændringer markeret? Forfatter
dato
19 Bilag
Målhierarki for ICE programmet – til kapitel 4
Milepæle og projektplan for hele ICE programmet – til kapitel 8 og 10.5.
Milepæle og projektplan for it-projektet for 2015 – til kapitel 8 og 10.5.
Risikoregister (produktbilag C) – til kapitel 12
Privatlivsvurdering – til kapitel 13

20 Produktbilag C: Risikoregister
[Dobbeltklik på ikonet nedenfor og åbn risikoregisteret i Excel. Risikoregisteret kan også
downloades som separat Excel-fil.]
ProduktRisikoregister
2.1 (Produktbilag C i PID).xlsx


Language

PID 2015 Ejendomsvurderingsprojekt

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PID 2015 Ejendomsvurderingsprojekt

Uploaded by

Copyright:

Available Formats

Projektinitieringsdokument (PID)

12. maj 2015

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen

2 FORRETNINGENS FORMÅL MED PROJEKTET .............................................. 2

3 SCOPE OG AFGRÆNSNINGER .................................................................. 7

4 MÅL OG SUCCESKRITERIER ..................................................................... 8

5 ØKONOMISKE HOVEDTAL OG FINANSIERING ............................................ 10

7 TEKNISK LØSNING ................................................................................ 14

20 PRODUKTBILAG C: RISIKOREGISTER ....................................................... 43

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [1]

2 Forretningens formål med projektet

2.1 Den nuværende situation (baggrund)

Udvalget anbefalede endvidere, at vurderingsprocesserne fremadrettet så vidt muligt bør være

Regeringen etablerede med afsæt i Ekspertudvalgets anbefalinger et nyt Implementeringscen-

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [2]

Figur 2.1. Systemdiagram for ejendomsvurderingsområdet

BBR VUR/ESR (Kommuner)

Udskrivning af vurd. medd. (PDF)

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [3]

2.2 Formålet med projektets løsning og bidrag til strategiske mål

Et nyt it-system er en forudsætning for at udvikle et nyt ejendomsvurderingssystem, der er

1. Den daglige drift med gennemførelse af ejendomsvurderinger samt den efterfølgende

Forbedring af datakvaliteten og indsamling af data, fastlæggelse af de kommende vurderings-

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [4]

2.3 Den fremtidige situation efter indførelse af løsningen

Figur 2.3. Overblik over hoved- og delprocesser i den fremtidige ejendomsvurdering

De primære slutbrugere er sagsbehandlerne i SKAT og Skatteankestyrelsen (herefter SANST).

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [5]

I projektets løbetid er der planlagt store ændringer i grunddataregistrene på ejendomsområ-

2.4 Situationen hvis projektet ikke gennemføres (business as usual)

Endelig vil omlægningen af systemlandskabet på ejendomsområdet hos andre myndigheder

2.5 Alternative løsningsscenarier

3Afrapportering. Fremtidigt administrationsgrundlag for værdiansættelse af ejendomme. Sammenfatning.

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [6]

2.5.2 Tilpasning af standardrammesystemer

Deloitte Consulting har gennemført en analyse af en lang række standardrammesystemer for

Skatteministeriet har på den baggrund vurderet, at standardrammesystemer ikke er en reali-

Systemet skal således understøtte vurderingsprocesserne og videreformidle vurderingerne til

Forbedring af datakvaliteten og indsamling af data, fastlæggelse af de kommende vurderings-

Udenfor scope (afgrænsning) Begrundelse for afgræsning

Lovgivningen udgør dog den vigtigste eksterne afhængig-

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [7]

Det skal understreges at arbejdet med etablering af nyt ejendomsvurderingssystem – og her-

Projektets mål Beskrivelse Succeskriterier

For at understøtte bedst mulig data- Brugertilfredshed (ejendomsejere) stigende

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [8]

Da datakvalitet er en stor udfordringer,

Reduceret tidsforbrug ved manuel sagbe-

Effektiv håndtering af Effektiv proces- og systemunderstøt- Brugertilfredshed (ejendomsejere) på min x%

Tidsforbrug på håndtering af borgerhenven-

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [9]

Lavt uddannelsesbehov (x-timer pr. medar-

Korte sagsbehandlingstider (effektivt og ka-

5 Økonomiske hovedtal og finansiering

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [10]

Det samlede udgiftsbaserede budget for egenudvikling et vist i nedenstående tabel.

Risikopuljen udgør 10 pct. af de samlede budgetterede udviklingsudgifter. Puljen er fastsat

Det omkostningsbaserede budget er i vist i nedenstående tabel.

Finansieringen af de samlede udgifter på 81,8 mio. kr. skal afklares nærmere.

Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [11]

6.1 Strategi for gevinstrealisering

Figur 6.1. Gevinstdiagram for udvikling og implementering af nyt it-system

5 Det er uafklaret, i hvilket omfang driftsopgaven sendes i udbud.