MONOLITH LAW OFFICE+81-3-6262-3248Hverdager 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Hva er lovene knyttet til konflikter og problemer i systemdriftsfasen?

IT

Hva er lovene knyttet til konflikter og problemer i systemdriftsfasen?

Det er velkjent at det kan oppstå ulike konflikter og problemer i prosjekter som utvikler IT-systemer. Men det er ikke slik at alt er trygt så lenge hele utviklingsprosessen er fullført uten problemer. IT-systemer som brukes i bedrifter håndterer vanligvis store mengder konfidensiell informasjon og personopplysninger, og det kan oppstå ulike problemer selv i driftsfasen. Derfor er det viktig å bruke juridisk kunnskap for å vurdere og forhindre slike situasjoner også i driftsfasen.

Hvordan endres juridiske diskusjoner rundt systemer med utvikling og drift?

Hva er de juridiske problemene knyttet til “utvikling” og “drift” av IT-systemer?

Et typisk eksempel på juridiske problemer knyttet til IT-systemer som brukes i bedrifter, er utvilsomt “brann” problemer i “utviklings” fasen av prosjektet. Systemutviklingsprosjekter er ofte store prosjekter som krever mange mennesker, penger og tid, og de går vanligvis fremover mens de bærer risikoen for forskjellige konflikter og problemer, store eller små.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

I artikkelen ovenfor har vi organisert typene konflikter som ofte oppstår i en serie systemutviklingsprosjekter i henhold til juridiske rammer. I tillegg er det som karakteriserer juridiske problemer knyttet til IT-systemer, “prosjektledelsesplikten” som leverandøren, som er en ekspert på systemutvikling, antas å bære omfattende.

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

Imidlertid går IT-systemer inn i en “drifts” fase etter “utvikling”. Drift av IT-systemer, for å si det enkelt, betyr å bruke og betjene det utviklede systemet for å utføre faktiske oppgaver. Siden det ofte er nødvendig å være godt kjent med spesifikasjonene for å bruke IT-systemet, er det ofte nødvendig med IT-teknikere her også. Det faktum at teknisk kunnskap er nødvendig for både utvikling og drift av IT-systemer betyr at skillet mellom de to kan være uklart i praksis. Et eksempel som tydelig viser dette er eksistensen av “supportplikt”.

https://monolith.law/corporate/support-obligations-of-vendors-after-system-development[ja]

I artikkelen ovenfor introduserer vi en rettsavgjørelse som anerkjenner “supportplikt” som en plikt til å gi støtte for drift og implementering etter utvikling, i motsetning til “prosjektledelsesplikten” som leverandøren bærer under systemutviklingsprosjektet. Med andre ord, det er tilfeller der leverandørens juridiske plikter blir bestemt mens man tar hensyn til forholdene i den etterfølgende driftsfasen. I tillegg, når utviklingen av et nytt system går fremover samtidig som det gamle systemet blir avskaffet, kan “dataoverføring” fra det gamle systemet være et problem. I slike tilfeller vil driften av det gamle systemet og utviklingen av det nye systemet være nært knyttet sammen.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Hvordan bør juridiske problemer knyttet til systemdrift organiseres?

Vi har nå sett at praksis knyttet til IT-systemer er tett sammenvevd mellom “utvikling” og “drift”. Imidlertid, i driftsfasen, siden utviklingsprosjektet er avsluttet, er det nødvendig å tenke på problemene med “prosjektledelsesplikt” separat. For å diskutere juridiske problemer med “utvikling” og “drift” på en enhetlig måte, er det nødvendig å organisere dem i en litt mer juridisk orientert, høyere abstraksjonsramme. For eksempel er organiseringen fra perspektivet av juridisk “ansvar” knyttet til IT-systemer, som forklart i artikkelen nedenfor, et eksempel på dette.

https://monolith.law/corporate/responsibility-system-development[ja]

I artikkelen ovenfor forklarer vi om sivilrettslig ansvar for kontraktsbrudd, garantiansvar for mangler, og ansvar for ulovlige handlinger, med tanke på konteksten til IT-systemer. Imidlertid er det ikke mange tilfeller der garantiansvar for mangler blir et problem i drift, bortsett fra tilfeller der feil blir oppdaget etter aksept. Derfor bør du først organisere med tanke på ansvar for kontraktsbrudd basert på kontraktsinnholdet, og ansvar for ulovlige handlinger som ikke forutsetter en kontraktsrelasjon.

Vurder først om det er brudd på leverandørens plikter

Hvis det er ansvar for kontraktsbrudd, blir brudd på kontraktsmessige forpliktelser et problem, og hvis det er ansvar for ulovlige handlinger, blir det et spørsmål om det er en realitet som “krenkelse av andres rettigheter”. I tilfelle av ansvar for kontraktsbrudd, vil innholdet i Service Level Agreement (SLA) være et problem. Vær også oppmerksom på at både ansvar for kontraktsbrudd og ansvar for ulovlige handlinger krever forsett eller uaktsomhet.

Sjekk deretter brukerens skadesituasjon

Erstatningsplikt er noe du bærer i forhold til skaden som har oppstått på brukersiden. Derfor, enten det er kontraktsbrudd eller ulovlig handling, vil du ikke pådra deg erstatningsplikt hvis det ikke har oppstått skade på brukersiden.

Vurder også muligheten for uaktsomhetsavregning og anvendelse av ansvarsbegrensningsklausuler

Imidlertid, selv om leverandørsiden kan pådra seg erstatningsplikt, kan det også tenkes at det vil bli gjort en uaktsomhetsavregning hvis det også er en form for uaktsomhet på brukersiden. I tillegg, hvis det er satt en grense for erstatningsbeløpet i kontrakten som ble inngått på forhånd, kan erstatningsbeløpet endres avhengig av det. For eksempel, i den representative malen for kontrakter kalt “Ministry of Economy, Trade and Industry Model Contract”, er det satt følgende bestemmelser om ansvarsbegrensning (understrekingen er lagt til av forfatteren).

(Erstatning)
Artikkel 53 A og B kan kreve erstatning fra den andre parten hvis de lider skade på grunn av årsaker som kan tilskrives den andre parten i forbindelse med utførelsen av denne kontrakten og individuelle kontrakter. Imidlertid kan denne forespørselen ikke gjøres etter at ○ måneder har gått siden fullføringen av aksept av leveransen eller bekreftelsen av slutten av arbeidet som er angitt i den individuelle kontrakten som er årsaken til forespørselen om erstatning.

2. Det totale beløpet av erstatning i henhold til foregående ledd skal, uavhengig av årsaken til kravet, være begrenset til beløpet angitt i den individuelle kontrakten som forårsaket årsaken til ansvar.

3. Foregående ledd skal ikke gjelde i tilfeller basert på forsett eller grov uaktsomhet fra den ansvarlige for erstatningsplikten.

Hva er typiske problemer og konflikter som kan oppstå ved systemdrift?

Hva bør man være oppmerksom på for å løse problemer og konflikter i systemdriften?

I praksis er det flere typiske problemer og konflikter som kan oppstå ved systemdrift. Noen av disse er:

Tap av data på grunn av feil fra driftspersonalet

Arbeidet med systemdrift innebærer ofte håndtering av viktig bedriftshemmeligheter og personopplysninger, og ulykker kan skje på grunn av uforsiktighet. Et eksempel på dette er “tap av data”. Vi har en detaljert forklaring på dette i artikkelen nedenfor.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Det er viktig å ta forhåndsregler, som å ta sikkerhetskopi av data, for å forhindre ulykker som tap av data. Hvis slike tiltak er forsømt, kan det være svært vanskelig å holde leverandøren som har fått driftsoppgavene ansvarlig, så det er viktig å være forsiktig.

Sikkerhetsangrep, inkludert virus

I tillegg, i tilfelle av IT-systemer som brukes av et stort antall mennesker på nettet, som e-handelsnettsteder, kan det oppstå store hendelser eller ulykker på grunn av sikkerhetsangrep, inkludert virus. Det kan være en del av driftsoppgavene å oppdage slike sikkerhetsangrep og ta forholdsregler.

Bugs og feil som blir oppdaget etter godkjenning

Det kan også være tilfeller der bugs og feil blir oppdaget etter godkjenning. Det er ikke alltid mulig å fullstendig vurdere alle potensielle bugs og feil i testfasen, og noen kan bli oppdaget etterpå. I slike tilfeller er leveransen vanligvis ansett som fullført, og ytelsen av forpliktelsen er ansett som fullført, og man er normalt unntatt fra ansvar for mislighold. Imidlertid kan det være tilfeller der erstatningskrav basert på garantiansvar for mangler er anerkjent. Vi har en detaljert forklaring på dette i artikkelen nedenfor.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Oppsummering

I fasen som kalles “drift” av systemet, finnes det mange problemer og konflikter som er forskjellige fra utviklingsprosjekter. Imidlertid, ved å basere seg på juridiske teorier som ansvar for kontraktsbrudd, ulovlig handling, og ansvar for mangler, er det mulig å organisere et enhetlig felt uten å bli fanget av disse forskjellene.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Tilbake til toppen