Ce măsuri se iau în cazul întreruperii dezvoltării sistemului din cauza utilizatorului?

Activitatea de dezvoltare a sistemelor este adesea un proiect pe termen lung. Dar ce se poate face dacă, după ce ați început să lucrați la dezvoltarea unui sistem, utilizatorul vă spune unilateral că “nu mai este nevoie de acel sistem, așa că nu trebuie să-l mai creați”? Ce opțiuni are furnizorul care a acceptat acest lucru?

Acest articol va clarifica caracteristicile specifice ale contractelor de dezvoltare a sistemelor și va explica măsurile care pot fi luate în astfel de situații.

Importanța considerării întreruperii datorate convenienței utilizatorului

Contractul de dezvoltare a sistemelor are câteva caracteristici notabile atunci când este privit ca un contract. Una dintre ele este faptul că perioada de lucru este de obicei lungă și, ca obligație de management al proiectului, partea furnizorului are o mare discreție și o responsabilitate semnificativă. Detaliile complete despre obligațiile de management al proiectului pe care le are partea furnizorului sunt explicate în detaliu în articolul de mai jos.

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

De asemenea, un alt aspect este faptul că utilizatorul, chiar și clientul, are o obligație largă de a coopera cu activitățile furnizorului. Dacă este un sistem utilizat în interiorul companiei, nu este suficient să fie “aruncat” către partea furnizorului. Există o obligație de a coopera corespunzător de la interiorul companiei, astfel încât furnizorul să poată aplica expertiza în activitatea sa. Acest lucru este explicat în detaliu în articolul de mai jos.

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

Dacă rezumăm conținutul de mai sus în mod simplu, între furnizor și utilizator există o relație de contraprestație ca “contractor extern” care dezvoltă sistemul și “clientul” care plătește recompensa, dar în același timp, există și o fațetă ca “colegi” care ar trebui să colaboreze pentru a atinge obiectivul comun al realizării proiectului. Această complexitate a relației nu este de obicei prezentă în cazul unui croitor care face costume la comandă, și este o caracteristică majoră a contractelor legate de dezvoltarea sistemelor. Disputele legate de dezvoltarea sistemelor sunt adesea complicate din cauza acestei complexități a relației, și odată ce se încurcă, devine dificil să se clarifice legal relația dintre cele două părți.

Este important să ne gândim la problema de a înțelege relația dintre drepturi și obligații atunci când partea utilizatorului se răzgândește și spune brusc “În cele din urmă, nu mai avem nevoie de acel sistem, așa că nu mai este nevoie să continuăm proiectul”. Într-un sens, acest lucru are și semnificația de a prezenta un exemplu de gândire juridică în fața unei astfel de relații contractuale complexe. În continuare, vom organiza problemele care ar trebui examinate ulterior, presupunând acest caz.

În primul rând, organizați motivele pentru care a fost solicitată rezilierea

Chiar și în cazurile în care, din perspectiva furnizorului, “utilizatorul dorește să întrerupă unilateral proiectul”, nu este neapărat că această percepție este împărtășită cu utilizatorul. Să luăm ca exemplu un caz în care a fost inițiat un proiect pentru dezvoltarea unui sistem de gestionare a personalului pentru angajații staționați la birourile din străinătate, iar mai târziu planul de expansiune în străinătate a fost retras, făcând dezvoltarea acestui sistem inutilă. Într-adevăr, dacă ne uităm doar la această explicație, s-ar putea interpreta ca o schimbare unilaterală de opinie din partea utilizatorului.

Însă, dacă există circumstanțe care au condus la această decizie, cum ar fi încălcarea obligațiilor de management al proiectului de către furnizor, cum ar fi întârzierile în diferite etape, și dacă dificultățile în progresul dezvoltării au fost unul dintre factorii care au condus la schimbarea politicii companiei, cum ar fi?

După cum am menționat anterior, dezvoltarea de sisteme implică o responsabilitate mare atât pentru furnizor, cât și pentru utilizator, și trebuie să progreseze în strânsă colaborare. Prin urmare, chiar dacă utilizatorul este cel care a inițiat întreruperea și furnizorul consideră că este o reziliere din cauza circumstanțelor personale ale utilizatorului, ar trebui să fie conștient de posibilitatea ca acesta să fie acuzat de motive imputabile furnizorului și să se revendice rezilierea pe baza neexecutării obligațiilor sau rezilierea de comun acord.

Diferențierea între rezilierea din cauza circumstanțelor personale, rezilierea pe baza neexecutării obligațiilor sau rezilierea de comun acord depinde în mare măsură de progresul proiectului și de istoricul negocierilor, și este adesea judecată individual pentru fiecare caz. Prin urmare, dacă furnizorul continuă să proceseze post-procesarea pe baza înțelegerii că este o reziliere din cauza circumstanțelor personale ale utilizatorului, este important să păstreze o înregistrare clară a acestui fapt în minutele de întâlnire, etc., pentru a preveni disputele ulterioare pe acest punct.

Verificarea prevederilor legale pentru cererea de remunerație și despăgubiri

Luând în considerare aspectele menționate mai sus, în cazul în care discuția se poate continua ca o reziliere a contractului din proprie inițiativă a utilizatorului, următorul pas este să evaluăm dacă furnizorul poate solicita utilizatorului o remunerație proporțională cu procentul de finalizare a lucrării sau despăgubiri.

Prevederile legale de referință în astfel de cazuri variază în funcție de tipul de contract. Contractele pentru dezvoltarea de sisteme pot fi clasificate, în linii mari, în contracte de prestări de servicii și contracte de mandat.

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

Și, în cazul contractelor de mandat și al contractelor de prestări de servicii, Codul Civil Japonez (Legea Civilă Japoneză) prevede următoarele:

a.) În cazul contractelor de mandat
Cererea de remunerație: Articolul 648 alineatul (3) din Codul Civil Japonez
Când mandatul se încheie în timpul executării din cauze care nu pot fi imputate mandatarului, acesta poate solicita o remunerație proporțională cu ceea ce a executat deja.
Cererea de despăgubiri: Articolul 651 din Codul Civil Japonez
1. Mandatul poate fi reziliat în orice moment de către oricare dintre părți.
2. Dacă una dintre părți reziliază mandatul într-un moment defavorabil celeilalte părți, acea parte trebuie să despăgubească daunele celeilalte părți. Cu toate acestea, aceasta nu se aplică dacă există motive justificabile.

b.) În cazul contractelor de prestări de servicii
Cererea de despăgubiri: Articolul 641 din Codul Civil Japonez
Cât timp prestatorul de servicii nu a finalizat lucrarea, clientul poate rezilia contractul în orice moment, despăgubind daunele.

De asemenea, se consideră că domeniul de aplicare al despăgubirilor în baza articolului 641 din Codul Civil Japonez include nu numai costurile deja suportate, dar și “profitul care ar fi fost obținut dacă contractul nu ar fi fost reziliat”. Acest lucru reflectă ideea că este inutil ca legea să forțeze finalizarea lucrării care a devenit inutilă pentru client, și că, în astfel de cazuri, este mai rațional să se garanteze profitul prestatorului de servicii prin plata unei sume echivalente.

În ceea ce privește despăgubirile în baza articolului 641 din Codul Civil Japonez, nu este neobișnuit ca acestea să fie excluse în contractele individuale între furnizor și utilizator. În astfel de cazuri, promisiunile individuale între părți (adică contractul) au prioritate, și prevederile Codului Civil Japonez nu se aplică, așa că este necesară precauție.

Avansarea dovezilor de volum și daune

În cazul rezilierii din proprie inițiativă de către utilizator, cele mai frecvente în contract sunt prevederile care permit solicitarea de comisioane pentru volumul de muncă (adică partea finalizată) și solicitarea de despăgubiri. Prin urmare, de obicei, este necesar ca partea furnizorului să furnizeze dovezi cu privire la volumul de muncă și daunele pentru a solicita despăgubiri.

Cu toate acestea, se poate prevedea că furnizarea de dovezi cu privire la acest volum de muncă, adică procentul de finalizare, poate fi o sarcină foarte dificilă dacă este efectuată în realitate. Acest lucru se datorează faptului că, dacă există mai mulți subcontractanți, cantitatea de audieri necesare pentru a verifica progresul, cum ar fi cât de mult a fost finalizat fiecare element de lucru, poate fi considerabilă dacă este efectuată în realitate. În plus, dacă trebuie să creați documente pentru a susține rezultatele audierilor și să documentați conținutul audierilor în sine, efortul va fi enorm. Există multe dificultăți, cum ar fi riscul ca, chiar și după toate acestea, să se spună că dovezile sunt insuficiente, ceea ce ar face ca efortul depus pentru pregătirea dovezilor să fie în zadar.

Ținând cont de aceste aspecte, ca măsură, se poate lua în considerare, de exemplu, să se menționeze clar de la începutul etapei contractuale că, în cazul rezilierii pe parcurs, se va calcula pro rata pe baza numărului de zile până la momentul rezilierii, pentru a simplifica calculul. De asemenea, având în vedere efortul necesar pentru a furniza dovezi pentru volumul de muncă, se poate lua în considerare renunțarea la solicitarea pentru volumul de muncă în sine și solicitarea de “costuri implicate în dezvoltarea părții deja finalizate”. Dacă este vorba de costuri de dezvoltare interne, nu este neobișnuit să puteți calcula simplu cu formula “numărul de ore x tarif”. În special pentru proiectele cu o rată scăzută a profitului, prin prioritizarea solicitării pe baza costurilor, nu a volumului de muncă, se poate aștepta la compensarea pierderilor, luând în considerare ușurința recuperării creanțelor, ceea ce poate fi o măsură de salvare mai realistă în multe cazuri.

Ce ar trebui să ia în considerare partea utilizatorului?

De altfel, există și aspecte pe care utilizatorii ar trebui să le ia în considerare înainte de a iniția rezilierea contractului din motive proprii. Unul dintre acestea este să verifice în prealabil cu furnizorul care ar fi suma aproximativă a despăgubirilor pe care ar trebui să le plătească. Când vorbim de “suma aproximativă”, ne referim la stabilirea unei estimări generale care să servească drept ghid pentru negocierile ulterioare (deoarece întârzierea exprimării intenției de reziliere ar fi contraproductivă, nu este necesară o sumă exactă).

Dacă suma estimată pare nejustificat de mare, ar trebui să solicitați o explicație. Cu toate acestea, dacă încercați să negociați în mod excesiv pentru a reduce suma de plată, există riscul de a provoca litigii inutile care ar putea complica și mai mult situația. Dacă negocierile între cele două părți par dificile, ar putea fi o idee bună să consultați un avocat.

De asemenea, acest articol a presupus că există un contract în vigoare pentru dezvoltarea de sisteme. În realitate, în cadrul dezvoltării de sisteme, nu este neobișnuit ca validitatea contractului în sine să fie pusă sub semnul întrebării. Detalii despre acest subiect pot fi găsite în articolul de mai jos.

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

Rezumat

Acest articol a explicat procesul de gestionare a cazurilor în care un proiect este întrerupt din cauza utilizatorului. Cu toate acestea, punctul principal al acestui articol este necesitatea de a examina dacă este cu adevărat o problemă de conveniență personală a utilizatorului și dacă furnizorul nu a avut cu adevărat nicio greșeală.

Dezvoltarea de sisteme, un proiect în care atât furnizorul cât și utilizatorul își asumă responsabilități mari, este caracteristică. Prin urmare, dacă nu examinați în prealabil dacă este cu adevărat posibil să atribuiți unilateral vina partenerului, s-ar putea să ajungeți într-o situație care ar putea adăuga combustibil la foc. Acest lucru ar trebui să fie conștientizat.