Servicii de programare şi de consultanţă software

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.

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

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

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.

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.

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.

Î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

Î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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.