Jak radzić sobie w sytuacji, gdy rozwój systemu zostaje przerwany z powodu użytkownika?

Zadanie takie jak rozwój systemu często przybiera formę długotrwałego projektu. Co jednak, jeśli po rozpoczęciu prac nad rozwojem systemu, użytkownik jednostronnie stwierdzi, że “ten system już nie jest potrzebny, więc nie musisz go tworzyć”? Co może zrobić dostawca, który przyjął to zadanie?

W tym artykule omówimy charakterystyczne cechy umowy dotyczącej rozwoju systemu oraz strategie radzenia sobie w takiej sytuacji.

Znaczenie rozważenia przerwania z powodu użytkownika

Umowa o rozwój systemu ma kilka charakterystycznych cech, jeśli spojrzeć na nią jako na umowę. Jedną z nich jest to, że okres realizacji jest zazwyczaj długotrwały, a dostawca, mając duże uprawnienia, ma również duże obowiązki w zarządzaniu projektem. Szczegółowe wyjaśnienie ogólnej treści obowiązków zarządzania projektem, które dostawca musi podjąć, można znaleźć w poniższym artykule.

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

Inną cechą jest to, że użytkownik, nawet jeśli jest klientem, ma szeroki zakres obowiązków współpracy z dostawcą. System używany wewnętrznie w firmie nie może być po prostu “zrzucony” na dostawcę. Wewnętrznie, w firmie, istnieje obowiązek współpracy, aby dostawca mógł wykorzystać swoją specjalistyczną wiedzę w pracy. Szczegółowe wyjaśnienie na ten temat można znaleźć w poniższym artykule.

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

Podsumowując powyższe, między dostawcą a użytkownikiem istnieje związek oparty na zapłacie, gdzie “zewnętrzny dostawca” rozwija system, a “klient” płaci wynagrodzenie, ale jednocześnie obie strony powinny współpracować w celu osiągnięcia wspólnego celu, jakim jest realizacja projektu. Ta złożoność relacji nie jest typowa dla zwykłych krawców szyjących garnitury na zamówienie, ale jest jedną z głównych cech umów związanych z rozwojem systemów. Spory związane z rozwojem systemów są skomplikowane z powodu tych relacji, a jeśli raz się zaplączą, staje się skomplikowane, jak należy uporządkować relacje między stronami z punktu widzenia prawa.

Jeśli użytkownik zmieni zdanie i nagle powie: “W końcu nie potrzebujemy tego systemu, więc nie musisz kontynuować projektu”, warto rozważyć, jak należy zrozumieć relacje praw i obowiązków między stronami. W pewnym sensie, to jest przykład myślenia prawnego w obliczu tak skomplikowanych relacji umownych. Poniżej omówimy kwestie, które należy rozważyć po założeniu takiej sytuacji.

Najpierw uporządkuj powody, dla których złożono wniosek o rozwiązanie umowy

Z punktu widzenia dostawcy, może wystąpić sytuacja, w której “użytkownik jednostronnie chce przerwać projekt”, ale nie zawsze jest to postrzegane tak samo przez użytkownika. Na przykład, rozważmy sytuację, w której projekt dotyczący tworzenia systemu do zarządzania pracownikami delegowanymi do pracy w zagranicznych oddziałach został uruchomiony, a później plany ekspansji za granicę zostały wycofane, co sprawiło, że rozwój takiego systemu stał się zbędny. Rzeczywiście, patrząc tylko na to wyjaśnienie, można by to interpretować jako jednostronne zmienienie zdania przez użytkownika.

Jednakże, co jeśli w procesie prowadzącym do takiej decyzji, dostawca również miał problemy z naruszeniem obowiązków zarządzania projektem, takich jak opóźnienia w poszczególnych etapach, a trudności z postępem w rozwoju samego projektu również przyczyniły się do zmiany polityki firmy?

Jak wcześniej wspomniano, rozwój systemu to proces, w którym zarówno dostawca, jak i użytkownik ponoszą duże obowiązki i muszą ściśle współpracować. Dlatego, nawet jeśli to użytkownik zainicjował przerwanie projektu, a dostawca uważał, że jest to rozwiązanie umowy z powodu własnych okoliczności użytkownika, istnieje możliwość, że zostanie wskazany powód, dla którego dostawca jest odpowiedzialny, i zostanie zarzucone twierdzenie, że jest to rozwiązanie umowy na podstawie niewykonania zobowiązań lub rozwiązanie umowy za porozumieniem stron.

Różnica między rozwiązaniem umowy z powodu własnych okoliczności, rozwiązaniem umowy na podstawie niewykonania zobowiązań, a rozwiązaniem umowy za porozumieniem stron często zależy od postępu projektu i dotychczasowego przebiegu negocjacji. Dlatego, jeśli dostawca zamierza kontynuować postępowanie po rozwiązaniu umowy z powodu własnych okoliczności użytkownika, ważne jest, aby jasno zaznaczyć to w protokołach z posiedzeń i innych dokumentach, aby uniknąć późniejszych sporów na ten temat.

Następnie sprawdź podstawę prawna dla roszczeń o wynagrodzenie i odszkodowanie

Biorąc pod uwagę powyższe punkty, jeśli możemy kontynuować rozmowę jako rezygnację z usług z powodów leżących po stronie użytkownika, następnie rozważamy, czy dostawca może wystąpić z roszczeniem o wynagrodzenie proporcjonalne do stopnia realizacji lub o odszkodowanie od użytkownika.

Artykuły, które należy odnosić w takich przypadkach, różnią się w zależności od typu umowy. Umowy dotyczące rozwoju systemów można generalnie podzielić na umowy o dzieło i umowy o zlecenie.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

W przypadku umów o zlecenie i umów o dzieło, Kodeks Cywilny (japoński Kodeks Cywilny) zawiera następujące postanowienia:

a.) W przypadku umowy o zlecenie
Roszczenie o wynagrodzenie: Artykuł 648 paragraf 3 Kodeksu Cywilnego
Jeśli zlecenie zostanie zakończone w trakcie realizacji z powodów, które nie mogą być przypisane zleceniobiorcy, zleceniobiorca może żądać wynagrodzenia proporcjonalnego do stopnia realizacji.
Roszczenie o odszkodowanie: Artykuł 651 Kodeksu Cywilnego
1. Zlecenie może być anulowane przez każdą ze stron w dowolnym momencie.
2. Jeśli jedna ze stron anuluje zlecenie w niekorzystnym dla drugiej strony momencie, ta strona musi zrekompensować drugiej stronie szkodę. Jednakże, nie dotyczy to sytuacji, gdy istnieją nieuniknione okoliczności.

b.) W przypadku umowy o dzieło
Roszczenie o odszkodowanie: Artykuł 641 Kodeksu Cywilnego
Zamawiający może w dowolnym momencie anulować umowę, rekompensując szkodę, dopóki wykonawca nie zakończy pracy.

Zakres odszkodowania na podstawie artykułu 641 Kodeksu Cywilnego obejmuje nie tylko już poniesione koszty, ale także “zyski, które mogłyby być uzyskane, gdyby umowa nie została anulowana”. Jest to odzwierciedlenie poglądu, że jest bezsensowne, aby prawo wymagało zakończenia pracy, która stała się niepotrzebna dla zamawiającego, i że w takich przypadkach racjonalniejsze jest gwarantowanie zysków wykonawcy poprzez zapłatę równoważnej kwoty.

Jednakże, co do odszkodowania na podstawie artykułu 641 Kodeksu Cywilnego, nie jest rzadkością, że w indywidualnych umowach między dostawcą a użytkownikiem, odszkodowanie jest wyłączone z roszczeń. W takich przypadkach, indywidualne umowy między stronami (tj. umowy) mają pierwszeństwo, a przepisy Kodeksu Cywilnego nie mają zastosowania, co wymaga ostrożności.

Dalsze dowodzenie na rzecz obrotu i szkód

W przypadku rezygnacji z umowy z własnej inicjatywy przez użytkownika, najczęściej spotykanym zapisem w umowie jest możliwość wystąpienia z roszczeniem o opłatę za wykonaną pracę (tj. część zakończoną) oraz o odszkodowanie za szkody. Z tego powodu, zwykle od strony dostawcy wymagane jest dowodzenie na rzecz obrotu i szkód, aby wystąpić z roszczeniem o odszkodowanie.

Jednakże, dowodzenie na rzecz takiego obrotu, czyli stopnia ukończenia, może okazać się bardzo trudnym zadaniem. Dlaczego? Ponieważ, szczególnie gdy mamy do czynienia z wieloma podwykonawcami, przeprowadzenie wywiadów w celu sprawdzenia postępów, może okazać się bardzo czasochłonne. Dodatkowo, tworzenie dokumentacji potwierdzającej wyniki tych wywiadów, a także dokumentowanie samej treści wywiadów, może zająć ogromną ilość czasu. Jeśli mimo to istnieje ryzyko, że dowody będą niewystarczające, cały wysiłek włożony w przygotowanie dowodów może okazać się daremny, co stanowi jedno z wielu potencjalnych problemów.

Biorąc pod uwagę powyższe, możliwe są takie środki zaradcze jak jasne określenie na etapie umowy, że w przypadku rezygnacji w trakcie trwania umowy, obliczenia będą dokonywane proporcjonalnie do liczby dni do dnia rezygnacji, co pozwoli na proste obliczenia. Ponadto, zważywszy na trudności związane z dowodzeniem na rzecz obrotu, można rozważyć rezygnację z roszczeń dotyczących samego obrotu i zamiast tego wystąpić z roszczeniem o “koszty poniesione na rozwój już ukończonej części”. W przypadku kosztów rozwoju wewnętrznego, nie jest rzadkością, że można je łatwo obliczyć za pomocą prostego wzoru “ilość godzin x stawka”. Szczególnie w przypadku projektów o niskiej marży, priorytetowanie roszczeń opartych na kosztach, a nie na obrotach, może ułatwić odzyskiwanie należności i rekompensatę za straty, co często stanowi bardziej realistyczne środki zaradcze.

Co powinien rozważyć użytkownik z perspektywy odwrotnej?

Przy okazji, również po stronie użytkownika, który zamierza wypowiedzieć umowę z własnej inicjatywy, istnieją punkty, które należy rozważyć z góry. Chodzi o to, aby sprawdzić przybliżoną kwotę odszkodowania, które należy zapłacić między użytkownikiem a dostawcą. Kiedy mówimy o “przybliżonej” kwocie, chodzi o ustalenie ogólnego punktu odniesienia, aby umożliwić przewidywanie przebiegu przyszłych negocjacji (opóźnienie w wyrażeniu woli wypowiedzenia byłoby sprzeczne z celem, więc dokładna kwota nie jest konieczna).

Jeśli sprawdzona przybliżona kwota jest niewłaściwie wysoka, powinieneś poprosić o wyjaśnienie powodów. Jednak próba przeprowadzenia nierozsądnych negocjacji w celu ograniczenia kwoty płatności może prowadzić do bezsensownych procesów sądowych i dodatkowych komplikacji. Jeśli negocjacje między dwiema stronami wydają się trudne, rozważenie konsultacji z prawnikiem może być jednym z rozwiązań.

W tym artykule omówiliśmy na podstawie założenia, że umowa dotycząca rozwoju systemu została zawarta. Jednak w rzeczywistych sytuacjach rozwoju systemu, nie jest rzadkością, że spór dotyczy pytania, czy umowa została skutecznie zawarta. Szczegółowe wyjaśnienia na ten temat można znaleźć w poniższym artykule.

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

Podsumowanie

W tym artykule omówiliśmy proces radzenia sobie z sytuacją, gdy projekt jest przerywany z powodu okoliczności po stronie użytkownika. Jednak najważniejszym punktem tego artykułu jest pytanie, czy rzeczywiście można mówić o okolicznościach po stronie użytkownika, oraz czy po stronie dostawcy naprawdę nie było żadnych zaniedbań. To są kwestie, które należy rozważyć.

Charakterystyczną cechą projektu, jakim jest rozwój systemu, jest to, że zarówno dostawca, jak i użytkownik ponoszą duże obowiązki. Biorąc to pod uwagę, jeśli nie zastanowimy się wcześniej, czy rzeczywiście można obarczyć drugą stronę jednostronną odpowiedzialnością, może to prowadzić do sytuacji, która tylko podsyca ogień. To jest coś, co powinniśmy mieć na uwadze.