Problemele juridice asociate cu tranziția de la vechiul sistem în dezvoltarea de sisteme

Crearea unui nou sistem IT utilizat în companii este un domeniu reprezentativ pentru inginerii IT, dar când vorbim despre “crearea unui nou sistem”, adesea acest proces include și “eliminarea sistemului folosit până acum”. În acest articol, vom aborda proiectul de dezvoltare a unui nou sistem din perspectiva “eliminării vechiului sistem” și vom discuta problemele legale asociate cu acesta.

Ce înseamnă tranziția către un sistem nou

Durata de viață a unui sistem IT nu este eternă

Sistemele IT utilizate în companii nu sunt ceva ce, odată creat, poate fi folosit în mod continuu pentru totdeauna. De asemenea, nu este întotdeauna benefic să folosim în mod constant ceva vechi. Deși există variații în funcție de fiecare companie și de scopul sistemului, ca o regulă generală, există o tendință ca decizia de management să fie de a înlocui un sistem cu unul nou după aproximativ 10 ani de utilizare.

În decursul a 10 ani, performanța computerelor disponibile pe piață se schimbă semnificativ. De exemplu, un program care nu era practic de implementat din cauza restricțiilor de viteză de procesare a computerului acum 10 ani (deși este un design simplu și excelent din punct de vedere uman) ar putea fi acum posibil de implementat. În plus, dacă ați continuat să utilizați un sistem timp de 10 ani de la crearea sa, fluxul de lucru al afacerii companiei și regulile interne ar putea fi schimbate semnificativ în acest timp. Codul implementat ulterior pentru a răspunde la aceste schimbări în mediul de afaceri intern și extern al companiei poate avea o structură complexă și încâlcită care nu poate fi recunoscută de pe ecran. În acest caz, chiar dacă utilizatorii doresc funcții suplimentare, situația poate ajunge la un punct în care este imposibil pentru dezvoltatori să adauge implementări suplimentare.

Sistemele vechi pot genera treptat mai multe “operațiuni manuale” (de exemplu, emiterea de interogări pentru extragerea datelor individuale) pentru inginerii IT. Ironia este că sistemul însuși, pe măsură ce îmbătrânește, începe să “personalizeze” operațiunile. Când încercăm să implementăm măsuri suplimentare de “sistemare” pentru operațiunile legate de sistem care au devenit prea personalizate din cauza îmbătrânirii, se va lansa un proiect pentru “dezvoltarea unui nou sistem pentru a face tranziția de la sistemul vechi”.

Dezvoltarea noului sistem avansează odată cu eliminarea sistemului vechi

După cum am menționat anterior, chiar dacă nu toate proiectele de dezvoltare a sistemelor sunt așa, multe proiecte de dezvoltare a unui sistem implică în același timp aspectul de tranziție de la sistemul vechi. Sistemul în sine se poate schimba adesea discontinuu de la o zi la alta.

Însă progresul zilnic al activităților trebuie să fie continuu, de la trecut la prezent și de la prezent la viitor. Păstrând datele necesare din trecut, fără a împiedica progresul activităților curente și propunând concepte superioare de “sistemizare” pentru viitor, tranziția către noul sistem adesea implică diverse provocări. Datorită combinației acestor circumstanțe, dezvoltarea noului sistem și operațiunile și întreținerea sistemului existent sunt strâns legate și devin inseparabile în anumite cazuri.

Ce înseamnă etapele de tranziție către un nou sistem

În procesul de tranziție de la sistemul existent la unul nou, este deosebit de important să se realizeze o migrare adecvată a datelor. Pașii pentru migrarea datelor urmează în general următoarea procedură.

1. Clarificați care dintre datele stocate de sistemul vechi ar trebui să fie migrate către noul sistem → Trebuie să se determine care date ar trebui să fie ușor de căutat din ecranul noului sistem, precum și care date ar trebui să fie disponibile pentru extragere, chiar dacă nu sunt necesare pentru căutare (de exemplu, în cazul unui audit).
2. Exportați datele identificate în pasul 1, care ar trebui să fie importate în noul sistem, într-un format precum un fișier CSV.
3. Importați datele extrase în pasul 2 în noul sistem.
4. Verificați dacă datele importate în pasul 3 sunt reflectate în noul sistem și confirmați dacă migrarea a fost realizată corect. → Rezultatele verificării dacă migrarea a fost realizată corect sunt de obicei păstrate ca documente de evidență prin afișarea pe ecran sau prin imprimarea rapoartelor (așa-numitul proces de testare).

Tranziția către un nou sistem este dificilă în ceea ce privește clarificarea rolurilor utilizatorilor și furnizorilor

În etapele de migrare a datelor menționate anterior, o problemă frecventă este cât de mult ar trebui ca partea utilizatorului să trateze aceasta ca o problemă internă și să o gestioneze. De asemenea, pentru o prezentare generală a “obligației de cooperare a utilizatorului” în proiectele de dezvoltare a sistemelor în general, nu doar în cazul migrării datelor, vă rugăm să consultați articolul de mai jos.

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

În general, în proiectele de dezvoltare a sistemelor, este adevărat că furnizorii adesea au un avantaj asupra utilizatorilor în ceea ce privește cunoștințele specializate necesare pentru dezvoltarea sistemelor (sau, mai degrabă, acesta este adesea motivul pentru care li se încredințează această sarcină). Cu toate acestea, pe de altă parte, adesea numai partea utilizatorului poate discuta despre “forma ideală” a propriului sistem.

Ținând cont de aceste aspecte, o posibilă clarificare a rolurilor ar fi ca utilizatorul să efectueze pașii 1 și 4 menționați anterior. Dacă am îndrăzni să o spunem în alt mod, în timpul întregii migrări a datelor, “definirea cerințelor” pentru datele care trebuie migrate și “acceptarea” dacă datele au fost migrate conform cerințelor ar putea fi considerate obligații de cooperare ale utilizatorului. Sau, ca o altă modalitate de a organiza, dacă există persoane cu cunoștințe ample despre sistemul vechi pe partea utilizatorului, ar putea fi posibil să se considere că și pasul 2 este responsabilitatea utilizatorului.

Dacă se poate gestiona problema sistemului vechi în cadrul companiei fără a recurge la externalizare, se poate dori să se externalizeze doar problema sistemului nou către furnizor. În acest fel, în lucrările de migrare a datelor, clarificarea rolurilor între utilizatori și furnizori poate deveni uneori ambiguă. De asemenea, atunci când utilizatorul externalizează lucrările legate de dezvoltarea sistemelor către furnizor, pentru o explicație generală a rolurilor așteptate de la furnizor și a obligațiilor legale care le revin, vă rugăm să consultați și articolul de mai jos.

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

Exemple de procese anterioare legate de tranziția la un nou sistem

Există cazuri reale în care, în cadrul proiectelor de dezvoltare a sistemelor care vizează tranziția la un nou sistem, au apărut probleme care au dus la procese. Cazul citat în decizia de mai jos implică eșecul operațiunilor de tranziție a datelor în timpul tranziției, generând incoerențe și bug-uri în datele din noul sistem și cauzând întârzieri în termenele de livrare. Diversele probleme care au apărut au dus la dispute cu privire la obligațiile pe care le aveau fiecare parte – furnizorul și utilizatorul – în cadrul proiectului. În final, s-a stabilit că furnizorul a încălcat obligațiile de precauție pe care ar fi trebuit să le îndeplinească, după cum urmează:

Defendantul, în cadrul serviciilor de tranziție a datelor bazate pe contractul de subcontractare, nu s-a limitat doar la a transfera datele de pe vechiul sistem la noul sistem, ci a avut obligația de a pune în funcțiune noul sistem cu datele transferate. Mai concret, înainte de a începe operațiunile de tranziție a datelor, a trebuit să cerceteze și să analizeze datele care urmau să fie transferate de pe vechiul sistem, să înțeleagă natura și starea acestora, să examineze dacă aceste date vor deveni un obstacol în funcționarea noului sistem după transfer, și dacă vor deveni un obstacol, să decidă când și cum vor fi corectate aceste date. În cele din urmă, a avut obligația de a pune în funcțiune noul sistem cu datele transferate de pe vechiul sistem.

Este corect să recunoaștem că, în acest caz, avea obligația de a corecta și elimina incoerențele datelor în timpul tranziției datelor.

Decizia Curții Districtuale Tokyo, 30 noiembrie 2016 (Heisei 28)

Acest caz implică o situație în care utilizatorul a preluat pașii 1 și 4, iar furnizorul a preluat pașii 2 și 3. Adică, furnizorul a preluat o dată extragerea datelor din vechiul sistem (pasul 2). Prin urmare, instanța a decis că, dacă furnizorul (ca specialist în dezvoltarea de sisteme) a preluat inclusiv extragerea datelor, ar fi trebuit să examineze în prealabil dacă operațiunea de extragere a datelor poate fi realizată fără probleme.

Totuși, ce s-ar fi întâmplat dacă, înainte de a împărți rolurile, utilizatorul ar fi preluat pasul 2 (adică extragerea datelor) și ar fi eșuat în această operațiune? În acest caz, este posibil ca utilizatorul să fie acuzat de încălcarea obligației de cooperare, deoarece a neglijat să cerceteze în prealabil dacă extragerea datelor poate fi realizată fără probleme, ceea ce a dus la întârzieri în termenele de livrare.

De asemenea, aceste decizii se bazează nu numai pe contract, ci și pe procesele verbale care corespund progresului dezvoltării sistemului. Importanța proceselor verbale este explicată în detaliu în articolul de mai jos.

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

Rezumat

Un proiect de dezvoltare a sistemului, cum ar fi cel pe care îl discutăm, implică o serie de obligații reciproce atât pentru utilizatori, cât și pentru furnizori, care trebuie să comunice în mod constant și meticulos. Prin urmare, chiar și în cazul precedentului juridic menționat anterior, o mică schimbare în condițiile de bază poate inversa cu ușurință responsabilitatea între utilizator și furnizor.

Având în vedere posibilitatea ca un sistem să conțină o cantitate enormă de date și mecanisme complexe, care nu pot fi imaginat doar din aspectul exterior al ecranului, și faptul că o mică diferență în premise poate schimba semnificativ direcția deciziei judiciare finale, putem spune că gestionarea riscurilor în proiectele de dezvoltare a noilor sisteme este importantă și ar trebui abordată în mod cuprinzător, împreună cu eliminarea sistemelor vechi.