Achiziție - Servicii de programare şi de consultanţă software

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.

... afișează tot conținutul

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ț.

... afișează tot conținutul

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.

... afișează tot conținutul

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.

... afișează tot conținutul

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?

... afișează tot conținutul

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.

... afișează tot conținutul

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?

... afișează tot conținutul

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.

... afișează tot conținutul

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.

... afișează tot conținutul

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

... afișează tot conținutul

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.

... afișează tot conținutul

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ț.

... afișează tot conținutul

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ă.

... afișează tot conținutul

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ț.

... afișează tot conținutul

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.

... afișează tot conținutul

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

... afișează tot conținutul

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ă.

... afișează tot conținutul

1. Corelarea cerințelor cu complexitatea proiectului
Cerințele privind personalul-cheie au fost stabilite în conformitate cu principiile proporționalității și concurenței loiale, raportate la complexitatea proiectului.
În acest sens:
• certificările profesionale (ex.: TOGAF, CISSP, ISTQB, PMP/PRINCE2 sau echivalent) sunt recunoscute ca indicatori relevanți de competență, însă nu sunt impuse ca cerințe eliminatorii;
• competențele pot fi demonstrate prin experiență practică în proiecte similare, ceea ce permite participarea unui spectru mai larg de operatori economici, fără a compromite nivelul de calificare.
________________________________________
2. Asigurarea unei evaluări obiective și comparabile
Evaluarea ofertelor se realizează în baza criteriilor stabilite în documentația de atribuire, care sunt:
• clare, publice și aplicabile uniform tuturor ofertanților;
• fundamentate pe analiza cumulativă a experienței, competențelor și relevanței proiectelor prezentate;
• structurate astfel încât să permită o comparabilitate reală între oferte.
Certificările profesionale constituie un avantaj în evaluare, contribuind la punctaj, însă nu sunt singurul element de diferențiere.
________________________________________
3. Echivalența „experiență vs certificare”
Experiența practică este evaluată în baza unor elemente obiective, inclusiv:
• numărul și complexitatea proiectelor similare;
• rolul efectiv al expertului (ex.: arhitect, responsabil securitate, QA, manager proiect);
• durata implicării și responsabilitățile asumate;
• livrabilele realizate (ex.: arhitecturi, specificații, planuri de securitate, rapoarte QA etc.);
• documente justificative (contracte, procese-verbale de recepție, recomandări).
Aceste elemente permit verificarea și validarea experienței declarate, fără a se limita exclusiv la certificări.
________________________________________
4. Impactul metodologiei „Da/Nu”
Metodologia utilizată:
• nu este una formală sau izolată, ci face parte dintr-un cadru mai larg de evaluare tehnică;
• presupune îndeplinirea cumulativă a unui set de criterii relevante;
• nu permite compensarea integrală a lipsei unor competențe esențiale prin criterii minore, întrucât evaluarea are în vedere relevanța și coerența întregii echipe propuse.
Deși nu toate criteriile sunt marcate ca eliminatorii, unele au importanță majoră în evaluarea calitativă.
________________________________________
5. Mecanisme de asigurare a calității echipei
Autoritatea contractantă asigură calitatea echipei propuse prin:
• evaluarea detaliată a CV-urilor și experienței profesionale;
• analiza portofoliilor și livrabilelor relevante;
• solicitarea și verificarea documentelor justificative;
• posibilitatea de a solicita clarificări suplimentare sau de a verifica referințele;
• includerea în contract a unor clauze privind performanța și înlocuirea personalului necorespunzător.
Declarațiile pe proprie răspundere nu sunt analizate izolat, ci în corelare cu celelalte dovezi prezentate.
________________________________________
Concluzie
Cadrul actual de evaluare:
• respectă principiile legale aplicabile;
• asigură un echilibru între accesul concurențial și rigoarea tehnică;
• permite selectarea unei echipe cu competențe reale și relevante, pe baza unui ansamblu de criterii obiective.

... afișează tot conținutul

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.

... afișează tot conținutul

Stimați operatori economici,
Referitor la cerința privind „experiență în testarea modulară, integrarea continuă, DevOps” pentru rolul Business Analyst (BA), comunicăm următoarele:

1. Relevanța criteriului pentru rolul BA
Responsabilitățile principale ale rolului BA rămân cele specifice domeniului de analiză de business (analiza cerințelor, modelarea proceselor, documentare funcțională, facilitarea comunicării).Menționarea competențelor aferente proceselor de tip DevOps și CI/CD are rolul de a:
• asigura o mai bună colaborare cu echipele tehnice;
• facilita înțelegerea ciclului de livrare software și a dependențelor dintre cerințe și implementare;
• contribui la definirea unor cerințe aliniate cu procesele moderne de dezvoltare.
Aceste competențe sunt complementare, nu esențiale pentru exercitarea rolului.
2. Impactul asupra punctajului
• Cerința respectivă este tratată ca avantaj și poate fi reflectată limitat în evaluarea tehnică;
• nu constituie criteriu eliminatoriu și nu are o pondere semnificativă în punctajul total;
• lipsa acestei competențe nu afectează calificarea și poate fi compensată prin îndeplinirea criteriilor principale aferente rolului.
3. Riscul de distorsionare a evaluării
Evaluarea este realizată astfel încât:
• competențele fundamentale ale rolului BA să aibă prioritate (analiză de business, modelare, documentare, comunicare);
• criteriile secundare, inclusiv cele de tip DevOps, să nu conducă la o ierarhizare nejustificată;
• să fie evitată favorizarea unui profil tehnic în detrimentul unuia relevant funcțional.
4. Coerența grilei de evaluare
Metodologia de evaluare:
• diferențiază implicit între criterii esențiale și criterii complementare;
• nu tratează toate cerințele la același nivel de importanță, chiar dacă sunt exprimate în format „Da/Nu”;
• asigură că criteriile secundare nu influențează disproporționat rezultatul final.

5. Intenția Autorității Contractante
Cerința nu reflectă o redefinire a rolului BA într-un profil hibrid obligatoriu (BA + DevOps), ci:
• reprezintă un criteriu orientativ, menit să evidențieze un plus de adaptabilitate la medii moderne de dezvoltare;
• nu are impact semnificativ asupra eligibilității și nici nu modifică profilul de bază al rolului.
Competențele menționate (testare modulară, CI/CD, DevOps) sunt considerate avantaje opționale, fără caracter obligatoriu, iar evaluarea va acorda prioritate competențelor esențiale specifice rolului de Business Analyst.

... afișează tot conținutul