Právní problémy spojené s přechodem z starého systému při vývoji systému

Vytváření nových IT systémů v podnicích je typickou pracovní oblastí IT inženýrů. Avšak když mluvíme o “vytvoření nového systému”, často to zahrnuje také proces “zrušení systému, který byl dosud používán”. V tomto článku se zaměříme na projekt vývoje nového systému z pohledu “zrušení starého systému” a vysvětlíme různé právní problémy, které s tím souvisí.

Co znamená přechod na nový systém

Životnost IT systémů není věčná

IT systémy používané v podnicích nejsou něco, co by se jednou vytvořilo a pak se používalo navždy. Navíc není vždy dobré trvale používat staré věci. I když se to samozřejmě liší podle podniku a účelu systému, obecně platí, že po zhruba deseti letech provozu jednoho systému je obvykle lepší rozhodnutí managementu nahradit ho novým.

Za deset let se výkonnost počítačů na trhu dramaticky mění. To může znamenat, že programy, které před deseti lety nebyly prakticky realizovatelné kvůli omezením, jako je rychlost zpracování počítače (i když byly z pohledu člověka jednoduché a dobře navržené), jsou nyní realizovatelné. Navíc, pokud jste systém používali deset let od jeho vytvoření, pracovní postupy a interní pravidla firmy se mohou v průběhu této doby značně změnit. Kód, který byl implementován ex post, aby reagoval na tyto změny v interním a externím podnikatelském prostředí, může mít tak složitou a komplikovanou strukturu, že ji nelze rozpoznat z obrazovky. To může vést k situaci, kdy i když uživatelé chtějí přidat další funkce, z pohledu vývojářů je již další implementace nemožná.

Staré systémy mohou postupně způsobovat, že IT inženýři budou muset provádět mnoho “ručních” operací (například vydávání dotazů pro individuální extrakci dat a další provozní úkoly). Ironií je, že samotný systém, jak stárne, “personalizuje” práci. Když se systém stane příliš starým a práce související se systémem se stává příliš personalizovanou, a je třeba zavést další “systémová” opatření, vzniká projekt “vývoj nového systému pro přechod ze starého systému”.

Vývoj nového systému pokračuje společně s likvidací starého systému

Jak bylo uvedeno výše, i když to neplatí pro všechny projekty vývoje systémů, mnoho z nich zahrnuje současně také aspekt přechodu ze starého systému. Systém samotný často přechází nespojitě z jednoho dne na druhý.

Avšak průběh každodenních operací by měl být kontinuální od minulosti do přítomnosti a od přítomnosti do budoucnosti. Zatímco je třeba uchovávat potřebná data z minulosti, současný průběh operací by neměl být narušen a měly by být představeny vynikající koncepty “systémizace” pro budoucnost. Přechod na nový systém často přináší řadu výzev. Tyto okolnosti se mohou kombinovat a vývoj nového systému a operace a údržba stávajícího systému se mohou složitě propojit, což vede k neoddělitelným vztahům.

Kroky přechodu na nový systém

Při přechodu ze starého systému na nový je zvláště důležité správně přenést data. Kroky při přenosu dat obvykle postupují podle následujícího postupu.

1. Jasně určit, která data uložená ve starém systému by měla být přenesena do nového systému → je třeba určit, která data by měla být snadno vyhledatelná z obrazovky nového systému, a také, která data nemusí být vyhledatelná z obrazovky, ale měla by být k dispozici pro výběr podle potřeby (například pro audit).
2. Vyexportovat data identifikovaná v kroku 1, která by měla být importována do nového systému, ve formátu jako je CSV soubor.
3. Importovat data extrahovaná v kroku 2 do nového systému.
4. Ověřit, zda jsou data importovaná v kroku 3 reflektována v novém systému, a zkontrolovat, zda byl přenos proveden správně. → Výsledky ověření správnosti přenosu jsou obvykle dokumentovány prostřednictvím zobrazení na obrazovce nebo tisku výpisů (tzv. testovací proces).

Přechod na nový systém je obtížný kvůli definování rolí uživatelů a dodavatelů

V krocích převodu dat, které jsme dříve uvedli, se často stává problémem, do jaké míry by měli uživatelé považovat tuto záležitost za interní problém své společnosti a měli by ji mít pod kontrolou. Mimochodem, pro obecný přehled o “povinnosti spolupráce uživatelů” v rámci celkového projektu vývoje systému, nejen v případě převodu dat, se prosím podívejte na následující článek.

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

Obecně platí, že v projektech vývoje systémů, dodavatelé často převyšují uživatele v odborných znalostech potřebných pro vývoj systému (nebo spíše, to je často důvod, proč jsou pověřeni tímto úkolem). Na druhou stranu, často je tak, že pouze uživatelé mohou diskutovat o tom, jak by měl jejich systém vypadat.

Vzhledem k těmto skutečnostem, můžeme zvážit, že uživatelé by měli provést kroky 1 a 4, jak jsme dříve uvedli. Jinými slovy, můžeme říci, že “definice požadavků” na data, která mají být převedena, a “přijetí” zda byla data převedena podle požadavků, by měly být povinnostmi uživatele. Alternativně, pokud existuje někdo na straně uživatele, kdo má bohaté znalosti o starém systému, můžeme také zvážit, že krok 2 by měl být také zodpovědností uživatele.

Pokud je možné řešit otázky týkající se starého systému interně, bez nutnosti outsourcingu, může být také možné, že by se chtěli obrátit na dodavatele pouze pro otázky týkající se nového systému. V tomto kontextu se role uživatelů a dodavatelů v procesu převodu dat mohou stát nejasnými. Mimochodem, pro obecný přehled o tom, jaké role se obvykle očekávají od dodavatelů, když uživatelé outsourcují práci související s vývojem systémů, a jaké právní povinnosti jim připadají, se prosím podívejte také na následující článek.

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

Příklady minulých soudních sporů souvisejících s přechodem na nový systém

Existují skutečné případy, kdy v projektech vývoje systémů zaměřených na přechod na nový systém došlo k problémům, které vedly k soudním sporům. Případ uvedený v následujícím citátu z rozsudku se týkal selhání při převodu dat během přechodu, což vedlo k nesrovnalostem a chybám v datech v novém systému a také k zpoždění v dodání. Hlavním bodem sporu bylo, jaké povinnosti měli dodavatel a uživatel vůči projektu vzhledem k těmto různým problémům. Nakonec soud určil následující povinnosti, které měl dodavatel splnit, a uznal, že dodavatel nesplnil svou povinnost dbát zvláštní péče.

Obžalovaný měl v rámci převodu dat na základě této smlouvy o dílo nejen převést data z původního systému na nový systém, ale také měl povinnost spustit nový systém pomocí převedených dat. Konkrétně, před zahájením převodu dat měl provést průzkum a analýzu dat, která měla být převedena z původního systému, pochopit povahu a stav dat, zvážit, zda tato data po převodu do nového systému nezpůsobí problémy s provozem, a pokud by takové problémy mohly nastat, rozhodnout, kdy a jakým způsobem budou tato data opravena. Nakonec měl povinnost spustit nový systém pomocí dat převedených z původního systému.

Je správné uznat, že v tomto případě měl obžalovaný povinnost opravit a odstranit nesrovnalosti v datech při převodu dat.

Rozsudek tokijského okresního soudu ze dne 30. listopadu 2016 (rok Heisei 28)

Tento případ se týkal situace, kdy bylo původně dohodnuto, že uživatel převezme kroky 1 a 4 a dodavatel kroky 2 a 3. Jinými slovy, dodavatel se jednou zavázal převzít extrakci dat z původního systému (krok 2). Soud tedy rozhodl, že pokud dodavatel (jako odborník na vývoj systémů) převzal extrakci dat, měl by mít možnost předem zvážit, zda bude možné extrakci dat provést hladce.

Co by se ale stalo, kdyby bylo předem dohodnuto, že krok 2 (tj. extrakce dat) bude úkolem uživatele, a pokud by se v tomto procesu vyskytly problémy? V takovém případě by mohlo dojít k situaci, kdy by uživatel, který zanedbal předběžný průzkum, zda je možné extrakci dat provést hladce, mohl být obviněn z porušení povinnosti spolupráce, pokud by došlo ke zpoždění v dodání.

Dále je třeba poznamenat, že taková rozhodnutí jsou často založena nejen na smlouvách, ale také na zápisech z jednání, které jsou vedeny v průběhu vývoje systému. Význam zápisů z jednání je podrobně vysvětlen v následujícím článku.

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

Shrnutí

Projekt vývoje systému by měl být prováděn s pečlivou komunikací mezi uživateli a dodavateli, kteří oba nesou mnoho povinností. Proto, jak bylo uvedeno v předchozích soudních případech, i malé změny v předpokladech mohou snadno převrátit odpovědnost na stranu uživatele nebo dodavatele.

Vzhledem k možnosti, že systém může obsahovat obrovské množství dat a složité mechanismy, které si nelze představit pouze z vzhledu obrazovky, a k možnosti, že i malé rozdíly v předpokladech mohou výrazně ovlivnit konečné soudní rozhodnutí, je důležité komplexně řešit řízení rizik projektu vývoje nového systému spolu s odstraněním starého systému.