Wat is de wetgeving rondom geschillen en problemen in de fase van systeembeheer?

Het is algemeen bekend dat er in projecten voor de ontwikkeling van IT-systemen verschillende conflicten en problemen kunnen ontstaan. Echter, het is niet zo dat alles in orde is zodra alle stadia van een dergelijk ontwikkelingsproject succesvol zijn afgerond. IT-systemen die in bedrijven worden gebruikt, behandelen vanwege hun aard meestal grote hoeveelheden vertrouwelijke en persoonlijke informatie, en er kunnen ook op operationeel niveau verschillende problemen ontstaan. Daarom is het belangrijk om juridische kennis te gebruiken om maatregelen te overwegen en te voorkomen voor dergelijke situaties, ook op operationeel niveau.

Hoe verandert de juridische discussie rond systemen bij ontwikkeling en operatie?

Een typisch juridisch probleem met betrekking tot IT-systemen die in bedrijven worden gebruikt, is ongetwijfeld het ‘brandende’ probleem van projecten in de ‘ontwikkelings’ fase. Systeemontwikkelingsprojecten, die vaak grootschalige ondernemingen zijn waarbij veel mankracht, geld en tijd worden geïnvesteerd, gaan meestal gepaard met verschillende conflicten en problemen, groot of klein.

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

In het bovenstaande artikel worden de soorten conflicten die vaak voorkomen in een reeks systeemontwikkelingsprojecten georganiseerd volgens een juridisch kader. Bovendien, wat de juridische problemen rond IT-systemen kenmerkt, is de ‘projectmanagementverplichting’ die wordt geacht te worden gedragen door de systeemontwikkelingsexpert, de leverancier.

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

Echter, na de ‘ontwikkeling’ van het IT-systeem, gaat het over naar de ‘operatie’ fase. In één woord, operatie in IT-systemen betekent het gebruik en de bediening van het ontwikkelde systeem om daadwerkelijke taken uit te voeren. Omdat het vaak nodig is om de specificaties van het IT-systeem goed te kennen om het te kunnen gebruiken, is de hulp van IT-technici vaak nodig. Het feit dat technische kennis vereist is in zowel de ontwikkeling als de operatie van IT-systemen betekent dat de scheiding tussen de twee in de praktijk vaag kan zijn. Een voorbeeld dat dit duidelijk illustreert, is het bestaan van ‘ondersteuningsverplichtingen’.

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

In het bovenstaande artikel wordt een rechtszaak geïntroduceerd die de ‘ondersteuningsverplichting’ erkent als een verplichting om ondersteuning te bieden voor de operatie en implementatie na de ontwikkeling, onderscheiden van de ‘projectmanagementverplichting’ die de leverancier draagt tijdens het systeemontwikkelingsproject. Met andere woorden, er zijn gevallen waarin de wettelijke verplichtingen van de leverancier die de ontwikkelingswerkzaamheden aanneemt, worden bepaald met inachtneming van de omstandigheden van de latere operationele fase. Bovendien, wanneer de ontwikkeling van een nieuw systeem gelijktijdig plaatsvindt met de afschaffing van het oude systeem, kunnen problemen zoals ‘datamigratie’ van het oude systeem een probleem worden. In dergelijke gevallen zijn de operatie van het oude systeem en de ontwikkeling van het nieuwe systeem nauw met elkaar verbonden.

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

Hoe moeten juridische kwesties met betrekking tot systeembeheer worden georganiseerd?

Zoals we hebben gezien, zijn de praktijken rond IT-systemen nauw verbonden in de ‘ontwikkeling’ en ‘operatie’ fasen. Echter, in de operationele fase, aangezien het ontwikkelingsproject is voltooid, is het ook noodzakelijk om los te denken van de kwesties van ‘projectmanagementverplichtingen’. Om juridische kwesties van ‘ontwikkeling’ en ‘operatie’ uniform te bespreken, is het noodzakelijk om ze te organiseren in een enigszins juridisch georiënteerd, abstract kader. Een voorbeeld hiervan is de organisatie vanuit het perspectief van de juridische ‘verantwoordelijkheid’ met betrekking tot IT-systemen, zoals uitgelegd in het volgende artikel.

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

In het bovenstaande artikel worden civielrechtelijke aansprakelijkheden zoals wanprestatie, garantie voor gebreken en onrechtmatige daad uitgelegd in de context van IT-systemen. Echter, in de operationele fase, zijn er niet veel gevallen waarin de garantie voor gebreken een probleem wordt, behalve wanneer defecten worden ontdekt na acceptatie. Daarom is het in eerste instantie voldoende om te organiseren met het oog op de twee punten van wanprestatie gebaseerd op contractinhoud en onrechtmatige daad die niet uitgaat van een contractuele relatie.

Onderzoek eerst of er sprake is van een contractbreuk door de leverancier

Of het nu gaat om wanprestatie of onrechtmatige daad, het punt van geschil is of er een realiteit is zoals ‘schending van de rechten van anderen’. In het geval van wanprestatie, worden de bepalingen van de Service Level Agreement (SLA) een probleem. Let ook op het feit dat zowel wanprestatie als onrechtmatige daad opzettelijk of nalatig zijn.

Controleer vervolgens de schade aan de gebruikerszijde

De verplichting tot schadevergoeding is iets dat wordt gedragen met betrekking tot de feitelijke schade die aan de gebruikerszijde is ontstaan. Daarom, of het nu gaat om wanprestatie of onrechtmatige daad, als er geen schade is ontstaan aan de gebruikerszijde, zal er geen verplichting tot schadevergoeding ontstaan.

Overweeg ook de toepasbaarheid van nalatigheid compensatie en beperkte aansprakelijkheidsclausules

Zelfs als de leverancier uiteindelijk aansprakelijk is voor schadevergoeding, kan er in gevallen waarin de gebruiker ook enige nalatigheid heeft, een behandeling van nalatigheid compensatie worden overwogen. Bovendien kan het bedrag van de schadevergoeding veranderen als er een limiet is gesteld aan het bedrag van de schadevergoeding in het contract dat vooraf is gesloten. Bijvoorbeeld, in het standaard contractformulier dat bekend staat als het METI-modelcontract, is de volgende bepaling geplaatst met betrekking tot beperkte aansprakelijkheid (de onderstreepte delen zijn toegevoegd door de auteur).

(Schadevergoeding)
Artikel 53 Partij A en B kunnen, in verband met de uitvoering van dit contract en individuele contracten, schadevergoeding eisen van de andere partij als zij schade lijden door een oorzaak die aan de andere partij kan worden toegeschreven. Echter, deze eis kan niet worden gedaan na het verstrijken van ○ maanden vanaf de datum van voltooiing van de acceptatie van de goederen bepaald in het betreffende individuele contract of de datum van bevestiging van het einde van de dienst.

2. Het totale cumulatieve bedrag van de schadevergoeding in het vorige lid, ongeacht de oorzaak van de eis, zoals wanprestatie, wettelijke garantie voor gebreken, ongerechtvaardigde verrijking, onrechtmatige daad, enz., zal beperkt zijn tot het bedrag van ○○○ bepaald in het individuele contract dat de oorzaak van de aansprakelijkheid werd.

3. Het vorige lid is niet van toepassing in gevallen gebaseerd op opzettelijke of ernstige nalatigheid van de schadevergoedingsplichtige.

Voorbeelden van veelvoorkomende problemen en conflicten bij systeembeheer

In de praktijk zijn er verschillende voorbeelden van problemen en conflicten die kunnen ontstaan bij het beheer van systemen. Hieronder volgen enkele van de meest voorkomende.

Incidenten zoals dataverlies veroorzaakt door fouten van de beheerder

Werkzaamheden gerelateerd aan systeembeheer hebben vaak te maken met de verwerking van belangrijke bedrijfsgeheimen en persoonlijke informatie. Onoplettendheid kan leiden tot incidenten, zoals ‘dataverlies’. We bespreken dit soort zaken in detail in het volgende artikel.

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

Voor incidenten zoals dataverlies is het belangrijk om vooraf maatregelen te nemen, zoals het maken van back-ups. Als dergelijke maatregelen worden verwaarloosd, kan het zeer moeilijk zijn om de verantwoordelijkheid bij de aangewezen leverancier te leggen, dus voorzichtigheid is geboden.

Beveiligingsaanvallen, waaronder virussen

Daarnaast kunnen IT-systemen die door een groot aantal mensen op het web worden gebruikt, zoals e-commerce sites, grote incidenten of ongevallen veroorzaken door beveiligingsaanvallen, waaronder virussen. Het detecteren van dergelijke beveiligingsaanvallen en het nemen van maatregelen kan ook deel uitmaken van de beheertaken.

Bugs en defecten die aan het licht komen na acceptatie

Er kunnen ook nieuwe bugs of defecten aan het licht komen na acceptatie. Het is niet altijd mogelijk om alle mogelijke bugs en defecten uitgebreid te overwegen tijdens de testfase, en sommige kunnen pas achteraf worden ontdekt. In dergelijke gevallen wordt de levering meestal als voltooid beschouwd, en wordt de uitvoering van de verplichting als voltooid beoordeeld, waardoor men normaal gesproken wordt vrijgesteld van aansprakelijkheid voor niet-nakoming. Echter, claims voor schadevergoeding op basis van garantieaansprakelijkheid kunnen soms worden erkend. We bespreken dit soort zaken in detail in het volgende artikel.

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

Samenvatting

In de fase van ‘operatie’ van een systeem zijn er veel problemen en conflicten die verschillen van de aard van ontwikkelingsprojecten. Echter, door het baseren op juridische theorieën zoals aansprakelijkheid voor contractbreuk, onrechtmatige daad aansprakelijkheid en garantieaansprakelijkheid voor gebreken, is het mogelijk om een uniforme indeling van het veld te maken zonder gevangen te worden door deze verschillen.