Jakie są środki zaradcze w przypadku wykrycia błędów systemu po akceptacji?

Rozwój systemu, mówiąc ogólnie, polega na tym, że implementacja programu jest prowadzona zgodnie z treścią ustaloną w fazie definiowania wymagań, a na końcu zarówno użytkownik, jak i dostawca sprawdzają, czy produkt końcowy jest zgodny ze specyfikacją. Proces ten kończy się po otrzymaniu akceptacji podczas odbioru.

Jednak w praktyce, błędy i problemy, które nie zostały wykryte podczas testowania i odbioru, mogą faktycznie wystąpić w późniejszych fazach eksploatacji. Co można żądać prawnie, jeśli już zaakceptowano dostawę?

Nie jest dziwne, że błędy pozostają nawet po akceptacji lub procesie testowania

Z technicznego punktu widzenia, nie jest rzadkością, że różne błędy i problemy ujawniają się po zakończeniu różnych procesów testowych po stronie dostawcy oraz po akceptacji po stronie użytkownika. Zazwyczaj, to, co użytkownik robi podczas procesu akceptacji, skupia się głównie na sprawdzaniu wejść i wyjść, które można potwierdzić na ekranie. Jednakże, systemy IT często mają skomplikowaną i szczegółową strukturę w bazie danych lub w części programu, który kontroluje różne obliczenia i sterowanie, co jest więcej niż to, co można zobaczyć na ekranie z perspektywy użytkownika. Dlatego, jest pewne ograniczenie w tym, co można zbadać z punktu widzenia użytkownika na ekranie. Dlatego, nie jest realistyczne, aby w pełni zweryfikować wszystkie możliwe problemy, które mogą wystąpić w późniejszej fazie operacyjnej podczas sprawdzania.

Podobne okoliczności mogą być powiedziane, nawet z perspektywy dostawcy, który jest odpowiedzialny za rozwój. Na przykład, proces testowy jest tym, który sprawdza, czy nie ma błędów lub problemów w treści zaimplementowanego programu. Jednakże, nawet w procesie testowym, nie zawsze jest możliwe w pełni zweryfikowanie wszystkich możliwych błędów i problemów. Nawet po tym, jak rozwinięty system zaczyna być aktywnie wykorzystywany w biznesie, wymaga to doskonałych umiejętności technicznych, aby stworzyć system, który nadal działa bez problemów, nawet gdy są wykonywane operacje, których dostawca nie przewidział, lub gdy zaczyna się rejestrować dużą ilość danych, lub gdy wielu użytkowników zaczyna jednocześnie uzyskiwać dostęp.

Powinniśmy najpierw zrozumieć, że nie jest realistyczne, aby odkryć wszystkie błędy i problemy na etapie akceptacji lub testowania, i że różne problemy mogą się ujawnić po rozpoczęciu użytkowania systemu IT.

Zazwyczaj dług jest uznawany za wykonany

Więc jak należy postępować, gdy takie problemy faktycznie się pojawią? Przeanalizujemy to zgodnie z kolejnością prawną.

Po pierwsze, jeśli po fakcie odkryto różne błędy i usterki, użytkownik prawdopodobnie będzie chciał pociągnąć do odpowiedzialności dostawcę, od którego do tej pory zlecał prace. Jednak zazwyczaj, jeśli dostawa już została zakończona i została zatwierdzona, trudno jest dochodzić odpowiedzialności na podstawie niewykonania zobowiązania.

Przede wszystkim, jeśli nie ma żadnych specjalnych ustaleń, umowa o rozwój systemu podlega przepisom o umowie o dzieło w kodeksie cywilnym. Szczegółowe wyjaśnienie, czym jest umowa o dzieło, znajduje się w poniższym artykule.

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

W umowie o dzieło, “ukończenie pracy” jest wymogiem wykonania zobowiązania. Szczegółowe wyjaśnienie, co konkretnie oznacza “ukończenie pracy”, znajduje się w poniższym artykule.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Tutaj wyjaśniamy, że w poprzednich wyrokach sądowych, “ukończenie pracy” w umowie o dzieło oznacza zakończenie całego procesu rozwoju systemu. Wyjaśniamy również, że problemy takie jak błędy i usterki po zakończeniu całego procesu rozwoju stają się problemem odpowiedzialności za wady w umowie o dzieło.

Podsumowując, jeśli raz przyjęto dostawę i zakończono proces akceptacji, zobowiązanie jest z góry uznawane za wykonane, a następnie pojawia się problem gwarancji jakości, czyli możliwość dochodzenia odpowiedzialności za wady. To jest zazwyczaj problem.

Ścieżka dochodzenia odpowiedzialności na podstawie gwarancji za wady

Więc, jakie kroki powinniśmy podjąć, aby żądać od dostawcy działań na podstawie gwarancji za wady? Sprawdźmy to poniżej.

Pierwszym krokiem jest sprawdzenie powagi i nasilenia błędów i usterek

Kiedy błędy i usterki zostają wykryte po fakcie i są one uznane za “wady” w sensie prawnym, powaga tych błędów i usterek staje się problemem. Kwestia prawnych wad dzieli się na trzy kategorie:

1. Chociaż jest to błąd lub usterka, jest to tylko drobna sprawa i nie można jej uznać za “wadę” w sensie prawnym
2. Chociaż jest to “wada” w sensie prawnym, osiągnięcie celu umowy jest nadal możliwe
3. Jest to “wada” w sensie prawnym, a osiągnięcie celu umowy jest niemożliwe

Co dzieli możliwość dochodzenia odpowiedzialności na podstawie gwarancji za wady to granica między 1 a 2, a co dzieli możliwość rozwiązania umowy na podstawie gwarancji za wady to granica między 2 a 3.

Artykuł 634

1. Kiedy w przedmiocie umowy jest wada, zamawiający może żądać od wykonawcy naprawy tej wady w określonym czasie. Jednakże, jeśli wada nie jest poważna i naprawa wymaga nadmiernych kosztów, nie dotyczy to tego przypadku.

2. Zamawiający może żądać odszkodowania zamiast lub wraz z naprawą wady. W tym przypadku stosuje się przepisy artykułu 533

Artykuł 635

Kiedy w przedmiocie umowy jest wada i z tego powodu nie można osiągnąć celu umowy, zamawiający może rozwiązać umowę. Jednakże, nie dotyczy to budynków i innych konstrukcji związanych z ziemią.

Co do stopniowego rozróżnienia “wad”, omówiliśmy to szczegółowo w poniższym artykule.

https://monolith.law/corporate/defect-warranty-liability[ja]

Następnie należy jasno określić, czego należy żądać od dostawcy

Następnie musisz jasno określić, czego powinieneś żądać od drugiej strony. Jeśli chcesz rozwiązać umowę, nie wystarczy udowodnić, że jest to wada, musisz również udowodnić, że jest to na tyle poważne, że “nie można osiągnąć celu umowy”. W ocenie “celu” ważne są takie rzeczy jak protokoły z posiedzeń odbywających się na początku projektu rozwoju systemu czy zapisy w specyfikacji. Ponieważ możliwe jest, że błędy i usterki zostaną wykryte po akceptacji, ważne jest, aby zachować wszelkie dokumenty nawet po zakończeniu projektu rozwoju.

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

W przypadku innych niż rozwiązanie, możliwe jest żądanie odszkodowania za szkody lub naprawy wad jako treści gwarancji za wady.

Inne punkty do rozważenia

Podczas podejmowania działań prawnych, takich jak rozwiązanie umowy, ważne jest, jak to zrobić

Jeśli zawartość odpowiedzialności za wady jest taka, że umowa jest rozwiązana, powinieneś również nauczyć się, jak przeprowadzić procedury prawne do rozwiązania umowy. Szczegółowe wyjaśnienia dotyczące skutków rozwiązania umowy, skutecznego wyrażenia woli, sposobu powiadamiania, aby uniknąć problemów w przyszłości, są dostępne w poniższym artykule.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Preferowane jest rozwiązanie poprzez negocjacje, a nie spory

Ponadto, te wszystkie argumenty prawne nie mają znaczenia tylko wtedy, gdy dochodzi do procesu sądowego. Rozwiązanie sporu przez sąd jest bardzo obciążające dla obu stron. Zamiast tego, te wiedze powinny być wykorzystane na etapie negocjacji przed procesem sądowym. Szczegółowe wyjaśnienia na temat znaczenia tej wiedzy prawnej w negocjacjach poza sądem są dostępne w poniższym artykule.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

Powinniśmy rozróżniać między błędami i usterkami a brakiem funkcji

Dyskusja różni się w zależności od tego, czy istnieją błędy lub usterki w funkcjach lub specyfikacjach, które zostały zaimplementowane, czy też nie ma niezbędnych funkcji. Jeśli nie ma wszystkich niezbędnych funkcji, “zakończenie pracy” w umowie o zlecenie może nie być uznane, a wykonanie zobowiązania może nie być uznane.

Nawet jeśli nie ma tych niezbędnych funkcji lub specyfikacji, jeśli wynika to z faktu, że użytkownik nie dostarczył odpowiednich informacji na etapie definiowania wymagań, może być niewłaściwe uważać to za część treści umowy.

Podsumowanie

Problemy, które pojawiają się w trakcie realizacji projektu, mogą ujawnić się zarówno podczas jego trwania, jak i na etapie eksploatacji, czyli po zakończeniu. Charakterystyczną cechą projektów związanych z rozwojem systemów jest to, że nie zawsze można czuć się bezpiecznie, nawet po pomyślnym zakończeniu wszystkich etapów. Wydaje się, że jest to symbolizowane przez system odpowiedzialności za wady, znanego jako “odpowiedzialność za gwarancję jakości”. Uważa się, że ważne jest zarówno dokładne zarządzanie dokumentacją, uwzględniające okres po zakończeniu projektu rozwoju systemu, jak i zrozumienie całego tego procesu.