I min tidligere artikel om løsninger på forældede IT-systemer, gav jeg en oversigt over de tre løsninger, vi oftest ser brugt, når virksomheder, kommuner og andre offentlige instanser vil udskifte deres forældede IT-systemer.
Efter en kort opsummering af problemet vil denne artikel, på baggrund af den interesse, der blev udvist samt spændende diskussioner med kolleger, kunder og netværk, konkretisere og uddybe én af de tidligere nævnte tre muligheder for udbygning/udfasning af forældede IT-systemer.
Problemet opsummeret
En lang række veletablerede virksomheder, elementer af den offentlige sektor og andre organisationer er stavnsbundet af deres forældede IT-systemer – også kaldt legacysystemer.
Nyligt eksempel på legacyproblem: Københavns Universitet har brugt et HR-system kaldet ScanPas siden 1985 – altså i over 20 år. KU Ønskede for 5 år siden at udskifte deres gamle ScanPas-system med et nyt system. Desværre kuldsejlede projektet efter 5 års udvikling og må nu kasseres.
Legacysystemerne er pr. definition et levn fra fortiden. De er udviklet for mange år siden, sandsynligvis i et programmeringssprog som kun få udviklere stadig bruger. Derfor kan legacysystemer være enormt dyre at vedligeholde, have problemer med hastighed, kan mangle nyere ønskværdige funktioner og kan være ineffektive for medarbejderne at arbejde med.
Særligt de legacysystemer, som er kritiske for organisationens fungeren, kan være ganske problematiske. Disse kan organisationen ikke nemt udskifte, da systemerne er dybt integreret i organisationen, og fordi en udskiftning af de komplekse systemer kan være uoverskueligt dyrt og bære ufattelige risici med sig.
Som Mads Buch Andersen, Kontorchef ved Koncern IT i Københavns Kommune udtalte:
“Vi må bare erkende at i en kommunal kontekst, der lider vi under rigtig rigtig mange meget tunge og umoderne systemer. Og det er ikke en mulighed for os at få udskiftet de her systemet i løbet få måneder eller et eller tre år.“
Omvendt er det ikke attraktivt at fortsætte med de exceptionelt høje vedligeholdelsespriser og systemets ikke-optimale effektivitet.
Som Mads Haaning Andersen, Fuldmægtig i Landbrugs- og Fiskeristyrelsens IT-afdeling, kommenterede på min tidligere artikel:
“Når man udskyder og udskyder [fornyelsen af legacysystemer], bliver regningen derimod kolossal til sidst.”
Virksomheden har overordnet set tre valg:
- Acceptér skyhøj risiko og pris – Byg et helt nyt system
- Forsæt som altid – Accepter de høje vedligeholdelespriser og systemets til tider ineffektivitet
- Udbyg systemet – Integrér legacysystemet med nye systemer og udfas legacysystemet over flere faser
Det er særligt løsning 3, som denne artikel beskæftiger sig med.
Løsning 3: Data-integration og microservices
Løsning 3 (fra ovenstående liste) fås i flere størrelser alt efter projektets størrelse, omfang, budget, forretningsbehov og mål.
For simplicitetens skyld vil jeg præsentere tre forskellige løsningsmodeller og give dem hvert et pædagogisk navn – hhv. simpel, kompleks og centraliseret.
Simpel integration
At udvikle en simpel integration til forlængelse af legacysystemers liv kan være en glimrende mulighed.
At integrere systemer betyder, kort sagt, at man bygger en bro mellem systemerne, så de kan kommunikere (udveksle data).
De simple integrationer, populært kaldet én-til-en integrationer, har eksisteret i 30 år. Men det er først i nyere tid, at integrationerne har nået et prisniveau, som er rentabelt for fleste virksomheder.
Eksempel på simpel integration: Et vilkårligt forretningskritisk legacysystem skal bruge data fra et givent nyere system – eksempelvis tage imod resultater fra medicinske tests, finansielle beregninger, oplysninger om salg fra websystem eller oplysninger om løn, statistik, ferier og andre administrative data.
Der findes mange virkelige legacysystemer, men for at undgå lange og specifikke beskrivelser gør vi dette eksempel mere almengyldigt.
Lad os give et fiktivt navn til vores eksempel på et legacysystem. Lad os kalde det AuldSys. (AuldSys er forresten naturligvis kodet i COBOL, som er umådeligt dyrt at videreudvikle.)
Desværre er vores fiktive AuldSys umådeligt langsomt. Selv navigation i systemet tager lang tid, da systemet skal loade i 10 sekunder hver gang, medarbejderen tager et skridt. Tilmed skal der navigeres langt for at komme frem til den ønskede destination i systemet.
Det tager medarbejderen 5-10 minutter at indlæse dataen – hver gang.
5-10 minutter 2-3 gange om dagen pr. medarbejder bliver hurtigt til mange mandetimer.
For at spare medarbejderen den tid, og for at sikre at de rigtige oplysninger bliver indlæst uden menneskelige fejl, kan organisationen med fordel vælge at integrere AuldSys med andre systemer.
Stort problem – simpel løsning
En integration bliver udviklet, så AuldSys automatisk modtager data fra organisationens andre systemer – vel at mærke uden menneskelig indblanding. Således undgår medarbejderen at skulle bruge tid på at bøvle med indtastning.
Forestiller vi os, at en større organisation har 100 administrative medarbejdere, som hver kan spare blot 15 minutter dagligt, giver det på årsbasis med 250 arbejdsdage en besparelse på 6.250 mandetimer årligt.
Denne simple integration kan således give en estimeret årlig besparelse på en-til-to millioner kroner alt efter medarbejdernes lønniveau. Dertil kommer forbedring i produktiviteten, da medarbejderen nu kan bruge de daglige 15 minutter på mere værdiskabende arbejde.
Om digitalisering udtalte André Rogaczewski, CEO/Co-founder, Netcompany til Version2:
“Tværtimod vil vi frigøre kræfter til de sjove opgaver. Alle de steder jeg kommer, har økonomiafdelingerne eksempelvis fået færre opgaver – men til gengæld indsigt i data og økonomiske mønstre, der gør, at medarbejderne kan indgå aktivt i styringen af virksomheden frem for at taste tal. Medarbejderne får nye roller, som gør afdelingerne mere værdifulde. Den transformation vil ske i de kommende år.”
Denne type ovenstående integration kunne formentlig have været en glimrende løsning på nogle af KUs tidligere nævnte problemer.
Ifølge denne rapport var det netop en integration mellem KUs HR-system ScanPas og Statens LønSystem (SLS), som de søgte. En simpel integration, som ville have skabt stor værdi for dem. Desværre ved vi ikke nøjagtigt hvor stor en værdi, for de tal er blevet censureret i rapporten.
Fra en simpel til en kompleks integration
Simple integrationer har historisk optimeret virksomheder verden over. De er hamrende smarte og sparer tid og penge. Men historisk har de, grundet udviklingsprisen, desværre kun været forbeholdt de største virksomheder.
At opleve effekten af at integrere to systemer inspirerer ofte organisationer til at gå skridtet videre og integrere flere systemer. Jo mere der kan integreres, des flere mandetimer frigives.
Understående er et eksempel på en organisation, som har valgt at integrere 6 af deres systemer.
Fordelene ved integrationer er indlysende – ved at forbinde så mange systemer som muligt spares al den tid, som medarbejderne ellers skulle bruge på manuelt at indtaste data fra ét system til et andet.
Integrationerne optimerer desuden tiden, som en given arbejdsproces tager, da data fra system 1 øjeblikkeligt sendes til og fra system 2, 3, 4 etc. Således skal processen ikke vente på, at en medarbejder har tid til at overføre data manuelt.
Men desværre er intet problemfrit.
Problemet ved højkompleksitets-integratiosløsninger
Der er fire overordnede problemer, når kompleksiteten stiger.
Omkostningerne, udviklingstiden, levetiden og risici.
Foruden en de eksplosive omkostninger og udviklingstiden kommer spørgsmålet om risici. Jo højere kompleksiteten er, des større er skaden, skulle et system eller en integration gå ned. Arkitekturen kan være konstrueret med single points of failure. Dvs. en større del af integrationsløsningen kan være fuldstændig afhængig af én enkelt integration. Hvis denne integration pludselig ikke virker, som den skal, så mangler en stor del af systemerne pludselig de kritiske data, som de har behov for. Sker dette vil systemet uundgåeligt bryde sammen.
Levetiden på den samlede stack og på de enkelte systemer vil være ‘relativ kort’. Dvs. udskiftning af systemer, i et setup som vist på illustrationen, er ganske vanskeligt. Ønsker man at udskifte et centralt system (eksempelvis skifte fra Dynamics NAV til det nyere Dynamics 365), skal umådeligt mange integrationer bygges fra bunden igen. Dette fører store omkostninger med sig – for ikke at nævne den tid som det vil tage at udvikle. Derfor kan udfasning af legacysystemer, givet denne traditionelle arkitektur, være problematisk.
Arkitekturen er dog, med stor succes, blevet brugt af tusindvis af virksomheder gennem de sidste 30 år. Den automatiserer, sparer virksomheder for utallige mandetimer og optimerer organisationers arbejdsprocesser.
Når gamle systemer udfases og automatiseres, er det desuden ganske vigtigt, at man er opmærksom på proces-designfejl.
Som min kære chef Bo Møller sagde i sin korte video om fejl ved automatisering:
“[Automatisering] handler om at levere nogle resultater på en hurtig og nem måde. Teknologien hjælper til det, men den skal være usynlig.”
Målet med udfasning og automatisering bør aldrig være at udskifte den med en ny tidskrævende proces, som skaber mere forvirring end værdi.
Uanset hvilken type integration, eller anden type digital transformering, en organisation eller kommune vælger, så er én ting sikkert, ifølge Birgitte Hass, adm. direktør i IT-Branchen.
“Gevinsten og fremtiden for kommunerne ligger i deres evne til at lægge en klar digital strategi og foretage de nødvendige it-investeringer i tide. Gør de ikke det, så risikerer de at ende som det støvede og analoge B-hold, der fravælges.”
Er du selv i en situation, hvor der skal findes den helt rigtige løsning på en integraitonsudfordring? Så skriv til adm. direktør Bo Møller fra Twentyfour på bm@html24.dk.
