Juridische problemen bij de overgang van oude systemen in systeemontwikkeling

Het creëren van nieuwe IT-systemen voor bedrijven is een typisch werkgebied voor IT-ingenieurs. Echter, wanneer we het hebben over “het creëren van een nieuw systeem”, omvat dit proces vaak ook “het afschaffen van het oude systeem” dat tot nu toe in gebruik was. In dit artikel zullen we de ontwikkeling van nieuwe systemen heroverwegen vanuit het perspectief van “het afschaffen van oude systemen”, en de diverse juridische kwesties die hiermee gepaard gaan, toelichten.

Wat betekent het om over te stappen naar een nieuw systeem?

De levensduur van een IT-systeem is niet eeuwig

Een IT-systeem dat in een bedrijf wordt gebruikt, is niet iets dat eenmaal gemaakt kan worden en dan voor altijd kan worden gebruikt. Bovendien is het niet altijd goed om oude dingen te blijven gebruiken. Hoewel er natuurlijk variaties zijn tussen bedrijven en het doel van het systeem, is er over het algemeen een neiging om een managementbeslissing te nemen dat het beter is om een systeem te vernieuwen na ongeveer tien jaar gebruik.

In tien jaar tijd kan de prestatie van computers op de markt drastisch veranderen. Bijvoorbeeld, een programma dat tien jaar geleden (hoewel het vanuit menselijk oogpunt een eenvoudig en superieur ontwerp had) niet praktisch was om te implementeren vanwege beperkingen zoals de verwerkingssnelheid van de computer, kan nu wel geïmplementeerd worden. Bovendien, als je het tien jaar lang hebt gebruikt sinds je het hebt gemaakt, kunnen de workflow van het bedrijf en de interne regels aanzienlijk zijn veranderd. De code die achteraf is geïmplementeerd om aan te passen aan deze interne en externe bedrijfsomgevingsveranderingen kan zo complex en ingewikkeld zijn geworden dat het niet herkenbaar is vanaf het scherm. In dit geval kan het zelfs zo zijn dat, hoewel de gebruiker extra functies wil toevoegen, het vanuit het oogpunt van de ontwikkelaar niet langer mogelijk is om extra implementaties toe te voegen.

Een verouderd systeem kan geleidelijk aan veel ‘handmatig werk’ (zoals operationele taken zoals het uitvoeren van queries om individuele gegevens te extraheren) veroorzaken voor IT-ingenieurs. Ironisch genoeg, naarmate het systeem ouder wordt, wordt het werk meer ‘persoonsgebonden’. Wanneer je probeert verdere ‘systematisering’ maatregelen te nemen voor taken die verband houden met systemen die te oud zijn geworden en te veel persoonsgebonden taken hebben, zal er een project ontstaan voor de ontwikkeling van een nieuw systeem om over te stappen van het oude systeem.

De ontwikkeling van het nieuwe systeem gaat hand in hand met de afschaffing van het oude systeem

Zoals eerder vermeld, hoewel niet alle systeemontwikkelingsprojecten dit doen, hebben veel systeemontwikkelingsprojecten vaak tegelijkertijd het aspect van migratie van het oude systeem. Het systeem zelf zal vaak discontinu veranderen vanaf een bepaalde dag.

Maar de voortgang van de dagelijkse werkzaamheden moet echter continu doorgaan vanuit het verleden naar het heden en van het heden naar de toekomst. Terwijl de nodige gegevens uit het verleden worden bewaard, wordt de voortgang van de huidige werkzaamheden niet belemmerd, en er zijn vaak verschillende uitdagingen bij de overgang naar het nieuwe systeem, zoals het formuleren van een superieur ‘systeem’ concept voor de toekomst. Door deze omstandigheden te combineren, worden de ontwikkeling van het nieuwe systeem en de bedrijfsactiviteiten zoals de werking en het onderhoud van het bestaande systeem complex gerelateerd, en er kunnen situaties ontstaan waarin ze een onafscheidelijke relatie hebben.

Wat zijn de stappen voor de overgang naar een nieuw systeem?

Bij de overgang van een bestaand systeem naar een nieuw systeem is het vooral belangrijk om de gegevens correct over te zetten. De stappen voor het overzetten van gegevens volgen meestal de volgende procedure:

1. Verduidelijk welke gegevens van het oude systeem moeten worden overgezet naar het nieuwe systeem → bepaal welke gegevens gemakkelijk doorzoekbaar moeten zijn vanaf het scherm van het nieuwe systeem, en welke gegevens niet noodzakelijkerwijs doorzoekbaar hoeven te zijn vanaf het scherm, maar wel beschikbaar moeten zijn indien nodig (bijvoorbeeld voor audits).
2. Exporteer de gegevens die in stap 1 zijn geïdentificeerd en die moeten worden geïmporteerd in het nieuwe systeem, in een formaat zoals een CSV-bestand.
3. Importeer de gegevens die in stap 2 zijn geëxtraheerd in het nieuwe systeem.
4. Verifieer of de gegevens die in stap 3 zijn geïmporteerd, worden weerspiegeld in het nieuwe systeem en controleer of de overdracht correct is uitgevoerd. → De resultaten van de verificatie of de overdracht correct is uitgevoerd, worden meestal vastgelegd als bewijsmateriaal door middel van schermafdrukken of het afdrukken van rapporten (het zogenaamde testproces).

De overgang naar een nieuw systeem maakt het moeilijk om de rollen van gebruikers en leveranciers te definiëren

In de eerder genoemde stappen van gegevensoverdracht, is een vaak voorkomend probleem hoe ver de gebruikerskant dit als een intern probleem moet beheren. Voor een algemene uitleg over de ‘verplichting tot samenwerking van de gebruiker’ in systeemontwikkelingsprojecten in het algemeen, niet beperkt tot gegevensoverdracht, zie het volgende artikel.

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

In algemene termen, in een project zoals systeemontwikkeling, is het vaak zo dat de leverancier superieur is aan de gebruiker in termen van gespecialiseerde kennis voor systeemontwikkeling (of eerder, dat is vaak de reden waarom ze de taak hebben gekregen). Aan de andere kant, het is vaak zo dat alleen de gebruikerskant kan discussiëren over hoe hun systeem eruit zou moeten zien.

Met dat in gedachten, kan men overwegen om de rollen te definiëren zodat de gebruiker de eerder genoemde stappen 1 en 4 uitvoert. Om het anders te zeggen, tijdens de gehele gegevensoverdracht, kan men zeggen dat het definiëren van de ‘vereisten’ van de te migreren gegevens en het ‘accepteren’ of de gegevens al dan niet volgens de vereisten zijn gemigreerd, beide de verantwoordelijkheid van de gebruiker zijn. Of, als alternatieve manier van organiseren, als er iemand aan de gebruikerskant is met uitgebreide kennis van het oude systeem, kan men overwegen om ook stap 2 aan de gebruikerskant toe te wijzen.

Als men kan omgaan met het oude systeem intern zonder het uit te besteden, kan men overwegen om alleen het nieuwe systeem uit te besteden aan de leverancier. Op deze manier kan de rolverdeling tussen de gebruiker en de leverancier soms vaag worden in het proces van gegevensoverdracht. Voor een algemene uitleg over welke rollen normaal gesproken van de leverancier worden verwacht en welke wettelijke verplichtingen van toepassing zijn wanneer de gebruiker systeemontwikkelingswerkzaamheden uitbesteedt aan de leverancier, zie ook het volgende artikel.

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

Vorige rechtszaken met betrekking tot de overgang naar nieuwe systemen

Er zijn daadwerkelijk gevallen waarin problemen zijn ontstaan tijdens projecten voor systeemontwikkeling gericht op de overgang naar nieuwe systemen, wat heeft geleid tot rechtszaken. Het geval dat wordt geciteerd in het onderstaande vonnis betreft een situatie waarin er tijdens de datamigratie mislukkingen optraden, wat leidde tot verschillende inconsistenties en bugs in het nieuwe systeem, en ook tot vertragingen in de levering. De vraag was welke verplichtingen de leverancier en de gebruiker elk hadden ten opzichte van het project in het licht van deze verschillende problemen. De conclusie was dat de leverancier de volgende verantwoordelijkheden had als onderdeel van zijn zorgplicht, en dat er sprake was van een schending van deze zorgplicht door de leverancier.

De verweerder had, als onderdeel van zijn verplichtingen onder het contract voor de overdracht van gegevens, niet alleen de taak om de gegevens van het oude systeem eenvoudigweg over te dragen naar het nieuwe systeem, maar ook de verplichting om het nieuwe systeem operationeel te maken met de overgedragen gegevens. Concreet betekent dit dat voordat de datamigratie begon, de verweerder de gegevens die zouden worden overgedragen van het oude systeem moest onderzoeken en analyseren, de aard en toestand van de gegevens moest begrijpen, moest overwegen of deze gegevens na overdracht naar het nieuwe systeem operationele problemen zouden veroorzaken, en als dat het geval was, moest beslissen wanneer en hoe deze gegevens zouden worden gecorrigeerd, voordat hij aan de datamigratie begon (het ontwerpen van de migratie, het ontwikkelen van migratietools, het overdragen van gegevens), en uiteindelijk de verplichting op zich nam om het nieuwe systeem operationeel te maken met de gegevens die waren overgedragen van het oude systeem.

Het is redelijk om te erkennen dat in dit geval, bij de datamigratie, de verweerder de verplichting had om inconsistenties in de gegevens te corrigeren en op te lossen.

Tokyo District Court, 30 november 2016 (Heisei 28)

Dit geval betrof een situatie waarin de gebruiker stappen 1 en 4 op zich nam, en de leverancier stappen 2 en 3. Met andere woorden, de leverancier had oorspronkelijk de taak op zich genomen om de gegevens uit het oude systeem te extraheren (stap 2). Daarom oordeelde de rechtbank dat als de leverancier (als een professionele systeemontwikkelaar) de taak op zich had genomen om de gegevens te extraheren, hij van tevoren had moeten overwegen of deze extractie daadwerkelijk soepel zou kunnen verlopen.

Echter, wat zou er gebeurd zijn als de gebruiker van tevoren had afgesproken dat hij de taak van stap 2 (dat wil zeggen, de extractie van gegevens) op zich zou nemen, en vervolgens had gefaald in de extractie? In dit geval zou het mogelijk zijn geweest dat de gebruiker, omdat hij nalatig was geweest in het vooraf onderzoeken of de gegevensextractie soepel zou kunnen verlopen, waardoor er vertraging was opgetreden in de levering, nu op zijn beurt zou worden aangeklaagd wegens schending van zijn medewerkingsplicht.

Bovendien worden dergelijke oordelen niet alleen gebaseerd op het contract, maar ook op bewijsmateriaal zoals notulen die zijn opgesteld in overeenstemming met de voortgang van de systeemontwikkeling. Het belang van notulen wordt in detail uitgelegd in het onderstaande artikel.

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

Samenvatting

Een project zoals systeemontwikkeling vereist dat zowel de gebruikerskant als de leverancierskant veel verantwoordelijkheden op zich nemen en nauwgezet communiceren. Daarom kan in de eerder genoemde rechtszaak, zelfs een kleine verandering in de voorwaarden, gemakkelijk de verantwoordelijkheid tussen de gebruiker en de leverancier omkeren.

Gezien de mogelijkheid dat een systeem, dat veel meer gegevens en complexe mechanismen bevat dan men zou kunnen vermoeden vanuit het uiterlijk van het scherm, en het feit dat een klein verschil in de voorwaarden de uiteindelijke juridische beslissing sterk kan beïnvloeden, kan worden gezegd dat het belangrijk is om het risicobeheer van nieuwe systeemontwikkelingsprojecten op een alomvattende manier te benaderen, inclusief de afschaffing van oude systemen.