{"id":61446,"date":"2023-12-08T20:55:29","date_gmt":"2023-12-08T11:55:29","guid":{"rendered":"https:\/\/monolith.law\/no\/?p=61446"},"modified":"2023-12-29T20:26:39","modified_gmt":"2023-12-29T11:26:39","slug":"the-transition-from-the-oldsystem","status":"publish","type":"post","link":"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem","title":{"rendered":"Juridiske problemer knyttet til overgangen fra gamle systemer i systemutvikling"},"content":{"rendered":"\n<p>\u00c5 utvikle nye IT-systemer for bruk i bedrifter er et typisk arbeidsomr\u00e5de for IT-ingeni\u00f8rer. Men n\u00e5r vi snakker om \u00e5 &#8220;lage et nytt system&#8221;, inneb\u00e6rer det ofte ogs\u00e5 prosessen med \u00e5 &#8220;fjerne det gamle systemet&#8221; som har blitt brukt tidligere. I denne artikkelen vil vi ta en ny tiln\u00e6rming til prosjektet med \u00e5 utvikle nye systemer ved \u00e5 fokusere p\u00e5 aspektet av &#8220;fjerning av det gamle systemet&#8221;, og vi vil forklare de ulike juridiske problemene som f\u00f8lger med det.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Hva_innebaerer_det_a_overfore_til_et_nytt_system\" title=\"Hva inneb\u00e6rer det \u00e5 overf\u00f8re til et nytt system?\">Hva inneb\u00e6rer det \u00e5 overf\u00f8re til et nytt system?<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#IT-systemers_levetid_er_ikke_evig\" title=\"IT-systemers levetid er ikke evig\">IT-systemers levetid er ikke evig<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Utviklingen_av_det_nye_systemet_skjer_parallelt_med_avviklingen_av_det_gamle_systemet\" title=\"Utviklingen av det nye systemet skjer parallelt med avviklingen av det gamle systemet\">Utviklingen av det nye systemet skjer parallelt med avviklingen av det gamle systemet<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Hva_er_trinnene_for_overgang_til_et_nytt_system\" title=\"Hva er trinnene for overgang til et nytt system?\">Hva er trinnene for overgang til et nytt system?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Overgang_til_nytt_system_er_vanskelig_med_tanke_pa_a_klargjore_roller_mellom_brukere_og_leverandorer\" title=\"Overgang til nytt system er vanskelig med tanke p\u00e5 \u00e5 klargj\u00f8re roller mellom brukere og leverand\u00f8rer\">Overgang til nytt system er vanskelig med tanke p\u00e5 \u00e5 klargj\u00f8re roller mellom brukere og leverand\u00f8rer<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Tidligere_rettsavgjorelser_knyttet_til_overgangen_til_nye_systemer\" title=\"Tidligere rettsavgj\u00f8relser knyttet til overgangen til nye systemer\">Tidligere rettsavgj\u00f8relser knyttet til overgangen til nye systemer<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/no\/it\/the-transition-from-the-oldsystem\/#Oppsummering\" title=\"Oppsummering\">Oppsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_innebaerer_det_a_overfore_til_et_nytt_system\"><\/span>Hva inneb\u00e6rer det \u00e5 overf\u00f8re til et nytt system?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"IT-systemers_levetid_er_ikke_evig\"><\/span>IT-systemers levetid er ikke evig<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>IT-systemer som brukes i bedrifter er ikke noe som, n\u00e5r de f\u00f8rst er laget, kan brukes kontinuerlig for alltid. Dessuten er det ikke alltid bra \u00e5 fortsette \u00e5 bruke gamle ting n\u00f8ye. Selv om det selvf\u00f8lgelig varierer fra bedrift til bedrift og etter systemets form\u00e5l, er det en tendens til at en ledelsesbeslutning blir tatt om at det er bedre \u00e5 fornye til noe nytt etter omtrent ti \u00e5r med bruk av et system.<\/p>\n\n\n\n<p>Etter ti \u00e5r vil ytelsen til datamaskiner p\u00e5 markedet ha endret seg dramatisk. For eksempel, selv om det var et program som ikke kunne implementeres p\u00e5 grunn av begrensninger som datamaskinens prosesseringshastighet for ti \u00e5r siden (selv om det er en enkel og utmerket design fra et menneskelig perspektiv), kan det n\u00e5 v\u00e6re mulig \u00e5 implementere det. I tillegg, hvis du har brukt det kontinuerlig i ti \u00e5r siden du f\u00f8rst laget det, kan arbeidsflyten i selskapets virksomhet og interne regler ha endret seg betydelig i l\u00f8pet av den tiden. Koden som har blitt implementert etterp\u00e5 for \u00e5 h\u00e5ndtere endringer i selskapets interne og eksterne forretningsmilj\u00f8 kan ha blitt s\u00e5 komplisert og intrikat at den ikke kan gjenkjennes fra skjermen. I slike tilfeller kan det hende at det gradvis blir umulig for utviklere \u00e5 legge til nye funksjoner som brukerne \u00f8nsker.<\/p>\n\n\n\n<p>Eldre systemer kan gradvis f\u00f8re til at IT-ingeni\u00f8rer utf\u00f8rer mye &#8220;manuelt arbeid&#8221; (for eksempel operasjonelle oppgaver som \u00e5 utstede sp\u00f8rringer for \u00e5 trekke ut data individuelt). Ironisk nok, jo eldre systemet blir, jo mer &#8220;personavhengig&#8221; blir arbeidet. N\u00e5r det er mange personavhengige oppgaver i forbindelse med et system som har blitt for gammelt, og du pr\u00f8ver \u00e5 ta tiltak for ytterligere &#8220;systematisering&#8221;, vil det oppst\u00e5 et prosjekt for &#8220;utvikling av et nytt system for overgang fra det gamle systemet&#8221;.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Utviklingen_av_det_nye_systemet_skjer_parallelt_med_avviklingen_av_det_gamle_systemet\"><\/span>Utviklingen av det nye systemet skjer parallelt med avviklingen av det gamle systemet<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Som nevnt tidligere, selv om ikke alle systemutviklingsprosjekter er slik, er det ofte slik at et enkelt systemutviklingsprosjekt ogs\u00e5 inneb\u00e6rer en overgang fra det gamle systemet. Systemet i seg selv vil ofte skifte diskontinuerlig fra en dag til en annen.<\/p>\n\n\n\n<p>Men den daglige driftsprosessen skal v\u00e6re kontinuerlig fra fortiden, gjennom n\u00e5tiden og inn i fremtiden. Mens n\u00f8dvendige data fra fortiden blir lagret, skal den n\u00e5v\u00e6rende driftsprosessen ikke hindres, og det er ofte mange utfordringer forbundet med overgangen til det nye systemet, som \u00e5 fremme en overlegen &#8220;systematisering&#8221; -konsept for fremtiden. P\u00e5 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\u00e5 situasjoner der de blir uatskillelige.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hva_er_trinnene_for_overgang_til_et_nytt_system\"><\/span>Hva er trinnene for overgang til et nytt system?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_25686103_M-1024x634.jpg\" alt=\"\" class=\"wp-image-2758\" \/><figcaption class=\"wp-element-caption\">Hva er de viktige trinnene for overgang fra det gamle systemet til det nye systemet?<\/figcaption><\/figure>\n\n\n\n<p>N\u00e5r man overf\u00f8rer fra det gamle systemet til det nye, blir det spesielt viktig \u00e5 overf\u00f8re dataene p\u00e5 riktig m\u00e5te. Trinnene for dataoverf\u00f8ring f\u00f8lger ofte denne generelle prosedyren:<\/p>\n\n\n\n<ol>\n<li>Identifiser hvilke data som er lagret i det gamle systemet som b\u00f8r overf\u00f8res til det nye systemet. Dette inkluderer \u00e5 identifisere hvilke data som b\u00f8r v\u00e6re lett s\u00f8kbare fra det nye systemets brukergrensesnitt, samt hvilke data som kanskje ikke trenger \u00e5 v\u00e6re s\u00f8kbare, men som b\u00f8r v\u00e6re tilgjengelige for uttrekk ved behov (for eksempel for revisjon).<\/li>\n\n\n\n<li>Eksporter dataene som ble identifisert i trinn 1 til det nye systemet, for eksempel i form av en CSV-fil.<\/li>\n\n\n\n<li>Importer dataene som ble trukket ut i trinn 2 inn i det nye systemet.<\/li>\n\n\n\n<li>Verifiser at dataene som ble importert i trinn 3 er reflektert i det nye systemet, og bekreft at overf\u00f8ringen har blitt utf\u00f8rt korrekt. Bevis p\u00e5 verifiseringen, som skjermbilder eller utskrifter, blir vanligvis bevart (dette er den s\u00e5kalte testprosessen).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Overgang_til_nytt_system_er_vanskelig_med_tanke_pa_a_klargjore_roller_mellom_brukere_og_leverandorer\"><\/span>Overgang til nytt system er vanskelig med tanke p\u00e5 \u00e5 klargj\u00f8re roller mellom brukere og leverand\u00f8rer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>I trinnene for datamigrering nevnt tidligere, er et problem som ofte oppst\u00e5r, hvor langt brukerne skal behandle dette som et internt problem i sin egen organisasjon. For en generell oversikt over &#8220;brukerens samarbeidsplikt&#8221; i systemutviklingsprosjekter generelt, ikke bare i forbindelse med datamigrering, vennligst se artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/user-obligatory-cooperation\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/user-obligatory-cooperation[ja]<\/a><\/p>\n\n\n\n<p>Generelt sett, i et systemutviklingsprosjekt, er det ofte slik at leverand\u00f8ren har en fordel over brukeren n\u00e5r det gjelder spesialisert kunnskap for systemutvikling (eller snarere, det er ofte grunnen til at de er tildelt oppgaven). P\u00e5 den annen side, er det ofte slik at bare brukersiden kan diskutere &#8220;hvordan systemet skal v\u00e6re&#8221;.<\/p>\n\n\n\n<p>Med dette i betraktning, kan det v\u00e6re en mulighet \u00e5 klargj\u00f8re at brukeren skal utf\u00f8re trinn 1 og 4 nevnt tidligere. For \u00e5 si det p\u00e5 en annen m\u00e5te, det kan v\u00e6re en metode \u00e5 organisere det slik at &#8220;kravspesifikasjonen&#8221; for dataene som skal migreres, og &#8220;akseptansen&#8221; av om dataene har blitt migrert i henhold til kravene, er brukerens samarbeidsplikt. Eller, som en annen m\u00e5te \u00e5 organisere det p\u00e5, hvis det er noen p\u00e5 brukersiden som har omfattende kunnskap om det gamle systemet, kan det v\u00e6re mulig \u00e5 ogs\u00e5 gj\u00f8re trinn 2 til brukerens ansvar.<\/p>\n\n\n\n<p>Hvis det er mulig \u00e5 h\u00e5ndtere det gamle systemet internt uten \u00e5 m\u00e5tte outsource det, kan det v\u00e6re at man \u00f8nsker \u00e5 outsource bare det nye systemet til leverand\u00f8ren. P\u00e5 denne m\u00e5ten kan rollene mellom bruker og leverand\u00f8r bli noe uklare i datamigreringsprosessen. For en generell forklaring p\u00e5 hva slags roller som forventes av leverand\u00f8ren, og hvilke juridiske forpliktelser som p\u00e5ligger dem n\u00e5r brukeren outsourcer systemutviklingsrelaterte oppgaver til leverand\u00f8ren, vennligst se ogs\u00e5 artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/project-management-duties\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/project-management-duties[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Tidligere_rettsavgjorelser_knyttet_til_overgangen_til_nye_systemer\"><\/span>Tidligere rettsavgj\u00f8relser knyttet til overgangen til nye systemer<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_45516155_M-1024x682.jpg\" alt=\"\" class=\"wp-image-2759\" \/><figcaption class=\"wp-element-caption\">Det kan oppst\u00e5 rettssaker i prosjekter for overgang til nye systemer.<\/figcaption><\/figure>\n\n\n\n<p>Det finnes faktiske tilfeller der problemer har oppst\u00e5tt i systemutviklingsprosjekter som sikter mot overgang til nye systemer, og som har resultert i rettssaker. Saken sitert nedenfor involverte feil under dataoverf\u00f8ring, noe som f\u00f8rte til flere datainkonsekvenser og bugs i det nye systemet, samt forsinkelser i leveringstiden. Det ble diskutert hvilke forpliktelser leverand\u00f8rsiden og brukersiden hadde i prosjektet i forhold til disse forskjellige problemene. Konklusjonen var at leverand\u00f8ren hadde brutt sin plikt til \u00e5 utvise forsiktighet, som inkluderte f\u00f8lgende punkter:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Defendant, i henhold til kontrakten for dataoverf\u00f8ring, hadde ikke bare ansvaret for \u00e5 overf\u00f8re data fra det gamle systemet til det nye, men ogs\u00e5 for \u00e5 sikre at det nye systemet kunne operere med de overf\u00f8rte dataene. Spesifikt, f\u00f8r de startet dataoverf\u00f8ringen, skulle de unders\u00f8ke og analysere dataene som skulle overf\u00f8res fra det gamle systemet, forst\u00e5 dataenes natur og tilstand, vurdere om disse dataene ville hindre driften av det nye systemet etter overf\u00f8ring, og hvis det var tilfelle, bestemme n\u00e5r og hvordan de skulle korrigere disse dataene. De skulle deretter g\u00e5 videre med dataoverf\u00f8ringen (overf\u00f8ringsdesign, utvikling av overf\u00f8ringsverkt\u00f8y, dataoverf\u00f8ring), og til slutt hadde de ansvaret for \u00e5 sikre at det nye systemet kunne operere med dataene som ble overf\u00f8rt fra det gamle systemet.<\/p>\n\n\n\n<p>Det er rimelig \u00e5 anerkjenne at i denne saken, ved dataoverf\u00f8ring, hadde de en plikt til \u00e5 rette opp og l\u00f8se datainkonsekvenser.<\/p>\n<cite>Tokyo District Court, November 30, Heisei 28 (2016)<\/cite><\/blockquote>\n\n\n\n<p>I denne saken var det opprinnelig avtalt at brukersiden skulle ta seg av trinn 1 og trinn 4, mens leverand\u00f8rsiden skulle ta seg av trinn 2 og trinn 3. Med andre ord, leverand\u00f8rsiden hadde p\u00e5tatt seg ansvaret for \u00e5 trekke ut dataene fra det gamle systemet (trinn 2). Derfor konkluderte retten med at leverand\u00f8ren, som en spesialist innen systemutvikling, skulle ha vurdert p\u00e5 forh\u00e5nd om datauttrekkingen kunne utf\u00f8res jevnt.<\/p>\n\n\n\n<p>Men hva ville ha skjedd hvis brukersiden hadde p\u00e5tatt seg ansvaret for trinn 2 (det vil si datauttrekking) og feilet i denne oppgaven? I dette tilfellet kunne det ha v\u00e6rt mulig at brukersiden, som hadde fors\u00f8mt \u00e5 unders\u00f8ke p\u00e5 forh\u00e5nd om datauttrekkingen kunne utf\u00f8res jevnt, og som dermed hadde for\u00e5rsaket forsinkelser i leveringstiden, kunne ha blitt anklaget for brudd p\u00e5 sin samarbeidsplikt.<\/p>\n\n\n\n<p>I tillegg blir slike avgj\u00f8relser tatt basert p\u00e5 bevis som ikke bare inkluderer kontrakten, men ogs\u00e5 m\u00f8tereferater som er tilpasset fremdriften i systemutviklingen. Viktigheten av m\u00f8tereferater er forklart i detalj i artikkelen nedenfor.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Oppsummering\"><\/span>Oppsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>Et prosjekt som systemutvikling krever at b\u00e5de brukersiden og leverand\u00f8rsiden tar p\u00e5 seg mange forpliktelser og kommuniserer n\u00f8ye med hverandre. Derfor, selv i de rettssakene vi har nevnt tidligere, kan skyldsp\u00f8rsm\u00e5let lett skifte mellom bruker og leverand\u00f8r bare ved \u00e5 endre noen f\u00e5 forutsetninger.<\/p>\n\n\n\n<p>Med tanke p\u00e5 at systemet kan inneholde enorme mengder data og komplekse mekanismer som er umulige \u00e5 forestille seg fra skjermens utseende, og at en liten forskjell i forutsetningene kan endre utfallet av en juridisk avgj\u00f8relse, kan vi si at det er viktig \u00e5 ha en omfattende tiln\u00e6rming til risikostyring i nye systemutviklingsprosjekter, inkludert fjerning av gamle systemer.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u00c5 utvikle nye IT-systemer for bruk i bedrifter er et typisk arbeidsomr\u00e5de for IT-ingeni\u00f8rer. Men n\u00e5r vi snakker om \u00e5 &#8220;lage et nytt system&#8221;, inneb\u00e6rer det ofte ogs\u00e5 prosessen med \u00e5 &#8220;f [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":62642,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61446"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=61446"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61446\/revisions"}],"predecessor-version":[{"id":62641,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/61446\/revisions\/62641"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/62642"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=61446"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=61446"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=61446"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}