Juridiska problem i samband med övergången från gamla system i systemutveckling

Att skapa nya IT-system för företag är en typisk uppgift för IT-ingenjörer. Men när vi talar om att “skapa ett nytt system” innebär det ofta också att “avveckla det gamla systemet” samtidigt. I denna artikel kommer vi att omvärdera projektet att utveckla nya system från perspektivet av “avveckling av gamla system” och diskutera de olika juridiska frågorna som uppstår i samband med detta.

Vad innebär det att övergå till ett nytt system?

IT-systemens livslängd är inte evig

Det är inte så att IT-system som används i företag kan fortsätta att användas för evigt bara för att de har skapats en gång. Dessutom är det inte alltid bra att fortsätta att använda gamla saker omsorgsfullt. Även om det naturligtvis varierar mellan företag och beroende på systemets användning, tenderar det att vara en affärsbedömning att det är bättre att förnya till något nytt efter att ha använt ett system i ungefär 10 år.

Om tio år kommer prestandan på datorer som cirkulerar på marknaden att förändras dramatiskt. I så fall kan det vara så att program som inte var praktiska att implementera på grund av begränsningar som datorns bearbetningshastighet (som är enkel och utmärkt design från människors perspektiv) för tio år sedan nu kan implementeras. Dessutom, om du har fortsatt att använda det i tio år sedan du skapade det, kan företagets arbetsflöde och interna regler ha förändrats mycket under den tiden. Koden som har implementerats efteråt för att möta dessa förändringar i företagets interna och externa affärsmiljö kan ha blivit så komplex och invecklad att den inte kan erkännas från skärmen. I så fall kan det hända att även om användaren gradvis vill lägga till funktioner, kan det bli omöjligt att lägga till implementeringar från utvecklarens perspektiv.

Äldre system kan gradvis orsaka många “manuella” uppgifter (till exempel driftsuppgifter som att utfärda frågor för att extrahera data individuellt) för IT-ingenjörer. Ironiskt nog, ju äldre systemet blir, desto mer “personalberoende” blir det. När du försöker vidta åtgärder för ytterligare “systematisering” för systemrelaterade uppgifter där det finns många personalberoende uppgifter på grund av att de har blivit för gamla, kommer det att uppstå ett projekt för “utveckling av ett nytt system för att migrera från det gamla systemet”.

Utvecklingen av det nya systemet fortskrider i takt med avvecklingen av det gamla systemet

Som tidigare nämnt, även om inte alla systemutvecklingsprojekt är sådana, innebär ofta ett systemutvecklingsprojekt samtidigt en övergång från det gamla systemet. Systemet i sig kan ofta byta över diskontinuerligt från en dag till en annan.

Men själva framstegen i den dagliga verksamheten bör vara en kontinuerlig kedja från det förflutna till nuet, och från nuet till framtiden. Medan det är nödvändigt att lagra nödvändiga data från det förflutna, bör framstegen i den nuvarande verksamheten inte hindras, och det finns ofta olika utmaningar i övergången till det nya systemet, såsom att presentera en överlägsen “systematisering” koncept för framtiden. På grund av dessa komplexa omständigheter, kan utvecklingen av det nya systemet och verksamheten för drift och underhåll av det befintliga systemet bli komplicerat relaterade, och det kan uppstå situationer där de är oskiljaktigt kopplade.

Vad är stegen för övergången till ett nytt system?

När man övergår från det gamla systemet till ett nytt system, är det särskilt viktigt att överföra data på rätt sätt. Stegen för att överföra data följer vanligtvis följande procedur:

1. Identifiera vilka data som lagras i det gamla systemet som bör överföras till det nya systemet. Det är nödvändigt att tydligt identifiera vilka data som bör vara lätt sökbara från det nya systemets skärmsida, samt vilka data som inte nödvändigtvis behöver vara sökbara från skärmsidan, men som bör kunna hämtas vid behov (till exempel för revisioner).
2. Exportera de data som identifierats i steg 1 och som bör importeras till det nya systemet, till exempel i form av en CSV-fil.
3. Importera de data som extraherats i steg 2 till det nya systemet.
4. Verifiera om de data som importerats i steg 3 återspeglas i det nya systemet och bekräfta att överföringen har utförts korrekt. Bevis på att verifieringen har utförts korrekt lämnas vanligtvis genom att visa skärmbilder eller skriva ut dokument (det så kallade teststeget).

Övergången till ett nytt system är svårt att klargöra rollerna för användare och leverantörer

I stegen för datamigrering som nämndes tidigare, är det ofta ett problem att avgöra hur mycket användaren ska hantera det som ett internt problem i sitt eget företag. För en allmän översikt över “användarens samarbetsplikt” i systemutvecklingsprojekt i allmänhet, inte bara datamigrering, se följande artikel.

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

Generellt sett, i ett projekt som systemutveckling, är det sant att leverantören ofta överträffar användaren i termer av specialiserad kunskap för systemutveckling (eller snarare, det är ofta anledningen till att de är anlitade för jobbet). Men å andra sidan, det är ofta bara användaren som kan diskutera hur deras system “borde vara”.

Med detta i åtanke, kan en möjlig rollfördelning vara att användaren utför steg 1 och 4 som nämnts tidigare. Eller för att uttrycka det på ett annat sätt, det kan sägas att det är användarens ansvar att definiera “kraven” för de data som ska migreras och att “acceptera” om datan har migrerats enligt kraven. Alternativt, om det finns någon på användarsidan med omfattande kunskap om det gamla systemet, kan de också överväga att göra steg 2 till användarens ansvar.

Om det gamla systemet kan hanteras internt utan att behöva outsourca, kan det vara möjligt att endast outsourca det nya systemet till leverantören. I detta fall kan rollfördelningen mellan användare och leverantör bli oklar i datamigreringsprocessen. För en allmän förklaring av vilka roller som förväntas av leverantören och vilka juridiska skyldigheter som tillkommer när en användare outsourcar systemutvecklingsrelaterade uppgifter till en leverantör, se även följande artikel.

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

Tidigare rättsfall som rör övergången till nya system

I projekt för systemutveckling som syftar till att övergå till ett nytt system, finns det faktiska fall där problem har uppstått och lett till rättsliga tvister. Fallet som citeras i domen nedan involverade problem som uppstod när dataöverföringen misslyckades under övergången, vilket resulterade i flera datainkonsekvenser och buggar i det nya systemet, samt förseningar i leveransen. Frågan var vilka skyldigheter leverantören och användaren hade gentemot projektet. Slutsatsen var att leverantören hade brutit mot sin skyldighet att vara försiktig, som beskrivs nedan.

Defendant, in the data migration work based on this contract, not only simply migrated the data from the old system to the new one, but also had the obligation to operate the new system with the migrated data, specifically, before starting the data migration work, investigated and analyzed the data to be migrated from the old system, understood the nature and condition of the data, considered whether it would hinder the operation after being migrated to the new system, and if it would, decided when and how to correct the data, and then proceeded with the data migration work (migration design, development of migration tools, data migration), and finally, had the obligation to operate the new system with the data migrated from the old system.

It is reasonable to recognize that in this case, the defendant had the obligation to correct and eliminate data inconsistencies in the data migration, and it should be said that the defendant had the obligation to do so.

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

I detta fall var det ursprungligen så att användaren tog på sig steg 1 och steg 4, medan leverantören tog på sig steg 2 och steg 3. Med andra ord, leverantören hade en gång tagit på sig att extrahera data från det gamla systemet (steg 2). Därför ansåg domstolen att om leverantören hade tagit på sig att extrahera data, inklusive om extraktionen kunde genomföras smidigt eller inte, borde detta ha övervägts i förväg.

Men vad skulle ha hänt om användaren hade tagit på sig steg 2 (dvs. dataextraktion) som sin uppgift och misslyckats med extraktionen? I detta fall kan det tänkas att användaren skulle ha blivit anklagad för att ha brutit mot sin samarbetsplikt eftersom leveransen försenades på grund av att användaren inte hade undersökt i förväg om dataextraktionen kunde genomföras smidigt.

Dessutom baseras sådana bedömningar inte bara på kontraktet, utan också på protokoll som tas fram i enlighet med framstegen i systemutvecklingen. Vikten av protokoll förklaras mer detaljerat i artikeln nedan.

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

Sammanfattning

Projekt som involverar systemutveckling kräver att både användare och leverantörer tar på sig många skyldigheter och kommunicerar noggrant med varandra. Därför kan, som vi nämnde i tidigare rättsfall, bara en liten förändring i förutsättningarna lätt vända skulden mellan användare och leverantör.

Med tanke på att ett system kan innehålla enorma mängder data och komplexa mekanismer som inte kan föreställas utifrån dess gränssnitt, och att en liten skillnad i förutsättningar kan drastiskt ändra rättens slutliga beslut, kan vi säga att det är viktigt att hantera riskerna med nya systemutvecklingsprojekt på ett omfattande sätt, inklusive avvecklingen av gamla system.