It-professor Søren Lauesen: EFI hang alt for dårligt teknisk sammen med tilknyttede it-systemer (podcast)

16. oktober 2015 kl. 16:172
Professor Søren Lauesen, IT Universitet, påpeger i Version2 Podcast, at en af de tekniske svagheder i EFI var, at snitfladen mellem søstersystemerne Debitormotor inddrivelses-systemet DMI og EFI var udviklet med forskellige datamodeller. Det er en del af årsagen til, at systemet nu må skrottes.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

En af de uheldige tekniske forhold bag det nu skrottede EFI-system fra Skat er, at det var opbygget af to systemer, der var meget afhængige af hinanden, men som alligevel var usammenhængende rent teknisk. Nemlig det, der hedder debitor-motor-systemet og selve EFI.

Årsagen til dette skal søges i at det ene system blev udviklet af KMD mens det andet af CSC.

»Det med, at man vil have flere leverandører, handler om, at man vil undgå monopol. Men nu får vi så to monopoler, der skal samarbejde. Nogle gange går det også ok. Men i EFI's tilfælde, var snitfladen mellem de to systemer lagt meget uheldigt,« siger Søren Lauesen i Version2s podcast.

Det ene system tager sig af at registrere fordringer, og det andet af at opkræve dem, der ikke er blevet betalt.

Version2 Podcast, episode #2: Dårlig teknisk sammenhæng i EFI

Skats skandaleramte it-system EFI kom aldrig til at fungere. Men hvad gik der egentlig galt, og er der noget, vi kan lære i forhold til offentlige it-systemer, så det ikke sker igen.

Du finder XML-feedet til Version2's podcast her

Og bruger du iTunes, kan du klikke her

Du kan også høre podcasten direkte i din browser via Soundcloud i bunden af denne artikel.


»Det er altså de samme data, de arbejder på. Men de er ikke enige om datamodellen. Og det betyder, at data, der er i de to systemer, kan være ude at trit med hinanden.«

Opdateringer forvirrede systemerne så data var uforståelige

Systemerne udveksler pga. den indbyrdes afhængighed konstant data. Men når det ene system er ved at opdatere noget, og det andet spørger hvad situationen er, så kan de altså komme til at kigge i et resultat, som modparten ikke kan forstå.

Artiklen fortsætter efter annoncen

»Så der er inkonsistens mellem systemerne, og det giver jo også anledning til en masse fejl. Det er utroligt svært at teste sådan noget.«

Med til at komplicere situationen var, at det var Skat som definerede snitfladerne. Hvis man absolut vil have to leverandører ind, er det ifølge it-professoren ikke heldigt, at det er Skat der sidder og definerer, hvordan snitfladen skal se ud.

»De tror, de kan definere det, og at de er rigtigt smarte. Men det kan de nok ikke.«

Hvem skal gøre det?

Artiklen fortsætter efter annoncen

»De skal de to parter gøre. Det ender alligevel med at være dem, der skal forhandle de sidste ting på plads. Men i dette tilfælde kan jeg ikke se, der havde været noget som helst problem ved at nøjes med én leverandør.«

Få hele forklaringen i Version2’s podcast om tekniske svagheder i EFI.

Vi tager gerne imod ris/ros og forslag til nye afsnit på redaktion@version2.dk Du kan høre podcasten direkte i din browser via Soundcloud i bunden af denne artikel eller ved at abonnere på vores xml-feed i din foretrukne podcast-klient:

2 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
19. oktober 2015 kl. 22:33

Fuldkommen enig. Det giver slet ikke mening ikke at have deffineret modeller for udvekslingen og regelsæt herom.

Hvis det VIRKELIG er en hovedforklaringer på fejlene i EFI, så er det jo helt galt. Tror nok at man skal tilbage til runestenen, hvis man ikke kan løse den slags udfordringer....

1
19. oktober 2015 kl. 12:40

Det er set før, men leverandører der ikke er indbyrdes kontraktigt forpligtede, har per definition ikke noget samarbejde ! Det er derfor spm. om ikke begge kontrakter - DBM og EFI burde have tilfaldet samme leverandør. ELLER, at SKAT havde udviklet en 3'dje parts model, i begge kontrakter, der tvinger parterne til at levere indbyrdes, (måske) med SKAT som Service Integrator. Og i dette tilfælde med denne artikel kommer der sikkert Agile folk strømmende til og vil dømme vandfaldsmodellen ude ! Men det er for sent, I skulle have været der ca. 2007...