Juridiske problemer knyttet til overgangen fra gamle systemer i systemutvikling

Å utvikle nye IT-systemer for bruk i bedrifter er et typisk arbeidsområde for IT-ingeniører. Men når vi snakker om å “lage et nytt system”, innebærer det ofte også prosessen med å “fjerne det gamle systemet” som har blitt brukt tidligere. I denne artikkelen vil vi ta en ny tilnærming til prosjektet med å utvikle nye systemer ved å fokusere på aspektet av “fjerning av det gamle systemet”, og vi vil forklare de ulike juridiske problemene som følger med det.

Hva innebærer det å overføre til et nytt system?

IT-systemers levetid er ikke evig

IT-systemer som brukes i bedrifter er ikke noe som, når de først er laget, kan brukes kontinuerlig for alltid. Dessuten er det ikke alltid bra å fortsette å bruke gamle ting nøye. Selv om det selvfølgelig varierer fra bedrift til bedrift og etter systemets formål, er det en tendens til at en ledelsesbeslutning blir tatt om at det er bedre å fornye til noe nytt etter omtrent ti år med bruk av et system.

Etter ti år vil ytelsen til datamaskiner på markedet ha endret seg dramatisk. For eksempel, selv om det var et program som ikke kunne implementeres på grunn av begrensninger som datamaskinens prosesseringshastighet for ti år siden (selv om det er en enkel og utmerket design fra et menneskelig perspektiv), kan det nå være mulig å implementere det. I tillegg, hvis du har brukt det kontinuerlig i ti år siden du først laget det, kan arbeidsflyten i selskapets virksomhet og interne regler ha endret seg betydelig i løpet av den tiden. Koden som har blitt implementert etterpå for å håndtere endringer i selskapets interne og eksterne forretningsmiljø kan ha blitt så komplisert og intrikat at den ikke kan gjenkjennes fra skjermen. I slike tilfeller kan det hende at det gradvis blir umulig for utviklere å legge til nye funksjoner som brukerne ønsker.

Eldre systemer kan gradvis føre til at IT-ingeniører utfører mye “manuelt arbeid” (for eksempel operasjonelle oppgaver som å utstede spørringer for å trekke ut data individuelt). Ironisk nok, jo eldre systemet blir, jo mer “personavhengig” blir arbeidet. Når det er mange personavhengige oppgaver i forbindelse med et system som har blitt for gammelt, og du prøver å ta tiltak for ytterligere “systematisering”, vil det oppstå et prosjekt for “utvikling av et nytt system for overgang fra det gamle systemet”.

Utviklingen av det nye systemet skjer parallelt med avviklingen av det gamle systemet

Som nevnt tidligere, selv om ikke alle systemutviklingsprosjekter er slik, er det ofte slik at et enkelt systemutviklingsprosjekt også innebærer en overgang fra det gamle systemet. Systemet i seg selv vil ofte skifte diskontinuerlig fra en dag til en annen.

Men den daglige driftsprosessen skal være kontinuerlig fra fortiden, gjennom nåtiden og inn i fremtiden. Mens nødvendige data fra fortiden blir lagret, skal den nåværende driftsprosessen ikke hindres, og det er ofte mange utfordringer forbundet med overgangen til det nye systemet, som å fremme en overlegen “systematisering” -konsept for fremtiden. På grunn av disse komplekse omstendighetene, blir utviklingen av det nye systemet og driften og vedlikeholdet av det eksisterende systemet komplekst relatert, og det kan oppstå situasjoner der de blir uatskillelige.

Hva er trinnene for overgang til et nytt system?

Når man overfører fra det gamle systemet til det nye, blir det spesielt viktig å overføre dataene på riktig måte. Trinnene for dataoverføring følger ofte denne generelle prosedyren:

1. Identifiser hvilke data som er lagret i det gamle systemet som bør overføres til det nye systemet. Dette inkluderer å identifisere hvilke data som bør være lett søkbare fra det nye systemets brukergrensesnitt, samt hvilke data som kanskje ikke trenger å være søkbare, men som bør være tilgjengelige for uttrekk ved behov (for eksempel for revisjon).
2. Eksporter dataene som ble identifisert i trinn 1 til det nye systemet, for eksempel i form av en CSV-fil.
3. Importer dataene som ble trukket ut i trinn 2 inn i det nye systemet.
4. Verifiser at dataene som ble importert i trinn 3 er reflektert i det nye systemet, og bekreft at overføringen har blitt utført korrekt. Bevis på verifiseringen, som skjermbilder eller utskrifter, blir vanligvis bevart (dette er den såkalte testprosessen).

Overgang til nytt system er vanskelig med tanke på å klargjøre roller mellom brukere og leverandører

I trinnene for datamigrering nevnt tidligere, er et problem som ofte oppstår, hvor langt brukerne skal behandle dette som et internt problem i sin egen organisasjon. For en generell oversikt over “brukerens samarbeidsplikt” i systemutviklingsprosjekter generelt, ikke bare i forbindelse med datamigrering, vennligst se artikkelen nedenfor.

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

Generelt sett, i et systemutviklingsprosjekt, er det ofte slik at leverandøren har en fordel over brukeren når det gjelder spesialisert kunnskap for systemutvikling (eller snarere, det er ofte grunnen til at de er tildelt oppgaven). På den annen side, er det ofte slik at bare brukersiden kan diskutere “hvordan systemet skal være”.

Med dette i betraktning, kan det være en mulighet å klargjøre at brukeren skal utføre trinn 1 og 4 nevnt tidligere. For å si det på en annen måte, det kan være en metode å organisere det slik at “kravspesifikasjonen” for dataene som skal migreres, og “akseptansen” av om dataene har blitt migrert i henhold til kravene, er brukerens samarbeidsplikt. Eller, som en annen måte å organisere det på, hvis det er noen på brukersiden som har omfattende kunnskap om det gamle systemet, kan det være mulig å også gjøre trinn 2 til brukerens ansvar.

Hvis det er mulig å håndtere det gamle systemet internt uten å måtte outsource det, kan det være at man ønsker å outsource bare det nye systemet til leverandøren. På denne måten kan rollene mellom bruker og leverandør bli noe uklare i datamigreringsprosessen. For en generell forklaring på hva slags roller som forventes av leverandøren, og hvilke juridiske forpliktelser som påligger dem når brukeren outsourcer systemutviklingsrelaterte oppgaver til leverandøren, vennligst se også artikkelen nedenfor.

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

Tidligere rettsavgjørelser knyttet til overgangen til nye systemer

Det finnes faktiske tilfeller der problemer har oppstått i systemutviklingsprosjekter som sikter mot overgang til nye systemer, og som har resultert i rettssaker. Saken sitert nedenfor involverte feil under dataoverføring, noe som førte til flere datainkonsekvenser og bugs i det nye systemet, samt forsinkelser i leveringstiden. Det ble diskutert hvilke forpliktelser leverandørsiden og brukersiden hadde i prosjektet i forhold til disse forskjellige problemene. Konklusjonen var at leverandøren hadde brutt sin plikt til å utvise forsiktighet, som inkluderte følgende punkter:

Defendant, i henhold til kontrakten for dataoverføring, hadde ikke bare ansvaret for å overføre data fra det gamle systemet til det nye, men også for å sikre at det nye systemet kunne operere med de overførte dataene. Spesifikt, før de startet dataoverføringen, skulle de undersøke og analysere dataene som skulle overføres fra det gamle systemet, forstå dataenes natur og tilstand, vurdere om disse dataene ville hindre driften av det nye systemet etter overføring, og hvis det var tilfelle, bestemme når og hvordan de skulle korrigere disse dataene. De skulle deretter gå videre med dataoverføringen (overføringsdesign, utvikling av overføringsverktøy, dataoverføring), og til slutt hadde de ansvaret for å sikre at det nye systemet kunne operere med dataene som ble overført fra det gamle systemet.

Det er rimelig å anerkjenne at i denne saken, ved dataoverføring, hadde de en plikt til å rette opp og løse datainkonsekvenser.

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

I denne saken var det opprinnelig avtalt at brukersiden skulle ta seg av trinn 1 og trinn 4, mens leverandørsiden skulle ta seg av trinn 2 og trinn 3. Med andre ord, leverandørsiden hadde påtatt seg ansvaret for å trekke ut dataene fra det gamle systemet (trinn 2). Derfor konkluderte retten med at leverandøren, som en spesialist innen systemutvikling, skulle ha vurdert på forhånd om datauttrekkingen kunne utføres jevnt.

Men hva ville ha skjedd hvis brukersiden hadde påtatt seg ansvaret for trinn 2 (det vil si datauttrekking) og feilet i denne oppgaven? I dette tilfellet kunne det ha vært mulig at brukersiden, som hadde forsømt å undersøke på forhånd om datauttrekkingen kunne utføres jevnt, og som dermed hadde forårsaket forsinkelser i leveringstiden, kunne ha blitt anklaget for brudd på sin samarbeidsplikt.

I tillegg blir slike avgjørelser tatt basert på bevis som ikke bare inkluderer kontrakten, men også møtereferater som er tilpasset fremdriften i systemutviklingen. Viktigheten av møtereferater er forklart i detalj i artikkelen nedenfor.

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

Oppsummering

Et prosjekt som systemutvikling krever at både brukersiden og leverandørsiden tar på seg mange forpliktelser og kommuniserer nøye med hverandre. Derfor, selv i de rettssakene vi har nevnt tidligere, kan skyldspørsmålet lett skifte mellom bruker og leverandør bare ved å endre noen få forutsetninger.

Med tanke på at systemet kan inneholde enorme mengder data og komplekse mekanismer som er umulige å forestille seg fra skjermens utseende, og at en liten forskjell i forutsetningene kan endre utfallet av en juridisk avgjørelse, kan vi si at det er viktig å ha en omfattende tilnærming til risikostyring i nye systemutviklingsprosjekter, inkludert fjerning av gamle systemer.