Koppla ihop systemen utan onödiga manuella steg

Vad gör att manuella steg uppstår – och vad interoperabilitet löser

Manuella steg uppstår sällan genom beslut. De uppstår när information ska passera en gräns mellan system eller aktörer som saknar gemensam struktur för att beskriva och överföra informationen.

I prop. 2004/05:175 pekade regeringen på behovet av gemensamma grundfunktioner, specifikationer och standarder för säker kommunikation, interoperabilitet (information ska lätt kunna föras mellan tekniska miljöer), förenklat informationsutbyte och sökbar offentlig information. Kommittédirektiv 2006:36 bygger på samma resonemang.

Direktivet konstaterar att IT-utvecklingen i stat, kommun och regioner i huvudsak är marknads- och verksamhetsstyrd. Delvis nya gemensamma tekniska, semantiska, organisatoriska och legala strukturer och standarder kan behövas för att få ut mesta möjliga nytta av informationssamhället.

Dessa fyra nivåer avgör om en koppling blir helautomatisk eller kräver handpåläggning.

Uppdraget gällde i första hand staten, men också relationen till kommun- och regionsektorn och näringslivet. Samma fyra nivåer gäller därför även för en privat verksamhet som vill koppla ihop sina egna system.

Teknisk nivå: kan systemen tala med varandra? Semantisk nivå: betyder begreppen samma sak? Organisatorisk nivå: är ansvar och rutiner överenskomna? Legal nivå: får informationen överföras, och på vilka villkor?

Kartlägg flödet. Markera var någon skriver samma uppgift två gånger, kopierar mellan system, exporterar till kalkylark, mejlar en fil eller väntar på att någon annan lägger in informationen.

Varje sådant ställe är en kandidat för en koppling. Bygger kopplingen på en gemensam standard minskar risken att nästa systembyte återskapar det manuella steget.

På den legala nivån behöver krav på standarder, gränssnitt och informationsutbyte formuleras redan i upphandlingen, inte läggas till i efterhand.

Ett område där kopplingen är särskilt kritisk är integration mellan medicinteknisk utrustning och IT-system. Där avgör den legala nivån om uppgifterna får föras över och på vilka villkor, innan någon teknisk lösning väljs.

Verktygen för att bygga kopplingar har namn: iPaaS, ESB, API-baserad integration, dataintegration och arbetsflödesplattformar. De kan ansluta system via API:er, transformera dataformat och orkestrera flerstegsarbetsflöden.

Alumio Route Builder, Jitterbit och Junipeer är exempel på iPaaS. Multisoft levererar systemlösningar som integrerar mot befintliga och nya system. En integrationsplattform fungerar som nav, tolk eller mellanvarulager.

Konkreta steg är att ansluta via API:er, mappa dataformat som JSON till XML, hantera autentisering, loggning och säkerhet samt övervaka framgång eller misslyckande.

Bygg på gemensamma standarder i stället för punktlösningar

Kommittédirektiv 2006:36 skulle bedöma och vid behov föreslå bättre former för samordning av standardutveckling inom IT-området, i första hand inom staten men även mot kommuner, regioner och näringsliv.

Uppdraget omfattade att underlätta utveckling och användning av IT-standarder av olika slag – inklusive de facto-standarder, grundfunktioner och gemensamma kravspecifikationer. Det skulle också kartlägga nivåer och processer inom IT-standardiseringen och beakta internationella och nationella regelverk.

IT-standardiseringsutredningens uppdrag var att föreslå hur IT-standardiseringen i den offentliga förvaltningen kan samordnas bättre.

Direktivet kopplar standarder till upphandling. Utredaren skulle undersöka hur standarder och gemensamma kravspecifikationer påverkar aktörerna vid offentlig upphandling, och om bättre samordning kan stimulera innovationer genom upphandlingen och öka småföretagens deltagande.

Standardval påverkar därför vilka leverantörer som kan lämna anbud och hur låst man blir vid en enskild lösning.

Utredaren skulle också föreslå hur användningen av öppen programvara i offentlig förvaltning kan främjas. Öppen programvara är därför ett alternativ att väga in när en koppling inte ska bindas till en enskild leverantörs format.

Grundtanken gäller oavsett verksamhetsområde: en gemensam standard gör att många aktörer kan bygga samma gränssnitt. Annars tar varje köpare och leverantör fram en egen punktlösning som bara fungerar i det enskilda fallet.

Praktiskt bör varje integration börja med frågan vilken standard som redan beskriver flödet, i stället för att specificera ett eget format. Egenutvecklade format binder informationsutbytet till en leverantörs lösning.

Nästa systembyte eller samarbetspartner tvingar då fram manuella rutiner igen.

Kommittédirektiv 2006:36 beslutades vid regeringssammanträde den 6 april 2006 och skulle redovisas senast den 30 juni 2007. Samordningen av IT-standarder är alltså ett långsiktigt arbete, och varje enskild koppling behöver förvaltas över samma tidshorisont.

När en standard ska införas finns stöd genom SFTI Tekniskt kansli, informationsinsatser, utbildningar, webb med valideringstjänst, handledningar och arbetsgrupper. SFTI deltar också i CEN och SIS.

En integrationsplattform kan minska risken för punktlösningar genom förbyggda kopplingar och flödesbyggare med logikmappning.

Använd svenska tillämpningsanvisningar för standarder

Internationella standarder är sällan detaljerade nog att användas rakt av i en svensk offentlig inköpsprocess. Därför finns SFTI (Single Face To Industry), med Upphandlingsmyndigheten, Kammarkollegiet och Sveriges Kommuner och Regioner (SKR) som huvudmän.

En SFTI-rekommendation är en gemensam svensk tillämpningsanvisning för hur en standard ska användas för att skapa interoperabilitet. Den utgår från en namngiven standard och kompletteras med anvisningar för svensk användning, i första hand för att underlätta tillämpningen mellan inköpare, leverantörer och deras IT-system.

SFTI tar normalt inte fram egna tekniska standarder utan anpassar och preciserar befintliga internationella standarder. Undantag finns, till exempel API och vissa specialprocesser.

Sedan juli 2025 rekommenderar SFTI enbart valda delar av standarden Peppol BIS. Tillämpningsanvisningarna, en viktig del av rekommendationerna, kan ställa högre krav än minimikraven i Peppol BIS men är samtidigt kompatibla med dem.

Rekommendationerna tas fram i en förankringsprocess där representanter från statliga myndigheter, kommuner och regioner samverkar med upphandlade leverantörer och med leverantörer av programvaror och tjänster som stödjer den digitala inköpsprocessen.

SFTI deltar i nationellt och internationellt standardarbete för hela inköpsprocessen, bland annat i CEN och SIS.

Syftet med rekommendationerna är uttalat att underlätta för leverantörer, främst de som arbetar mot offentlig sektor, när en standard ska tillämpas mellan parterna och deras system. En SFTI-rekommendation kan därför fungera som gemensam referens i en kravspecifikation.

Den som kopplar ihop system behöver inte välja mellan en internationell standard och en svensk anpassning: SFTI:s rekommendation är bryggan. Utgår man från en namngiven standard med svenska tillämpningsanvisningar kan aktörerna och deras system kopplas samman utan manuella mellanled.

Kraven blir begripliga för både upphandlare och systemleverantörer.

Tillämpningsanvisningen preciserar den underliggande standarden, men ersätter den inte. Välj därför rekommendation efter den process som ska kopplas ihop, och kontrollera vilka delar av standarden rekommendationen omfattar.

SFTI:s rekommenderade standarder stöds genom SFTI Tekniskt kansli, utbildningar, handledningar, arbetsgrupper och en webb med valideringstjänst. Där kan meddelanden kontrolleras mot vald standard.

Nyckelorganisationer och resurser för standardisering i Sverige

Välj standarder utifrån verksamhetens informationsflöden

SIS har tagit fram grundpaket inom IT och information för offentlig verksamhet, med aktuella och verksamhetsspecifika standarder som inspiration. Urvalet kan enkelt kompletteras med fler standarder som behövs i verksamheten.

Paketet är en utgångspunkt, inte en färdig lista. Informationsflödena i den egna verksamheten bör styra vilka standarder som faktiskt införs.

I paketet ingår SS 12000:2024, Informationshantering – Gränssnitt för informationsutbyte mellan verksamhetsprocesser i skolan. Där ingår också den tekniska rapporten SIS-TR 91102:2016, Digitala trygghetslarm – Internetprotokoll för digitala trygghetslarm (SCAIP) – Implementationsvägledning.

Båda beskriver informationsutbyte i en specifik verksamhetsprocess. De kan styra val av integration, i stället för att varje system skaffar sig ett eget gränssnitt.

Paketet innehåller också styrningsstandarder. SS-ISO/IEC 38500:2024, Informationsteknik – Övergripande styrning av IT för en organisation, SIS-ISO/IEC TR 38502:2014, Informationsteknik – Styrning av IT – Struktur och modell, samt SS-ISO/IEC 20000-1:2018, Informationsteknik – Ledningssystem för tjänster – Del 1: Krav.

Därutöver finns SS 854000:2021 om styrning och ledning för hållbar utveckling i kommuner och regioner och SS 10701:2016 om datautbytesformat vid antagning till gymnasieskolan.

För en kommun eller region blir frågan: vilka av våra informationsflöden har redan en svensk standard eller teknisk rapport, och vilka integrationer kan därmed köpas eller byggas mot en känd specifikation i stället för mot en egen lösning?

Ju fler integrationer som vilar på en utpekad standard, desto färre manuella rutiner behöver hållas levande parallellt.

SIS har en kontaktväg för frågor om hur standarder kan användas i offentlig sektor och erbjuder utbildningar. Pris för standardpaketet lämnas efter prisförfrågan.

SIS kontaktväg för frågor om standarder i offentlig sektor: Antje Thiele, [email protected], 08 555 521 24.

Top 5 svenska standarder att utgå från vid integration

Säkert informationsutbyte utan nya manuella kontroller

Att koppla ihop system handlar inte bara om att informationen rör på sig, utan också om att den gör det säkert.

Standarder är inte en frivillig krydda vid sidan av regelverket, utan en del av hur informationsutbyte förväntas gå till i offentlig förvaltning.

En fellösning är att kompensera en osäker eller otydlig koppling med manuella kontroller: någon läser av en fil, kontrollerar den mot ett register och godkänner överföringen. Det ger en känsla av kontroll men skapar en flaskhals.

Kontrollen blir personberoende i stället för inbyggd i flödet.

Bygger man i stället på standardiserade meddelanden och gemensamma format kan krav på behörighet, spårbarhet och loggning hanteras i själva kopplingen. Då behöver varje överföring inte hanteras manuellt.

Det går att i efterhand se vad som skickats, av vem och när – utan separat dokumentation vid sidan om.

Kraven på standarder är formulerade för offentlig förvaltning, men principerna är desamma i en privat verksamhet: behörighet, spårbarhet och loggning byggs in i kopplingen i stället för att läggas ovanpå den.

I en iPaaS kan säkerhet, autentisering och loggning hanteras centralt. iPaaS-lösningar kan också omfatta datakryptering och efterlevnad av integritetsstandarder.

Centraliserade övervaknings- och granskningsverktyg gör att misslyckade processer kan upptäckas. Skalbar infrastruktur med failover och redundans minskar driftavbrott.

Styr och förvalta kopplingarna över tid

Standardiseringsarbete konkurrerar med verksamhetens vardag. Kommittédirektivet 2006:36 noterar att sådant arbete riskerar att försummas eftersom det är tids- och resurskrävande och kan uppfattas som en störning i den egentliga verksamheten i företaget eller myndigheten.

Samma mekanism gör att en fungerande integration fem år senare kan ha hamnat utanför förvaltningen och ersatts av en manuell rutin.

SFTI:s verksamhet visar en möjlig samverkansstruktur: en styrgrupp, en beredningsgrupp och arbetsgrupper, med stöd av ett tekniskt kansli och handläggare hos de olika huvudmännen.

Införandet av rekommenderade standarder stöds genom det tekniska kansliet, informationsinsatser, utbildningar, webb med tillhörande valideringstjänst, handledningar och arbetsgrupper.

En organisation kan bygga en enklare variant: en namngiven ägare per integration, en grupp som hanterar förändringar och en kanal för frågor.

För förvaltningen finns stöd i standarder. 38500-standarden ger övergripande styrning av IT för en organisation. TR 38502:2014 beskriver struktur och modell för styrning av IT, och 20000-1-standarden ställer krav på ledningssystem för tjänster.

I den egna verksamheten räcker det ofta med tre beslut: vem äger kopplingen, hur hanteras versionsförändringar i standarden, och hur upptäcks det när ett system slutar skicka som det ska?

Utan svar är risken stor att manuella rutiner smyger sig tillbaka.

Aktörerna att hålla reda på är SFTI med huvudmännen Upphandlingsmyndigheten, Kammarkollegiet och SKR, SIS för standarder och tekniska rapporter samt Digg, som har utrett säkert informationsutbyte i offentlig sektor.

I en integrationsplattform kan övervakning och granskning centraliseras. Alumio Route Builder används för att ansluta, orkestrera och styra integrationer i stor skala från ett visuellt gränssnitt.

Jitterbit är en molnbaserad iPaaS för att bygga, distribuera och hantera integrationer mellan molntjänster och on-premise-system.

Exempel: hela inköpsprocessen utan manuella omtag

SFTI:s vision 2030 är att hela inköpsprocessen i offentlig sektor ska vara digital och standardiserad. Målbilden är användbar när system ska kopplas ihop.

I en typisk inköpsprocess uppstår överlämningar vid behovsanalys och beställning, annonsering och avrop, order, orderbekräftelse, leveransavisering, fakturering och till sist betalning och bokföring.

Varje punkt kan beskrivas med ett standardiserat meddelande eller ett API. Då följer ordernummer, referens, belopp och parter med genom hela kedjan, i stället för att skrivas in på nytt i varje system.

SFTI rekommenderar branschöverskridande standarder för hela inköpsprocessen och, sedan juli 2025, enbart valda delar av standarden Peppol BIS kompletterade med svenska tillämpningsanvisningar.

Undantag finns där SFTI tar fram egna specifikationer, till exempel API och vissa specialprocesser.

Den som upphandlar ett nytt inköps- eller fakturasystem kan därför kräva att systemet stödjer de rekommenderade standarderna och de svenska tillämpningsanvisningarna – och undvika manuella mellanled vid införandet.

Kravspecifikationen är det dokument där kopplingen avgörs. Lagen om offentlig upphandling fastställer vad som gäller när till exempel en region ska köpa varor och tjänster, och kraven på stöd för de rekommenderade standarderna och de svenska tillämpningsanvisningarna behöver stå där.

I en iPaaS kan order, orderbekräftelse, leveransavisering, fakturering och betalning kopplas ihop via API:er och standardiserade meddelanden. Data mappas så att ordernummer, referens, belopp och parter följer med.

Alumio Route Builder och Jitterbit är exempel på plattformar som kan ansluta, orkestrera och övervaka ett sådant flöde. Junipeer är ett annat exempel på iPaaS.

För redovisningsautomation kan mottagna betalningar matchas mot öppna fakturor utan manuell intervention. Lagersynkronisering kan återspegla lagerförändringar över försäljningskanaler och ERP.

Checklista innan ni kopplar ihop nästa system

Frågorna nedan är en enkel genomgång inför en ny koppling eller översyn av en befintlig integration. De utgår från nivåerna i kommittédirektivet 2006:36: teknik, semantik, organisation och juridik.