Problemy prawne związane z migracją ze starego systemu podczas rozwoju systemu

Tworzenie nowych systemów IT wykorzystywanych w firmach to typowe zadanie dla inżynierów IT. Jednakże, kiedy mówimy o “tworzeniu nowego systemu”, często oznacza to również proces “wycofania systemu, który był dotychczas używany”. W tym artykule, podejdziemy do projektu rozwoju nowego systemu z perspektywy “wycofania starego systemu” i omówimy różne problemy prawne związane z tym procesem.

Co oznacza przejście na nowy system?

Żywotność systemu IT nie jest wieczna

Systemy IT używane w firmach nie są takie, że po ich stworzeniu można z nich korzystać na zawsze. Co więcej, nie zawsze jest dobrze, aby stale korzystać ze starych rzeczy. Chociaż różnią się one w zależności od firmy i zastosowania systemu, zazwyczaj po około dziesięciu latach korzystania z jednego systemu, zaleca się podjęcie decyzji zarządczej o zastąpieniu go nowym.

W ciągu dziesięciu lat, wydajność komputerów dostępnych na rynku ulega znacznej zmianie. W takim przypadku, na przykład, program, który nie był praktyczny do implementacji dziesięć lat temu z powodu ograniczeń, takich jak prędkość przetwarzania komputera (mimo że z punktu widzenia człowieka był prosty i dobrze zaprojektowany), może być teraz możliwy do zaimplementowania. Ponadto, jeśli korzystałeś z niego przez dziesięć lat od momentu stworzenia, workflow firmy i zasady wewnętrzne mogły się znacznie zmienić. Kod, który został zaimplementowany po fakcie, aby sprostać tym zmianom w środowisku biznesowym firmy, może stać się tak skomplikowany i zawiły, że nie jest już widoczny z poziomu interfejsu użytkownika. W takim przypadku, nawet jeśli użytkownicy chcą dodać nowe funkcje, może dojść do sytuacji, w której dodatkowa implementacja staje się niemożliwa z punktu widzenia dewelopera.

Stare systemy mogą stopniowo zmuszać inżynierów IT do wykonywania wielu “ręcznych” operacji (takich jak wydawanie zapytań do ekstrakcji danych na żądanie). Ironią jest, że sam system, gdy się starzeje, zaczyna “personalizować” pracę. Kiedy starzejący się system zaczyna generować coraz więcej zadań związanych z systemem, które stają się bardziej personalizowane, projekt “rozwoju nowego systemu do migracji ze starego systemu” powstaje w celu wprowadzenia dalszych “systematycznych” środków.

Rozwój nowego systemu postępuje wraz z likwidacją starego systemu

Jak wcześniej wspomniano, wiele projektów rozwoju systemów (choć nie wszystkie) często łączy w sobie aspekt migracji ze starego systemu. Sam system często zmienia się nieciągło, z jednego dnia na drugi.

Jednak codzienny postęp pracy powinien być ciągły, od przeszłości do teraźniejszości, a z teraźniejszości do przyszłości. Przechowując potrzebne dane z przeszłości, nie przeszkadzając w bieżącej pracy, a jednocześnie prezentując doskonałe koncepcje “systematyzacji” skierowane w przyszłość, migracja do nowego systemu często wiąże się z różnymi wyzwaniami. Te okoliczności łączą się w skomplikowany sposób, a rozwój nowego systemu i operacje i konserwacja istniejącego systemu są ze sobą powiązane, co prowadzi do nierozerwalnej relacji.

Kroki przejścia do nowego systemu

Podczas przechodzenia ze starego systemu do nowego, szczególnie ważne jest prawidłowe przeniesienie danych. Proces migracji danych zazwyczaj przebiega zgodnie z następującymi krokami:

1. Określenie, które dane przechowywane w starym systemie powinny zostać przeniesione do nowego systemu. Należy również zidentyfikować, które dane powinny być łatwo dostępne z poziomu interfejsu nowego systemu, a które – mimo że nie muszą być dostępne z poziomu interfejsu – powinny być dostępne w razie potrzeby (np. podczas audytu).
2. Wyeksportowanie danych zidentyfikowanych w punkcie 1 do pliku, np. w formacie CSV, które mają zostać zaimportowane do nowego systemu.
3. Zaimportowanie danych wyekstrahowanych w punkcie 2 do nowego systemu.
4. Weryfikacja, czy dane zaimportowane w punkcie 3 są prawidłowo odzwierciedlone w nowym systemie i czy migracja przebiegła poprawnie. Zazwyczaj dowodem na poprawność migracji są wydruki ekranów lub raportów z nowego systemu (tzw. etap testowania).

Przejście na nowy system jest trudne ze względu na wyjaśnienie ról użytkowników i dostawców

W krokach migracji danych, które omówiliśmy wcześniej, często pojawia się problem, do jakiego stopnia użytkownicy powinni traktować to jako wewnętrzny problem swojej firmy, który powinni kontrolować. Zwróć uwagę, że to nie dotyczy tylko migracji danych. Ogólny przegląd “obowiązku współpracy użytkowników” w całym projekcie rozwoju systemu można znaleźć w poniższym artykule.

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

Na ogół, w projekcie takim jak rozwój systemu, dostawca często przewyższa użytkownika pod względem specjalistycznej wiedzy potrzebnej do rozwoju systemu (lub raczej, to jest często powód, dla którego dostawca jest zatrudniony). Jednak z drugiej strony, często tylko użytkownik może dyskutować o “pożądanym stanie” systemu firmy.

Biorąc pod uwagę te kwestie, można rozważyć wyjaśnienie ról, w których użytkownik wykonuje wcześniej wspomniane kroki 1 i 4. Inaczej mówiąc, można powiedzieć, że “definicja wymagań” dla danych do migracji i “akceptacja” czy dane zostały przeniesione zgodnie z wymaganiami są obowiązkami użytkownika. Alternatywnie, jeśli w firmie jest osoba z dużą wiedzą o starym systemie, można rozważyć przypisanie jej do kroku 2.

Jeśli można poradzić sobie z kwestią starego systemu wewnętrznie, bez konieczności zlecania jej na zewnątrz, można rozważyć zlecenie dostawcy tylko kwestii nowego systemu. W ten sposób, w pracy migracji danych, role użytkowników i dostawców mogą czasami stać się niejasne. Zwróć uwagę, że gdy użytkownik zleca dostawcy prace związane z rozwojem systemu, zwykle oczekuje się, że dostawca będzie pełnił określone role, a na nim spoczywają określone obowiązki prawne. Ogólny przegląd tych kwestii można znaleźć w poniższym artykule.

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

Przykłady z przeszłości dotyczące procesów sądowych związanych z przejściem na nowy system

W projektach rozwoju systemów mających na celu przejście na nowy system, rzeczywiście wystąpiły problemy, które doprowadziły do procesów sądowych. Przykładem jest poniżej cytowany wyrok, w którym podczas migracji danych wystąpiły błędy, powodując niespójności i błędy w nowym systemie, co z kolei spowodowało opóźnienia w terminie dostawy. Sporne stało się, jakie obowiązki wobec projektu miały strony – dostawca i użytkownik. Wnioskiem było, że dostawca powinien ponosić odpowiedzialność za następujące obowiązki:

Pozwany, w ramach umowy o wykonanie usługi migracji danych, nie tylko przenosił dane z poprzedniego systemu do nowego, ale także miał obowiązek uruchomienia nowego systemu za pomocą przeniesionych danych. Konkretnie, przed rozpoczęciem migracji danych, powinien zbadać i przeanalizować dane, które mają być przeniesione z poprzedniego systemu, zrozumieć ich charakter i stan, rozważyć, czy te dane staną się przeszkodą po przeniesieniu do nowego systemu, a jeśli tak, zdecydować, kiedy i jak te dane powinny być poprawione. Ostatecznie, miał obowiązek uruchomienia nowego systemu za pomocą danych przeniesionych z poprzedniego systemu.

Uważamy, że jest to odpowiednie, a w tym przypadku, podczas migracji danych, powinien ponosić obowiązek korekty i eliminacji niespójności danych.

Sąd Okręgowy w Tokio, 30 listopada 2016 roku (rok 28 ery Heisei)

W tym przypadku, użytkownik miał na swoim koncie kroki 1 i 4, a dostawca kroki 2 i 3. Innymi słowy, dostawca początkowo zgodził się na ekstrakcję danych ze starego systemu. Dlatego sąd uznał, że jeśli dostawca, jako specjalista w dziedzinie rozwoju systemów, zgodził się na ekstrakcję danych, powinien był wcześniej rozważyć, czy proces ekstrakcji danych może przebiegać płynnie.

Jednak co by się stało, gdyby krok 2 (czyli ekstrakcja danych) był wcześniej zdefiniowany jako zadanie użytkownika, a mimo to proces ekstrakcji danych nie powiódł się? W takim przypadku możliwe jest, że użytkownik, który zaniedbał wcześniejsze badanie, czy ekstrakcja danych może przebiegać płynnie, spowodował opóźnienie w terminie dostawy, a teraz to użytkownik mógłby być oskarżony o naruszenie obowiązku współpracy.

Ponadto, takie decyzje są podejmowane nie tylko na podstawie umowy, ale także na podstawie protokołów z posiedzeń dostosowanych do postępu w rozwoju systemu. Ważność protokołów z posiedzeń jest omówiona szczegółowo w poniższym artykule.

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

Podsumowanie

Projekt związany z rozwojem systemu to zadanie, które wymaga od obu stron – użytkowników i dostawców – podjęcia wielu obowiązków i prowadzenia szczegółowej komunikacji. Dlatego też, jak pokazano w wcześniej wspomnianym przykładzie sądowym, nawet niewielka zmiana w założeniach może łatwo odwrócić stronę odpowiedzialną, czy to użytkowników, czy dostawców.

Z uwagi na fakt, że system może zawierać ogromne ilości danych i skomplikowane mechanizmy, które są trudne do wyobrażenia na podstawie wyglądu interfejsu, a także fakt, że niewielka różnica w założeniach może znacznie zmienić ostateczną decyzję sądową, można powiedzieć, że zarządzanie ryzykiem w projekcie rozwoju nowego systemu jest ważne, a także powinno być rozważane w sposób kompleksowy, wraz z likwidacją starego systemu.