Med købet af Mjølner Informatics forventer Accenture, at cirka 400 specialister fra Mjølner Informatics bliver en del af Accenture Danmark. Mjølner Informatics er et dansk it-hus med speciale i software, digitalisering og end-to-end-løsninger med hovedsæde i Århus og kontorer i Silkeborg, Fredericia, København og Madrid.   

Mjølner Informatics har siden virksomheden blev grundlagt i 1988 været kendt for at omsætte kunders komplekse udfordringer til konkrete it-løsninger. Virksomheden arbejder strategisk med digital engineering herunder AI og softwareudvikling.

Opkøbet betyder samtidig, at Norlys og Accenture bygger videre på det strategiske partnerskab, der allerede er etableret i forbindelse med integrationen af Telia Danmark ind i Norlys. Accenture skal fremover også løse en række af de digitale udviklings- og it-opgaver, som Mjølner Informatics hidtil har løst for Norlys.   

Med Accenture som partner får Norlys adgang til større skala, international erfaring og kompetencer inden for blandt andet modernisering af it-platforme, kunstig intelligens, cybersikkerhed og udvikling af digitale kunderejser. Det understøtter Norlys’ ambition om at være en teknologidrevet virksomhed, der tager ansvar for de forbindelser, kunderne og samfundet er afhængige af. 

Transaktionens vilkår er ikke offentliggjort. Gennemførelsen af opkøbet er underlagt sædvanlige betingelser og betinget myndighedernes godkendelse. 

Om Accenture  

Accenture er en globalt ledende partner inden for reinvention, forretningsudvikling og digital transformation. Med knap 800.000 medarbejdere globalt kombinerer vi dyb brancheindsigt, avancerede teknologier og stærke partnerskaber i vores økosystem for at hjælpe verdens største virksomheder med at gentænke og fremtidssikre deres forretning.  

Vores tilgang er forankret i en ansvarlig og målrettet brug af AI med fokus på at skabe forretningsværdi og drive en sikker og bred anvendelse af AI. Vi dækker hele spektret af virksomhedens behov: fra cybersikkerhed og digital transformation til finans, supply chain, teknologi og talent.  

Accenture har cirka 9.000 kunder globalt og realiserede en omsætning på ca. 70 mia. USD i regnskabsåret 2025.  

Gert Vinther Jørgensen, Group CEO i Norlys sammen med Jakob Kaad, Mette Steffensen og Peter Jørgensen fra Accenture Leadership samt Brian Gottorp Jeppesen, CEO i Mjølner

Når et styringssystem bliver utilgængeligt, en leverandøradgang svigter, eller et anlæg ikke kan styres som forventet, bliver OT-sikkerhed hurtigt et spørgsmål om drift, ansvar og beslutningskraft.

For energi- og forsyningsselskaber handler OT-sikkerhed derfor ikke kun om at beskytte systemer. Det handler om at sikre, at de vigtigste funktioner kan fortsætte, når noget går galt. Derfor bør ledelsen starte med de scenarier, der kan ramme driften hårdest.

Dette er tredje indlæg i vores serie om OT-sikkerhed i energi- og forsyningssektoren. I de to første indlæg satte vi bl.a. fokus på, hvorfor OT-sikkerhed er blevet et ledelsesanliggende, og hvorfor OT ikke kan håndteres med samme logik som klassisk IT-sikkerhed.

Har du ikke læst dem endnu, er de et godt sted at starte:

Når IT og OT mødes: 3 klassiske fejl ledelsen skal undgå

Nye risici, nye krav: 5 råd om OT-sikkerhed til ledelsen

Med det afsæt bevæger vi os nu fra erkendelse til praksis. For når ledelsen først har forstået, hvorfor OT-sikkerhed kræver en anden tilgang, bliver det afgørende spørgsmål:

Hvordan arbejder man konkret med OT-risiko i praksis?

Perspektiverne i indlægget bygger på erfaringer og anbefalinger fra Mjølners domæneeksperter inden for energi- og forsyningssektoren, Jakob Hviid og André Bryde Alnor, samt vores partner Jørgen Hartig fra SecuriOT. De arbejder med sikkerhed, drift og digitalisering i miljøer, hvor robusthed, oppetid og ansvarlige beslutninger er afgørende.

Mange organisationer starter med det, der er lettest at få øje på: fysisk sikring, adgangskontrol, netværkssegmentering eller enkelte tekniske kontroller. Alt sammen relevant. Men ikke nødvendigvis dér, hvor risikoen er størst.

Hvis OT-sikkerhed skal skabe reel værdi, bør ledelsen starte med et andet spørgsmål:

Hvad kan i praksis stoppe eller alvorligt påvirke vores evne til at levere?

Det spørgsmål flytter arbejdet fra generelle sikkerhedstiltag til konkrete scenarier, ledelsen kan prioritere, teste og handle på.

Start med det, der absolut skal fungere

Et godt udgangspunkt for OT-sikkerhed er ikke en lang liste af tekniske tiltag. Det er et mere grundlæggende ledelsesspørgsmål:

Hvilke funktioner skal absolut fungere, for at vi kan levere vores kerneydelse?

For OT-sikkerhed handler ikke først og fremmest om at beskytte teknologi. Det handler om at beskytte organisationens evne til at fungere. Om at sikre, at strøm, varme, vand eller produktion kan opretholdes – også når noget går galt.

Det er en afgørende forskel. For hvor IT-sikkerhed ofte tager udgangspunkt i adgang, data og systembeskyttelse, tager OT-sikkerhed i høj grad udgangspunkt i driftens evne til at fortsætte – også når noget fejler.

Jakob Hviid, Senior Solution Architect hos Mjølner, peger på den samme grundlæggende forskel mellem de to verdener. Hvor IT ofte kan reagere på en hændelse ved at lukke ned, isolere eller ændre systemer hurtigt, er præmissen en anden i OT:

Først når de kritiske funktioner er tydelige, giver det mening at se på, hvilke systemer, netværk, leverandører, processer og supportfunktioner der understøtter dem.

Flyt fokus fra anlæg til konsekvenser

Mange organisationer er vant til at tænke i aktiver:

• Hvilke anlæg/systemer er dyrest?
• Hvilke komponenter er sværest at erstatte?
• Hvad er teknisk mest komplekst?

Det er relevante spørgsmål. Men de er ikke tilstrækkelige. En mere moden tilgang er at flytte fokus fra anlæg og komponenter til konsekvenser:

• Hvad sker der, hvis en essentiel funktion svigter
• Hvad sker der, hvis et centralt system er utilgængeligt i flere døgn?
• Hvad sker der, hvis en leverandørforbindelse forsvinder på det forkerte tidspunkt?
• Hvad sker der, hvis en fejl i ét system forplanter sig til andre dele af driften?

For ledelsen giver det et stærkere beslutningsgrundlag. Når konsekvensen er tydelig, bliver det lettere at prioritere de indsatser, der faktisk reducerer risikoen mest.

Konsekvenserne stopper ikke ved OT-miljøet

En OT-hændelse rammer sjældent kun ét system eller ét anlæg. Den kan påvirke hele værdikæden omkring drift, produktion, fejlretning og genopretning.

Det ser vi ofte i praksis. Mange har et godt overblik over deres fysiske anlæg, men mindre overblik over de afhængigheder, der ligger rundt om anlægget.

Det kan være ordreflow, leverandøradgange, supportprocesser, dataudveksling, interne arbejdsgange eller nøglepersoner, som viser sig at være afgørende, når noget går galt.

Derfor er det ikke nok at spørge, om OT-miljøet er beskyttet. Ledelsen må også spørge:

Hvilke dele af værdikæden er driften afhængig af – og hvor hurtigt kan vi komme tilbage til stabil drift, hvis de svigter?

Byg få scenarier, der virkelig gør ondt

En af de mest brugbare tilgange er også en af de mest enkle: Start ikke med alt. Start med nogle få scenarier, som vil have alvorlige konsekvenser, hvis de bliver virkelighed.

Det er et godt råd, fordi det tvinger organisationen til at prioritere. I stedet for at forsøge at kortlægge enhver tænkelig risiko kan ledelsen begynde med et begrænset antal hændelser, som vil have alvorlige konsekvenser for drift, forsyning, sikkerhed eller omdømme.

Det kan for eksempel være scenarier som:

• Et centralt styringssystem er utilgængeligt i flere døgn
• En ekstern leverandør mister adgangen til et kritisk miljø
• Et anlæg kan ikke styres som forventet
• En hændelse i ét system påvirker andre dele af driften
• En nøgleperson eller kritisk supportfunktion er utilgængelig under en hændelse

Scenarierne behøver ikke være perfekte fra starten. Det vigtige er, at de er konkrete nok til, at organisationen kan begynde at stille de rigtige spørgsmål.

Gør tid til en del af risikoen

Et scenarie bliver langt mere anvendeligt, når man tilføjer tid.

Det er én ting at sige, at et system kan gå ned. Det er noget andet at spørge, hvad det betyder, hvis det er nede i 24, 48 eller 72 timer. Så bliver risikoen konkret: Hvor længe kan funktionen være påvirket, før det rammer forsyning, sikkerhed eller drift? Hvilke nødprocesser kan holde driften i gang imens? Og hvilke leverandører, reservedele eller nøglepersoner er afgørende for at komme tilbage til stabil drift?

Brug scenarierne til at prioritere rigtigt

Når de vigtigste scenarier er tydelige, bliver det lettere at afgøre, hvilke investeringer der faktisk reducerer risikoen mest.

Det kan være tekniske kontroller, bedre overblik over OT-landskabet, strammere styring af leverandøradgange, beredskabsplaner, test, reservedele eller klare beslutningsveje under en hændelse.

Det afgørende er, at prioriteringen tager udgangspunkt i konsekvensen for drift og forsyning – ikke kun i, hvad der er lettest at implementere.

Jakob sætter ord på forskellen sådan her:

I OT er det netop opretholdelsen af værdikæden, der må være styrende.

OT-risiko kræver flere perspektiver

Scenariearbejdet kan ikke løftes af én funktion alene.

Der skal være tydeligt ejerskab, men arbejdet bliver først stærkt, når flere relevante perspektiver bringes i spil. OT-risiko opstår sjældent ét sted. Den opstår i samspillet mellem anlægsdrift, IT, leverandører, beredskab og forretning.

Derfor bør scenarierne ikke kun vurderes af OT-specialister. De bør gennemgås sammen med de funktioner, der skal handle, hvis scenariet bliver virkelighed.

For ledelsen er opgaven at sikre en struktur, hvor de relevante fagligheder arbejder sammen om at vurdere risiko, konsekvens og handlemuligheder. Ellers risikerer OT-sikkerhed at blive enten et isoleret specialistprojekt eller et risikoregister uden reel betydning for driften.

Fra bekymring til beslutning

OT-sikkerhed bliver først for alvor værdifuld, når det går fra at være et diffust bekymringspunkt til at blive en måde at træffe bedre beslutninger på.

Det er netop det, scenarietænkning kan.

Den hjælper organisationen med at fokusere på det, der betyder mest. Den gør risiko konkret. Den skaber et fælles sprog mellem ledelse, drift og specialister. Og den gør det lettere at prioritere både investeringer og indsatser.

Ledelsen kan starte med fire spørgsmål:

1. Hvilke funktioner skal absolut fungere, for at vi kan levere vores kerneydelse?
2. Hvilke 5-6 scenarier vil ramme driften hårdest?
3. Hvor længe kan vi tåle, at centrale systemer eller leverandørforbindelser er utilgængelige?
4. Hvem ejer ansvaret for at teste, prioritere og følge op?

Det vigtigste er ikke at finde alle svar på én gang.

Det vigtigste er at komme i gang med de få scenarier, der virkelig betyder noget. For når de står klart, bliver det også tydeligere, hvilke systemer, processer, leverandører og beslutninger der faktisk er kritiske.

Hos Mjølner hjælper vi energi- og forsyningsselskaber med at omsætte OT-risiko til konkrete scenarier, prioriteringer og beslutningsgrundlag, som både ledelse, drift og specialister kan handle på.

Når IT og OT smelter sammen, findes der sjældent én standardløsning. Tag en uforpligtende snak med André om, hvordan I kan styrke OT-sikkerheden uden at gå på kompromis med drift og oppetid.

E-mail

Telefon

Du har fået en ny kollega på kontoret. Hun er utrættelig, hurtig og ekstremt selvsikker. Agentic coding kan føles som en ny juniorudvikler på teamet, men hun opfører sig ikke som dem af kød og blod. Så hvordan får du styr på sikkerheden, inden du giver din nye kollega nøglerne til alt det, du selv har adgang til?

Der er et stort potentiale i agentic coding, men der følger også risici med. For når vi giver AI-agenter adgang til at kode, giver vi dem i praksis også adgang til en række systemer, beslutninger og handlinger, der kan få konsekvenser, hvis man ikke har styr på sit setup.

I blogindlægget forklarer Lead Security Engineer Mads Schaarup Andersen, hvor organisationer bør starte, før AI-agenter bliver en fast del af udviklingsmiljøet.

Kom i gang!

Det kan virke som en banal pointe, men overraskende mange organisationer kommer i problemer, fordi de ikke kommer i gang rettidigt. Som leder kan du være helt sikker på, at der allerede er medarbejdere, der er i fuld gang med at benytte agentic coding – uanset om du er klar eller ej.

AI-politikker og trusselsmodellering er en proces, der kommer til at udvikle sig over tid. Hvis I beslutter jer for at bygge et forkromet rammeværk, inden I involverer jeres medarbejdere, er I helt sikkert allerede bagud.

Forstå trusselmodellen

Med AI som partner bevæger vi os ind i nyt land. Og som enhver anden opdagelsesrejsende er du nødt til at kortlægge det territorie, du er ved at udforske. Derfor bør I starte med en trusselmodel: Hvad skal beskyttes, hvem eller hvad kan kompromittere det, og hvad er konsekvensen, hvis det sker?

Start med at få en forståelse for, at der faktisk er mange komponenter i spil, når I laver agentbaseret kodning. Der er modellen (LLM’en), man forbinder til, der er ressourcer i lokalmiljøet på udviklermaskinerne, agent-plugins, MCP-servere, custom-agenter og skills – bare for at starte et sted. Som udgangspunkt kan agenten tilgå alle dele af setup’et, men spørg jer selv, om det er hensigtsmæssigt?

Det er også vigtigt at tænke i ondsindet manipulation. En agent kan ikke kun påvirkes af det, brugeren skriver direkte. Den kan også blive påvirket af bl.a. såkaldte injection attacks, hvor ondsindede instruktioner bliver tilføjet til workflowet fra fx et manipuleret plugin eller en manipuleret hjemmeside.

Opkvalificér og involvér udviklere

Selv de bedste regler og sikkerhedsværn virker kun, hvis udviklerne forstår, hvorfor de findes, og hvordan de skal bruges i hverdagen. Derfor er det organisationens ansvar at klæde udviklerne på til at arbejde sikkert med agentic coding. Og så er det altafgørende for succesen (og sikkerheden), at udviklerne bliver involveret i processen:

Det handler blandt andet om at lære udviklere at genkende risici som prompt injection, usikre plugins, ukritisk package-installation, deling af secrets og for brede rettigheder. Brug anerkendte ressourcer som OWASP, interne guidelines og konkrete eksempler fra jeres egne udviklingsmiljøer, så sikkerheden bliver praktisk og relevant.

Samtidig bør udviklerne vide, hvornår de skal stoppe op og bede om godkendelse – for eksempel før agenten får adgang til nye tools, eksterne services, produktionsdata eller credentials.

Etabler governance og risikostyring

Når AI-agenter får adgang til dit udviklingsmiljø, er det ikke nok at stole på, at de opfører sig korrekt, eller at den enkelte udvikler selv har styr på alle risici. I skal som organisation sætte rammerne i form af governance: klart definerede regler for, hvilke skills, plugins, MCP-servere og CLI-værktøjer der må bruges, og hvordan de installeres og administreres.

En god tommelfingerregel er at opfatte agenten som enhver anden del af jeres software supply chain: Det skal vurderes, godkendes, opdateres og kunne fjernes igen, hvis de viser sig at udgøre en risiko.

Implementér sikkerhedsværktøjer og sandboxes

Governance sætter rammerne. De tekniske sikkerhedsværn skal håndhæve dem i praksis. Brug f.eks. sandboxes, containere eller isolerede udviklingsmiljøer, så agenten ikke frit kan læse hele filsystemet, ændre kritiske filer eller køre kommandoer uden begrænsning.

Sikkerhedsscanninger, agent hooks og approval gates kan hjælpe med at stoppe risikable handlinger, før de sker. Det kan for eksempel være krav om menneskelig godkendelse, før agenten installerer packages, ændrer CI/CD-konfiguration, bruger secrets, sletter filer, pusher kode eller forsøger at tilgå produktionsmiljøer.

Sikkerhedsfunktionerne skal ikke kun slås til én gang. De bør testes løbende, så I ved, om de faktisk stopper de handlinger, de er sat op til at forhindre.

Opsummering: Fem sikkerhedsanbefalinger, der får jer i gang

Mads’ vigtigste pointe er, at agentic coding med stor hast er på vej ind i udviklingsmiljøerne. I mange organisationer er det allerede i brug – måske også i jeres. Derfor kan arbejdet med sikkerhed, governance og risikostyring ikke vente. Start her:

• Kom i gang nu. Vent ikke på det perfekte rammeværk. Sæt retning, forventninger og rammer, mens I lærer og tilpas løbende.
• Start med trusselmodellen. Få overblik over, hvad der skal beskyttes, hvilke data der flyder hvorhen, hvilke komponenter der indgår i jeres setup, og hvor noget kan gå galt.
• Opkvalificér og involvér udviklerne. Sikkerheden skal passe til den måde, udviklerne faktisk arbejder på. Derfor skal de med fra start – både som brugere, sparringspartnere og medskabere af rammerne.
• Sæt klare rammer for governance og risikostyring. Det bør ikke være op til den enkelte udvikler at vurdere, hvilke plugins, MCP-servere, skills, CLI-værktøjer eller eksterne services der er sikre nok.
• Håndhæv rammerne med tekniske sikkerhedsværn. Brug sandboxes, containere, sikkerhedsscanninger, agent hooks og approval gates, så agenten ikke frit kan tilgå filer, credentials, produktionsdata eller kritiske systemer uden kontrol.

Det er i første omgang organisationens og ledelsens ansvar at skabe de sikre rammer. Ikke den enkelte udviklers. For agentic coding kommer til at fylde mere, og de organisationer, der kommer i gang nu, står stærkere end dem, der først reagerer, når AI-agenten allerede har fået nøglerne.

Mads runder af med en opfordring til at huske, at alle ikke har samme udgangspunkt:

Fleksibelt elforbrug kan give store gevinster for samfundet, når vi flytter noget af forbruget væk fra de tidspunkter, hvor elnettet er mest presset. Det er hovedkonklusionen i to nye rapporter, der sætter spot på, hvorfor forbrugsfleksibilitet kan spille en afgørende rolle i den grønne omstilling. 

Den ene rapport fra CIP Foundation undersøger de strukturelle rammer, potentialer og samfundsøkonomiske gevinster ved fleksibelt elforbrug. Her peger rapporten blandt andet på, at en gennemsnitlig husstand kan spare op mod 11.000 kroner om året ved at flytte sit forbrug til de tidspunkter, hvor prisen på strøm er lavest.  

Mjølner har sammen med Alexandra Instituttet bidraget med den anden rapport ‘Et grønnere og mere fleksibelt elforbrug’, der går tættere på det digitale fundament, som skal gøre fleksibiliteten mulig i praksis. Her har vi analyseret de digitale løsninger og tekniske forudsætninger, der kan aktivere forbrugsfleksibilitet på tværs af elbiler, solceller, husstandsbatterier og varmepumper. 

Leverandører af fleksibilitetsydelser lykkes faktisk allerede i dag med at styre mange forskellige fleksible enheder og anvender forskellige tekniske arkitekturer til at håndtere data- og teknologiudfordringer. Til gengæld viser analysen, at de forskellige fleksibilitetsløsninger optimerer på forskellige parametre.  

Styringslogikken for de enkelte enheder er ikke designet til at blive koordineret på tværs. Det skaber kort sagt et hjem fuld af enheder, der hver især optimerer efter egne mål, men ikke nødvendigvis efter pris eller elnettets behov for fleksibilitet. Når enhederne ikke er koordineret, risikerer de endda at modarbejde hinanden. 

Hvad gør man så? 

8 anbefalinger til en robust skalering af forbrugsfleksibilitet – kort fortalt

Analysen viser, at der er et stort potentiale i at gøre det lettere at koble mindre, fleksible enheder på energisystemet – til gavn for både forbrugerne og elnettet. 

Men teknisk integration kan ikke stå alene. Anbefalingerne skal også ses i lyset af tre vigtige hensyn: digital suverænitet, cybersikkerhed og risikoen for teknologisk forældelse. 

Derfor kan en række gode principper for teknologiudvikling skabe fundamentet for de mere tekniske anbefalinger: 

1. Undgå at blive afhængige af enkelte leverandører 
   Varmepumper, batterier og elbiler er ofte afhængige af producenternes egne cloudløsninger og lukkede styringssystemer. Det kan skabe afhængighed af enkelte leverandører og gøre løsningerne sårbare, hvis teknologien, servicen eller leverandøren ændrer sig. Derfor bør markedet understøtte flere leverandører, åbne løsninger og reel mulighed for at skifte leverandør. 

2. Prioritér europæiske og åbne løsninger, hvor det er muligt
   Europæiske aktører og open source-løsninger kan være med til at styrke digital suverænitet og reducere afhængigheden af enkelte udenlandske teknologileverandører. Det kræver dog, at løsningerne reelt kan drives og videreudvikles uafhængigt – ikke blot videresælger lukkede tjenester fra andre.
3. Giv bedre mulighed for lokal styring og frakobling
   Enheder bør så vidt muligt kunne fungere uden konstant forbindelse til producentens cloud eller fjernstyring. Åbne API’er, lokale styringsmuligheder og dokumenterede integrationsflader gør det lettere at bevare kontrollen, også hvis en cloudtjeneste ændres, lukkes eller ikke længere er tilgængelig.
    
4. Skab større transparens om teknologiafhængigheder 
   Mange forbrugere, kommuner og andre professionelle aktører har ikke nødvendigvis overblik over, hvilke afhængigheder og cyberrisici, der følger med en løsning. Derfor kan uafhængige audits og tydelig dokumentation gøre det nemmere at vælge robuste løsninger og undgå skjulte afhængigheder. 

5. Tænk længere end den næste softwareopdatering 
   Mange fleksible enheder har en levetid på 10-20 år, mens software, cloud-API’er og kommunikationsstandarder kan ændre sig langt hurtigere. Derfor skal løsningerne bygges, så de kan opdateres, vedligeholdes og integreres med nye systemer over tid.

6. Gør det lettere at koble løsninger sammen 
   Hvis forbrugsfleksibilitet fra mindre enheder skal skaleres, er der brug for mere fælles og standardiserede integrationsprotokoller. Det vil gøre det lettere for leverandører at udvikle løsninger, der fungerer på tværs af forskellige brands og typer af enheder.

7. Byg sikkerhed og robusthed ind fra begyndelsen 
   Når flere mindre enheder kobles sammen og kan styres fleksibelt, bliver cybersikkerhed endnu vigtigere. Derfor bør der være klare krav til adgangsstyring, databeskyttelse, sikre opdateringer, netværksadskillelse og dokumenteret systemrobusthed.

8. Brug europæiske standarder og initiativer aktivt 
   Europæiske initiativer, fælles standarder, dataformater og protokoller kan være med til at skabe mere åbne og interoperable løsninger. Jo flere aktører der bruger dem, desto større værdi får de for markedet som helhed. 

 
Det danske elnet er ingen ø 

Når Danmark skal styrke forbrugsfleksibiliteten, bør vi se ud over vores egne grænser. Mange af de tekniske rammer og markedsprincipper, der skal få fleksible enheder til at spille sammen med energisystemet, er allerede under udvikling internationalt – ikke mindst i EU. Derfor er det vigtigt, at danske løsninger bygges, så de kan passe ind i de fælles europæiske spor, frem for at ende som isolerede systemer, der senere skal laves om. 

Det stiller krav til den måde, vi designer de digitale services på. De skal kunne justeres og videreudvikles, når lovgivning, standarder og teknologier ændrer sig. Ellers risikerer vi at låse os fast i løsninger, der hurtigt bliver dyre at vedligeholde eller svære at koble sammen med resten af markedet. 

Samtidig peger analysen på, at næste skridt ikke først og fremmest handler om mere data. Det handler i højere grad om bedre fælles spilleregler for, hvordan enheder, styringssystemer, fleksibilitetsleverandører og energisystemet kan tale sammen. Her bliver standardisering, interoperabilitet og åbne integrationsmuligheder afgørende. 

De elektriske små enheder, vi har i hjemmene, kan ende med at spille en stor rolle i fremtidens elnet. Men det kræver, at løsningerne fra begyndelsen udvikles med blik for sikkerhed, digital kontrol og lang levetid. 

Læs mere i de to rapporter

Forbrugsfleksibilitet som fundament for den grønne omstilling

CIP Foundations rapport præsenterer indsigter og anbefalinger fra et omfattende analyseprojekt med formålet at beskrive muligheder og barrierer for at aktivere forbrugsfleksibilitet helt ude på villavejene. Rapporten kommer med 10 anbefalinger for at fremme forbrugsfleksibilitet i den danske elnet. Læs rapporten her.

Et grønnere og mere fleksibelt elforbrug

Mjølner Informatics har i samarbejde med Alexandra Instituttet analyseret de digitale løsninger, der kan aktivere forbrugsfleksibilitet på tværs af elbiler, solceller, husstandsbatterier og varmepumper. Der findes allerede digitale løsninger, men landskabet er fragmenteret og det fulde potentiale bliver langt fra udnyttet i dag. Rapporten indeholder 8 generelle anbefalinger til at fremme fleksibilitet, sikre digital suverænitet og cybersikkerhed samt undgå teknologisk forældelse. Derudover rummer rapporten 7 tekniske anbefalinger, der peger på konkrete tiltag til at fremme forbrugsfleksibilitet i praksis. Læs rapporten her.

Vi hjælper aktører i energi- og forsyningssektoren med at udvikle digitale løsninger, der styrker drift, overvågning, integrationer og markedsprocesser – og som kan skaleres i takt med den grønne omstilling.

E-mail

Telefon

Mange energi- og forsyningsvirksomheder har de senere år løftet deres arbejde med cybersikkerhed betydeligt. Men i takt med at data, integrationer og digitale værktøjer rykker tættere på den fysiske drift, opstår en ny ledelsesudfordring:

Hvordan skaber man sikkerhed, når IT- og OT-systemer ikke længere kan tænkes hver for sig?

Netop det spørgsmål fylder mere og mere i energi- og forsyningssektoren, hvor digitale løsninger i stigende grad bliver en del af den kritiske drift. Og i takt med at afhængighederne mellem IT og OT vokser og får større betydning for den kritiske drift, bliver det tydeligt, at klassiske IT-greb ikke altid fungerer efter hensigten i OT-miljøer.

Tværtimod kan sikkerhedstiltag, der giver god mening i administrative systemer, skabe nye problemer, når de flyttes direkte over i produktion og drift.

Perspektiverne i indlægget bygger på erfaringer og anbefalinger fra Mjølners domæneeksperter inden for energi- og forsyningssektoren, Jakob Hviid og André Bryde Alnor, samt vores partner Jørgen Hartig fra SecuriOT.

I et tidligere indlæg har vi samlet 5 konkrete råd til ledelsen om OT-sikkerhed. Det kan du læse her.

I dette indlæg fokuserer vi på 3 klassiske fejl, ledelsen bør undgå, når IT og OT mødes.

1. At behandle OT som almindelig IT-sikkerhed

Den første fejl er at antage, at OT kan sikres med den samme værktøjskasse, som man bruger i IT.

Det virker umiddelbart logisk. Hvis noget handler om cyber, må IT-sikkerhed være det naturlige svar. Men der er en afgørende forskel: i IT handler sikkerhed typisk om at beskytte data, brugere og systemer. I OT handler sikkerhed i høj grad om at holde driften kørende, sikre oppetid og undgå, at fejl eller angreb får fysiske konsekvenser.

OT-sikkerhed er altså ikke kun et spørgsmål om at beskytte sig mod malware eller uautoriseret adgang. Det handler også om at sikre, at virksomheden kan fortsætte sin drift, når noget går galt:

Det er en afgørende forskel. For hvor IT-sikkerhed ofte tager udgangspunkt i adgang, data og systembeskyttelse, tager OT-sikkerhed i høj grad udgangspunkt i driftens evne til at fortsætte – også når noget fejler.

Jakob Hviid, Senior Solution Architect hos Mjølner, peger på den samme grundlæggende forskel mellem de to verdener. Hvor IT ofte kan reagere på en hændelse ved at lukke ned, isolere eller ændre systemer hurtigt, er præmissen en anden i OT:

Jørgen peger på, at klassiske IT-krav kan skabe nye risici, hvis de overføres direkte til OT. Han nævner et eksempel fra en virksomhed, hvor en streng passwordpolitik også blev gjort gældende på produktionslinjen, så operatører i treholdsskift skulle logge ind med lange passwords på et HMI-interface. I en administrativ IT-kontekst kan det virke fornuftigt. Men i en driftssituation, hvor der skal handles hurtigt, kan det få den modsatte effekt:

Jørgens pointe er enkel: Et stærkt passwordkrav kan være fornuftigt i et administrativt system, men skabe en ny risiko i en kritisk driftssituation, hvor en operatør skal kunne reagere hurtigt. Når en sikkerhedskontrol designes ud fra IT-logikken alene, kan den komme i konflikt med OT’s virkelighed.

Det betyder ikke, at klassiske IT-kontroller er forkerte. Men det betyder, at de ikke kan kopieres direkte over i OT uden at blive vurderet i den rette kontekst.

For ledelsen er læringen klar: Sikkerhed i OT skal vurderes ud fra konsekvensen for drift, oppetid og fysisk sikkerhed – ikke kun ud fra, om kontrollen ser rigtig ud på papiret.

2. At undervurdere, hvordan integration mellem IT og OT ændrer risikobilledet

Den anden fejl er at se integration mellem IT- og OT-systemer som en ren gevinst.

I praksis giver integration store fordele. Data fra anlæg og drift kan bruges til analyse, planlægning, fejlhåndtering, beslutningsstøtte og optimering. Det er en vigtig del af sektorens digitale udvikling.

André Bryde Alnor, Energy Solution Strategist hos Mjølner, fremhæver netop, at flere og flere digitale løsninger i dag bygger på data fra driften:

Det skaber store muligheder. Men det skaber også nye afhængigheder.

Når flere systemer, leverandører og forretningskritiske processer hænger sammen, bliver risikobilledet mere komplekst. En beslutning om digitalisering er derfor ikke kun en teknisk beslutning. Det er også en ledelsesbeslutning om risiko, ansvar og robusthed.

For André er det centrale spørgsmål derfor, hvordan virksomheder kan høste gevinsterne ved moderne arkitektur og bedre beslutningsstøtte uden at svække sikkerheden:

Digitaliseringen skal med andre ord ikke bremses. Men den skal ske med blik for de nye afhængigheder, den skaber.

Det gælder for eksempel leverandøradgange, fjernsupport, dataudveksling og andre forbindelser, som er etableret for at understøtte effektiv drift.

Det er en vigtig pointe for ledelsen. For mange af de løsninger, der skaber værdi i hverdagen, kan samtidig åbne for nye sårbarheder.

Jørgen peger for eksempel på, hvordan eksterne leverandørforbindelser ofte opstår af helt legitime grunde: hurtigere support, mindre nedetid og mere stabil drift. Problemet er ikke intentionen. Problemet er, at løsningen også kan skabe en ny vej ind i OT-miljøet.

Derfor bør ledelsen ikke kun spørge, hvilke digitale muligheder integrationen giver. Man bør også spørge:

• Hvor mødes IT og OT hos os?
• Hvilke forbindelser og afhængigheder har vi?
• Hvilke praktiske genveje i driften er potentielle angrebsflader?
• Hvad gør vi, hvis en vigtig forbindelse, leverandør eller løsning pludselig ikke virker?
  

3. At placere ansvaret i én silo

Den tredje fejl er organisatorisk.

Når OT-sikkerhed får mere opmærksomhed, opstår det naturlige spørgsmål: Hvem har ansvaret?

Og her ser mange organisationer den samme tendens. Ansvaret bliver lagt i én funktion – ofte der, hvor ordet “sikkerhed” allerede findes. Men hvis OT-sikkerhed placeres for snævert, risikerer virksomheden at placere opgaven hos nogen, der kun forstår den ene halvdel af problemet.

André Alnor siger det meget direkte:

Det er netop udfordringen i krydsfeltet mellem IT og OT. En klassisk IT-sikkerhedsfunktion kan være stærk i cyberdiscipliner, adgangskontrol og netværksbeskyttelse – men mangle det nødvendige greb om drift, beredskab og fysisk infrastruktur. Omvendt kan en driftsfunktion have stærkt fokus på oppetid og kontinuitet, men ikke nødvendigvis være rustet til at håndtere de cybertrusler, der følger med digitalisering og integration.

“Broen” mellem IT og OT er ikke noget, man bare kan hente ned fra hylden. Den skal bygges organisatorisk.

For ledelsen betyder det, at OT-sikkerhed ikke bør reduceres til et rent IT-anliggende eller et rent driftsmæssigt spørgsmål. Det kræver en struktur, hvor nogen har mandat til at samle perspektiverne, koordinere indsatsen og løfte de rigtige risici til ledelsen.

Men ansvaret må ikke blive en silo. Det skal skabe sammenhæng mellem de funktioner, der hver især sidder med en del af problemet: ledelse, IT, drift, beredskab, risikostyring og leverandørstyring.

Hvad betyder det for ledelsen?

Når IT og OT mødes, er det ikke nok at spørge, om sikkerheden er høj nok. Ledelsen må også spørge, om sikkerheden er tænkt rigtigt.

Det betyder blandt andet:

• at OT-sikkerhed skal vurderes ud fra driftens virkelighed
• at integration mellem IT og OT skal ses som både en gevinst og en ny risikoflade
• at ansvaret skal forankres på en måde, der bygger bro mellem fagområder frem for at forstærke siloer

Det er i sidste ende den vigtigste pointe.

God sikkerhed er ikke nødvendigvis den kontrol, der ser stærkest ud på papiret. Det er den løsning, der beskytter organisationen uden at underminere dens evne til at fungere.

I energi- og forsyningssektoren handler sikkerhed nemlig ikke kun om data. Det handler også om drift, oppetid og kritiske funktioner i samfundet.

Derfor kan klassiske IT-greb ikke stå alene, når OT bliver en større del af det digitale risikobillede.

Når IT og OT mødes, skal ledelsen forstå begge verdener. Ellers risikerer man at skabe nye problemer i forsøget på at løse de gamle.

Dyk ned i næste indlæg i serien, OT-sikkerhed i praksis: Sådan arbejder ledelsen med de scenarier, der kan ramme driften hårdest, og få konkrete perspektiver på, hvordan ledelsen kan omsætte OT-risiko til scenarier, prioriteringer og beslutninger, der styrker driften.

Når IT og OT smelter sammen, findes der sjældent én standardløsning. Tag en uforpligtende snak med André om, hvordan I kan styrke OT-sikkerheden uden at gå på kompromis med drift og oppetid.

E-mail

Telefon

Efter knap 10 år som både medejer og en del af ledelsen stopper Michael Heegaard hos Mjølner og går på pension. Selvom it har været overskriften for en lang karriere, er det menneskene og det faglige samspil, der står tilbage som det væsentligste. 

Da Michael Heegaard trådte ind ad døren hos Mjølner i 2016, blev han mødt af faglig stolthed, nysgerrighed og en ordentlighed, der hurtigt fik ham til at ønske at blive en del af holdet.

En fremtid med AI og fokus på sikkerhed

Gennem de seneste to år er Mjølner rykket endnu tættere på kundernes forretning. Det er bl.a. sket ved at oprette afdelinger med specifikt branchefokus og ansætte domæneeksperter inden for AI, industri, energi og forsyning. For Michael har det især været vigtigt, at Mjølner nu kan tage nye typer samtaler med kunderne.

Michael ser det som en vigtig opgave for Mjølner fortsat at hjælpe kunderne med at udvikle og skalere deres forretning gennem digitale løsninger. Det kræver dygtige konsulenter tæt på projekterne, og at Mjølner tager ansvar for den samlede leverance.

Når samtalen falder på fremtiden for it-branchen – som Michael understreger er svær at omtale som én branche – er der især to emner, han fremhæver: AI og sikkerhed.

Selvom AI-udviklingen buldrer derudad, skal der i høj grad stadig være fokus på klassiske it-dyder som compliance og sikkerhed. I en tid præget af geopolitisk uro, væbnet konflikt i flere regioner og skarpt optrukne politiske linjer, er it-sikkerhed ikke et tilvalg, men en nødvendighed. 

Mjølner er mennesker

De faglige resultater, økonomiske milepæle og spændende kundeprojekter har været mange gennem de seneste ti år. Alligevel er det særligt de mennesker, som Michael Heegaard har arbejdet sammen med, der har været brændstoffet for hans arbejdsliv.

I de år, Michael har været hos Mjølner, er virksomheden mere end fordoblet i antallet af medarbejdere og tæller nu 300 fastansatte og over 80 freelancere. Michael peger på, at vi fremadrettet skal finde den rette balance mellem individuel kreativitet og standardisering. Det betyder fx i højere grad at genbruge komponenter på en måde, der både er fagligt solid og skaber værdi for kunderne.

Som en del af ledergruppen har Michael set det som en spændende opgave at bibeholde essensen af Mjølner, samtidig med at virksomheden har oplevet stor vækst. Visse opgaver og processer er blevet mere formaliserede, men Michael oplever, at de grundlæggende værdier lever videre og udleves i dagligdagen.

For halvandet år siden trådte Michael ud af den øverste ledelse og har senest haft titlen som CSO og Head of Marketing. Stafetten er nu givet videre, og med en afskedsreception den 1. maj er punktummet for arbejdslivet sat.

Software- og designhuset Mjølner Informatics offentliggør et årsregnskab præget af strate-giske investeringer. Udbygningen af datterselskabet i Madrid, nye kontorfaciliteter og styr-kede AI-kompetencer påvirker årets resultat, men skaber et stærkt fundament for 2026.

I 2025 har Mjølner fortsat investeret i det spanske datterselskab, Mjolner Informatics Spain, og i dag drives flere produktteams på tværs af brancher fra Madrid. Det giver virksomhedens kunder både kapacitet og fleksibilitet til at gennemføre komplekse udviklingsprojekter. I løbet af året er antallet af spanske kollegaer fordoblet fra 14 til 30 medarbejdere, og udviklingen fortsætter i 2026.

Mjølner har i 2025 udvidet sine kontorfaciliteter for at understøtte virksomhedens vækst. Blandt andet flyttede virksomheden ved årets udgang ind i en ny tilbygning på Finlandsgade i Aarhus, hvor 1.300 ekstra kvadratmeter har skabt plads til 70 kollegaer.

Selskabet forventede et resultat på niveau med 2024. Som følge af årets investeringer og øgede kapacitetsomkostninger udgør resultatet før skat 16,7 mio. kr. mod knap 21 mio. kr. året før.

Automize med på holdet

I juni 2025 blev Automize en integreret del af Mjølner. Sammenlægningen styrker Mjølners position og ambition om at være en af Danmarks stærkeste digitale samarbejdspartnere. Med Automizes teknologiske specialise-ring og Mjølners stærke udviklingsmiljø samles kræfterne i én organisation.

Blandt de hurtigste på savannen

I starten af oktober blev Mjølner Informatics for tredje år i træk kåret som Børsen Gazelle. Prisen er et konkret skulderklap for virksomhedens udvikling og vækst, og det er hele femte gang, at Mjølner kåres som gazellevirksomhed. Tilbage i 2008 og 2009 blev virksomheden hædret to år i træk. Siden da har it-huset formået at mere end firdoble antallet af medarbejdere.

”Vi er vilde med teknologi, men tænker forretning først”

For det kommende år forventer Mjølner et fortsat højt aktivitetsniveau. Fokus bliver at styrke Mjølners position længere oppe i kundernes værdikæde gennem større ansvar i projekter og udvikling af produkter.

Væksten skal blandt andet drives af den fortsatte udvikling af det spanske datterselskab, styrkede forretnings- og teknologikompetencer samt øget automatisering af processer og systemer. Her kommer både rådgivning om og udvikling af AI-løsninger til at spille en central rolle.

Samtidig skal interne udviklingsprojekter understøtte selskabets konkurrenceevne og effektivitet. På den baggrund forventer ledelsen et resultat i niveauet 20-25 mio. kr. i 2026.

Læs mere i årsrapporten

Dyk ned i Mjølners årsrapport 2025 og bliv klogere på de farverige historier og tørre tal. 

Cybersikkerhed er blevet et strategisk tema i energi- og forsyningssektoren. Mange organisationer har de senere år styrket deres IT-sikkerhed markant. Men i takt med at digitaliseringen også når produktion og drift, opdager flere, at der findes et område, hvor overblikket ofte er mindre.

Det område er OT – Operational Technology.

OT dækker de systemer, der styrer den fysiske drift: produktionsanlæg, pumpestationer, transformerstationer og kontrolsystemer. Det er her, software møder den fysiske infrastruktur – og hvor konsekvensen af et sikkerhedsbrud ikke kun er tab af data, men potentielt driftsstop eller påvirkning af kritisk infrastruktur. For ledelsen rejser det et centralt spørgsmål:

Hvordan kommer man i gang med OT-sikkerhed på en måde, der skaber reel værdi for forretningen?

De følgende 5 råd bygger på erfaringer og anbefalinger fra Mjølners domæneeksperter inden for energi og forsyning, Jakob Hviid og André Bryde Alnor, samt vores partner Jørgen Hartig fra SecuriOT.

1. Få placeret ansvaret

En af de største udfordringer ved OT-sikkerhed er organisatorisk.

I mange organisationer opstår der hurtigt en rundtur mellem afdelinger: produktion peger på IT, og IT peger tilbage på produktionen.

I mange organisationer falder OT-sikkerhed derfor mellem flere stole: forsyning, IT og cybersikkerhed. Resultatet er, at alle anerkender risikoen – men ingen har det klare mandat til at drive arbejdet.

Derfor starter OT-sikkerhed ikke med teknologi. Den starter med en ledelsesbeslutning om ansvar.

Men hvem giver det mening at placere ansvaret hos?

Erfaringen fra mange organisationer er, at rollen sjældent bør ligge i en ren IT-sikkerhedsfunktion alene. OT-sikkerhed handler i høj grad om drift, oppetid og fysisk infrastruktur – og kræver derfor forståelse for produktionen.

En god tommelfingerregel er at placere ansvaret hos en funktion, der:

Forstår driften og værdikæden
Personen skal kunne vurdere, hvad der faktisk er kritisk for produktionen eller forsyningen.

Kan arbejde på tværs af IT og forsyningen
OT-sikkerhed ligger i spændingsfeltet mellem flere fagområder. Rollen skal kunne samle organisationen – ikke forstærke siloerne.

Har mandat til at løfte risiko til ledelsen
OT-sikkerhed handler i sidste ende om forretningsrisiko. Derfor skal den ansvarlige kunne oversætte tekniske problemstillinger til ledelsesbeslutninger. I nogle organisationer ligger rollen hos en CISO med OT-kompetence, i andre hos en drifts- eller anlægsfunktion med tæt samarbejde med IT. Den præcise placering kan variere – men det afgørende er, at ansvaret er tydeligt og har ledelsens opbakning.

2. Forstå forskellen mellem IT-sikkerhed og OT-sikkerhed

En klassisk faldgrube er at håndtere OT-sikkerhed som et almindeligt IT-sikkerhedsproblem. De to områder arbejder nemlig ud fra forskellige præmisser. I IT-verdenen er sikkerhed typisk centreret omkring beskyttelse af data og systemer. I OT-verdenen er fokus først og fremmest stabil drift og fysisk sikkerhed.

Det betyder også, at nogle klassiske IT-sikkerhedstiltag ikke nødvendigvis passer direkte ind i OT-miljøer.

Pointen er ikke, at sikkerhed er mindre vigtig i OT – men at den skal designes ud fra forsyningens virkelighed.

3. Start med risiko – ikke med det letteste

Når organisationer begynder at arbejde med OT-sikkerhed, er der en tendens til at starte med det, der er lettest at forholde sig til, såsom: 

• hegn og fysisk adgangskontrol
• Netværkssegmentering
• Backup af software 

Alle tre ting er vigtige. Men det er ikke nødvendigvis der, hvor risikoen er størst. 

Den mere effektive tilgang er at starte med risikovurderingen.

Et godt første spørgsmål er: Hvad er de funktioner i vores organisation, der absolut skal fungere, for at vi kan levere vores kerneydelse?

Når de essentielle funktioner er identificeret, kan man arbejde videre med:

• hvilke systemer der understøtter dem
• hvilke trusler der kan påvirke dem
• hvad konsekvensen vil være, hvis de svigter.

Mange organisationer arbejder med konkrete trusselsscenarier – for eksempel hvad der sker, hvis et centralt styringssystem er utilgængeligt i flere dage. Det gør det langt lettere for ledelsen at prioritere investeringer, fordi diskussionen tager udgangspunkt i forretningsrisiko frem for teknologi.

4. IT og OT skal arbejde tættere sammen

Historisk har OT-miljøer ofte været relativt isolerede fra resten af organisationens systemer. Men i takt med digitalisering og dataanalyse bliver integrationen mellem IT og OT stadig tættere.

Det betyder, at sikkerhedsarbejdet ikke længere kan foregå i siloer. IT- og OT-specialister skal arbejde tættere sammen, og ledelsen skal sikre, at organisationen har en struktur, der understøtter det samarbejde.

5. Find jeres modenhedspunkt – og byg videre derfra

En anden vigtig pointe fra erfaringerne i sektoren er, at OT-sikkerhed ikke kan implementeres i én samlet indsats. Det sker ofte, når arbejdet drives af compliancekrav eller regulering. Organisationen forsøger at implementere alle kontroller samtidig og ender med et stort program, som er svært at operationalisere. En mere realistisk tilgang er at starte fra organisationens nuværende modenhedsniveau.

Det betyder typisk: at etablere grundlæggende processer først, at arbejde struktureret med risici og løbende forbedre sikkerheden. OT-sikkerhed er ikke et projekt med en slutdato. Det er en disciplin, der udvikler sig over tid i takt med teknologi, digitalisering og trusselsbillede.

Fem centrale råd til ledelsen – kort opsummeret

Hvis man skal koge erfaringerne ned til fem centrale råd til ledelsen i energi- og forsyningsvirksomheder, er de: 

1. Placér et tydeligt ansvar for OT-sikkerhed
   OT-sikkerhed falder ofte mellem drift og IT. Sørg for, at én funktion har mandat til at drive området og koordinere indsatsen på tværs af organisationen.
2. Tag udgangspunkt i forretningens risiko
   Start ikke med teknologien. Start med spørgsmålet: Hvad må ikke gå galt i vores forsyning – og hvad vil konsekvensen være, hvis det gør?
3. Prioritér ud fra risiko – ikke ud fra hvad der er lettest
   Mange organisationer starter med skalsikring af anlæg eller netværkssegmentering, fordi det er konkret og synligt. Det er vigtigt, men ikke nødvendigvis der, risikoen er størst. Lad risikovurderingen styre indsatsen.
4. Skab overblik over jeres OT-landskab
   Ledelsen bør sikre, at organisationen har et realistisk billede af sine OT-systemer, forbindelser og afhængigheder. Man kan ikke beskytte noget, man ikke kender.
5. Arbejd med OT-sikkerhed som en løbende modenhedsrejse
   OT-sikkerhed bliver ikke “færdig”. Start fra jeres nuværende niveau, byg strukturer og processer op, og forbedr dem løbende.

Det værste er at gøre ingenting

OT-sikkerhed kan virke komplekst. Infrastruktur, systemer og leverandører har ofte udviklet sig over mange år, og der findes sjældent en enkel løsning.

Men det betyder ikke, at man skal vente. Tværtimod. Den største risiko for mange organisationer er ikke at starte for småt – men slet ikke at starte.

Som erfaringerne fra sektoren viser, er det vigtigste skridt at komme i gang, skabe overblik og begynde at arbejde struktureret med risiko.

Det værste er at gøre ingenting.

Vil du dykke mere ned i samspillet mellem IT og OT? Så læs også vores artikel: Når IT og OT mødes: 3 klassiske fejl ledelsen skal undgå. Eller få konkrete perspektiver på, hvordan ledelsen kan omsætte OT-risiko til scenarier, prioriteringer og beslutninger, der styrker driften: OT-sikkerhed i praksis: Sådan arbejder ledelsen med de scenarier, der kan ramme driften hårdest.

Når IT og OT smelter sammen, findes der sjældent én standardløsning. Tag en uforpligtende snak med André om, hvordan I kan styrke OT-sikkerheden uden at gå på kompromis med drift og oppetid.

E-mail

Telefon

Energi- og forsyningsbranchen opererer i et OT-landskab, hvor driftsstabilitet, cybersikkerhed og compliance ikke er til diskussion. Samtidig stiger kravene til fleksibilitet og integration. Det udfordrer de traditionelle leverandørmodeller. Open source er ikke en mirakelløsning, men for mange organisationer kan det være et strategisk svar på udfordringerne. 

Behovet for ny funktionalitet i OT-løsninger er vokset markant. Mange organisationer oplever, at udviklingstempoet hos traditionelle leverandører ikke altid matcher deres behov for hurtig tilpasning. Såkaldt cloud native, open source-software understøtter en mere modulær og uafhængig tilgang, hvor løsninger bliver sammensat af mindre komponenter, som kan tilpasses og udskiftes løbende.  

Ifølge André Bryde Alnor, Energy Solution Strategist hos Mjølner, ser vi allerede den bevægelse i energisektoren. Open source har sat standarden i IT-verdenen, og med initiativer som LF Energy oplever vi nu, hvordan tilgangen kan skabe fælles innovation og styrket kontrol i energisektoren. 

Læs med og bliv klogere på, hvorfor open source for mange energivirksomheder er blevet et strategisk alternativ til traditionelle leverandørløsninger. 

Større kontrol og transparens 

De åbne kodebaser i open source–software giver indsigt i, hvordan løsningen faktisk fungerer, og det giver større gennemsigtighed. Samtidig betyder de åbne licenser, at du kan tilpasse og udskifte komponenter efter behov. I mange kommercielle løsninger er indholdet mere lukket, hvilket kan gøre det vanskeligere at få fuld indsigt i arkitektur og afhængigheder. 

Hurtig håndtering af sårbarheder 

I mange tilfælde håndteres sårbarheder hurtigt i open source-miljøer, fordi fejl opdages og deles åbent. Det giver organisationer mulighed for at reagere hurtigt, hvis de selv har styr på opdateringer og drift. Den samarbejdende tilgang gør det lettere at håndtere og lukke sårbarheder i kritiske systemer. 

Skalerbarhed og fleksibilitet 

Med open source i forening med en løst koblet arkitektur kan man justere dele af systemlandskabet uden at skulle udskifte hele platforme. Derfor kan du som aktør hurtigt skalere og tilpasse løsninger til skiftende behov i energisektoren, hvor kravene udvikler sig hurtigt. 

Omkostningseffektivitet

Når du benytter open source til OT-løsninger, kan du reducere licensomkostninger og flytte flere midler fra licenser til udvikling og drift. Samtidig kan funktionalitet hurtigt implementeres ved at udvælge og konfigurere eksisterende komponenter. 

Fælles innovation og samarbejde

Open source skaber mulighed for fælles udvikling på tværs af energisektoren. Når flere aktører samarbejder om fælles komponenter, kan man dele omkostninger, mindske dobbeltarbejde og udvikle nye løsninger hurtigere.

De ændringer og den nye funktionalitet, der kommer ud af samarbejdet, kan implementeres langt hurtigere, da man ikke er afhængig af kommercielle leverandørers udviklingscyklusser. Samtidig mindsker fælles komponenter duplikation og fremskynder integration på tværs af lande og infrastrukturer. 

Bedre efterlevelse af cybersikkerhedskrav

Med adgang til kildekoden kan man lettere sikre, at løsningen lever op til specifikke sikkerhedskrav og kan tilpasse sig nye trusler. Flere øjne på kritisk kode reducerer desuden fejl og sårbarheder: en vigtig egenskab i OT, hvor konsekvenserne af fejl er høje. 

Det giver et bedre grundlag for dokumentation over for myndigheder og bestyrelser. 

Afmystificering af risici 

At benytte open source kan virke kontroversielt, fordi driftskravene er tårnhøje, når det kommer til forsyningssikkerhed og kritisk infrastruktur. Men en del overser det faktum, at open source er standard i global softwareudvikling, og at de fleste kommercielle produkter allerede bygger på open source-komponenter. 

Den stigende kompleksitet i energisystemer kræver samarbejde på tværs af organisationer og leverandører, og derfor er det ikke til at komme uden om open source. 

Open source er ikke den nemmeste vej. Tilgangen kræver kompetencer, governance og klare driftsmodeller. Men for energivirksomheder, der ønsker fleksibilitet og strategisk uafhængighed i deres OT-landskab, kan det være en god måde at komme i kontrol over sit systemlandskab, risici og leverandørforhold. 

Rigtigt grebet an kan platform engineering reducere kognitiv load, forkorte time-to-market og skabe bedre flow i hverdagen for udviklere. Forkert grebet an kan det blive endnu et lag kompleksitet, der flytter problemerne i stedet for at løse dem.

Ved alle større tekniske og organisatoriske initiativer er der faldgruber, som kan underminere værdien, hvis man ikke er opmærksom. Vi har spurgt Martin Schmidt Daugaard, der er Cloud Architect, hvad man skal være opmærksom på, hvis man arbejder med eller overvejer platform engineering. Læs med og blive klogere på, hvor du ikke ønsker at bevæge dig hen.

1. At bygge en platform for platformens skyld

En af de mest grundlæggende faldgruber er at gøre platformen til målet i sig selv. Når fokus bliver at “bygge en platform”, frem for at løse konkrete problemer for forretningen og udviklerne, risikerer man at ende med et teknisk flot, men forretningsmæssigt irrelevant produkt.

Hvis udviklernes hverdag ikke bliver mærkbart bedre, eller forretningen ikke bevæger sig hurtigere og mere sikkert, er platformen i praksis ikke lykkedes – uanset hvor elegant den er bygget.

2. Ivory tower‑beslutninger og manglende brugerinddragelse

En anden klassisk faldgrube opstår, når platformteams isolerer sig og træffer beslutninger uden tæt dialog med dem, der skal bruge platformen. Hvis arkitektur, værktøjer og processer defineres ud fra, hvad der er teknisk fordelagtigt, frem for hvad der løser reelle pains, opstår der hurtigt afstand mellem platform- og udviklingsteams.

Det betyder, at man ikke blot skal lytte til deres løsningsforslag, men især forstå de problemer, de møder i hverdagen. Platforme, der designes fra et elfenbenstårn, risikerer at være rigtige på papiret, men forkerte i praksis.

3. Overstandardisering og en for rigid “paved road”

Standardisering er en vigtig del af platform engineering, men den bliver en faldgrube, når den bliver for rigid. En paved road, der er obligatorisk i alle situationer, efterlader ikke plads til særlige behov, eksperimenter eller forretningskritiske afvigelser.

Hvis teams med legitime krav bliver tvunget ind i løsninger, der ikke passer til deres kontekst, vil de enten blive bremset i deres leverancer eller finde uofficielle veje udenom platformen. En god platform tillader afvigelser, men gør konsekvenser og ansvar tydelige. Alternativet er snowflake‑løsninger og tab af tillid til platformen.

4. Tool‑fetichisme og “shiny object syndrome”

Det skinner og er flot. Derfor må det være godt. Nogle gange lader vi værktøjer og teknologier styre retningen i ren begejstring over teknologien. Når platformbeslutninger træffes, fordi et værktøj er populært, nyt eller “lækkert”, risikerer man at skabe unødvendig kompleksitet.

Teknologier som Kubernetes, avancerede cloudservices eller komplekse CI/CD-opsætninger kan være de rigtige valg, men kun i den rette kontekst. Platform engineering bør tage udgangspunkt i friktion, skala og organisatoriske behov, ikke i trends. Ellers ender man med at løse problemer, man endnu ikke har.

5. At automatisere dårlige processer

Automatisering er ofte en central del af platform engineering, men den bliver en faldgrube, hvis man blot automatiserer eksisterende arbejdsgange uden at gentænke dem. At “sætte strøm til” en uhensigtsmæssig proces gør den ikke bedre, men blot hurtigere og sværere at ændre senere.

Uden arkitektoniske overvejelser og klar adskillelse af ansvar risikerer man at skabe tæt koblede systemer, platform drag og øget driftsrisiko. Platform engineering kræver, at du stopper op og spørger: Er det her en proces, vi bør understøtte – eller en, vi bør gentænke, eller måske endda helt fjerne?

Platforme lykkes ikke på teknologi.
De lykkes på adfærd.

De fem faldgruber, som Martin peger på, har noget helt centralt til fælles: Platform engineering fejler sjældent, fordi teknologien ikke virker. Det fejler, fordi fokus flytter sig væk fra det egentlige formål:

• Når platformen bliver vigtigere end den værdi, den skal skabe.
• Når vi glemmer at tage udvikleren alvorligt som kunde.
• Når standarder bliver vigtigere end mennesker.
• Når værktøjer vælges før løsninger.
• Når vi automatiserer det eksisterende i stedet for at forbedre det.

En god platform kan gøre en kæmpe forskel for både udviklere og organisation. Den gør det nemmere at gøre det rigtige – at følge vejen fremfor at fare vild i skoven. Og det er værd at huske på, fastslår Martin: