Czym jest obowiązek wsparcia, który dostawca musi ponieść po zakończeniu rozwoju systemu?

W kontekście rozwoju systemów, dobrze wiadomo, że specjaliści od rozwoju systemów, zwani dostawcami, ponoszą “obowiązek zarządzania projektem”. Jednakże, obok tego, istnieje podobne, ale nieco inne pojęcie w prawie, zwane “obowiązkiem wsparcia”. W tym artykule omówimy “obowiązek wsparcia”, uwzględniając wcześniejsze precedensy sądowe.

Co to jest obowiązek wsparcia?

Podstawy obowiązku wsparcia

W kontekście obowiązków, które dostawca ma wobec użytkownika, jednym z najbardziej typowych jest obowiązek zarządzania projektem. Jest to koncepcja, która została ugruntowana poprzez wielokrotne odwołania do niej w poprzednich wyrokach sądowych, i obejmuje obowiązki, które dostawca, jako ekspert w dziedzinie rozwoju systemów, ma wobec całego projektu.

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

Obowiązek zarządzania projektem jest bardzo znanym terminem prawnym w kontekście rozwoju systemów, i nie ma wątpliwości, że jest to jedno z głównych obowiązków, które dostawca podejmuje. Jednakże, w niektórych wyrokach sądowych, obok obowiązku zarządzania projektem, uznano istnienie innego obowiązku, zwanego “obowiązkiem wsparcia”.

Obowiązek wsparcia staje się problemem w kontekście wsparcia operacyjnego dla użytkowników

Więc czym jest obowiązek wsparcia? I dlaczego jest on nazywany innym terminem niż obowiązek zarządzania projektem? Obowiązek wsparcia staje się problemem zazwyczaj po zakończeniu rozwoju systemu. Projekt rozwoju systemu, będąc “rozwojem”, kończy się zasadniczo po zakończeniu tworzenia systemu, który miał być stworzony. To znaczy, projekt rozwoju systemu zaczyna się od określenia, co ma być stworzone (definicja wymagań), a kończy się potwierdzeniem, czy to, co miało być stworzone, zostało rzeczywiście stworzone (testowanie lub akceptacja). Co do procesu akceptacji, biorąc pod uwagę, że ma on “ważne znaczenie jako zakończenie projektu rozwoju systemu”, omawiamy szczegółowo typowe problemy prawne, które mogą wystąpić na tym etapie, w poniższym artykule.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Jednakże, nawet jeśli projekt rozwoju systemu jest rozumiany jako sam proces tworzenia nowego systemu, jest oczywiste, że system, który został rozwinięty, będzie później wykorzystywany w działalności. Innymi słowy, jest nieracjonalne, aby całkowicie zignorować kwestię, jak wykorzystać system po jego rozwoju, i stwierdzić, że “jako osoba odpowiedzialna tylko za rozwój, wystarczy, że go stworzę”. Biorąc pod uwagę te kwestie, w poprzednich wyrokach sądowych, pojawiło się pytanie, czy nie można nałożyć na dostawcę, który jest odpowiedzialny za rozwój systemu, pewnego obowiązku wsparcia operacyjnego. To znaczy, czy w ramach obowiązków, które dostawca ma w ramach umowy o rozwój systemu, nie powinno się uwzględnić obowiązków związanych z wsparciem operacyjnym po rozwoju. Ponieważ wsparcie operacyjne nie jest częścią samego procesu rozwoju, termin “obowiązek wsparcia” został użyty w celu odróżnienia go od obowiązku zarządzania projektem.

Przykłady sądowe, w których problemem były obowiązki wsparcia

Przypadek, w którym problemy w trakcie testów systemowych zakłóciły działalność użytkownika

W przypadku cytowanego poniżej wyroku, podczas testów systemowych przeprowadzonych przed uruchomieniem systemu, użytkownik nie był w stanie wykorzystać systemu tak, jak pierwotnie zakładał, co skutkowało rezygnacją z uruchomienia systemu. Problemem w tym przypadku było ustalenie, na jakiej podstawie można uzasadnić odpowiedzialność dostawcy na podstawie umowy o wykonanie prac na rzecz rozwoju systemu, która została zawarta wcześniej. W rezultacie, roszczenie o odszkodowanie ze strony użytkownika zostało uznane, a jako podstawę wskazano “naruszenie obowiązku wsparcia”.

I Naruszenie obowiązku wsparcia
(A) Przedstawiciel powoda, 14 lipca 1997 roku (Heisei 9), zwrócił się do pozwanego z prośbą: “Nie tylko twórz system, ale dbaj o niego do końca, aby działał poprawnie.“, “Jesteśmy laikami, płacimy dużo pieniędzy, więc chcemy, aby działał do końca.“. W odpowiedzi na to, pozwany wyjaśnił, że jest w stanie zbudować system, który umożliwi osiągnięcie celów wprowadzenia i obiecał wsparcie do momentu, gdy system będzie działał poprawnie. W rezultacie, między powodem a pozwanym doszło do porozumienia, że pozwany będzie świadczyć wsparcie do momentu, gdy powód będzie w stanie poprawnie korzystać z systemu.
Obowiązek wsparcia ze strony pozwanego dla powoda jest oczywisty, biorąc pod uwagę, że koszty w wysokości 1 726 000 jenów zostały uwzględnione jako opłata za umowę pod pozycją “Wsparcie przy wprowadzaniu pakietu”, a w kosztorysie, w odniesieniu do miesięcznej opłaty za utrzymanie, zapisano “bezpłatne utrzymanie przez sześć miesięcy po wprowadzeniu”, a w dokumencie zatytułowanym “Wsparcie SE w przyszłości (materiały do narady wewnętrznej)” potwierdzono, że można otrzymać wsparcie SE w zakresie “tworzenia procedur wprowadzenia (planu)” i “pracy nad weryfikacją danych / operacji” w odniesieniu do zamówień świeżych produktów.

(B) A zatem, obowiązek wsparcia, który pozwany ma wobec powoda, konkretnie obejmuje co najmniej: ①udzielanie odpowiednich porad dotyczących sposobu korzystania z systemu, ②uczestnictwo w testach operacyjnych i reagowanie na problemy z systemem, które wystąpiły podczas tych testów, ③poprawianie systemu w odpowiedzi na wyniki testów operacyjnych, ④prowadzenie szkoleń dla operatorów.
Jednakże, pozwany, mimo licznych problemów podczas testów operacyjnych, nie zareagował na nie poważnie, twierdząc, że są one problemem doświadczenia operatorów, i żądał jedynie opłat za szkolenie operatorów, nie świadcząc powodowi żadnego odpowiedniego wsparcia w kierunku pełnej operacyjności.

Wyroki Sądu Okręgowego w Hachioji w Tokio, 5 listopada 2003 roku (Heisei 15)

W tym wyroku, włączając spis treści, słowo “wsparcie” pojawia się około 30 razy w całym tekście wyroku. Można zauważyć, że jest to konkluzja, która dąży do sprawiedliwego rozwiązania, biorąc pod uwagę szczegółowy kontekst sprawy, w tym bezpośrednie odzwierciedlenie głosu użytkownika żądającego odpowiedniego wsparcia. Szczególnie warto zwrócić uwagę na następujące aspekty związane z zrozumieniem tego przypadku:

• Naruszenie obowiązku wsparcia jest traktowane jako “niewykonanie zobowiązań”, co prowadzi do nakazania odszkodowania za wynikłe z tego powodu szkody
• Termin “obowiązek zarządzania projektem” nie jest używany ani razu w całym tekście wyroku

Można zauważyć podejście, które traktuje to jako koncepcję odrębną od zarządzania projektem, ale próbuje traktować to jako obowiązek wynikający z umowy, który jest zawarty w umowie o rozwój systemu.

Jak należy interpretować naturę obowiązku wsparcia?

Obowiązek wsparcia nie jest jeszcze jasno zdefiniowany

Wcześniej wspomniane orzeczenie sugeruje, że dostawca, który rozwija system, powinien również zapewnić niezbędne wsparcie, aby użytkownik mógł rozpocząć jego eksploatację. Jednak obowiązek wsparcia nie jest tak dobrze udokumentowany w orzecznictwie jak obowiązek zarządzania projektem, a informacje na jego temat nie są tak liczne. Szczególnie termin “wsparcie” sam w sobie zawiera problem, ponieważ nie jest jasne, co konkretnie powinno być zrobione.

Obowiązek wsparcia nie jest nieograniczony

Ponadto, wyrok, który uznał naruszenie obowiązku wsparcia przez dostawcę, również wskazał bardzo ważny punkt.

Pozwany, na podstawie niniejszej umowy o zlecenie, jest zobowiązany do zapewnienia pewnego wsparcia, które jest niezbędne dla powoda, aby mógł eksploatować system, który został zbudowany i dostarczony powodowi. Jednakże, nie można uznać, że jego treść była taka, jak twierdzi powód, że bez ograniczenia czasu, aż powód będzie faktycznie w stanie eksploatować system, wszelkie wsparcie jest bezpłatne.

Wyrok Sądu Okręgowego w Hachioji w Tokio z dnia 5 listopada 2003 roku (rok Heisei 15)

Jeśli głównym zadaniem jest rozwój systemu, można przypuszczać, że istnieją pewne ograniczenia w zakresie tego, co powinno być zrobione jako wsparcie dla późniejszej eksploatacji. W tym wyroku, sąd zwrócił uwagę na kilka charakterystycznych punktów, takich jak cytowanie opinii użytkowników proszących o wsparcie w tekście wyroku, odwoływanie się do treści wcześniejszych szacunków, czy istnieje specjalny układ dotyczący świadczenia wsparcia itp. Innymi słowy, biorąc pod uwagę, że rozszerzenie koncepcji obowiązku wsparcia na nieskończoność spowodowałoby duże obciążenie dla dostawcy, można przypuszczać, że zamiar był taki, aby podejść do uznania naruszenia obowiązku z pewną ostrożnością.

Substancja obowiązku wsparcia powinna być rozważana wraz z obowiązkiem współpracy użytkownika

Podsumowując, można powiedzieć, że jest to kwestia “jak użytkownik i dostawca powinni dzielić się obciążeniem pracy w początkowej fazie eksploatacji w rozwoju systemu”. Zawiera to na pewno nieco skomplikowane pytanie, jakie prawne obowiązki dostawca powinien podjąć przy rozpoczęciu eksploatacji na podstawie umowy dotyczącej “rozwoju”. Jednocześnie, nie można zaprzeczyć, że istnieje silna tendencja do wymagania oceny na podstawie indywidualnych okoliczności.

Jednakże, to, jakie jest rzeczywiste znaczenie obowiązku wsparcia, które dostawca musi podjąć, staje się bardziej pewne, gdy zrozumie się obowiązek współpracy, który użytkownik musi podjąć.

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

Przede wszystkim, inicjatywa polegająca na ulepszaniu pracy za pomocą nowego systemu ma aspekt wspólnej pracy dostawcy, który jest specjalistą w dziedzinie technologii, i użytkownika, który posiada wiedzę o pracy w firmie. Dlatego też, jeśli chodzi o tzw. obowiązek wsparcia, wyraźne określenie kwestii, które użytkownik powinien rozwiązać poprzez własne wysiłki jako część “wykonywania obowiązku współpracy”, często prowadzi do samoistnego określenia jego zakresu.

Podsumowanie

W tym artykule, na podstawie podstaw zarządzania projektami, dokonaliśmy uporządkowania kwestii “obowiązku wsparcia”, który można by nazwać pochodną zarządzania projektami. Chociaż koncepcja obowiązku wsparcia nadal ma wiele niejasności, uważamy, że podstawowe kwestie, takie jak “obowiązek zarządzania projektem” i “obowiązek współpracy”, są nadal kluczowe dla jej zrozumienia.