Ce înseamnă obiectivele de management și obiectivele numerice în proiectele de dezvoltare a sistemelor din punct de vedere juridic?

Proiectele de dezvoltare a sistemelor sunt adesea strâns legate de îmbunătățirile majore ale operațiunilor în companii și locuri de muncă. În acest context, se poate solicita o atitudine de contribuție la rezolvarea problemelor de management ale companiei utilizatorului sau la atingerea obiectivelor numerice. Cu toate acestea, este oare o obligație legală să ne angajăm în aceste obiective de management? Problema devine ce înseamnă legal obiectivele numerice și de management. În acest articol, vom discuta problemele legale asociate cu diferitele “scopuri” și “obiective” în dezvoltarea sistemelor.

De ce devin obiectivele și scopurile dezvoltării de sistem surse de conflict?

Este o problemă situată între obligația de cooperare a utilizatorului și discreția limitată a furnizorului

Privind din perspectiva tranzacțiilor comerciale, proiectele de dezvoltare a sistemelor au câteva caracteristici distinctive. Una dintre ele este faptul că dezvoltarea sistemelor de către furnizor nu este ceva ce poate fi realizat doar de furnizor, ci necesită cooperarea din partea utilizatorului. Existenta acestei obligații este clară în jurisprudență, sub numele de “obligația de cooperare”. În principal, utilizatorul este solicitat să coopereze în dezvoltarea sistemului în faze precum ①definirea cerințelor ②proiectarea de bază ③acceptarea produselor finite.

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

Un alt aspect este că, de obicei, se așteaptă ca furnizorul să exercite o mare discreție în îndeplinirea sarcinilor sale. Există un termen juridic care cuprinde ceea ce furnizorul ar trebui să facă în cadrul unui proiect de dezvoltare a sistemului, numit “obligația de management al proiectului”. Acest lucru este explicat în detaliu în articolul de mai jos.

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

Rezumând conținutul de mai sus, putem sublinia două puncte importante:

• Utilizatorul este solicitat în practică să furnizeze informații necesare furnizorului și să coopereze cu activitatea de dezvoltare a acestuia.
• Furnizorul este solicitat în practică să înțeleagă scopul și obiectivele proiectului pentru utilizator și să întreprindă acțiuni care să se alinieze cu acestea.

Datorită acestor două puncte, devine o problemă până unde obligațiile furnizorului pot ajunge în ceea ce privește realizarea obiectivelor de management și a obiectivelor numerice prezentate în prealabil de către utilizator. Adică, pe de o parte, există aspectul că este obligația utilizatorului să rezume ceea ce furnizorul ar trebui să facă (nu ceva vag ca obiectivele) în specificații și să le prezinte. Pe de altă parte, există și aspectul că furnizorul are obligația, ca expert, să furnizeze ceea ce utilizatorul solicită în esență (nu doar să facă ceea ce i s-a spus). Acest conflict între cele două părți cu puncte de vedere opuse este o caracteristică a conflictelor legate de “obiectivele” și “scopurile” dezvoltării sistemelor. Din perspectiva legii, o problemă practică este să se ofere orientări pentru rezolvarea conflictelor într-un mod echitabil pentru ambele părți.

Scenarii concrete în care obiectivele utilizatorului influențează proiectul

Proiectele de dezvoltare a sistemelor sunt adesea legate de măsuri de îmbunătățire și eficientizare a operațiunilor la scară largă în companii și locuri de muncă, și adesea se realizează audieri privind problemele de management și obiectivele de management chiar și în etapa de planificare și propunere. Aici, se poate presupune că vor avea loc discuții despre costul eficienței asociat cu dezvoltarea sistemului și diverse obiective numerice.

• Reducerea costurilor cu personalul datorită eficientizării
• Creșterea vânzărilor și a profiturilor
• Reducerea timpului de lucru

De exemplu, în cazul în care elementele de mai sus devin scopul final al proiectului, se poate presupune că furnizorul va explica în prealabil efectele investiției în dezvoltarea sistemului din poziția unui consultant și va realiza vânzări.

Exemple de cazuri judiciare în care obiectivele de management ale utilizatorilor au devenit o problemă

Însă, furnizorii sunt, în mod normal, experți în dezvoltarea de sisteme. Dacă toată responsabilitatea pentru obiectivele de management ale utilizatorilor cade asupra lor, acest lucru poate deveni o povară prea mare.

Cazul în care îmbunătățirea vitezei de lucru a fost stabilită ca obiectiv

În legătură cu acest caz, în documentul de planificare creat la începutul proiectului, care este citat mai jos, au fost menționate scopurile și obiectivele pentru inițierea proiectului de dezvoltare a sistemului. Cu toate acestea, după ce sistemul a fost finalizat și a început să fie utilizat, nu a fost posibil să se atingă aceste scopuri și obiective, ceea ce a dus la un conflict. În documentul de planificare inițial, era menționat că se urmărește realizarea următoarelor stări după ce sistemul este finalizat și începe să fie utilizat:

• Reducerea timpului de introducere manuală cu 50%
• Finalizarea procesării administrative cu ajutorul acestui sistem IT într-o perioadă prestabilită

Utilizatorii, neputând realiza aceste obiective, au încercat să urmărească răspunderea pentru neexecutarea obligațiilor și răspunderea pentru garanția defectelor față de furnizor. Cu toate acestea, instanța nu a acceptat aceste argumente (sublinierile și textul îngroșat au fost adăugate de autor).

Și, (omis) conform întregii esențe a argumentelor, ① scopul acestui caz este “îmbunătățirea eficienței muncii”, “construirea unei baze pentru CRM”, “implementarea unei gestionări vizibile”, etc., care sunt abstracte, iar valorile țintă sunt “creșterea punctelor de contact cu clienții”, “redistribuirea efortului de lucru al personalului administrativ către controlul intern și suportul de vânzări”, “realizarea unor previziuni de vânzări mai precise”, “limitarea reducerilor excesive de vânzări”, etc., care sunt în mare parte abstracte, iar “reducerea timpului de introducere cu 50%”, “reducerea timpului de estimare cu 50%”, “realizarea dezvăluirii legale în termenul legal”, etc., sunt valori țintă care depind de modul în care sunt gestionate și operate afacerile după implementarea SBO, și nu sunt de natura celor pe care o companie de dezvoltare de sisteme care sprijină implementarea software-ului de pachet, cum este reclamantul, le poate asuma, ② în procesul verbal al întâlnirii după începerea acestui proiect, nu există nicio mențiune că s-a discutat în mod concret despre realizarea scopului și a valorilor țintă, ③ în planul de proiect al acestui caz, sunt folosite expresii care nu pot fi considerate ca având natura unui contract, cum ar fi “pentru a deveni o companie listată”, etc., (omis) luând în considerare aceste circumstanțe, se poate considera că reclamantul a creat descrierea scopului acestui caz în planul de proiect al acestui caz pe baza explicațiilor pârâtului, pentru a evita eșecul acestui proiect, pentru a obține o înțelegere comună a scopului și a rezultatelor acestui proiect, și nu se poate considera că pârâtul a încredințat reclamantului dezvoltarea unui sistem pentru realizarea scopului acestui caz. (omis) Prin urmare, nu se poate considera că reclamantul a preluat dezvoltarea unui sistem pentru realizarea scopului acestui caz de la pârât, (omis) și nici argumentele privind răspunderea pentru neexecutarea obligațiilor și răspunderea pentru garanția defectelor nu au nicio bază.

Hotărârea Tribunalului din Tokyo, 28 decembrie 2010 (Heisei 22)

Înțelesul legal al obiectivelor de management și al obiectivelor numerice, așa cum se poate citi din cazurile judecătorești

După cum se menționează și în această hotărâre, dacă obiectivele dezvoltării de sistem sau obiectivele cantificate numeric pot fi atinse sau nu, depinde în mod normal de o varietate de factori, cum ar fi eforturile de management ale utilizatorilor care utilizează sistemul. Prin urmare, ar trebui să considerăm că pragul pentru a face vânzătorul responsabil este foarte înalt. În primul rând, dacă responsabilitatea vânzătorului pentru neexecutarea obligațiilor sau pentru garanția defectelor este recunoscută, aceasta înseamnă că atingerea “obiectivului” sau “țintei” a fost inclusă ca parte a conținutului contractului. Cu toate acestea, în acest caz, “obiectivul” sau “ținta” a primit o evaluare legală cum ar fi:

• Pentru lucrurile abstracte și vagi, este dificil să le considerăm ca făcând parte din conținutul contractului, deoarece nu se potrivesc cu natura obligațiilor legale
• Pentru lucrurile care necesită eforturi de auto-ajutorare, în special din partea managementului utilizatorului, este inadecvat să se atribuie vânzătorului, deoarece acestea sunt în afara controlului vânzătorului, și este dificil să le considerăm ca făcând parte din obligațiile contractuale

Așa cum s-a menționat mai sus, a primit o evaluare legală.

Ce se poate deduce în plus din această hotărâre

Această hotărâre include și alte câteva aspecte interesante.

• Curtea a luat în considerare faptul că împărtășirea “scopului” și “obiectivelor” unui proiect de dezvoltare a sistemului poate fi doar o parte a eforturilor de comunicare pentru a obține o “înțelegere comună” între utilizator și furnizor.
• În cadrul unui șir de proiecte, curtea a luat în considerare cât de esențiale au fost aceste “scopuri” și “obiective”, referindu-se la procesele verbale ale ședințelor.

De asemenea, în ceea ce privește problemele legale asociate cu proiectele de dezvoltare a sistemelor, din perspectiva importanței gestionării documentelor și a proceselor verbale, explicăm în articolul de mai jos.

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

Aspecte legale privind obiectivele de management și țintele numerice

Totuși, în ceea ce privește problemele legale legate de aceste “scopuri” și “obiective”, ar trebui să luăm în considerare și următoarele aspecte suplimentare.

Consultanța poate fi plătită sau gratuită, iar acest lucru poate schimba situația

Dacă, pe lângă proiectul de dezvoltare a sistemului, ați încheiat și un contract de consultanță plătită, situația s-ar putea schimba semnificativ. Dacă există circumstanțe precum stabilirea unui plan de implementare cu posibilități reduse de realizare, fără a lua în considerare resursele de management de care dispune partea utilizatorului, este posibil să fie urmărită răspunderea pentru neexecutarea obligațiilor în cadrul contractului de consultanță plătită.

Defectele produsului final, neconformitățile funcționale și cerințele de specificații sunt probleme separate

De asemenea, dacă există defecte în proiectul de “dezvoltare” în sine, adică dacă sunt identificate probleme sau bug-uri în produsul final, acestea trebuie înțelese separat de problemele menționate mai sus. În acest caz, discuția despre “scopuri” și “obiective” de management nu este necesară, ci mai degrabă conformitatea dintre produsul final și cerințele funcționale și de specificații este problema. De exemplu, măsurile pe care partea utilizatorului le poate lua în cazul în care se descoperă defecte în sistem după fapt sunt explicate în articolul de mai jos.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Alte subiecte conexe includ situații în care, deși nu sunt incluse în cerințe, se recunoaște că partea furnizorului are obligația de a implementa la discreția sa. Acest lucru este explicat în detaliu în articolul de mai jos.

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

În oricare dintre cazuri, acestea ar trebui înțelese ca fiind diferite, dar similare cu disputele legate de “scopuri” și “obiective”.

Se cere o înțelegere fundamentală a temelor precum responsabilitatea și contractul

Așa cum am explicat mai sus, am discutat problemele legale legate de “scopul” și “obiectivul” dezvoltării de sisteme. În conflictele legate de aceste aspecte, se consideră că instanțele de judecată înțeleg pe deplin că, în eforturile de a alinia utilizatorii și furnizorii, comunicarea este adesea împărtășită ca parte a eforturilor. Cu toate acestea, chiar dacă se poate înțelege pe deplin validitatea concluziei în sine prin intermediul simțului practic al practicienilor, în procesul care duce la aceasta, se cere o înțelegere fundamentală a lucrurilor precum “responsabilitatea” și “contractul”. Explicăm aceste puncte în articolul de mai jos.

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

Este important să obținem o înțelegere mai esențială, ținând cont de faptul că responsabilitatea legală este diferită de responsabilitatea morală vagă și că “consensul clar” între ambele părți este ceea ce generează responsabilitatea contractuală.