Ce înseamnă obligațiile de suport pe care le are furnizorul după finalizarea dezvoltării sistemului

În dezvoltarea de sisteme, este bine cunoscut faptul că furnizorii specializați în dezvoltarea de sisteme, cunoscuți sub numele de “vânzători”, au “obligația de gestionare a proiectului”. Cu toate acestea, în termeni legali, există și un concept similar, dar diferit, numit “obligația de suport”. În acest articol, vom explica “obligația de suport”, luând în considerare și exemplele de cazuri juridice anterioare.

Ce înseamnă obligația de suport

Prezentarea generală a obligației de suport

În discuția despre obligațiile pe care un furnizor le are față de utilizator, un exemplu reprezentativ este obligația de management al proiectului. Acesta este un concept care a fost stabilit de-a lungul timpului prin repetate referiri în cazurile judecătorești anterioare și reprezintă obligațiile pe care un furnizor, ca expert în dezvoltarea de sisteme, le are față de un proiect în ansamblu.

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

Obligația de management al proiectului este un termen juridic foarte cunoscut în domeniul dezvoltării de sisteme și nu există nicio îndoială că este una dintre principalele obligații pe care un furnizor le are. Cu toate acestea, unele cazuri judecătorești recunosc existența unei obligații diferite de obligația de management al proiectului, numită “obligația de suport”.

Obligația de suport devine problematică în ceea ce privește asistența operațională pentru utilizatori

Deci, ce este obligația de suport? Și de ce este numită diferit de obligația de management al proiectului? Obligația de suport devine de obicei problematică după finalizarea dezvoltării sistemului. Un proiect de dezvoltare a sistemului, fiind un “proiect de dezvoltare”, se încheie în mod normal odată cu finalizarea sistemului care trebuie creat. Adică, începe cu clarificarea a ceea ce trebuie să fie sistemul (definirea cerințelor) și se încheie cu confirmarea dacă acesta a fost realizat sau nu (testare sau acceptare). Problemele juridice care apar adesea la această etapă, acceptarea, sunt tratate în detaliu în articolul de mai jos, ținând cont de faptul că aceasta are o semnificație importantă ca “sfârșitul proiectului de dezvoltare a sistemului”.

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

Cu toate acestea, chiar dacă un proiect de dezvoltare a sistemului este înțeles ca fiind procesul de creare a unui nou sistem, este de la sine înțeles că sistemul dezvoltat va fi utilizat în activitățile ulterioare. Adică, este posibil să se considere că este nerezonabil să se ignore complet modul în care sistemul va fi utilizat după dezvoltare și să se spună că “atâta timp cât suntem responsabili doar pentru dezvoltare, trebuie doar să-l creăm”. Având în vedere aceste aspecte, în cazurile judecătorești anterioare, a fost pusă problema dacă nu ar trebui impusă o anumită obligație de asistență operațională furnizorului care se ocupă de dezvoltarea sistemului. Adică, problema este dacă nu ar trebui să se considere că obligațiile pe care un furnizor le are în cadrul unui contract de dezvoltare a sistemului includ și obligații legate de asistența operațională după dezvoltare. Deoarece asistența operațională nu face parte din procesul de dezvoltare în sine, se crede că termenul “obligație de suport” a fost folosit pentru a o distinge de obligația de management al proiectului.

Ce înseamnă cazurile de judecată în care a fost pusă în discuție obligația de suport

Un caz în care operațiunile utilizatorului au fost afectate în etapa de testare a sistemului

În cazul menționat în hotărârea de judecată citată mai jos, utilizatorul nu a putut utiliza sistemul așa cum se aștepta inițial în timpul testării sistemului efectuată înainte de punerea acestuia în funcțiune, ceea ce a dus la renunțarea la utilizarea sistemului în sine. Deși acesta a fost un incident la începerea operațiunilor de către utilizator, problema a fost cum să se stabilească responsabilitatea furnizorului pe baza contractului de dezvoltare a sistemului încheiat anterior. În final, s-a recunoscut cererea de despăgubire a utilizatorului, iar “încălcarea obligației de suport” a fost indicată ca motiv.

I Încălcarea obligației de suport
(A) Reprezentantul reclamantului a solicitat pârâtului la 14 iulie (1997), “Nu doar să creați sistemul, ci să aveți grijă de el până când funcționează corect.“, “Suntem amatori, așa că plătim mult și vrem să-l putem folosi până la sfârșit.“. În răspuns, pârâtul a explicat că este posibil să construiască un sistem care să îndeplinească obiectivele de implementare ale reclamantului și a promis să ofere suport până când acesta poate fi utilizat corect. Prin urmare, a fost încheiat un acord între reclamant și pârât ca pârâtul să ofere suport până când reclamantul poate utiliza corect sistemul.
Obligația pârâtului de a oferi suport reclamantului este evidentă din faptul că, ca preț al contractului în cauză, a înregistrat un cost de 17,26 milioane pentru “asistență pentru implementarea pachetului”, iar în estimarea costurilor, este menționat “suport gratuit pentru șase luni după implementare” pentru taxa lunară de întreținere, iar în documentul intitulat “Despre suportul SE în viitor (document de discuție internă)”, este confirmat că se poate primi suport SE pentru “crearea procedurii de implementare (plan)” și “verificarea datelor / operațiunilor” pentru comanda de produse proaspete.

(B) Și obligația de suport pe care pârâtul o are față de reclamant este, în mod concret, cel puțin până când reclamantul ajunge la funcționarea completă a sistemului, pârâtul trebuie să ofere reclamantului ①sfaturi adecvate despre cum să opereze sistemul, ②să participe la testele de operare și să răspundă la problemele sistemului care apar în timpul testelor de operare, ③să îmbunătățească sistemul în funcție de rezultatele testelor de operare, ④să ofere instruire operatorilor.
Cu toate acestea, chiar dacă au apărut multe probleme în timpul testelor de operare, pârâtul nu a luat în serios aceste probleme, cerând doar costurile de instruire a operatorilor și nu oferind niciun suport adecvat reclamantului pentru funcționarea completă.

Hotărârea Tribunalului Districtual Hachioji, Tokyo, 5 noiembrie (2003)

În această hotărâre de judecată, termenul “suport” apare de aproximativ 30 de ori în întregul text, inclusiv în cuprins. Se poate vedea că concluzia a fost atinsă în urma unei considerări foarte concrete a circumstanțelor cazului, cu vocea utilizatorului care solicită suport adecvat fiind înregistrată direct în hotărârea de judecată. În plus, punctele care ar trebui să fie deosebit de remarcate în înțelegerea acestui caz sunt:

• Încălcarea obligației de suport este tratată ca “neexecutarea obligațiilor”, astfel încât despăgubirile rezultate sunt ordonate
• Termenul “obligația de management al proiectului” nu este folosit nici măcar o dată în întreaga hotărâre de judecată

Se poate vedea o atitudine de a trata acesta ca o obligație contractuală inclusă în contractul de dezvoltare a sistemului, deși este un concept diferit de managementul proiectului.

Cum ar trebui interpretată natura obligației de suport?

Obligația de suport nu este încă un concept clar

Exemplul de caz menționat anterior indică în esență că furnizorul care a dezvoltat sistemul ar trebui să ofere și suportul necesar pentru ca utilizatorul să înceapă operarea. Cu toate acestea, obligația de suport nu are la fel de multe exemple de cazuri sau resurse abundente ca obligația de management al proiectului, iar indiciile pentru a înțelege realitatea sa nu sunt atât de numeroase. În special, termenul “suport” în sine include problema că nu este clar ce ar trebui să facă în mod concret.

Obligația de suport nu este recunoscută fără limită

În plus, hotărârea care a recunoscut încălcarea obligației de suport a furnizorului a indicat și un punct foarte important.

Defendantul, pe baza contractului de subcontractare în cauză, este considerat a avea obligația de a oferi un anumit suport necesar pentru ca reclamantul să opereze sistemul pe care l-a construit și livrat. Cu toate acestea, conținutul acestuia nu este considerat a fi așa cum susține reclamantul, fără a limita perioada, până când reclamantul poate opera efectiv sistemul în cauză, oferind tot suportul gratuit.

Hotărârea din 5 noiembrie 2003 (2003) a Tribunalului Districtual Tokyo Hachioji

Se poate presupune că acesta a subliniat că există restricții naturale asupra ceea ce ar trebui făcut ca suport pentru “operare” dacă principala sarcină asumată este “dezvoltarea” sistemului. În această hotărâre, există câteva puncte caracteristice, cum ar fi citarea vocea utilizatorilor care solicită suport în textul hotărârii, menționarea conținutului estimării preliminare și a existenței sau nu a unei clauze speciale pentru a oferi suport. În alte cuvinte, se poate presupune că intenția a fost de a fi relativ prudent în recunoașterea încălcării obligației, ținând cont de faptul că dacă conceptul de obligație de suport se extinde fără limită, acesta va impune o sarcină mare furnizorului.

Substanța obligației de suport ar trebui examinată împreună cu obligația de cooperare a utilizatorului

Până acum, discuția poate fi rezumată ca “în etapa inițială a operării în dezvoltarea sistemului, cum ar trebui să împartă sarcina de muncă între utilizator și furnizor”. Acest lucru include cu siguranță problema dificilă a cât de multă obligație legală ar trebui să aibă furnizorul la începerea operării din contractul de “dezvoltare”. În același timp, este inevitabil să spunem că există o tendință puternică de a solicita un verdict bazat pe circumstanțe individuale.

Cu toate acestea, se poate presupune că substanța obligației de suport pe care o are furnizorul devine mai sigură prin înțelegerea obligației de cooperare pe care o are utilizatorul.

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

În primul rând, efortul de a îmbunătăți operațiunile cu un nou sistem are aspectul unei munci comune între furnizor, care este un expert în tehnologie, și utilizator, care are cunoștințe despre operațiunile interne. Prin urmare, se poate presupune că în multe cazuri, domeniul acestuia va fi determinat în mod natural prin clarificarea problemele care ar trebui rezolvate prin efortul propriu ca parte a “îndeplinirii obligației de cooperare” a utilizatorului cu privire la ceea ce se numește obligația de suport.

Rezumat

În acest articol, am organizat informații despre ‘obligația de suport’, care poate fi considerată o derivată a managementului de proiect, pe baza cunoștințelor de bază despre managementul de proiect. Deși există încă multe aspecte neclare în conceptul de ‘obligație de suport’, se consideră că elementele fundamentale, cum ar fi ‘obligația de management de proiect’ și ‘obligația de cooperare’, sunt importante pentru înțelegerea acestuia.