Juridiske problemer forbundet med overgangen fra gamle systemer i systemudvikling

At skabe nye IT-systemer til brug i virksomheder er et typisk arbejdsområde for IT-ingeniører. Men når vi taler om at “skabe et nyt system”, indebærer det ofte også processen med at “afskaffe det system, der tidligere blev brugt”. I denne artikel vil vi genoverveje projektet med at udvikle et nyt system fra perspektivet af “afskaffelse af det gamle system”, og vi vil forklare de forskellige juridiske problemer, der følger med det.

Hvad betyder det at overgå til et nyt system?

IT-systemers levetid er ikke evig

Det er en misforståelse at tro, at IT-systemer, der anvendes i virksomheder, kan bruges kontinuerligt, når de først er oprettet. Det er heller ikke nødvendigvis godt at fortsætte med at bruge gamle ting. Selvom der naturligvis er variationer afhængigt af virksomheden og systemets formål, er der en tendens til, at en ledelsesbeslutning træffes om at forny systemet efter omkring 10 år.

Efter 10 år vil computerens ydeevne på markedet have ændret sig markant. For eksempel, selvom et program, der ikke var praktisk at implementere på grund af begrænsninger i computerens behandlingshastighed for 10 år siden (selvom det fra et menneskeligt synspunkt var et simpelt og fremragende design), nu kan være muligt at implementere. Desuden, hvis du har brugt det i 10 år siden det blev oprettet, kan virksomhedens arbejdsflow og interne regler have ændret sig betydeligt i mellemtiden. Koden, der er blevet implementeret efterfølgende for at imødekomme disse ændringer i virksomhedens interne og eksterne ledelsesmiljø, kan have en kompleks og indviklet struktur, der ikke kan genkendes fra skærmen. I sådanne tilfælde kan det blive umuligt for udviklerne at tilføje nye funktioner, som brugerne ønsker.

Ældre systemer kan gradvist kræve mere “manuelt arbejde” fra IT-ingeniører (for eksempel driftsopgaver som at udstede forespørgsler for at trække individuelle data). Ironisk nok, jo ældre systemet bliver, jo mere “personafhængigt” bliver arbejdet. Når man forsøger at implementere yderligere “systematisering” for arbejdsopgaver relateret til systemer, der er blevet for gamle og har mange personafhængige opgaver, opstår der et projekt for “udvikling af et nyt system til overførsel fra det gamle system”.

Udviklingen af det nye system skrider frem sammen med afskaffelsen af det gamle system

Som tidligere nævnt, er det ofte tilfældet, at et systemudviklingsprojekt (selvom ikke alle systemudviklingsprojekter er sådan) har aspekter af overgang fra det gamle system. Systemet i sig selv vil ofte skifte diskontinuerligt fra en dag til den næste.

Men den daglige drift skal fortsætte uafbrudt fra fortiden til nutiden og fra nutiden til fremtiden. Mens vi opbevarer de nødvendige data fra fortiden, skal vi ikke forstyrre den nuværende drift, og vi skal også fremlægge koncepter for fremragende “systematisering” for fremtiden. Overgangen til det nye system er ofte ledsaget af forskellige udfordringer. På grund af disse komplekse omstændigheder er udviklingen af det nye system og driften og vedligeholdelsen af det eksisterende system ofte komplekst forbundet, og der kan opstå situationer, hvor de er uadskillelige.

Hvad er trinene til overgang til et nyt system?

Når man overgår fra det gamle system til et nyt system, er det særligt vigtigt at overføre data korrekt. Trinene for dataoverførsel følger generelt følgende procedure.

1. Klarlæg hvilke data, der er gemt i det gamle system, der skal overføres til det nye system → Det skal også være klart, hvilke data der skal være let søgbare fra skærmen i det nye system, og hvilke data der ikke nødvendigvis skal være søgbare fra skærmen, men skal kunne trækkes ud efter behov (f.eks. til revision).
2. Udskriv de data, der er identificeret i trin 1, som skal indlæses i det nye system, i et format som en CSV-fil.
3. Indlæs de data, der er udtrukket i trin 2, i det nye system.
4. Verificer om de data, der er indlæst i trin 3, er reflekteret i det nye system, og bekræft om overførslen er korrekt udført. → Verificeringsresultaterne for korrekt overførsel er normalt dokumenteret som bevismateriale gennem skærmvisninger og udskrivning af rapporter (den såkaldte testproces).

Overgangen til et nyt system kan være udfordrende med hensyn til at definere rollerne for brugere og leverandører

I trinene for datamigrering, som nævnt tidligere, er et ofte opstået problem, hvor meget brugerne skal betragte det som et internt problem i deres egen virksomhed, der skal holdes under kontrol. For en generel diskussion om “brugerens pligt til at samarbejde”, som ikke kun er begrænset til datamigrering, men gælder for systemudviklingsprojekter generelt, se venligst artiklen nedenfor.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Generelt i et systemudviklingsprojekt, er det ofte, at leverandøren har en fordel over brugeren i form af specialiseret knowhow til systemudvikling (eller snarere, det er ofte grunden til, at de er blevet tildelt opgaven). På den anden side, er det ofte kun brugeren, der kan diskutere, hvordan deres eget system “bør være”.

Med dette i tankerne, kan det være en mulighed at brugeren udfører trin 1 og 4, som nævnt tidligere. For at sige det på en anden måde, under hele datamigreringsprocessen, kan det være, at “kravspecifikationen” for de data, der skal migreres, og “accepttesten” for at se, om dataene er blevet migreret korrekt, begge kan betragtes som brugerens ansvar. Alternativt, hvis der er nogen på brugersiden, der har omfattende kendskab til det gamle system, kan det også være en mulighed at gøre trin 2 til brugerens ansvar.

Hvis det er muligt at håndtere det gamle system internt uden at skulle outsource det, kan det være en mulighed at kun outsource udviklingen af det nye system til leverandøren. I denne form for datamigreringsarbejde, kan rollerne mellem brugeren og leverandøren nogle gange blive uklare. For en generel forklaring på, hvilke roller der forventes af leverandøren, og hvilke juridiske forpligtelser der påhviler dem, når brugeren outsourcer systemudviklingsrelaterede opgaver til leverandøren, se venligst også artiklen nedenfor.

https://monolith.law/corporate/project-management-duties[ja]

Tidligere retssager vedrørende overgang til nye systemer

Der er faktiske tilfælde, hvor problemer er opstået i systemudviklingsprojekter, der sigter mod overgang til nye systemer, og som er endt i retten. Den dom, der citeres nedenfor, involverer en sag, hvor der opstod fejl under datamigreringen, hvilket resulterede i flere datainkonsistenser og bugs i det nye system, og forsinkelser i leveringstiden. De forskellige problemer, der opstod, førte til en tvist om, hvilke forpligtelser leverandøren og brugeren hver især havde over for projektet. Konklusionen var, at leverandøren havde overtrådt sin pligt til at udvise forsigtighed, som beskrevet nedenfor.

Defendanten havde, ud over blot at overføre data fra det gamle system til det nye system i henhold til kontrakten, en forpligtelse til at drive det nye system med de overførte data. Specifikt, før de påbegyndte datamigreringsarbejdet, skulle de undersøge og analysere dataene i det gamle system, der skulle migreres, forstå dataenes karakter og tilstand, overveje om disse data ville forhindre driften af det nye system efter migreringen, og hvis det var tilfældet, beslutte hvornår og hvordan de skulle rette disse data. Derefter skulle de påtage sig datamigreringsarbejdet (migreringsdesign, udvikling af migreringsværktøjer, datamigrering), og endelig havde de en forpligtelse til at drive det nye system med dataene, der var migreret fra det gamle system.

Det er rimeligt at anerkende, at i dette tilfælde, havde de en forpligtelse til at rette og løse datainkonsistenser i forbindelse med datamigreringen.

Tokyo District Court, November 30, Heisei 28 (2016)

Dette tilfælde involverede en situation, hvor brugeren skulle tage sig af trin 1 og trin 4, mens leverandøren skulle tage sig af trin 2 og trin 3. Med andre ord, leverandøren havde oprindeligt påtaget sig opgaven med at ekstrahere data fra det gamle system (trin 2). Derfor konkluderede retten, at hvis leverandøren, som en specialist i systemudvikling, havde påtaget sig opgaven, skulle de have overvejet på forhånd, om dataekstraktionsprocessen kunne forløbe gnidningsløst.

Men hvad ville der være sket, hvis brugeren på forhånd havde aftalt at tage sig af trin 2 (dvs. dataekstraktion), og derefter fejlede i ekstraktionsprocessen? I dette tilfælde kunne det være muligt, at brugeren ville blive anklaget for at have overtrådt sin samarbejdspligt, fordi de ikke havde undersøgt på forhånd, om dataekstraktionen kunne forløbe gnidningsløst, hvilket resulterede i forsinkelser i leveringstiden.

Desuden baseres sådanne afgørelser ikke kun på kontrakten, men også på mødereferater, der er tilpasset fremskridtene i systemudviklingen. Vigtigheden af mødereferater er detaljeret forklaret i artiklen nedenfor.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Opsummering

Et projekt som systemudvikling kræver, at både brugere og leverandører påtager sig mange gensidige forpligtelser og kommunikerer omhyggeligt undervejs. Derfor kan det i de tidligere nævnte retssager ses, at selv mindre ændringer i forudsætningerne kan let skifte ansvaret mellem brugeren og leverandøren.

Der er en mulighed for, at systemet kan indeholde en enorm mængde data og komplekse mekanismer, der er umulige at forestille sig fra skærmens udseende. Der er også en mulighed for, at en lille forskel i forudsætningerne kan ændre retning af den endelige juridiske afgørelse. Derfor kan det siges, at det er vigtigt at se risikostyring af nye systemudviklingsprojekter i en omfattende kontekst, herunder fjernelse af gamle systemer.