Lise Gerd Pedersen

Jeg skulle have været humanist...

Den første it-chef jeg stødte på som relativ nyuddannet it-kandidat i mit første konsulent projekt proklamerede på det første møde vi havde "jeg ved intet om teknologi og det er jeg glad for".

En anden variant: En karismatisk direktør for en offentlig styrelse udtalte til mig (i 2001), at den IT-direktør, han netop havde ansat, ikke vidste noget om IT, men det var heller ikke nødvendigt, for direktøren himself havde programmeret lidt på sin ingeniøruddannelse og vidste derfor alt, hvad styrelsen havde behov for at vide om digitalisering ...

Jeg lavede på det tidspunkt masterprojekt på MPA uddannelsen om offentlige IT-skandaler sammen med to offentlige chefer. De var meget imponerede af denne direktør og hans udtalelse, og jeg havde lidt svært ved at få dem til at forstå, hvorfor jeg ikke var.

9. oktober kl. 09:46
Jeg skulle have været humanist...

Det bedste er selvfølgelig en lang, grundig og relevant uddannelse. Men man kan komme langt i IT-branchen med en kortere grunduddannelse, mesterlære og masser af efteruddannelse. I 80'erne arbejdede jeg sammen med folk, der var kommet ind fra gaden på baggrund af en IQ-test med så forskellige tidligere beskæftigelser som bager, maskinarbejder, brandmand osv. Det væsentlige er, om man har flair for at tænke stringent og logisk og er villig til at arbejde for at lære nyt. At gå efter at ansætte færdiguddannede humanister er uddannelsessnobberi ... og hvor er det dog spild af samfundsressourcer at uddanne så mange humanister, som ikke kan få arbejde inden for deres eget fag. Det værste er næsten, at jeg har oplevet mange af disse omskolede humanister have en selvforståelse, som lå langt fra deres reelle kompetencer ... men de var jo kandidater!

6. oktober kl. 11:54
Leder: Statens it-projekter løber fuldstændig løbsk

I 2000-2002 læste jeg MPA (Master of Public Administration) på CBS. Da jeg jo var IT-menneske, valgte jeg at fokusere på "offentlige IT-skandaler" - for det var meget oppe i tiden dengang ;-). Der er ikke sket meget på de 20 år ...

Jeg vil koge problemet ned til:

  • Først og fremmest digitaliserer vi for meget. Hvis man realistisk regnede ud, hvad det koster at udvikle, drive og ikke mindst vedligeholde IT-funktionalitet, er der meget, der aldrig skulle have været udviklet. Men det er sjovere og giver mere status at være fadder til digitalisering end at smøge ærmerne op og bare udføre det kedelige arbejde. Derfor underbudgetterer man mere eller mindre bevidst, så business casen hænger sammen.
  • Fordi vi digitaliserer for meget, sætter vi skibe i søen, vi ikke kan bemande forsvarligt. Det handler kun delvis om lønninger, for der findes simpelt hen ikke tilstrækkelig mange dygtige folk på markedet. Sætter staten sine lønninger op, risikerer man bare at give flere penge for tvivlsomme ressourcer. Selvfølgelig findes der dygtige folk i staten, men jeg har ofte set, at man ansætter, hvad man kan få - blandt andet fordi de, der ansætter, ikke altid er i stand til at vurdere de reelle kompetencer. Der er en udbredt tro i staten på, at enhver akademiker - også humanister - nok kan styre et IT-projekt eller kan fungere som IT-arkitekt. Hvis jeg vil lave en tilbygning til mit hus, og der ikke er ledige tømrere på markedet, hyrer jeg altså ikke en ledig slagter til opgaven. Så må jeg vente, til tømreren får tid.
  • Vi har et kæmpe efterslæb af gamle systemer, som er udokumenterede og teknisk forældede. Nye systemer skal ofte integrere til disse, og det er en svær opgave. Det er i hvert fald umuligt at prissætte integrationer på forhånd, når leverandørerne ikke aner, hvad de er oppe imod - og kunden kan ikke beskrive det, hvis dokumentationen af de gamle systemer mangler. Det samme gælder konvertering af data fra et gammelt system til et nyt - en ofte undervurderet udfordring, da eksisterende data kan være af svingende kvalitet.
  • Som én længere oppe i tråden skrev, så er det en udbredt misforståelse i ledelseslaget, at man bare kan købe og tilpasse et standardsystem. Ja, hvis opgaven er standard, men der skal ikke tilpasses meget, før det er en meget dyr og dårlig løsning frem for at udvikle selv (gerne OVEN PÅ mindre, afgrænsede standardkomponenter, som evt. kan udskiftes hen ad vejen). Standardsystemer kommer med den pris, at man får en stor leverandørafhængighed og årlige udgifter til licenser i al fremtid ... det vil sige, det skal jo i genudbud en gang imellem, og hvis en ny leverandør vinder, skal man til at starte forfra med tilpasning, datakonvertering, implementering osv.
6. juni kl. 14:16
Hård kritik af ny digitaliseringsstrategi: Urealistiske tidsplaner og underfinansierede projekter

Det er en interessant tanke at sammenligne IT porteføljen med fysisk infrastruktur så som veje og broer.

Der ofres store summer på vedligeholdelse af veje og broer ... simpelt hen fordi det er endnu dyrere at lade stå til. Forud for beslutning om et vedligeholdelsesarbejde går en løbende monitorering af tilstanden. Man kører rundt med målebiler på vejnettet hvert år for at registrere fx huller, sporkøring og ujævnheder samt udfører regelmæssige tilsyn af bygværkerne. Man opgør behovet for vedligeholdelse, hvorefter man ansøger og får tildelt midler på finansloven. Derefter prioriterer man de bevilgede midler til de veje og broer, der trænger mest, og gennemfører vedligeholdelsen.

Tilgangen til vedligeholdelse af IT porteføljen har indtil nu været helt anderledes. Det har aldrig været politisk appetitligt at budgettere med midler til at holde gamle IT-systemer i luften (fx ved løbende at modernisere dem). Det er sjovere at profilere sig ved at digitalisere nye områder. Tænk, hvis man i enhver business case på et nyt system havde indregnet en realistisk årlig vedligeholdelse af systemet (10-20%?) og afsat disse midler i budgetterne. Det ville nok i mange tilfælde have tippet balancen for, hvornår det kunne betale sig at digitalisere en arbejdsopgave.

De gennemførte IT-kasseeftersyn (2017/2018) resulterede mig bekendt ikke i flere penge til de enkelte myndigheder. Tværtimod har det for hver myndighed kostet store summer at registrere og vurdere alle IT-systemer samt udfærdige IT handlingsplaner. Penge, der skulle tages ud af eksisterende budgetter.

I Digitaliseringsstrategien står under vision 7: "Det offentlige it-landskab er i dag at betragte som kritisk infrastruktur på linje med fx vores broer, der binder landet sammen. Det betyder, at systemerne skal efterses og fremtidssikres på samme måde, som når vi løbende vedligeholder vores veje og broer. Offentlige myndigheder skal derfor løbende udvikle og modernisere deres offentlige it-løsninger og sikre, at nye teknologier tages i brug."

Ord er taknemmelige. Men bemærk, at der (så vidt jeg kan se) ikke er nogen af de 61 initiativer i Digitaliseringsstrategien, der understøtter ovenstående. Det skulle da lige være initiativ 50, hvor der bl.a. står: " Et analysearbejde skal kortlægge statens it-opgaver og -udgifter med henblik på at komme med anbefalinger til styrket styring af statens it-udgifter". Jeg troede, at det var det, statens IT-kasseeftersyn 2017/2018 og Statens It-råd løbende allerede havde gennemført?

Tænk, hvis det var formuleret som et højt prioriteret initiativ i Digitaliseringsstrategien, at vi skal have styr på IT-porteføljen og indfri den tekniske gæld. Tænk, hvis man estimerede de nødvendige midler til at indhente efterslæbet og afsatte dem på Finansloven. Tænk, hvis man nedlagde gamle systemer og gik tilbage til manuelle arbejdsgange, hvor det (når man indregner vedligeholdelsen) ikke kan betale sig at holde en IT-løsning i luften.

Måske det var vigtigere at få ryddet op efter mange års forsømmelse end hovedparten af de 61 visionære initiativer?

16. maj kl. 10:21
Ny kedelig rekord: Hvert fjerde statslige it-projekt får rødt lys af Statens it-råd

Man skulle måske overveje, om ikke man igangsætter alt for mange store, ambitiøse og komplicerede projekter i forhold til de ressourcer/kompetencer, man kan disponere over.

Jeg har i min tid i statsligt regi set mere end en gang, at når ikke man får kvalificerede ansøgninger til en IT-stilling (eller den ansættende myndighed ikke kan gennemskue, hvad det er for kompetencer, man har brug for), ansætter man, hvad man kan få - bare de er akademikere, nærmest uanset fag. Og når de så ikke kan løse de konkrete opgaver, hyrer man konsulenter.

Hvis jeg vil lave en tilbygning til mit hus, venter jeg, til der er ledige bygningshåndværkere at få. Jeg hyrer ikke en slagter til opgaven.

Og hvis manglen på kompetente IT-folk er sagens kerne, så virker det da lidt tumbet at afvise ansøgere til IT-uddannelserne.

3. november 2021 kl. 11:04
It-koks i Skattestyrelsen: Kan ikke lave statistik over momsindbetalinger

hvis man sammenligner med effektiviteten for > 50 år siden

Det er et rigtigt godt spørgsmål - ikke kun i forbindelse med SKAT.

Tag for eksempel en driftsopgave i det fri (renhold, græsslåning eller lignende). I stedet for at ansætte nogen til simpelthen at udføre arbejdet, skal opgaven udbydes på det frie marked. Det kræver udbudsjurister og andet godtfolk til at kravspecificere og evaluere tilbud. Leverandørne skal bruge tid på at skrive et tilbud, hvilket alt andet lige fører til højere priser. Realistiske tilbud på renhold/græsslåning osv. forudsætter, at arealernes størrelse er kendt. Derfor digitaliserer du dem - den opgave skal også udbydes - og udvikler et IT-system - som også skal udbydes og efterfølgende implementeres og holdes i luften. Desuden skal der ansættes folk til at føre tilsyn med, om leverandøren nu lever op til kravspecifikationen, og hvis ikke skal der føres sager om bod osv.

Tænk, hvis man bare ansatte folk og gav dem et distrikt, de havde ansvar for?

15. september 2021 kl. 12:50
Offentlige midler, offentlig kode!

Men hvorfor SKAL man håndtere de henvendelser ? Det må hver anvender selv beslutte om det giver mening for dem.

For mange af de statslige systemer er der kun 1 (en) anvender. Hvis denne statslige institution ikke håndterer henvendelser, hvad er pointen så? Spørgsmålet er, om den i henhold til forvaltningsloven overhovedet kan undlade at registrere og besvare henvendelser?

Husk også, at staten sjældent udvikler noget selv. Det er outsourcet til leverandører. Så det vil ikke være statsansatte, der kan spare en konsulenttime ved selv at trykke på en merge knap (som Jesper skrev i #27).

Generelt kan jeg sagtens se fordelene ved open source - men de forudsætter efter min mening, at der er mere end én anvender af koden.

17. maj 2021 kl. 13:25
Offentlige midler, offentlig kode!

Du skriver også udtrykkeligt at "Det kan ikke undgå at fordyre projekterne".

Okay, så prøver jeg at udtrykke mig mere præcist: Det kan ikke undgå at påføre projekterne omkostninger til at håndtere og vurdere henvendelser. Om der er besparelser, der opvejer disse omkostninger, skal jeg ikke kunne sige. Skal vi stoppe ordkløveriet her?

16. maj 2021 kl. 11:31
Offentlige midler, offentlig kode!

Det er da i hvert fald en antagelse, er det noget du kan dokumentere/underbygge?

Håndteringen af henvendelser vil kræve ressourcer - det vil du vel ikke betvivle? Jeg skriver jo udtrykkeligt, at jeg ikke kan vurdere, om fordelene berettiger det. Omkostningerne skal bare ikke overses.

15. maj 2021 kl. 22:47
Offentlige midler, offentlig kode!

Men er det nødvendigt og eller nyttigt at koden er lukket?

Måske ikke. Men før man offentliggør koden, bør man overveje, hvem der skal behandle henvendelser fra borgere, konkurrenter mv. om kodekvalitet, mistanker om fejl (også fra folk, der ikke kan gennemskue koden) osv.. samt hvor mange ressourcer man vil og kan afsætte til det. Det kan ikke undgå at fordyre projekterne. Om fordelene vil opveje det, skal jeg ikke kunne sige.

15. maj 2021 kl. 16:43
Offentlige midler, offentlig kode!

både du og Lise Gerd var dumpet på stedet, hvis i en eksamenssituation sagde den slags vrøvl, med mig som censor

René, jeg håber, at du læste min blog, inden du dumpede mig offentligt. Min udtalelse havde ikke noget som helt med open source at gøre, men var i konteksten standardsystemer / specialudvikling.

15. maj 2021 kl. 11:59
Hvad skal staten stille op med sine gamle IT-systemer?

Ja, Torben - det var sådan, man i bagklogskabens ulideligt klare lys skulle have gjort. Men mange af systemerne er udviklet, før det var almindelig praksis. Det kan være uhyggelig svært at dekomponere et system, der er en stor portion spaghetti - og det er du nødt til, før du kan modernisere modul for modul.

12. maj 2021 kl. 12:49
Hvad skal staten stille op med sine gamle IT-systemer?

uden samtidig at løbe en stor risiko for at ende som en grå mus i hjørnet af et uhjælpeligt projekt og uden tilstrækkeligt med karrieremæssig udvikling indenfor rækkevidde

Jeg tror, at du rammer hovedet på sømmet her. Selv om man kan se samfundsværdien i at udvikle offentlige IT-systemer, kan man blive demotiveret af håbløse projekter og faglig inkompetent ledelse.

12. maj 2021 kl. 12:46
Hvad skal staten stille op med sine gamle IT-systemer?

Tak, Peter. Du har ret i, at der er positive udviklinger, og dem vil jeg heller ikke underkende. Men det er kun toppen af isbjerget at implementere standardsystemer for det, der vitterligt er standardopgaver (ESDH, økonomi, timeregistrering osv.).

Min erfaring med ESDH-systemerne (som i sin tid vandt FESD-kontrakterne) og Navision Stat for år tilbage var i øvrigt, at de ikke havde API og var svære at integrere med. Sådanne systemer skal jo netop kunne ligge som services i bunden (som Klavs skriver), så man kan bygge institutionsspecifik funktionalitet ovenpå. Måske er det blevet bedre siden.

FDA og de fællesoffentlige komponenter peger alle i den rigtige retning. Det løser dog ikke problemet med den del af isbjerget, der gemmer sig under vandet. Institutionsspecifikke, gamle fagsystemer.

12. maj 2021 kl. 12:41
Regeringen vil poste milliarder i digitalisering: »En meget markant satsning«

Husk, at der gennem de sidste 40 år er udviklet masser af systemer, hvoraf en del stadig er i drift. Den tekniske gæld er en tikkende bombe og vil lægge beslag på mange resurser de kommende år. Det er ikke så sexy politisk at tale om, men det er et faktum.

Husk også, at der skal nogen til at udføre de ambitiøse planer. Der er behov for langt flere konkrete IT-kompetencer, end der for tiden kan opdrives på markedet. Hvad med at skrue op for optaget på datamatikeruddannelsen og ITU på bekostning af brødløse fag?

17. marts 2021 kl. 10:14
URL'ens historie: Opfinderen fortrød, at han kopierede Apollo-løsningen

Vi havde sådan en arbejdsstation på Værdipapircentralen midt i 80'erne med et case-værktøj installeret. Jeg var systemadministrator på den. Når der kom ny version af operativsystemet, skulle man indlæse et par og tyve 8-tommer floppy disks (der kunne være 256k på hver). Og så havde den en mus - sådan en med en gummibold - det var helt nyt!

7. maj 2020 kl. 20:45
URL'ens historie: Før 1982 var der ingen domæne­navne. Så fik Arpanet vokse­værk

I 1983 skrev jeg og et par andre en opgave med titlen "Computernetværk nu og i fremtiden" som afslutning på et datanommodul. Vi beskrev bl.a. teknikken bag Arpanet og EURONET. Afslutningsvis skulle vi komme med nogle bud på fremtiden. Det var oplagt at foreslå, at man kunne sammenkoble de to net. Men vi skulle jo også være visionære, så vi foreslog, at man med tiden kunne udvikle et "verdensomspændende datanetværk". Vi syntes selv, at det var virkelig morsomt ... og troede selv ikke et øjeblik på det. Opgaven blev i øvrigt afleveret delvist håndskrevet ... det kunne man dengang.

22. april 2020 kl. 21:39
Professor om forsinket gælds-it: Ufornuftigt kun at benytte agil udvikling

Bravo, Henrik. Det har altid undret mig, at journalister så ukritisk refererer professorer ved de højere læreanstalter som "eksperter" i, hvordan den virkelige verden fungerer - også selv det er længe siden, de sidst har befundet sig i den. Hvis der er teori og empiri bag deres udtalelser, så er den akademiske titel relevant - ellers er det falsk varebetegnelse.

12. september 2019 kl. 08:15
Tusindvis af bilister har ikke fået klip i kørekortet på grund af it-bøvl hos Rigspolitiet

Er vedligeholdelsen af POLSAS ikke overgået fra DXC (CSC) til IBM? Kan det tænkes, at den nye leverandør har svært ved at finde ud af, hvor de skal rette i koden? Kunne det skyldes et gammelt, knopskudt system og måske manglende dokumentation?

9. august 2019 kl. 10:41
Lær at leve med knopskydende it-systemer

Artiklen indeholder efter min mening rigtig mange fornuftige synspunkter. Jeg vil gerne fremhæve dette:

Vores udgangspunkt er, at identificere hvor virksomheden reelt har brug for at være unik, og hvor virksomheden kan anvende noget som er standard og billigt

En ofte forekommende misforståelse på ledelsesniveau er, at man kan købe et standardsystem til noget, som absolut ikke er standard. Det kan blive en meget dyrere og dårligere løsning end selv at udvikle oven på standardkomponenter.

9. august 2019 kl. 10:32