Obiectul achiziției

Statut Suspendat

Valoarea estimată fără TVA 37 500 000 MDL

Perioada clarificărilor: 3 apr 2026, 16:44 - 26 apr 2026, 21:18

Perioada de depunere a ofertelor: 26 apr 2026, 21:18 - 17 mai 2026, 23:18

Începutul licitației: nu va fi folosită

Suport Tehnic pentru furnizori:

(+373) 79999801

Aceasta procedura se va desfășura fară licitație electronică. Oferta Dvs. este finală și trebuie să conțină toată lista de documente cerută de documentația de atribuire.

Servicii de elaborare şi implementare a unui nou sistem informaţional ,,Protecţia Socială” pentru anii 2026-2028
În conformitate cu Caietul de sarcini (Termeni de referință)

Informaţia despre solicitant

Denumirea

Casa Națională de Asigurări Sociale

Codul fiscal/IDNO

1004600030235

Adresa

2028, MOLDOVA, mun.Chişinău, locality, Gheorghe Tudor nr.3

Web site

---

Persoana de contact

Nume Prenume

Donici Serghei

Telefonul de contact

+37322257681

E-mail

serghei.donici@cnas.gov.md

Datele achizitiei

Data publicării

Data ultimilor modificări

17 apr 2026, 11:01

Valoarea estimată (fără TVA)

37 500 000 MDL

Achizitii.md ID

21593345

MTender ID

ocds-b3wdp1-MD-1775223422648

Tipul procedurii

Licitație deschisă

Criteriu de atribuire

Preţul cel mai scăzut

Adresa de livrare

2028, MOLDOVA, mun.Chişinău, mun.Chişinău, Conform cerințelor din Caietul de sarcini

Durata contractului

2 iun 2026 03:00 - 31 dec 2028 02:00

Lista pozițiilor

Denumirea

Servicii de elaborare şi implementare a unui nou sistem informaţional ,,Protecţia Socială” pentru anii 2026-2028 CPV: 72200000-7 - Servicii de programare şi de consultanţă software

Cantitatea: 1.0

Unități de măsură: Bucata

Documentele procedurii de achiziție

Caietul de sarcini 03.04.2026.semnat

Specificaţie tehnică

Caietul de Sarcini

3.04.26 16:44

DUAE dezvoltare SI Protecția Socială CNAS 2026

Specificaţie tehnică

DUAE în word

3.04.26 16:44

DUAE dezvoltare SI Protecția Socială CNAS 2026.semnat

Specificaţie tehnică

DUAE

3.04.26 16:44

Caietul de sarcini 03.04.2026

Specificaţie tehnică

Caietul de sarcini în word

3.04.26 16:44

ds_servicii_omf_115_15_09_2021 dezvoltare SI Protecția Socială CNAS 2026.semnat

Specificaţie tehnică

Documentația Standard

3.04.26 16:44

ds_servicii_omf_115_15_09_2021 dezvoltare SI Protecția Socială CNAS 2026

Specificaţie tehnică

Documentația Standard în Word

3.04.26 16:44

Anunt de participare dezvoltare SI Protecția Socială CNAS 2026 (2).semnat

Specificaţie tehnică

Anunț de participare

3.04.26 16:44

Caietul de sarcini 17.04.2026 modificat.semnat

Specificaţie tehnică

Caietul de sarcini modificat pe 17,04,2026

17.04.26 11:01

Istoria licitației

Vezi licitația

Obiectul achiziției

Data:

14 apr 2026, 12:20

Subiectul întrebării:

Metodologie solicitată

Întrebare:

Conform cerintei MG 002, SI „Protecția Socială” trebuie implementat în baza metodologiei iterative Waterfall. Rugăm să precizați care este metodologia solicitată, Watterfall, sau totuși o metodologie iterativă?

Răspuns (17 apr 2026, 08:21):

Se optează pentru o metodologie hibridă, care îmbină principiile modelului Waterfall cu elemente iterative. Astfel, etapele principale (analiză, proiectare, dezvoltare, testare și implementare) sunt parcurse secvențial, conform abordării Waterfall, însă în interiorul fiecărei etape sunt prevăzute iterații controlate pentru clarificarea cerințelor, ajustarea soluțiilor și validarea intermediară a livrabilelor. Această abordare permite menținerea unui cadru predictibil și documentat, specific Waterfall, concomitent cu flexibilitatea necesară adaptării la schimbări și îmbunătățirii continue pe parcursul dezvoltării.

Obiectul achiziției

Data:

14 apr 2026, 15:43

Subiectul întrebării:

Clarificare livrabile solicitate

Întrebare:

Cu referință la DEL 002. Ce ar reprezenta livrabilul ”Backlog-ul produsului” în contextul în care se solicită și Software Requirements Specification (SRS) și Software Design Document (SDD)?

Răspuns (17 apr 2026, 08:21):

Ţinînd cont de metodologia propusă backlogul ca livrabil, se exclude.

Obiectul achiziției

Data:

14 apr 2026, 16:57

Subiectul întrebării:

Cerințe ECHIPĂ

Întrebare:

Pentru rolul Busines Analyst este solicitata ”experiență în testarea modulară, integrarea continuă, DevOps”. Acesta este o cerință care aparține de regulă inginerilor de sistem sau dezvoltatorilor Senior. Din ce considerente ați inclus astfel de cerințe rolul de BA care nu scrie cod de testare și nici nu configurează servere in cadrul proiectului?

Răspuns (17 apr 2026, 08:22):

Cerința poate fi tratată ca un avantaj (nu e obligatoriu) pentru acest rol.

Obiectul achiziției

Data:

15 apr 2026, 15:19

Subiectul întrebării:

Cerințe echipă

Întrebare:

Ref. Tabelul 6.3. Cerințe pentru echipa de implementare a SI „Protecția Socială”. În cerințele față de UX/UI designer este menționat ”Empatie și conștientizare față de diversitatea nevoilor utilizatorilor” și ”UX/UI designerul trebuie să meargă dincolo de simpla execuție a sarcinilor – să gândească strategic”. Cum poate fi demonstrată în ofertă deținerea acestor abilități de către candidatul propus pentru a asigura conformitatea și cum vor fi măsurate aceste calități la evaluarea ofertelor?

Răspuns (17 apr 2026, 10:28):

Se verifică, cel puțin, dacă în procesul de testare au fost incluși utilizatori din grupuri diverse, dacă au fost identificate probleme reale de accesibilitate și de înțelegere, precum și dacă soluțiile au fost ajustate în urma testării.

Obiectul achiziției

Data:

15 apr 2026, 15:20

Subiectul întrebării:

Testarea de acceptanță

Întrebare:

Din UAT 002 nu este clar. Cine efectuează testarea de acceptanță, Furnizorul, sau Beneficiarul?

Răspuns (17 apr 2026, 10:29):

Furnizorul împreună cu Beneficiarul, inclusiv dacă o anumită etapă de testare va fi interdependentă de alţi furnizori de servicii sau mecanisme de integrare, beneficiarul (CNAS) poate solicita participarea acestora la aceste activităţi.

Obiectul achiziției

Data:

15 apr 2026, 22:25

Subiectul întrebării:

cerinte contradictorii

Întrebare:

COM 001 prin care se solicită ca Furnizorul să propună și justifice strategia optimă de punere în producție a SI „Protecția Socială” (exemplu: pe faze, big-bang, exploatare în paralel, lansare pilot). În COM 004 se specifică că SI „Protecția Socială” poate fi pus în producție dacă este disponibil și operațional pentru toți utilizatorii autorizați, iar Procesul verbal de acceptanță a SI „Protecția Socială” a fost semnat. Conform UAT 001 Înaintea demararea testelor de acceptanță, toate componentele SI „Protecția Socială” trebuie să fie implementate. Respectiv cerințele COM 004 si UAT 001 practic exclud scenarii de lansare etapizată solicitate ca mandatory în COM 001. Care este scopul cerinței COM 001 și nu ar constitui motiv de depunctare propunerea unei strategii de lansare etapizată în condițiile în care UAT 001 și COM 004 prevăd expres condițiile de acceptanță și punere în producție?

Răspuns (17 apr 2026, 10:30):

Propunerea unei strategii nu constituie motiv de depunctare, atâta timp cât aceasta demonstrează atingerea integrală a cerințelor funcționale înainte de UAT, asigură că, la momentul acceptanței, sistemul este complet operațional pentru toți utilizatorii, include măsuri clare de tranziție către starea finală conform COM 004.

Obiectul achiziției

Data:

17 apr 2026, 14:02

Subiectul întrebării:

Aviz Agentie Guvernare Electronica

Întrebare:

Având in vedere că în cazul achizițiilor din domeniul tehnologiei informației și comunicațiilor, pentru entitățile vizate de HG nr. 544/2019, planurile generale de achiziții TIC, modificările la acestea, iar potrivit Ghidului practic al AGE și documentația aferentă procedurii de achiziție, se supun coordonării/avizării de către Agenția de Guvernare Electronică, vă rugăm să prezentați Avizul AGE privind această achiziție.

Răspuns (21 apr 2026, 09:57):

În conformitate cu prevederile Hotărârii Guvernului nr. 544/2019, procedurile de achiziții în domeniul TIC sunt supuse coordonării cu Agenția de Guvernare Electronică, inclusiv prin emiterea avizelor corespunzătoare. Totodată, menționăm că legislația în domeniul achizițiilor publice stabilește în mod expres conținutul documentației de atribuire care urmează a fi pusă la dispoziția operatorilor economici, iar avizele de coordonare interinstituțională nu sunt incluse în această categorie de documente. Prin urmare, deși procedura a fost inițiată cu respectarea obligațiilor de coordonare prevăzute de cadrul normativ aplicabil, avizul emis de Agenția de Guvernare Electronică nu face parte din documentația de atribuire destinată publicării sau transmiterii către operatorii economici. Documentația publicată conține toate informațiile necesare pentru elaborarea ofertelor, în conformitate cu cerințele legale

Obiectul achiziției

Data:

17 apr 2026, 14:02

Subiectul întrebării:

Aviz Agentie Guvernare Electronica

Întrebare:

Răspuns (21 apr 2026, 09:58):

Obiectul achiziției

Data:

17 apr 2026, 14:37

Subiectul întrebării:

Solicitare de clarificări privind fundamentarea valorii estimate a contractului

Întrebare:

Stimați membri ai grupului de lucru, În vederea elaborării unei oferte conforme, competitive și realiste pentru procedura de achiziție menționată, vă solicităm respectuos să ne oferiți clarificări suplimentare cu privire la modul de determinare a valorii estimate a contractului, în sumă de 37.500.000,00 MDL (fără TVA). Având în vedere complexitatea ridicată a sistemului solicitat, considerăm necesară înțelegerea bazei de calcul care a stat la fundamentarea acestui buget. În acest sens, vă rugăm să ne comunicați: Dacă la baza stabilirii acestei valori a stat un studiu de fezabilitate, o analiză de piață sau un deviz estimativ pe categorii de activități (ex: analiză, proiectare, dezvoltare, testare, instruire, mentenanță în perioada de garanție). În măsura în care aceste documente sunt publice, vă rugăm să ne puneți la dispoziție o sinteză a acestora pentru a asigura o corelare optimă a Planului financiar solicitat în Documentația Standard cu așteptările și resursele autorității contractante. Această informație este esențială pentru a minimiza riscurile de execuție și pentru a asigura o trasabilitate financiară corectă a livrabilelor, așa cum este solicitat în secțiunea „Criterii de atribuire”. Vă mulțumim pentru colaborare.

Răspuns (23 apr 2026, 14:07):

Stimați operatori economici, Referitor la solicitarea privind fundamentarea valorii estimate a contractului, în sumă de 37.500.000,00 MDL (fără TVA), comunicăm următoarele: 1. Modul de determinare a valorii estimate Valoarea estimată a fost stabilită în conformitate cu prevederile legislației în domeniul achizițiilor publice, în baza: • analizei necesităților instituționale, raportate la obiectivele proiectului; • complexității funcționale și tehnice a sistemului informațional „Protecția Socială”, inclusiv integrarea cu multiple sisteme externe și cerințele de securitate, interoperabilitate și scalabilitate; • estimării volumului de activități aferente etapelor principale de implementare (analiză de business, proiectare, dezvoltare, testare, implementare, instruire și mentenanță). Totodată, structura Caietului de sarcini reflectă aceste categorii de activități și livrabile, inclusiv cerințele privind implementarea și suportul sistemului . 2. Cu privire la documentele justificative (studii, devize detaliate) Valoarea estimată nu este fundamentată pe un deviz rigid pe poziții prestabilite, ci pe o estimare agregată, specifică proiectelor IT complexe de tip „end-to-end”, unde: • detalierea completă a efortului urmează a fi realizată în etapa de analiză (Milestone 1); • soluția tehnică finală și modul de implementare sunt propuse de ofertanți. În acest sens: • documentele interne detaliate utilizate la estimare nu fac obiectul publicării; • însă, Caietul de sarcini oferă toate elementele necesare pentru elaborarea unei oferte financiare fundamentate. 3. Recomandări pentru ofertanți privind planificarea financiară Operatorii economici urmează să elaboreze oferta financiară: • în baza propriei metodologii de estimare; • ținând cont de toate cerințele funcționale și nefuncționale; • incluzând toate etapele proiectului, precum și riscurile asociate (inclusiv integrarea, mentenanța și suportul). 4. Concluzie Valoarea estimată are caracter orientativ și reflectă o estimare realistă a resurselor necesare şi planificate în planul strategic de dezvoltare a CNAS, fără a limita modul de structurare a ofertelor de către operatorii economici. Menționăm că, implementarea contractului este planificată multianual, pentru perioada 2026–2028, în funcție de mijloacele bugetare corespunzătoare fiecărui an

Obiectul achiziției

Data:

17 apr 2026, 15:14

Subiectul întrebării:

Metodologie solicitata

Întrebare:

Referitor la răspunsul din 17.04.2026 08:31 ”Se optează pentru o metodologie hibridă..”, va fi modificat caietul de sarcini? La moment este stipulat expres metodologie Waterfall (DEV 001, DEV 002 manadatory).

Răspuns (23 apr 2026, 14:08):

Referitor la întrebarea privind corelarea răspunsului anterior (metodologie hibridă) cu prevederile actuale ale Caietului de sarcini (DEV 001, DEV 002 – metodologie Waterfall), comunicăm următoarele: 1. Interpretarea cerințelor existente Prevederile din Caietul de sarcini care fac referire la metodologia Waterfall stabilesc un cadru general de structurare a etapelor proiectului (analiză, proiectare, dezvoltare, testare, implementare), necesar pentru asigurarea controlului, trasabilității și livrabilelor formale în cadrul unui proiect public de asemenea complexitate . 2. Aplicarea metodologiei hibride Răspunsul anterior privind abordarea hibridă are caracter de clarificare interpretativă, în sensul că: • este permisă utilizarea dferitor practici în cadrul etapelor definite; • aceste practici pot fi aplicate la nivel operațional (dezvoltare, livrare incrementală, feedback continuu); • cu respectarea structurii de livrabile și milestone-uri stabilite în documentație. 3. Modificarea documentației La această etapă: • nu se impune modificarea expresă a Caietului de sarcini; • prevederile existente se vor interpreta în sensul unei abordări flexibile (hibride), fără a afecta cerințele obligatorii privind livrabilele și etapele proiectului. 4. Concluzie • metodologia Waterfall rămâne cadrul formal de referință pentru managementul proiectului; • utilizarea unei metodologii hibride este permisă și încurajată la nivel de implementare; • nu sunt necesare modificări ale documentației, întrucât interpretarea oferită asigură coerența aplicării acesteia.

Obiectul achiziției

Data:

17 apr 2026, 15:19

Subiectul întrebării:

Referitor la ”Răspuns: 17.04.2026 08:31

Întrebare:

Referitor la ”Răspuns: 17.04.2026 08:31 Ţinînd cont de metodologia propusă backlogul ca livrabil, se exclude.” Urmează a fi modificat DEL 002?

Răspuns (23 apr 2026, 14:09):

Referitor la întrebarea privind necesitatea modificării livrabilului DEL 002, în contextul clarificării anterioare privind excluderea backlog-ului ca livrabil distinct, comunicăm următoarele: 1. Statutul backlog-ului În conformitate cu răspunsul anterior, backlog-ul nu este solicitat ca livrabil formal obligatoriu, întrucât metodologia de implementare are la bază un cadru structurat de livrabile și etape definite, specific proiectelor de tip guvernamental . 2. Interpretarea livrabilului DEL 002 DEL 002 va fi interpretat după cum urmează: • conținutul acestuia nu va include backlog-ul ca element obligatoriu distinct; • livrabilul va reflecta rezultatele analizei și specificațiilor funcționale, inclusiv cerințele detaliate, scenariile de utilizare și alte artefacte relevante pentru implementare; • ofertanții pot utiliza instrumente de tip backlog la nivel intern , însă fără obligația de a le livra formal. 3. Modificarea documentației La această etapă: Caietul de sarcini a fost modificat şi publicat la data de 17/04/2026 11:01.

Obiectul achiziției

Data:

17 apr 2026, 15:52

Subiectul întrebării:

Ref. răspuns - ”Cerința poate fi tratată ca un avantaj (nu e obligatoriu) pentru acest rol.”

Întrebare:

Referitor la răspunsul din 17.04.2026 08:31 ”Cerința poate fi tratată ca un avantaj (nu e obligatoriu) pentru acest rol.” Am verificat în documentația standard la descrierea principiilor de evaluare („îndeplinit / neîndeplinit (Da/Nu)”, conform cerințelor detaliate pentru fiecare poziție), pentru BA este listată cerința ”experiență în testarea modulară, integrarea continuă”. Prin urmare nu este o cerință opțională, dar una care contribuie direct la evaluare și este tratată echivalent cu celelalte calificări solicitate. Va fi exclusă din cerințe, sau indicată ca și opțională?

Răspuns (23 apr 2026, 14:10):

Răspuns: Referitor la solicitarea de clarificări privind statutul cerinței „experiență în testarea modulară, integrarea continuă” pentru poziția de Business Analyst (BA), comunicăm următoarele: În conformitate cu prevederile documentației de atribuire și cu structura generală a criteriilor de evaluare, cerințele stabilite pentru fiecare poziție reflectă nivelul minim de competență necesar pentru asigurarea implementării eficiente a proiectului. Totodată, în contextul specificului proiectului „Sistemul informațional Protecția Socială”, care presupune dezvoltare modulară, integrare cu multiple sisteme externe și respectarea principiilor de interoperabilitate și scalabilitate , anumite competențe tehnice, inclusiv cele aferente proceselor de testare și integrare continuă, sunt relevante la nivel de echipă, dar nu constituie în mod obligatoriu cerințe eliminatorii pentru toate rolurile individuale. Prin urmare, cerința „experiență în testarea modulară, integrarea continuă” pentru poziția de Business Analyst: • nu va fi tratată ca cerință obligatorie (eliminatorie); • va fi considerată cerință opțională/avantaj, care poate contribui la evaluarea calitativă a ofertei, fără a afecta calificarea acesteia în cazul neîndeplinirii. În consecință, cerința menționată urmează a fi interpretată și aplicată în procesul de evaluare ca element de valoare adăugată, și nu ca criteriu obligatoriu de conformitate (Da/Nu). Această abordare asigură respectarea principiului proporționalității și permite evaluarea echilibrată a ofertelor, în raport cu rolul și responsabilitățile specifice poziției vizate.

Obiectul achiziției

Data:

17 apr 2026, 16:24

Subiectul întrebării:

Riscuri legate de Migrarea Datelor

Întrebare:

Conform documentatiei tehnice sistemul actual datează din 2007. Migrarea către o arhitectură nouă fără o descriere a volumului și calității datelor actuale este un risc major de blocaj. Solicitare clarificare: Caietul de sarcini menționează că migrarea și popularea datelor sunt în responsabilitatea Furnizorului (Milestone 4), dar CNAS va „pregăti și livra” datele. Vă rugăm să precizați: - Care este volumul total al datelor (în TB sau număr de înregistrări) care urmează a fi migrate? - În ce formate și structuri (SGBD actual) vor fi puse la dispoziție datele de către CNAS? - Există un audit de calitate a datelor actuale? Cine poartă răspunderea pentru întârzierile cauzate de necesitatea „curățării” unor date incoerente din sistemul vechi (2007)?

Răspuns (24 apr 2026, 21:06):

Referitor la aspectele ce țin de migrarea și calitatea datelor, comunicăm următoarele: 1. Cu privire la volumul datelor ce urmează a fi migrate La această etapă, nu este stabilit un volum exact (în TB sau număr de înregistrări) care poate fi comunicat ca valoare fixă, întrucât Sistemul actual datat din 2007 este bazat pe Oracle.: Ofertanții urmează să ia în considerare la etapa formării ofertei un volum de circa 3TB de date istorice, specific unui sistem operațional utilizat pe termen lung. 2. Cu privire la formatele și structura datelor Datele vor fi puse la dispoziția Furnizorului: • din sistemele informaționale existente ale CNAS; • în formate și structuri disponibile la momentul respectiv • Detalierea exactă a formatelor, structurilor și mecanismelor de transfer va fi realizată în etapa de analiză, cu implicarea ambelor părți. 3. Cu privire la auditul și calitatea datelor Nu există, la această etapă, un audit exhaustiv formalizat al calității datelor pentru toate registrele. 4. Cu privire la responsabilități și riscuri Responsabilitățile sunt delimitate după cum urmează: • CNAS: asigură accesul la datele existente, furnizarea acestora și suportul informațional necesar; • Furnizorul: este responsabil de procesul de migrare (analiză, transformare, încărcare, validare tehnică). În ceea ce privește întârzierile: • eventualele dificultăți generate de calitatea datelor istorice vor fi gestionate în mod colaborativ; • impactul asupra termenelor va fi analizat și tratat în conformitate cu mecanismele contractuale (managementul schimbărilor, riscurilor și dependențelor). 5. Concluzie Migrarea datelor reprezintă o componentă complexă a proiectului, care va fi detaliată în etapa de analiză, iar ofertanții trebuie să prevadă în ofertă resursele și expertiza necesare pentru gestionarea acestui proces.

Obiectul achiziției

Data:

17 apr 2026, 16:28

Subiectul întrebării:

Ambiguitatea Domeniului de Aplicare

Întrebare:

Conform caietului de sarcini multe funcționalități urmează a fi definite abia după „analiza de business” din Milestone 1. Acest lucru face imposibilă o estimare fixă corectă. Solicitare clarificare: Referitor la cerința CF 19.07, care menționează „până la 150 de rapoarte”: - Există o listă preliminară a acestora pentru a evalua complexitatea lor (rapoarte simple vs. tablouri de bord BI complexe)? - Cerința PIR 018 impune includerea a 50 om/zile pentru dezvoltări neplanificate în perioada de garanție. Cum va fi cuantificat acest efort și ce se întâmplă dacă necesitățile depășesc acest prag? Deoarece arhitectura trebuie să fie „greenfield, în ce măsură Furnizorul va avea acces la codul sursă al sistemului actual pentru a înțelege regulile de business care nu sunt documentate în actualul Caiet de Sarcini?

Răspuns (24 apr 2026, 21:12):

Referitor la aspectele invocate, în baza prevederilor Caietului de sarcini și a cadrului general de implementare a proiectului, comunicăm următoarele: 1. Cu privire la cerința CF 19.07 („până la 150 de rapoarte”) În cadrul Caietului de sarcini este inclusă o listă preliminară de rapoarte (Anexa nr. 6), care are caracter orientativ și reflectă necesitățile de bază ale instituției . Totodată: • lista nu este exhaustivă, aceasta urmând a fi detaliată și ajustată în etapa de analiză de business (Milestone 1); • complexitatea rapoartelor poate varia (rapoarte operaționale, statistice, analitice), inclusiv posibilitatea dezvoltării de rapoarte configurabile și tablouri de bord; • ofertantul urmează să țină cont de un mix rezonabil de complexitate, specific sistemelor informaționale de nivel guvernamental, cu accent pe flexibilitate și reutilizare. Se menționează că implementarea noului sistem este planificată pe o durată estimativă de până la 3 ani, perioadă în care sistemul informațional existent va continua să fie dezvoltat și utilizat, ceea ce poate influența evoluția necesităților de raportare. 2. Cu privire la cerința PIR 018 (50 om/zile pentru dezvoltări neplanificate în perioada de garanție) Cerința respectivă reprezintă un volum estimativ minim de efort inclus în ofertă, destinat acoperirii necesităților neprevăzute apărute în perioada de garanție. Aplicarea acesteia se va realiza după cum urmează: • efortul va fi gestionat și validat de autoritatea contractantă, în baza solicitărilor concrete și a priorităților stabilite; • activitățile vor fi acceptate și monitorizate în baza livrabilelor și rapoartelor de activitate; • în cazul în care necesitățile depășesc pragul de 50 om/zile, acestea vor fi tratate separat, în baza unor mecanisme contractuale ulterioare (ex.: servicii suplimentare, acte adiționale), în conformitate cu legislația privind achizițiile publice. 3. Cu privire la accesul la codul sursă al sistemului existent (abordare „greenfield”) Proiectul este definit ca unul de tip „greenfield”, ceea ce presupune dezvoltarea unei soluții noi, independente de sistemul existent, conform cerințelor funcționale și nefuncționale stabilite. În acest context: • Caietul de sarcini conține descrierea proceselor, fluxurilor și cerințelor necesare implementării sistemului; • detalierea regulilor de business va fi realizată în cadrul etapei de analiză de business (Milestone 1), cu implicarea activă a autorității contractante; • accesul la codul sursă al sistemului existent nu este garantat ca parte a livrabilelor inițiale, însă, după caz, pot fi oferite informații suplimentare (documentații, explicații funcționale) necesare înțelegerii proceselor existente, în limitele disponibile și permise.

Obiectul achiziției

Data:

17 apr 2026, 16:30

Subiectul întrebării:

Garanție și Post-Implementare

Întrebare:

Conform caietului de sarcini mentenanța este inclusă în preț, dar include și actualizarea documentației și remedierea oricăror deficiențe. Solicitare clarificare: Cerința PIR 022 obligă Furnizorul să aplice noi versiuni ale aplicațiilor „cel puțin lunar”. Sunt aceste versiuni limitate la bug-fixing sau includ și actualizări legislative (având în vedere dinamica legislativă a CNAS)? Dacă pe parcursul perioadei de mentenanță apar modificări legislative majore, acestea vor fi acoperite din cele 50 om/zile (PIR 018) sau vor face obiectul unor contracte separate?

Răspuns (24 apr 2026, 21:18):

Referitor la cerințele privind mentenanța și actualizările periodice, comunicăm următoarele: Cerința PIR 022 privind aplicarea versiunilor lunar, vizează, în principal: remedieri de erori, îmbunătățiri minore şi actualizări tehnice necesare asigurării funcționării optime a sistemului. Aceste versiuni pot include și ajustări determinate de modificări legislative, în măsura în care acestea sunt de complexitate redusă (de ex. modificarea coeficientului indexării anuale stabilite prin hotărârea de guvern) și nu implică modificări semnificative ale arhitecturii, funcționalităților sau fluxurilor sistemului. Modificările legislative majore, care presupun dezvoltări substanțiale, extinderi de funcționalitate sau reconfigurări semnificative ale sistemului, nu sunt incluse în activitățile curente de mentenanță. Acestea vor fi tratate distinct și pot face obiectul unor documentări separate, după caz. Prezenta clarificare are caracter explicativ și nu modifică documentația de atribuire.

Obiectul achiziției

Data:

17 apr 2026, 16:30

Subiectul întrebării:

Garanție și Post-Implementare

Întrebare:

Răspuns (24 apr 2026, 21:18):

Obiectul achiziției

Data:

17 apr 2026, 16:32

Subiectul întrebării:

Interoperabilitate și Dependențe Externe

Întrebare:

Conform caietului de sarcini sistemul depinde de integrarea cu 13+ sisteme externe și servicii guvernamentale. Orice indisponibilitate a acestora afectează performanța noului SI. Solicitare clarificare: Cerința PSR 010 impune timpi de răspuns sub 1-3 secunde. Acești timpi includ și latența răspunsurilor primite de la sistemele externe (ex: ASP, SFS)? Cine asigură suportul tehnic pentru API-urile sistemelor externe în cazul în care specificațiile acestora se schimbă pe parcursul implementării (2026-2028)?

Răspuns (23 apr 2026, 14:13):

În contextul dependențelor de interoperabilitate cu sisteme externe și servicii guvernamentale, comunicăm următoarele: 1. Cu privire la cerința PSR 010 (timpi de răspuns 1–3 secunde) Timpii de răspuns prevăzuți în cerința PSR 010 se referă la performanța sistemului informațional dezvoltat (SI „Protecția Socială”), în condiții normale de operare. Astfel: • acești timpi nu includ latența generată de sistemele externe (ex.: ASP, SFS, alte sisteme integrate), asupra cărora autoritatea contractantă și furnizorul nu au control direct; • ofertantul va asigura optimizarea performanței pentru componentele proprii ale sistemului (ex.: procesare internă, baze de date, mecanisme de cache, gestionarea apelurilor asincrone); • pentru interacțiunea cu sisteme externe, se vor aplica bune practici de integrare (ex.: timeouts, retry, queueing), în vederea minimizării impactului asupra experienței utilizatorului. Această abordare este în concordanță cu principiile de interoperabilitate și arhitectură distribuită prevăzute pentru sistem . 2. Cu privire la suportul tehnic pentru API-urile sistemelor externe Suportul tehnic pentru API-urile sistemelor externe este asigurat după cum urmează: • deținătorii sistemelor externe (ex.: ASP, SFS, AGE etc.) sunt responsabili de mentenanța, actualizarea și publicarea specificațiilor API aferente; • autoritatea contractantă va facilita, după caz, coordonarea instituțională și accesul la documentațiile necesare; • furnizorul va avea responsabilitatea de a adapta și menține integrările realizate, în conformitate cu modificările comunicate oficial de către deținătorii sistemelor externe, pe durata implementării și conform prevederilor contractuale.

Obiectul achiziției

Data:

17 apr 2026, 16:58

Subiectul întrebării:

Cerințe față de ofertanți

Întrebare:

În scopul pregătirii unei oferte conforme și pentru a asigura un tratament egal tuturor operatorilor economici, vă solicităm clarificări cu privire la cerința 5.4 „Cerințe față de ofertanți”: 1. Perioada de referință: Vă rugăm să precizați care este perioada corectă pentru demonstrarea experienței similare. Secțiunea 5.4 indică 5 ani , în timp ce Anexa nr. 2 menționează 15 ani 2. Care dintre aceste perioade va fi utilizată ca bază pentru stabilirea eligibilității (punctul 9 din Anunțul de participare)? 3. Definiția „proiectului similar”: Vă rugăm să confirmați dacă prin „proiecte de complexitate similară” se înțelege doar similitudinea funcțională și tehnică (ex: management de registre, interoperabilitate MConnect) sau dacă există o valoare financiară minimă per proiect sub care acesta nu va fi luat în considerare.

Răspuns (23 apr 2026, 15:54):

În vederea asigurării unui tratament egal al operatorilor economici și a unei interpretări unitare a cerințelor din documentația de atribuire, se comunică următoarele: 1. Perioada de referință pentru experiența similară Pentru îndeplinirea cerințelor de calificare, perioada de referință aplicabilă este de 5 ani, conform prevederilor secțiunii 5.4 din Caietul de sarcini. Mențiunea din Anexa nr. 2 privind perioada de 15 ani se interpretează în contextul evaluării tehnice, în cadrul criteriului „cel mai bun raport calitate-preț”. 2. Stabilirea eligibilității Pentru a fi considerat eligibil, ofertantul trebuie să demonstreze experiență similară realizată în ultimii 5 ani. Perioada de referinţă până la 15 ani nu constituie o condiție obligatorie de calificare, însă poate fi valorificată în etapa de evaluare, contribuind la obținerea unui punctaj. 3. Aplicarea cerinței privind numărul de proiecte • minimum 2 proiecte similare – condiție minimă de calificare; • pentru evaluare, pot fi luate în considerare proiecte realizate în ultimii 15 ani, în funcție de relevanța acestora. Definiția „proiectului similar” Prin „proiecte de complexitate similară” se înțeleg proiecte comparabile din punct de vedere: • funcțional (ex.: sisteme de gestiune a registrelor, fluxuri operaționale complexe); • tehnic (ex.: arhitecturi moderne, interoperabilitate cu alte sisteme – inclusiv platforme guvernamentale precum MConnect, MPass, MSign); • operațional (volum de date, număr de utilizatori, integrare cu sisteme externe, inclusiv costul proiectului propus de autoritatea contractantă ).

Obiectul achiziției

Data:

17 apr 2026, 17:06

Subiectul întrebării:

Contradicția privind Criteriul de Atribuire

Întrebare:

În Anunțul de participare, apar două mențiuni succesive care se bat în cap: 1) Punctul 24: Specifică drept criteriu de evaluare: „Cel mai mic preț fără TVA pentru întreaga ofertă”. 2) Punctul 25: Specifică imediat după: „Cel mai bun raport calitate-preț”, unde prețul are o pondere de doar 40%, restul de 60% fiind factori tehnici. Impact: Aceasta este o eroare fundamentală. Operatorul economic nu știe dacă să pregătească o ofertă bazată pe optimizarea costurilor (pentru prețul cel mai mic) sau una bazată pe excelență tehnică (pentru raport calitate-preț).

Răspuns (23 apr 2026, 14:14):

Referitor la neconcordanțele identificate în Anunțul de participare, comunicăm următoarele: Se confirmă existența unei inadvertențe de redactare între punctele 24 și 25, care poate genera interpretări diferite privind criteriul de atribuire. În acest context, se precizează că criteriul corect de evaluare aplicabil procedurii este „cel mai bun raport calitate-preț”, după cum urmează: • componenta financiară (prețul) – 40%; • componenta tehnică (calitatea ofertei) – 60%. Totodată, pentru asigurarea clarității și transparenței procedurii, vor fi operate modificări corespunzătoare în documentația de atribuire, inclusiv în Anunțul de participare. În consecință, operatorii economici vor elabora și prezenta ofertele în baza criteriului „cel mai bun raport calitate-preț”, conform ponderilor indicate.

Obiectul achiziției

Data:

17 apr 2026, 17:09

Subiectul întrebării:

Experienta similara

Întrebare:

Numărul minim de proiecte solicitate: 1) Minim 2 proiecte: Caietul de Sarcini (Secțiunea 5.4) și descrierea generală a factorului de evaluare din Anexa 2 menționează necesitatea a cel puțin două proiecte TIC de complexitate similară. 2) Minim 3 proiecte: În tabelul de punctaj din Anexa 2, prima linie de evaluare impune un prag de minim 3 proiecte pentru a fi considerat conform cerinței de experiență similară. Impact: Această discrepanță creează o barieră de intrare ambiguă. Nu este clar dacă 2 proiecte sunt suficiente pentru calificare sau dacă al treilea este obligatoriu pentru a trece pragul minim de evaluare.

Răspuns (23 apr 2026, 14:15):

Referitor la neconcordanțele semnalate privind numărul minim de proiecte similare, comunicăm următoarele: Mențiunea privind minimum 3 proiecte reprezintă o greșeală mecanică, care va fi corectată prin modificarea documentației de atribuire. În acest sens, se precizează: 1. Condiția minimă de eligibilitate Pentru a fi considerat eligibil, ofertantul trebuie să demonstreze implementarea a minimum 2 proiecte TIC de complexitate similară, conform secțiunii 5.4 din Caietul de sarcini. Aceasta constituie cerința minimă obligatorie de calificare. 2. Criteriul de evaluare (punctaj) Prezentarea unui număr mai mare de proiecte similare: • nu este obligatorie pentru calificare; • constituie însă un avantaj competitiv, care poate conduce la acordarea unui punctaj suplimentar în cadrul evaluării tehnice, în funcție de relevanța și complexitatea acestora. 3. Clarificare finală • prezentarea a 2 proiecte este suficientă pentru îndeplinirea cerinței minime; • prezentarea a 3 sau mai multe proiecte contribuie la îmbunătățirea scorului tehnic, fără a condiționa admiterea ofertei. Totodată, pentru eliminarea ambiguităților, documentația de atribuire va fi ajustată corespunzător, iar forma actualizată va fi publicată în SIA RSAP.

Obiectul achiziției

Data:

17 apr 2026, 17:29

Subiectul întrebării:

Perioada de referință pentru experiența similară

Întrebare:

Ref: Solicitare de clarificare privind perioada de referință pentru experiența similară (Contradicție între Sect. 5.4 și Anexa nr. 2) În urma analizei documentației de atribuire, am identificat o discrepanță majoră privind perioada de referință pentru demonstrarea experienței similare, care poate afecta calitatea implementării noului SI „Protecția Socială”: 1) Secțiunea 5.4 din Caietul de Sarcini solicită corect demonstrarea experienței pentru proiecte implementate în ultimii 5 ani 2) Anexa nr. 2 la Documentația Standard (Criterii de atribuire) extinde această perioadă la 15 ani Având în vedere că acest proiect impune o „abordare de tip greenfield”, utilizarea unor tehnologii moderne precum Kubernetes, procese de integrare și livrare continuă (CI/CD) și interoperabilitate avansată prin platformele guvernamentale actuale (MConnect, MSign, MPass), considerăm că experiența dobândită acum 10-15 ani nu mai are relevanță tehnică pentru complexitatea solicitată astăzi. În acest sens, vă solicităm: Să clarificați dacă pragul de calificare este cel de 5 ani (conform Sect. 5.4), acesta fiind singurul care garantează că ofertantul deține expertiză actualizată în stivele tehnologice moderne solicitate. Să ajustați Anexa nr. 2, astfel încât punctajul pentru experiență similară să fie acordat exclusiv pentru proiecte recente (ultimii 3-5 ani). Menținerea pragului de 15 ani permite participarea unor operatori a căror experiență „similară” se bazează pe tehnologii și arhitecturi de business perimate, crescând exponențial riscul de eșec în livrarea unei soluții moderne și scalabile pentru CNAS.

Răspuns (23 apr 2026, 14:16):

Referitor la discrepanța semnalată privind perioada de referință pentru demonstrarea experienței similare, comunicăm următoarele: În vederea asigurării unui tratament egal al operatorilor economici și a unei aplicări unitare a documentației de atribuire, se precizează: 1. Perioada de referință pentru calificare Pentru îndeplinirea cerințelor de eligibilitate, ofertantul trebuie să demonstreze experiență similară aferentă proiectelor implementate în ultimii 5 ani, conform secțiunii 5.4 din Caietul de sarcini . Aceasta reprezintă condiția minimă obligatorie de calificare și asigură relevanța experienței în raport cu cerințele tehnologice actuale ale proiectului. 2. Perioada de referință pentru evaluare Mențiunea din Anexa nr. 2 privind perioada de până la 15 ani se aplică exclusiv în cadrul evaluării tehnice, în contextul criteriului „cel mai bun raport calitate-preț”, după cum urmează: • experiența mai extinsă poate fi luată în considerare ca element suplimentar de apreciere; • punctajul se acordă în funcție de relevanța și complexitatea proiectelor, nu doar de vechimea acestora. 3. Abordarea relevanței tehnice În procesul de evaluare, autoritatea contractantă va acorda prioritate proiectelor care demonstrează: • utilizarea tehnologiilor moderne; • implementarea de arhitecturi scalabile și interoperabile; • experiență relevantă pentru proiecte de tip „greenfield”. Astfel, chiar dacă pot fi prezentate proiecte realizate într-o perioadă mai extinsă, relevanța tehnologică și funcțională a acestora va fi factorul determinant în acordarea punctajului. 4. Cu privire la ajustarea documentației Nu se consideră necesară limitarea exclusivă a perioadei de 5 ani pentru evaluare, întrucât: • abordarea actuală permite maximizarea concurenței; • asigură o evaluare flexibilă, bazată pe relevanță, nu doar pe criteriul temporal.

Obiectul achiziției

Data:

17 apr 2026, 18:04

Subiectul întrebării:

Solicitare de clarificări privind standardele de calificare ale personalului-cheie (Tabelul 3.1)

Întrebare:

Stimați membri ai grupului de lucru, Având în vedere valoarea estimată a contractului de 37.500.000,00 MDL și complexitatea extremă a SI „Protecția Socială”, considerăm că actualele cerințe față de personalul-cheie sunt insuficiente pentru a garanta succesul implementării. Analizând Tabelul 3.1 și metodologia de punctare „Da/Nu”, am observat că pentru roluri de o importanță strategică, certificările profesionale recunoscute internațional sunt tratate doar ca un „avantaj” sau sunt diluate într-o masă de 74 de criterii. În acest sens, vă solicităm următoarele clarificări și măsuri de rigoare: 1) Certificări obligatorii pentru rolurile critice: De ce pentru rolurile de System Architect (unde se menționează TOGAF/CTA), Specialist Securitate IT (unde se menționează CISSP/CompTIA) și Inginer Asigurare Calitate (unde se menționează ISTQB), certificările sunt calificate doar ca „avantaj”? Considerăm că lipsa obligativității acestor certificări permite accesul unor experți fără o confirmare riguroasă a competențelor, crescând riscul de erori arhitecturale grave într-un sistem național. 2) Rigoarea procesului de selecție: Având în vedere că proiectul impune conformitatea cu standarde internaționale (ex: ISO 27001, ISO 15408), vă rugăm să explicați cum va asigura Autoritatea Contractantă respectarea acestora dacă echipa tehnică a Furnizorului nu deține obligatoriu certificări profesionale care să ateste stăpânirea acestor metodologii? 3) Impactul asupra calității: Metodologia curentă (proporționalitatea punctajului pe 74 de criterii) permite unui ofertant să obțină un punctaj ridicat chiar dacă niciunul dintre experții propuși nu deține o certificare profesională validă, compensând prin alte criterii minore. Vă solicităm să revizuiți Documentația Standard pentru a introduce certificările profesionale ca cerințe minime obligatorii (eliminatorii) pentru rolurile de Manager Proiect, Arhitect, Securitate și QA. Menținerea unor cerințe „relaxate” în raport cu un buget de asemenea anvergură subminează principiul utilizării eficiente a banilor publici și expune CNAS unor riscuri tehnice ce pot duce la eșecul total al noului sistem informațional.

Răspuns (23 apr 2026, 14:17):

Stimați operatori economici, Referitor la propunerile privind revizuirea cerințelor pentru personalul-cheie și introducerea certificărilor profesionale ca cerințe obligatorii, comunicăm următoarele: 1. Cu privire la caracterul certificărilor profesionale Cerințele stabilite în documentația de atribuire sunt formulate în conformitate cu principiile proporționalității, nediscriminării și asigurării concurenței, prevăzute de legislația în domeniul achizițiilor publice. În acest sens: • certificările profesionale (ex.: TOGAF, CISSP, ISTQB etc.) sunt recunoscute ca elemente relevante și valorizate în evaluare, însă nu sunt stabilite ca cerințe eliminatorii; • competențele pot fi demonstrate și prin experiență practică relevantă, confirmată prin documente justificative; • impunerea certificărilor ca cerințe obligatorii ar putea conduce la restrângerea nejustificată a concurenței. Respectarea standardelor menționate este asigurată printr-un ansamblu de cerințe tehnice, mecanisme contractuale și procese de control, și nu exclusiv prin deținerea unor certificări individuale. 2. Modalitatea de demonstrare a competențelor profesionale Competențele solicitate pentru personalul-cheie, inclusiv cele de natură analitică, managerială sau de design, pot fi justificate printr-un set de documente relevante, precum: • CV-uri detaliate, care reflectă experiența în proiecte similare; • descrierea rolului și contribuției în cadrul proiectelor implementate; • portofolii de lucrări (pentru roluri precum BA sau UX/UI), inclusiv livrabile, prototipuri, studii de caz, rapoarte de testare usability; • artefacte livrate (ex.: specificații funcționale, documentație de design, concluzii din testări); • scrisori de recomandare sau referințe; • diplome, certificări sau cursuri de specialitate (unde există); • declarații pe proprie răspundere privind competențele deținute. Aceste documente permit evaluarea reală și verificabilă a capacității profesionale a experților propuși. 3. Asigurarea conformității cu standardele internaționale Respectarea standardelor (ex.: ISO 27001, bune practici în securitate și dezvoltare software) este asigurată prin: • cerințele funcționale și nefuncționale din Caietul de sarcini; • obligațiile contractuale ale furnizorului; • procesele de testare, validare și acceptanță; • evaluarea tehnică a echipei și a soluției propuse. Prin urmare, conformitatea este determinată de capacitatea demonstrată a echipei și a soluției, nu exclusiv de deținerea unor certificări individuale. 4. Metodologia de evaluare Metodologia aplicată permite o evaluare complexă și echilibrată, luând în considerare: • experiența similară; • competențele și calificările echipei; • abordarea tehnică; • capacitatea de implementare. Certificările profesionale reprezintă un avantaj competitiv și pot influența pozitiv punctajul, fără a constitui însă unicul criteriu de apreciere. 5. Concluzie Abordarea actuală din documentația de atribuire se menține, întrucât: • respectă cadrul legal aplicabil; • asigură echilibrul între rigoarea tehnică și concurență; • permite selectarea ofertei celei mai avantajoase din punct de vedere calitate-preț.

Obiectul achiziției

Data:

20 apr 2026, 00:21

Subiectul întrebării:

Cerințe echipă

Întrebare:

Conform DS, ”Ofertantul va prezenta documente justificative care să confirme îndeplinirea cerințelor stabilite”. Cum pot fi justificate/demonstrate următoarele calificări solicitate: PM - abilități puternice analitice, de conducere și motivare a personalului BA - Competențe și abilități cheie: · Competențe și abilități cheie: - UX/UI designerul trebuie să meargă dincolo de simpla execuție a sarcinilor – să gândească strategic, să identifice oportunități de îmbunătățire și să propună soluții care simplifică fluxurile complexe de utilizator. Rolul necesită gândire analitică, curiozitate și abilitatea de a conecta nevoile utilizatorilor, obiectivele de business și realitățile tehnice. Designerul va face parte din echipa de bază, contribuind la luarea deciziilor și livrarea rezultatelor – nu doar la crearea interfețelor; - Înțelegere solidă și aplicare a principiilor de design centrat pe utilizator și design de servicii; - Abilitatea de a documenta clar deciziile de design pentru predarea către echipele de inginerie (specificații Figma, adnotări pentru componente); - Capacitatea de a lucra eficient în echipe multidisciplinare și de a gestiona simultan mai multe proiecte; - Empatie și conștientizare față de diversitatea nevoilor utilizatorilor și cerințele de accesibilitate; - Orientare către rezultate, cu accent pe impact măsurabil și îmbunătățire continuă bazată pe feedbackul utilizatorilor și date; - Gândire analitică și orientată spre soluții, cu abilitatea de a transforma nevoile complexe ale utilizatorilor în design-uri simple și intuitive; Astfel de abilități pot fi evaluate în cadrul unor interviuri de angajare. În ofertă ce ar fi considerat suficient și acceptabil documentat pentru a demonstra așa gen de competențe, ținând cont că sunt obligatorii si fac parte din evaluare.

Răspuns (23 apr 2026, 14:18):

Referitor la modalitatea de demonstrare a competențelor și abilităților calitative (soft skills) solicitate pentru personalul-cheie, comunicăm următoarele: În contextul documentației de atribuire, cerința privind prezentarea documentelor justificative are ca scop confirmarea rezonabilă și verificabilă a calificărilor declarate, inclusiv pentru competențele de ordin comportamental și profesional. Având în vedere natura acestor competențe (analitice, de leadership, colaborare, gândire strategică etc.), acestea nu pot fi demonstrate exclusiv prin documente formale standardizate, motiv pentru care se acceptă un ansamblu de dovezi relevante, după cum urmează: 1. Pentru rolul de Project Manager (PM) Competențele precum abilități analitice, de conducere și motivare pot fi demonstrate prin: • CV detaliat, care evidențiază experiența în coordonarea proiectelor similare (dimensiune, echipă, complexitate); • descrierea proiectelor implementate, cu indicarea rolului concret (ex.: coordonare echipă, gestionare riscuri, luare decizii); • scrisori de recomandare/referințe de la beneficiari sau angajatori anteriori; • certificări relevante (dacă există) – ex.: PMP, PRINCE2 (nu obligatorii, dar relevante); • declarație pe proprie răspundere privind competențele de leadership și management. 2. Pentru rolul de Business Analyst (BA) și UX/UI Designer Competențele menționate (gândire analitică, design centrat pe utilizator, colaborare etc.) pot fi demonstrate prin: • portofoliu de lucrări/proiecte (ex.: livrabile, wireframe-uri, mockup-uri, studii de caz, prototipuri – inclusiv Figma sau alte instrumente); • descrierea contribuției în proiecte similare, inclusiv: o analiza cerințelor; o definirea fluxurilor de utilizator; o colaborarea cu echipe tehnice; • artefacte livrate (ex.: specificații funcționale, user stories, documentație de design); • CV detaliat, cu evidențierea competențelor aplicate în contexte reale; • scrisori de recomandare/referințe profesionale; • certificări sau cursuri relevante (unde există) – ex.: UX/UI, design thinking etc. 3. Abordarea în procesul de evaluare Evaluarea acestor competențe se va realiza: • în baza documentelor prezentate în ofertă, prin analiza coerenței și relevanței acestora; • prin aprecierea experienței practice demonstrate în proiecte similare; • fără a solicita simularea interviurilor, dar urmărind consistența profilului profesional. 4. Clarificare importantă • Cerințele privind aceste competențe sunt considerate obligatorii la nivel declarativ și demonstrativ, însă evaluarea lor se face în mod rezonabil, în baza probelor disponibile; • nu se solicită dovezi imposibil de furnizat (ex.: testări psihologice sau evaluări interne), ci documente uzuale în practică. Concluzie Pentru demonstrarea competențelor menționate, ofertanții vor prezenta un set coerent de documente (CV, portofoliu, descrieri de proiecte, referințe), care să permită autorității contractante evaluarea credibilă a experienței și capacității profesionale a experților propuși.

Obiectul achiziției

Data:

20 apr 2026, 00:22

Subiectul întrebării:

Testarea de acceptanță

Întrebare:

Ați indicat in sarcina tehnica si ați confirmat prin răspuns la clarificări că testarea de acceptanță ar urma să fie efectuată de Furnizor împreună cu Beneficiarul. Atragem atenție că în conformitate cu standardele, atât PMBOK, cât și PRINCE2, la care faceți referință în documentație, responsabilitatea finală pentru testarea de acceptanță aparține beneficiarului (clientului) — chiar dacă furnizorul poate oferi suport în procesul de testare. Respectiv UAT 002 și DEL 005 contravin standardelor și pasează nejustificat pe Furnizor responsabilitatea pentru organizarea testării de acceptanță și raportarea/documentarea rezultatelor UAT. Sau planul de asigurare a calității care este solicitat prin PIR 040 ar putea/trebui să fie elaborat cu încălcarea standardelor pentru a corespunde așteptărilor și cerințelor din UAT 002 și DEL 005?

Răspuns (23 apr 2026, 14:18):

Referitor la responsabilitățile privind testarea de acceptanță (UAT) și corelarea acestora cu bunele practici internaționale (PMBOK, PRINCE2), comunicăm următoarele: 1. Principiul responsabilității pentru UAT Autoritatea contractantă confirmă că, în conformitate cu standardele și bunele practici invocate, responsabilitatea finală pentru acceptarea sistemului aparține Beneficiarului (CNAS). 2. Rolul Furnizorului în procesul de testare de acceptanță Cerințele UAT 002 și DEL 005 nu transferă responsabilitatea finală asupra Furnizorului, ci stabilesc obligația acestuia de a: • organiza și facilita procesul de testare de acceptanță (suport tehnic și metodologic); • elabora și pune la dispoziție scenarii de testare, date de test și medii de testare; • asigura remedierea neconformităților identificate; • contribui la documentarea rezultatelor testării. 3. Rolul Beneficiarului (CNAS) Beneficiarul: • validează scenariile de testare; • participă activ la executarea testelor; • decide asupra acceptării sau respingerii livrabilelor; • confirmă rezultatele finale ale UAT. 4. Cu privire la Planul de asigurare a calității (PIR 040) Planul de asigurare a calității: • urmează a fi elaborat de Furnizor în conformitate cu standardele și bunele practici aplicabile; • va include clar delimitarea responsabilităților între Furnizor și Beneficiar; • nu presupune și nu necesită abaterea de la standarde, ci operaționalizarea acestora în contextul proiectului. 5. Concluzie Nu există o contradicție între cerințele documentației și standardele menționate. • Furnizorul asigură suportul operațional și tehnic al procesului UAT; • Beneficiarul păstrează responsabilitatea decizională finală privind acceptanța sistemului.

Obiectul achiziției

Data:

26 apr 2026, 16:40

Subiectul întrebării:

Aviz Agentia Guvernare Electronica

Întrebare:

Având în vedere că, potrivit Hotărârii Guvernului nr. 544/2019, achizițiile în domeniul tehnologiei informației și comunicațiilor realizate de entitățile vizate de acest act normativ sunt supuse mecanismului de coordonare/avizare de către Agenția de Guvernare Electronică, iar potrivit practicii și ghidurilor aplicabile în domeniul achizițiilor TIC, coordonarea vizează nu doar planurile generale de achiziții TIC și modificările acestora, ci și documentația aferentă procedurii de achiziție, vă solicităm să prezentați, în mod expres, următoarele informații și documente: dacă pentru prezenta procedură de achiziție a fost solicitat și obținut Avizul Agenției de Guvernare Electronică; numărul, data și obiectul Avizului AGE, precum și confirmarea dacă acesta se referă exact la prezenta procedură de achiziție și la documentația publicată; copia Avizului AGE, inclusiv eventualele observații, condiționări, recomandări sau rezerve formulate de AGE; în cazul în care refuzați prezentarea copiei Avizului AGE, vă rugăm să indicați temeiul legal expres care permite refuzul comunicării acestui document către operatorii economici interesați. Subliniem că distincția invocată anterior între „documentația de atribuire” și „avizele de coordonare interinstituțională” nu poate justifica lipsa de transparență asupra unui document care privește legalitatea, oportunitatea tehnică și conformitatea sistemică a achiziției TIC. Faptul că un aviz nu este enumerat expres printre documentele minime ale documentației de atribuire nu înseamnă că acesta este exceptat de la regimul informațiilor de interes public, mai ales în condițiile în care el privește utilizarea fondurilor publice, conformitatea cu infrastructura guvernamentală TIC și condițiile tehnice reale în baza cărora urmează să fie elaborată oferta. În lipsa prezentării Avizului AGE sau cel puțin a datelor minime de identificare ale acestuia, operatorii economici nu pot verifica dacă procedura a fost inițiată cu respectarea cadrului normativ aplicabil achizițiilor TIC și dacă cerințele tehnice publicate sunt conforme cu condițiile, observațiile sau limitările formulate de autoritatea competentă în domeniul guvernării electronice. Prin urmare, vă rugăm să confirmați expres dacă Avizul AGE există și să îl puneți la dispoziția operatorilor economici, iar în caz contrar să indicați temeiul legal concret al neprezentării acestuia.

Răspuns (26 apr 2026, 19:15):

Referitor la aplicabilitatea Hotărârii Guvernului nr. 544/2019 și la solicitarea privind prezentarea Avizului Agenției de Guvernare Electronică (AGE), comunicăm următoarele: 1. Cu privire la existența și conținutul avizului AGE Pentru prezenta procedură de achiziție, avizul Agenției de Guvernare Electronică a fost solicitat și obținut, acesta fiind pozitiv și referindu-se la obiectul procedurii de achiziție și la documentația aferentă. 2. Cu privire la caracterul avizului Avizul AGE are caracter consultativ (recomandator), în conformitate cu prevederile Hotărârii Guvernului nr. 544/2019. Recomandările formulate au fost analizate și, după caz, integrate în documentația de atribuire. 3. Cu privire la prezentarea copiei avizului Avizul AGE face parte din circuitul intern de coordonare interinstituțională și nu constituie document obligatoriu al documentației de atribuire publicate în cadrul procedurii de achiziție. Totodată: informațiile esențiale relevante pentru operatorii economici se regăsesc în documentația de atribuire publicată în SIA RSAP; lipsa publicării avizului nu afectează transparența procedurii și nici posibilitatea operatorilor economici de a elabora oferte conforme. 4. Cu privire la temeiul neprezentării copiei În conformitate cu cadrul normativ aplicabil, autoritatea contractantă are obligația de a publica documentele prevăzute expres de legislația în domeniul achizițiilor publice. Avizele de coordonare interinstituțională nu sunt incluse în această categorie și, respectiv, nu există obligația legală de publicare a acestora în cadrul procedurii. Concluzie avizul AGE a fost solicitat și obținut; acesta este pozitiv și are caracter recomandator; documentația de atribuire a fost elaborată ținând cont de recomandările relevante; publicarea copiei avizului nu este obligatorie conform cadrului normativ aplicabil. Prezenta clarificare confirmă respectarea cerințelor legale și a procedurilor aplicabile în domeniul achizițiilor TIC

Obiectul achiziției

Data:

26 apr 2026, 17:19

Subiectul întrebării:

Solicitare de clarificări privind adecvarea standardelor de calificare pentru personalul-cheie în raport cu complexitatea proiectului

Întrebare:

Stimați membri ai grupului de lucru, Având în vedere valoarea estimată a contractului (37.500.000 MDL) și natura critică a sistemului informațional „Protecția Socială”, considerăm că cerințele actuale privind calificarea personalului-cheie și metodologia de evaluare aferentă necesită clarificări suplimentare pentru a asigura selectarea reală a celei mai competente echipe. Analizând Tabelul 3.1 și mecanismul de evaluare bazat pe 74 de criterii de tip „Da/Nu”, constatăm următoarele riscuri: lipsa unor cerințe minime ferme pentru roluri critice (arhitectură, securitate, QA, management proiect); posibilitatea compensării lipsei competențelor esențiale prin acumularea de puncte pe criterii secundare; absența unui mecanism clar de diferențiere între experiență generală și expertiză validată în mod obiectiv. În acest context, vă rugăm să clarificați: 1. Corelarea nivelului cerințelor cu complexitatea proiectului Cum justifică Autoritatea Contractantă faptul că pentru roluri critice (System Architect, Specialist Securitate IT, QA, Manager Proiect), certificările profesionale recunoscute internațional (ex. TOGAF sau echivalent, CISSP sau echivalent, ISTQB sau echivalent, PMP/PRINCE2 sau echivalent) sunt tratate exclusiv ca avantaje și nu ca indicatori minimi de calificare, în condițiile unui proiect național cu cerințe explicite de conformitate la standarde internaționale? 2. Risc de evaluare neuniformă În lipsa unor cerințe minime obligatorii pentru aceste roluri, vă rugăm să explicați: - cum se asigură o evaluare obiectivă și comparabilă între ofertanți; - cum se evită situația în care un ofertant fără certificări relevante pentru roluri critice obține un punctaj similar sau superior unuia cu expertiză validată formal. 3. Definirea echivalenței „experiență vs certificare” Întrucât ați indicat că experiența practică poate substitui certificările, vă rugăm să specificați criteriile obiective de echivalare: - număr minim de ani de experiență relevantă; - tipul proiectelor acceptate (complexitate, domeniu, rol efectiv); - livrabile concrete realizate; - modalitatea de verificare a acestor afirmații. În lipsa unor astfel de criterii, evaluarea competențelor devine subiectivă și dificil de auditat. 4. Impactul metodologiei „Da/Nu” asupra calității selecției Metodologia actuală permite acumularea punctajului prin criterii multiple, fără a garanta îndeplinirea unor competențe esențiale la nivel minim. Vă rugăm să precizați: - dacă există criterii considerate implicit critice (chiar dacă nu sunt marcate ca eliminatorii); - dacă lipsa unor competențe fundamentale (ex. arhitectură enterprise, securitate avansată) poate fi compensată integral prin alte criterii. 5. Mecanisme reale de asigurare a calității echipei În contextul în care certificările nu sunt obligatorii, vă rugăm să detaliați: - ce mecanisme concrete (nu doar contractuale) asigură că echipa propusă are competențele necesare pentru proiectarea și implementarea unui sistem de asemenea complexitate; - cum se verifică autenticitatea și relevanța experienței declarate; - dacă declarațiile pe proprie răspundere sunt considerate suficiente pentru validarea competențelor tehnice critice. Concluzie: În forma actuală, abordarea permite o participare largă, dar ridică semne de întrebare privind capacitatea de a diferenția efectiv între echipe cu niveluri foarte diferite de maturitate profesională. Vă rugăm să clarificați modul în care cadrul actual asigură nu doar respectarea principiului concurenței, ci și selectarea unei echipe cu nivel adecvat de expertiză pentru un proiect de importanță sistemică.

Răspuns (26 apr 2026, 20:05):

Stimați operatori economici, În continuarea clarificărilor anterioare privind perioada de calificare și evaluare, în vederea asigurării transparenței și aplicării uniforme a criteriilor de evaluare, comunicăm următoarele: 1. Cu privire la definirea „relevanței tehnice” Evaluarea relevanței proiectelor similare se realizează în baza criteriilor stabilite în documentația de atribuire (Caietul de sarcini și Anexa nr. 2), având în vedere, în mod cumulativ: • similitudinea funcțională • complexitatea tehnică • tipul și volumul activităților realizate • rolul și responsabilitățile ofertantului în cadrul proiectului; • mediul de implementare. Aceste criterii sunt reflectate în cerințele și factorii de evaluare din documentație, iar aplicarea lor se realizează uniform pentru toți ofertanții, de către grupul de lucru. 2. Corelarea vechimii cu punctajul • Proiectele nu sunt evaluate exclusiv în funcție de vechime; • relevanța tehnico-funcțională este determinantă în acordarea punctajului; • proiectele recente, care demonstrează utilizarea tehnologiilor actuale și abordări moderne, au în mod natural o pondere mai mare în evaluare, prin prisma relevanței; • proiectele mai vechi pot fi luate în considerare doar în măsura în care rămân relevante din punct de vedere tehnic. 3. Cu privire la formula de punctaj Modul de acordare a punctajului este stabilit în Anexa nr. 2 și presupune o evaluare bazată pe: • numărul proiectelor similare prezentate; • complexitatea și relevanța acestora; • gradul de corespondență cu obiectul achiziției. Nu se aplică o formulă strict aritmetică exclusiv bazată pe vechime, ci o evaluare calitativă și proporțională, în limitele și ponderile stabilite în documentație. 4. Cu privire la riscul de compensare Metodologia de evaluare este concepută astfel încât: • să nu permită compensarea artificială a lipsei experienței relevante cu proiecte nerelevante; • punctajul să fie acordat în funcție de relevanța reală și demonstrabilă a experienței; • experiența în tehnologii și arhitecturi actuale să fie reflectată corespunzător în evaluare. 5. Coerența criteriilor (5 ani vs. 15 ani) • perioada de 5 ani asigură un prag minim de actualitate a experienței pentru calificare; • perioada de până la 15 ani permite valorificarea unei experiențe mai extinse, fără a limita concurența; • diferențierea are la bază un echilibru între relevanța tehnologică și experiența acumulată, în conformitate cu principiile proporționalității și eficienței utilizării fondurilor publice. Concluzie Evaluarea ofertelor se realizează în baza criteriilor stabilite în documentația de atribuire, într-o manieră transparentă, proporțională și nediscriminatorie, asigurând selectarea ofertei cu cel mai bun raport calitate-preț.

Obiectul achiziției

Data:

26 apr 2026, 17:19

Subiectul întrebării:

Solicitare de clarificări privind adecvarea standardelor de calificare pentru personalul-cheie în raport cu complexitatea proiectului

Întrebare:

Obiectul achiziției

Data:

26 apr 2026, 17:41

Subiectul întrebării:

Evaluare experienta

Întrebare:

Stimați membri ai grupului de lucru, Vă mulțumim pentru clarificarea privind diferențierea între perioada de calificare (5 ani) și cea de evaluare (până la 15 ani). Cu toate acestea, răspunsul ridică o serie de aspecte critice privind transparența și obiectivitatea evaluării, motiv pentru care vă rugăm să furnizați următoarele clarificări suplimentare: 1. Definirea „relevanței tehnice” Ați menționat că punctajul va fi acordat în funcție de relevanța tehnologică și funcțională a proiectelor. Vă rugăm să precizați: - care sunt criteriile obiective utilizate pentru evaluarea relevanței; - dacă există o grilă sau o metodologie formală de evaluare; - cum se asigură aplicarea uniformă a acestor criterii între ofertanți. În absența unor criterii explicite, evaluarea poate deveni subiectivă și dificil de verificat. 2. Corelarea vechimii cu punctajul Vă rugăm să clarificați: - dacă proiectele realizate în urmă cu 10–15 ani sunt evaluate pe picior de egalitate cu cele recente; - dacă există mecanisme de diminuare a punctajului pentru proiecte bazate pe tehnologii sau arhitecturi depășite; - dacă vechimea proiectului influențează în mod direct punctajul acordat. 3. Formula de punctaj Vă rugăm să indicați: - modul concret de calcul al punctajului pentru experiența similară; - dacă există limite maxime de punctaj pentru experiență veche vs recentă; - dacă numărul de proiecte sau complexitatea acestora prevalează în evaluare. 4. Riscul de compensare În contextul actual, este posibil ca: - experiența extinsă, dar neactualizată tehnologic, să compenseze lipsa experienței relevante în tehnologii moderne. Vă rugăm să precizați dacă există mecanisme care previn această situație. 5. Coerența criteriilor Având în vedere că pragul de calificare este limitat la 5 ani pentru a asigura relevanța tehnologică, vă rugăm să explicați: - în ce mod perioada de 15 ani pentru evaluare este compatibilă cu acest obiectiv; - care este rațiunea tehnică și economică pentru menținerea acestei diferențieri.

Obiectul achiziției

Data:

26 apr 2026, 18:30

Subiectul întrebării:

Clarificare privind relevanța criteriilor pentru rolul Business Analyst și impactul asupra evaluării

Întrebare:

Referitor la cerința privind „experiență în testarea modulară, integrarea continuă, DevOps” pentru rolul Business Analyst și răspunsul conform căruia aceasta poate fi tratată ca avantaj, vă rugăm să clarificați următoarele aspecte: 1. Relevanța criteriului pentru rol Având în vedere că responsabilitățile tipice ale unui Business Analyst vizează: - analiza cerințelor, - modelarea proceselor, - documentarea funcțională, - facilitarea comunicării între stakeholderi, vă rugăm să explicați: - care este justificarea tehnică și organizațională pentru includerea competențelor de tip DevOps și CI/CD în profilul acestui rol; - în ce mod aceste competențe contribuie direct la îndeplinirea responsabilităților BA în cadrul proiectului. 2. Impactul asupra punctajului În contextul în care cerința este calificată ca „avantaj”, vă rugăm să precizați: - dacă aceasta este inclusă în criteriile punctabile din cadrul evaluării tehnice; - ce punctaj concret sau proporțional poate influența; - dacă lipsa acestei competențe poate fi compensată prin alte criterii. 3. Riscul de distorsionare a evaluării În forma actuală, există posibilitatea ca: - un expert BA cu competențe solide în analiză de business, dar fără expunere DevOps, - să fie punctat inferior - unui expert cu profil tehnic mixt, dar mai puțin relevant pentru rolul de analiză. Vă rugăm să precizați: - dacă există mecanisme care previn această situație; - dacă sunt definite criterii prioritare pentru rolul BA. 4. Coerența grilei de evaluare Având în vedere metodologia bazată pe criterii multiple de tip „Da/Nu”, vă rugăm să clarificați: - dacă acest criteriu este tratat la același nivel cu competențele fundamentale ale rolului; - cum se asigură că criteriile secundare nu influențează disproporționat rezultatul evaluării. 5. Intenția Autorității Contractante Vă rugăm să precizați dacă: - această cerință reflectă o extindere intenționată a rolului BA către un profil hibrid (BA + Tech/DevOps), sau - reprezintă un criteriu orientativ fără impact semnificativ asupra evaluării.

Cu părere de rău întrebările se pun doar în perioada "Activ".

Clarificări