Decizie CNSC 1509/2025

În conformitate cu prevederile art. 14 alin. (2) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, cu modificările și completările ulterioare, Consiliul adoptă următoarea: DECIZIE Nr. 1509/C1/1518 Data: 02.05.2025 Prin contestația nr. 1602/28.04.2025, înregistrată la Consiliul Național de Soluționare a Contestațiilor sub nr. 27392/29.04.2025, formulată de SOFTWARE IMAGINATION&VISION SRL în calitate de lider al Asocierii SOFTWARE IMAGINATION&VISION SRL – MAGUAY COMPUTERS SRL, cu sediul în București, Șoseaua București-Ploiești, nr. 73-81, sector 1, Victoria Park, corp clădire C4, parter, Zona B, înmatriculată la Registrul Comerțului cu nr. J2019016321, având cod unic de înregistrare RO 41963989, reprezentată legal prin șef departament licitații, împotriva rezultatului procedurii de atribuire, emis de către entitatea contractantă Societatea Națională NUCLEARELECTRICA SA, cu sediul în București, str. Iancu de Hunedoara, nr. 48, sector 1, în cadrul procedurii de licitație deschisă, organizată în vederea atribuirii contractului, având ca obiect: „Implementare sistem integrat de management al resurselor umane, prin extinderea soluției Oracle HR, aflată în exploatare la CNE Cernavodă, la SNN Sediul Central București și la FCN Pitești, și prin adăugarea de noi funcționalități”, cod CPV 72260000-5, s-a solicitat: 1. În principal: a) obligarea autorității contractante la anularea raportului procedurii nr. E-SAch-RAP-PROC-00492-17-04-25 din 17.04.2025 și documentelor conexe acestuia, respectiv a procesului verbal nr. DA_DA- 25- 00502/ 18.03.2025 și procesului-verbal nr. DA_DA-25- 00655/01.04.2025; b) obligarea autorității contractante la reevaluarea ofertei Asocierii SOFTWARE IMAGINATION&VISION SRL – MAGUAY COMPUTERS SRL pentru aspectele de depunctare nejustificate a ofertei sale menționate în raportul procedurii E-SAch-RAP-PROC-00492-17-04-25 din 17.04.2025 2025 și documentelor conexe acestuia, respectiv a procesului verbal nr. DA_DA-25-00502/18.03.2025 și procesului-verbal nr. DA_DA-25-00655/ 01.04.2025 ca fiind corespunzătoare pentru acordarea unui punctaj superior conform celor pe care le va detalia în continuare. Pagina 1 din 3

c) obligarea autorității contractante la reevaluarea ofertei depuse de CANCOM ROMANIA SRL, având ca subcontractanți pe ORACLE ROMANIA SRL și LOGIKA IT SOLUTIONS SRL. 2. În subsidiar, în eventualitatea în care nu s-ar mai putea dispune măsuri de remediere, solicită anularea procedurii, în conformitate cu prevederile art. 225, alin. (1) lit. d) din Legea nr. 99/2016. În luarea deciziei, CONSILIUL, legal investit, a avut în vedere următoarele: Pentru aceste motive în baza documentelor depuse de părți, CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR DECIDE: Respinge, ca nefondată, contestația formulată de SOFTWARE IMAGINATION&VISION SRL în contradictoriu cu entitatea contractantă Societatea Națională NUCLEARELECTRICA SA. Obligatorie. Împotriva prezentei decizii se poate formula plângere în termen de 10 zile de la comunicare. Complet de soluționare a contestațiilor în domeniul achizițiilor publice: Consilier de soluționare ................. PREȘEDINTE .................... Consilier de soluționare ....................... Redactat practicaua deciziei Maria ROVENȚA Pagina 2 din 3

Redactată în 4 (patru) exemplare originale, conține 162 (osutășaizecișidouă) pagini Pagina 3 din 3

În conformitate cu prevederile art. 14 alin. (2) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, cu modificările și completările ulterioare, Consiliul adoptă următoarea: DECIZIE Nr. 1509/C1/1518 Data: 02.05.2025 Prin contestația nr. 1602/28.04.2025, înregistrată la Consiliul Național de Soluționare a Contestațiilor sub nr. 27392/29.04.2025, formulată de ............................SRL în calitate de lider al Asocierii ............................SRL – ............................SRL, cu sediul în ........., Șoseaua .........-................, înmatriculată la Registrul Comerțului cu nr. ........., având cod unic de înregistrare RO ..............., reprezentată legal prin șef departament licitații, împotriva rezultatului procedurii de atribuire, emis de către entitatea contractantă ......... SA, cu sediul în ........., str. ........., ........., în cadrul procedurii de licitație deschisă, organizată în vederea atribuirii contractului, având ca obiect: „Implementare sistem integrat de management al resurselor umane, prin extinderea soluției Oracle HR, aflată în exploatare la CNE Cernavodă, la SNN Sediul Central ......... și la FCN Pitești, și prin adăugarea de noi funcționalități”, cod CPV 72260000-5, s-a solicitat: 1. În principal: a) obligarea autorității contractante la anularea raportului procedurii nr. E-SAch-RAP-PROC-00492-17-04-25 din 17.04.2025 și documentelor conexe acestuia, respectiv a procesului verbal nr. DA_DA- 25- 00502/ 18.03.2025 și procesului-verbal nr. DA_DA-25- 00655/01.04.2025; b) obligarea autorității contractante la reevaluarea ofertei Asocierii ............................SRL – ............................SRL pentru aspectele de depunctare nejustificate a ofertei sale menționate în raportul procedurii E-SAch-RAP-PROC-00492-17-04-25 din 17.04.2025 2025 și documentelor conexe acestuia, respectiv a procesului verbal nr. DA_DA-25-00502/18.03.2025 și procesului-verbal nr. DA_DA-25-00655/ 01.04.2025 ca fiind corespunzătoare pentru acordarea unui punctaj superior conform celor pe care le va detalia în continuare. c) obligarea autorității contractante la reevaluarea ofertei depuse de

............................SRL,

având

ca

subcontractanți pe ............................SRL și ............................SRL. Pagina 1 din 171

2. În subsidiar, în eventualitatea în care nu s-ar mai putea dispune măsuri de remediere, solicită anularea procedurii, în conformitate cu prevederile art. 225, alin. (1) lit. d) din Legea nr. 99/2016. În luarea deciziei, CONSILIUL, legal investit, a avut în vedere următoarele: A. Suspendarea procedurii de atribuire a contractului de achiziție publică. B. Preliminar contestatorul face o scurtă prezentare a situației de fapt. Contestatorul precizează că la data de 17.04.2025, entitatea contractantă a publicat în SEAP raportul procedurii nr. RAP-PROC-00492- 17-04-25

din

17.04.2025

din

care

rezultă

că

oferta Asocierii ............................SRL – ............................SRL, s-a clasat pe locul II cu un punctaj total de 74 puncte, oferta câștigătoare fiind cea depusă de ............................SRL cu un punctaj total de 81,12 puncte. Precizează că în data de 24.04.2025 entitatea contractantă i-a acordat acces la dosarul achiziție. Analizând argumentele aduse consideră ca neîntemeiată și nelegală decizia de depunctare a ofertei sale. Având în vedere faptul că apreciază contestația a fi pe fond întemeiată, urmează să arate în continuare motivele pentru care susține admiterea acesteia: C. Nerespectarea prevederilor art. 288 din Legea nr. 99/2016 privind transmiterea comunicării rezultatului procedurii. Contestatorul arată că la art. 228, alin. (1) din Legea nr. 99/2016 se prevede obligația entității contractante de a informa fiecare ofertant cu privire la deciziile luate în ceea ce privește rezultatul procedurii, cât mai curând posibil, dar nu mai târziu de 3 zile de la emiterea deciziilor respective. Conform prevederilor art. 288, alin. (2), lit. c) din Legea nr. 99/2016, în cadrul comunicării privind rezultatul procedurii, entitatea contractantă are obligația de a include în conținutul acesteia, pentru oferta admisibilă, dar care nu a fost declarată câștigătoare caracteristicile și avantajele relative ale ofertei/ofertelor desemnate câștigătoare în raport cu oferta sa, numele ofertantului căruia urmează să i se atribuie contractul sectorial. Precizează că entitatea contractantă, deși avea această obligație legală, nu i-a transmis comunicarea rezultatului procedurii în conformitate cu prevederile art. 288 alin. (2) lit. c) din Legea nr. 99/2016, limitându-se doar la publicarea raportului procedurii în SICAP. De altfel, susține că, în pofida faptului că a solicitat, în mod expres, prin adresa nr. 1563/22.04.2025, să i se transmită comunicarea rezultatului procedurii, entitatea contractantă nu a dat curs acestei solicitări. Pagina 2 din 171

În plus, la studiul dosarului achiziției de la sediul entității contractante, din data de 24.04.2025, entitatea contractantă nu i-a dat posibilitatea să obțină o copie, fie în format letric, fie în format electronic, cel puțin după procesul verbal nr. DA_DA-25- 00502/18.03.2025 și procesul-verbal nr. DA_DA-25-00655/01.04.2025, care conțin rezultatul evaluării propunerii tehnice și financiare și sunt parte a dosarului achiziției, mai ales în contextul în care entitatea contractantă nu i-a transmis comunicarea rezultatului procedurii care să conțină cel puțin informațiile prevăzute la art. 288 alin. (2) lit. c) din Legea nr. 99/2016. Practic, în intervalul celor 2 ore acordate de entitatea contractantă pentru studiul dosarului achiziției publice, aceasta a dat posibilitatea reprezentanților Asocierii sale doar să noteze câteva informații esențiale pe care le-au identificat la studiul dosarului achiziției. De asemenea, solicită Consiliul să constate că raportul procedurii nu conține niciun detaliu/informație cu privire la aspectele pentru care oferta Asocierii ............................SRL – ............................SRL a fost depunctată de către comisia de evaluare pentru componenta tehnică - subfactorii de evaluare. Pentru aspectele anterior menționate, consideră că entitatea contractantă a îngrădit dreptul său de a avea acces complet la informațiile pe care aceasta în mod nelegal a refuzat să i le comunice în mod oficial, așa cum legiuitorul a statuat (art. 288 din Legea nr. 99/2019), fiind puși în imposibilitatea de a-și face o apărare corespunzătoare, în lipsa informațiilor detaliate privind motivele depunctării sale și detalii privind caracteristicile și avantajele relative ale ofertei desemnate câștigătoare în raport cu oferta sa. D. Situația pe fond, netemeinicia și nejustificarea depunctării ofertei Asocierii ............................SRL – ............................SRL, pentru componenta tehnică. 1. Depunctarea ofertei sale pentru Factorul 2 - Componenta tehnică pentru care a primit 34 de puncte dintr-un total de 60 de puncte este netemeinică și nejustificată. Conform cap. 2.4.2 Evaluarea propunerilor tehnice din raportul procedurii, oferta sa a obținut un punctaj total de 34 puncte pentru factori de evaluare tehnici, în conținutul raportului procedurii nefiind inclusă nicio o detaliere a motivelor pentru care oferta sa a fost depunctată: Conform cap. 2.4.5 Aplicarea criteriului de atribuire și stabilirea clasamentului ofertanților din raportul procedurii, oferta Asocierii ......... SRL a obținut un punctaj total de 74 puncte, din care 34 puncte pentru componenta tehnică: Nr. crt . Ofertant Punctaj total component Punctaj total component Puncta j total obținut clasamen t Pagina 3 din 171

a tehnică a financiară 1 CANCOM ROMÂNIA SRL 44,00 37,12 81,12 Loc I 2 Asocierea .................. ..........SRL – ............................SR L 34,00 40,00 74,00 Loc II Ca urmare a studierii dosarului achiziției, și pe baza informațiilor pe care a reușit să le noteze, dat fiind refuzul entității contractante, nelegale, de a ne transmite comunicarea rezultatului care să conțină cel puțin informațiile prevăzute la art. 228 din Legea nr. 99/2016 și de a-i acorda posibilitatea de a obține o copie după procesele verbale menționate în raportul procedurii, prezintă în continuare argumentele sale cu privire la netemeinicia depunctării ofertei sale pentru „Componenta tehnică”, pentru: a) Subfactorul 2.1 - calitatea planului și metodologiei de proiect - a obținut 8 puncte din maxim 30 de puncte; Contestatorul prezintă tabelar, detaliat motivele contestației sale aferente fiecărei linii directoare aferent subfactorilor de evaluare conform detalierii grilei de acordare a punctajului prevăzute în Anexa 1 - Fișa de date Informații componenta tehnică, parte din documentația de atribuire: Factorul 2: COMPONENTA TEHNICA - Subfactor 2.1 – Calitatea planului și metodologiei de proiect (30 DE PUNCTE) Punctaj acordat pentru Factorul 2: COMPONENTA TEHNICA - Subfactor 2.1 – Calitatea planului și metodologiei de proiect - 8 puncte. Subfactor 2.1.a - Gradul de detaliere al planului de proiect si al metodologiei de implementare. „Gradul de detaliere a planului de proiect și a metodologiei este corespunzător și facilitează înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. (Foarte bine - 5 puncte)”. „Gradul de detaliere a planului de proiect și a metodologiei este corespunzător și facilitează parțial înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. (Bine - 3 puncte)”. „Gradul de detaliere a planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. (Acceptabil - 1 punct)”. Punctaj acordat de entitatea contractantă - 1 punct. Pagina 4 din 171

Motivele invocate de Entitatea Contractantă pentru acordarea punctajului. i). Riscurile nu sunt tratate din punct de vedere impact și nici al probabilităților de expunere la risc. Motivare contestație: Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Astfel, în Anexa 2 din cadrul Ofertei tehnice - Metodologia de management de proiect, la cap. 3.3.8 Managementul Riscului (pag. 10- 11), susține că a prezentat metodologia de management a riscurilor care descrie modalitatea de tratare a riscurilor din punct de vedere impact și al probabilităților: „Analiza calitativă a riscului este procesul de evaluare a impactului și probabilității de apariție a fiecărui risc identificat. Acest proces prioritizează riscurile în funcție de efectul lor potențial asupra obiectivelor de proiect. Evoluția critică în timp a acțiunilor legate de riscuri poate amplifica importanța riscului. O evaluare a calității informațiilor disponibile ajută de asemenea la modificarea evaluării riscului. Analiza calitativă a riscului necesită ca probabilitatea și consecințele riscului să fie evaluate folosind metode și instrumente de analiză calitativă recunoscute. Procesul de Analiza cantitativă a riscului urmărește să analizeze numeric probabilitatea fiecărui risc și a consecințelor sale asupra obiectivelor de proiect, cât și dimensiunea riscului general al proiectului. În acest proces vor fi folosite tehnici bazate pe analiza de decizie pentru: • Determinarea probabilității de a atinge obiectivele de proiect specifice. • Cuantificarea expunerii la risc a proiectului, și determinarea dimensiunii costurilor și a rezervei planificate de contigență, de care ar putea fi nevoie. • Identificarea riscurilor cu cea mai mare atenție prin cuantificarea contribuției lor relative la riscurile proiectului. • Identificarea de costuri, programe sau ținte realiste și rezonabile privind aria de cuprindere a proiectului”. De asemenea, susține că în Anexa IV.1 - Anexă la propunerea tehnică - la secțiunea 24 - Ipoteze și riscuri (pag. 260 - 266) sunt prezentate în detaliu conform cerințelor din Caietul de sarcini, din punct de vedere impact și al probabilităților de expunere la risc, riscurile cu cel mai mare grad de probabilitate a apariției, pe perioada derulării contractului. Pagina 5 din 171

Pe lângă riscurile indicate în caietul de sarcini, și la care, așa cum a arătat mai sus, a răspuns în oferta sa, societatea a identificat si prezentat în oferta depusă si alte riscuri împreună cu recomandările si propunerile de reducere sau eliminare a riscurilor care ar putea afecta implementarea serviciilor, astfel: • „Comunicarea defectuoasă/ ineficientă în cadrul echipei și/ sau cu echipa prestatorului. Riscul este alocat atât Operatorului Economic cât și Entității Contractante, iar prin măsurile de prevenire și gestionare se vor avea în vedere următoarele: Managerul de proiect al Ofertantului va intermedia comunicarea în cadrul echipei proprii de implementare. Comunicarea între echipa Prestatorului și echipa Entității Contractante se va face printr-un punct unic, astfel încât toate părțile să fie informate (adresă de email comună). • Creșterii neprevăzută a timpului necesar pentru aprobarea livrabilelor proiectului. Riscul este alocat atât Operatorului Economic cât si Entității Contractante, iar prin măsurile de prevenire si gestionare se vor avea în vedere următoarele: - Limitarea numărului de revizuiri în vederea aprobării livrabilelor proiectului în Metodologia de Implementare a Proiectului care va fi utilizată - Îmbunătățirea calității livrabilelor proiectului prin verificări/validări suplimentare efectuate de experții Prestatorului, înainte de a fi trimise spre validare Entității Contractante. • Produsul nu respectă întocmai cerințele clientului. Riscul este alocat atât Operatorului Economic cât și Entității Contractante, iar prin măsurile de prevenire și gestionare se va avea în vedere validarea etapelor intermediare astfel încât să se poată observa cât mai rapid orice deviație și pentru a se putea lua măsurile necesare pentru corectarea acestora. • Presiunea de a lansa în producție soluțiile într-o perioadă relativ scurtă. Presiunea de a lansa în producție soluțiile într-o perioadă relativ scurtă crește semnificativ riscurile proiectului. Aceasta va duce cu ușurință la eșec (imposibilitatea lansării la data prevăzută) și la depășiri financiare. Riscul este alocat atât Operatorului Economic cât și Entității Contractante, iar prin măsurile de prevenire și gestionare se vor avea în vedere următoarele: - o atitudine realistă privind termenul proiectului și graficele de predare - gestionarea așteptărilor Furnizorului și Beneficiarului - instituirea unui instrument de management având ca scop rezistența la presiune. • Accesul neautorizat în sistemul informatic. Riscul este alocat atât Operatorului Economic cât și Entității Contractante, iar prin măsurile de prevenire și gestionare se va avea în vedere efectuarea unei analize de securitate privind accesul în sistemul informatic. Pagina 6 din 171

• Standardele de design să nu fie specificate sau să nu fie complete. Riscul este alocat atât Operatorului Economic, iar prin măsurile de prevenire și gestionare se va avea în Vedere revizuirea standardelor de design a sistemului în faza de proiectare a acestuia”. În acest context, apreciază că motivul invocat de Entitatea Contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). Nu este descrisă arhitectura sistemului. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În evaluare acestui sub-factor de evaluare, Entitatea Contractantă trebuie să analizeze „gradul de detaliere a planului de proiect și a metodologiei de implementare” și nu să analizeze o eventuală descriere a arhitecturii sistemului. Nici Planul de proiect și nici Metodologia de implementare nu trebuie să includă descrierea arhitecturii sistemului. Metodologia de proiect descrie modul de lucru în cadrul proiectului și procedurile care trebuie aplicate în cursul implementării acestuia. În plus, susține că în caietul de sarcini, nu există nicio cerință privind descrierea arhitecturii sistemului, singura referire la „arhitectura sistemului” regăsindu-se la punctul 5.1.2.13, „Cerință administrare”, pag. 13 din Caietul de sarcini: „[...] documentația despre arhitectura sistemului, care trebuie să cuprindă: - tehnologiile folosite; - diagrama componentelor logice ale aplicației; - diagrama componentelor fizice ale soluției; - modul în care componentele sunt conectate și comunică; - protocoalele și porturile de comunicație utilizate; - interfețele de comunicare cu alte aplicații”. La cerința mai sus citată, precizează că a răspuns în „ANEXA la Formularul IV.4.1 de propunere tehnică” (pag 41-53), după cum urmează: „Contractantul va livra următoarele documente cu documentația specifică pentru administratorii de sistem: [...] - documentația despre arhitectura sistemului, care trebuie să cuprindă: - tehnologiile folosite; - diagrama componentelor logice ale aplicației; - diagrama componentelor fizice ale soluției; - modul în care componentele sunt conectate si comunică; - protocoalele și porturile de comunicație utilizate; - interfețele de comunicare cu alte aplicații”. Pagina 7 din 171

Iar detalierea răspunsului se regăsește în Anexa 3 - Metodologie de implementare Oracle (OUM). În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iii). Metodologia OUM este descrisă în termeni generali Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Astfel, societatea sa a prezentat în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, la cap 1. Metodologia de implementare OUM - (Oracle Unified Methodology), o prezentare generală a metodologiei de implementarea a sistemelor informatice și mentenanța acestora pe baza OUM - Oracle Unified Methodology (pag 3-14), apoi la cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, a prezentat detaliat Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului (pag 15-69). În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iv). Capitolele nu sunt numerotate și legătura dintre acestea se poate intui doar prin denumirea etapei. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat: În documentul Anexa 3 - Metodologia de implementare Oracle (OUM)_final.pdf, capitolele sunt numerotate, așa cum se vede din extrasul conținând cuprinsul documentului. În documentul Anexa 2 - Metodologia de management de proiect.pdf, capitolele sunt numerotate, așa cum se vede din extrasul conținând cuprinsul documentului. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. v). Planul de proiect este în mică măsură corelat cu planul GANTT, sunt diferențe majore între activități și livrabile și sunt necorelate. Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat: Conform denumirii „Subfactorului (2.1.a): Gradul de detaliere al planului de proiect și al metodologiei de implementare”, consideră că evaluarea autorității contractante trebuia să vizeze detalierea planului de proiect (planul Gantt) și al metodologiei de implementare. Pagina 8 din 171

Susține că a prezentat în cadrul ofertei depuse Planul de proiect (GANTT) (Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, la cap 1.2 Planul de implementare, 1.2.1 Graficul de tip Gantt) care conține planificarea activităților și asigură corelarea acestora cu rezultatele proiectului, cu rapoartele și livrabilele aferente, conform cerințelor din caietul de sarcini. Planul de proiect (GANTT) este conform cu abordarea și metodologia de implementare propusă (prezentata în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, pag 3-70), demonstrează înțelegerea prevederilor din Caietul de sarcini și abilitatea sa de a transpune prevederile într-un plan de lucru fezabil. Totodată, acesta asigură încadrarea activităților în timp de așa manieră încât să se asigure finalizarea serviciilor în termenele specificate în caietul de sarcini. De asemenea, în Planul de proiect (GANTT) sunt evidențiate activități care revin inclusiv SNN, de ex: i). Efectuare testare de acceptanță pe mediul de test - Faza I (linia 87 din Planul Gantt): ii). Efectuare testare de acceptanță pe mediul de test - Faza II (linia 120 din Planul Gantt) În concluzie, susține că a prezentat Planul de proiect (GANTT) și metodologia de implementare la un nivel de detaliere corespunzător care facilitează înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. vi). Activități și subactivități din planul de proiect nu se regăsesc în metodologie și GANTT Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Arată că în caietul de sarcini, entitatea contractantă a solicitat ca operatorii economici să prezinte în cadrul Metodologiei de implementare și în Planul de proiect (GANTT) o serie de activități, sub activități și livrabile. Analizând comparativ, activitățile, sub activitățile și livrabilele aferente etapelor menționate în caietul de sarcini, cu cele menționate în Metodologia de implementare și în Planul de proiect (GANTT) rezultă în mod evident că acestea sunt prezentate și corelate în mod corespunzător, fiind reflectate integral și unitar în cele trei documente menționate. Pagina 9 din 171

În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliu, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. vii). Planul de proiect conține livrabile irelevante pentru etapa de testare. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Toate livrabilele aferente etapei de testare, solicitate în caietul de sarcini, sunt evidențiate în Planul de proiect și sunt prezentate în mod corespunzător de societatea sa în Metodologia de implementare OUM. Din perspectiva sa, toate livrabilele prezentare în cadrul Planului de Proiect (GANTT) și în Metodologia de implementare OUM, inclusiv livrabilele aferente etapei de testare, sunt relevate pentru buna implementare a proiectului. Dorește să puncteze totodată faptul că, a prezentat în mod corespunzător în cadrul ofertei, toate livrabilele solicitate în cadrul caietului de sarcini, pentru etapa de testare, aceste livrabile regăsindu- se atât în Planul de proiect cât și în Metodologia de Implementare OUM, astfel: - Lvr. Planul de testare - Faza I - Lvr. Raportul cu rezultatele testării pentru Faza I - Lvr. Planul de testare de acceptanță - Faza I - Lvr. Raport testare de acceptanță - Faza I - Lvr. Planul de testare - Faza II - Lvr. Raportul cu rezultatele testării pentru Faza II - Lvr. Planul de testare de acceptanță - Faza II - Lvr. Raport testare de acceptanță - Faza II. Deoarece caietul de sarcini conține cerințe minime și obligatorii pentru operatorii economici, susține că avea obligația de a reflecta în mod corespunzător în oferta sa aceste cerințe. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei noastre cu privire la acest punct. viii). Activitatea de testare - nu conține acțiuni pentru rezolvarea problemelor la testare și nici o analiză a rezultatelor obținute și modul în care se pot rezolva. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Susține că a prezentat în detaliu în Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf (la cap ) toate activitățile de Pagina 10 din 171

testare la cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test. Pentru rezolvarea problemelor apărute în urma testării societatea sa a prezentat următoarele acțiuni: - Efectuarea de reconfigurări necesare după testarea internă pe mediul de test (linia 85 din Planul de proiect - Gantt); - Efectuarea de reconfigurări și dezvoltări necesare după testarea internă pe mediul de test (linia 118 din Planul de proiect - Gantt); Precizează că aceste acțiuni se vor efectua de către experții cheie alocați în urma unei analize a rezultatelor obținute la testare și a evaluării modalității în care se pot rezolva. În metodologia Oracle Unified Method (OUM) Capitolul 1.1.3 – „Etapa de configurare, testare și acceptanță pe mediul de test” (pag. 43 - 48), procesele de testare enumerate respectiv: - Definirea misiunii evaluării - Verificarea abordării testării - Implementarea Mediului Intern de Testare - Validarea stabilității artefactului testat - Testarea și evaluarea artefactului testat - Îndeplinirea misiunii acceptabile - Îmbunătățirea artefactelor de testare includ acțiuni explicite dedicate identificării și rezolvării problemelor apărute în timpul testării, dar nu prevăd în mod formal o etapă separată dedicată analizei detaliate a rezultatelor sau a metodelor de remediere post-testare. Mai exact: În fazele de Validare a stabilității artefactului testat și Testare și evaluare a artefactului testat, sunt realizate testele efective și sunt identificate discrepanțele sau defectele, iar în cazul unor probleme sunt inițiate acțiuni de corectare imediată asupra soluției sau artefactelor livrate. În procesul „Îmbunătățirea artefactelor de testare”, există un mecanism de ajustare a cazurilor de test, procedurilor sau scripturilor de testare, ca răspuns la problemele identificate în timpul execuției testelor. Totuși, metodologia OUM nu detaliază o activitate distinctă dedicată analizei formale a performanței sau a gradului de acoperire a testării, sau a optimizării strategice a procesului de remediere bazat pe lecțiile învățate din testare. Aceste activități sunt, de regulă, integrate implicit în ciclurile de testare - corectare - retestare, fără a exista o fază separată de tipul Test Results Analysis and Resolution Strategy întâlnită în alte metodologii de testare (ex: TMAP, ISTQB Advanced Level). În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Pagina 11 din 171

ix). În Gantt nu sunt asigurați responsabilii pe elaborarea livrabilelor Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În Planul de proiect - Gantt, pentru toate activitățile societatea sa a desemnat responsabili pentru realizarea activităților și subactivităților în cauză. Livrabilele sunt rezultatul activităților aferente fiecărei etape /subetape. Responsabilii livrabilelor sunt aceiași cu responsabilii activităților aferente. Cu titlu de exemplu: - Linia 42 din Graficul de proiect (GANTT) activitatea „Design soluție optimizată și upgrade- ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)” aflată în responsabilitatea Specialistului în implementarea de tehnologii Oracle EBS HCM 2, are ca rezultat - livrabilul „Lvr. Documentația despre arhitectura sistemului - Faza I” (Liniile 44-46 din GANTT), rezultând în mod neechivoc faptul că acest livrabil este realizat de Specialistul în implementarea de tehnologii Oracle EBS HCM 2. În acest context, menționarea specialiștilor responsabili atât pentru activitatea din Graficul de proiect GANTT cât și pentru livrabilul/livrabilele rezultat/rezultate ar fi fost redundantă. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. x). Referitor la liniile 42 și 73 din Gantt - nu este menționat decât expertul Specialist ORACLE EBS HCM, fără a fi implicat și expertul Architect de sistem ORACLE EBS. Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În Planul de proiect - graficul Gantt, pentru activitățile: i) Design soluție optimizată ți upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)” (Linia 42) și ii) „Actualizarea sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR” (Linia 73) este alocat Specialistul în implementarea de tehnologii Oracle EBS HCM 2 și nu este nevoie de alocarea Arhitectului de sistem Oracle EBS, deoarece: Pagina 12 din 171

- Activitățile sunt operaționale, nu de arhitectură: Upgrade-ul de sistem de operare și actualizarea versiunii de produs presupun operațiuni tehnice standardizate și nu implică modificări ale arhitecturii generale a soluției Oracle EBS. Specialistul are competențele necesare: Specialistul Oracle EBS HCM deține toate certificările și experiența practică necesară atât pentru operațiunile de upgrade OS (Oracle Linux), cât și pentru actualizarea aplicației Oracle HR, fără a necesita intervenția unui arhitect. - Fără schimbări în infrastructura sau topologia sistemului: Activitățile de upgrade nu implică redesenarea infrastructurii, schimbări de integrare sau repoziționări de sisteme — sarcini care ar justifica implicarea unui arhitect. - Procedură de upgrade deja aprobată: Există o metodologie validată de upgrade și actualizare, acceptată anterior în cadrul organizației, ceea ce înseamnă că nu este necesară o nouă analiză arhitecturală. - Optimizarea costurilor și eficienței: Implicarea suplimentară a unui Arhitect de sistem ar crește costurile și complexitatea activităților fără un beneficiu tehnic justificabil, întrucât specialistul poate acoperi integral cerințele upgrade-ului. În concluzie, precizează că activitățile de upgrade ale sistemului de operare Oracle Linux și actualizare a versiunii produsului Oracle Human Resources sunt strict operaționale și nu presupun modificări de arhitectură sau infrastructură IT. Specialistul în implementarea de tehnologii Oracle EBS HCM deține competențele necesare pentru realizarea acestor sarcini, iar implicarea suplimentară a unui Arhitect de sistem nu este justificată, evitând astfel alocarea ineficientă de resurse și costuri suplimentare. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. xi). Etapele din GANTT sunt prezentate consecutiv și nu în ordinea cronologică, adică să fie prezentate activitățile pentru Faza 1, după care activitățile pentru Faza 2. Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat. Contestatorul susține că entitatea contractantă nu a solicitat prin caietul de sarcini ca modalitatea de prezentare a etapelor din Planul de proiect - Gantt, să fie în ordine cronologică sau consecutivă. În acest context, alegerea modalității de prezentare a Planului de proiect (GANTT) este la latitudinea operatorilor economici ofertanți. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale Pagina 13 din 171

de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. xii). Nu sunt metionati expertii suplimentari (non cheie) pe activitațile și livrabile din Plan + GANTT Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Cu privire la acest aspect arată că în caietul de sarcini entitatea contractantă a solicitat ofertanților prezentarea următorilor experți (cheie) (pag. 6 din caietul de sarcini): 1. Manager de proiect (1 expert) 2. Analist de business HR (1 expert) 3. Arhitect de sistem Oracle EBS (1 expert) 4. ......... baze de date Oracle (1 expert) 5. Specialist în implementarea de tehnologii Oracle EBS HCM (2 experți). Totodată, la pagina 7 din caietul de sarcini, aceasta a precizat următoarele: „Operatorul economic are libertatea de a dimensiona structural și numeric această echipă astfel încât să se asigure că poate să respecte condițiile impuse prin cerințele proiectului pe durata contractului, dar nu mai puțin de cei 6 experți-cheie listați mai sus”. În secțiunea IV.4.1.a Anexa la propunere tehnica_final.pdf, la cap 24.2 Riscuri pag 261-262, contestatorul susține că a prezentat următoarele riscuri: 24.2.1 Indisponibilitatea experților-cheie propuși în Ofertă 24.2.2 Neîndeplinirea obligațiilor contractuale de către Prestatorul selectat 24.2.6 Gradul mare de funcționalități custom necesare implementării cerințelor incluse în prezentul Caiet de Sarcini. Ca măsuri de prevenire și gestionare a acestor riscuri susține că a alocat pe lângă experții cheie și o serie de experți non-cheie. Precizează că va utiliza experții non-cheie numai dacă riscurile identificare mai sus se vor materializa. În acest caz societatea sa va actualiza planul de proiect- Gantt, cu evidențierea și a experților non- cheie pe activitățile necesare. În acest context, experții non cheie nu au fost menționați clar în Planul de proiect (Gantt) pe fiecare activitate, deoarece la momentul ofertării riscurile nu s-au materializat. Față de cele de mai sus, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. xiii). Nu sunt prezentate activitățile care revin personalului SNN Pagina 14 din 171

Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În planul de proiect (Gantt) susține că a evidențiat, pe lângă activitățile aflate în sarcina personalului propriu, și activități care revin personalului SNN. Cu titlu de exemplu menționează: i). Efectuare testare de acceptanță pe mediul de test - Faza I (linia 87 din Planul Gantt) ii). Efectuare testare de acceptanță pe mediul de test - Faza II (linia 120 din Planul Gantt) În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Subfactor (2.1.b) corelarea planului de proiect cu cerințele din caietul de sarcini: „Exista corelare între cerințele și livrabilele solicitate prin caietul de sarcini si planul de proiect propus (Foarte bine - 5 puncte)”. „Exista corelare cu deviații minore între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus. (Bine - 3 puncte)”. „Corelarea între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus este cu deviații majore. (Acceptabil - 1 punct)”. Motivele invocate de entitatea contractantă pentru acordarea punctajului. i). Documentația de Baza de date și Documentația de Arhitectură a sistemului nu sunt livrabile aferente Fazei 1. Acestea sunt identice cu cele din Faza 2. ii). Experții suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat. iii). Planul de proiect face referire plan de integrare versiuni fără corespondență în CS și GANTT. iv). Planul de proiect conține roluri suplimentare pentru testare fără corespondență în GANTT și CS. v). Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție. Motivare contestație: i). Documentația de Baza de date și Documentația de Arhitectură a sistemului nu sunt livrabile aferente Fazei 1. Acestea sunt identice cu cele din Faza 2. Pagina 15 din 171

Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În Planul de proiect (GANTT) a menționat atât la Faza I cât și la Faza II livrabilele aferente pentru Baza de date și Arhitectura, astfel: i). Faza I. Subfactor planului de proiect cu cerințele din caietul de sarcini: Lvr. Documentația despre arhitectura sistemului - Faza I (linia 45 din Planul de proiect - Gantt), Lvr. Documentația bazei de date - faza I (linia 46 din Planul de proiect - Gantt). ii). Faza II. Lvr. Documentația despre arhitectura sistemului - Faza II (linia 62 din Planul de proiect - Gantt). Lvr. Documentația bazei de date - faza II (linia 63 din Planul de proiect - Gantt). Motivul pentru care Livrabilele privind arhitectura sistemului și baza de date au fost identificate separat pentru Faza I și Faza II, este că, pentru fiecare fază în parte se solicită realizarea unei etape de analiză separată cu potențial impact asupra documentației subsecvente (inclusiv documentația de arhitectură a sistemului respectiv a bazei de date), așa cum se solicită și în caietul de sarcini la Capitolul 6 (pag. 35), unde se menționează următoarele: „Fiecare dintre cele 2 faze ale implementării va presupune cel puțin următoarele etape: - analiză procese și funcționalități (maxim 2 luni la începutul fazei de implementare); - configurare, testare și acceptanță pe mediul de test; - trecere în producție”. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). Experții suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În caietul de sarcini entitatea contractantă a solicitat ofertanților prezentarea următorilor experți (cheie) (pag. 6 din caietul de sarcini): 1. Manager de proiect (1 expert) 2. Analist de business HR (1 expert) 3. Arhitect de sistem Oracle EBS (1 expert) 4. ......... baze de date Oracle (1 expert) Pagina 16 din 171

5. Specialist în implementarea de tehnologii Oracle EBS HCM (2 experți). Totodată, la pagina 7 din caietul de sarcini, aceasta a precizat următoarele: „Operatorul Economic are libertatea de a dimensiona structural și numeric această echipă astfel încât să se asigure că poate să respecte condițiile impuse prin cerințele proiectului pe durata contractului, dar nu mai puțin de cei 6 experți-cheie listați mai sus”. În secțiunea IV.4.1.a Anexa la propunere tehnica_final.pdf, la cap 24.2 Riscuri pag 261-262, contestatorul precizează că a prezentat următoarele riscuri: 24.2.1 Indisponibilitatea experților-cheie propuși în Ofertă 24.2.2 Neîndeplinirea obligațiilor contractuale de către Prestatorul selectat 24.2.6 Gradul mare de funcționalități custom necesare implementării cerințelor incluse în prezentul Caiet de Sarcini. Ca măsuri de prevenire și gestionare a acestor riscuri societatea sa a alocat pe lângă experții cheie și o serie de experți non-cheie. Susține că va utiliza experții non-cheie numai dacă riscurile identificare mai sus se vor materializa. În acest caz societatea va actualiza planul de proiect- Gantt, cu evidențierea și a experților non- cheie pe activitățile necesare. În acest context, experții non cheie nu au fost menționați clar în Planul de proiect (Gantt) pe fiecare activitate, deoarece la momentul ofertării riscurile nu s-au materializat. Suplimentar, menționează faptul că, referitor la acest aspect, entitatea contractantă a procedat în mod nejustificat la depunctarea ofertei sale atât pentru subfactorul 2.1 a) cât și pentru prezentul subfactor 2.1 b). În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliu, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iii). Planul de proiect face referire plan de integrare versiuni fără corespondență în CS și GANTT. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Precizează că Planul de integrare a versiunilor la care face referire entitatea contractantă se regăsește în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf (metodologia de implementare) și nu în planul de proiect, la procesele: - Integrarea componentelor în sub-sisteme (pagina 40) - Integrarea sub-sistemelor la nivelul sistemului (pagina 40) - Instalarea și configurarea soluției (Deployment) (pagina 41) Pagina 17 din 171

- Dezvoltarea planului de implementare (pagina 42), este un document intern (apare ca o intrare în procesele specificate mai sus), utilizat de Ofertant în conformitate cu Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului. De asemenea, susține că Planul de integrare a versiunilor nu este un livrabil în cadrul proiectului, este doar un document intern utilizat de Ofertant, conform Metodologiei de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului, astfel încât acesta nu este prezentat în Planul de proiect - graficul Gantt și nici în caietul de sarcini. În Planul de proiect – Gantt, precizează că sunt specificate livrabilele solicitate în CS. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iv). Planul de proiect conține roluri suplimentare pentru testare fără corespondență în GANTT și CS. Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Rolurile suplimentare pentru testare se regăsesc în Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului. Astfel în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.docx, la cap 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test, pe lângă experții cheie solicitați, sunt prezentate și alte roluri precum: - Managerul de testare - Analist de Testare - Designer de Testare - Proiectantul de Testare - Tester - Manager Configurație. Precizează că aceste roluri prezentate în Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului pot fi asimilate experților non-cheie. Totodată arată că în Planul de proiect -Gantt sunt menționați doar experții cheie pe activitățile proiectului, așa cum au fost solicitați în CS, astfel încât planul de proiect este corelat cu cerințele din caietul de sarcini. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale Pagina 18 din 171

de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. v). Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Contestatorul precizează că activitățile de instruire sunt planificate a fi realizate în Planul de proiect înainte de finalizare etapei de punere în producție: (a se vedea activitățile de la liniile 163-166 din Planul de proiect (Gantt.) Prin urmare, sesiunile de instruire aferente fazei I sunt planificate a fi susținute astfel: - Susținere 1 sesiune pentru administratorii de sistem (soluția Oracle HR Core extinsă și integrări): 30.07.2025 - 05.08.2025; - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă și rapoarte) pentru CNE Cernavodă: 06.08.2025 - 12.08.2025; - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă si rapoarte) pentru SNN Sediul Central .........: 13.08.2025 - 19.08.2025 - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă și rapoarte) pentru FCN Pitești: 20.08.2025 - 26.08.2025, iar jalonul de punere în producție pentru faza I este: - Acceptanță etapa Trecere în producție - Faza I: 29.08.2025. După cum se poate observa de mai sus, sesiunile de instruire aferente fazei I se vor realiza înainte de punerea în producție. În acest context, apreciază că motivul invocat de Entitatea Contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Subfactor (2.1.c): corelarea planului de proiect cu metodologia de management de proiect: „Există corelare între planul de proiect și metodologia utilizată în cadrul proiectului. (Foarte bine - 5 puncte)” „Exista corelare cu deviații minore între planul de proiect cu metodologia utilizata în cadrul proiectului. (Bine - 3 puncte)” „Corelarea între planul de proiect și metodologia utilizată în cadrul proiectului este cu deviații majore. (Acceptabil - 1 punct)”. Motivele invocate de Entitatea Contractantă pentru acordarea punctajului. i). Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general. Pagina 19 din 171

ii). Activitățile din GANTT nu sunt în ordine cronologică, adică activitatea de instruire este după activitate de punere în producție. iii). Nu este marcat corect drumul critic. Doar activitatea de management de proiect este singura critică. iv). Metodologia de management de proiect este prezentată in cap. 3.3.8 din Oferta tehnică (Anexa 2 la aceasta) dar riscurile specifice nu sunt tratate în planul de proiect. i). Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Precizează că Planul de proiect pentru realizarea serviciilor - planificarea activităților și Graficul implementării prezentat anterior asigura corelarea activităților cu rezultatele Contractului, cu rapoartele și livrabilele, conform cerințelor din caietul de sarcini. Planul de proiect propus este conform cu abordarea și metodologia propusă, demonstrează înțelegerea prevederilor din Caietul de sarcini, abilitatea de a transpune prevederile într-un plan de lucru fezabil. Planul de proiect propus asigură încadrarea activităților în timp de așa manieră încât să se asigure finalizarea serviciilor în termenele specificate în caietul de sarcini. Contestatorul susține că a prezentat: - Planul de proiect pentru realizarea serviciilor - planificarea activităților și Graficul implementării (prezentat în ofertă în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, la cap 1.2 Planul de implementare, 1.2.1 Graficul de tip Gantt) asigură corelarea activităților cu rezultatele contractului, cu rapoartele și livrabilele, conform cerințelor din caietul de sarcini. - Planul de proiect propus (prezentat în ofertă în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, la cap 1.2 Planul de implementare, 1.2.1 Graficul de tip Gantt) este conform cu abordarea și metodologia de implementare propusă (prezentata în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.pdf, pag 3-70), demonstrează înțelegerea prevederilor din caietul de sarcini, abilitatea de a transpune prevederile într-un plan de lucru fezabil. - Planul de proiect propus asigura încadrarea activităților în timp de așa manieră încât să se asigure finalizarea serviciilor în termenele specificate în caietul de sarcini. - Planul de proiect și graficul Gantt au fost elaborate în conformitate cu metodologia de management de proiect adoptată (ex.: PMBOK), astfel încât să asigure o planificare structurată, controlabilă și predictibilă a execuției proiectului. Corelarea se realizează astfel: Pagina 20 din 171

- Structurarea activităților pe faze și procese: Activitățile din Gantt sunt organizate pe etape principale (Inițiere, Planificare, Execuție, Monitorizare și Control, Închidere), reflectând fazele ciclului de viață al proiectului așa cum sunt definite în metodologie. - Definirea clară a livrabilelor: Fiecare activitate sau grup de activități din Gantt este asociată cu livrabile concrete, conform principiului de management al proiectelor bazat pe livrabile (deliverable- based planning). - Stabilirea relațiilor de dependență: Relațiile Finish-to-Start între activități respectă logica secvențială a proceselor de management de proiect (ex.: analiza trebuie să preceadă proiectarea, proiectarea trebuie să preceadă dezvoltarea, testarea trebuie să urmeze dezvoltării). - Planificarea punctelor de control și a livrabilelor intermediare: Gantt-ul integrează momente cheie de validare (ex.: Review de analiză, Aprobare proiectare, UAT - User Acceptance Testing), în conformitate cu practicile de Monitorizare și Control specificate de metodologia de proiect. - Asigurarea trasabilității între procesele de planificare și execuție: Planul Gantt include activități specifice de management de proiect (ex.: actualizare plan de proiect, managementul riscurilor, raportări de progres), asigurând implementarea continuă a metodologiei și nu doar a livrabilelor tehnice. Astfel, graficul Gantt nu este doar o succesiune de activități tehnice, ci un instrument de lucru integrat în procesul de management al proiectului, sprijinind atingerea obiectivelor printr-o planificare aliniată metodologic. Structura și logica planului de proiect (Gantt) reflectă aplicarea metodologiei de management de proiect adoptate, asigurând alinierea activităților la fazele ciclului de viață al proiectului, trasabilitatea livrabilelor și controlul eficient al progresului. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). Activitățile din GANTT nu sunt în ordine cronologică, adică activitatea de instruire este după activitate de punere în producție. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Contestatorul precizează că activitățile de instruire sunt planificate a fi realizate în Planul de proiect înainte de finalizare etapei de punere în producție (a se vedea activitățile de la liniile 163-166 din planul de proiect-graficul Gantt). Astfel, sesiunile de instruire aferente fazei I sunt planificate a fi susținute astfel: Pagina 21 din 171

- Susținere 1 sesiune pentru administratorii de sistem (soluția Oracle HR Core extinsă si integrări): 30.07.2025 - 05.08.2025 - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă și rapoarte) pentru CNE Cernavodă: 06.08.2025 - 12.08.2025, - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă si rapoarte) pentru SNN Sediul Central .........: 13.08.2025 - 19.08.2025, - Susținere sesiune pentru administratorii de aplicație (soluția Oracle HR Core extinsă și rapoarte) pentru FCN Pitești: 20.08.2025 - 26.08.2025, iar jalonul de punere în producție pentru faza I este: - Acceptanță etapa Trecere în producție - Faza I: 29.08.2025. Arată că după cum se poate observa de mai sus, sesiunile de instruire aferente fazei I se vor realiza înainte de punerea în producție. Activitățile de instruire sunt planificate a fi realizate în Planul de proiect înainte de finalizare etapei de punere în producție: a se vedea activitățile de la liniile 180-189 din planul de proiect-graficul Gantt. Astfel, sesiunile de instruire aferente fazei II sunt planificate a fi susținute astfel: - Susținere 1 sesiune pentru administratorii de sistem (module noi și integrări): 19.05.2026 - 25.05.2026, - Susținere sesiune pentru administratorii de aplicație (module noi și rapoarte) pentru CNE Cernavodă): 26.05.2026 - 01.06.2026, - Susținere sesiune pentru administratorii de aplicație (module noi și rapoarte) pentru SNN Sediul Central .........: 02.06.2026 - 08.06.2026, - Susținere sesiune pentru administratorii de aplicație (module noi și rapoarte) pentru FCN Pitești: 09.06.2026 - 15.06.2026, - Susținere sesiune pentru rolurile speciale(pentru rolurile de gestionare conflict de interese, responsabil de gestionarea informărilor și acordurilor privind prelucrarea datelor cu caracter personal, responsabil audit GDPR etc) pentru CNE Cernavodă: 16.06.2026 - 22.06.2026, - Susținere sesiune pentru rolurile speciale(pentru rolurile de gestionare conflict de interese, responsabil de gestionarea informărilor și acordurilor privind prelucrarea datelor cu caracter personal, responsabil audit GDPR etc) pentru FCN Pitești: 23.06.2026 - 29.06.2026, - Susținere sesiune pentru rolurile speciale(rolurile de gestionare conflict de interese, responsabil de gestionarea informărilor și acordurilor privind prelucrarea datelor cu caracter personal, responsabil audit GDPR etc) pentru SNN Sediul Central .........: 30.06.2026 - 06.07.2026, - Susținere sesiune „train the trainer” (funcționalități ale modulelor noi pentru utilizatori: Self-Service, Pontaj, Evaluarea Performanțelor) pentru CNE Cernavodă: 13.07.2026, Pagina 22 din 171

- Susținere sesiune „train the trainer” (funcționalități ale modulelor noi pentru utilizatori: Self- Service, Pontaj, Evaluarea Performanțelor) pentru SNN Sediul Central .........: 14.07.2026 - 20.07.2026, - Susținere sesiune „train the tra iner” (funcționalități ale modulelor noi pentru utilizatori: Self-Service, Pontaj, Evaluarea Performanțelor) pentru FCN Pitești: 27.07.2026, iar jalonul de punere în producție pentru faza II este: - Acceptanță etapa Trecere în producție - Faza II: 30.07.2026. Arată că după cum se poate observa din cele de mai sus, sesiunile de instruire aferente fazei II se vor realiza înainte de punerea în producție. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iii). Nu este marcat corect drumul critic. Doar activitatea de management de proiect este singura critica. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Precizează că Drumul critic este evidențiat corect în Planul de proiect (GANTT). De asemenea arată că nu este o cerință din partea autorității contractante de evidențiere a drumului critic. Evidențierea sau nu a drumului critic nu este un criteriu relevant în contextul evaluării Subfactorului 2.1.c - Corelarea planului de proiect cu metodologia de management de proiect. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iv). Metodologia de management de proiect este prezentată in cap. 3.3.8 din Oferta tehnică (Anexa 2 la aceasta) dar riscurile specifice nu sunt tratate in planul de proiect. Consideră ca în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Observația entității contractante nu este relevantă în contextul evaluării Subfactorului 2.1.c - Corelarea planului de proiect cu metodologia de management de proiect. Planul de proiect (GANTT) nu conține tratarea riscurilor ci activități, livrabile, jaloane, etc. In documentul Anexa 2 - Metodologia de management de proiect.pdf, subscrisa am prezentat Metodologia de management a riscului la cap. 3.3.8 Managementul Riscului. Pagina 23 din 171

Societatea sa a tratat riscurile specifice în documentul IV.4.1.a Anexa la propunere tehnica_final.pdf la Cap 24.2 Riscuri (pag 261-266). Astfel, susține că societatea sa a luat la cunoștință și și-a asumat riscurile cu cea mai mare probabilitate de apariție în perioada derulării contractului, identificate de către entitatea contractantă în etapa de pregătire a documentației de atribuire, în vederea gestionării acestora. De asemenea susține că a detaliat în documentul specificat mai sus recomandări și propuneri de reducere sau eliminare a riscurilor cu cea mai mare probabilitate de apariție în perioada derulării contractului, identificate de către entitatea contractantă în etapa de pregătire a documentației de atribuire. Mai mult, susține că a identificat și a prezentat în documentul specificat mai sus și alte riscuri împreună cu recomandările și propunerile de reducere sau eliminare a riscurilor care ar putea afecta implementarea serviciilor. Subfactor (2.1.d): realismul planului prin corelarea efortului estimat cu complexitatea activităților: „Duratele activităților detaliate în planul de proiect sunt corespunzătoare complexității activităților și sunt în mod realist estimate. (Foarte bine - 5 puncte)”. „Duratele activităților detaliate în planul de proiect sunt parțial corelate cu complexitatea activităților și sunt parțial realist estimate. (Bine - 3 puncte)”. „Duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate. (Acceptabil - 1 punct)”. Motivele invocate de Entitatea Contractantă pentru acordarea punctajului. i). Estimarea duratelor activităților nu este realistă. ii). În planul de proiect avem analiza pentru Faza 2 în 2 luni, desfășurarea etapelor fiind prezentată secvențial. iii). Etapa de analiza pentru pontaje este de 4 zile. iv). Realizare upgrade Oracle pentru Faza 1 - 4 zile. v). Durata trecerii în producție nu este corect dimensionată și nu include activități de pregătire a personalului SNN. vi). Planul de proiect nu prezintă toate resursele implicate, ci doar experții cheie. vii). Nu sunt prezentate rolurile și sarcinile personalului SNN. Motivarea contestației: i). Estimarea duratelor activităților nu este realistă. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa, după cum va arăta în continuare. În opinia sa, afirmația autorității contractante este subiectivă și nu se bazează pe o analiză temeinică în acest sens. Pagina 24 din 171

Susține că a ținut cont în estimarea activităților proiectului de următoarele: - analiză detaliată a cerințelor din caietul de sarcini, - expertiza și experiența în proiecte și activități similare cu cel curent și datele istorice relevante, - nivelul real de dificultate al fiecărei activități aferente etapelor proiectului și eventualele probleme tehnice care pot apărea, - riscurile cu cea mai mare probabilitate de apariție în perioada derulării Contractului, identificate de către entitatea contractantă în etapa de pregătire a documentației de atribuire, - alte riscuri identificate de Ofertant, împreună cu recomandările și propunerile de reducere sau eliminare a riscurilor care ar putea afecta implementarea serviciilor, - estimarea a fost efectuată de manager de proiect și experți cu suficientă experiență în proiecte similare care au folosit metode de estimare recunoscute (precum PERT, Three-Point Estimation). - compararea cu activități similare în proiecte trecute. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca, prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). În planul de proiect avem analiza pentru Faza 2 în 2 luni, desfășurarea etapelor fiind prezentată secvențial. Consideră că, în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat. Susține că a prezentat secvențial desfășurarea etapelor în Planul de proiect (Gantt). Prezentarea secvențială a activităților într-un plan de proiect are mai multe avantaje clare față de prezentarea în paralel. Avantaje ale prezentării secvențiale: - Claritate mai mare a dependențelor: Se vede ușor ce activitate depinde de alta și în ce ordine trebuie făcute lucrurile. - Reducerea riscului de erori: Este mai puțin probabil să începi activități fără ca cele necesare înaintea lor să fie terminate. - Monitorizare și control mai ușor: Managerul de proiect poate urmări progresul pas cu pas și poate interveni rapid dacă apare o întârziere. - Planificare mai realistă a resurselor: Resursele (oameni, echipamente) pot fi alocate eficient, știind exact când sunt necesare. - Gestionarea mai bună a riscurilor: Se pot identifica din timp punctele critice (momentele unde dacă întârzii o activitate, întârzii tot proiectul). - Mai bună comunicare între echipe: Fiecare echipă știe clar când să înceapă munca și pe ce se bazează. Pagina 25 din 171

- Simplificarea ajustărilor: Dacă apare o schimbare (de ex., întârziere sau problemă), e mai ușor să ajustezi planul, pentru că vezi legăturile dintre activități. În opinia sa în comparație, prezentarea în paralel poate crea impresia că mai multe activități pot fi făcute simultan fără probleme, ceea ce poate duce la: - Confuzie în prioritizarea task-urilor, - Concurență pe aceleași resurse, - Riscuri nedeclarate sau greu de gestionat, - Lipsă de coordonare și suprapuneri inutile. Societatea sa a ales această modalitate de implementare, tocmai pentru a evita eventualele riscuri (mai sus descrise) ce ar putea conduce la decalarea semnificativă a termenului de implementare ceea ce este în beneficiul proiectului și al entității contractante. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca, prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iii). Etapa de analiză pentru pontaje este de 4 zile. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Consideră că afirmația autorității contractante este subiectivă și nu se bazează pe o analiză temeinică în acest sens. Societatea sa a alocat experți Analist de business HR cu experiență foarte mare pentru realizarea acestei activități. Astfel, activitatea „Analiza cerințelor funcționale modul Pontaj (evidența timpului lucrat și a orelor nelucrate, planificare timp lucrat și ore nelucrate, listă predefinită pontaj, cerere concediu, notă de chemare, bilet de voie, muncă la distanță, modificare program de lucru,)” poate fi realizată în 4 zile de cei 2 Analist de business HR: - Distribuirea sarcinilor: Activitatea de analiză a fost împărțită în mod eficient între cei doi experți, fiecare concentrându-se pe un set clar de cerințe sau procese, reducând timpul total necesar. - Nivel ridicat de experiență: Cei doi analiști au experiență relevantă în proiecte similare, ceea ce le permite să înțeleagă rapid cerințele și să evite perioade lungi de documentare sau clarificare. - Metodologie de lucru bine definită: Se aplică o metodologie de analiză standardizată (ex: Agile user stories, BPMN pentru procese), care reduce timpul necesar pentru colectarea și modelarea informațiilor. - Acces facil la stakeholderi și informații: Datele și persoanele cheie pentru procesul de analiză sunt deja disponibile și accesibile, evitând blocaje de comunicare sau întârzieri. Pagina 26 din 171

- Claritatea domeniului analizat: Domeniul/proiectul este bine cunoscut de către analiști sau documentația existentă este completă, deci analiza nu pleacă „de la zero”. - Colaborare eficientă între analiști: Cei doi analiști au colaborat anterior și au un flux de lucru bine sincronizat, eliminând timpii morți sau suprapunerile inutile. În opinia sa estimarea de 4 zile pentru desfășurarea activității de analiză de către doi analiști de business este realistă datorită împărțirii eficiente a sarcinilor, experienței anterioare relevante a acestora în proiecte similare și disponibilității imediate a stakeholderilor și a documentației necesare. Aplicarea unei metodologii standardizate de colectare și modelare a cerințelor asigură desfășurarea rapidă și eficientă a activității. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca, prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iv). Realizare upgrade Oracle pentru Faza 1 - 4 zile. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Consideră că afirmația autorității contractante este subiectivă și nu se bazează pe o analiză temeinică în acest sens. Societatea sa a alocat experți Specialist în implementarea de tehnologii Oracle EBS HCM (Iulia Calistrate) cu experiența foarte mare pentru realizarea acestei activități în 2 zile. Astfel, activitatea „Design soluție optimizată și upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)” poate fi realizată în 2 zile de Specialistul în implementarea de tehnologii Oracle EBS HCM: - Nivelul de specializare al expertului: Specialistul are experiență vastă și certificări în Oracle EBS HCM și în operațiuni de upgrade ale Oracle Linux, ceea ce permite o execuție rapidă și fără etape de învățare suplimentară. - Proceduri de upgrade bine definite: Procesul de upgrade pentru sistemul de operare și produsul Oracle HR este standardizat și documentat, reducând semnificativ timpul de implementare. - Există infrastructură pregătită: Mediile hardware și software necesare pentru testare și upgrade sunt deja disponibile și configurate corespunzător, fără necesitatea unor etape suplimentare de setup. - Intervenție limitată asupra funcționalității aplicației: Actualizarea versiunii Oracle HR implică modificări tehnice controlate, fără impact major asupra customizărilor existente, deci fără necesitatea unor teste complexe de regresie în această fază. Pagina 27 din 171

- Experiență anterioară cu versiuni similare: Specialistul a efectuat anterior operațiuni similare de upgrade pentru Oracle Linux și Oracle EBS HCM, deci este familiarizat cu eventualele probleme și știe să le anticipeze. - Colaborare eficientă cu echipele conexe: Colaborarea cu echipele de infrastructură, DBA și suport aplicativ este deja stabilită, ceea ce reduce timpii de așteptare sau coordonare. Activitatea de „Design soluție optimizată și upgrade a sistemului Oracle Linux și Oracle Human Resources”, consideră că este estimată realist la 2 zile de către Specialistul în implementarea de tehnologii Oracle EBS HCM, având în vedere experiența anterioară a acestuia în upgrade-uri similare, existența unor proceduri operaționale clare și infrastructura deja pregătită pentru implementare. Procesul presupune pași standardizați cu risc redus de blocaje neprevăzute. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca, prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. v). Durata trecerii în producție nu este corect dimensionată și nu include activități de pregătire a personalului SNN. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Consideră că afirmația autorității contractante este subiectivă și nu se bazează pe o analiză temeinică în acest sens. Durata planificată a etapei de tecere în producție - Faza I, în opinia sa este corect dimensionată având în vedere complexitatea și natura critică a activităților incluse: - Livrare și activare licențe Oracle - 1 zi: Procesul de livrare și activare a licențelor presupune verificarea compatibilității licențelor cu mediile de producție și DR, configurarea acestora și validarea funcționalității, activități care se pot realiza într-o zi cu resursele alocate. - Instalare pe mediile de producție și DR a versiunii finale a soluției - 7 zile: Instalarea soluției în două medii critice (producție și Disaster Recovery) implică: - Implementarea aplicațiilor și serviciilor configurate, - Validarea integrării cu sistemele existente, - Realizarea testelor funcționale și de performanță post-instalare. Având în vedere cerințele de redundanță și necesitatea sincronizării exacte între cele două medii, durata de 7 zile este realistă și necesară pentru a asigura implementarea corectă și fără riscuri. - Verificare livrabile și servicii - 2 zile: Această activitate presupune: Pagina 28 din 171

- Revizuirea tuturor livrabilelor (documentație, configurări, rapoarte de testare), - Validarea implementării serviciilor și soluțiilor în mediile de producție și DR, - Întocmirea rapoartelor de conformitate și remedierea eventualelor neconformități minore. - Semnare proces verbal de recepție etapa Trecere în producție - Faza I- 1 zi: Această zi este rezervată activităților de finalizare formală: revizuirea documentației finale, semnarea procesului verbal de recepție, remedierea eventualelor observații minore. În cadrul acestei etape, este planificată și instruirea personalului SNN asupra: - noii versiuni a soluției instalate - procedurilor operaționale post-go-live - măsurilor de escaladare în caz de incidente. Contestatorul precizează că activitățile de instruire a personalului SNN sunt integrate în etapa de Trecere în producție - Faza I și sunt realizate prin metoda de shadowing al experților Implementatorului. Această abordare practică permite personalului SNN să observe direct procesele de instalare, configurare și verificare a soluției, să înțeleagă procedurile operaționale și să se familiarizeze cu specificul noii versiuni implementate. Prin participarea activă la activitățile de producție, personalul SNN beneficiază de o instruire contextualizată, eficientă și imediat aplicabilă, fără a necesita sesiuni suplimentare dedicate, optimizând astfel durata generală a etapei de trecere în producție. Această metodă asigură o tranziție eficientă a cunoștințelor și pregătește echipa SNN pentru operarea independentă a sistemului după finalizarea implementării. Instruirea prin shadowing minimizează timpul pierdut cu traininguri teoretice și maximizează asimilarea practică, personalul SNN va putea prelua rapid responsabilitățile post-go-live. Această abordare asigură și un transfer de know-how real, adaptat exact soluției și infrastructurii SNN. Durata de 9 zile alocată pentru etapa de Trecere în producție - Faza II, consideră că este corect dimensionată, având în vedere structura și complexitatea activităților planificate: - Livrare și activare licențe Oracle - 1 zi: Livrarea și activarea licențelor aferente fazei II pentru mediile de producție și DR presupune proceduri bine definite și validate în etapa anterioară, cu un grad redus de risc, justificând o durată de o zi. - Instalare pe mediile de producție și DR a versiunii finale - 5 zile; Instalarea implică: - Configurarea și aplicarea versiunii finale a soluției, - Verificarea integrărilor cu sistemele existente, Pagina 29 din 171

- Testarea funcționalităților critice în ambele medii (producție și DR). Durata de 5 zile reflectă volumul de muncă estimat și necesitatea desfășurării activităților într-un mod controlat și etapizat, minimizând riscurile de întrerupere a serviciilor. - Verificare livrabile și servicii - 2 zile Se realizează: - Validarea completă a instalărilor, - Confirmarea funcționalității și integrității soluției, - Verificarea respectării cerințelor de livrare. - Semnare proces-verbal de recepție - 1 zi: Această zi este rezervată activităților de finalizare formală: revizuirea documentației finale, semnarea procesului verbal de recepție, remedierea eventualelor observații minore. Pe parcursul activităților de instalare și verificare, personalul desemnat de SNN participă direct, prin shadowing, la toate operațiunile desfășurate de echipa Implementatorului: - Observă procedurile de implementare și verificare, - Își însușește cunoștințele necesare pentru operarea și mentenanța soluției în producție, - Se familiarizează cu intervențiile și scenariile de remediere în caz de incidente. Această abordare permite integrarea eficientă a instruirii în activitățile tehnice, fără a prelungi durata totală a fazei. În concluzie, durata de 9 zile aferentă etapei de Trecere în producție - Faza II este fundamentată pe complexitatea activităților necesare și pe principiile unei implementări controlate și sigure. Etapa include activități de livrare și activare licențe, instalare a soluției în medii de producție și DR, verificare completă a livrabilelor, precum și semnarea procesului verbal de recepție. Pe parcursul activităților de instalare și verificare, personalul SNN este instruit prin metoda de shadowing, participând direct la operațiuni pentru a asigura preluarea eficientă a cunoștințelor operaționale și administrative, fără a afecta durata planificată a etapei. Această abordare optimizează tranziția către utilizarea independentă a soluției, asigurând sustenabilitatea rezultatelor implementării. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. vi). Planul de proiect nu prezinta toate resursele implicate, ci doar experții cheie. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Pagina 30 din 171

În acest sens arată că în caietul de sarcini entitatea contractantă a solicitat ofertanților prezentarea următorilor experți (cheie) (pag. 6 din caietul de sarcini): 1. Manager de proiect (1 expert) 2. Analist de business HR (1 expert) 3. Arhitect de sistem Oracle EBS (1 expert) 4. ......... baze de date Oracle (1 expert) 5. Specialist în implementarea de tehnologii Oracle EBS HCM (2 experți). Totodată, la pagina 7 din caietul de sarcini, aceasta a precizat următoarele: „Operatorul Economic are libertatea de a dimensiona structural și numeric această echipă astfel încât să se asigure că poate să respecte condițiile impuse prin cerințele proiectului pe durata contractului, dar nu mai puțin de cei 6 experți-cheie listați mai sus”. În secțiunea IV.4.1.a Anexa la propunere tehnica_final.pdf, la cap 24.2 Riscuri pag 261-262, contestatorul precizează că a prezentat următoarele riscuri: 24.2.1 Indisponibilitatea experților-cheie propuși în Ofertă 24.2.2 Neîndeplinirea obligațiilor contractuale de către Prestatorul selectat. 24.2.6 Gradul mare de funcționalități custom necesare implementării cerințelor incluse în prezentul caiet de sarcini. Ca măsuri de prevenire și gestionare a acestor riscuri societatea sa a alocat pe lângă experții cheie și o serie de experți non-cheie. Precizează că va utiliza experții non-cheie numai dacă riscurile identificare mai sus se vor materializa. În acest caz va actualiza planul de proiect- Gantt, cu evidențierea și a experților non-cheie pe activitățile necesare. În acest context, experții non cheie nu au fost menționați clar în Planul de proiect (Gantt) pe fiecare activitate, deoarece la momentul ofertării riscurile nu s-au materializat. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. vii). Nu sunt prezentate rolurile si sarcinile personalului SNN. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Contestatorul susține că în Planul de proiect (Gantt) sunt evidențiate activități care revin inclusiv SNN, de ex: - Efectuare testare de acceptanță pe mediul de test - Faza I (linia 87 din Planul Gantt) Pagina 31 din 171

- Efectuare testare de acceptanță pe mediul de test - Faza II (linia 120 din Planul Gantt). În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Subfactor (2.1.e): optimizarea utilizării resurselor

în cadrul proiectului și flexibilitate pentru situații neprevăzute: „Planul de proiect demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților permite flexibilitate pentru situații neprevăzute. (Foarte bine - 5 puncte)”; „Planul de proiect demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților nu permite flexibilitate pentru situații neprevăzute. (Bine - 3 puncte)”; „Planul de proiect nu demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților nu permite flexibilitate pentru situații neprevăzute. (Acceptabil – 1 punct)”. Motivele invocate de Entitatea Contractantă pentru acordarea punctajului. i). În planul de proiect nu este optimizata utilizarea resurselor, acestea fiind implicate secvențial. ii). Planificarea nu permite flexibilitate pentru activități neprevăzute. iii). Activitatea de proiectare începe după activitatea de analiză. În procedura ORACLE acestea se realizează în paralel - Linia 41 din Gant este condiționată de realizarea liniei 20 din GANTT. Motivarea contestației. i). În planul de proiect nu este optimizată utilizarea resurselor, acestea fiind implicate secvențial. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Societatea sa a prezentat secvențial desfășurarea etapelor în Planul de proiect - graficul Gantt. Prezentarea secvențială a activităților într-un plan de proiect are mai multe avantaje clare față de prezentarea în paralel. Avantaje ale prezentării secvențiale: - Claritate mai mare a dependențelor: Se vede ușor ce activitate depinde de alta și în ce ordine trebuie făcute lucrurile. - Reducerea riscului de erori: Este mai puțin probabil să începi activități fără ca cele necesare înaintea lor să fie terminate. - Monitorizare si control mai ușor: Managerul de proiect poate urmări progresul pas cu pas si poate interveni rapid dacă apare o întârziere. Pagina 32 din 171

- Planificare mai realistă a resurselor: Resursele (oameni, echipamente) pot fi alocate eficient, știind exact când sunt necesare. - Gestionarea mai bună a riscurilor: Se pot identifica din timp punctele critice (momentele unde dacă întârzii o activitate, întârzii tot proiectul). - Mai bună comunicare între echipe: Fiecare echipă știe clar când să înceapă munca și pe ce se bazează. - Simplificarea ajustărilor: Dacă apare o schimbare (de ex., întârziere sau problemă), e mai ușor să ajustezi planul, pentru că vezi legăturile dintre activități. În comparație, prezentarea în paralel poate crea impresia că mai multe activități pot fi făcute simultan fără probleme, ceea ce poate duce la: - Confuzie în prioritizarea task-urilor, - Concurență pe aceleași resurse, - Riscuri nedeclarate sau greu de gestionat, - Lipsă de coordonare și suprapuneri inutile. În opinia sa optimizarea utilizării resurselor nu rezultă doar din planificarea secvențială sau în paralel a activităților ci prin: • Optimizarea prin tehnici specifice, precum: o Resource leveling: Ajustarea activităților pentru a evita suprapunerea și epuizarea resurselor. o Resource smoothing: Menținerea unei utilizări uniforme a resurselor, fără a modifica datele-cheie de finalizare. o Analiza valorii câștigate (EVA) pentru urmărirea performanței în timp real. • Monitorizare și ajustare continuă: o Folosirea unui software de management al proiectelor (ex: MS Project) pentru urmărirea alocărilor. o Ajustarea alocărilor în funcție de: - Modificări în proiect - Întârzieri - Probleme cu disponibilitatea resurselor În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). Planificarea nu permite flexibilitate pentru activități neprevăzute. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. În cadrul planificării proiectului, a introdus o marjă de flexibilitate pentru a gestiona eficient riscurile asociate cu apariția unor activități neprevăzute. Pagina 33 din 171

Această abordare are la bază următoarele principii: - Caracterul dinamic al proiectelor IT: În special în proiectele complexe (ex: implementări și upgrade-uri de soluții Oracle), pot apărea situații neanticipate care necesită ajustări rapide — probleme de compatibilitate, mici întârzieri în livrare, solicitări suplimentare de la beneficiar etc. - Gestionarea riscurilor operaționale: Planul include o rezervă de resurse pentru a preveni blocaje sau prelungiri necontrolate ale duratei proiectului în caz de activități suplimentare sau modificări de cerințe. - Flexibilitate controlată: Marja de flexibilitate este dimensionată astfel încât să nu afecteze obiectivele principale ale proiectului si este utilizată doar în baza unei decizii justificate si aprobate de managementul de proiect. - Asigurarea continuității implementării: Prin integrarea flexibilității în planificare, se evită nevoia de renegociere a calendarului sau a bugetului la apariția fiecărei situații neprevăzute, protejând astfel cursul proiectului și încrederea părților implicate. - Sesiuni de reevaluare a progresului (ex: checkpoints intermediare) pentru identificarea devierilor din timp util. - Mecanism de escaladare rapidă pentru aprobarea utilizării flexibilității. - Resurse suplimentare disponibile on-call, în funcție de necesitate. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. iii). Activitatea de proiectare începe după activitatea de analiză. În procedura ORACLE acestea se realizează în paralel - Linia 41 din Gant este condiționată de realizarea liniei 20 din GANTT. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Contestatorul susține că deși în cadrul Metodologiei Oracle Unified Method (OUM) activitățile de analiză și proiectare pot fi realizate în paralel, în planificarea actuală s-a decis condiționarea explicită a activității de proiectare (linia 41) de finalizarea activității de analiză (linia 20), pentru a asigura: - Calitatea livrabilelor de analiză: Se dorește ca documentele de analiză să fie complet validate înainte de inițierea proiectării, pentru a evita necesitatea refacerii sau ajustării soluției în cazul descoperirii ulterioare a unor cerințe suplimentare sau eronate. - Reducerea riscului de modificări în faza de proiectare: Pornind de la un set complet și stabil de cerințe, activitatea de proiectare devine mai predictibilă, evitând costuri suplimentare sau întârzieri generate de schimbări neplanificate. Pagina 34 din 171

- Adaptare la specificul proiectului și al beneficiarului: Dat fiind contextul organizațional și cerințele stricte de conformitate ale beneficiarului (SNN), a fost preferată o abordare secvențială, mai conservatoare, care minimizează riscul apariției de neconcordanțe între analiză și proiectare. - Controlul mai bun al versiunilor de documentație: Evitarea paralelismului reduce problemele de integrare între livrabilele de analiză si cele de proiectare, ceea ce este esențial pentru un proces de auditare și aprobare formală, cum este cazul în proiectele critice. - În metodologia OUM există flexibilitate în adaptarea modului de aplicare, în funcție de natura și criticitatea proiectului („OUM is scalable and tailorable”). - Această adaptare reflectă alegerea rațională a unei variante de risc minim pentru un proiect strategic. În concluzie, pentru a asigura stabilitatea cerințelor și calitatea proiectării soluției, activitatea de proiectare (linia 41) este condiționată de finalizarea analizei (linia 20), deși OUM permite realizarea lor în paralel. Această abordare minimizează riscurile și optimizează controlul asupra livrabilelor. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Subfactor (2.1.f): optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat: „Planul de proiect demonstrează că ofertantul a fost preocupat de optimizarea duratei proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat. (Foarte bine - 5 puncte)”, „Planul de proiect demonstrează că ofertantul a fost preocupat de optimizarea duratei proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat dar modul de abordare este parțial realist. (Bine - 3 puncte)”, „Planul de proiect demonstrează că ofertantul nu a fost preocupat de optimizarea duratei proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat, dar respectă termenul de prestare solicitat prin caietul de sarcini. (Acceptabil - 1 punct)”. Motivele invocate de Entitatea Contractantă pentru acordarea punctajului. i). Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități, chiar dacă tehnic se pot executa în paralel și metodologia Oracle prevede această practică. ii). Cu mici excepții activitățile au un singur predecesor, activități anterioare, iar restul sunt de tip finish to start. Motivarea contestației. Pagina 35 din 171

i). Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități, chiar dacă tehnic se pot executa în paralel și metodologia Oracle prevede această practică. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Susține că a prezentat secvențial desfășurarea etapelor în Planul de proiect (Gantt). În opinia sa prezentarea secvențială a activităților într-un plan de proiect are mai multe avantaje clare față de prezentarea în paralel. Avantaje ale prezentării secvențiale: - Claritate mai mare a dependențelor: Se vede ușor ce activitate depinde de alta și în ce ordine trebuie făcute lucrurile. - Reducerea riscului de erori: Este mai puțin probabil să începi activități fără ca cele necesare înaintea lor să fie terminate. - Monitorizare și control mai ușor: Managerul de proiect poate urmări progresul pas cu pas și poate interveni rapid dacă apare o întârziere. - Planificare mai realistă a resurselor: Resursele (oameni, echipamente) pot fi alocate eficient, știind exact când sunt necesare. - Gestionarea mai bună a riscurilor: Se pot identifica din timp punctele critice (momentele unde dacă întârzii o activitate, întârzii tot proiectul). - Mai bună comunicare între echipe: Fiecare echipă știe clar când să înceapă munca și pe ce se bazează. - Simplificarea ajustărilor: Dacă apare o schimbare (de ex., întârziere sau problemă), e mai ușor să ajustezi planul, pentru că vezi legăturile dintre activități. În comparație, prezentarea în paralel poate crea impresia că mai multe activități pot fi făcute simultan fără probleme, ceea ce poate duce la: - Confuzie în prioritizarea task-urilor, - Concurență pe aceleași resurse, - Riscuri nedeclarate sau greu de gestionat, - Lipsă de coordonare și suprapuneri inutile. Precizează că deși în cadrul metodologiei Oracle Unified Method (OUM) activitățile (de ex analiză și proiectare) pot fi realizate în paralel, în planificarea actuală s-a decis condiționarea explicită a activității de proiectare (linia 41) de finalizarea activității de analiză (linia 20), pentru a asigura: - Calitatea livrabilelor de analiză: Se dorește ca documentele de analiză să fie complet validate înainte de inițierea proiectării, pentru a evita necesitatea refacerii sau ajustării soluției în cazul descoperirii ulterioare a unor cerințe suplimentare sau eronate. Pagina 36 din 171

- Reducerea riscului de modificări în faza de proiectare: Pornind de la un set complet si stabil de cerințe, activitatea de proiectare devine mai predictibilă, evitând costuri suplimentare sau întârzieri generate de schimbări neplanificate. - Adaptare la specificul proiectului și al beneficiarului: Dat fiind contextul organizațional și cerințele stricte de conformitate ale beneficiarului (SNN), a fost preferată o abordare secvențială, mai conservatoare, care minimizează riscul apariției de neconcordanțe între analiză și proiectare. - Controlul mai bun al versiunilor de documentație: Evitarea paralelismului reduce problemele de integrare între livrabilele de analiză și cele de proiectare, ceea ce este esențial pentru un proces de auditare și aprobare formală, cum este cazul în proiectele critice. - În metodologia OUM există flexibilitate în adaptarea modului de aplicare, în funcție de natura și criticitatea proiectului („OUM is scalable and tailorable”). - Această adaptare reflectă alegerea rațională a unei variante de risc minim pentru un proiect strategic. În concluzie, pentru a asigura stabilitatea cerințelor și calitatea proiectării soluției, activitatea de proiectare (linia 41) este condiționată de finalizarea analizei (linia 20), deși OUM permite realizarea lor în paralel. Această abordare minimizează riscurile și optimizează controlul asupra livrabilelor. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. ii). Cu mici excepții activitățile au un singur predecesor, activități anterioare, iar restul sunt de tip finish to start. Consideră că în mod neîntemeiat, entitatea contractantă a depunctat oferta sa pentru motivul mai sus menționat, după cum va arăta în continuare. Cu privire la acest aspect arată că în cadrul planului de proiect, activitățile sunt corelate astfel încât fiecare are un singur predecesor principal și sunt legate în relații de tip Finish-to-Start (FS). Această abordare urmărește optimizarea duratei proiectului din următoarele considerente: - Claritatea și simplitatea succesiunii activităților: Fiecare activitate are o relație logică directă și ușor de urmărit, reducând complexitatea lanțurilor de dependențe și facilitând monitorizarea progresului. - Maximizarea fluxului de lucru: Relația Finish-to-Start între activități impune începerea unei activități imediat după finalizarea celei anterioare, eliminând timpii morți sau întârzierile inutile între sarcini. - Reducerea riscului de blocaje: Definind un singur predecesor principal pentru fiecare activitate, se minimizează dependențele multiple Pagina 37 din 171

care ar putea complica derularea proiectului în cazul unor modificări sau întârzieri punctuale. - Flexibilitate crescută în replanificare: Structura simplificată a succesiunilor permite o adaptare mai rapidă a Gantt-ului în caz de necesitate, fără a afecta întregul lanț de activități. - Optimizarea duratei totale a proiectului: Prin reducerea overlap- ului inutil sau a așteptărilor între activități și asigurarea unei tranziții rapide între etape, proiectul avansează într-un flux continuu și eficient. În concluzie, precizează că graficul Gantt utilizat, bazat pe relații Finish-to-Start și un singur predecesor principal per activitate, optimizează fluxul execuției, reduce timpii de așteptare între sarcini și minimizează complexitatea dependențelor, contribuind la scurtarea duratei totale a proiectului și la creșterea capacității de gestionare a riscurilor. În acest context, apreciază că motivul invocat de entitatea contractantă pentru depunctarea ofertei sale este neîntemeiat și, pe cale de consecință, solicită Consiliului, ca prin hotărârea pe care o va pronunța, să dispună reevaluarea ofertei sale cu privire la acest punct. Față de cele mai sus arătate, solicită obligarea entității contractante la reevaluarea ofertei sale tehnice, cu privire la aplicarea factorilor de evaluare pentru componenta tehnică, pentru aspectele pentru care oferta sa a fost depunctată în mod neîntemeiat așa cum a arătat detaliat în prezenta contestație. E. Oferta tehnică ............................SRL este neconformă deoarece nu a fost completată corespunzător cerințelor de la cap. 5.1 - Cerințe generale din Caietul de sarcini. Contestatorul precizează că în urma studierii dosarului achiziției la sediul entității contractante, a constatat faptul că oferta tehnică a ............................SRL nu a fost completată conform cerințelor din documentația de atribuire. Astfel, deși la cap. 5.1 - Cerințe generale din Caietul de sarcini se solicită în mod expres faptul că: „Pentru fiecare cerință din prezentul caiet de sarcini, Ofertantul va prezenta răspunsul detaliat, însoțit de descrierea modalității de implementare în cadrul soluției, din care să rezulte îndeplinirea fără echivoc a cerinței, menționând dacă implementarea fiecărei cerințe se realizează prin configurarea produsului standard sau necesită configurări și dezvoltări adiționale. Răspunsurile neconcludente de tip DA/NU sau „soluția îndeplinește” sau reformularea cerințelor ca răspuns prin simpla copiere a acestora din Caietul de sarcini nu vor fi luate în considerare, iar Oferta va fi considerată neconformă.”, În Anexa la Formularul IV.4.1 de propunere tehnică, ofertantul ............................SRL, a completat în coloana privind modalitatea de îndeplinire a cerințelor minime solicitate în caietul de sarcini, pentru anumite cerințe, folosind sintagma „confirmăm Pagina 38 din 171

îndeplinirea cerinței”, fără a prezenta detalii privind îndeplinirea fără echivoc a cerinței. Prin urmare, în mod neîntemeiat entitatea contractantă a declarat oferta depusă de ............................SRL ca fiind conformă, ignorând propriile cerințe din documentația de atribuire privind modalitatea de evaluare a ofertelor, ceea ce contravine principiilor privind nediscriminarea și tratamentul egal prevăzute la art. 2, alin. (2) din Legea nr. 99/2016. Pe cale de consecință, solicită obligarea entității contractante la reevaluarea ofertei ............................SRL, cu respectarea dispozițiilor legale și a documentației de atribuire în sensul celor arătate mai sus. Pentru toate argumentele expuse mai sus, solicită admiterea contestației și: 1. anularea raportului procedurii nr. E-SAch-RAP-PROC-00492-17- 04-25 din 17.04.2025 și documentelor conexe acestuia, respectiv a Procesului verbal nr. DA_DA-25-00502/18.03.2025 și Procesului-verbal nr. DA_DA-25- 00655/01.04.2025, menționate în Raportul procedurii; 2. reevaluarea ofertei sale cu privire la aplicarea factorului de evaluare „Componenta tehnică” pentru care a fost depunctat conform Procesului verbal nr. DA_DA-25-00502/18.03.2025 și Procesului-verbal nr. DA_DA-25- 00655/01.04.2025 menționate în Raportul procedurii; 3. reevaluarea ofertei depuse de ............................SRL, având ca subcontractanți pe ............................SRL și ............................SRL. În drept, își întemeiază prezenta pe prevederile art. 6 și 8 din Legea nr. 101/2016, precum și pe toate textele legale invocate în cuprinsul prezentei. Probe. În susținerea prezentei contestații înțelege se bazează pe documentele existente în cadrul dosarului achiziției. Solicită încuviințarea probei cu înscrisuri, precum și a oricărei alte probe a cărei necesitate ar reieși din dezbateri. Prin adresa înregistrată la CNSC sub nr. 28913/06.05.2025 entitatea contractantă transmite punctul său de vedere cu privire la contestație solicitând respingerea contestației ca fiind nefondată. Preliminar autoritatea contractantă face o scurtă prezentare a situației de fapt. Cu privire la nerespectarea prevederilor art. 228 din Legea nr. 99/2016 privind transmiterea comunicării rezultatului procedurii, respectiv punctul C din contestație: În ceea ce privește criticile formulate de ............................ la punctele [23]-[26] din contestație, consideră aceste critici ca fiind nefondate pentru următoarele motive: Contestatorul în mod eronat afirmă că nu i s-a transmis comunicarea rezultatului procedurii, în conformitate cu prevederile art. 228 din Legea nr. 99/2016, articol citat în cuprinsul contestației, Pagina 39 din 171

entitatea contractantă limitându-se doar la publicarea raportului procedurii în SICAP. Fata de afirmația contestatorului, precizează faptul că comunicarea rezultatului procedurii cu privire la oferta contestatorului, declarată admisibilă, dar necâștigătoare și clasată pe locul al doilea, a fost întocmită și transmisă ofertantului cu respectarea prevederile art. 228, alin. (2) lit. c) din Legea nr. 99/2016, în data de 17.04.2025 prin SEAP împreună cu publicarea, pentru participanții la procedura a raportului procedurii întocmit în conformitate cu structura definita prin Ordinul Președintelui ANAP nr. 1170/2021 - Anexa nr. 5. Astfel prin comunicarea privind rezultatul procedurii transmisă cu adresa Nr. E-SAch-C-RP-00494- 17-04-25 i s-au comunicat contestatorului atât avantajele relative ale ofertei câștigătoare în raport cu oferta sa, precum și numele ofertantului căruia urmează să i se atribuie contractul sectorial, după cum urmează: „Prin prezenta, în conformitate cu prevederile art. 228, alin. (1) și alin. (2), lit. c) din Legea nr. 99/2016, cu modificările și completările ulterioare, în urma evaluării ofertelor depuse în cadrul procedurii organizată în vederea atribuirii contractului de achiziție sectorială mai sus menționat, vă comunicăm faptul că oferta dumneavoastră a fost declarată admisibilă dar nu a fost declarată câștigătoare pentru atribuirea acestui contract deoarece, în urma aplicării criteriului de atribuire asupra ofertelor admisibile, respectiv „Cel mai bun raport calitate-preț”, aceasta s-a clasat pe locul 2 în ierarhia rezultatelor cu un punctaj total de 74 puncte și un preț total al propunerii financiare, de 10.487.013,36 Lei fără TVA. Motivul pentru care oferta depusă de Asocierea ......... SRL + ............................SRL. pe care o reprezentați nu a fost declarată câștigătoare este că după aplicarea criteriului de atribuire publicat în anunțul de participare și fișa de date a achiziției, oferta declarată câștigătoare a obținut un punctaj total mai mare în comparație cu oferta prezentată de dumneavoastră. Totodată, vă comunicăm faptul că oferta declarată câștigătoare pentru atribuirea contractului mai sus amintit a fost cea depusă de ............................SRL cu un punctaj total de 81,12 puncte. Avantajul relevant al ofertei declarate câștigătoare a fost punctajul total obținut pentru factorii de evaluare tehnici”. Prin urmare, contrar afirmațiilor contestatorului, consideră respectate în totalitate obligațiile prevăzute la art. 228 alin. (1) din Legea nr. 99/2016 privind achizițiile sectoriale, cu modificările și completările ulterioare, entitatea contractantă stabilind oferta câștigătoare pe baza criteriului de atribuire și a factorilor de evaluare precizați în documentația de atribuire. Referitor la pct. [27] – „În plus, la studiul dosarului achiziției de la sediul Entității contractante, din data de 24.04.2025, Entitatea Pagina 40 din 171

contractantă nu ne-a dat posibilitatea să obținem o copie fie în format letric, fie în format electronic, cel puțin după Procesul verbal nr. DADA- 25-

00502/18.03.2025

și

Procesul-verbal

nr.

DADA-25- 00655/01.04.2025, care conțin rezultatul evaluării propunerii tehnice și financiare și sunt parte a dosarului achiziției, mai ales în contextul în care Entitatea contractantă nu ne-a transmis Comunicarea rezultatului procedurii care să conțină cel puțin informațiile prevăzute la art. 288, alin. (2) lit. c) din Legea nr. 99/2016”. și Pct. [28] – „Practic, în intervalul celor 2 ore acordate de Entitatea contractantă pentru studiul dosarului achiziției publice, aceasta a dat posibilitatea reprezentanților Asocierii noastre doar să noteze câteva informații esențiale pe care le-au identificat la studiul dosarului achiziției.” Din contestație, entitatea contractantă precizează următoarele: În conformitate cu legislația aplicabilă, respectând cerințele legale potrivit cărora entitatea contractantă este obligată să permită, la cerere, accesul la dosarul achiziției într-un termen care nu poate depăși o zi lucrătoare de la data primirii cererii, subliniază faptul că entitatea contractantă a acționat prompt și în mod transparent, ca urmare a solicitării ............................ de acces la dosarul achiziției. În fapt, pe baza documentelor existente și înregistrate, accesul la dosarul achiziției a decurs astfel: ............................ a solicitat via e- mail, acces la dosarul achiziției, in data de 23.04.2025, cu adresa nr. 1570/23.04.2025, înregistrată la SNN cu nr. E-Sach-CER-ACCES-00589- 23-04-25. Conform adresei SNN_FRZI-25-02128-23-04-2025, aceasta a facilitat accesul la dosar pentru data de 24.04.2025 inclusiv la propunerea

tehnică

și

propunerea

financiară

a ofertantului ............................SRL clasat pe locul I, concluziile întâlnirii fiind menționate și în Procesul verbal nr. SAch_SAch-25-00754-24-04- 2025 semnat atât de reprezentanții ............................ împuterniciți din partea contestatorului să participe la studierea dosarului cât și de reprezentanții SNN. Potrivit alin. (6) al art. 231 din Legea nr. 99/2016, accesul la documentele dosarului achiziției prevede în principal studierea acestora și nu și posibilitatea multiplicării lor, întrucât însăși scopul reglementării este de a permite oricărui ofertant/candidat să își poată asigura în mod eficient apărarea în măsura în care ar intenționa să conteste rezultatul procedurii. Întrucât, în alin. (6) al art. 231 din Legea nr. 99/2016, legiuitorul folosește sintagma «acces neîngrădit» și nu face vreo distincție între studierea documentelor și multiplicarea lor, consideră că în speță este incident principiul de drept conform căruia unde legiuitorul nu distinge, nici interpretului legii nu îi este permis să distingă. Având în vedere faptul că legislația în domeniul achizițiilor publice prevede obligația entității de a acorda accesul ofertanților la dosarul Pagina 41 din 171

achiziției fără a face referire la o anumită modalitate de studiere a documentelor, faptul că, potrivit criticilor contestatorului, SNN nu a dat posibilitatea obținerii unei copii fie în format letric, fie în format electronic, după Procesul verbal nr. DA_DA- 25-00502/18.03.2025 (Proces verbal de evaluare tehnica finala) și Procesul-verbal nr. DA_DA- 25- 00655/ 01.04.2025 (Proces verbal de evaluare financiara finala, nu poate fi calificat drept act vătămător din perspectiva definiției actului autorității contractante date la art. 3 alin. (1) lit. a) din Legea nr. 101/2016. Așa cum poate observa Consiliul, prin Procesul verbal nr. Sach-SAch-25- 00754-24.04.2025 de acces dosar achiziție, documentele anterior menționate au fost puse la dispoziția contestatorului pentru studiu și luarea de notițe, aspect ce nu echivalează cu o îngrădire a accesului la informațiile dosarului achiziției, iar contestatorul a semnat procesul verbal anterior menționat fără obiecțiuni. Foarte important de menționat este faptul că entitatea contractantă nu a restricționat accesul petentei în vreun fel la conținutul dosarului achiziției, aceasta având acces la toate documentele dosarului de achiziție, SNN asigurând transparența întregului proces de vizionare, prin urmare această critică este nefondată, petenta dispunând de toate informațiile necesare pentru a formula o contestație și o apărare corespunzătoare. Cu privire la critica de la pct.28 din contestație, solicită Consiliului să ia act de faptul că entitatea contractantă a acordat accesul neîngrădit la dosarul achiziției așa cum a prezentat anterior, respectiv in data de 24.04.2025, reprezentanții ............................ prezenți la sediul SNN finalizând studiul dosarului achiziției pus la dispoziție de entitatea contractanta într-un timp de cca o ora și 40 de minute, fără a considera necesară solicitarea acordării de către SNN a unui timp de studiu suplimentar, situație din care rezultă că timpul acordat a fost suficient pentru contestator, iar critica adusă este tendențioasă și de rea credință. În consecință, solicită să se constate că entitatea contractantă i-a permis contestatorului studierea, la data de 24.04.2025, a dosarului achiziției sectoriale în forma în care se regăsea la acel moment, nefiind în niciun fel îngrădit accesul petentei de a-și formula apărările corespunzătoare, ca dovadă depunerea contestației în cauză. Referitor la criticile prezentate la Pct. [29] „De asemenea, rugăm Onoratul Consiliul să constate că Raportul procedurii nu conține niciun detaliu/informație cu privire la aspectele pentru care oferta Asocierii ......... SRL și ............................SRL a fost depunctată de către comisia de evaluare pentru componenta tehnică - subfactorii de evaluare”, și la Pct. [30] „Pentru aspectele anterior menționate, Entitatea contractantă a îngrădit dreptul nostru de a avea acces complet la informațiile pe care aceasta în mod nelegal a refuzat să ni le comunice în mod oficial, așa cum legiuitorul a statuat (art. 288 din Legea nr.199/2019), fiind puși în imposibilitatea de a ne face o apărare Pagina 42 din 171

corespunzătoare, în lipsa informațiilor detaliate privind motivele depunctării noastre si detalii privind caracteristicile si avantajele relative ale ofertei desemnate câștigătoare în raport cu oferta noastră.”, entitatea contractantă consideră că sunt nefondate pentru următoarele motive: În conformitate cu prevederile art. 230, alin. (1) din Legea nr. 99/2016, entitatea contractantă a întocmit raportul procedurii de atribuire nr. E-SAch-RAP-PROC-00492-17-04-25 și l-a publicat în SEAP, semnat cu semnătură electronică calificată, în aceeași zi cu transmiterea comunicărilor privind rezultatul procedurii. Modelul folosit în elaborarea raportului procedurii este conform Anexei nr. 5 din Ordinul Președintelui ANAP nr. 1170/2021 prezentat oficial pe site-ul oficial ANAP: https://anap.gov.ro/web/ordinul- presedintelui-anap-nr-1170-2021-privind-aprobarea-formularelor- standard-ale-proceselor-verbale-intermediare-de-evaluare-aferente- procedurilor-de-atribuire-a-contractelor-de-achizitie-publica și conține toate informațiile impuse prin această anexă. Așa cum a reiterat anterior, comunicarea a fost adusă la cunoștința contestatorului și a fost publicată în SEAP încă din data de 17.04.2025 iar informațiile voluminoase cu detalierea minuțioasă privind analiza comisiei și acordarea punctajului aferent factorilor tehnici fiind prezentate în Procesul verbal nr. DA_DA-25-00502/18.03.2025, document pus la dispoziția contestatorului în data de 24.04.2025 la momentul studierii dosarului achiziției. Pentru critica de la punctul D. din contestație - SITUATIA PE FOND, NETEMEINICIA SI NEJUSTIFICAREA DEPUNCTĂRII OFERTEI Asocierea formată din ......... SRL, în calitate de Lider de Asociație și ............................SRL, în calitate de Asociat, pentru componenta tehnică. Entitatea contractantă precizează că potrivit Anexei 1 la contestație analizează mai jos fiecare element care face obiectul criticilor ............................. Referitor la critica ............................ privind motivul de depunctare de la: Subfactorul de evaluare nr. F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare. - „1.i). Riscurile nu sunt tratate din punct de vedere impact și nici al probabilităților de expunere la risc”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: 1. i) În Caietul de sarcini, în cap. 24 Ipoteze și riscuri, la pag. 49, este detaliată cerința referitoare la riscuri: „Ofertanții trebuie să aibă în vedere cel puțin ipotezele și riscurile descrise în continuare și să estimeze posibilele efecte ale acestora. În Pagina 43 din 171

acest sens, la întocmirea Ofertei, fiecare operator economic trebuie să ia în considerare resursele necesare (de timp, financiare și de orice altă natură), pentru implementarea strategiilor de risc pe care le va propune. [...]”. Astfel, Anexa 2 din cadrul Ofertei tehnice - Metodologia de management de proiect, în cap. 3.3.8 Managementul Riscului (pag. 10- 11) prezentată de contestator, conține doar definiții ale noțiunilor generale, fără a se face referire la riscurile menționate în Caietul de sarcini sau la alte riscuri identificate pentru proiect, nefiind analizate nici impactul și nici probabilitatea de expunere la riscurile implementării, ca elemente predominante ale analizei calitative a riscurilor, conform mențiunilor din metodologie prezentate de contestator în Anexa 2, pag. 11: „Analiza calitativă a riscului este procesul de evaluare a impactului și probabilității de apariție a fiecărui risc identificat. Acest proces prioritizează riscurile în funcție de efectul lor potențial asupra obiectivelor de proiect”. Face precizarea că în evaluarea metodologiei, comisia de evaluare a dat dovadă de înțelegere și a luat în considerare riscurile precizate în cadrul Anexei 1 (după cum se menționează mai jos) deși acestea, așa cum a precizat nu sunt menționate niciunde în cadrul Anexei 2 - Metodologia de management de proiect. Prezentarea informațiilor în mod organizat și sistematic este sarcina exclusivă a ofertantului, pentru a putea demonstra conformitate ofertei acestuia și modul în care tratează cerințele din Caietul de sarcini. În Anexa 1 din cadrul Ofertei tehnice - Formularul IV.4.1.a, pentru cerința 24.2 Riscuri, la pag. 261-264, referitor la riscurile prezentate în Caietul de sarcini, este menționat faptul că „Ofertantul a luat la cunoștință și asumă [...]” și este prezentată recomandarea de suplimentare a echipei cu experți pentru eliminarea acestor riscuri, dar cele 6 riscuri identificate de entitatea contractantă nu au fost analizate din perspectiva impactului și probabilității de apariție a riscurilor respective. În cadrul răspunsului la aceeași cerință sunt identificate 6 noi riscuri de către contestator, dar pentru care de asemenea nu este tratat nici impactul și nici probabilitatea de expunere la risc, conform metodologiei prezentate. În concluzie, deoarece oferta nu a inclus o estimare a posibilelor efecte și o clasificare a riscurilor prezentate, bazată pe probabilitatea și severitatea apariției, iar contestatorul nu a prezentat în Metodologia de management de proiect nicio informație din care să reiasă o descriere exhaustivă a analizei riscurilor, comisia de evaluare a ofertelor a apreciat că oferta nu poate fi încadrată la un punctaj superior. În consecință, la notarea subfactorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la tratarea riscurilor, comisia de evaluare a ofertelor a constatat că gradul de detaliere al planului de proiect și a metodologiei facilitează Pagina 44 din 171

limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Riscurile nu sunt tratate din punct de vedere al impactului și nici al probabilității de expunere la risc”. Referitor la critica ............................ privind motivul de depunctare de la: „1.ii). Nu este descrisă arhitectura sistemului”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În Anexa 1 din cadrul Ofertei tehnice - Formularul IV.4.1.a, în cap. 5.1.2.13 Cerință administrare, la pag. 40-53, se face referire la documentația despre arhitectura sistemului, doar ca livrabil al proiectului, fără a conține o descriere corespondentă minimală în Metodologia de implementare, pentru a putea fi relevantă pentru punctarea metodologiei, cu privire la resursele necesare implementării sistemului din perspectiva arhitecturii acestuia, deși contestatorul știa ce ar trebui să livreze ca „documentație despre arhitectura sistemului”, conform cerințelor din Caietul de sarcini de la cap. 5.1.2.13, finalul subcapitolului, pag. 14. Face precizarea că în evaluarea metodologiei, comisia de evaluare a dat dovadă de înțelegere și a luat în considerare livrabilele precizate în cadrul Anexei 1 (după cum se menționează mai sus) deși acestea, așa cum a precizat nu sunt menționate niciunde în cadrul Anexei 3 - Metodologia de implementare Oracle (OUM). Prezentarea informațiilor în mod organizat și sistematic este sarcina exclusivă a ofertantului, pentru a putea demonstra conformitate ofertei acestuia și modul în care tratează cerințele din Caietul de sarcini. Anexa 3 din cadrul Ofertei tehnice - Metodologia de implementare Oracle (OUM) prezentată de contestator nu ține cont de situația existentă în cadrul SNN și implicit de obiectul achiziției, care este extindere aplicație Oracle HR, și prezintă detalii generale ale metodologiei OUM, ca și cum ce ar trebui să implementeze ar fi o soluție nouă, iar în planul de implementare, în cap. 1.1.2 Etapa de proiectarea soluției tehnice, nu se ia în considerare, ca data de intrare, arhitectura sistemului existent (detaliată în Caietul de sarcini la începutul capitolului 5), ci este inclusă o activitate de Prototipare arhitecturală, pag. 30-31, specifică implementării de proiecte noi și nu de extindere a unora deja existente. Prezintă un extras relevant din Anexa 3, cap 1.1.2. Ținând cont de faptul că Faza I a implementării obiectului achiziției este o extindere a soluției Oracle HR, deja implementate în SNN, este evident că arhitectura, care trebuie prezentată în metodologie, trebuia să țină cont de datele din Caietul de sarcini, cap. 5, pag. 4: Pagina 45 din 171

„Începând cu anul 2009, la nivelul sucursalei CNE Cernavodă se află în producție aplicația Oracle HR Core, din cadrul pachetului Oracle Enterprise Business Suite (EBS versiunea 12.2.10), cu ajutorul căreia se gestionează: - procesele de lucru standard de management al activităților de resurse umane și dezvoltare organizațională, prin produsul Oracle Human Resources; - evidența pregătirii angajaților și personalului contractor, prin produsul Oracle Learning Management, și în plus, pentru a facilita înregistrarea necesarului de pregătire la nivel de poziție și gestionarea pregătirilor individuale ale angajaților și personalului contractor, este configurată și afișarea certificărilor utilizatorilor prin intermediul aplicației JRTR (Job Related Training Requirements). Platforma actuală, care este implementată pe sistemul de operare Oracle Linux (versiunea 7.9) și pe Oracle Database (versiunea 19), va fi folosită și pentru sistemul integrat la nivel SNN. [...]”, și nu să prezinte o metodologie de implementare a unui proiect nou. Precizează Consiliului că informațiile prezentate de contestator cu privire la „activitatea de prototipare de arhitectură” de la cap 1.1.2 Etapa de proiectarea soluției tehnice a Anexei 3 - Metodologia de implementare Oracle (OUM) nu se regăsesc în graficul Gantt, ceea ce denotă o superficialitate marcantă a contestatorului, după cum reiese din modul în care a înțeles să întocmească ANEXA 3. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențe interne și externe, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu este descrisă arhitectura necesară sistemului care urmează a fi implementat”. Referitor la critica ............................ privind motivul de depunctare de la: „1.iii). Metodologia OUM este descrisă în termeni generali”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În oferta prezentată de contestator în Anexa 3 din cadrul Ofertei tehnice - Metodologia de implementare Oracle (OUM), la cap. 1. Metodologia de implementare OUM - (Oracle Unified Methodology), pag. 3-14, ofertantul prezintă succint și nestructurat metodologia OUM fără a permite o legătură logică și structurată cu celelalte capitole ale documentului, lăsând să se evidențieze că fiecare capitol din Metodologia Pagina 46 din 171

prezentată este de sine stătător fără să aibă o legătură intrinsecă cu informațiile din capitolul 1, care ar fi trebuit să dea indicii clare asupra modului cum vor fi prezentate informațiile. Ca exemplu elocvent, cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, pag. 15-69, prezintă modalitatea de implementare a proiectului, după cum se poate observa din denumirea subcapitolelor 1.1.1 - 1.1.8 din cuprinsul prezentat mai jos la punctul 1. iv), care sunt grupate conform cerințelor din Caietul de sarcini și nu au nicio legătura cu ce a fost precizat în cadrul capitolului. 1 al metodologiei OUM. În concluzie, s-a apreciat în mod indulgent, că metodologia OUM detaliată în cap. 1 al Anexei 3 este descrisă în termeni generali, aceasta netratând de fapt structura modului de implementare a proiectului. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a constatat că gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că „Metodologia de implementare OUM este descrisă în termeni generali, capitolele din metodologie nu sunt numerotate și legătura se poate intui doar prin denumirea anumitor etape”. Referitor la critica ............................ privind motivul de depunctare de la: „1.iv). Capitolele nu sunt numerotate si legătura dintre acestea se poate intui doar prin denumirea etapei”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În oferta prezentată de contestator în Anexa 3 din cadrul Ofertei tehnice - Metodologia de implementare Oracle (OUM), în cap. 1. Metodologia de implementare OUM - (Oracle Unified Methodology), pag. 3-14, nu sunt incluse subcapitole și nu sunt numerotate etapele, așa cum rezultă din cuprinsul prezentat. În cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, pag. 15- 69, este prezentată modalitatea de implementare, de asemenea nestructurat, după cum se poate observa din denumirea subcapitolelor 1.1.1 - 1.1.8 din cuprinsul prezentat, care nu urmărește etapele și iterațiile metodologiei OUM, ci Caietul de sarcini și, în plus, include o serie de etape și activități care nu se regăsesc în graficul Gantt. În cap. 1.2 Planul de implementare sunt incluse doar graficul Gantt și graficul de facturare, fără detalierea particularizată a etapelor, activităților, metodelor și mijloacelor de realizare a acestora. Anexa 2 din cadrul Ofertei tehnice - Metodologia de management de proiect nu are legătură Pagina 47 din 171

cu metodologia de implementare OUM și cu factorul de evaluare F2.1 a), prin urmare cuprinsul prezentat este irelevant. În concluzie, capitolele metodologiei OUM prezentate în cap. 1 al Anexei 3 nu sunt numerotate, iar etapele incluse în cap. 1.1 al Anexei 3 sunt corelate în mică măsură cu graficul Gantt. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Metodologia de implementare OUM este descrisă în termeni generali, capitolele din metodologie nu sunt numerotate și legătura se poate intui doar prin denumirea anumitor etape”.  Referitor la critica ............................ privind motivul de depunctare de la: „1.v). Planul de proiect este în mică măsură corelat cu planul GANTT, sunt diferențe majore între activități și livrabile și sunt necorelate”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În graficul Gantt, activitățile de la liniile 87 și 120 sunt singurele care au alocate resurse din echipa de proiect a beneficiarului, acestea rezultând direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag.42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Echipa de proiect a beneficiarului nu este implicată în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3. Prin urmare, metodologia și planul de proiect nu sunt corelate din acest punct de vedere. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de proiect este prezentat prin etape ale metodologiei combinate cu serviciile solicitate prin Caietul de sarcini și prin urmare este în mică măsură corelat cu graficul Gantt (multe roluri, activități și livrabile ale etapelor diferă)”. Pagina 48 din 171

Referitor la critica ............................ privind motivul de depunctare de la: „1.vi). Activități și subactivități din planul de proiect nu se regăsesc în metodologie și GANTT”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Activitățile și subactivitățile prezentate în cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului al Anexei 3 sunt prezentate nestructurat și nu se regăsesc în graficul Gantt, însă pot afecta durata și alocarea resurselor proiectului, cum ar fi de exemplu activitățile de testare de la pag. 43-48 din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3 (detaliate și de contestator la subfactorul F 2.1 a) punctul viii) de mai jos). În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei” facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul proiectului prezintă activități și sub-activități grupate în etape, care nu se regăsesc nici în metodologia OUM și nici în graficul Gantt, care includ roluri și livrabile irelevante pentru implementarea proiectului (de exemplu pentru testare sau integrare versiuni)”. Referitor la critica ............................ privind motivul de depunctare de la: „1.vii). Planul de proiect conține livrabile irelevante pentru etapa de testare”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În cap. 1.1.3 Metodologia de implementare și mentenanță adaptată la specificul proiectului din Anexa 3 sunt incluse o serie de livrabile care nu se regăsesc în graficul Gantt și care nu sunt solicitate nici în Caietul de sarcini. Un document pe care îl consideră irelevant în contextul implementării proiectului este Planul de integrare a versiunilor, care apare ca intrare în mai multe sub-activități, însă nu se specifică nicio activitate prin care este elaborat și de către cine. Iar referitor la testare, activitățile prezentate au ca intrări documente, cum ar fi Planul general de testare sau Planul de proiectare, care nu sunt menționate ca ieșiri pentru alte activități, prin urmare nu rezultă când și de către cine sunt elaborate, după cum reiese de exemplu din pag. 44 (pe care îl redă în continuare). Pagina 49 din 171

În consecință, în cadrul factorului de evaluare Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul proiectului prezintă activități și sub-activități grupate în etape, care nu se regăsesc nici în metodologia OUM și nici în graficul Gantt, care includ roluri si livrabile irelevante pentru implementarea proiectului (de exemplu pentru testare sau integrare versiuni)”. Referitor la critica ............................ privind motivul de depunctare de la: „1.viii). Activitatea de testare - nu conține acțiuni pentru rezolvarea problemelor la testare și nici o analiză a rezultatelor obținute și modul în care se pot rezolva”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În graficul Gantt, activitățile de la liniile 85 și 118 reprezintă activități interne care sunt anterioare testării de acceptanță și au ca responsabili rolurile care au participat la configurare (le redă in continuare). În cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3, pag. 43 - 48, activitățile de testare au în comun cu graficul Gantt și cu Caietul de sarcini doar livrabilele etapelor de testare, însă descrierea activităților și rolurile sunt total diferite, de exemplu la pag. 45: „Verificarea abordării testării (.........)”. În concluzie, nici în planul de implementare conform metodologiei din cap. 1.1.3 al Anexei 3 și nici în graficul Gantt nu sunt incluse activități de analiză și retestare în urma activităților de testare de acceptanță. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Testarea de acceptanță nu include activități pentru rezolvarea problemelor identificate la testare și retestare și nici analiza rezultatelor testării”. Pagina 50 din 171

Referitor la critica ............................ privind motivul de depunctare de la: „1.ix). În Gantt nu sunt asignati responsabilii pe elaborarea livrabilelor”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Înainte de a explica evaluarea alocării responsabililor în graficul Gantt, entitatea precizează că în conformitate cu cerințele Caietului de Sarcini, nu există o corespondență între activități și livrabile. Numărul activităților este mult mai mare decât numărul livrabilelor. Prin motivația prezentată, contestatorul încearcă să inducă în mod netemeinic faptul că responsabili de livrabile sunt aceeași cu responsabilii de activități. Astfel, cerința Caietului de Sarcini a fost ca în graficul Gantt să fie menționați responsabilii de activități și nu de livrabile. De altfel, contestatorul nu a menționat niciunde în metodologiile prezentate (Anexa 2 și Anexa 3) că responsabilii de livrabile sunt aceeași cu cei care execută toate activitățile corespunzătoare, completând prin contestație elemente care ar putea să denatureze modul în care a prezentat oferta. Pentru clarificarea situației de alocare pe fiecare activitate și livrabil, comisia de evaluare a solicitat clarificări prin adresa nr. SNN_FRZI- 25-00114/23.01.2025, care la punctul 5 prevede: „Având în vedere cerințele Caietului de sarcini din cap. 5.1.2.1 Cerințe management contract, vă solicităm să completați Planul de implementare de tip Gantt cu responsabilii pentru fiecare activitate și livrabil, menționând rolul și persoana pentru cazul în care sunt mai mulți experți propuși pe același rol, atât pentru experții-cheie, cât și pentru cei non- cheie, dacă au fost nominalizați”. În răspunsul transmis, contestatorul nu a menționat, din nou, în graficul Gantt toate rolurile și experții responsabili pentru livrabilele realizate, în condițiile în care nu a inclus nici activități de elaborare a livrabilelor. Solicitarea entității contractante a avut ca scop clarificarea referitoare la rolurile și experții care vor fi implicați în elaborarea livrabilelor și care își vor asuma documentația prin semnătură, în special pentru rolurile unde au fost alocați de către ofertant câte 2 experți. Referitor la activitatea de la linia 42 „Design soluție optimizată și upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)” consideră că a fost repartizat eronat rolului Specialist în implementarea de tehnologii Oracle EBS HCM 2 - Iulia Calistrate, dată fiind cerința din Caietul de sarcini, de la cap. 5.1.2.2 Cerințe personal tehnic de specialitate, la pag. 8: „(3) Arhitect de sistem Oracle EBS (1 expert) Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea Pagina 51 din 171

cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”, prin care se solicită ca rolul Arhitect de sistem Oracle EBS să fie responsabil de optimizarea și upgrade-ului sistemului de operare și a Oracle HR, inclusiv de avizarea documentației. Referitor la livrabilul de la linia 45 „Lvr. Documentația despre arhitectura sistemului - Faza I” este evident că acesta nu este livrabil pentru faza I, ci este livrabil pentru Faza II, conform Caietului de sarcini, cerința 18.3.3, pag. 47: „Procesul verbal va avea anexate: - manualul de utilizare a aplicației (destinat utilizatorilor generali și administratorilor aplicației); - manualul de administrare a soluției (destinat administratorilor de sistem și care include și procedura de instalare, strategia de backup, procedură de recuperare în caz de dezastru, documentația bazelor de date, documentația despre arhitectura sistemului); - raportul de trecere în producție faza II; - rapoartele de status săptămânal”. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea sarcinilor personalului implicat, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Graficul Gantt include roluri și specialiști responsabili pentru fiecare activitate, dar nu sunt asignați responsabili și pentru elaborarea livrabilelor”. Referitor la critica ............................ privind motivul de depunctare de la: „1.x). Referitor la liniile 42 și 73 din Gantt - nu este menționat decât expertul Specialist ORACLE EBS HCM, fără a fi implicat și expertul Architect de sistem ORACLE EBS”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Prin cerința din Caietul de sarcini, de la cap. 5.1.2.2 Cerințe personal tehnic de specialitate, la pag. 8: „(3) Arhitect de sistem Oracle EBS (1 expert) Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa Pagina 52 din 171

tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”, se menționează că rolul Arhitect de sistem Oracle EBS este responsabil de optimizarea și upgrade-ul sistemului de operare și a Oracle HR. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea sarcinilor personalului implicat, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În graficul Gantt, sarcinile: Design soluție optimizată și upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources) și Actualizarea sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR (liniile 42 și 73) sunt asignate doar rolului Specialist în implementarea de tehnologii Oracle EBS HCM 2, fără a fi implicat și rolul Arhitect de sistem Oracle EBS”. Referitor la critica ............................ privind motivul de depunctare de la: „1.xi). Etapele din GANTT sunt prezentate consecutiv și nu în ordinea cronologică, adică să fie prezentate activitățile pentru Faza 1, după care activitățile pentru Faza 2”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Graficul Gantt se presupune a fi un instrument structurat care să faciliteze înțelegerea și urmărirea derulării implementării, în special de către managerii de proiect, oferind o vizualizare clară a cronologiei proiectului, și nu doar o transpunere a cerințelor și livrabilelor din Caietul de sarcini. Reprezentarea cronologică a activităților este o caracteristică fundamentală a graficului Gantt, permițând o planificare, urmărire a progresului și comunicare eficientă a activităților proiectului în timp. Având în vedere că cele două faze ale proiectului se vor desfășura consecutiv, graficul Gantt (reprezentarea grafică a planului de implementare, parte din acesta) ar fi trebuit să permită identificarea clară și ușoară a activităților din cele 2 faze ale implementării, inclusiv a celor critice, în vederea analizei din punct de vedere al completitudinii (toate activitățile necesare execuției fazei sunt prevăzute, cu dependențe și constrângeri între ele), duratelor și resurselor alocate. Analiza planului de implementare și a graficului Gantt asociat incluse în ofertă este consumatoare de timp și necesită mijloace suplimentare, forma Pagina 53 din 171

prezentată fiind foarte dificil de verificat. În plus, forma prezentată nu va putea fi utilizată în urmărirea derulării proiectului, deoarece nu permite identificarea automată, utilizând instrumente de planificare consacrate (Microsoft Project, Primavera), a stadiului de realizare a fazei II. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențele interne și externe, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În graficul Gantt sunt menționate dependențe între activități, însă etapele sunt prezentate consecutiv și nu în ordine cronologică (toate activitățile fazei I, urmate de toate activitățile fazei II)”. Referitor la critica ............................ privind motivul de depunctare de la: „1.xii). Nu sunt menționați experții suplimentari (non cheie) pe activitățile și livrabile din Plan + GANTT”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Precizează Consiliului că motivul invocat de contestator este unul fals, comisia de evaluare nu a luat în considerare pentru calculul subfactorului F2.1 a) elementele menționate de aceasta, deoarece nu a făcut obiectul evaluării desemnarea experților suplimentari (non cheie) pe activitățile și livrabile din Plan + GANTT. În opinia sa acest mod de abordare este un alt comportament deviant pe care contestatorul îl folosește nejustificat pentru a induce Consiliul în eroare și a reuși să își îndeplinească scopul. Referitor la critica ............................ privind motivul de depunctare de la: „1.xiii). Nu sunt prezentate activitățile care revin personalului SNN”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Activitățile de la liniile 87 și 120 din graficul Gantt sunt singurele care fac referire la activități care includ la responsabili și echipa de proiect a beneficiarului, iar acestea rezultă direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Echipa de proiect a beneficiarului nu este inclusă în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3. Pagina 54 din 171

În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențele interne și externe, comisia de evaluare a ofertelor a apreciat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu sunt prezentate dependențe externe: nu au fost prevăzute activități în sarcina SNN, care însă pot afecta durata proiectului (de exemplu: corecții de date, pregătire utilizatori finali, analiză de business)”. Subfactorul de evaluare nr. F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini. Referitor la critica ............................ privind motivul de depunctare de la: „2.i). Documentația de Baza de date și Documentația de Arhitectură a sistemului nu sunt livrabile aferente Fazei 1. Acestea sunt identice cu cele din Faza 2”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Includerea în graficul Gantt a Documentației bazei de date și a Documentației despre arhitectura sistemului ca livrabile pentru faza I demonstrează faptul că ofertantul nu are viziunea corectă asupra sistemului aflat în producție la CNE și nici a soluției care urmează a fi implementată, deoarece baza de date este deja creată și nu este necesară livrarea unei Documentații a bazei de date doar pentru faza I, ci doar la finalul fazei II, după ce vor fi realizate și noile module ale soluției. De asemenea, graficul Gantt nu include și activități de elaborare a acestor documentații, cu responsabili asignați, iar din captura prezentată se poate observa că nici livrabilele nu au desemnați responsabili. În plus, cele 2 livrabile sunt menționate separat pentru faza I și faza II ca intrări/ieșiri ale unor sub-activități prezentate în Anexa 3 din cadrul Ofertei tehnice - Metodologia de implementare Oracle (OUM), la cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, de exemplu la pag. 34 pentru Revizuirea Documentației de proiectare, activitate care nu apare în graficul Gantt, cu rolul responsabil Evaluator arhitectură software, care de asemenea nu apare în graficul Gantt (pe care-l redă în continuare). Elaborarea documentației despre baza de date și a documentației despre arhitectura sistemului ar trebui planificată de la inițierea implementării proiectului prin descrierea situației actuale, urmând ca documentele să fie revizuite în etapele de analiză și proiectare (și de fiecare dată când apare o modificare în etapele de testare sau chiar la Pagina 55 din 171

trecerea în producție), însă se va livra doar versiunea finală, conform Caietului de sarcini, cerința 18.3.3 Etapa de trecere în producție faza II, pag. 47: „Procesul verbal va avea anexate: - manualul de utilizare a aplicației (destinat utilizatorilor generali și administratorilor aplicației); - manualul de administrare a soluției (destinat administratorilor de sistem și care include și procedura de instalare, strategia de backup, procedură de recuperare în caz de dezastru, documentația bazelor de date, documentația despre arhitectura sistemului); - raportul de trecere în producție faza II; - rapoartele de status săptămânal”. În consecință, în cadrul factorului de evaluare F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini, cu privire la corelarea între livrabilele din caietul de sarcini si planul de proiect propus, comisia de evaluare a ofertelor a apreciat că „există corelare cu deviații minore între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus” și a calificat ca „Bună” îndeplinirea cerințelor, justificând, printre altele, că: „Documentația bazei de date și Documentația despre arhitectura sistemului nu sunt livrabile pentru faza I și nu sunt documente diferite pentru faza I și faza II (sistemul presupune o singură bază de date și o singură arhitectură)”. Referitor la critica ............................ privind motivul de depunctare de la: „2.ii). Experții suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Precizează Consiliului că motivul invocat de contestator este unul fals, comisia de evaluare nu a luat în considerare pentru calculul subfactorului F2.1 b) elementele menționate de aceasta, deoarece nu a făcut obiectul evaluării desemnarea experților suplimentari (non cheie) în GANTT pe activitățile în care au fost implicați. În opinia sa acest mod de abordare este un alt comportament deviant pe care contestatorul îl folosește nejustificat pentru a induce Consiliul în eroare și a reuși să își îndeplinească scopul. Referitor la critica ............................ privind motivul de depunctare de la: „2.iii). Planul de proiect face referire plan de integrare versiuni fără corespondență în CSșsi GANTT”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Documentul menționat în Anexa 3 a contestatorului, și anume Planul de integrare a versiunilor, nu a fost identificat de către comisia de evaluare în graficul Gantt. Pagina 56 din 171

Din această perspectivă comisia de evaluare l-a considerat un element care nu asigură un calificativ superior celui acordat pentru subfactorul de evaluare F2.1. b). Menționează de asemenea că în cadrul Metodologiei OUM nu se specifică niciun detaliu cu referire la modul cum va arăta Planul de integrare a versiunilor și ce va conține acesta și, în plus, activitatea prin care acesta este elaborat și de către cine. În consecință, în cadrul factorului de evaluare F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini, cu privire la corelare între cerințele din caietul de sarcini și planul de proiect propus, comisia de evaluare a ofertelor a apreciat că „există corelare cu deviații minore între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus” și a calificat ca „Bună” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de proiect (Anexa 3) face referire la elaborarea documentului Plan de integrare a versiunilor, care nu are corespondent în Caietul de sarcini sau în graficul Gantt”. Referitor la critica ............................ privind motivul de depunctare de la: „2.iv). Planul de proiect conține roluri suplimentare pentru testare fără corespondență în GANTT și CS”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Faptul că în graficul Gantt nu au fost menționate rolurile de: -Managerul de testare -Analist de Testare -Designer de Testare -Proiectantul de Testare -Tester -Manager Configurație pe care contestatorul le-a precizat în Planul de proiect din Anexa 3 la cap.1.1.3, a condus la acordarea unui calificativ inferior celui maxim alocat, aferent subfactorului F2.1 punctul b). Menționează că cele 6 roluri nu au fost solicitate expres în Caietul de Sarcini. În consecință, în cadrul factorului de evaluare F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini, cu privire la corelare între cerințele din caietul de sarcini și planul de proiect propus, comisia de evaluare a ofertelor a apreciat că „există corelare cu deviații minore între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus” și a calificat ca „Bună” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de implementare conține roluri suplimentare pentru activitățile de testare, care nu se regăsesc în Caietul de sarcini și nici în graficul Gantt”. Referitor la critica ............................ privind motivul de depunctare de la: Pagina 57 din 171

„2.v). Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Contestatorul a înțeles în mod eronat modul în care a fost evaluată la acest subfactor, deoarece succesiune etapei de instruire este legată de acceptarea Planului de instruire și nu a etapei de trecere în producție. Astfel, arată că în graficul Gantt, acceptarea livrabilelor pentru sesiunile de instruire, liniile 169-170 pentru faza I, la data de 29 august 2025, ar trebuie să se realizeze înainte de începerea sesiunilor de instruire, liniile 163-166 pentru faza I, care însă sunt planificate în perioada 30 iulie - 26 august 2025. Aceeași observație și pentru faza II. În concluzie, în oferta tehnică se propune începerea sesiunilor de instruire înainte de livrarea Planului de instruire și a suportului de curs. Nu a fost considerată pentru depunctarea ofertei planificarea sesiunilor de instruire înainte de trecerea în producție, care respectă cerințele din Caietul de sarcini (cap. 6.2, pag. 36¬37). În consecință, în cadrul factorului de evaluare F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini, cu privire la corelare între livrabilele din caietul de sarcini si planul de proiect propus, comisia de evaluare a ofertelor a apreciat că „există corelare cu deviații minore între cerințele și livrabilele solicitate prin caietul de sarcini și planul de proiect propus” și a calificat ca „Bună” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de instruire și materialele de pregătire pentru faza I (liniile 169-170) ar trebui să fie acceptate înainte de începerea sesiunilor de instruire (liniile 163-166), iar elaborarea acestor documente ar putea fi inițiată în etapele de Analiză și Proiectare; similar pentru faza II”. Subfactorul de evaluare nr. F.2.1 c) Corelarea planului de proiect cu metodologia de management de proiect Referitor la critica ............................ privind motivul de depunctare de la: „3.i). Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliata foarte general”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Ofertantul a prezentat metodologia de management de proiect, cu detalii generale, în Anexa 2 - Metodologia de management de proiect din cadrul ofertei tehnice. Referitor la afirmația: „Structurarea activităților pe faze și procese: Activitățile din Gantt sunt organizate pe etape principale (Inițiere, Planificare, Execuție, Monitorizare și Control, Închidere), reflectând Pagina 58 din 171

fazele ciclului de viață al proiectului așa cum sunt definite în metodologie”, din graficul Gantt se poate observa că au fost incluse doar etapele de Inițiere, Planificare și Închidere, iar restul etapelor diferă față de prezentarea metodologiei din Anexa 2, cap. 3.5 Procesele managementului de Proiect, pag. 24-67, atât ca denumiri, structură, dar și intrări/ieșiri ale proceselor. Referitor la afirmația: „Definirea clară a livrabilelor: Fiecare activitate sau grup de activități din Gantt este asociată cu livrabile concrete, conform principiului de management al proiectelor bazat pe livrabile (deliverable-based planning)”, se poate observa că în Anexa 2 nu este prezentat principiul deliverable-based planning, iar livrabilele urmăresc în principal cerințele din Caietul de sarcini. Referitor la afirmația: „Stabilirea relațiilor de dependență: Relațiile Finish-to-Start între activități respectă logica secvențială a proceselor de management de proiect (ex.: analiza trebuie să preceadă proiectarea, proiectarea trebuie să preceadă dezvoltarea, testarea trebuie să urmeze dezvoltării)”, poate afirma că în graficul Gantt sunt marcate relații de precedență între sarcinile echipei de proiect, iar în Anexa 2, la cap. 3.5 Procesele managementului de Proiect, sunt reprezentate diagramele fluxurilor pentru procesele de care este responsabil managerul de proiect din partea Furnizorului și care presupun pași secvențiali între activități, dar care nu au corespondent în graficul Gantt. Referitor la afirmația: „Planificarea punctelor de control și a livrabilelor intermediare: Gantt-ul integrează momente cheie de validare (ex.: Review de analiză, Aprobare proiectare, UAT - User Acceptance Testing), în conformitate cu practicile de Monitorizare și Control specificate de metodologia de proiect”, consideră că nu există o corelare între validarea din partea Beneficiarului a livrabilelor intermediare (care este marcată în graficul Gantt doar prin sarcinile de testare de acceptanță - liniile 87 și 120) și prezentarea procesului din Anexa 2 de la cap. 3.5.5 Monitorizarea și Controlul Proiectului, unde sunt detaliate activitățile prin care Furnizorul (prin managerul de proiect și responsabilul tehnic de proiect) urmărește implementarea proiectului și unde nu sunt incluse și activități de validare din partea Beneficiarului. Referitor la afirmația: „Asigurarea trasabilității între procesele de planificare și execuție: Planul Gantt include activități specifice de management de proiect (ex.: actualizare plan de proiect, managementul riscurilor, raportări de progres), asigurând implementarea continuă a metodologiei și nu doar a livrabilelor tehnice”, în opinia sa se poate proba cu ușurință că în graficul Gantt nu sunt incluse activități de managementul riscurilor și nici de actualizarea planului de proiect, care este elaborat/actualizat doar la inițierea implementări (și nici nu presupune validarea de către managerul de proiect al beneficiarului), prin urmare singurele raportări de progres sunt cele de status săptămânal, care sunt solicitate prin Caietul de sarcini. Pagina 59 din 171

În consecință, în cadrul factorului de evaluare F2.1 c) Corelarea planului de proiect cu metodologia de management de proiect, comisia de evaluare a ofertelor a apreciat că „corelarea între planul de proiect și metodologia utilizată în cadrul proiectului este cu deviații majore” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de implementare și graficul Gantt sunt în mică măsură corelate cu metodologia de management de proiect, care este detaliată foarte general”. Referitor la critica ............................ privind motivul de depunctare de la: „3.ii). Activitățile din GANTT nu sunt în ordine cronologică, adică activitatea de instruire este după activitate de punere în producție”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Pentru subfactorul de evaluare F2.1 c) Corelarea planului de proiect cu metodologia de management de proiect, comisia de evaluare a ofertelor a apreciat că „corelarea între planul de proiect și metodologia utilizată în cadrul proiectului este cu deviații majore” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În graficul Gantt etapele nu sunt prezentate în ordine logică, de exemplu Trecerea în producție este înaintea Instruirilor (cu toate că estimările de date pentru Start și Finish pe activități sunt în ordine cronologică)”, dar fără a depuncta oferta pe motivul că: „Activitățile din GANTT nu sunt în ordine cronologică, adică activitatea de instruire este după activitate de punere în producție”, așa cum prezinta eronat contestatorul. Referitor la critica ............................ privind motivul de depunctare de la: „3.iii). Nu este marcat corect drumul critic. Doar activitatea de management de proiect este singura critica”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: În Anexa 2 - Metodologia de management de proiect, secțiunea 3.3.3 Managementul Timpului, paragraful „Secvențierea activităților” se menționează: „Managementul de Timp al proiectului include procesele necesare pentru a asigura încheierea la timp a proiectului și include următoarele procese: • Definirea activităților implici identificarea și documentarea activităților specifice care trebuie executate pentru a produce livrabilele și sub livrabilele de proiect. În acest proces este nevoie să definim activitățile astfel încât obiectivele proiectului să fie atinse. Definirea activităților se face în conformitate cu aria de cuprindere a proiectului prin descompunere, ținând cont de presupunerile făcute și de constrângerile proiectului. Pagina 60 din 171

• Secvențierea activităților implică identificarea și documentarea relațiilor de interacțiune logică. Activitățile trebuie secvențiate cu acuratețe pentru a sprijini dezvoltări ulterioare. Secvențierea poate fi executată prin metodologia drumului critic. În consecință, programul rezultat este definit cu jaloane și interdependențe. • Estimarea duratei activităților este procesul de preluare de informații asupra ariei de cuprindere și resurselor proiectului, cu scopul de a stabili durate, ca intrări pentru planul de proiect. Estimările vor fi elaborate progresiv, iar procesul ține cont de calitatea și disponibilitatea datelor de intrare. Estimarea se face utilizând metodologia drumului critic. • Dezvoltarea planului de activități înseamnă determinarea datelor de început și de sfârșit pentru activitățile de proiect. Dezvoltarea programului de activitate va fi iterativă (împreună cu procesele care furnizează intrări, mai ales estimarea duratei și estimarea costurilor) înainte de a determina planul de proiect. • Controlul planului de activități se ocupă cu influențarea factorilor care creează schimbări în program pentru a asigura că schimbările sunt agreate și gestionând schimbările efective”.  Arată că Drumul critic al proiectului reprezintă cea mai lungă secvență de activități dependente din proiect (dictează cel mai scurt timp posibil pentru finalizarea proiectului); modificarea duratei, a datei de start sau de finalizare a acestor activități conduce la nerespectarea datei de finalizare („întârzierea” proiectului). Prin urmare, marcarea corectă a drumului critic pe graficul Gantt este vitală pentru programarea eficientă a proiectului și alocarea resurselor. Entitatea contractantă susține că versiunea prezentată în motivare este cea din graficul Gantt inițial. În versiunea actualizată a graficului Gantt, transmisă în urma solicitărilor de clarificări, ca răspuns prin adresa ............................ cu nr. 407/ 30.01.2025 (fișierul Anexa 4 - Planul Gantt actualizat.pdf), singura activitate marcată critic este la linia 391. Prin urmare arată că drumul critic nu a fost marcat în graficul Gantt. În consecință, în cadrul factorului de evaluare F2.1 c) Corelarea planului de proiect cu metodologia de management de proiect, comisia de evaluare a ofertelor a apreciat că „corelarea între planul de proiect și metodologia utilizată în cadrul proiectului este cu deviații majore” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu este marcat corect drumul critic, activitatea Management Proiect este singura critică”. Referitor la critica ............................ privind motivul de depunctare de la: Pagina 61 din 171

„3.iv). Metodologia de management de proiect este prezentată in cap. 3.3.8 din Oferta tehnică (Anexa 2 la aceasta) dar riscurile specifice nu sunt tratate in planul de proiect”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Riscurile nu sunt menționate în graficul Gantt și nici în Anexa 3 - Metodologia OUM. În Anexa 2 - Metodologia de management al proiectului este inclus cap. 3.3.8 Managementul Riscului, care conține bune practici, iar în Formularul IV.4.1.a este detaliată cerința 24.2 Riscuri din Caietul de sarcini, fără analiza calitativă a riscurilor identificate de Entitatea Contractantă sau de Ofertant. Prin urmare, riscurile specifice implementării proiectului nu sunt tratate în planul de proiect. În consecință, în cadrul factorului de evaluare F2.1 c) Corelarea planului de proiect cu metodologia de management de proiect, comisia de evaluare a ofertelor a apreciat că „corelarea între planul de proiect și metodologia utilizată în cadrul proiectului este cu deviații majore” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În metodologia de management de proiect este prezentat managementul riscului (cap. 3.3.8), însă riscuri specifice nu sunt tratate în planul de proiect”. Subfactorul de evaluare nr. F2.1 d) „Realismul planului prin corelarea efortului estimat cu complexitatea activităților”. Referitor la critica ............................ privind motivul de depunctare de la: „4.i). Estimarea duratelor activităților nu este realistă. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Date fiind complexitatea și particularitățile proceselor HR din cadrul SNN, în special pentru activitățile de analiză de business pentru noile modele care se vor adăuga soluției, durata activităților nu a fost estimată realist în graficul Gantt. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Estimarea duratei nu este realistă pentru activitățile prezentate în graficul Gantt”. Referitor la critica ............................ privind motivul de depunctare de la: „4.ii). În planul de proiect avem analiza pentru Faza 2 în 2 luni, desfășurarea etapelor fiind prezentate secvențial.” Pagina 62 din 171

Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Prin Caietul de sarcini au fost solicitați 2 experți cheie pentru rolul Specialist în implementarea de tehnologii Oracle EBS HCM cu scopul de a permite, în special în faza II, desfășurarea activităților de analiză și configurare în paralel și astfel optimizarea timpului de implementare. Consideră că cele 6 noi module care se vor adăuga soluției nu sunt condiționate de multe interdependențe, iar cerințele de configurare pentru formulare conțin un număr mare de parametri. De asemenea, responsabilii proceselor de Resurse Umane care vor fi implicați în etapa de analiză de business diferă pentru fiecare dintre cele 6 noi module. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Din graficul Gantt rezultă că etapa de analiză pentru cele 6 noi module ale fazei II se va realiza secvențial, într-o perioadă de doar 2 luni”. Referitor la critica ............................ privind motivul de depunctare de la: „4.iii). Etapa de analiza pentru pontaje este de 4 zile”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Prin Caietul de sarcini a fost solicitat un singur expert pentru rolul de Analist de business HR, iar ofertantul a inclus 2 experți pentru a satisface cerințele minime de calificare: „(2) Analist de business HR (1 expert) Analistul de business va fi responsabil cu desfășurarea și documentarea etapei de analiză detaliată, descrierea proceselor de business HR, elaborarea specificațiilor tehnice și funcționale pentru implementarea produselor software Oracle EBS HCM, dar va participa și la etapele de testare, instruire utilizatori, acceptanță, garanție și suport tehnic. Cerințe minime: - studii superioare absolvite cu diplomă de licență sau echivalent; - competențe privind analiza de business dovedite prin cel puțin o certificare recunoscută la nivel național sau internațional; - experiență profesională specifică constând în activități de analiză de business, în cadrul a cel puțin 1 proiect finalizat de upgrade/migrare/ implementare produse software Oracle EBS, în ultimii 5 ani. Este imperios necesar ca experiența profesională de analist de business HR să fie dobândită în proiecte derulate în ultimii 5 ani raportat la data limită de depunere a Ofertelor, având în vedere că în domeniul IT, în special în cazul produselor software Oracle, progresul tehnologic este foarte rapid și sunt emise noi versiuni frecvent”. Pagina 63 din 171

Prin urmare, cei 2 experți desemnați în oferta tehnică vor fi responsabili împreună de execuția activităților de analiză de business. În ofertă au fost desemnați experții: - Florina Țarălungă, pentru care au fost îndeplinite cerințele de calificare, mai puțin cea referitoare la experiența în analiză de business pentru soluții Oracle EBS în HR în ultimii 5 ani; - Rodica Naca, pentru care a fost prezentat 1 proiect cu experiență relevantă pentru calificare. Cu toate acestea, planificarea din graficul Gantt nu prevede distribuirea sarcinilor de analiză între cei 2 experți, după cum se poate vedea la activitatea de la linia 27: În plus, ținând cont de motivele prezentate mai sus, în motivarea de la subfactorul F2.1 d) punctul ii), consideră că nu ar fi indicată o astfel de abordare de analiză în paralel pentru cerințele aceluiași modul (în acest caz pentru Pontaj), activitate în care ar trebui să fie implicați și responsabilii de Pontaj din partea Entității Contractante și cel puțin unul dintre experții desemnați pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM. Din complexitatea cerințelor solicitate prin cap. 5.2.4 din Caietul de sarcini referitoare la customizările și dezvoltările necesare pentru particularitățile entității contractante, prin comparație cu funcționalitățile standard oferite de modulul Oracle Time and Labor, se poate concluziona că modulul de Pontaj va necesita o perioadă mai mare de 4 zile pentru analiza de business. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Din graficul Gantt rezultă că etapa de analiză pentru modulul de Pontaj se va realiza în doar 4 zile”. Referitor la critica ............................ privind motivul de depunctare de la: „4.iv). Realizare upgrade Oracle pentru Faza 1 — 4 zile”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Dată fiind cerința din Caietul de sarcini, specialitate, la pag. 8: „(3) Arhitect de sistem Oracle EBS (1 expert) Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a Pagina 64 din 171

cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului.”, prin care se solicită ca rolul Arhitect de sistem Oracle EBS să fie responsabil de optimizarea și upgrade-ului sistemului de operare Oracle Linux și a Oracle HR, considerăm că în graficul Gantt, pentru activitatea de upgrade Oracle Linux pe cele 4 medii, ar fi trebuit repartizați experții de pe rolurile de Specialist în implementarea de tehnologii Oracle EBS HCM și Arhitect de sistem Oracle EBS.  În graficul Gantt, sarcinile corespunzătoare upgrade-ului de Oracle Linux sunt cele de la pozițiile 42 și 73, de unde rezultă că ar fi fost mai potrivit să fie repartizat același expert atât pentru proiectarea cât și pentru actualizarea Oracle Linux. Prin urmare, consideră că durata și rolul repartizat pentru această activitate nu au fost planificate corespunzător. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Din graficul Gantt rezultă că activitatea de upgrade Oracle Linux pe cele 4 medii se va realiza în doar 4 zile de către unul dintre experții cu rol de Specialist în implementarea de tehnologii Oracle EBS HCM, fără implicarea rolului Arhitect de sistem Oracle EBS”. Referitor la critica ............................ privind motivul de depunctare de la: „4.v). Durata trecerii în producție nu este corect dimensionată și nu include activități de pregătire a personalului SNN”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: 4.v) Din graficul Gantt rezultă că perioada pentru pregătirea trecerii în producție este de doar 4 zile: Faza I: - Acceptanță pe mediul de test: 14 august 2025 - Activare licențe pe mediul de producție: 15 august 2025 - Începere trecere în producție: 18 august 2025 Faza II: - Acceptanță pe mediul de test: 17 iulie 2026 - Activare licențe pe mediul de producție: 20 iulie 2026 - Începere trecere în producție: 21 iulie 2026 și nu sunt incluse activitățile de instruire a utilizatorilor finali (toți angajații SNN) de către echipa SNN. Serviciile de instruire în sarcina contractorului nu presupun cursuri pentru toți angajații SNN, ci conform Caietului de sarcini, cap. 5.1.3 Cerințe instruiri, pag. 15-16, fiecare sesiune se adresează la maxim 15 angajați: Pagina 65 din 171

„Furnizorul este responsabil pentru instruirea personalului desemnat de către SNN, după ce soluția este funcțională pe mediul de test. Pregătirea trebuie să permită utilizatorilor înțelegerea tuturor funcționalităților și operarea aplicației, precum și transferul informațiilor despre mentenanța de rutină care urmează a fi efectuată de către administratorii aplicației și de către cei de sistem. Sesiunile de instruiri vor cuprinde toate funcționalitățile soluției HR Management, astfel: Faza I: - 1 sesiune pentru administratorii de sistem (soluția Oracle HR Core extinsă și integrări); - 3 sesiuni pentru administratorii de aplicație (câte o sesiune pentru fiecare entitate a SNN: soluția Oracle HR Core extinsă și rapoarte). Faza II: - 1 sesiune pentru administratorii de sistem (module noi și integrări); - 3 sesiuni pentru administratorii de aplicație (câte o sesiune pentru fiecare entitate a SNN: module noi și rapoarte); - 3 sesiuni pentru rolurile speciale (câte o sesiune pentru fiecare entitate a SNN, de exemplu pentru rolurile de gestionare conflict de interese, responsabil de gestionarea informărilor și acordurilor privind prelucrarea datelor cu caracter personal, responsabil audit GDPR etc); - 3 sesiuni „train the trainer” (câte o sesiune pentru fiecare entitate a SNN: funcționalități ale modulelor noi pentru utilizatori: Self- Service, Pontaj, Evaluarea Performanțelor). [..] - fiecare sesiune va dura cel mult 5 zile și se va adresa către un număr de maxim 15 participanți; [... ] - ca urmare a numărului mare de utilizatori, sesiunile de instruire pentru utilizatori vor avea structura „train the trainer” și vor fi dedicate utilizatorilor-cheie, viitori instructori de utilizatori, cu următoarele obiective: modul de realizare a operațiilor uzuale pentru fiecare modul al soluției și prezentarea erorilor uzuale la operarea interfețelor aplicației;” Metoda de shadowing al experților implementatorului nu a fost prezentată în cadrul ofertei tehnice și nu este aplicabilă utilizatorilor finali, fiind mai potrivită pentru administratorii de aplicație și de sistem, în plus față de sesiunile de instruire. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Durata pentru pregătirea trecerii în producție nu este corect Pagina 66 din 171

dimensionată, graficul nu include activitatea de pregătire a utilizatorilor finali, în sarcina SNN”. Referitor la critica ............................ privind motivul de depunctare de la: „4.vi). Planul de proiect nu prezintă toate resursele implicate, ci doar experții cheie”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Ținând cont de faptul că la motivarea de la subfactorul F2.1 a) punctul viii) despre activități de testare prezentate în cap. 1.1.3 al Anexei 3 contestatoarea a precizat că sunt corelate cu unele activități de testare din graficul Gantt și: „Aceste acțiuni se vor efectua de către experții cheie alocați”, iar la motivarea subfactorul F2.1 b) punctul iv) despre aceleași activități de testare prezentate în cap. 1.1.3 al Anexei 3, care nu au fost solicitate prin Caietul de sarcini, contestatorul a menționat: „Astfel în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) _final.docx, la cap 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test, pe lângă experții cheie solicitați, sunt prezentate și alte roluri precum: - Managerul de testare - Analist de Testare - Designer de Testare - Proiectantul de Testare - Tester - Manager Configurație Aceste roluri prezentate în Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului pot fi asimilate experților non-cheie”, rezultă că nu au fost prezentate toate resursele în graficul Gantt care au fost desemnate ca roluri responsabile pe sub-activitățile de testare din cap, 1.1.3 al Anexei 3. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de implementare nu prezintă toate resursele implicate (alți specialiști în echipa de proiect), ci doar experții cheie solicitați prin Caietul de sarcini”. Referitor la critica ............................ privind motivul de depunctare de la: „4.vii). Nu sunt prezentate rolurile si sarcinile personalului SNN”. Pagina 67 din 171

Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Activitățile de la liniile 87 și 120 din graficul Gantt sunt singurele care fac referire la activități care includ la responsabili și echipa de proiect a beneficiarului, iar acestea rezultă direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Consideră că responsabili din partea entității contractante ar trebui să fie desemnați cel puțin pe activitățile de analiză de business, instruire utilizatori finali, validare documentație, corecții de date. Echipa de proiect a beneficiarului nu este inclusă în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu sunt prezentate roluri și sarcini pentru echipa SNN (echipa de proiect a beneficiarului este asignată doar pe sarcinile de testare de acceptanță)”. Subfactorul de evaluare nr. F2.1 e). „Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situașii neprevăzute”. Referitor la critica ............................ privind motivul de depunctare de la: „5.i). În planul de proiect nu este optimizată utilizarea resurselor, acestea fiind implicate secvențial”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Ținând cont de motivarea contestatorului de la subfactorul F2.1 d) punctul iii) privind distribuirea sarcinilor între 2 experți desemnați pe același rol, cum ar fi cel de Specialist în implementarea de tehnologii Oracle EBS HCM, pe care au fost solicitați 2 experți prin Caietul de sarcini, consideră că activitățile de analiză de business și de configurare, în special pentru modulele din faza II, se pot desfășura în paralel cu aplicarea metodelor și mijloacelor de gestionare a proiectului (ex.: identificarea corectă a dependențelor și constrângerilor între activități), pentru optimizarea alocării resurselor și a timpului de implementare și asigurarea unei rezerve de resurse pentru situații neprevăzute. În consecință, în cadrul factorului de evaluare F2.1 e) Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute, comisia de evaluare a ofertelor a apreciat că „Planul de proiect nu demonstrează că ofertantul a optimizat utilizarea resurselor. Pagina 68 din 171

Planificarea activităților nu permite flexibilitate pentru situații neprevăzute”, și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Activitățile sunt planificate secvențial (de ex. pentru analiză și pentru configurare module în faza II), chiar dacă sunt desemnați 2 experți pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM”. Referitor la critica ............................ privind motivul de depunctare de la: „5.ii). Planificarea nu permite flexibilitate pentru activități neprevăzute”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: „Marja de flexibilitate” menționată în motivație de contestator nu este inclusă ca elemente de descriere în oferta tehnică, ea fiind prezentată în premieră în cadrul contestației, fapt care conduce iar către un caracter manipulator al contestatorului, iar planificarea activităților a fost realizată secvențial în graficul Gantt. În consecință, în cadrul factorului de evaluare F2.1 e) Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute, comisia de evaluare a ofertelor a apreciat că „Planul de proiect nu demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților nu permite flexibilitate pentru situații neprevăzute.” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Activitățile sunt planificate secvențial, nu se suprapun”. Referitor la critica ............................ privind motivul de depunctare de la: „5.iii). Activitatea de proiectare începe după activitatea de analiza. In procedura ORACLE aceste se realizează în paralel — Linia 41 din Gant este condiționată de realizarea liniei 20 din GANTT”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Motivarea din contestație nu este inclusă în oferta tehnică. La analiza ofertei, s-a constatat ca planificarea activităților nu respectă principiile metodologiei selectate (OUM), activitățile fiind planificate exclusiv secvențial. Mai mult, în planul de implementare nu au fost incluse activități de îmbunătățire a soluției existente, la începutul fazei I, care puteau include și activități din etapa de proiectare în paralel cu cele de analiză, cu scopul de optimizare a alocării resurselor și timpului de implementare și asigurarea calității livrabilelor proiectului. În consecință, în cadrul factorului de evaluare F2.1 e) Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute, comisia de evaluare a ofertelor a apreciat că „Planul de proiect nu demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților nu permite flexibilitate pentru situații Pagina 69 din 171

neprevăzute” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Activitatea de Proiectare a soluției tehnice începe după activitatea de Analiză din faza I (în graficul Gantt, linia 41 este condiționată de linia 20), însă etapa de Proiectare poate fi inițiată la începutul fazei I prin propuneri de optimizare a soluției existente”. Subfactorul de evaluare nr. F2.1 f) „Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat”. Referitor la critica ............................ privind motivul de depunctare de la: „6.i). Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități, chiar dacă tehnic se pot executa în paralel și metodologia Oracle prevede aceasta practică”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Motivarea din contestație nu este inclusă în oferta tehnică; de asemenea, oferta tehnică nu demonstrează cum se asigură flexibilitatea în cadrul proiectului aplicând metodologia aleasă. Metodologia OUM, descrisă în Anexa 3, este de tip Agile și presupune o abordare iterativă a activităților de analiză, proiectare, configurare și deployment, în opoziție cu implementările de tip Waterfall în care etapele sunt parcurse secvențial, fără a se reveni la analiză și proiectare și fără optimizare prin distribuirea către mai multe sub-echipe (vezi standardele profesionale „Project Management Institute. 2021. A Guide to the Project Management Body of Knowledge (PMBOK Guide) -- Seventh Edition and The Standard for Project Management” și „Project Management Institute. 2019. Agile Practice Guide „.) În consecință, în cadrul factorului de evaluare F2.1 f) Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat, comisia de evaluare a ofertelor a apreciat că „Planul de proiect demonstrează că ofertantul nu a fost preocupat de optimizarea duratei proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat, dar respecta termenul de prestare solicitat prin caietul de sarcini.” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități chiar dacă tehnic se pot executa în paralel și metodologia prevede această practică;”. Referitor la critica ............................ privind motivul de depunctare de la: „6.ii). Cu mici excepții activitățile au un singur predecesor, activități anterioare, iar restul sunt de tip finish to start”. Referitor la motivarea din contestație entitatea contractantă precizează următoarele: Metodologia OUM este de tip Agile și presupune o abordare iterativă a activităților de analiză, proiectare, configurare și deployment, în Pagina 70 din 171

opoziție cu implementările de tip Waterfall în care etapele sunt parcurse secvențial, fără a se reveni la analiză și proiectare și fără optimizare prin distribuirea către mai multe sub-echipe. În consecință, în cadrul factorului de evaluare F2.1.f) Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat, comisia de evaluare a ofertelor a apreciat că „Planul de proiect demonstrează că ofertantul nu a fost preocupat de optimizarea duratei proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat, dar respectă termenul de prestare solicitat prin caietul de sarcini.” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „cu mici excepții, activitățile au un singur predecesor, activitatea anterioară, iar relația este FS (Finish to Start)”. - Pentru critica de la punctul E. din contestație, „Oferta tehnică ............................S.A. este neconformă deoarece nu a fost completată corespunzător cerințelor de la cap. 5.1 Cerințe generale din Caietul de sarcini”. Pentru criticile formulate în contestație de ............................ la art. [36] - [39] Entitatea contractantă consideră ca aceste critici sunt nefondate pentru următoarele motive: Din nou consideră lipsită de fond afirmația petentei, având în vedere că la analiza propunerii tehnice comisia a luat în considerare toate informațiile prezentate în Formularul IV.4.1 de propunere tehnică respectiv la art. 5.1. Cerințe generale din Caietul de sarcini în Anexa la Formular, ofertantul ............................SA, precizând următoarele: „Datorită volumului foarte mare de informații dar și al faptului că echipa Cancom a dorit sa abordeze mult mai complex fiecare cerință ridicată de către autoritatea contractantă și existând riscul de a afecta formatarea capitolelor din prezenta matrice, a fost generată și o ANEXA TEHNICA numită ANEXA 1 - OFERTA TEHNICA DETALIATA. Aceasta anexă prezintă într-un mod complex și organizat toate elementele pe care le-am considerat necesare dar esențiale pentru buna desfășurare a proiectului”. În acest fel, afirmațiile contestatorului sunt simple alegații care încearcă să deturneze Consiliul de la o judecată corectă activitatea și modul în care comisia de evaluare a înțeles să evalueze ofertele și să declare conformă oferta Cancom. Astfel acolo unde în cadrul Formularului IV 4.1 se regăsesc afirmații de tipul: „confirmăm îndeplinirea cerinței”, „am luat la cunoștință” detalierea modului în care este îndeplinită cerința se regăsește asumat, structurat și detaliat în ANEXA 1 - OFERTA TEHNICA DETALIATA, fapt ce a conferit comisiei de evaluare o confidență mult mai mare decât cea prin care ............................ a dovedit-o prin transcrierea cerinței Caietului de sarcini aproape „ad literam”. Având în vedere cele menționate mai sus, solicită Consiliului să respingă susținerile contestatorului ca neîntemeiate și nefondate. Pagina 71 din 171

Prin adresa nr. 1914/20.05.2024, înregistrată la CNSC sub nr. 33232/21.05.2025 ............................SRL transmite Concluzii scrise ca urmare a studierii dosarului cauzei la CNSC. I. În ceea ce privește punctul de vedere al autorității contractante, referitor la nerespectarea prevederilor art. 228 din Legea nr. 99/2016 privind transmiterea comunicării rezultatului procedurii, respectiv punctul C din contestație. Contrar celor afirmate de autoritatea contractantă, solicită Consiliului să constate că aceasta nu a respectat prevederile art. 228 alin. (2) lit. c) din Legea nr. 99/2016 în ceea ce privește conținutul comunicării rezultatului procedurii. Arată că din conținutul comunicării rezultatului procedurii pe care autoritatea contractantă l-a redat în punctul de vedere se poate observa că aceasta s-a limitat la a preciza punctajul primit de oferta sa și oferta declarată câștigătoare, precizând că oferta sa „nu a fost declarată câștigătoare deoarece oferta declarată câștigătoare a obținut un punctaj total mai mare în comparație cu oferta noastră”. Or, raportat la prevederile art. 228, alin. (2), lit. c) din Legea nr. 99/2016, autoritatea contractantă avea obligația de a preciza concret caracteristicile și avantajele relative ale ofertei/desemnate câștigătoare în raport cu oferta sa, în sensul de a prezenta aspectele tehnice aferente factorilor de evaluare din oferta declarată câștigătoare pentru care aceasta a obținut un punctaj mai mare în urma aplicării criteriul de atribuire raportat la oferta sa. Pentru aceste considerente își menține critica adusă prin contestație, respectiv că autoritatea contractantă nu a respectat dispozițiile legale anterior referite cu privire la conținutul comunicării rezultatului aferent ofertei sale. II. În ceea ce privește punctul de vedere al autorității contractante, referitor la punctul D. din contestație, privind situația pe fond, netemeinicia

și

nejustificarea

depunctării

ofertei Asocierii ............................SRL – ............................SRL, pentru componenta tehnică. II.1 Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul i). – „Riscurile nu sunt tratate din punct de vedere impact și nici al probabilităților de expunere la risc”. Analizând punctul de vedere transmis de autoritatea contractantă prin adresa nr. E- E-DA- PCTVED-CONTEST-01091 din data de 05-05-25, cu privire la acest punct din contestația sa, apreciază în continuare că motivul invocat de către autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat, pentru motivele expuse în continuare. Cu privire la acest aspect arată că prevederile din caietul de sarcini (cap. 24 - Ipoteze și riscuri, pag. 49) solicită ca ofertanții să: „estimeze Pagina 72 din 171

posibilele efecte ale riscurilor și să ia în considerare resursele necesare pentru implementarea strategiilor de risc”. Consideră că această cerință a fost integral acoperită în oferta sa, în mod structurat și justificat, în două secțiuni distincte: • În Anexa 2 - Metodologia de management de proiect, cap. 3.3.8, a prezentat metodologia completă de tratare a riscurilor, care include explicit: o evaluarea impactului și a probabilității riscurilor (analiza calitativă și cantitativă), o prioritizarea riscurilor în funcție de efectele potențiale asupra obiectivelor proiectului, o identificarea și alocarea resurselor necesare (inclusiv costuri, timp, rezerve de contingență) pentru tratarea riscurilor. Acest capitol nu se limitează la definiții generale, ci oferă un cadru metodologic clar pentru tratarea riscurilor, în conformitate cu standardele de proiect management (PMBOK). • În Anexa IV.1 - secțiunea 24 - Ipoteze și riscuri, a realizat: o o identificare detaliată a riscurilor prevăzute în Caietul de sarcini, o o extindere a listei de riscuri relevante, identificate în plus față de cele cerute, o pentru fiecare risc, a oferit măsuri concrete de prevenție și tratare, o a menționat clar alocarea responsabilității pentru fiecare risc între părți. Deși evaluarea entității contractante susține că, în oferta depusă, nu a estimat impactul și probabilitatea apariției unor riscuri, consideră că această concluzie este eronată și formalistă, întrucât: o metodologia descrisă în Anexa 2 stabilește criteriile de analiză și evaluare (probabilitate + impact), o riscurile din Anexa IV.1 sunt tratate prin măsuri de reducere, ceea ce presupune în mod implicit o analiză de severitate (impact + probabilitate), o în oferta sa nu s-a realizat doar o listare de riscuri, ci o abordare integrată între identificare, alocare, tratare și prevenire. Subliniază că, deși comisia de evaluare recunoaște existența riscurilor tratate în Anexa IV.1, aceasta a ales să ignore metoda de analiză și tratament prezentată în Anexa 2, motivând o presupusă lipsă de conexiune între cele două. Apreciază că această abordare exceda cerințelor caietului de sarcini și impune standarde formale neprevăzute, afectând astfel principiul proporționalității și transparenței în evaluare. În opinia sa prezentarea organizată a informațiilor este o chestiune de formă, nu de fond. Esențial este dacă riscurile sunt tratate conform cerințelor - ceea ce, în cazul său, este evident din conținutul celor două anexe complementare. Pagina 73 din 171

Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației formulate cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale cu privire la subfactorul F2.1 a). II.2 Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul ii). – „Nu este descrisă arhitectura sistemului”. Analizând punctul de vedere transmis de autoritatea contractantă prin adresa nr. E- E- DA-PCTVED-CONTEST-01091 din data de 05-05-25, cu privire la acest punct din contestația sa, apreciază în continuare că motivul invocat de către autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat, pentru următoarele motive: • Obiectul evaluării la acest sub-factor (F2.1 a) este clar definit ca fiind „gradul de detaliere a planului de proiect și a metodologiei de implementare”, conform Documentației de atribuire. Acesta nu presupune în mod expres descrierea arhitecturii sistemului, care este prevăzută separat, la nivel de livrabil, în etapa de implementare, potrivit cerinței din capitolul 5.1.2.13 - „Cerință administrare” din Caietul de sarcini. • Descrierea arhitecturii sistemului este menționată ca livrabil, nu ca element care trebuie detaliat în planul de proiect sau în metodologia de implementare. În cadrul ofertei tehnice (Anexa la Formularul IV.4.1, pag. 41-53), susține că a asumat livrarea documentației privind arhitectura sistemului, conform cerințelor caietului de sarcini: - tehnologii folosite; - diagrame logice și fizice; - interfețe de comunicare; - porturi și protocoale etc. În opinia sa acest angajament este suficient pentru demonstrarea conformității ofertei, în contextul în care detalierea tehnică completă a arhitecturii nu era cerută ex ante, ci doar livrată în faza de implementare. • Menționarea livrabilului în Anexa 1 (Formularul IV.4.1.a, cap. 5.1.2.13) arată clar că a înțeles și asumat cerințele din caietul de sarcini, inclusiv în ceea ce privește arhitectura sistemului. • În mod contrar evaluării obiective, comisia de evaluare a apreciat că metodologiei sale îi lipsește „descrierea arhitecturii sistemului”, deși: o aceasta nu era cerută expres în metodologia de implementare; o a furnizat activități relevante în metodologia de implementare, inclusiv prototiparea arhitecturală, ca practică standard OUM pentru a adapta arhitectura la contextul existent; Pagina 74 din 171

o metodologia sa a fost una standard, adaptabilă, nu generalistă, întrucât a fost structurată pe procese OUM și a inclus activități de analiză și integrare a sistemelor existente. • Este incorectă interpretarea comisiei de evaluare conform căreia „prototiparea arhitecturală” ar presupune dezvoltarea unui sistem complet nou. În contextul metodologiei OUM, această activitate este utilizată inclusiv în proiecte de extindere pentru a verifica compatibilitatea și a simula modificările necesare arhitecturii existente. • Graficul Gantt nu a inclus separat această activitate pentru că prototiparea este o activitate transversală, de suport pentru analiza tehnică, nu o etapă independentă. Acest lucru este în concordanță cu practicile de planificare ale proiectelor informatice bazate pe metodologii Agile sau iterative. • Comentariul comisiei privind lipsa corelării cu arhitectura existentă nu ține cont de faptul că datele respective au fost tratate în secțiunile aferente planificării și analizării cerințelor, iar platforma existentă (Oracle Linux, Oracle DB, Oracle EBS) a fost menționată ca premisă a extinderii propuse. Sintetizând aspectele mai sus menționate, apreciază că: o Cerința privind descrierea arhitecturii sistemului trebuie tratată ca livrabil, nu ca element de detaliere în metodologie; o A furnizat un răspuns coerent, complet și în acord cu caietul de sarcini; o Aspectele reținute de Comisia de evaluare reflectă o apreciere subiectivă a acestui factor și nu un criteriu clar de excludere sau depunctare obiectivă. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale cu privire la acest punct. II.3 Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare punctul iii). – „Metodologia OUM este descrisă în termeni generali”. Astfel, consideră că în mod neîntemeiat, autoritatea contractantă a depunctat oferta sa cu motivarea că metodologia OUM este descrisă în termeni generali, pentru următoarele considerente: • Structura metodologiei prezentate de societatea sa în cadru propunerii tehnice, este împărțită în două părți: o În capitolul 1 (pag. 3-14 din Anexa 3), a prezentat cadrul general al metodologiei Oracle Unified Method (OUM), pentru a fundamenta alegerea metodei și a introduce conceptele utilizate în proiect. Pagina 75 din 171

o În capitolul 1.1 (pag. 15-69), a adaptat metodologia OUM la specificul concret al proiectului propus, structurând implementarea conform etapelor cerute de caietul de sarcini. Subcapitolele 1.1.1-1.1.8 tratează pe larg: - proiectarea soluției, - analiza cerințelor, - integrarea sistemelor existente, - tratarea riscurilor și dependențelor, - planificarea testării și validării etc. • Afirmația că „metodologia este descrisă în termeni generali” ignoră conținutul detaliat din capitolul 1.1, care reprezintă tocmai adaptarea specifică a metodologiei propuse la proiectul vizat (extindere Oracle HR în cadrul SNN). Aprecierea comisiei pare să se bazeze exclusiv pe capitolul introductiv, care are rol de cadru teoretic și de referință. • Lipsa numerotării continue între capitole nu afectează coerența logică a documentului. Capitolul 1.1 continuă explicit tematica capitolului 1, iar legătura dintre secțiuni se face prin conținut și structură, nu doar prin numerotare. De altfel, titlurile subcapitolelor 1.1.1-1.1.8 corespund cerințelor din caietul de sarcini, fiind ușor de urmărit și corelat. • Afirmația că subcapitolele 1.1.1-1.1.8 „nu au legătură” cu capitolul 1 este eronată, întrucât întreaga structură metodologică urmează fluxul OUM adaptat. Astfel, conținutul oferit este: o Structurat pe procesele OUM (Business Requirements, Analysis, Design, Implementation etc.); o Personalizat pentru mediul tehnologic Oracle EBS deja existent; o Corelat cu etapele și cerințele din caietul de sarcini, inclusiv integrarea arhitecturii existente. • Gradul de detaliere este adecvat cerințelor de evaluare, în special prin: o explicitarea etapelor și activităților, o descrierea livrabilelor pentru fiecare fază, o abordarea riscurilor și interdependențelor, o prezentarea modului de gestionare a resurselor. În acest context, consideră că aprecierea metodologiei de către comisia de evaluare ca fiind „descrisă în termeni generali” este nejustificată, iar evaluarea acestui subfactor nu reflectă realitatea conținutului ofertei sale, deoarece: o A structurat metodologia în conformitate cu cerințele din caietul de sarcini; o A adaptat clar OUM la specificul proiectului; o Documentul oferă informații detaliate, coerente și ușor de corelat cu etapele de implementare. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și Pagina 76 din 171

motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.4 Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul iv). – „Capitolele nu sunt numerotate și legătura dintre acestea se poate intui doar prin denumirea etapei”. Astfel, consideră că în mod neîntemeiat, autoritatea contractantă a depunctat oferta sa pentru lipsa de numerotare a capitolelor și pentru presupusa lipsă de coerență între etapele descrise, pentru următoarele motive: • În documentul Anexa 3 - Metodologia de implementare Oracle (OUM), capitolele sunt numerotate și structurate logic. Prezintă mai jos un extras din cuprinsul acestuia pentru clarificare. După cum se poate observa din extrasul prezentat, conținutul și ordinea secțiunilor sunt numerotate și structurate logic. Exemplu: o Cap. 1: Metodologia de implementare OUM - Oracle Unified Methodology (pag. 3-14); o Cap. 1.1: Metodologia de implementare și mentenanță adaptată la specificul proiectului (pag. 15-69), cu subcapitole 1.1.1 - 1.1.8; o Cap. 1.2: Planul de implementare (pag. 70-75), care include graficul Gantt și graficul de facturare. În opinia sa această structură respectă cerințele de organizare logică și facilitează parcurgerea documentului, contrar afirmației că „nu sunt numerotate capitolele”. Subcapitolele 1.1.1 - 1.1.8, deși nu corespund mecanic etapelor OUM standard, reflectă adaptarea metodologiei OUM la cerințele proiectului SNN și la structura impusă prin caietul de sarcini - ceea ce este o abordare justificată și conformă bunelor practici de implementare. • Graficul Gantt din cap. 1.2 prezintă succesiunea etapelor de implementare conform planificării temporale, iar corelarea cu descrierile detaliate din secțiunile anterioare este clară prin denumirea etapelor. Menționează că Gantt-ul nu este menit să redea metodologia detaliată, ci doar calendarul execuției - metodologia fiind descrisă extensiv în cap. 1.1. • Referirea comisiei la lipsa de legătură între Anexa 3 și Anexa 2 (Metodologia de management de proiect) este irelevantă în contextul în care el nu a invocat Anexa 2 ca justificare pentru metodologia OUM, ci doar pentru a arăta caracterul consecvent al structurării și numerotării documentelor din ofertă. În acest context, consideră că depunctarea ofertei sale pe motivul că „capitolele nu sunt numerotate” și că „legătura se poate doar intui” este nejustificată, întrucât: o Documentul are structură numerotată clară și logică; Pagina 77 din 171

o Metodologia este adaptată coerent la proiect și cerințele autorității contractante; o Gantt-ul reflectă succesiunea activităților, fără a dubla descrierile din metodologie. Prin urmare, solicită Consiliului să dispună reevaluarea ofertei sale sub acest aspect, întrucât nu se justifică acordarea unui punctaj diminuat pe baza unei percepții eronate privind forma și coerența documentului depus. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.5 Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect si al metodologiei de implementare”, punctul v). – „Planul de proiect este în mică măsură corelat cu planul GANTT, sunt diferențe majore între activități și livrabile și sunt necorelate”. Consideră că motivul pentru care autoritatea contractantă a depunctat oferta sa este nejustificat, deoarece planul de proiect (GANTT) prezentat de societatea sa este corelat în mod logic și funcțional cu metodologia de implementare propusă și respectă cerințele caietului de sarcini. • Conform cerințelor Subfactorului F2.1.a), gradul de detaliere trebuia evaluat atât pentru planul GANTT, cât și pentru metodologia de implementare. Societatea sa a prezentat ambele componente în cadrul documentului Anexa 3 - Metodologia de implementare Oracle (OUM), respectiv: o Cap. 1.1: Metodologia de implementare și mentenanță adaptată la specificul proiectului - care detaliază abordarea tehnică și procedurală; o Cap. 1.2: Planul de implementare, incluzând Graficul GANTT, care transpune activitățile și livrabilele într-un calendar fezabil. • Planul GANTT reflectă structura logică a proiectului, astfel încât să asigure: o respectarea etapelor propuse prin metodologia OUM; o corelarea activităților cu livrabilele; o includerea activităților care implică atât echipa sa, cât și echipa SNN, acolo unde este prevăzut în caietul de sarcini. Ca exemplu, activitățile „Efectuare testare de acceptanță pe mediul de test - Faza I” (linia 87) și Faza II (linia 120) sunt explicit corelate cu cerințele de la Cap. 10 din Caietul de sarcini, care prevăd implicarea Entității Contractante în procesul de testare. o Planul GANTT nu are scopul de a replica textual metodologia, ci de a reprezenta succesiunea în timp a etapelor, activităților și livrabilelor, pentru o viziune de ansamblu. Legătura dintre acestea este Pagina 78 din 171

logică, iar diferențele de formă menționate de comisie nu constituie lipsă de corelare, ci o adaptare funcțională la structura impusă de proiect. o Constatările comisiei privind faptul că „activitățile și livrabilele diferă” sunt nefondate, în condițiile în care activitățile prezentate în metodologia de implementare sunt reflectate în GANTT, cu alocarea corespunzătoare a duratei, resurselor și livrabilelor. Astfel, susține că planul GANTT prezentat este în concordanță cu metodologia de implementare propusă, respectă structura de livrabile, implicările ambelor părți și termenele prevăzute în Caietul de sarcini. Argumentul privind „diferențe majore între activități și livrabile” nu reflectă realitatea documentelor transmise și constituie un motiv nejustificat de depunctare. Solicită, așadar, Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, întrucât îndeplinește cerințele prevăzute în documentația de atribuire și demonstrează o înțelegere completă și coerentă a proiectului. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.6. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul vi). — „Activități și subactivități din planul de proiect nu se regăsesc în metodologie și GANTT”. Consideră că argumentul invocat de autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat, întrucât documentația tehnică depusă de societatea sa demonstrează coerență, consistență și corelare între Metodologia de implementare, Planul de proiect (GANTT) și cerințele caietului de sarcini. Astfel: • În Anexa 3 - Metodologia de implementare Oracle (OUM), a structurat și detaliat activitățile și subactivitățile relevante în cadrul Capitolului 1.1 - Metodologia de implementare și mentenanță adaptată la specificul proiectului, respectând cerințele de conținut impuse de autoritatea contractantă. • În Capitolul 1.2 - Planul de implementare, este prezentat Graficul GANTT, care transpune în mod logic și cronologic activitățile și livrabilele identificate în metodologia de implementare. Structura GANTT-ului urmează etapele proiectului, detaliind sarcini, responsabilități și termene aferente. • Afirmația potrivit căreia „activitățile prezentate în cap. 1.1 sunt nestructurate și nu se regăsesc în GANTT” este nejustificată, deoarece: Pagina 79 din 171

o Activitățile de testare menționate între paginile 43-48 din metodologia propusă sunt reflectate și în GANTT, la etapele de testare aferente Fazei I și Fazei II, conform liniei 87, respectiv 120. o Detalierea unor activități în metodologie servește unei mai bune înțelegeri a abordării tehnice și nu exclude reprezentarea lor condensată în GANTT, adaptată formei de planificare temporală. o Societatea sa a inclus activități suplimentare (ex. integrare versiuni) pentru a reflecta bune practici și riscuri anticipate în proiecte informatice complexe; o Aceste activități nu sunt irelevante, ci vin în completarea cerințelor minime, pentru a demonstra înțelegerea complexității și asigurarea unui control eficient al livrabilelor. În concluzie, activitățile, subactivitățile și livrabilele propuse sunt coerente, justificate și corelate între metodologia de implementare și Planul de proiect (GANTT). Diferențele de granularitate nu afectează înțelegerea sau fezabilitatea planului, ci oferă un nivel suplimentar de detaliu și control. În acest context, solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, întrucât aprecierea „Acceptabilă” nu reflectă conținutul real și complet al ofertei tehnice, iar motivul invocat pentru depunctare este lipsit de temei. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.7. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul vii). — „Planul de proiect conține livrabile irelevante pentru etapa de testare „ Consideră că motivul invocat de autoritatea contractantă pentru depunctarea ofertei sale este nefundamentat, întrucât toate livrabilele prezentate pentru etapa de testare sunt relevante, necesare și conforme cu cerințele caietului de sarcini și cu bunele practici în domeniul proiectelor IT de complexitate ridicată. • Toate livrabilele expres solicitate în caietul de sarcini pentru etapa de testare au fost clar identificate și integrate în: o Metodologia de implementare OUM (Anexa 3 - Cap. 1.1.3); o Planul de proiect (GANTT - Cap. 1.2.1). Livrabilele respective includ: o Planuri și rapoarte de testare pentru Faza I și Faza II; o Documentație aferentă testării de acceptanță, inclusiv pentru mediul de test. • În ceea ce privește livrabilele suplimentare invocate de entitatea contractantă ca fiind „irelevante” (ex. Planul de integrare a versiunilor, Pagina 80 din 171

Planul general de testare, Planul de proiectare), menționează următoarele: o Acestea sunt instrumente standard în cadrul metodologiei Oracle Unified Method (OUM), utilizate pentru gestionarea riscurilor și asigurarea calității; o Ele nu se substituie livrabilelor solicitate prin caietul de sarcini, ci contribuie la coerența metodologică și controlul integrat al procesului de testare și livrare; o Existența acestor documente demonstrează o abordare profesionistă, care depășește strictul minim impus de documentația de atribuire, fără a contraveni acestuia. • Observația privind lipsa indicării momentului elaborării anumitor documente (ex. Planul general de testare) nu reflectă o neconformitate, ci este caracteristică metodologiilor iterative, unde anumite livrabile sunt: o Predefinite ca artefacte reutilizabile (de ex., din fazele anterioare ale ciclului de viață); o Create prin activități de tip „rolling wave planning”, care nu sunt întotdeauna detaliate în GANTT la nivel de document individual. Societatea sa a prezentat, atât în metodologie, cât și în GANTT, toate livrabilele relevante pentru etapa de testare, conforme cu cerințele minime ale caietului de sarcini și cu bunele practici în implementarea proiectelor informatice. Așa-numitele livrabile „irelevante” sunt în realitate documente de control, integrare și calitate, perfect justificate în contextul metodologiei OUM și contribuie la o implementare riguroasă și predictibilă. Prin urmare, apreciază că evaluarea drept „Acceptabilă” este vădit disproporționată și solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, în vederea reflectării corecte a conținutului și calității documentației tehnice prezentate. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestație cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.8. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul viii). — „Activitatea de testare — nu conține acțiuni pentru rezolvarea problemelor la testare și nici o analiză a rezultatelor obținute și modul în care se pot rezolva”. Analizând aspectele invocate de autoritatea contractantă în punctul de vedere transmis, apreciază că depunctarea ofertei sale în cadrul factorului de evaluare F2.1 a), pentru presupusa lipsă a activităților de analiză a rezultatelor testării și de remediere a problemelor identificate, Pagina 81 din 171

este neîntemeiată și rezultă dintr-o interpretare restrictivă a metodologiei propuse, respectiv Oracle Unified Method (OUM). În documentația tehnică transmisă - Anexa 3 _Metodologia de implementare Oracle (OUM)_final.pdf, Capitolul 1.1.3 „Etapa de configurare, testare și acceptanță pe mediul de test” (paginile 43-48), susține că au fost prezentate detaliat toate activitățile de testare prevăzute în metodologia OUM, inclusiv: o Definirea misiunii evaluării o Verificarea abordării testării o Implementarea mediului intern de testare o Validarea stabilității artefactului testat o Testarea și evaluarea artefactului testat o Îmbunătățirea artefactelor de testare. Aceste etape includ, în mod inerent, identificarea și corectarea problemelor apărute în timpul testării, precum și ajustarea cazurilor, procedurilor sau scripturilor de testare. Activitatea de îmbunătățire a artefactelor de testare presupune explicit încorporarea lecțiilor învățate în urma testării și ajustarea corespunzătoare a soluției. În Planul de proiect - Gantt, la: - Linia 85: „Efectuarea de reconfigurări necesare după testarea internă pe mediul de test” - Linia 118: „Efectuarea de reconfigurări și dezvoltări necesare după testarea internă pe mediul de test”. Precizează că aceste activități indică în mod direct existența unui mecanism de răspuns la problemele apărute în timpul testării și implementarea corecțiilor necesare înainte de testarea finală. Acțiunile respective sunt realizate de experți cheie, în urma unei analize a rezultatelor obținute. Subliniază că, în metodologia OUM, procesul de testare este unul iterativ, iar analiza rezultatelor și aplicarea corecțiilor nu sunt prezentate ca o fază formală separată (cum ar fi „Test Results Analysis” în TMAP sau ISTQB), ci sunt integrate în mod natural în fluxul testare- remediere- retestare. Este important să menționeze că: o Metodologia OUM este una agreată internațional și utilizată în implementări Oracle la scară largă; o Lipsa unei denumiri explicite a unei etape de analiză a testării nu echivalează cu absența procesului în sine; o Activitățile de testare din metodologie și din Gantt converg în livrabilele cerute și respectă scopul cerințelor din caietul de sarcini. De altfel, susține că evaluarea unei metodologii ar trebui să se bazeze pe substanța activităților propuse și nu doar pe denumirea sau organizarea lor formală, conform principiului echivalenței funcționale între metodologii. Pagina 82 din 171

În acest context, consideră că motivul depunctării este nejustificat, întrucât: o au fost descrise în mod concret și adecvat acțiuni de remediere în urma testării; o metodologia oferă acoperire pentru activitățile de analiză și îmbunătățire, chiar dacă nu într-o etapă explicit denumită; o planul de proiect este corelat logic și cronologic cu metodologia propusă. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.9. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul ix). — „În Gantt nu sunt asignați responsabilii pe elaborarea livrabilelor”. Analizând aspectele invocate de autoritatea contractantă în punctul de vedere transmis, consideră că depunctarea ofertei sale pe motivul că „în graficul Gantt nu sunt asignați responsabilii pentru elaborarea livrabilelor” este neîntemeiată și nu reflectă în mod corect conținutul și structura documentației depuse. În Planul de proiect - Gantt, susține că a desemnat pentru fiecare activitate și subactivitate un responsabil, conform rolului tehnic aferent. Fiindcă livrabilele sunt rezultatul direct al acestor activități, este logic și practic ca responsabilul activității să fie implicit și responsabilul livrabilului corespunzător. Acest principiu este reflectat clar în structura Gantt, astfel cum se poate observa, cu titlu de exemplu: o Linia 42: Activitatea „Design soluție optimizată și upgrade-ata” este alocată Specialistului Oracle EBS HCM 2; o Liniile 44-46: Livrabilul „Documentația despre arhitectura sistemului” rezultă direct din activitatea menționată anterior, fiind, în mod firesc, în responsabilitatea aceluiași expert tehnic. Consideră că repetarea formală a responsabililor pe fiecare linie de livrabil ar fi fost redundantă, dat fiind că sunt clar desemnați în cadrul activităților din care rezultă respectivele livrabile. Această abordare este, de altfel, frecvent utilizată în bunele practici de management de proiect, în special când există o trasabilitate evidentă între activități și rezultate. Menționează că, deși în răspunsul la solicitarea de clarificări nu au fost inserați în Gantt toți responsabilii nominali pentru fiecare livrabil, oferta sa a fost construită în mod unitar și coerent, cu precizarea rolurilor implicate în toate livrabilele, în corelare cu activitățile din Gantt și cu Anexele 2 și 3 (metodologiile). Această abordare reflectă, în opinia Pagina 83 din 171

sa, modul în care un plan integrat de proiect trebuie evaluat - pe baza coerenței întregii documentații, nu doar a unui singur fișier. Pe de altă parte, susține că solicitarea de completare ulterioară nu avea caracter de corecție a unui viciu formal esențial, ci de detaliere suplimentară, iar faptul că nu s-au duplicat aceleași informații nu ar trebui să atragă o sancțiune de punctaj, atâta timp cât în oferta tehnică: o au fost identificați responsabili pentru toate activitățile relevante; o livrabilele sunt clar legate de activități din care derivă logic și cronologic; o rolurile experților propuși sunt descrise corespunzător în metodologia de implementare. În ceea ce privește observația comisiei referitoare la activitatea de la linia 42 - și presupusa alocare eronată a rolului „Specialist în implementarea Oracle EBS HCM 2” în locul „Arhitectului de sistem Oracle EBS” - consideră că această interpretare ignoră distribuirea complementară a sarcinilor între experții-cheie propuși. Activitatea menționată a fost planificată cu participarea unei echipe multidisciplinare, în care și specialistul menționat are atribuții în dezvoltare și configurare, sub avizarea Arhitectului de sistem, conform Anexei 2. Dacă ar fi existat neclarități asupra rolului principal sau a delimitării între „responsabil” și „avizator”, acestea puteau fi soluționate prin solicitări de clarificare, fără a impune o penalizare. Observația privind poziționarea greșită a acestui livrabil în Faza I și nu în Faza II este formalistă și nu reflectă întregul conținut al livrabilului. Menționarea acestuia în Gantt a fost făcută anticipativ, ca parte a unei abordări iterative în redactarea documentației tehnice, practică frecventă în proiectele IT de complexitate ridicată. În documentația tehnică, versiuni parțiale ale documentației de arhitectură pot apărea încă din etapele incipiente pentru validare și corectare ulterioară în Faza II, ceea ce este în deplină concordanță cu bunele practici de proiectare software și IT governance. În acest context, consideră că abordarea sa este una completă, funcțională și conformă cu cerințele Caietului de sarcini și cu bunele practici în managementul proiectelor IT. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.10. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul x). — „Referitor la liniile 42 si 73 din Gantt - nu este menționat decât expertul Specialist ORACLE EBS HCM, fără a fi implicat și expertul Architect de sistem ORA CLE EBS”. Pagina 84 din 171

Consideră că depunctarea ofertei sale de către autoritatea contractantă pentru lipsa implicării expertului Arhitect de sistem Oracle EBS în activitățile de la liniile 42 și 73 din graficul Gantt este neîntemeiată, după cum argumentează mai jos: În cadrul Planului de proiect - Graficul Gantt: o Linia 42: „Design soluție optimizată și upgrade-ată (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)”, o Linia 73: „Actualizarea sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR”, aceste activități au fost alocate Specialistului în implementarea de tehnologii Oracle EBS HCM 2, expert certificat, cu experiență relevantă și dovedită în realizarea operațiunilor tehnice respective. Precizează următoarele: • Activitățile sunt operaționale, nu de arhitectură: o Aceste sarcini presupun implementarea practică a unui upgrade de sistem de operare și actualizarea aplicației Oracle HR, fără a implica modificări de arhitectură sau schimbări structurale în sistemul existent. • Conținutul cerinței din caietul de sarcini la cap. 5.1.2.2, citat în răspunsul autorității, se referă la responsabilități minimale ale arhitectului, dar nu exclude posibilitatea ca activități operaționale să fie delegate către specialiști tehnici cu experiență, în măsura în care acestea nu presupun proiectare arhitecturală sau avizare. • Specialistul propus este pe deplin calificat și poate implementa eficient upgrade-ul sistemului de operare și actualizarea aplicației, în conformitate cu metodologiile validate anterior în cadrul organizației. Nu au fost implicate activități de reproiectare, integrare sau restructurare care să justifice în mod obligatoriu implicarea arhitectului. • Eficiență și utilizare optimă a resurselor: Alocarea exclusivă a arhitectului pentru activități de rutină și execuție ar genera o ineficiență în utilizarea resurselor, contrară principiilor de bună gestiune și optimizare a costurilor asumate prin ofertă. • Cerința trebuie interpretată în contextul specific al activității: Deși rolul Arhitectului este important în etapa de proiectare și avizare a documentației de arhitectură, nu orice activitate ce menționează „upgrade” implică automat intervenția acestuia, mai ales în lipsa unui proces de reproiectare sau documentare tehnică strategică aferentă livrabilelor majore. În concluzie, atribuirea activităților operaționale menționate exclusiv specialistului Oracle EBS HCM este justificată tehnic, respectă cerințele proiectului, reflectă eficiență în alocarea resurselor și nu contravine responsabilităților Arhitectului de sistem Oracle EBS. Prin urmare, solicită Consiliului să dispună reevaluarea ofertei sale la acest subpunct, întrucât motivul de depunctare nu reflectă o Pagina 85 din 171

interpretare obiectivă și proporțională a cerințelor din documentația de atribuire. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.11. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xi). — „Etapele din GANTT sunt prezentate consecutiv și nu în ordinea cronologică, adică să fie prezentate activitățile pentru Faza 1, după care activitățile pentru Faza 2”. În primul rând, arată că caietul de sarcini nu impune obligația expresă privind ordonarea cronologică strictă a activităților în Planul de proiect - Grafic GANTT, sub forma grupării activităților exclusiv pe faze (Faza I complet, urmat de Faza II). Cerințele referitoare la Planul de implementare și la graficul Gantt vizează prezentarea activităților, a duratelor, a responsabililor și a dependențelor, fără a specifica formatul de grupare a activităților sau ordonarea acestora în funcție de faze. În acest context, alegerea modului de structurare vizuală a activităților în cadrul graficului Gantt revine ofertantului, atât timp cât acesta asigură următoarele condiții: o toate activitățile sunt incluse; o duratele și succesiunile logice sunt clar precizate; o sunt evidențiate relațiile de dependență între activități; o sunt nominalizați responsabilii. Prin urmare, forma graficului Gantt prezentat de societatea sa nu afectează conținutul sau calitatea informației livrate și nu împiedică desfășurarea activităților, urmărirea progresului proiectului sau respectarea cerințelor contractuale. Subliniază că graficele Gantt utilizate în practică sunt instrumente dinamice, iar aspecte precum reordonarea activităților sau filtrarea pe faze pot fi realizate cu ușurință în orice instrument de planificare consacrat (ex: Microsoft Project), în funcție de preferințele utilizatorului. Modul de grupare a activităților în Gantt nu reflectă o lipsă de completitudine sau deficiențe în înțelegerea succesiunii implementării, ci o opțiune de redactare. În acest context, apreciază că motivul invocat de autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat, întrucât: o nu există o cerință explicită în documentația de atribuire privind forma de grupare a activităților pe faze; o toate informațiile necesare sunt prezentate clar și integral în Gantt; o forma propusă nu afectează capacitatea graficului de a susține monitorizarea proiectului. Pagina 86 din 171

Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.12. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xii) — „Nu sunt menționați experții suplimentari (non cheie) pe activitățile și livrabilele din Plan + GANTT”. Cu privire la petitul din contestație conform căruia oferta sa nu a fost punctată pe motiv că „Nu sunt menționați experții suplimentari (non cheie) _pe activitățile și livrabilele din Plan + GANTT”, înțelege să renunțe la acest capăt de cerere ca urmare a studierii detaliate a conținutului Proceselor verbale de evaluare puse la dispoziție de CNSC. II.13. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xiii) — „Nu sunt prezentate activitățile care revin personalului SNN”. Consideră că în mod neîntemeiat autoritatea contractantă a apreciat că oferta sa nu conține activitățile care revin personalului SNN, întrucât acestea sunt prezentate explicit în cadrul Planului de proiect (GANTT), după cum va arăta în cele ce urmează. În cuprinsul graficului GANTT, a evidențiat în mod expres activități în responsabilitatea echipei beneficiarului. Cu titlu exemplificativ, menționează următoarele activități relevante, regăsite în planificare: o Linia 87 – „Efectuare testare de acceptanță pe mediul de test - Faza I”, o Linia 120 – „Efectuare testare de acceptanță pe mediul de test - Faza II”. Precizează că aceste activități sunt atribuite explicit echipei beneficiarului (SNN), în conformitate cu Capitolul 10 din Caietul de sarcini, unde se menționează: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Pe această bază, consideră că includerea acestor activități confirmă identificarea unor responsabilități clare ale beneficiarului, asumate în cadrul planificării, în concordanță cu documentația de atribuire. Menționează totodată că, într-un proiect IT de complexitate ridicată, responsabilitățile echipei beneficiarului sunt adesea iterative, detaliate progresiv, și sunt integrate în dinamică pe parcursul implementării, în funcție de disponibilitatea resurselor interne și necesitatea de validare, testare, corecție sau suport operațional. Așadar, abordarea sa — de a evidenția activitățile cu implicarea SNN în fazele Pagina 87 din 171

critice — este una echilibrată, realistă și conformă cu bunele practici de management de proiect. Afirmația autorității contractante conform căreia „nu sunt prezentate dependențe externe care pot afecta durata proiectului (ex. corecții de date, pregătire utilizatori finali, analiză de business)” nu este însoțită de o solicitare explicită în caietul de sarcini privind prezentarea acestor activități ca responsabilitate exclusivă a SNN, și nici nu a fost detaliată o structură obligatorie de repartizare a sarcinilor beneficiarului. În concluzie consideră că: o oferta sa conține activități în sarcina personalului SNN, prezentate clar în GANTT; o documentația de atribuire nu impune explicit prezentarea tuturor responsabilităților beneficiarului într-un mod exhaustiv și separat; o acest aspect nu afectează calitatea planului de proiect sau gradul de detaliere al metodologiei propuse. Pe cale de consecință, solicită Consiliului să dispună reevaluarea ofertei sale pentru acest punct, cu luarea în considerare a faptului că activitățile în responsabilitatea personalului SNN au fost prevăzute în mod corect și în conformitate cu cerințele minime stabilite în caietul de sarcini. II.14. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul i). — „Documentația de Bază de date și Documentația de Arhitectură a sistemului nu sunt livrabile aferente Fazei 1. Acestea sunt identice cu cele din Faza 2”. Consideră că autoritatea contractantă a interpretat în mod neîntemeiat structura planului de livrabile propus de către societatea sa și, prin urmare, depunctarea ofertei pe acest considerent este nejustificată, din următoarele motive: În Planul de proiect (GANTT), a indicat în mod clar existența și alocarea documentațiilor aferente bazei de date și arhitecturii sistemului pentru fiecare fază a implementării, după cum urmează: Faza I: o Documentația despre arhitectura sistemului - Faza I (linia 45) o Documentația bazei de date - Faza I (linia 46) Faza II: o Documentația despre arhitectura sistemului - Faza II (linia 62) o Documentația bazei de date - Faza II (linia 63). În opinia sa această abordare este perfect justificată și necesară în contextul cerințelor caietului de sarcini - Capitolul 6 (pag. 35), care prevede explicit că fiecare fază a implementării va include o etapă proprie de analiză a proceselor și funcționalităților. Astfel, fiecare fază este autonomă din punct de vedere al analizei și proiectării tehnice, iar documentațiile asociate sunt supuse unor revizuiri și adaptări specifice. Pagina 88 din 171

Contrar afirmațiilor autorității contractante, documentațiile aferente Fazei I nu sunt finale, ci reprezintă livrabile intermediare, esențiale pentru: o fundamentarea corectă a arhitecturii parțiale inițiale; o validarea soluției propuse pentru prima fază; o facilitarea urmăririi modificărilor și optimizărilor care vor interveni în Faza II. Această practică este aliniată metodologiei de implementare OUM, dar și principiilor recunoscute de management al arhitecturii software (de ex. TOGAF), care recomandă elaborarea și actualizarea incrementală a documentației tehnice odată cu evoluția sistemului. De asemenea, faptul că documentațiile sunt reluate în Faza II nu înseamnă că sunt „identice”, ci că reflectă progresul soluției: în Faza II se vor documenta și noile componente/module, completând structura generală. Referitor la observația că „nu există activități de elaborare și responsabili desemnați în GANTT”, menționează că: o Livrabilele respective sunt generate în urma unor activități incluse în analiza și proiectarea fiecărei faze; o Responsabilii acestor documente sunt implicit definiți în echipa tehnică - de ex., Arhitectul de sistem și Administratorul de baze de date, ambii experți-cheie, conform propunerii tehnice; o Pentru claritate, aceste activități pot fi evidențiate ca subactivități în actualizarea ulterioară a GANTT-ului, dar prezența livrabilelor în sine indică asumarea lor concretă. În ceea ce privește cerința din Cap. 18.3.3 (pag. 47) a caietului de sarcini, care menționează anexarea documentației finale la procesul- verbal de trecere în producție al Fazei II, aceasta nu contrazice existența versiunilor preliminare/livrabilelor din Faza I, ci impune predarea versiunii consolidate la final, după integrarea completă a ambelor faze. În concluzie, raportat la cele de mai sus: o Prevederea acestor livrabile atât în Faza I cât și în Faza II este justificată logic, metodologic și contractual; o Documentațiile din Faza I sunt versiuni parțiale/intermediare, necesare pentru fiecare etapă de analiză și implementare; o Planificarea livrabilelor în ambele faze este o dovadă de rigoare și profesionalism în abordarea proiectului. Pe cale de consecință, solicită Consiliului să dispună reevaluarea ofertei sale în cadrul subfactorului F2.1.b, cu recunoașterea corectă a planificării livrabilelor conform cerințelor caietului de sarcini. II.15. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul ii). — „Experții suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat”. Pagina 89 din 171

Cu privire la petitul din contestație conform căruia oferta sa nu a fost punctată pe motiv că „Experții suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat”, înțelege să renunțe la acest capăt de cerere ca urmare a studierii detaliate a conținutului Proceselor verbale de evaluare puse la dispoziție de CNSC. II.16. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul iii). — „Planul de proiect face referire plan de integrare versiuni fără corespondenta în CS și GANTT”. Consideră că depunctarea ofertei sale pentru motivul invocat de entitatea contractantă este nejustificată și derivă dintr-o interpretare formalistă, care nu reflectă în mod corect conținutul și scopul documentului respectiv, după cum va demonstra mai jos: • „Planul de integrare a versiunilor” nu este un livrabil solicitat prin caietul de sarcini, ci un document tehnic intern, utilizat conform metodologiei standard de dezvoltare software adoptate de ofertant - Oracle Unified Methodology (OUM) - și menționat ca atare în cadrul Anexei 3 - Metodologia de implementare Oracle (OUM). În mod specific, acest document este o intrare (input) în cadrul unor activități metodologice standard, precum: o Integrarea componentelor în sub-sisteme (pagina 40) o Integrarea sub-sistemelor la nivelul sistemului (pagina 40) o Instalarea și configurarea soluției (pagina 41) o Dezvoltarea planului de implementare (pagina 42). Astfel, precizează că documentul este utilizat pentru a ghida procesele interne de integrare în cadrul echipei de dezvoltare și nu are statut de livrabil contractual, ceea ce justifică pe deplin lipsa sa din Planul de proiect - GANTT, care, în mod corect, include doar livrabilele solicitate în mod expres prin caietul de sarcini. • Acest tip de document (Plan de integrare a versiunilor) face parte din buna practică în ingineria software, fiind un instrument uzual de control și coordonare a versiunilor componentelor sistemului în mediile de dezvoltare, testare și producție. Prin includerea sa ca referință metodologică, a demonstrat o abordare riguroasă și profesionistă, chiar dacă acest document nu a fost solicitat explicit de autoritatea contractantă. • Contrar celor susținute de SNN în răspunsul la contestație, faptul că nu a detaliat conținutul documentului și atribuțiile privind elaborarea sa nu este o omisiune relevantă pentru evaluarea conformității cu cerințele caietului de sarcini, în condițiile în care: o Nu a fost solicitat un astfel de document ca livrabil; o Activitatea de integrare este oricum acoperită de activitățile din metodologie și din Planul de proiect; Pagina 90 din 171

o Detalierea excesivă a documentelor interne ar încărca nejustificat oferta tehnică. În concluzie, prezența unei referințe la un document intern suplimentar - care nu contravine în niciun fel cerințelor, dar reflectă o abordare profesionistă și conformă cu metodologia declarată – în opinia sa nu poate fi considerată un motiv legitim de depunctare, mai ales într- un context în care se urmărește corelarea între cerințele din caietul de sarcini și planul de proiect. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.17. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul iv). — „Planul de proiect conține roluri suplimentare pentru testare fără corespondență în GANTT și CS”. Consideră că depunctarea ofertei sale pentru acest motiv este nejustificată și nefundamentată, întrucât reflectă o interpretare rigidă și formalistă a corelării dintre documentele propunerii tehnice, după cum va arăta în continuare: • Rolurile suplimentare menționate (Manager testare, Analist testare, Designer testare, Proiectant testare, Tester, Manager configurație) sunt parte integrantă a Metodologiei de dezvoltare software - OUM (Oracle Unified Methodology), adaptată la specificul proiectului și prezentată în mod transparent în Anexa 3 - Metodologia de implementare Oracle (OUM), la capitolul 1.1.3 - Etapa de configurare, testare și acceptanță pe mediul de test. • Aceste roluri nu sunt echivalente cu experții-cheie, nici nu sunt solicitate explicit prin caietul de sarcini, ci reprezintă roluri metodologice interne, specifice etapelor de testare, alocate în vederea asigurării unei implementări de calitate, conform practicilor din cadrul metodologiei OUM. • Faptul că aceste roluri nu sunt reflectate distinct în GANTT nu poate fi considerat o omisiune relevantă, deoarece: o Caietul de sarcini nu solicită nominalizarea sau reflectarea acestor roluri; o Planul de proiect - GANTT este corelat cu cerințele din caietul de sarcini, respectiv include exclusiv experții-cheie solicitați; o Rolurile suplimentare pot fi asimilate experților non-cheie, care, conform precizărilor din caietul de sarcini (pagina 7), pot fi utilizați discreționar de ofertant pentru a asigura livrarea contractului, fără a fi impusă prezentarea acestora în GANTT. • În realitate, includerea acestor roluri în metodologia propusă reflectă un plus de rigoare și profesionalism, demonstrând că ofertantul a Pagina 91 din 171

planificat adecvat procesele de testare, configurare și validare a soluției - aspect care ar trebui să fie apreciat pozitiv, nu sancționat. • Depunctarea pentru faptul că rolurile metodologice suplimentare nu apar în GANTT, deși nu sunt cerute de caietul de sarcini, înseamnă sancționarea unui supliment de calitate, ceea ce contravine scopului unei evaluări obiective și proporționale cu cerințele. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.18. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul v). — „Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție”. Contestatorul consideră neîntemeiată depunctarea ofertei sale la subfactorul F2.1 b) „Corelarea planului de proiect cu cerințele din caietul de sarcini”, având în vedere următoarele: Deși în justificarea deciziei de evaluare se menționează că „sesiunile de instruire sunt planificate a începe înainte de acceptarea planului de instruire și a materialelor suport”, dorește să sublinieze că: • Activitățile de instruire sunt planificate anterior trecerii în producție, conform cerințelor din caietul de sarcini (Cap. 6.2), ceea ce se poate verifica în Planul de proiect (Gantt), la liniile 163-166. Astfel: o Instruirea pentru administratorii de sistem: 30.07.2025 - 05.08.2025 o Instruirea pentru administratorii de aplicație, pe locații: - CNE Cernavodă: 06.08.2025 - 12.08.2025 - SNN Sediul Central: 13.08.2025 - 19.08.2025 - FCN Pitești: 20.08.2025 - 26.08.2025 o Punerea în producție - Faza I: 29.08.2025. • Se afirmă că activitățile de instruire încep înainte de acceptarea planului de instruire (linii 169-170 din Gantt, planificate la 29.08.2025). Cu toate acestea: o Planificarea acestor activități nu presupune că acceptarea formală a planului de instruire trebuie să aibă loc exclusiv în data menționată în Gantt (29.08.2025), această dată reprezentând, în mod uzual, finalizarea sau confirmarea formală a unui livrabil, nu inițierea procesului de elaborare sau de utilizare. o Activitățile de elaborare și transmitere a planului de instruire și a materialelor suport pot fi realizate anterior acestei date, în etapele de analiză și proiectare (așa cum însăși comisia de evaluare recunoaște). • Din cele de mai sus rezultă că există o corelare logică între activitățile din Planul de proiect și cerințele caietului de sarcini, iar Pagina 92 din 171

presupusa „deviație” este una de natură formală, nu substanțială, nejustificând calificarea ca „Bună” în loc de „Foarte Bună”. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.19. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul i). — „Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general”. Cu privire la critica formulată de către autoritatea contractantă în cadrul factorului de evaluare F2.1.c), conform căreia „Planul de implementare și graficul Gantt sunt în mică măsură corelate cu metodologia de management de proiect, care este detaliată foarte general”, consideră această apreciere ca fiind neîntemeiată, după cum urmează: • Prezentarea metodologiei și a planului de proiect în ofertă: Ofertantul a prezentat în mod structurat metodologia de implementare și planul de proiect în cadrul documentului Anexa 3 - Metodologia de implementare Oracle (OUM)_final.pdf, în special în capitolele: o 1.2 Planul de implementare o 1.2.1 Graficul de tip Gantt. În plus, susține că metodologia generală de management de proiect (ex: PMBOK) a fost prezentată în Anexa 2 - Metodologia de management de proiect, cap. 3.5, pag. 24-67. • Planul Gantt respectă structura principalelor faze ale ciclului de viață al proiectului: Inițiere, Planificare, Execuție, Monitorizare și Control, Închidere, chiar dacă denumirile exacte ale sub-activităților diferă ușor față de descrierile teoretice din Anexa 2. Această adaptare are ca scop personalizarea metodologiei la specificul proiectului și nu reprezintă o abatere metodologică. • Gantt-ul include livrabile și activități cheie aferente fiecărei etape, chiar dacă acestea sunt aliniate direct cu cerințele Caietului de sarcini — ceea ce este firesc, dat fiind că proiectul urmărește îndeplinirea contractului, iar metodologia trebuie adaptată scopului contractual. • Structurarea pe faze: activitățile sunt grupate logic pe etape, corespondente fazelor din metodologia PMBOK. • Livrabile concrete: fiecare grup de activități are asociate livrabile definite în ofertă, iar organizarea este făcută pe livrabile, în mod consecvent cu un planning orientat pe rezultate. Pagina 93 din 171

• Relații de dependență: sunt respectate logicile secvențiale ale implementării (analiză ^ proiectare ^ dezvoltare ^ testare), vizibile în succesiunea și relațiile din Gantt. • Puncte de control: Gantt-ul conține activități precum „User Acceptance Testing” sau „Aprobări interne”, care joacă rol de validare a livrabilelor. Faptul că aceste activități nu sunt numite identic sau amplu descrise ca în metodologie nu le anulează rolul. • Activități de management: planul Gantt conține activități precum raportările de progres, ședințe de status, etc. Deși riscurile sau actualizarea planului nu sunt marcate distinct, acestea sunt implicite în procesul continuu de control al proiectului. • Orice plan de proiect se bazează pe o metodologie generală (ex. PMBOK), dar adaptarea sa la cerințele specifice ale proiectului, ale beneficiarului și ale livrabilelor contractuale este esențială pentru aplicabilitate practică. • Așteptarea ca fiecare proces teoretic din metodologie să fie reflectat literal și complet în Gantt denotă o abordare rigidă, nealiniată practicii reale de management de proiect. • Observațiile privind „deviațiile majore” sunt disproporționate: o Eventualele diferențe de terminologie sau absența explicitării unor activități secundare nu afectează coerența dintre metodologie și planul de implementare. o Însăși existența unui Gantt detaliat, care reflectă logic succesiunea activităților și respectă fazele proiectului, demonstrează aplicarea metodologiei propuse. În concluzie, consideră că evaluarea a fost subiectivă, excesiv de formalistă și a omis să țină cont de corelările esențiale, funcționale și explicite dintre planul de proiect și metodologia de management. Prin urmare, solicită reevaluarea ofertei sale la acest subfactor și reconsiderarea calificativului acordat. II.20. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul ii). — „Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general”. Consideră că aprecierea comisiei conform căreia „etapele nu sunt prezentate în ordine logică” este neîntemeiată, fiind bazată pe o evaluare formală a structurii Gantt, fără a ține cont de ordinea cronologică efectivă a desfășurării activităților, așa cum aceasta este reflectată prin datele de start și de finalizare asociate fiecărei activități din graficul Gantt. În concret: Activitățile de instruire sunt planificate anterior jalonului de punere în producție, atât în cadrul Fazei I, cât si al Fazei II: Pagina 94 din 171

Pentru Faza I: o Sesiunile de instruire pentru administratori de sistem și aplicație sunt planificate în perioada 30.07.2025 - 26.08.2025; o Trecerea în producție - Faza I este planificată la data de 29.08.2025. Pentru Faza II: o Sesiunile de instruire (inclusiv „train the trainer”) sunt planificate în perioada 19.05.2026 - 27.07.2026; o Trecerea în producție - Faza II este planificată la data de 30.07.2026. Prin urmare, arată că nu există o inversare a logicii activităților, iar afirmația că etapele nu ar fi în ordine logică este contrazisă de realitatea datelor cronologice din Gantt. În plus, susține că orice confuzie privind poziționarea în structură a activităților poate fi atribuită unei prezentări grafice în Gantt, care nu reflectă în mod necesar succesiunea logică prin poziția liniilor, ci prin relațiile de dependență și datele calendaristice. Mai mult, arată că această observație nu a fost calificată de comisie drept motiv de depunctare individuală, iar referința făcută de contestator la „depunctare” pentru acest punct a fost doar un mod de exprimare general, având în vedere că întreaga evaluare a fost încadrată la „Acceptabil”. În concluzie, activitățile de instruire sunt planificate înainte de trecerea în producție, iar structura cronologică este respectată în Gantt. În consecință, solicită Consiliului să dispună reevaluarea acestui aspect în considerarea faptelor obiective și a modului corect de interpretare a graficului Gantt. II.21. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul iii). — „Nu este marcat corect drumul critic. Doar activitatea de management de proiect este singura critica”. Consideră că aprecierea comisiei conform căreia „nu este marcat corect drumul critic” este nefundamentată, iar concluzia că activitatea de management de proiect este „singura critică” nu reflectă realitatea tehnică a planificării proiectului, după cum vom arăta în continuare. • Marcarea drumului critic nu a fost cerință explicită în documentația de atribuire. În cadrul documentației de atribuire și al factorului de evaluare F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect, nu a fost prevăzută cerința explicită de a evidenția grafic drumul critic în Gantt. În lipsa unei astfel de cerințe formale, nu poate fi susținut că omisiunea acestei marcări echivalează cu o „deviație majoră” de la cerințele metodologice. Pagina 95 din 171

De altfel, arată că prevederile din metodologia de management de proiect fac referire la importanța conceptuală a drumului critic, nu la o obligativitate de a-l marca într-un anumit mod grafic. • Drumul critic este prezent în planificarea logică a activităților, chiar dacă nu este evidențiat vizual prin culoare sau simbol. Chiar dacă în versiunea transmisă în urma clarificărilor (Anexa 4 - Planul Gantt actualizat.pdf) doar activitatea de management de proiect apare marcată critic, dependențele dintre activități, datele de start și de finalizare și secvențierea logică definesc în mod clar drumul critic al proiectului. În opinia sa este important de subliniat că drumul critic nu presupune exclusiv marcarea vizuală, ci este determinabil prin analiza relațiilor de dependență și a lipsei de slack (marjă) pentru anumite activități. Astfel, proiectul a fost planificat în conformitate cu metodologia de proiect management, iar succesiunea activităților critice este inclusă logic și coerent în Gantt, chiar dacă anumite activități nu sunt marcate explicit ca „critice” prin formatare automată. • Evaluarea ofertei nu poate fi penalizată pentru o problemă de formatare grafică a unui element necerut explicit. În contextul în care drumul critic este reflectat în structura logică a Gantt-ului, dar nu este vizibil marcat grafic în întregime, consideră că această situație nu justifică calificarea ca „deviație majoră” și încadrarea la nivelul „Acceptabil”. Mai ales în condițiile în care conținutul Gantt-ului reflectă corect relațiile de dependență care constituie drumul critic. În acest context, având în vedere că: o nu a existat o cerință explicită privind evidențierea vizuală a drumului critic, o drumul critic este prezent și coerent în structura de proiect, o evaluarea nu poate fi deturnată de la conținut către formatarea grafică, solicită Consiliului să dispună reevaluarea acestui punct, în spiritul proporționalității și al evaluării obiective, tehnice, a conținutului Planului de Proiect. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.22. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul iv). — „Metodologia de management de proiect este prezentată in cap. 3.3.8 din Oferta tehnică (Anexa 2 la aceasta) dar riscurile specifice nu sunt tratate în planul de proiect”. Pagina 96 din 171

Consideră că argumentul invocat de autoritatea contractantă, conform căruia riscurile specifice nu sunt tratate în Planul de Proiect, este neîntemeiat, iar concluzia referitoare la existența unor „deviații majore” nu reflectă corect conținutul ofertei sale tehnice, după cum va arăta în cele ce urmează. • Distribuția tematică a informațiilor este corectă și conformă cu structura documentației. Planul de Proiect (graficul Gantt) este, prin natura sa, un instrument de planificare temporală a activităților, livrabilelor și jaloanelor. El nu are ca scop prezentarea analizei riscurilor, aspect care este tratat corespunzător în alte secțiuni din oferta sa, așa cum solicită documentația de atribuire. Conform documentelor transmise: o Capitolul 3.3.8 „Managementul Riscului” din Anexa 2 - Metodologia de management de proiect detaliază metodologia generală aplicabilă managementului riscului în cadrul proiectului. o Capitolul 24.2 „Riscuri” din Formularul IV.4.1.a - Anexa la propunerea tehnică finală (pag. 261-266) abordează în mod concret și specific riscurile asociate implementării proiectului, inclusiv cele identificate de autoritatea contractantă în caietul de sarcini. • Riscurile sunt tratate distinct, în mod specific și în conformitate cu cerințele din Caietul de Sarcini. În cadrul Capitolului 24.2 din oferta sa, a abordat în mod concret: o Riscurile cu cea mai mare probabilitate de apariție, așa cum au fost identificate de Autoritatea Contractantă. o Măsuri specifice de atenuare și gestionare a riscurilor, corelate cu activitățile de implementare și cu contextul tehnic și organizațional al proiectului. o Riscuri suplimentare identificate de ofertant, însoțite de recomandări și soluții pentru controlul și diminuarea impactului acestora. Aceste informații reflectă o abordare riguroasă, preventivă și completă a managementului riscurilor, conform standardelor de bune practici în management de proiect (PMBOK), chiar dacă ele nu sunt integrate grafic în Gantt, ceea ce oricum nu era cerut de documentația de atribuire. • Menționarea în Gantt a riscurilor nu este cerință explicită și nu influențează corelarea cu metodologia. Evaluarea subfactorului F2.1.c - Corelarea planului de proiect cu metodologia - trebuie să vizeze logica și coerența dintre metodologie și planificarea operațională. Or, în oferta sa, metodologiile de planificare, control și management al riscurilor sunt dezvoltate coerent, iar documentele suport (Anexa 2 și Formularul IV.4.1.a) asigură această legătură în mod complet și corespunzător. În acest context, având în vedere că: Pagina 97 din 171

o tratarea riscurilor era prevăzută în documentele metodologice și în propunerea tehnică, o nu exista obligația explicită de a le marca în Gantt, o metodologia riscurilor este corect detaliată și riscurile sunt analizate conform cerințelor din Caietul de sarcini, solicită Consiliului să dispună reevaluarea ofertei sale la acest subfactor, cu luarea în considerare a conținutului efectiv al documentației tehnice și nu doar a elementelor de prezentare grafică. II.23. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul i). — „Estimarea duratelor activităților nu este realistă”. Consideră că motivul invocat de entitatea contractantă privind lipsa realismului estimărilor duratelor activităților este subiectiv, nefundamentat și nu reflectă abordarea profesională și metodologică utilizată de societatea sa în realizarea Planului de Proiect, după cum va demonstra în continuare. • Estimarea duratelor s-a bazat pe o metodologie consacrată și pe expertiză reală Pentru determinarea duratelor activităților incluse în graficul Gantt, el a utilizat: o analiză detaliată a cerințelor și constrângerilor specificate în Caietul de sarcini; o date istorice din proiecte similare implementate cu succes; o metode de estimare recunoscute, cum ar fi PERT și Three-Point Estimation; o implicarea experților cu experiență relevantă în proiecte similare, care au validat estimările în mod profesionist. • Estimările au ținut cont de complexitatea activităților și riscurile asociate. Duratele activităților au fost ajustate în funcție de: o nivelul de dificultate al fiecărei activități; o riscurile specifice menționate în documentația de atribuire și identificate suplimentar de echipa sa; o resursele alocate și interdependențele dintre activități, reflectate corespunzător în planificarea generală. Acest proces de estimare a permis formularea unor durate realiste și sustenabile, având ca scop asigurarea livrabilelor în termen și fără compromiterea calității. • Evaluarea realizată de comisie este generală și lipsită de justificări concrete. Constatarea că „estimarea duratei nu este realistă” nu este susținută de exemple concrete sau de referințe la activități specifice, ci este formulată în termeni generici. În lipsa unei analize tehnice detaliate Pagina 98 din 171

sau a unui benchmark obiectiv, această apreciere nu poate fundamenta o depunctare justificată. Mai mult, este discutabil caracterul „nerealist” al duratelor, atâta timp cât ele sunt rezultatul unui proces de estimare profesional, documentat și corelat cu practica proiectelor similare. Prin urmare, având în vedere că: o estimările duratelor s-au bazat pe o metodologie riguroasă și recunoscută; o acestea au fost validate de experți și corelate cu riscurile și complexitatea activităților; o evaluarea efectuată nu este susținută de argumente tehnice detaliate sau de o analiză obiectivă; solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, ținând cont de conținutul documentației tehnice și de caracterul profesionist al estimărilor propuse. II.24. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul ii). — „In planul de proiect avem analiza pentru Faza 2 în 2 luni, desfășurarea etapelor fiind prezentate secvențial.” Consideră că motivul invocat de autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat, fiind rezultatul unei interpretări subiective asupra unei opțiuni justificate strategic în cadrul Planului de Proiect, și nu al unei neconformități sau nerealism în estimarea duratelor. • Alegerea desfășurării secvențiale a activităților este justificată metodologic și managerial. Societatea sa a optat pentru o derulare secvențială a activităților de analiză în Faza II, având în vedere: o dependențele logice dintre anumite module și posibilele influențe reciproce asupra proceselor de HR; o dimensiunea și complexitatea fiecărui modul, necesitând o înțelegere profundă înainte de a trece la configurare; o necesitatea unei colaborări eficiente cu responsabilii proceselor de HR, fiecare având expertiză pe un domeniu distinct, ceea ce impune gestionarea etapizată a interacțiunilor pentru maximizarea eficienței și clarității. Planificarea secvențială este rezultatul unei abordări de risc minim, menită să: o reducă probabilitatea erorilor în etapa de analiză, o faciliteze o încadrare în termenele generale ale proiectului, o permită monitorizarea atentă a fiecărui modul, cu feedback specific și oportun, Pagina 99 din 171

o evite suprapunerea resurselor critice și posibilele blocaje în alocarea acestora. • Considerații privind resursele și estimarea duratei. În opinia sa prezența a doi experți în Oracle EBS HCM, așa cum este cerută de caietul de sarcini, nu presupune în mod obligatoriu desfășurarea strict paralelă a tuturor activităților. Expertiza acestora a fost utilizată pentru: o planificarea realistă a duratei activităților, inclusiv prin identificarea punctelor unde derularea în paralel ar fi ineficientă sau riscantă, o supravegherea atentă a fiecărei etape, astfel încât calitatea livrabilelor să nu fie compromisă de o aglomerare nerealistă a sarcinilor. o Desfășurarea pe durata a două luni a analizei pentru cele 6 module este realistă și adaptată complexității proceselor implicate, în condițiile unei abordări prudente și responsabile față de termene și rezultate. • Comisia nu a demonstrat existența unei corelații negative între planificarea secvențială și realizarea cu succes a activităților. În lipsa unei demonstrații concrete, cu referire la activități specifice, resurse, interdependențe reale și constrângeri asumate, concluzia comisiei potrivit căreia desfășurarea secvențială nu este realistă rămâne subiectivă și nefundamentată. În acest context, având în vedere: o caracterul fundamentat și strategic al planificării propuse, o faptul că această planificare are scopul de a proteja interesele proiectului și ale Entității Contractante prin evitarea riscurilor manageriale și tehnice, o lipsa unor argumente tehnice obiective care să susțină evaluarea negativă, solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct și să considere că planificarea propusă este realistă, justificată și eficientă în raport cu obiectivele proiectului. II.25. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul iii)- „Etapa de analiză pentru pontaje este de 4 zile”. Consideră că depunctarea ofertei sale pe motivul că durata activității de analiză pentru modulul Pontaj este prea scurtă (4 zile) este neîntemeiată, întrucât această estimare se bazează pe o alocare optimă de resurse, pe un nivel ridicat de expertiză și pe o metodologie eficientă de lucru. • Estimarea este realistă și justificată. Pagina 100 din 171

Durata de 4 zile pentru analiza cerințelor funcționale aferente modulului Pontaj este rezultatul unei planificări riguroase, care ține cont de: o experiența acumulată de analiști în proiecte similare, ceea ce reduce semnificativ timpul necesar pentru înțelegerea proceselor și colectarea cerințelor; o împărțirea clară a sarcinilor între cei doi experți desemnați în ofertă, ceea ce permite desfășurarea activităților în paralel sau prin alternanță eficientă, în funcție de subtematici (evidența timpului lucrat, concedii, muncă la distanță etc.); o disponibilitatea documentației și a stakeholderilor, ceea ce elimină întârzierile datorate clarificărilor sau validărilor ulterioare; o utilizarea unor metodologii consacrate de analiză, cum ar fi modelarea proceselor cu BPMN și elaborarea cerințelor prin user stories Agile, metodologii ce permit structurarea rapidă și coerentă a rezultatelor. • Referitor la numărul de experți și distribuția sarcinilor. Deși caietul de sarcini prevede un număr minim de un expert Analist de business HR, ofertantul precizează că a ales să desemneze doi experți pentru a asigura un grad superior de capacitate și flexibilitate în execuția activităților. Această abordare este perfect permisă și legală, întrucât cerințele minime nu restricționează alocarea unor resurse suplimentare. În plus, deși graficul Gantt nu indică în mod expres numele celor doi experți pentru fiecare subactivitate, în conținutul ofertei tehnice este menționată implicarea acestora în execuția activităților. Distribuirea sarcinilor a fost asumată și este reflectată în estimarea duratelor. Absența detaliului la nivel de Gantt nu invalidează logica planificării sau capacitatea echipei de a livra în termen. • Răspunsul autorității contractante este bazat pe o presupunere, nu pe o analiză concretă. Aprecierea comisiei conform căreia analiza ar necesita mai mult timp pornește de la o supraestimare subiectivă a complexității. În realitate, experiența experților și existența unui cadru deja bine definit permit derularea eficientă a acestei etape într-un termen rezonabil. Nu s- a demonstrat, cu argumente tehnice, de ce exact 4 zile ar fi insuficiente, ci doar s-a făcut o comparație generală cu alte proiecte sau cu funcționalitățile standard ale modulului Oracle Time and Labor. Această abordare generalizatoare ignoră faptul că: o analiza nu începe „de la zero”, o experții cunosc deja domeniul și soluția tehnologică, o metodologia aplicată permite documentarea rapidă și structurată. În concluzie, susține că estimarea duratei de 4 zile pentru analiza modulului Pontaj este: Pagina 101 din 171

o profesionistă, realistă și justificată prin metode de lucru și resurse competente, o rezultatul unui plan coerent și adaptat contextului Entității Contractante, o în deplină conformitate cu cerințele tehnice și de calificare din documentația de atribuire. Drept urmare, solicită reevaluarea ofertei sale pentru acest punct, în considerarea argumentelor de mai sus și înlăturarea depunctării bazate pe o presupunere nefundamentată și neproporțională. II.26. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul iv). — „Realizare upgrade Oracle pentru Faza 1 — 4 zile”. Consideră că depunctarea ofertei sale ca urmare a estimării unui termen de 4 zile pentru activitatea „Realizare upgrade Oracle pentru Faza 1” este nefundamentată și se bazează pe o interpretare formalistă a graficului Gantt, fără a reflecta în mod obiectiv modul de lucru, resursele alocate și eficiența procedurilor aplicate în cadrul acestei activități. • Estimarea este realistă și susținută de experiență concretă Activitatea de upgrade presupune: o upgrade-ul sistemului de operare Oracle Linux pe patru medii (dev, test, preprod, prod), o actualizarea versiunii produsului Oracle Human Resources (componentă Oracle EBS HCM), o realizarea acestora pe baza unor proceduri și tool-uri standardizate puse la dispoziție de Oracle. Această activitate a fost estimată la 4 zile calendaristice (2 zile efective de execuție + 2 zile de validare și verificări post-upgrade), în contextul în care: o expertul alocat, Iulia Calistrate, are experiență demonstrată și certificări relevante în upgrade-uri Oracle EBS și Oracle Linux; o toate mediile de lucru sunt deja disponibile și configurate, nefiind necesare activități prealabile de setup; o procesul de upgrade este standardizat, repetitiv și predictibil, iar eventualele riscuri sunt gestionabile prin planuri de remediere testate anterior; o procedura de upgrade propusă nu afectează major customizările deja existente, ceea ce permite un efort de validare redus în această etapă. • Rolul Arhitectului de sistem nu a fost exclus, ci este implicit coordonator. Referitor la observația entității contractante privind lipsa implicării Arhitectului de sistem Oracle EBS în activitatea de upgrade, menționează că: Pagina 102 din 171

o în cadrul ofertei noastre, Arhitectul de sistem este implicat în fazele de design, validare și avizare a soluției tehnice, inclusiv în activitățile de upgrade; o rolul Arhitectului nu presupune neapărat executarea directă a sarcinilor tehnice, ci coordonarea și supervizarea acestora; o chiar dacă în graficul Gantt activitatea a fost detaliată la nivelul executantului (Specialistul în implementarea de tehnologii Oracle EBS HCM), Arhitectul a fost prevăzut ca parte a echipei care validează și avizează rezultatele, conform cerințelor din Caietul de sarcini. Prin urmare, lipsa unei alocări explicite în Gantt nu înseamnă lipsa implicării Arhitectului, ci reflectă doar nivelul de detaliere ales pentru planificare. • Aprecierea comisiei este subiectivă și disproporționată. Afirmarea potrivit căreia estimarea de 4 zile ar fi nerealistă nu este susținută de o analiză tehnică detaliată din partea comisiei, ci doar de o concluzie generală referitoare la complexitate. Nu s-au adus argumente concrete privind imposibilitatea tehnică a realizării upgrade-ului în termenul propus. În practică, durata unui upgrade Oracle Linux și Oracle HR, în condiții de infrastructură pregătită și experți cu experiență relevantă, se încadrează într-un interval de 2-5 zile, conform bunelor practici Oracle. În concluzie, estimarea de 4 zile pentru activitatea de upgrade Oracle este: o corectă, realistă și justificată prin experiența resursei alocate, infrastructura pregătită și procedurile de lucru validate anterior; o conformă cu cerințele din documentația de atribuire, iar implicarea Arhitectului de sistem este asigurată prin activități de supervizare și avizare, chiar dacă nu apare explicit în Gantt. În consecință, solicită reevaluarea ofertei sale pentru acest punct, întrucât aprecierea comisiei este disproporționată și nu reflectă realitatea operațională și capacitatea sa tehnică dovedită. II.26. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul v). — „Durata trecerii în producție nu este corect dimensionată și nu include activități de pregătire a personalului SNN”. Consideră că depunctarea ofertei sale pentru acest motiv este neîntemeiată, iar evaluarea realizată de către Entitatea Contractantă nu reflectă în mod obiectiv planificarea și metodologia prezentate în ofertă. Precizează că va demonstra în continuare că durata alocată este realistă și că activitățile de instruire sunt integrate corespunzător. • Durata etapei de Trecere în producție este corect fundamentată: Pagina 103 din 171

Activitățile de trecere în producție pentru Faza I și Faza II sunt planificate pe baza unei experiențe semnificative în implementări Oracle în medii critice, incluzând: O Livrare și activare licențe - 1 zi O Instalare pe medii de producție și DR - 5-7 zile O Verificare livrabile și servicii - 2 zile O Semnare proces-verbal de recepție - 1 zi Această planificare reflectă standarde de bune practici în implementări Oracle, asigurând o tranziție sigură și controlată în producție, fără afectarea continuității serviciilor SNN. • Instruirea personalului SNN este acoperită, în mod justificat, prin metoda de shadowing: o Instruirea este integrată în activitățile de trecere în producție. o Personalul SNN este implicat direct în procesele de instalare, validare și recepție. o Această formă de învățare „on-the-job” este recunoscută ca fiind mai eficientă decât sesiunile formale pentru personalul tehnic și de suport. În acest context: o Administratorii de aplicații și sistem sunt instruiți practic și contextualizat; o Se asigură un transfer de know-how adaptat exact soluției implementate și infrastructurii SNN; o Durata alocată NU este afectată negativ, ci optimizată. • Cerințele de instruire din Caietul de Sarcini nu sunt încălcate: Instruirea utilizatorilor finali (prin metoda „train the trainer”) este în sarcina SNN, conform cap. 5.1.3 din Caietul de sarcini. Furnizorul instruiește doar administratorii și utilizatorii-cheie desemnați de SNN. Afirmația că „graficul nu include instruirea tuturor utilizatorilor” este irelevantă în contextul în care acest lucru nu intră în sarcina ofertantului. Metoda de shadowing nu substituie sesiunile formale de instruire, ci le completează, oferind un plus de valoare în procesul de tranziție și susținere post-implementare. • Neconcordanța indicată de SNN privind cele 4 zile din Gantt este rezultatul unei interpretări eronate: o Etapa de Trecere în producție este planificată în mod explicit pe o durată de 9 zile pentru fiecare fază, așa cum reiese din descrierea activităților din documentația tehnică. o Cele 4 zile menționate de SNN (între acceptanță și începerea trecerii în producție) nu includ, în mod intenționat, activitățile pregătitoare și de instruire care sunt parte integrantă a activităților desfășurate în perioada efectivă de trecere în producție. În opinia sa evaluarea efectuată de autoritatea contractantă este subiectivă și nealiniată cu metodologia propusă în ofertă și cu realitatea Pagina 104 din 171

implementărilor Oracle. Apreciază că a demonstrat caracterul realist și fundamentat al duratei etapei de Trecere în producție, precum și faptul că activitățile de instruire sunt integrate în mod corespunzător și eficient. Față de aspectele mai sus prezentate, solicită Consiliului, admiterea contestației cu privire la acest punct, astfel cum a fost formulată și motivată, constatarea caracterului neîntemeiat al motivului de depunctare invocat și, pe cale de consecință, reevaluarea ofertei sale. II.27. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul vi). — „Planul de proiect nu prezinta toate resursele implicate, ci doar experții cheie.” Consideră că motivul invocat de autoritatea contractantă pentru depunctarea ofertei sale este neîntemeiat și se bazează pe o interpretare excesiv de formalistă și limitativă a modului de prezentare a resurselor implicate în proiect. Potrivit Caietului de sarcini, la pag. 6 și 7, a fost impusă obligativitatea desemnării a minimum 6 experți-cheie, cu posibilitatea explicită de a extinde echipa cu alți experți, conform propriei strategii de implementare. Citat: „Operatorul Economic are libertatea de a dimensiona structural și numeric această echipă astfel încât să se asigure că poate să respecte condițiile impuse prin cerințele proiectului pe durata contractului, dar nu mai puțin de cei 6 experți-cheie listați mai sus.” Prin urmare, nu a existat obligația de a detalia în graficul Gantt toți specialiștii implicați pe fiecare activitate în parte, ci doar de a demonstra că echipa propusă este capabilă să ducă la bun sfârșit proiectul. În oferta sa susține că, a indicat clar că, pe lângă experții-cheie, are pregătită o echipă de experți non-cheie care vor fi alocați în funcție de necesitățile concrete apărute în derularea proiectului, ca măsură de prevenire și răspuns la riscuri identificate. Aceștia sunt menționați ca parte a strategiei de management al riscurilor (Cap. 24.2 din propunerea tehnică - pag. 261-262). Totodată, arată că în cadrul metodologiei de implementare (Anexa 3 - Metodologia OUM), au fost descrise explicit roluri suplimentare relevante pentru activitățile de testare și control al calității, cum ar fi: o Managerul de testare o Analistul de testare o Designerul de testare o Tester o Managerul de configurație. Aceste roluri corespund unor resurse non-cheie, prezentate ca parte integrantă a procesului de implementare, dar neindividualizate nominal în graficul Gantt, întrucât nu sunt obligatorii conform cerințelor minime din documentația de atribuire. Pagina 105 din 171

De altfel, metodologia OUM, adaptată proiectului, oferă un cadru complet și valid pentru gestionarea echipei tehnice în mod flexibil și eficient, fără a compromite vizibilitatea asupra capacității de implementare. Menționează că includerea în Gantt doar a experților-cheie NU înseamnă că alți specialiști nu vor fi alocați proiectului. Dimpotrivă, aceștia sunt prevăzuți ca resurse operaționale flexibile, care vor fi evidențiați și planificați în detaliu după semnarea contractului și definitivarea calendarului exact de execuție, în concordanță cu planul de gestionare a riscurilor. În concluzie, consideră că nu se poate afirma în mod obiectiv că planul nu reflectă resursele necesare sau că acestea sunt insuficiente, atâta timp cât: o au fost indicați clar experții-cheie solicitați de autoritate, o au fost identificatei și roluri suplimentare în cadrul metodologiei, o au fost prezentate măsuri de prevenire a riscurilor legate de resurse, o iar flexibilitatea în alocarea resurselor a fost asumată și justificată. În acest context, solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, în sensul recunoașterii caracterului realist și complet al planului de proiect în raport cu cerințele din documentația de atribuire. II.28. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul vii). — „Nu sunt prezentate rolurile și sarcinile personalului SNN.” Consideră că argumentul invocat de entitatea contractantă privind depunctarea ofertei sale pentru lipsa rolurilor și sarcinilor echipei SNN în planul de proiect este neîntemeiat, iar motivația nu reflectă corect realitatea și cadrul general al implementării. În Planul de proiect (Gantt), activitățile care implică echipa SNN sunt deja clar evidențiate, cum ar fi testele de acceptanță pe mediul de test, inclusiv pentru fazele I și II, menționate de entitatea contractantă: o Efectuare testare de acceptanță pe mediul de test - Faza I (linia 87 din Planul Gantt) o Efectuare testare de acceptanță pe mediul de test - Faza II (linia 120 din Planul Gantt) În opinia sa aceste activități sunt perfect corelate cu cerințele din caietul de sarcini, care prevede că testele de acceptanță vor fi realizate pe mediul de test pus la dispoziție de către Entitatea Contractantă, cu asistență din partea Furnizorului (cap. 10, pag. 42). Așadar, implicarea SNN în aceste activități este deja în conformitate cu cerințele Pagina 106 din 171

documentului și reflectă corect responsabilitățile echipei beneficiarului în procesul de testare. Referitor la mențiunea că echipa de proiect a beneficiarului nu este inclusă în activitățile de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță, este important să menționeze că în conformitate cu Caietul de sarcini, activitățile de testare sunt structurate astfel încât doar unele etape (în principal cele de testare de acceptanță) necesită o colaborare directă cu echipa SNN, iar pentru celelalte activități, atribuirea sarcinilor și rolurilor se face în funcție de cerințele specifice ale fiecărei etape. De asemenea, susține că planul de proiect (Gantt) a fost întocmit având în vedere că anumite sarcini ale echipei SNN nu erau încă finalizate în faza de ofertare, iar rolurile și sarcinile acestora vor fi detaliate și definite în documentele ulterioare, în funcție de progresul real al proiectului și de cerințele operaționale. În concluzie, rolurile și sarcinile echipei SNN sunt clar reflectate în planul de proiect pentru activitățile corelate direct cu acestea (testare de acceptanță). Din acest motiv, consideră că nu există un motiv obiectiv pentru depunctarea ofertei pe acest aspect și solicită Consiliului să dispună reevaluarea ofertei sale cu privire la acest punct, având în vedere clarificările aduse. II.29. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute”, punctul i). — „In planul de proiect nu este optimizata utilizarea resurselor, acestea fiind implicate secvențial.” Consideră că argumentul invocat de autoritatea contractantă privind depunctarea ofertei sale pentru presupusa lipsă de optimizare a utilizării resurselor, datorită prezentării activităților secvențial, este neîntemeiat. Va detalia în continuare raționamentul său. În Planul de proiect (Gantt), a ales o structură secvențială a activităților, având în vedere avantajele clare pe care această abordare le aduce în gestionarea unui proiect complex, cum ar fi: o Claritatea dependențelor: Permite o urmărire precisă a activităților care depind de altele, evitând riscul de a începe activități înainte ca cele anterioare să fie finalizate. o Reducerea riscurilor: Minimizarea posibilității de a întâmpina erori sau suprapuneri care pot apărea în planificările paralele. o Monitorizarea ușoară a progresului: Permite managementului de proiect să intervină rapid în caz de întârziere sau alte probleme. o Alocarea eficientă a resurselor: Resursele sunt utilizate într-un mod mai coordonat și eficient, în funcție de momentul în care sunt necesare. Pagina 107 din 171

o Gestionarea riscurilor și comunicarea mai bună: O planificare secvențială îmbunătățește coordonarea între echipe și reduce confuzia cu privire la prioritizarea sarcinilor. În același timp, consideră că optimizarea utilizării resurselor nu depinde exclusiv de alegerea între o planificare secvențială sau paralelă. Din această perspectivă, abordarea noastră este una bine fundamentată, iar alte tehnici de optimizare, cum ar fi: o Resource leveling: Ajustarea activităților pentru a evita epuizarea resurselor și suprapunerile. o Resource smoothing: Menținerea unei utilizări constante și eficiente a resurselor fără a modifica termenele de finalizare. o Analiza valorii câștigate (EVA): Utilizarea acestei metode pentru urmărirea în timp real a performanței proiectului. De asemenea, susține că este esențial de menționat că monitorizarea și ajustarea continuă a alocărilor, pe baza evoluției proiectului și a eventualelor întârzieri sau modificări, reprezintă o practică de optimizare constantă. Aceasta va fi realizată folosind software de management al proiectelor (de exemplu, MS Project), pentru a ajusta alocările în funcție de necesitățile reale. În concluzie, planificarea activităților într-o succesiune logică și coordonată nu constituie un impediment pentru optimizarea resurselor, ci dimpotrivă, asigură o utilizare mai eficientă și mai bine monitorizată a acestora. Consideră că argumentele aduse de entitatea contractantă nu reflectă corect realitățile unui proiect bine gestionat și solicită Consiliului să dispună reevaluarea ofertei sale în privința acestui punct, ținând cont de raționamentele prezentate. II.30. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute”, punctul ii). — „Planificarea nu permite flexibilitate pentru activități neprevăzute”. Consideră că argumentul invocat de autoritatea contractantă privind depunctarea ofertei sale, pe motivul lipsei de flexibilitate în planificarea activităților pentru situații neprevăzute, este neîntemeiat. Va detalia în continuare raționamentele care susțin abordarea sa și de ce consideră că planul său de proiect include suficientă flexibilitate pentru gestionarea eficientă a riscurilor. În cadrul planificării proiectului, susține că a prevăzut o marjă de flexibilitate special concepută pentru a răspunde eficient situațiilor neprevăzute care pot apărea, în special într-un proiect IT complex, cum ar fi implementarea unei soluții Oracle. Această flexibilitate a fost integrată în planul său de lucru pentru a preveni blocaje sau întârzieri semnificative și pentru a ne asigura că proiectul îi atinge obiectivele în termenii stabiliți. Principalele elemente ale acestei flexibilități includ: Pagina 108 din 171

o Caracterul dinamic al proiectelor IT: În proiectele complexe, cum sunt implementările de soluții Oracle, pot apărea probleme de compatibilitate, întârzieri mici în livrări sau solicitări suplimentare din partea beneficiarului. Acestea necesită o abordare flexibilă. o Gestionarea riscurilor operaționale: A inclus o rezervă de resurse care poate fi alocată rapid pentru a preveni prelungiri necontrolate ale duratei proiectului, în cazul în care sunt necesare activități suplimentare sau apar modificări de cerințe. o Flexibilitate controlată: Marja de flexibilitate este calculată astfel încât să nu interfereze cu obiectivele principale ale proiectului, fiind utilizată doar în baza unei decizii justificate și aprobate de managementul de proiect. o Sesiuni de reevaluare a progresului (checkpoints intermediare): Aceste sesiuni vor ajuta la identificarea din timp a eventualelor devieri și vor permite ajustarea rapidă a planului de proiect. o Mecanism de escaladare rapidă: Acest mecanism permite aprobarea rapidă a utilizării flexibilității, pentru a răspunde în mod eficient oricărei situații neprevăzute. o Resurse suplimentare disponibile on-call: În funcție de necesitățile proiectului, va avea la dispoziție resurse suplimentare care pot fi mobilizate rapid. Arată că răspunsul comisiei de evaluare susține că „marja de flexibilitate” nu a fost inclusă în oferta sa tehnică, însă aceasta nu a fost specificată în documentele depuse inițial pentru că flexibilitatea este o componentă dinamică a planului de proiect, care poate fi ajustată pe parcursul implementării, în funcție de necesitățile și evoluția proiectului. Consideră că această marjă de flexibilitate a fost adaptată și planificată astfel încât să nu afecteze obiectivele principale ale proiectului, ci să asigure continuitatea și buna desfășurare a activităților. De asemenea, nu a considerat necesar să o detalieze inițial în documentația depusă, având în vedere că flexibilitatea se activează doar în cazuri justificate și aprobate de managementul de proiect. În concluzie, susține că planificarea sa include suficiente măsuri de flexibilitate pentru gestionarea activităților neprevăzute, iar depunctarea ofertei sale pe acest temei nu este întemeiată. Solicită reevaluarea ofertei sale, având în vedere argumentele și măsurile de flexibilitate pe care le-a prevăzut. II.31. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute”, punctul iii). — „Activitatea de proiectare începe după activitatea de analiza. În procedura ORACLE acestea se realizează în paralel—Linia 41 din Gant este condiționată de realizarea liniei 20 din GANTT” Pagina 109 din 171

Consideră că argumentul invocat de entitatea contractantă pentru depunctarea ofertei sale pe acest punct nu este întemeiat, având în vedere că abordarea sa de planificare a fost gândită pentru a asigura stabilitatea și calitatea livrabilelor, în conformitate cu cerințele specifice ale proiectului. În continuare, va detalia raționamentele care susțin această abordare. Deși Metodologia Oracle Unified Method (OUM) permite realizarea activităților de analiză și proiectare în paralel, în cadrul planificării sale a ales o abordare secvențială a acestora, cu scopul de a asigura o implementare mai controlată și cu riscuri minime. Activitatea de proiectare (Linia 41 din Gantt) a fost condiționată de finalizarea activității de analiză (Linia 20 din Gantt) din următoarele motive: o Calitatea livrabilelor de analiză: Consideră esențial ca documentele de analiză să fie complet validate înainte de inițierea activității de proiectare, pentru a preveni eventualele ajustări ulterioare ale soluției în cazul în care apar cerințe suplimentare sau eronate. o Reducerea riscurilor de modificări în faza de proiectare: Începerea activității de proiectare pe baza unui set stabil de cerințe previne modificările costisitoare și întârzierile care ar putea apărea din cauza schimbărilor de cerințe în timpul procesului de proiectare. o Adaptare la specificul proiectului și al beneficiarului: Dat fiind contextul specific al beneficiarului (SNN) și cerințele stricte de conformitate, a preferat o abordare mai conservatoare, care să minimizeze riscurile de neconcordanțe între analiza inițială și soluția de proiectare. o Controlul versiunilor de documentație: Planificarea secvențială a activităților asigură o mai bună gestionare a versiunilor documentației, evitând potențiale probleme de integrare între livrabilele de analiză și cele de proiectare. o Flexibilitatea metodologică a OUM: Metodologia OUM este scalabilă și personalizabilă, ceea ce înseamnă că se poate adapta în funcție de natura și complexitatea proiectului. Astfel, alegerea de a organiza activitățile de analiză și proiectare în secvență nu reprezintă o încălcare a principiilor OUM, ci o adaptare rațională la nevoile specifice ale acestui proiect. În concluzie, activitatea de proiectare (Linia 41) a fost condiționată de finalizarea analizei (Linia 20) pentru a asigura o implementare mai sigură și mai controlată. Chiar dacă OUM permite desfășurarea acestor activități în paralel, a ales varianta care minimiza riscurile și asigura o mai bună coordonare a livrabilelor. Menționează că metodologia OUM permite atât secvențializarea cât și paralelizarea, alegerea unei abordări sau a celeilalte sau combinarea celor 2 abordări țin de adaptarea planificării la specificul fiecărui proiect. În acest caz abordarea secvențială a activităților prezintă avantajul unui control mai eficient a cerințelor identificate în faza de analiză, mai cu seama când vorbește de Pagina 110 din 171

un proiect care acoperă 3 entități mari. Acest control mai strict al cerințelor va genera o proiectare conformă și, implicit, o eficientizare a utilizării resurselor. Mai arată că comisia de evaluare subliniază faptul că planificarea sa nu include activități de îmbunătățire a soluției existente și că proiectarea ar putea fi inițiată mai devreme, încă din faza I. Totuși, acest raționament nu ține cont de faptul că etapa de analiză completă este crucială pentru o proiectare de calitate, iar orice tentativă de a începe proiectarea înainte de validarea completă a analizei ar putea genera riscuri de incompatibilitate între cele două faze. Solicită reevaluarea ofertei sale, având în vedere că abordarea sa secvențială este justificată de nevoia de a asigura calitatea și stabilitatea livrabilelor, fără a compromite succesul proiectului. II.32. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 f) - Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat”, punctul i). — „Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități, chiar dacă tehnic se pot execută în paralel și metodologia Oracle prevede această practică”. Consideră că aprecierea comisiei de evaluare, conform căreia planificarea activităților din oferta sa nu optimizează durata proiectului prin suprapunerea unor activități, este nefondată și nu reflectă o înțelegere completă a raționamentului din spatele abordării sale. În Planul de proiect (Gantt), societatea sa a propus o planificare secvențială a activităților, în mod deliberat, pentru a respecta specificul și complexitatea proiectului, precum și cerințele stricte de conformitate și auditabilitate ale beneficiarului. • Avantajele justificabile ale planificării secvențiale: o Claritate în relaționarea activităților: Secvențialitatea permite o vizibilitate crescută asupra dependențelor dintre activități, ceea ce facilitează controlul execuției. o Reducerea riscului de erori: Nu se riscă demararea unor activități fundamentate pe cerințe incomplete sau nevalidate. o Control predictibil al resurselor: Alocarea eficientă și etapizată a resurselor evită suprasolicitarea echipelor sau conflictul de resurse între activități paralele. o Calitatea și stabilitatea livrabilelor: Proiectarea soluției se bazează pe un set complet, verificat și aprobat de cerințe. o Simplificarea intervențiilor corective: Eventualele modificări sunt mai ușor de gestionat în lanț logic secvențial decât într-un sistem paralel complex. • Adaptare justificată la metodologia OUM Deși OUM este o metodologie flexibilă, care permite abordări iterative și activități desfășurate în paralel, nu impune acest lucru ca Pagina 111 din 171

obligatoriu, ci permite adaptarea în funcție de natura proiectului. Documentația oficială afirmă explicit că „OUM is scalable and tailorable”, ceea ce înseamnă că alegerea unei abordări secvențiale este validă atunci când este justificată prin nevoia de: o Minimizare a riscurilor operaționale; o Asigurare a unui control riguros asupra calității; o Aliniere la standarde stricte de documentație, verificare și audit, cum este cazul în proiectele critice derulate de SNN. • Comentariu față de afirmațiile comisiei: Comisia afirmă că „motivarea din contestație nu este inclusă în oferta tehnică”. Consideră că oferta sa include Planul de proiect (Gantt) care reflectă în mod clar alegerea unei abordări secvențiale, iar metodologia aplicată este justificabilă în contextul obiectivelor proiectului. O contestație este, prin natura sa, un act prin care ofertantul își explică sau detaliază intențiile și opțiunile deja exprimate în oferta inițială, nu un mijloc de completare a ofertei. Se menționează că metodologia OUM ar impune o abordare de tip Agile cu activități paralele. Menționează că, potrivit Agile Practice Guide citat de SNN, „agility is about appropriate tailoring”, iar implementarea unei metodologii Agile într-un proiect de tip critic nu înseamnă automat aplicarea unei paralelizări forțate, ci o ajustare rațională la contextul și riscurile specifice. Prin urmare, apreciază că depunctarea ofertei sale sub acest subfactor este nefundamentată, iar interpretarea rigidă a aplicării OUM contravine însăși principiului de flexibilitate și adaptabilitate al metodologiei, motiv pentru care solicită Consiliului ca, prin hotărârea ce o va pronunța, să dispună reevaluarea ofertei sale cu privire la subfactorul F2.1 f), în considerarea argumentelor prezentate mai sus. II.33. Referitor la punctul de vedere al autorității contractante privind aspectele contestate referitoare la „Subfactorul de evaluare nr. F2.1 f) - Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat”, punctul i). — „Cu mici excepții activitățile au un singur predecesor, activități anterioare, iar restul sunt de tip finish to start.” Consideră că argumentul invocat de comisia de evaluare pentru depunctarea ofertei sale este neîntemeiat, întrucât reflectă o interpretare formalistă a unei practici perfect valide de planificare și nu dovedește lipsa optimizării duratei proiectului. În cadrul planului de proiect inclus în oferta sa, activitățile sunt corelate în mod deliberat prin relații de tip Finish-to-Start (FS) și au, în cele mai multe cazuri, un singur predecesor logic principal, ceea ce reflectă o abordare rațională de structurare a lucrărilor, cu scopul de a asigura: o Claritate și predictibilitate în execuție - relațiile FS oferă o succesiune logică firească, ușor de urmărit și de gestionat; Pagina 112 din 171

o Maximizarea fluxului de lucru - fiecare activitate pornește imediat ce precedenta s-a încheiat, eliminând timpii de așteptare inutili; o Reducerea complexității lanțului de dependențe - relațiile multiple (de tip SS, FF etc.) cresc riscul de conflicte și erori în execuție, în special în proiecte critice; o Optimizare operațională - un model bazat pe FS cu un singur predecesor permite ajustarea mai rapidă a planificării în cazul unor modificări, fără a afecta lanțul de execuție global; o Controlul riscurilor - o succesiune bine definită reduce riscul de blocaje în execuție și facilitează monitorizarea progresului. În plus, abordarea propusă este aliniată cu specificul proiectului și cu cerințele stricte de trasabilitate și auditabilitate ale beneficiarului. Referitor la afirmația privind metodologia OUM: Este adevărat că Oracle Unified Method (OUM) permite utilizarea unor relații și structuri de lucru mai flexibile, inclusiv paralelism și abordare iterativă. Cu toate acestea, metodologia OUM este, prin definiție, scalabilă și adaptabilă, nu prescriptivă. Astfel, utilizarea relațiilor FS și a unui singur predecesor nu încalcă metodologia, ci reprezintă o adaptare rezonabilă pentru un proiect cu cerințe stricte de control, stabilitate și verificare etapizată a livrabilelor. Documentația oficială OUM subliniază posibilitatea ajustării metodologiei în funcție de: o complexitatea proiectului, o nivelul de risc, o gradul de formalizare cerut de client, o modul de organizare a echipelor și resurselor. Prin urmare, alegerea acestei structuri în planul Gantt reflectă o decizie strategică, nu o lipsă de preocupare pentru optimizare. În concluzie, apreciem că relațiile FS și folosirea unui singur predecesor pe activitate contribuie la simplificarea execuției, reducerea riscurilor și menținerea unui flux controlat și eficient de lucru. Astfel, afirmația că această abordare nu reflectă o preocupare pentru optimizarea duratei proiectului este nejustificată și nu ține cont de contextul și specificul proiectului. Pe această bază, solicită reevaluarea ofertei sale pentru subfactorul F2.1 f), întrucât decizia de depunctare nu reflectă realitatea tehnică și managerială a planificării proiectului. III. În ceea ce privește Punctul E. din contestație, „oferta tehnică ............................SA este neconformă deoarece nu a fost completată corespunzător cerințelor de la cap. 5.1 - Cerințe generale din caietul de sarcini”. Urmare a studierii detaliate a conținutului Proceselor verbale de evaluare puse la dispoziție de CNSC, înțelege să renunțe la acest capăt de cerere. Pagina 113 din 171

Pentru toate argumentele expuse mai sus, precum și pentru toate argumentele expuse pe larg în contestația sa, solicită: a) admiterea contestației, astfel cum aceasta a fost formulată pentru capetele de cerere așa cum a arătat în conținutul prezentului document și detaliate în contestație. b) să ia act de renunțarea sa la anumite capete de cerere astfel cum le-a prezentat mai sus. Prin adresa nr. E-DA-CONCL-SCRISE-01437-26-05-25, înregistrată la CNSC sub nr. 34839/27.05.2025 entitatea contractantă transmite punct de vedere față de concluziile scrise ale contestatorului. I. Cu privire la nerespectarea prevederilor art. 228 din Legea nr. 99/2016 privind transmiterea comunicării rezultatului procedurii (punctul c din contestație, punctul I din concluziile scrise). Entitatea contractantă, precizează faptul că această comunicare a rezultatului procedurii cu privire la oferta contestatorului, declarată admisibilă, dar necâștigatoare și clasată pe locul al doilea, a fost întocmită și transmisă ofertantului cu respectarea prevederile art. 228, alin. (2) lit. c) din Legea nr. 99/2016, în data de 17.04.2025 prin SEAP împreună cu publicarea, pentru participanții la procedura a raportului procedurii întocmit în conformitate cu structura definită prin Ordinul Președintelui ANAP nr. 1170/2021 - Anexa nr. 5. Cu privire la critica privind obligația entității contractante de a preciza în concret „caracteristicile și avantajele relative ale ofertei/ofertelor desemnate câștigătoare în raport cu oferta sa” menționează faptul că prin conținutul său, adresa de comunicare a rezultatului procedurii respectă prevederile legale anterior precizate, care nu impun un anume grad de detaliere, întrucât comunicarea în speță are menționat concret, în ce au constat caracteristicile și avantajele ofertei clasata pe locul întâi, respectiv punctajul obținut pentru oferta depusă. Mai mult, detalierea informațiilor voluminoase privind evaluarea propunerilor tehnice prezentate, modul de calcul al punctajelor pentru factorii tehnici precum și justificarea pentru care s-au acordat aceste punctaje, fiind prezentată în Procesul verbal de evaluare tehnică finală nr. DA_DA-25-00502-l8-03-2025 care conține 731 pagini, document care a fost pus la dispoziția contestatorului la momentul studierii dosarului achiziției. În concluzie, solicită Consiliului să constate caracterul nefondat al criticilor referitoare la conținutul adresei de comunicare a rezultatului procedurii, în sensul că prevederile legale aplicabile nu impun un anumit grad de detaliere a avantajelor ofertei câștigătoare. II. Referitor la situația pe fond, netemeinicia și nejustificarea depunctării ofertei Asocierii formată din ......... SRL, în calitate de Lider de Asociație și ............................SRL, în calitate de Asociat, pentru componenta tehnică (punctul D din Contestatie, punctul II din Concluziile scrise). Pagina 114 din 171

Arată că contestatorul a depus documentul intitulat „Concluzii scrise” prin Adresa ............................ nr. 1914/20.05.2025, prin intermediul cărora nu prezintă și nici nu combate argumentele aduse de entitatea contractantă în ceea ce privește modul de acordare a punctajului pentru factorii de evaluare (dinpotrivă la unele critici s-a renunțat) dar în schimb, prin motivarea acelorași puncte se încearcă argumentarea prin prezentarea unor motive noi care nu se regăsesc în oferta tehnică inițială și nici în răspunsurile la solicitările de clarificări. Or, raportat la prevederile art. 21 alin. (3) din Legea nr. 101/2016, și anume „Este inadmisibilă prezentarea unor noi motive de contestare și/sau formularea unor noi capete de cerere pe calea concluziilor scrise sau orale ori a precizărilor la contestație ulterior termenului legal de formulare a acesteia”. Astfel, prin concluziile scrise sau precizările la contestație care se pot depune și în urma studierii documentelor dosarului constituit la CNSC, contestatorul poate doar dezvolta/detalia motivele care se regăsesc deja într-o primă contestație, fără a depăși cadrul de formulare a acestora, respectiv aspectele vizate inițial, dar nu poate completa aceste motive cu noi motive de contestare și/sau noi capete de cerere, sub sancțiunea inadmisibilității acestora. Prin urmare, în cazul în care există noi motive de contestare și/sau noi capete de cerere există, în schimb, dreptul formulării unei noi contestații, în condițiile legii. În aceste condiții, solicită Consiliului să constate inadmisibilitatea criticilor din cuprinsul concluziilor scrise care conțin motive de contestare care nu se regăsesc, după cum a fost precizat și anterior, în contestația depusă de ............................ nr. 1602/28.04.2025, fiind formulate pentru prima dată, de către contestator, prin respectivele concluzii scrise. Detaliază în cele ce urmeaza fiecare punct din Concluziile scrise (punctul II) cu argumente care atestă considerentele sale privind respingerea susținerilor contestatorului ca inadmisibile în ceea ce privește motivele noi invocate și totodata, respingerea acestora ca nefondate: II. 1 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul i). – „Riscurile nu sunt tratate din punct de vedere impact și nici al probabilităților de expunere la risc” [5] - [11]. Răspuns SNN: Entitatea contractantă precizează că prin detaliile referitoare la riscuri, incluse în oferta tehnică în Anexa 1 - Formularul IV.4.1.a, pentru cerința 24.2 Riscuri, la pag. 261-264, contestatorul a răspuns doar la cerința din Caietul de sarcini, care nu include specificații din metodologia de management de proiect sau din metodologia de implementare, iar răspunsul a fost considerat conform. În concluziile scrise înaintate de contestator (prin Adresa ............................ nr. 1914/20.05.2025) la Pagina 115 din 171

paragraful [8] este specificat că „riscurile din Anexa IV. 1 sunt tratate prin măsuri de reducere, ceea ce presupune în mod implicit o analiză de severitate (impact + probabilitate)”, însă rezultatul explicit al acestei analize nu a fost inclus în ofertă. Pentru evaluarea subfactorului F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare au fost considerate liniile directoare incluse în Anunțul de participare, în Anexa 1 - Fișă de date informații componentă tehnică, inclusiv tratarea riscurilor. Oferta tehnică nu prezintă clar estimarea calitativă, ierarhia riscurilor sau gruparea acestora din punct de vedere al severității și al probabilității de apariție, prin corelare cu metodologia prezentată în Anexa 2 - Metodologia de management de proiect, în cap. 3.3.8 Managementul Riscului, pag. 10-11, completată cu riscurile specifice proiectului identificate în Anexa 1 - Formularul IV.4.1.a, astfel încât să dovedească evaluarea și prioritizarea eficientă a riscurilor, adaptate proiectului, respectiv corelarea măsurilor propuse de reducere a riscurilor cu severitatea/impactul produs și probabilitatea de apariție, ceea ce ar fi condus la acordarea unui punctaj superior celui obținut. II.2 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul ii). – „Nu este descrisă arhitectura sistemului” [12] - [14]. Răspuns SNN: Arată că în Anexa 1 - Formularul IV.4.1.a, pentru cerința de la cap. 5.1.2.13 Cerință administrare, la pag. 53, contestatorul a răspuns că va livra documentația specifică administratorilor de sistem, inclusiv documentația despre arhitectura sistemului, fără a include alte detalii despre arhitectură conform metodologiei de implementare. Pe cale de consecință cerința din CS a fost considerată indeplinită dar pentru acordarea punctajului maxim la factorul F.2.1 a) nu au fost îndeplinite cerințele pentru motivele arătate mai jos. Pentru evaluarea subfactorului F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare au fost considerate liniile directoare incluse în Anunțul de participare în Anexa 1 - Fișă de date informații componentă tehnică, inclusiv detalierea dependențelor interne și externe. În Anexa 3 - Metodologia de implementare Oracle (OUM) nu a fost descrisă arhitectura sistemului actual și nici cerințele minimale pentru extinderea soluției și pentru integrările necesare atât dintre componente cât și cu alte aplicații. Descrierea arhitecturii în cadrul OUM nu este doar o formalitate, ci o componentă esențială pentru succesul proiectului. Astfel, identificând corect arhitectura sistemului se demonstrează o înțelegere clară a cerințelor, se reduc riscurile, se optimizează timpul de implementare și este facilitată dezvoltarea și mentenanța pe termen lung, contribuind la livrarea unei soluții robuste, scalabile și aliniate cu obiectivele proiectului. Pagina 116 din 171

II.3 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul iii). – „Metodologia OUM este descrisă în termeni generali” [15] - [18]. Răspuns SNN: În concluziile scrise înaintate de contestator este specificat la paragraful [17] că „Am structurat metodologia în conformitate cu cerințele din Caietul de sarcini”, însă Caietul de sarcini nu conține cerințe referitoare la modalitatea de detaliere sau la structura de prezentare a metodologiei de implementare. În cap. 12 - Cerințe de asigurarea calității, la pag. 43, se solicită: „Pentru conformitate, pe perioada de derulare a proiectului se va respecta o metodologie a unui standard de implementarea sistemelor informatice și mentenanța acestora”. Pe cale de consecință cerința din CS a fost considerată îndeplinită (din Anexa 1 - Formularul IV.4.1.a, pag. 250: „Detalierea metodologiei de implementarea sistemelor informatice și mentenanța acestora este detaliată în Anexa 2 - Metodologie de Management de proiect și Anexa 3 - Metodologie de implementare Oracle (OUM)”) dar pentru acordarea punctajului maxim la factorul F.2.1 a) nu au fost îndeplinite cerințele pentru motivele arătate mai jos. Pentru evaluarea subfactorului F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare au fost considerate liniile directoare incluse în Anunțul de participare în Anexa 1 - Fișă de date informații componentă tehnică, inclusiv detalierea modului de abordare a proiectului. în Anexa 3 - Metodologia de implementare Oracle (OUM), activitățile detaliate în cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, pag. 15- 69, nu sunt corelate nici cu cap. 1. Metodologia de implementare OUM - (Oracle Unified Methodology), pag. 3-14, în care metodologia este prezentată nestructurat, și nici cu etapele sau activitățile majore din Graficul Gantt. II.4 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul iv). – „Capitolele nu sunt numerotate și legătura dintre acestea se poate intui doar prin denumirea etapei.” [19] - [23]. Răspuns SNN: În concluziile scrise, contestatorul precizează la paragraful [20]: „Referirea comisiei la lipsa de legătură între Anexa 3 și Anexa 2 (Metodologia de management de proiect) este irelevantă în contextul în care noi nu am invocat Anexa 2 ca justificare pentru metodologia OUM, ci doar pentru a arăta caracterul consecvent al structurării și numerotării documentelor din ofertă”. Cu toate că în cadrul ofertei tehnice, în Anexa 1 - Formularul IV.4.l.a, cap. 12, pag. 250, referitor la cerința despre metodologia de implementare se menționează și Anexa 2: „Detalierea metodologiei de implementarea sistemelor informatice și mentenanța acestora este Pagina 117 din 171

detaliată în Anexa 2 - Metodologie de Management de proiect si Anexa 3 - Metodologie de implementare Oracle (OUM)”, ne menținem aprecierea despre includerea Anexei 2 ca irelevantă în critica din contestația inițială, deoarece cuprinsul Anexei 2 este structurat în mai multe capitole, fiecare cu subcapitole, spre deosebire de Anexa 3, care conține un singur capitol, cu două subcapitole care nu sunt într-o subordonare logică cu capitolul 1. Prin structura Anexei 3 nu este realizată o diferențiere clară între descrierea metodologiei și Planul de implementare. În cadrul metodologiei OUM, Planul de implementare și Graficul Gantt sunt ambele instrumente esențiale pentru managementul proiectului, dar au roluri și conținuturi distincte. Planul de implementare răspunde la întrebările „ce” și „cum” la nivel strategic, iar Graficul Gantt la întrebarea „când” la nivel operațional. Planul de implementare în OUM este un document care definește abordarea generală, strategia și metodologia pentru a transforma cerințele și designul arhitectural într-o soluție funcțională. Conform metodologiei OUM, Planul de implementare conține: obiectivele și scopul proiectului, abordarea metodologiei și strategiei de dezvoltare, arhitectura soluției (atât documentația pentru design, componente, interfețe, dar și strategiile de integrare, securitate și scalabilitate), strategia de implementare, resursele, managementul riscurilor, planul de comunicare, standarde de calitate, procese de revizuire și aprobare, livrabilele principale. Graficul Gantt este o reprezentare a cronologiei proiectului și un instrument vizual de planificare și urmărire a derulării contractului, care descompune Planul de implementare în activități specifice, atribuie durate și resurse și identifică dependențe între activități. Graficul Gantt conține activități cu durată și resurse alocate, dependențe, milestone-uri, livrabile, permițând urmărirea progresului și punând în evidență drumul critic ale proiectului, pe toată durata de viață a acestuia. În concluzie, Graficul Gantt este un derivat al Planului de Implementare, pe care îl completează. Conform cerinței 5.1.2.1 din Caietul de sarcini, pag. 5, Planul de implementare se livrează la inițierea proiectului, iar Graficul Gantt este, printre altele, un instrument de urmărire a progresului proiectului, în continuă actualizare pe parcursul implementării. Ținând cont de modul în care a fost structurată Anexa 3, consideră că termenii Plan de implementare și Grafic Gantt au fost folosiți doar pentru reprezentarea grafică a planului, însă, dacă ia în considerare definițiile riguroase ale acestor noțiuni în cadrul OUM, atunci subcapitolul 1.1, pag. 15-69, ar trebui să fie de fapt denumit Planul de implementare. Prin urmare, reiterează faptul că în cap. 1. Metodologia de implementare OUM - (Oracle Unified Methodology), pag. 3-14, nu sunt incluse subcapitole și prezentarea metodologiei este nestructurată, adică etapele nu sunt numerotate, așa cum rezultă și din cuprinsul prezentat. Pagina 118 din 171

II.5 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul v). – „Planul de proiect este în mică măsură corelat cu planul GANTT, sunt diferențe majore între activități și livrabile și sunt necorelate.” [24] - [29]. Răspuns SNN: În concluziile scrise, la paragrafele [25] - [27], contestatorul folosește sintagma '„planul GANTT” sau „planul de proiect (GANTT)” de unde reiese că nu a ținut cont de diferențele între noțiunile Plan de implementare și Grafic Gantt, așa cum sunt definite prin metodologia OUM. Pentru evaluarea subfactorului F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare au fost considerate liniile directoare incluse în Anunțul de participare în Anexa 1 - Fișă de date informații componentă tehnică, inclusiv detalierea modului de abordare a proiectului, prin urmare a fost evaluată detalierea Planului de implementare, care ar trebui să urmeze metodologia OUM și să includă un Grafic Gantt, în care să se regăsească etapele, activitățile, rolurile și livrabilele din plan. în Anexa 3, la cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, prin comparație cu cap. 1.2.1 Graficul de tip Gantt, sunt prezentate o serie de activități și roluri care nu se regăsesc în Graficul Gantt, de exemplu cele care descriu etapele de testare, pag. 43-48: - Definirea misiunii evaluării - Verificarea abordării testării - Implementarea Mediului Intern de Testare - Validarea stabilității artefactului testat - Testarea și evaluarea artefactului testat - îndeplinirea misiunii acceptabile - îmbunătățirea artefactelor de testare Pe aceste activități de testare sunt alocare rolurile despre care la punctul II.6 F2.1 a) vi), de mai jos, a arătat că justificările din contestație nu sunt consistente, aceste roluri fiind asimilare atât experților cheie desemnați în proiect, cât și experților non cheie, care nu au fost nominalizați în oferta tehnică. II.6 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect si al metodologiei de implementare”, punctul vi). - „Activități și subactivități din planul de proiect nu se regăsesc în metodologie si GANTT” [30] - [35]. Răspuns SNN: În concluziile scrise, contestatorul menționează la paragraful [32]: „În Anexa 3 - Metodologia de implementare Oracle (OUM), subscrisa a structurat și detaliat activitățile și subactivitățile relevante în cadnd Capitolului 1.1 - Metodologia de implementare și mentenanță adaptată la specificul proiectului, respectând cerințele de conținut impuse de autoritatea contractantă”. Pagina 119 din 171

Însă Caietul de sarcini nu conține cerințe care să impună conținutul metodologiei de implementare, pe care urmează să o aleagă și să o prezinte ofertantul, singura cerință fiind cea din cap. 12, la pag. 43, prin care se solicită: „Pentru conformitate, pe perioada de derulare a proiectului se va respecta o metodologie a unui standard de implementarea sistemelor informatice și mentenanța acestora”. Tot în concluziile scrise, contestatorul menționează la paragraful [32]: „În Capitolul 1.2 - Planul de implementare, este prezentat Graficul GANTT, care transpune în mod logic și cronologic activitățile și livrabilele identificate în metodologia de implementare. Structura GANTT-ului urmează etapele proiectului, detaliind sarcini, responsabilități și termene aferente”. Susține că Graficul Gantt detaliat în ofertă nu prezintă activitățile grupate pe cele 2 faze ale implementării, extindere și adăugare de noi module, și nici în ordine cronologică, pentru a se putea urmări și progresul fiecărei faze de implementare, nu doar al proiectului integral (în Graficul Gantt prezentat, activitățile sunt grupate pe etapele de implementare specifice unui proiect IT, de implementare software, comune celor 2 faze). În plus, metodologia de implementare nu poate să conțină activitățile și livrabilele unui proiect, așa cum se motivează în concluziile scrise, acestea sunt derivate din Planul de implementare, în care se urmărește metodologia OUM. Tot în concluziile scrise, contestatoarea menționează la paragraful [32]: „Activitățile de testare menționate între paginile 43-48 din metodologia propusă sunt reflectate și în GANTT, la etapele de testare aferente Fazei I și Fazei II, conform liniei 87, respectiv 120”. Această afirmație, prin care activitățile de testare din cap. 1.1.3 corespund unor activități incluse în Graficul Gantt și pe care sunt alocați experți cheie (în ofertă sunt nominalizați doar experții cheie), nu este consistentă cu motivarea din contestația inițială de la punctul F2.1 b) iv) unde, despre aceleași activități de testare, se menționează că sunt alocate unor experți non-cheie: „Astfel în documentul Anexa 3 - Metodologia de implementare Oracle (OUM) Jinal.docx, la cap 1. 1.3 Etapa de configurare, testare și acceptanță pe mediul de test, pe lângă experții cheiei solicitati, sunt prezentate și alte roluri precum: -Managerul de testare -Analist de Testare -Designer de Testare -Proiectantul de Testare -Tester -Manager Configurație Pagina 120 din 171

Aceste roluri prezentate în Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului pot fi asimilate experților non-cheie.”, iar în concluziile scrise de la punctul II.17 - F2.1 b) iv) se menționează la paragraful [111]: „Aceste roluri nu sunt echivalente cu experții-cheie, nici nu sunt solicitate explicit prin Caietul de sarcini, ci reprezintă roluri metodologice interne, specifice etapelor de testare, alocate în vederea asigurării unei implementări de calitate, conform practicilor din cadrul metodologiei OUM”, și de asemenea în concluziile scrise de la punctul II.27 - F2.1 d) vi) se menționează la paragraful [168]: „Aceste roluri corespund unor resurse non-cheie, prezentate ca parte integrantă a procesului de implementare, dar neindividualizate nominal în graficul Gantt, întrucât nu sunt obligatorii conform cerințelor minime din documentația de atribuire”. Entitatea contractantă precizează că în Graficul Gantt activitatea de testare corespunzătoare liniei 87 este alocată rolului Specialist în implementarea de tehnologii Oracle EBS HCM și nu unui rol specific de testare. De asemenea arată că în concluziile scrise, contestatorul menționează la paragraful [33]: „În concluzie, activitățile, subactivitățile și livrabilele propuse sunt coerente, justificate și corelate între metodologia de implementare și Planul de proiect (GANTT). Diferențele de granularitate nu afectează înțelegerea sau fezabilitatea planului, ci oferă un nivel suplimentar de detaliu și control”, însă activitățile și subactivitățile prezentate în cap. 1.1 al Anexei 3 sunt nestructurate, adică nu sunt numerotate în cadrul unei etape, făcând extrem de dificilă și imprecisă corelarea livrabilelor (intrările și ieșirile unei activități), în cadrul aceleiași etape sau între etape. II.7 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul vii). – „Planul de proiect conține livrabile irelevante pentru etapa de testare” [36] - [41]. Răspuns SNN: Toate livrabilele solicitate expres prin cerințele Caietului de sarcini sunt prezentate în oferta tehnică, prin urmare aceasta a fost considerată conformă. La evaluarea ofertei și prin punctul de vedere transmis nu a negat îndeplinirea acestei solicitări. Referitor la livrabilele suplimentare incluse în ofertă (în Anexa 3 - cap 1.1, de exemplu: Planul de integrare a versiunilor, Planul general de testare, Planul de proiectare), prin concluziile scrise sunt aduse justificări care nu se regăsesc în ofertă, cum ar fi la paragraful [37]: Pagina 121 din 171

„Acestea sunt instrumente standard în cadrul metodologiei Oracle Unified Method (OUM), utilizate pentru gestionarea riscurilor și asigurarea calității;”. Insă aceste livrabilele (Planul de integrare a versiunilor, Planul general de testare, Planul de proiectare) nu sunt menționate în Anexa 3 la cap. 1, pag. 3-14, în care este detaliată metodologia OUM. În plus, în Anexa 3 la cap. 1.1, pag. 15-69, nu sunt incluse justificările transmise prin concluziile scrise la paragraful [37]: „Observația privind lipsa indicării momentului elaborării anumitor documente (ex. Planul general de testare) nu reflectă o neconformitate, ci este caracteristică metodologiilor iterative, unde anumite livrabile sunt: o Predefinite ca artefacte reutilizabile (de ex., din fazele anterioare ale ciclului de viață); o Create prin activități de tip „rolling wave planning”, care nu sunt întotdeauna detaliate în GANTT la nivel de document individual”. Prin urmare, în Anexa 3 a ofertei tehnice nu se pot identifica motivarea elaborării și corelarea între anumite livrabile menționate în activitățile de testare. Mai mult, prin argumentele transmise se încearcă modificarea ofertei inițiale. II.8 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul viii). – „Activitatea de testare - nu conține acțiuni pentru rezolvarea problemelor la testare și nici o analiză a rezultatelor obținute și modul în care se pot rezolva” [42] - [52]. Răspuns SNN: Prin concluziile scrise în paragrafele [43] - [51], sunt reluate criticile din contestația inițială, prin care se încearcă o corelare între activități de testare menționate în Anexa 3, la cap. 1.1.3, și 2 activități de testare internă incluse în Graficul Gantt, însă nu se ține cont de punctul de vedere deja transmis, prin care clarifica faptul că unul dintre motivele pentru care nu s-a acordat punctaj maxim pentru subfactorul F2.1 a) este acela că „Testarea de acceptanță nu include activități pentru rezolvarea problemelor identificate la testare și retestare și nici analiza rezultatelor testării”, adică este vorba despre etapa de testare de acceptanță, executată de echipa Beneficiarului, pe mediul de Test, la finalul activităților de configurare, ultima formă de testare înainte de trecerea în producție a sistemului, prin care se validează atât configurarea și funcționalitățile soluției, cât și fluxurile de lucru agreate, și nu de testarea internă, executată de echipa Prestatorului, anterior testării de acceptanță. Argumentele referitoare la metodologia OUM de tip Agile sunt corecte, însă nu justifică includerea în Graficul Gantt a activităților de reconfigurare numai după testarea internă și omiterea acestor activități în paralel cu/după testarea de acceptanță, nefiind prevăzută o rezervă de timp pentru remedierea deficiențelor descoperite Pagina 122 din 171

în timpul testării de acceptanță, a căror rezolvare ar putea împiedica trecerea în producție a soluției. II.9 Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect si al metodologiei de implementare”, punctul ix). - „în Gantt nu sunt assignati responsabilii pe elaborarea livrabilelor.” [53] - [64] Răspuns SNN: În răspunsul cu nr. 407/30.01.2025 la solicitarea de clarificări a entității contractante (adresa nr. SNN FRZI- 25-00114/23.01.2025, punctul 5), contestatorul a precizat la pagina 15: „Livrabilele aferente fiecărei etape sunt rezultatul activităților aferente etapei efectuate de resursele alocate. Astfel, resursele alocate pentru producerea livrabilelor aferente unei etape de proiect sunt aceleași cu cele alocate pe activitatile aferente etapei”. Arată că același raționament este folosit și în concluziile scrise, însă acesta nu poate fi utilizat în toate situațiile, motiv pentru care va da 2 exemple: În pagina 2 a Graficului Gantt, în etapa Proiectarea soluției tehice - Faza I nu este alocat rolul ......... Baze de date Oracle pe niciuna dintre activități, însă la livrabile este inclusă Documentația bazei de date, la linia 46: Și pagina 3 a Graficului Gantt, prezentată mai jos, se poate observa că este imposibilă identificarea responsabililor pentru elaborarea și asumarea unui livrabil doar prin raportare la responsabilii activităților anterioare, incluse în aceeași etapă cu livrabilul, cum se justifică în concluziile scrise. Mergând pe acest raționament, în exemplul de mai jos, pentru livrabilele din Etapa de Proiectare a soluției tehnice - Faza II ar trebui să fie responsabil doar rolul de Arhitect de sistem Oracle EBS care este alocat pe activitățile etapei, mai exact pentru livrabilul Documentația bazei de date - faza II, de la linia 63, nu ar trebui alocat și rolul ......... baze de date Oracle. Acest lucru este incorect, deoarece rolul ......... baze de date Oracle trebuie alocat în elaborarea livrabilelor Documentația bazei de date și Documentația despre arhitectura sistemului. În susținerea faptului că rolul ......... baze de date Oracle trebuie alocat în elaborarea livrabilelor Documentația bazei de date și Documentația despre arhitectura sistemului, adăugă și justificarea de la punctul II.14 F2.1 b) punctul i), paragraful [98]: „Responsabilii acestor documente sunt implicit definiți în echipa tehnică - de ex., Arhitectul de sistem și Administratorul de baze de date, ambii experți-cheie, conform propunerii tehnice;”, și consideră că nominalizarea explicită a responsabililor este utilă, prin urmare, este justificată solicitarea de clarificare a Entității Contractante (prin adresa nr. SNN_FRZI- 25- 00114/23.01.2025, punctul 5), în urma căreia însă Pagina 123 din 171

Graficul Gantt actualizat transmis de contestator tot nu a inclus alocarea responsabililor pentru livrabile. Mai mult, în Anexa 3, la cap. 1.1.2 - Etapa de proiectarea soluției tehnice, pag. 28-35, nu este menționat ca responsabil pe nicio activitate rolul de ......... baze de date Oracle, iar pe activitatea Proiectarea bazei de date este alocat doar rolul Arhitect de sistem, la pagina 32. În concluziile scrise, la paragraful [61], se menționează că: „Dacă ar fi existat neclarități asupra rolului principal sau a delimitării între „responsabil” și „avizator”, acestea puteau fi soluționate prin solicitări de clarificare, fără a impune o penalizare”. Nici prin cerințele Caietului de sarcini, și nici prin Anexa 3 la oferta tehnică nu au fost prezentate diferențele între noțiunile de „responsabil” sau de „avizator” pentru elaborarea unui livrabil, prin urmare acesta nu a fost un motiv de depunctare în evaluarea subfactorului F2.1 a), în Graficul Gantt, clarificarea referitoare la alocarea rolurilor și experților care vor fi implicați în elaborarea livrabilelor a avut ca scop evidențierea experților care își vor asuma documentația prin semnătură, în special pentru rolurile pentru care au fost alocați de către ofertant câte 2 experți. Nu toate livrabilele corespunzătoare unei etape trebuie să aibă alocate la responsabili toate rolurile implicate în toate activitățile etapei respective, iar informația nu este redundantă, cum încearcă să argumenteze contestatorul în concluziile scrise. Prin alocarea responsabililor pe livrabile s-ar evita omiterea sau includere eronată a unor roluri și experți în asumarea documentației de proiect. II.10 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul x). – „Referitor la liniile 42 și 73 din Gantt - nu este menționat decât expertul Specialist ORACLE EBS HCM, fără a fi implicat și expertul Architect de sistem ORACLE EBS” [65] - [71]. Răspuns SNN: Oferta tehnică trebuie să prevadă clar rolul necesar execuției unei activități, indiferent de experiența profesională complementară a altor membri ai echipei de implementare. Doar din cv-urile și documentele justificative incluse în oferta tehnică nu se poate aprecia experiența profesională în activități similare a celor 2 experți-cheie propuși pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM, însă pentru cele 2 activități incluse în Graficul Gantt la liniile 42 și 73, de Design soluție optimizată și Upgrade Oracle Linux, consideră că trebuie alocat și rolul Arhitect de sistem Oracle EBS, pentru care activitățile de design și upgrade au fost solicitate prin Caietul de sarcini, la cap. 5.1.2.2 - Cerințe personal tehnic de specialitate, de la pag. 8: „(3) Arhitect de sistem Oracle EBS (1 expert). Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Pagina 124 din 171

Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”. Acesta este unul dintre motivele pentru care punctajul obtinut este la primul nivel din barem în special pentru modalitatea de alocare a sarcinilor personalului implicat, la evaluarea subfactorului F2.1 a). II.11 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xi). – „Etapele din GANTT sunt prezentate consecutiv și nu în ordinea cronologică, adică să fie prezentate activitățile pentru Faza 1, după care activitățile pentru Faza 2” [72] - [79]. Răspuns SNN: Caietul de sarcini, prin cap. 5.1.2.1 - Cerințe management contract, nu specifică restricții de prezentare pentru Graficul Gantt, oferta tehnică fiind, din acest punct de vedere, conformă. Structura Graficului Gantt este stabilită prin metodologia de implementare OUM, iar monitorizarea progresului activităților este unul dintre scopurile sale principale, alături de planificarea inițială. Prin urmare, Graficul Gantt nu este doar un plan static, ci un instrument dinamic, care evoluează odată cu proiectul, și care trebuie să permită identificarea cu ușurință a progresului în timp real, întârzieri și devansări față de planificarea inițială. În evaluarea subfactorului F2.1 a) cu privire la dependențele interne și externe, dar și la modalitățile de monitorizare a stadiului de implementare, în plus față de justificarea din punctul de vedere transmis anterior, adăugăm faptul că s-a ținut cont și de Graficul de facturare, pentru care ofertantul a folosit o reprezentare cronologică a milestone- urilor și livrabilelor, adică acestea sunt prezentare în ordinea logică a celor 2 faze de implementare ale proiectului, iar corelarea cu Graficul Gantt se realizează foarte dificil din cauza modalității de prezentare alese pentru acesta, în care activitățile sunt grupate pe faze în cadrul fiecărei etape. Menționăm de asemenea faptul că prin cerințele Caietului de sarcini nu s-a impus o structură pentru Graficul de facturare, iar ofertantul nu a inclus procente din costul total pentru etape, prin urmare a prezentat doar un plan de proiect simplificat, din care lipsește efortul estimat pentru fiecare componentă. II.12 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xii) – „Nu sunt menționati experții suplimentari (non cheie) pe activitățile și livrabile din Plan + GANTT” [80] Contestatorul a renunțat la acest punct. II.13 „Subfactorul de evaluare nr. F2.1 a) - Gradul de detaliere al planului de proiect și al metodologiei de implementare”, punctul xiii) – „Nu sunt prezentate activitățile care revin personalului SNN” [81] - [90]. Pagina 125 din 171

Răspuns SNN: Caietul de sarcini conține cerințe pentru activitățile pe care urmează să le îndeplinească echipa Prestatorului de servicii. Activitățile de la liniile 87 și 120 din graficul Gantt prezentat de contestatoare sunt singurele care includ la responsabili și echipa de proiect a Beneficiarului, iar acestea rezultă direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului.”, aceste activități de acceptanță fiind prestate împreună de echipa Furnizorului și de reprezentanți ai echipei Beneficiarului. Cu toate acestea, echipa de proiect a Beneficiarului nu a fost inclusă în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3 a ofertei tehnice. Conform metodologiei OUM prezentate și bunelor practici în domeniul managementului de proiect, Graficul Gantt trebuie să includă activități atât pentru Furnizor, cât și pentru Beneficiar, fiind o reprezentare fidelă a întregului efort al proiectului, prin integrarea contribuțiilor și dependențelor ambelor părți. Proiectele de implementare Oracle sunt, prin natura lor, eforturi colaborative, iar multe activități ale Furnizorului (cum ar fi dezvoltarea sau configurarea) depind de intrări și decizii din partea Beneficiarului (cum ar fi aprobarea cerințelor, furnizarea datelor, participarea la sesiuni de testare, pregătirea utilizatorilor finali). Ignorarea activităților beneficiarului în Graficul Gantt creează un tablou incomplet și nerealist al dependențelor proiectului. Includerea activităților ambelor părți asigură transparență totală cu privire la stabilirea responsabilităților clare și reduce riscul de apariție a întârzierilor. Vizibilitatea acestor activități în Graficul Gantt permite identificarea timpurie a riscurilor și elaborarea unor planuri de atenuare. Dacă Graficul Gantt conține doar activitățile Furnizorului, durata totală a proiectului este subestimată. Timpul necesar pentru revizuiri, aprobări, pregătirea datelor, instruire utilizatori finali și testare din partea Beneficiarului poate fi semnificativ și trebuie planificat explicit. Beneficiarul este esențial în fiecare etapă a proiectului, prin următoarele activități: definirea cerințelor, validarea viziunii, aprobarea arhitecturii, design, revizuiri de prototipuri pentru noile module, pregătirea datelor, testarea de acceptanță, migrarea datelor, trecerea în producție, operarea și administrarea sistemului, dar și suportul post-implementare. În evaluarea subfactorului F2.1 a) cu privire la dependențele interne și externe s-a ținut cont de faptul că nu sunt prezentate dependențe externe și nu au fost prevăzute activități în sarcina SNN, care însă pot afecta durata și rezultatele proiectului. II.14 „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul i). – „Documentația de Baza de date și Documentația de Arhitectură a sistemului nu sunt Pagina 126 din 171

livrabile aferente Fazei 1. Acestea sunt identice cu cele din Faza 2” [91] - [102]. Răspuns SNN: Precizarea contestatorului din concluziile scrise de la paragraful [102], precum că: „Documentațiile din Faza I sunt versiuni parțiale/ intermediare, necesare pentru fiecare etapă de analiză și implementare;” nu se regăsește în oferta tehnica. Astfel, în opinia sa, contestatorul încearcă să inducă, prin concluziile scrise Consiliului, că a folosit terminologii sau definiții în cadrul ofertei tehnice care de fapt au respectat cerințele Caietului de Sarcini. În fapt în oferta tehnică contestatorul în loc să facă referiri la cele două documentații (Documentația de Baza de date și Documentația de Arhitectură a sistemului) doar pentru faza II a proiectului, aceasta face mențiuni dupa cum prezintă mai jos: Anexa 3 menționeaza următoarele: „Documentația despre arhitectura sistemului - Faza I” - la pag. 28 „Documentația despre arhitectura sistemului - Faza II” - la pag. 30 „Documentația despre arhitectura sistemului - Faza I (actualizat) „Documentația despre arhitectura sistemului - Faza II (actualizat)” - la pag. 31 și 34 „Documentația despre arhitectura sistemului - Faza I (final) „Documentația despre arhitectura sistemului - Faza II (final) „ - la pag. 33 „Documentația despre arhitectura sistemului - Faza I (revizuit) „Documentația despre arhitectura sistemului - Faza II (revizuit) „ - la pag. 34 „Documentația despre arhitectura sistemului - Faza II, actualizată „ - la pag. 54 „Documentația bazei de date -faza I” - la pag. 32 și 34 „Documentația bazei de date - faza II” - la pag. 32 și 35 „Documentația bazei de date - Faza II, actualizată” - la pag. 53 și 54 iar în Graficul Gantt este menționată actualizarea doar la finalul implementării și doar pentru documentațiile corespunzătoare Fazei II, la liniile 155 și 156. În concluzie, arată că oferta tehnică tratează livrabilele Fazei II, Documentația bazei de date și Documentația despre arhitectura sistemului, ca pe livrabile distincte pentru Faza I și Faza II, adică similar modului în care sunt prezentate Documentația cu specificațiile funcționale pentru faza I și Documentația cu specificațiile funcționale pentru faza II, care sunt livrabile cu conținut și termen de livrare diferite, și nu ca versiuni ale aceluiași document. II.15 „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul ii). – „Experții Pagina 127 din 171

suplimentari (non cheie) nu au fost menționați în GANTT pe activitatea în care va fi implicat.” [103] Contestatorul a renunțat la acest punct. II.16 „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul iii). – „Planul de proiect face referire plan de integrare versiuni iară corespondenta în CS și GANTT” [104] - [109]. Răspuns SNN: Arată că în concluziile scrise, contestatorul precizează în cadrul paragrafului [109]: „Contrar celor susținute de SNN în răspunsul la contestație, faptul că nu am detaliat conținutul documentului și atribuțiile privind elaborarea sa nu este o omisiune relevantă pentru evaluarea conformității cu cerințele caietului de sarcini, în condițiile în care: Nu a fost solicitat un astfel de document ca livrabil; Activitatea de integrare este oricum acoperită de activitățile din metodologie și din Planul de proiect; Detalierea excesivă a documentelor interne ar încărca nejustificat oferta tehnică”. Prin evaluarea corelării dintre planul de proiect și cerințele din Caietul de sarcini nu s-a urmărit conformitatea ofertei tehnice, prin urmare nu este relevant faptul că documentul Plan de integrare a versiunilor nu este solicitat printr-o cerință a Caietului de sarcini, ci faptul că acesta a fost menționat în Anexa 3 (din oferta tehnică) la cap. 1.1, fără a se prezenta necesitatea sau utilitatea acestuia (cine îl elaborează, ce conține) și nici corelarea cu metodologia din cap. 1 sau cu Graficul Gantt. Mai mult, activitatea de integrare (a versiunilor) nu este menționată nici în metodologia din cap. 1 și nici în Graficul Gantt. Prin urmare, consideră că „detalierea excesivă” prin includerea în cap. 1.1 al Anexei 3, fără motivație și fară menționarea corespondențelor în Graficul Gantt, a unor documente precum Plan de integrare a versiunilor (dar și: Plan general de testare sau Arhitectură Testare Automată), „încarcă nejustificat oferta tehnică”. II.17 „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul iv). – „Planul de proiect conține roluri suplimentare pentru testare fără corespondență în GANTT ți CS” [110] - [112]. Răspuns SNN: În motivarea inițială a acestui punct, adică F2.1 b) iv), contestatorul precizează despre rolurile aferentele activităților de testare că „Aceste roluri prezentate în Metodologia de dezvoltare software - OUM - Oracle Unified Methodology adaptată la specificul proiectului pot fi asimilate experților non-cheie.”, iar în motivarea inițială din contestatie, referitor la punctul F2.1 a) viii), despre aceleași activități de testare prezentate în cap. 1.1.3 al Anexei 3 contestatorul a precizat că sunt corelate cu unele activități de testare din graficul Gantt și „Aceste acțiuni Pagina 128 din 171

se vor efectua de catre experții cheie alocați”, prin urmare nu se poate stabili o corespondență clară între rolurile alocate pe activitățile de testare prezentate în cap. 1.1.3 al Anexei 3 din oferta tehnică și cele solicitate prin Caietul de sarcini, experți cheie sau non cheie. Arată că în concluziile scrise, la paragraful [111], se reia motivarea inițială prin care „Rolurile suplimentare pot fi asimilate experților non- cheié”, experții non cheie nefiind nominalizați în oferta tehnică. Modul în care au fost evaluate rolurile alocate activităților de testare din Anexa 3 este același expus la punctul II.6 F2.1 a) vi), de mai sus, adică criticile sunt inconsistente în justificări. II.18 „Subfactorul de evaluare nr. F2.1 b) - Corelarea planului de proiect cu cerințele din caietul de sarcini”, punctul v). – „Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție” [113]-[116] Răspuns SNN: Pentru analiza afirmațiilor cuprinse în paragraful [115] din concluziile scrise, entitatea cpntractantă precizează că le va numerota astfel: 1) Deși în justificarea deciziei de evaluare se menționează că „sesiunile de instruire sunt planificate a începe înainte de acceptarea planului de instruire și a materialelor suport”, dorim să subliniem că: 2) • Activitățile de instruire sunt planificate anterior trecerii în producție, conform cerințelor din caietul de sarcini (Cap. 6.2), ceea ce se poate verifica în Planul de proiect (Gantt), la liniile 163- 166. Astfel: o Instruirea pentru administratorii de sistem: 30.07.2025 - 05.08.2025 o Instruirea pentru administratorii de aplicație, pe locații: - CNE Cernavodă: 06.08.2025 - 12.08.2025 - SNN Sediul Central: 13.08.2025 - 19.08.2025 - FCN Pitești: 20.08.2025 -26.08.2025 o Punerea în producție - Faza I: 29.08.2025 3) • Se afirmă că activitățile de instruire încep înainte de acceptarea planului de instruire (linii 169-170 din Gantt, planificate la 29.08.2025). Cu toate acestea: 4) o Planificarea acestor activități nu presupune că acceptarea formală a planului de instruire trebuie să aibă loc exclusiv în data menționată în Gantt (29.08.2025), această dată reprezentând, în mod uzual, finalizarea sau confirmarea formală a unui livrabil, nu inițierea procesului de elaborare sau de utilizare. 5) o Activitățile de elaborare și transmitere a planului de instruire și a materialelor suport pot fi realizate anterior acestei date, în etapele de analiză și proiectare (așa cum însăși comisia de evaluare recunoaște). 6) • Din cele de mai sus rezultă că există o corelare logică între activitățile din Planul de proiect și cerințele caietului de sarcini, iar Pagina 129 din 171

presupusa „deviație” este una de natură formală, nu substanțială, nejustificând calificarea ca „Bună” în loc de „Foarte Bună”. Afirmația 1) include un citat (textul îngrosat) pentru care nu este precizată sursa, iar acesta nu se regăsește nici în procesul verbal de evaluare a ofertei tehnice și nici în punctul de vedere transmis anterior. Așa cum a menționat în punctul de vedere, în procesul verbal de evaluare este precizat că: „Planul de instruire și materialele de pregătire pentru faza I (liniile 169-170) ar trebui să fie acceptate înainte de începerea sesiunilor de instruire (liniile 163-166), iar elaborarea acestor documente ar putea fi inițiată în etapele de Analiză și Proiectare; similar pentru faza IF. Consideră că prin folosirea unor texte de tip citat (încadrate în ghilimele) contestatorul induce că textul a fost folosit de către comisia de evaluare, ceea ce este total fals. Afirmația 2) revine asupra criticii inițiale din contestație: „Instruirea trebuie să fie făcută înainte de punerea în producție, conform cerinței din CS. În GANTT la liniile 169-170 se precizează că instruirea se face după punerea în producție”, pentru care, prin punctul de vedere transmis anterior, a arătat deja că a fost formulată eronat, prin comparație cu justificarea din procesul verbal de evaluare a ofertei tehnice, prin urmare nu a fost considerată pentru depunctarea ofertei planificarea sesiunilor de instruire înainte de trecerea în producție, ci înainte de acceptarea materialelor pentru instruire. Afirmația 3) este justificarea acordarii punctajului, menționată în procesul verbal de evaluare a ofertei tehnice și a fost demonstrată prin capturi din Graficul Gantt în punctul de vedere transmis anterior. Afirmația 4) nu a fost menționată în oferta tehnică, iar Graficul Gantt nu include activități de elaborare a livrabilelor, prin urmare nu se poate proba care este momentul/etapa estimată pentru începerea acestor activități, însă termenul de finalizare și de acceptare a unui livrabil trebuie să fie dată specificată în Graficul Gantt. Afirmația 5) nu a fost menționată în oferta tehnică, iar Graficul Gantt nu include activități de elaborare a livrabilelor, prin urmare nu se poate proba care este momentul/etapa estimată pentru începerea acestor activități. Afirmația 6) conține o concluzie care nu se bazează pe argumente incluse în oferta tehnică și care să nu fi fost deja considerate în evaluare. Prin urmare justificarea din concluziile scrise pentru acest punct nu poate influența evaluarea subfactorul F2.1 b), pentru care, în plus, s-a ținut cont și de alte argumente (prezentate în procesul verbal de evaluare tehnică). II.19 „Subfactorul de evaluare nr. F2.1 c) – „Corelarea planului de proiect cu metodologia de management de proiect”, punctul i). – „Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general” [117] - [122]. Pagina 130 din 171

Răspuns SNN: Entitatea contractantă susține că atât critica inițială din contestație, cât și concluziile scrise conțin pentru acest punct argumente care nu se regăsesc în oferta tehnică, unele dintre acestea fiind ușor de verificat ca false. De exemplu, în punctul de vedere transmis anterior a expus următoarele: „Referitor la afirmația: „Asigurarea trasabilității între procesele de planificare și execuție: Planul Gantt include activități specifice de management de proiect (ex.: actualizare plan de proiect, managementul riscurilor, raportări de progres), asigurând implementarea continuă a metodologiei și nu doar a livrabilelor tehnice.” se poate proba cu ușurință că în graficul Gantt nu sunt incluse activități de managementul riscurilor și nici de actualizarea planului de proiect, care este elaborat/actualizat doar la inițierea implementări (și nici nu presupune validarea de către managerul de proiect al beneficiarului): prin urmare singurele raportări de progres sunt cele de status săptămânal, care sunt solicitate prin Caietul de sarcini. În concluziile scrise, contestatorul revine asupra acestei afirmații și menționează: „Activități de management: planul Gantt conține activități precum raportările de progres, ședințe de status, etc. Deși riscurile sau actualizarea planului nu sunt marcate distinct, acestea sunt implicite în procesul continuu de control al proiectului.”, însă se poate verifica ușor că ședințele de status nu sunt menționate în Graficul Gantt. Planul de proiect nu se rezumă doar la Graficul Gantt, iar activitățile de management specifice proiectului („raportările de progres, ședințe de status”) puteau fi detaliate în cadrul metodologiei din Anexa 3, însă nici în cap. 1.1 al acesteia („Metodologia de implementare și mentenanța adaptată specificului proiectului”) nu sunt prezentate activități de monitorizare a statusului proiectului sau de managementul riscurilor. II.20 „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul ii). - care în mod eronat a fost denumit de contestator „Planul de proiect și GANTT sunt în mică măsură corelate cu metodologia de management care este detaliată foarte general” dar care corect ar fi fost adresat prin: „Activitățile din GANTT nu sunt în ordine cronologică, adică activitatea de instruire este după activitate de punere în producție”. Fapt care în opinia sa denotă superficialitatea contestatorului și modul în care a înțeles să redacteze concluziile scrise. Referința: Paragrafele [123] - [130] din concluziile scrise. Răspuns SNN: Arată că în concluziile scrise, contestatorul reiterează criticile inițiale din contestație, fără a ține cont de punctul de vedere în care a specificat în clar că motivul depunctării nu este faptul că activitățile nu ar Pagina 131 din 171

avea alocate date de start și de finalizare în ordine cronologică.Îîn oferta tehnică, pentru Graficul Gantt s-a ales un mod de reprezentare care nu urmărește nici cele două faze de implementare ale proiectului și uneori nici succesiunea logică între etape (Trecerea în producție este afișată înainte de Instruiri, iar Rapoartele de status săptămânal sunt adăugate toate la finalul graficului), prin urmare, în această formă, graficul este un instrument dificil de utilizat pentru monitorizarea progresului proiectului. II.21 „Subfactorul de evaluare nr. F2.1 c) - Corelarea planului de proiect cu metodologia de management de proiect”, punctul iii). – „Nu este marcat corect drumul critic. Doar activitatea de management de proiect este singura critică”. [131] - [135]. Răspuns SNN: Aplicațiile software de management de proiect evidențiază automat drumul critic al proiectului, în funcție de duratele activităților, dependențele între acestea, rezervele de timp prevăzute și resursele alocate. În formatul prezentat, este marcată cu roșu (Legenda: Criticai) doar activitatea de la linia 391 - Activități de management de proiect, ceea ce denotă incorectitudine, omisiuni și neconcordanțe în conceperea Graficului Gantt. Forma prezentată, dată fiind structura aleasă, nu permite nici evidențierea separată a duratelor celor două faze de implementare. II.22 „Subfactorul de evaluare nr. F2.1 c) – „Corelarea planului de proiect cu metodologia de management de proiect”, punctul iv). – „Metodologia de management de proiect este prezentată în cap. 3.3.8 din Oferta tehnică (Anexa 2 la aceasta) dar riscurile specifice nu sunt tratate în planul de proiect.” [136]-[139]. Răspuns SNN: Arată că prin concluziile scrise se reiau argumentele din critica inițială a contestației și este repetată confuzia dintre noțiunile de Plan de proiect și Grafic Gantt, prin care contestatorul folosește termenul de Plan de proiect sau Plan de implementare cu sensul de reprezentare grafică. Așa cum reiese din detalierea definițiilor prezentate la punctul II.4 F2.1 a) iv) de mai sus, conform metodologiei OUM, Graficul Gantt este o reprezentare a Planul de implementare, care conține și o serie de elemente suplimentare, printre care și managementul riscurilor. Prin urmare, în evaluarea corelației planului de proiect cu metodologia de management de proiect, a ținut cont de faptul că nu au fost menționate activități de managementul riscului în planul de proiect din cap. 1.1 al Anexei 3. Oferta nu a fost depunctată pentru că riscurile nu au fost incluse în Graficul Gantt, așa cum argumentează contestatorul în critica acestui punct. II.23 „Subfactorul de evaluare nr. F2.1 d) – „Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul i). – „Estimarea duratelor activitatilor nu este realistă”. [140] -[143]. Răspuns SNN: Pagina 132 din 171

În concluziile scrise, contestatorul susține în paragraful [141] că: „Evaluarea realizată de comisie este generală și lipsită de justificări concrete”. Entitatea contractantă precizează că a evaluat duratele estimate pentru activitățile din Graficul Gantt pe baza istoricului de proiecte pe care le-a implementat recent, iar exemple concrete de neconcordanțe au fost menționate în procesul verbal de evaluare a ofertei tehnice: „- Din graficul Gantt rezultă că etapa de analiză pentru cele 6 noi module ale fazei II se va realiza secvențial, într-o perioadă de doar 2 luni - Din graficul Gantt rezultă că etapa de analiză pentru modulul de Pontaj se va realiza în doar 4 -Din graficul Gantt rezultă că activitatea de upgrade Oracle Linux pe cele 4 medii se va realiza în doar 4 zile de către unul dintre experții cu rol de Specialist în implementarea de tehnologii Oracle EBS HCM, fără implicarea rolului Arhitect de sistem Oracle EBS, - Durata pentru pregătirea trecerii în producție nu este corect dimensionată, graficul nu include activitatea de pregătire a utilizatorilor finali, în sarcina SNN, - Planul de implementare nu prezintă toate resursele implicate (alți specialiști în echipa de proiect), ci doar experții cheie solicitați prin Caietul de sarcini, - Nu sunt prezentate roluri și sarcini pentru echipa SNN (echipa de proiect a beneficiarului este asignată doar pe sarcinile de testare de acceptanță)”. II.24 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul ii). – „În planul de proiect avem analiza pentru Faza 2 în 2 luni, desfășurarea etapelor fiind prezentate secvențial.” [144] - [147]. Răspuns SNN: În concluziile scrise, contestatorul afirmă în paragraful [145] că: „Comisia nu a demonstrat existența unei corelații negative între planificarea secvențială și realizarea cu succes a activităților”. Entitatea contractantă precizează că nu a susținut în punctul de vedere transmis anterior că obiectivul proiectului nu poate fi atins prin planificarea secvențială a activităților, ci doar consideră că aceasta nu este strategia optimă. Din experiența acumulată în sesiunile de analiză de business internă în vederea elaborării Caietului de sarcini, din cadrul documentației de atribuire a acestui proiect, entitatea contractată poate aprecia că durată de 2 luni nu va fi suficientă pentru activități de analiză de business realizate secvențial. Spre deosebire de modelul tradițional Waterfall, abordarea Agile, pe care se bazează metodologia OUM, presupune că cerințele, costul și perioada nu pot fi toate fixe (Triple Constraint). Prin urmare, dacă ține cont de faptul că cerințele și costul proiectului sunt fixe, atunci singura variabilă ar trebui să fie perioada. Pentru a se încadra totuși în perioada deja stabilită a proiectului, singura soluție viabilă este planificarea Pagina 133 din 171

activităților în paralel, cu suplimentarea echipei de implementare (și desemnarea de experți non-cheie). II.25 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul iii). – „Etapa de analiza pentru pontaje este de 4 zile”. [148] - [152]. Răspuns SNN: În concluziile scrise, contestatorul afirmă la paragraful [149] că: „Estimarea este realistă și justificată Durata de 4 zile pentru analiza cerințelor funcționale aferente modulului Pontaj este rezultatul unei planificări riguroase, care ține cont de: 1) o experiența acumulată de analiști în proiecte similare, ceea ce reduce semnificativ timpul necesar pentru înțelegerea proceselor și colectarea cerințelor; 2) o împărțirea clară a sarcinilor între cei doi experți desemnați în ofertă, ceea ce permite desfășurarea activităților în paralel sau prin alternanță eficientă, în funcție de subtematici (evidența timpului lucrat, concedii, muncă la distanță etc.); 3) o disponibilitatea documentației și a stakeholderilor, ceea ce elimină întârzierile datorate clarificărilor sau validărilor ulterioare; 4) o utilizarea unor metodologii consacrate de analiză, cum ar fi modelarea proceselor cu BPMN și elaborarea cerințelor prin user stories Agile, metodologii ce permit structurarea rapidă și coerentă a rezultatelor”. Afirmația: 1) nu este susținută de documentația inclusă în oferta tehnică deoarece, așa cum a arătat și prin punctul de vedere transmis anterior, motivul pentru care în ofertă au fost desemnați 2 experți pe rolul

de

Analist

de

business

HR

este

faptul

că specialistul ............................ (Florina Țarălungă) nu îndeplinește toate cerințele din Caietul de sarcini, adică nu are experiență în activități de analiză de business HR în ultimii 5 ani, în consecință nici pe Pontaj. Ca urmare a solicitărilor de clarificări primite de la ofertanți înainte de depunerea ofertelor (inclusiv din partea ............................), entitatea contractantă a permis desemnarea a 2 experți pe rolul de Analist de business HR care să îndeplinească cumulativ cerințele și responsabilitățile (Solicitarea de clarificări ............................ nr. 1 din 02.12.2024, punctul 7). Afirmația 2), prin care se precizează că cei 2 experți vor lucra în paralel pe activitatea de analiză, nu se regăsește în oferta tehnică și nici nu considerăm că ar fi indicată o astfel de abordare, deoarece în echipa de analiză de business trebuie să fie incluși și responsabilii de Pontaj din partea entității contractante (din cele 3 entități ale SNN) și cel puțin unul dintre experții desemnați pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM, prin urmare nu se pot forma mai multe echipe cu aceiași specialiști. Pagina 134 din 171

Afirmația 3) este o ipoteză, pe care contestatorul nu a validat-o înainte de depunerea ofertelor, deși avea posibilitatea de a solicita detalii despre procedurile aplicabile modulului de Pontaj, așa cum este specificat în Caietul de sarcini, în cap. 5.2.4, la pag. 28: „Cerințele pentru modulul de Pontaj se vor detalia în etapa de analiză pentru a acoperi toate aspectele specificate în CCM și în procedurile interne SNN. Informații cu detalii ale proceselor referitoare la pontaj pot fi solicitate de către Operatorii Economici și vor fi puse la dispoziție la sediul Entității Contractante doar după semnarea unui acord de confidențialitate (Anexa nr. 2)”. Afirmația 4) conține elemente care nu se regăsesc în oferta tehnică inițiala: modelarea BPMN și elaborarea de user stories Agile, deci nu poate fi luată în considerare. II.26 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul iv). – „Realizare upgrade Oracle pentru Faza 1-4 zile” [153] -[157]. Răspuns SNN: Din experiența anterioară a sistemului de la CNE, pentru upgrade- ul de Oracle Linux și Oracle EBS din anul 2020 (pe mediile de test, producție și DR), a fost necesară o perioadă de cel puțin 2 săptămâni, însă estimarea efortului ar trebui să țină cont și de complexitatea customizărilor și integrărilor existente, care trebuie de asemenea actualizate. În concluziile scrise, contestatorul afirmă la paragraful [154] că: „Activitatea de upgrade presupune: o upgrade-ul sistemului de operare Oracle Linux pe patru medii (dev, test, preprod, prod)”, însă mediile care sunt menționate prin Caietul de sarcini, în cap. 5.2.1.1, la pag. 20, sunt: „Sistemul de operare Oracle Linux va fi actualizat de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR.”, de unde reiese faptul că argumentația conține unele confuzii legate de cerințele din Caietul de sarcini. Și tot la paragraful [154], contestatorul afirmă că: „Rolul Arhitectului de sistem nu a fost exclus, ci este implicit coordonator. Referitor la observația Entității Contractante privind lipsa implicării Arhitectului de sistem Oracle EBS în activitatea de upgrade, menționăm că: o în cadrul ofertei noastre, Arhitectul de sistem este implicat în fazele de design, validare și avizare a soluției tehnice, inclusiv în activitățile de upgrade; o rolul Arhitectului nu presupune neapărat executarea directă a sarcinilor tehnice, ci coordonarea și supervizarea acestora; o chiar dacă în graficul Gantt activitatea a fost detaliată la nivelul executantului (Specialistul în implementarea de tehnologii Oracle EBS Pagina 135 din 171

HCM), Arhitectul a fost prevăzut ca parte a echipei care validează și avizează rezultatele, conform cerințelor din Caietul de sarcini”, însă aceste detalii nu se regăsesc explicit în oferta tehnică. Referirea eronată la cap II.26 care corect ar fi fost: II.27 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul v). – „Durata trecerii în producție nu este corect dimensionată și nu include activități de pregătire a personalului SNN.” [158] - [161]. Răspuns SNN: Entitatea contractantă arată că concluziile scrise adaugă o serie de argumente care nu se regăsesc în oferta tehnică, cum ar fi metoda shadowing sau, la paragraful [159]: „activitățile pregătitoare și de instruire care sunt parte integrantă a activităților desfășurate în perioada efectivă de trecere în producție”. sau care sunt eronate, cum ar fi: „Instruirea utilizatorilor finali (prin metoda „train the trainer”) este în sarcina SNN, conform cap. 5.1.3 din Caietul de sarcini. Furnizorul instruiește doar administratorii și utilizatorii-cheie desemnați de SNN. Afirmația că „graficul nu include instruirea tuturor utilizatorilor” este irelevantă în contextul în care acest lucru nu intră în sarcina ofertantului”. Pregătirea utilizatorilor finali este în sarcina entității contractante, însă conceptul „train the trainer” se aplică instruirilor solicitate prin Caietul de sarcini, în sarcina Furnizorului, și anume training-ul utilizatorilor-cheie, viitori instructori de utilizatori. Cele 4 tipuri de instruiri solicitate prin Caietul de sarcini, cap. 5.1.3, la pag. 15-16, sunt destinate: administratorilor de sistem, administratorilor de aplicație, rolurilor speciale și utilizatorilor-cheie. De asemenea, Graficul Gantt trebuie să includă activitățile tuturor părților implicate, nu doar ale ofertantului. II.27 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul vi). – „Planul de proiect nu prezintă toate resursele implicate, ci doar experții cheie.” [162] - [173]. Răspuns SNN: În concluziile scrise, contestatorul afirmă la paragraful [166] că: „În oferta noastră, am indicat clar că, pe lângă experții-cheie, avem pregătită o echipă de experți non-cheie care vor fi alocați în funcție de necesitățile concrete apărute în derularea proiectului, ca măsură de prevenire și răspuns la riscuri identificate. Aceștia sunt menționați ca parte a strategiei de management al riscurilor (Cap. 24.2 din propunerea tehnică-pag. 261-262)”, însă în Formularul IV.4.1 .a, care este menționat, nu este inclusă o strategie de management al riscurilor și nici nu sunt nominalizate Pagina 136 din 171

resursele alocate, ca rol sau ca specialist, ci doar îndeplinește cerința 24.2 din Caietul de sarcini. În evaluarea realismului planului de implementare prin corelarea efortului estimat cu complexitatea activităților, entitatea precizează că a ținut cont de repartizarea responsabililor pe activități în Graficul Gantt (doar experți cheie, insuficienți relativ la complexitatea și durata sarcinilor) și de rolurile menționate pe activitățile detaliate în cap. 1.1 din Anexa 3, însă aici detaliile sunt inconsistente, atât cu privire la roluri, cât și la activități. Consideră că o analiză a impactului și probabilității riscurilor ar fi rezultat într-o estimare și planificare eficientă a resurselor încă din momentul ofertării și nu după ce vor apărea întârzieri în implementare. De obicei, între momentul ofertării și inițierea proiectului nu apar noi informații cu impact în evaluarea riscurilor care să rezulte în modificări semnificative ale Graficului Gantt. II.28 „Subfactorul de evaluare nr. F2.1 d) - Realismul planului prin corelarea efortului estimat cu complexitatea activităților”, punctul vii). — „Nu sunt prezentate rolurile și sarcinile personalului SNN.” [174] -[181]. Răspuns SNN: În concluziile scrise, contestatorul afirmă la paragraful [179] că: „De asemenea, planul de proiect (Gantt) a fost întocmit având în vedere că anumite sarcini ale echipei SNN nu erau încă finalizate în faza de ofertare, iar rolurile și sarcinile acestora vor fi detaliate și definite în documentele ulterioare, în funcție de progresul real al proiectului și de cerințele operaționale”. Așa cum a argumentat și la punctul II.13 F2.1 a) xiii) de mai sus, Graficul Gantt trebuie să conțină activitățile tuturor părților implicate, iar versiunea inclusă în oferta tehnică nu ar trebui să difere substanțial față de versiunea graficului care se va agrea la inițierea implementării sau de actualizările inerente din perioada de derulare a proiectului. II.29 „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situatii neprevăzute”, punctul i). – „în planul de proiect nu este optimizată utilizarea resurselor, acestea fiind implicate secvențial”. [182] - [188]. Răspuns SNN: Atât critica inițială din contestație, cât și concluziile scrise conțin argumente care nu se regăsesc în oferta tehnică, de exemplu la paragraful [185]: „In același timp, considerăm că optimizarea utilizării resurselor nu depinde exclusiv de alegerea între o planificare secvențială sau paralelă. Din această perspectivă, abordarea noastră este una bine fundamentată, iar alte tehnici de optimizare, cum ar fi: o Resource leveling: Ajustarea activităților pentru a evita epuizarea resurselor și suprapunerile. o Resource smoothing: Menținerea unei utilizări constante și eficiente a resurselor fără a modifica termenele de finalizare. Pagina 137 din 171

o Analiza valorii câștigate (EVA): Utilizarea acestei metode pentru urmărirea în timp real a performanței proiectului.” Contestatorul oferind o altă mostră de încercare de inducere în eroare a Consiliului prin faptul că introduce în conluziile scrise elemente care ar fi făcut parte din oferta tehnică și ar fi fost la dispoziția comisiei de evaluare. De asemenea motivele pe care le consideră relevante în favoarea planificării activităților în paralel au fost detaliate la punctul II.24, de mai sus. II.30 „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situatii neprevăzute”, punctul ii). – „Planificarea nu permite flexibilitate pentru activitati neprevăzute”. [189] - [196]. Răspuns SNN: În concluziile scrise contestatorul revine cu exact aceleași argumente din critica inițială, fară a specifica unde în oferta tehnică a menționat noțiuni ca „Marja de flexibilitate” sau „Sesiuni de reevaluare a progresului”, deși în punctul de vedere transmis anterior a precizat că încearcă modificarea ofertei, prin adăugarea de detalii noi cu privire la managementul riscurilor. De asemenea, prin planificarea sarcinilor cu rezerve de timp între activitățile critice se poate obține flexibilitate pentru activități neprevăzute. II.31 „Subfactorul de evaluare nr. F2.1 e) - Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situatii neprevăzute”, punctul iii). – „Activitatea de proiectare începe după activitatea de analiză. În procedura ORACLE aceste se realizezează în paralel - Linia 41 din Gant este condiționată de realizarea liniei 20 din GANTT” [197] - [203]. Răspuns SNN: În concluziile scrise, contestatorul afirmă la paragraful [201] că: „Comisia de evaluare subliniază faptul că planificarea noastră nu include activități de îmbunătățire a soluției existente și că proiectarea ar putea fi inițiată mai devreme, încă din faza I. Totuși, acest raționament nu ține cont de faptul că etapa de analiză completă este crucială pentru o proiectare de calitate, iar orice tentativă de a începe proiectarea înainte de validarea completă a analizei ar putea genera riscuri de incompatibilitate între cele două faze”. Fiecare dintre cele 2 faze de implementare a proiectului (faza I extindere și faza II adăugare noi module) conține câte o etapă de analiză urmată de proiectare, prin urmare paralelismul între etapele de analiză și proiectare din faza I nu are cum să producă efecte în faza II (care are propriile etape de analiză și proiectare, planificate secvențial). Motivul pentru care consideră utilă inițierea etapei de proiectare a fazei I la începutul fazei I este acela că proiectul își propune extinderea unei soluții existente, pentru care arhitectura ar trebui să fie optimizată, iar Pagina 138 din 171

solicitările de modificare ar trebui să fie incluse în livrabilele etapei de analiză a fazei I, acceptate, iar apoi pe baza acestora finalizată etapa de proiectare din faza I. II.32 „Subfactorul de evaluare nr. F2.1 f) - Optimizarea duratei proiectului (scurtarea termenului de livrare) cu incadrarea in bugetul alocat”, punctul i). – „Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități, chiar dacă tehnic se pot execută în paralel și metodologia Oracle prevede această practică” [204] - [208] Răspuns SNN: Entitatea contractantă arată că nici motivarea inițială din contestație, și nici justificările din concluziile scrise nu se regăsesc în oferta tehnică și, în plus, nu demonstrează cum se asigură optimizarea perioadei de implementare și flexibilitatea în cadrul proiectului, aplicând abordarea aleasă. Metodologia OUM, prezentată în oferta tehnică la cap. 1 din Anexa 3, pag. 3-14, utilizează abordarea Agile, care oferă o mai mare flexibilitate și adaptare la schimbări, permite livrarea de valoare timpurie și continuă, implică activ toate părțile participante în implementare, reduce riscurile, îmbunătățește calitatea și este mai adaptabilă la natura complexă și dinamică a proiectelor IT moderne. Principiile fundamentale ale OUM, cum ar fi iterația și incrementarea, orientarea către business și arhitectură, flexibilitatea și focusul pe risc, sunt aliniate cu valorile și principiile Agile, însă acestea nu sunt aplicate în cadrul ofertei propuse, în care abordarea este una secvențială, de tip tradițional Waterfall. II.33 „Subfactorul de evaluare nr. F2.1 f) - Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat”, punctul i) eronat referentiat în concluziile scrise, și corect adresat fiind ii) — „Cu mici excepții activitățile au un singur precedesor, activități anterioare, iar restul sunt de tip finish to start.” [209] - [216] Răspuns SNN: Nici motivarea inițială din contestație, și nici justificările din concluziile scrise nu se regăsesc în oferta tehnică și, în plus, nu demonstrează cum se asigură optimizarea perioadei de implementare și flexibilitatea în cadrul proiectului, aplicând abordarea aleasă. În concluzie, în oferta tehnică, la cap. 1.2 Planul de implementare din Anexa 3, inclusiv în Graficul Gantt, nu a fost dovedită optimizarea perioadei de implementare și a termenelor de livrare, acesta fiind motivul pentru punctajul obținut la subfactorul F2.1 f). Pentru toate motivele menționate atât în punctul de vedere cât și în prezentele concluzii, solicită a se constata că:  - derularea procedurii de atribuire a achiziției s-a realizat cu respectarea dispozițiilor legale; - evaluarea ofertelor reprezintă atributul exclusiv al entitatii contractante prin comisia de evaluare conform prevederilor imperative Pagina 139 din 171

ale art. 133, alin(l) din HG nr. 394/2016, cu modificările și completările ulterioare; - susținerile contestatorului sunt inadmisibile întrucât conțin motive de contestare care nu se regăsesc în contestația depusă de ............................ nr. 1602/28.04.2025, fiind formulate pentru prima dată, de către aceasta contestatoare, prin concluzii scrise; Având în vedere cele menționate mai sus, solicită Consiliului să respingă contestația depusă de ......... SRL ca nefondată și neîntemeiată. Prin adresa nr. 25-02291-06-05-2025, înregistrată la CNSC sub nr. 29289/07.05.2025 entitatea contractantă transmite dosarul achiziției pe stick. Prin adresa înregistrată la Consiliu sub nr. 28108/30.04.2025, ............................SRL depune, în original, recipisa de consemnare a cauțiunii nr. 211260521/1 din data de 30.04.2025, emisă de CEC Bank Sucursala Ilfov, în valoare de 226.140,81 lei. Analizând susținerile și documentele depuse la dosarul cauzei, CONSILIUL constată următoarele: ......... SA, în calitate de entitate contractantă, a organizat procedura de licitație deschisă, în vederea atribuirii contractului, având ca obiect: „Implementare sistem integrat de management al resurselor umane, prin extinderea soluției Oracle HR, aflată în exploatare la CNE Cernavodă, la SNN Sediul Central ......... și la FCN Pitești, și prin adăugarea de noi funcționalități”, cod CPV 72260000-5, elaborând, în acest sens, documentația de atribuire aferentă și publicând pe SEAP, anunțul de participare nr. CN1075659/25.11.2024, conform căruia valoarea estimată a procedurii este 11.307.040,56 lei. Conform cap. II.2.5 din anunț, criteriul de atribuire al contractului este „cel mai bun raport calitate preț”. Prin

contestația

care

face

obiectul

prezentei, ............................SRL este nemulțumit de punctajul pe care l-a acordat comisia de evaluare ofertei sale la Subfactorul „F2.1 - Calitatea planului si metodologiei de proiect” din factorul de evaluare tehnic, în urma aplicării criteriului de atribuire. Având în vedere criticile din contestația formulată de ............................SRL, Consiliul reține că, potrivit informațiilor de la secțiunea II.2.5 din anunțul de participare, entitatea contractantă a ales să aplice, în cadrul prezentei proceduri, criteriul de atribuire „Cel mai bun raport calitate – preț”, în cadrul căruia a alocat 60% din punctaj factorului de evaluare tehnic intitulat „componenta tehnică”, din care 30 de puncte pentru subfactorul „calitatea planului si metodologiei de proiect” și 30 de puncte pentru subfactorul „experiența profesională a experților propuși pentru implementarea soluției”. Conform informațiilor de la pag. 8 din raportul procedurii nr. 492/17.04.2025,

oferta

Asocierii

............................SRL – ............................SRL nu a fost desemnată câștigătoare, ci, s-a Pagina 140 din 171

situat pe locul 2, deoarece, punctajul obținut în urma aplicării criteriului de atribuire, respectiv 74 de puncte, este inferior celui obținut de oferta desemnată câștigătoare, căreia i-au fost acordate 81,12 puncte. Potrivit aceluiași document, Asocierea ............................SRL – ............................SRL a obținut punctaj maxim (40 de puncte) la factorul de evaluare financiar, deoarece, a ofertat cel mai scăzut preț din cele 2 oferte admisibile, iar, diferența de 34 de puncte, din cele maxim 60 de puncte posibile, a fost obținută la factorul de evaluare tehnic. Modalitatea de acordare a punctajului pe fiecare dintre cei 2 sub- factori de evaluare tehnici se regăsește în procesul verbal nr. DA_DA-25- 00502-18-03-2025, transmis de entitatea contractantă la dosarul cauzei în format electronic, în fișierul cu identificatorul „7. PV analiza tehnica finala - Implementare sistem integrat HR - CR 41565.pdf” din folderul „D Achizitie\4. Evaluare Tehnica\Evaluare Tehnica” și este format din 8 puncte (din maxim 30 posibile) la sub-factorul de evaluare „calitatea planului si metodologiei de proiect” și 26 de puncte (tot din maxim 30 posibile) la sub-factorul de evaluare „experiența profesională a experților propuși pentru implementarea soluției”. Ulterior

luării

la

cunoștință

a

rezultatului procedurii, ............................SRL a formulat contestația care face obiectul prezentei, criticile sale vizând exclusiv punctajul obținut la factorul de evaluare „calitatea planului si metodologiei de proiect” (pentru care a obținut 8 puncte din maxim 30 posibile) și conformitatea ofertei desemnată câștigătoare. Cu privire la oferta câștigătoare, Consiliul reține că, ulterior studierii dosarului cauzei, ............................SRL a formulat cerere de renunțare, motiv pentru care, în temeiul art. 26 alin. (8) din Legea nr. 101/2016, va lua act de faptul că societatea contestatoare a renunțat la criticile privind oferta desemnată câștigătoare, aparținând ............................SRL, urmând să analizeze, pe fond, doar criticile formulate de ............................SRL cu privire la punctajul obținut de propria sa ofertă la factorul de evaluare „calitatea planului si metodologiei de proiect” (numerotat 2.1 în anunțul de participare). În acest sens, se reține că algoritmul de acordare a punctajului, reglementat de art. 38 din HG nr. 394/2016, a fost detaliat de către autoritatea contractantă în fișierul publicat în SEAP sub identificatorul „[CN1075659/00008] ANEXA 1 Fisa de Date- Informatii Componenta Tehnica.pdf.p7s”, astfel: „Subfactorul F2.1 - Calitatea planului si metodologiei de proiect Cerința minimă conform Caietului de sarcini: entitatea contractantă urmărește în privința planului și a metodologiei de proiect 6 subfactori care vor fi utilizați ca puncte de reper în aprecierea factorului: a) Gradul de detaliere al planului de proiect si al metodologiei de implementare; b) Corelarea planului de proiect cu cerințele din Caietul de sarcini; Pagina 141 din 171

c) Corelarea planului de proiect cu metodologia de management de proiect; d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților; e) Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute; f) Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat. Nota: Cerințele menționate reprezintă cerințe minime pe care oferta trebui să le îndeplinească, în caz contrar, oferta va fi declarata neconformă (conform art. 143 alin. (3) litera a) din HG nr. 394/2016 si art. 228 din Legea nr. 99/2016. Detaliere

acordare punctaj: Linii directoare Calificativ Punctaj Subfactor (2.1.a): Gradul de detaliere al planului de proiect si al metodologiei de implementare Gradul de detaliere a planului de proiect și a metodologiei

este corespunzător

și facilitează

înțelegerea modului de abordare a proiectului,

de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. Foarte bine 5 Gradul de detaliere a planului de proiect și a metodologiei

este corespunzător

și facilitează

parțial înțelegerea modului de abordare a proiectului, de

monitorizare

a stadiului de derulare, de tratare a riscurilor, a sarcinilor

personalului implicat

și

a dependențelor interne și externe. Bine 3 Gradul de detaliere a planului de proiect și a metodologiei facilitează limitat

înțelegerea Acceptabil 1 Pagina 142 din 171

modului de abordare a proiectului,

de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe. Subfactor (2.1.b): corelarea planului de proiect cu cerintele din caietul de sarcini Exista

corelare intre

cerintele

si livrabilele solicitate prin caietul de sarcini si planul de proiect propus. Foarte bine 5 Exista corelare cu deviatii minore intre cerintele si livrabilele solicitate prin caietul de sarcini si planul de proiect propus. Bine 3 Corelarea intre cerintele si livrabilele solicitate prin caietul de sarcini si planul de proiect propus este cu deviatii majore. Acceptabil 1 Subfactor (2.1.c): corelarea planului de proiect cu metodologia de management de proiect Exista corelare intre planul de proiect si metodologia utilizata in cadrul proiectului. Foarte bine 5 Exista corelare cu deviatii minore intre planul de proiect si metodologia utilizata in cadrul proiectului. Bine 3 Corelarea intre planul de proiect si metodologia utilizata in cadrul proiectului este cu deviatii majore. Acceptabil 1 Subfactor (2.1.d): realismul planului prin corelarea efortului estimat cu complexitatea activitatilor Duratele activităților detaliate in planul de proiect sunt corespunzătoare complexitatii activităților si sunt in mod realist estimate. Foarte bine 5 Duratele activităților detaliate in planul de proiect sunt partial corelate cu complexitatea activităților si sunt partial realist estimate. Bine 3 Duratele activităților detaliate in planul de proiect sunt in mica masura corespunzatoare

complexitatii activităților si nu sunt realist estimate. Acceptabil 1 Pagina 143 din 171

Subfactor (2.1.e): optimizarea utilizarii resurselor in cadrul proiectului si flexibilitate pentru situatii neprevazute Planul de proiect demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților permite flexibilitate pentru situații neprevăzute. Foarte bine 5 Planul de proiect demonstrează că ofertantul a optimizat utilizarea resurselor. Planificarea activităților nu permite flexibilitate pentru situații neprevăzute. Bine 3 Planul

de

proiect

nu demonstrează că ofertantul a optimizat utilizarea

resurselor.

Planificarea activităților nu permite flexibilitate pentru situații neprevăzute. Acceptabil 1 Subfactor (2.1.f): optimizarea duratei proiectului (scurtarea termenului de livrare) cu incadrarea in bugetul alocat Planul de proiect demonstreaza ca ofertantul a fost preocupat de optimizarea

duratei

proiectului (scurtarea termenului de prestare) cu incadrarea in bugetul alocat. Foarte bine 5 Planul de proiect demonstreaza ca ofertantul a fost preocupat de optimizarea

duratei

proiectului (scurtarea termenului de prestare) cu incadrarea in bugetul alocat dar modul de abordare este partial realist. Bine 3 Planul de proiect demonstreaza ca ofertantul nu a fost preocupat de optimizarea

duratei

proiectului (scurtarea termenului de prestare) cu incadrarea in bugetul alocat, dar respecta termenul de prestare solicitat prin caietul de sarcini.˝ Acceptabil 1 Din analiza algoritmului de punctare anterior reprodus, Consiliul reține că sub-factorul de evaluare tehnic 2.1 este format din alți 6 sub- factori cărora li se asociază punctajul 1, 3 sau 5 în funcție de aprecierea comisiei de evaluare privind liniile directoare pentru fiecare din cele 6 repere precizate în algoritm, numerotate de la a) până la f). Conform informațiilor de la pag. 719 din procesul verbal nr. DA_DA-25-00502-18-03-2025,

cele

8

puncte

obținute

de Asocierea ............................SRL – ............................SRL la sub- factorul 2.1 „calitatea planului si metodologiei de proiect” sunt formate din 3 puncte la sub-factorul „2.1 b) Corelarea planului de proiect cu Pagina 144 din 171

cerințele din caietul de sarcini” și câte 1 punct la ceilalți 5 sub-factori, corespunzători literelor a, c, d, e și f. Motivele acordării acestor punctaje se regăsesc la pag. 719-722 din procesul verbal nr. DA_DA-25-00502-18-03-2025 și urmează a fi analizate în considerentele care urmează, cu respectarea principului disponibilității, statuat la art. 26 alin. (2) din Legea nr. 101/2016, respectiv în limitele investirii de către societatea contestatoare. Astfel, se reține că entitatea contractantă a acordat 1 punct, corespunzător calificativului „acceptabil”, la sub-factorul de evaluare „Gradul de detaliere al planului de proiect si al metodologiei de implementare”, menționând că a identificat următoarele puncte slabe: „Riscurile nu sunt tratate din punct de vedere al impactului și nici al probabilității de expunere la risc și nu este descrisă arhitectura necesară sistemului care urmează a fi implementat”. În coloana destinată justificărilor, comisia de evaluare a menționat următoarele aspecte: „detalierea modului de abordare a proiectului: - Metodologia de implementare OUM este descrisă în termeni generali, capitolele din metodologie nu sunt numerotate și legătura se poate intui doar prin denumirea anumitor etape - Planul de proiect este prezentat prin etape ale metodologiei combinate cu serviciile solicitate prin Caietul de sarcini și prin urmare este în mică măsură corelat cu graficul Gantt (multe roluri, activități și livrabile ale etapelor diferă) - Planul proiectului prezintă activități și sub-activități grupate în etape, care nu se regăsesc nici în metodologia OUM și nici în graficul Gantt, care includ roluri și livrabile irelevante pentru implementarea proiectului (de exemplu pentru testare sau integrare versiuni) - Metodologia de implementare OUM este de tip Agile și presupune iterații ale proceselor, iar planul de proiect și graficul Gantt nu sunt corelate din această perspectivă - Testarea de acceptanță nu include activități pentru rezolvarea problemelor identificate la testare și retestare și nici analiza rezultatelor testării monitorizarea stadiului de derulare: -În graficul Gantt, Managerul de proiect are asignate activități lunare de Monitorizarea, revizuirea și reglementarea evoluției proiectului, însă impactul acestor sarcini nu este detaliat în planul de tip Waterfall - În graficul Gantt, Managerul de proiect elaborează Rapoarte de status săptămânal, care sunt livrabile solicitate prin Caietul de sarcini tratarea riscurilor: -Riscurile nu sunt tratate din punct de vedere al impactului și nici al probabilității de expunere la risc. sarcinile personalului implicat: Pagina 145 din 171

- Graficul Gantt include roluri și specialiști responsabili pentru fiecare activitate, dar nu sunt asignați responsabili și pentru elaborarea livrabilelor - În graficul Gantt, sarcinile: Design soluție optimizată și upgrade- ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources) și Actualizarea sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR (liniile 42 și 73) sunt asignate doar rolului Specialist în implementarea de tehnologii Oracle EBS HCM 2, fără a fi implicat și rolul Arhitect de sistem Oracle EBS dependențe interne și externe: -În graficul Gantt sunt menționate dependențe între activități, însă etapele sunt prezentate consecutiv și nu în ordine cronologică (toate activitățile fazei I, urmate de toate activitățile fazei II) -Nu sunt prezentate dependențe externe: nu au fost prevăzute activități în sarcina SNN, care însă pot afecta durata proiectului (de exemplu: corecții de date, pregătire utilizatori finali, analiză de business) -Nu este descrisă arhitectura necesară sistemului care urmează a fi implementat”. Referitor la punctele slabe identificate de către comisia de evaluare, respectiv cele cu privire la riscuri, Consiliul reține că, în caietul de sarcini, în cap. 24 Ipoteze și riscuri, la pag. 49, este detaliată cerința referitoare la riscuri: „Ofertanții trebuie să aibă în vedere cel puțin ipotezele și riscurile descrise în continuare și să estimeze posibilele efecte ale acestora. În acest sens, la întocmirea Ofertei, fiecare operator economic trebuie să ia în considerare resursele necesare (de timp, financiare și de orice altă natură), pentru implementarea strategiilor de risc pe care le va propune. (…)”. ............................SRL susține, în cuprinsul contestației, că, în Metodologia de management de proiect aflată în Anexa 2 din cadrul propunerii sale tehnice, la cap. 3.3.8 Managementul Riscului (pag. 10- 11), ar fi prezentat metodologia de management a riscurilor care ar descrie modalitatea de tratare a riscurilor din punct de vedere impact si al probabilităților. Verificând, la rândul său, Anexa 2 intitulată Metodologia de management de proiect din cadrul propunerii tehnice a contestatorului (fișierul „Anexa 2_Metodologia de management de proiect.pdf”), Consiliul reține că la cap. 3.3.8 Managementul Riscului (pag. 10-11) se regăsesc doar definiții ale noțiunilor generale, fără a se face referire la riscurile menționate în Caietul de sarcini sau la alte riscuri identificate pentru proiect, nefiind analizate nici impactul și nici probabilitatea de expunere la riscurile implementării, ca elemente predominante ale Pagina 146 din 171

analizei calitative a riscurilor, conform mențiunilor din metodologie prezentate de contestator în Anexa 2, pag. 11: „Analiza calitativă a riscului este procesul de evaluare a impactului și probabilității de apariție a fiecărui risc identificat. Acest proces prioritizează riscurile în funcție de efectul lor potențial asupra obiectivelor de proiect”. În acest sens, Consiliul apreciază pertinente și pe deplin justificate susținerile entității contractante, din punctul de vedere, potrivit cărora, în evaluarea metodologiei, comisia de evaluare a dat dovadă de înțelegere și a luat în considerare riscurile precizate în cadrul Anexei 1 deși acestea nu sunt menționate niciunde în cadrul Anexei 2 - Metodologia de management de proiect. Totodată, Consiliul reține că era sarcina exclusivă a ofertantului prezentarea informațiilor în mod organizat și sistematic, pentru a putea demonstra conformitate ofertei acestuia și modul în care tratează cerințele din caietul de sarcini. În ceea ce privește susținerile contestatorului, potrivit cărora ar fi prezentat în Anexa IV.1 – Anexă la propunerea tehnică – la secțiunea 24 – Ipoteze și riscuri (pag. 260 – 266), în detaliu, conform cerințelor din caietul de sarcini, din punct de vedere impact și al probabilităților de expunere la risc, riscurile cu cel mai mare grad de probabilitate a apariției, pe perioada derulării contractului, Consiliul reține că în Anexa 1 din cadrul Ofertei tehnice – Formularul IV.4.1.a, pentru cerința 24.2 Riscuri, la pag. 261-264 este menționat, referitor la riscurile prezentate în Caietul de sarcini, faptul că „Ofertantul a luat la cunoștință și asumă […]” și este prezentată recomandarea de suplimentare a echipei cu experți pentru eliminarea acestor riscuri, dar cele 6 riscuri identificate de entitatea contractantă nu au fost analizate din perspectiva impactului și probabilității de apariție a riscurilor respective. În cadrul răspunsului la aceeași cerință sunt identificate 6 noi riscuri de către contestator, dar pentru care, de asemenea, nu este tratat nici impactul și nici probabilitatea de expunere la risc, conform metodologiei prezentate. În concluzie, Consiliul apreciază justificate susținerile entității contractante potrivit cărora oferta nu putea fi punctată suplimentar deoarece, astfel cum a fost reținut anterior, oferta nu a inclus o estimare a posibilelor efecte și o clasificare a riscurilor prezentate, bazată pe probabilitatea și severitatea apariției, iar contestatorul nu a prezentat în Metodologia de management de proiect nicio informație din care să reiasă o descriere exhaustivă a analizei riscurilor. În consecință, Consiliul apreciază că, la notarea subfactorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la tratarea riscurilor, comisia de evaluare a ofertelor a constatat în mod corect că gradul de detaliere al planului de proiect și a metodologiei facilitează, limitat, înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului Pagina 147 din 171

implicat și a dependențelor interne și externe și a calificat ca „acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Riscurile nu sunt tratate din punct de vedere al impactului și nici al probabilității de expunere la risc”. Cu privire la cea de a 2-a parte a constatărilor referitoare la punctele slabe identificate, respectiv, faptul că „nu este descrisă arhitectura

necesară

sistemului

care

urmează

a

fi implementat”, ............................SRL susține, prin contestație, că entitatea contractantă trebuia să analizeze „gradul de detaliere a planului de proiect și a metodologiei de implementare” și nu să analizeze o eventuală descriere a arhitecturii sistemului, că nici planul de proiect și nici metodologia de implementare nu trebuie să includă descrierea arhitecturii sistemului și că singura referire la „arhitectura sistemului” s- ar regăsi la punctul 5.1.2.13, „Cerință administrare”, pag 13 din caietul de sarcini. Consiliul reține că cerința 5.1.2.13 indicată de contestator, care se referă la documentația despre arhitectura sistemului și care trebuie să cuprindă „tehnologiile folosite, diagrama componentelor logice ale aplicației, diagrama componentelor fizice ale soluției, modul în care componentele sunt conectate și comunică, protocoalele și porturile de comunicație utilizate și interfețele de comunicare cu alte aplicații” reprezintă

o

cerință

de

conformitate,

pe

care Asocierea ............................SRL – ............................SRL și-a asumat-o, la pag. 52-53 din anexa 1 la propunerea sa tehnică, motiv pentru care, oferta acestuia a fost desemnată conformă. Pe de altă parte, pentru a fi punctată suplimentar la sub-factorul de evaluare „Gradul de detaliere al planului de proiect si al metodologiei de implementare”, propunerea tehnică a Asocierii ............................SRL – ............................SRL ar fi trebuit să conțină informații suplimentare celor solicitate cu titlu minimal drept cerință de conformitate, ceea ce nu s-a întâmplat în cazul ofertei contestatorului. Prin urmare, cerința din caietul de sarcini a fost considerată îndeplinită, dar, nu au fost întrunite condițiile pentru acordarea punctajului suplimentar. Raționamentul anterior se regăsește și în Instrucțiunea ANAP nr. 1/2017, care prevede, la art. 12, că factorii de evaluare sunt asociați unei/unor extinderi a cerinței/cerințelor minime obligatorii stabilite prin caietul de sarcini, avantajul urmărit fiind în corelație cu valori superioare ale nivelurilor unor anumite aspecte, ce fac obiectul factorilor de evaluare, față de nivelul minim ce trebuie îndeplinit pentru ca propunerea tehnică să fie declarată conformă Consiliul reține că, în Anexa 3 - Metodologia de implementare Oracle (OUM), indicată de ............................SRL în contestație, nu a fost descrisă arhitectura sistemului actual și nici cerințele minimale pentru extinderea soluției și pentru integrările necesare atât dintre Pagina 148 din 171

componente cât și cu alte aplicații. Astfel cum susține, în mod corect, entitatea contractantă în concluziile scrise, descrierea arhitecturii în cadrul OUM nu este doar o formalitate, ci, o componentă esențială pentru succesul proiectului. Astfel, identificând corect arhitectura sistemului se demonstrează o înțelegere clară a cerințelor, se reduc riscurile, se optimizează timpul de implementare și este facilitată dezvoltarea și mentenanța pe termen lung, contribuind la livrarea unei soluții robuste, scalabile și aliniate cu obiectivele proiectului. În deplin acord cu entitatea contractantă, Consiliul reține că Anexa 3 din cadrul propunerii tehnice – Metodologia de implementare Oracle (OUM) din oferta contestatorului nu ține cont de situația existentă în cadrul entității contractante și, implicit, de obiectul achiziției, care este extindere aplicație Oracle HR, și prezintă detalii generale ale metodologiei OUM, ca și cum ce ar trebui să implementeze ar fi o soluție nouă, iar, în planul de implementare, în cap. 1.1.2 Etapa de proiectarea soluției tehnice, nu se ia în considerare, ca dată de intrare, arhitectura sistemului existent (detaliată în Caietul de sarcini la începutul capitolului 5), ci, este inclusă o activitate de Prototipare arhitecturală, pag. 30-31, specifică implementării de proiecte noi și nu de extindere a unora deja existente. Ținând cont de faptul că Faza I a implementării obiectului achiziției este o extindere a soluției Oracle HR, deja implementate în cadrul entității contractante, este evident că arhitectura, care trebuie prezentată în metodologie, trebuia să țină cont de datele din Caietul de sarcini, cap. 5, pag. 4: „Începând cu anul 2009, la nivelul sucursalei CNE Cernavodă se află în producție aplicația Oracle HR Core, din cadrul pachetului Oracle Enterprise Business Suite (EBS versiunea 12.2.10), cu ajutorul căreia se gestionează: - procesele de lucru standard de management al activităților de resurse umane și dezvoltare organizațională, prin produsul Oracle Human Resources; - evidența pregătirii angajaților și personalului contractor, prin produsul Oracle Learning Management, și în plus, pentru a facilita înregistrarea necesarului de pregătire la nivel de poziție și gestionarea pregătirilor individuale ale angajaților și personalului contractor, este configurată și afișarea certificărilor utilizatorilor prin intermediul aplicației JRTR (Job Related Training Requirements). Platforma actuală, care este implementată pe sistemul de operare Oracle Linux (versiunea 7.9) și pe Oracle Database (versiunea 19), va fi folosită și pentru sistemul integrat la nivel SNN. […]” și nu să prezinte o metodologie de implementare a unui proiect nou. Consiliul mai are în vedere că informațiile prezentate de contestator cu privire la „activitatea de prototipare de arhitectură” de la cap 1.1.2 Pagina 149 din 171

Etapa de proiectarea soluției tehnice a Anexei 3 – Metodologia de implementare Oracle (OUM) nu se regăsesc în graficul Gantt, ceea ce denotă superficialitatea contestatorului în activitatea de întocmire a Anexei 3. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențe interne și externe, comisia de evaluare a ofertelor a apreciat, în mod corect că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu este descrisă arhitectura necesară sistemului care urmează a fi implementat”. Critica contestatorului cu privire la justificarea entității contractante, potrivit căreia „Metodologia OUM este descrisă in termeni generali” urmează a fi respinsă, deoarece, în oferta prezentată de contestator, în Anexa 3 din cadrul propunerii tehnice – Metodologia de implementare Oracle (OUM), la cap. 1. Metodologia de implementare OUM – (Oracle Unified Methodology), pag. 3-14, ofertantul prezintă succint și nestructurat metodologia OUM fără a permite o legătură logică și structurată cu celelalte capitole ale documentului. În acest sens, se reține că fiecare capitol din Metodologia prezentată este de sine stătător, fără să aibă o legătură intrinsecă cu informațiile din capitolul 1, care ar fi trebuit să dea indicii clare asupra modului cum vor fi prezentate informațiile. Cu titlu de exemplu, se reține că, la cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, pag. 15- 69, se prezintă modalitatea de implementare a proiectului, după cum se poate observa din denumirea subcapitolelor 1.1.1 – 1.1.8 din cuprinsul prezentat mai jos la punctul 1. iv), însă, acestea sunt grupate conform cerințelor din Caietul de sarcini (aspect recunoscut de contestator în concluziile scrise formulate drept replică la punctul de vedere) și nu au nicio legătura cu ce a fost precizat în cadrul capitolului. 1 al metodologiei OUM. În această situație, Consiliul apreciază drept pertinentă observația entității contractante, privind modalitatea indulgentă de verificare a conformității contestatorului, prin faptul că membrii comisiei de evaluare au apreciat conformă oferta contestatorului, deși, metodologia OUM detaliată în cap. 1 al Anexei 3 este descrisă în termeni generali, aceasta netratând, de fapt, structura modului de implementare a proiectului. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a Pagina 150 din 171

proiectului, comisia de evaluare a ofertelor a constatat, în mod corect, că gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Metodologia de implementare OUM este descrisă în termeni generali, capitolele din metodologie nu sunt numerotate și legătura se poate intui doar prin denumirea anumitor etape”. În ceea ce privește partea a doua a justificării, respectiv „Capitolele nu sunt numerotate și legătura dintre acestea se poate intui doar prin denumirea etapei”, Consiliul reține că, la pag. 3-14, nu sunt incluse subcapitole și nu sunt numerotate etapele, aspect facil de verificat din cuprinsul prezentat. În cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului, pag. 15-69, care este înscris distinct de cel numerotat „cap. 1”, este prezentată modalitatea de implementare, de asemenea nestructurat, după cum se poate observa din denumirea subcapitolelor 1.1.1 – 1.1.8 din cuprinsul prezentat, însă aceasta nu urmărește etapele și iterațiile metodologiei OUM, ci Caietul de sarcini și, în plus, include o serie de etape și activități care nu se regăsesc în graficul Gantt. În cap. 1.2 Planul de implementare sunt incluse doar graficul Gantt și graficul de facturare, fără detalierea particularizată a etapelor, activităților, metodelor și mijloacelor de realizare a acestora. Anexa 2 din cadrul Ofertei tehnice – Metodologia de management de proiect nu are legătură cu metodologia de implementare OUM și cu factorul de evaluare F2.1 a), prin urmare cuprinsul prezentat este irelevant. În concluzie, este corectă constatarea entității contractante conform căreia capitolele metodologiei OUM prezentate în cap. 1 al Anexei 3 nu sunt numerotate, iar etapele incluse în cap. 1.1 al Anexei 3 sunt corelate în mică măsură cu graficul Gantt. Critica v) de la punctul 1.1 urmează a fi respinsă, ca nefondată, deoarece, în graficul Gantt, activitățile de la liniile 87 și 120 sunt singurele care au alocate resurse din echipa de proiect a beneficiarului, acestea rezultând direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Echipa de proiect a beneficiarului nu este implicată în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3. Prin urmare, metodologia și planul de proiect nu sunt corelate din acest punct de vedere. Pagina 151 din 171

În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul de proiect este prezentat prin etape ale metodologiei combinate cu serviciile solicitate prin Caietul de sarcini și prin urmare este în mică măsură corelat cu graficul Gantt (multe roluri, activități și livrabile ale etapelor diferă)”. Critica vi) de la punctul 1.1 urmează să fie respinsă, ca nefondată, deoarece activitățile și sub-activitățile prezentate în cap. 1.1 Metodologia de implementare și mentenanță adaptată la specificul proiectului al Anexei 3 sunt prezentate nestructurat și nu se regăsesc în graficul Gantt, însă pot afecta durata și alocarea resurselor proiectului, cum ar fi de exemplu activitățile de testare de la pag. 43-48 din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Planul proiectului prezintă activități și sub-activități grupate în etape, care nu se regăsesc nici în metodologia OUM și nici în graficul Gantt, care includ roluri și livrabile irelevante pentru implementarea proiectului (de exemplu pentru testare sau integrare versiuni)”. Cu privire la critica vii) de la punctul 1.1, se reține că, în cap. 1.1.3 Metodologia de implementare și mentenanță adaptată la specificul proiectului din Anexa 3 sunt incluse o serie de livrabile care nu se regăsesc în graficul Gantt și care nu sunt solicitate nici în Caietul de sarcini. Un document, indicat de autoritatea contractantă și care a fost considerat, în mod corect, irelevant în contextul implementării proiectului este Planul de integrare a versiunilor, care apare ca intrare în mai multe sub-activități, însă nu se specifică nicio activitate prin care este elaborat și de către cine. Referitor la testare, activitățile prezentate au ca intrări documente, cum ar fi Planul general de testare sau Planul de proiectare, care nu sunt Pagina 152 din 171

menționate ca ieșiri pentru alte activități, prin urmare, nu rezultă când și de către cine sunt elaborate, după cum reiese din pag. 44, indicată, cu titlu de exemplu, în punctul de vedere. Cu privire la critica viii) de la punctul 1.1, se reține că, în graficul Gantt, activitățile de la liniile 85 și 118 reprezintă activități interne care sunt anterioare testării de acceptanță și au ca responsabili rolurile care au participat la configurare. În cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3, pag. 43 - 48, activitățile de testare au în comun cu graficul Gantt și cu Caietul de sarcini doar livrabilele etapelor de testare, însă descrierea activităților și rolurile sunt total diferite, de exemplu la pag. 45. În concluzie, nici în planul de implementare conform metodologiei din cap. 1.1.3 al Anexei 3 și nici în graficul Gantt nu sunt incluse activități de analiză și retestare în urma activităților de testare de acceptanță. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea modului de abordare a proiectului, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: “Testarea de acceptanță nu include activități pentru rezolvarea problemelor identificate la testare și retestare și nici analiza rezultatelor testării”. Cu privire la lipsa responsabililor pentru elaborarea livrabilelor, se reține că în caietul de sarcini, nu există o corespondență între activități și livrabile. Numărul activităților este mult mai mare decât numărul livrabilelor. Prin contestație, ............................SRL susține că responsabilii de livrabile sunt aceeași cu responsabilii de activități însă contestatorul nu a menționat în metodologiile prezentate (Anexa 2 și Anexa 3) că responsabilii de livrabile ar fi aceeași cu cei care execută toate activitățile corespunzătoare. Consiliul va mai reține că, referitor la alocarea pe fiecare activitate și livrabil, comisia de evaluare a solicitat clarificări prin adresa nr. SNN_FRZI- 25-00114/23.01.2025 (fișierul „Adresa solicitari clarificari propunere tehnica- Asociere ............................+..............pdf” din folderul „D Achizitie\4. Evaluare Tehnica\Evaluare Tehnica\3. Proces verbal evaluare tehnica clarificari\Solicitari si raspunsuri de clarificare Set 1”), care la punctul 5 prevede: Pagina 153 din 171

„Având în vedere cerințele Caietului de sarcini din cap. 5.1.2.1 Cerințe management contract, vă solicităm să completați Planul de implementare de tip Gantt cu responsabilii pentru fiecare activitate și livrabil, menționând rolul și persoana pentru cazul în care sunt mai mulți experți propuși pe același rol, atât pentru experții-cheie, cât și pentru cei noncheie, dacă au fost nominalizați.” Nici în răspunsul transmis, contestatorul nu a menționat, în graficul Gantt toate rolurile și experții responsabili pentru livrabilele realizate, în condițiile în care, nu a inclus nici activități de elaborare a livrabilelor. Astfel cum susține, în mod corect, în punctul de vedere entitatea contractantă, întrebarea a avut ca scop clarificarea referitoare la rolurile și experții care vor fi implicați în elaborarea livrabilelor și care își vor asuma documentația prin semnătură, în special pentru rolurile unde au fost alocați de către ofertant câte 2 experți. Pe de altă parte, referitor la activitatea de la linia 42 „Design soluție optimizată și upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources)”, Consiliul reține drept adecvată observația entității contractante că a fost repartizată eronat rolului Specialist în implementarea de tehnologii Oracle EBS HCM 2 – Iulia Calistrate, dată fiind cerința din Caietul de sarcini, de la cap. 5.1.2.2 Cerințe personal tehnic de specialitate, la pag. 8, prin care se solicită ca rolul Arhitect de sistem Oracle EBS să fie responsabil de optimizarea și upgrade-ului sistemului de operare și a Oracle HR, inclusiv de avizarea documentație: „Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”. Referitor la livrabilul de la linia 45 „Lvr. Documentația despre arhitectura sistemului – Faza I”, Consiliul apreciază veridice susținerile entității contractante că acesta nu este livrabil pentru faza I, ci este livrabil pentru Faza II, conform Caietului de sarcini, cerința 18.3.3, pag. 47: „Procesul verbal va avea anexate: - manualul de utilizare a aplicației (destinat utilizatorilor generali și administratorilor aplicației); - manualul de administrare a soluției (destinat administratorilor de sistem și care include și procedura de instalare, strategia de backup, procedură de recuperare în caz de dezastru, documentația bazelor de date, documentația despre arhitectura sistemului); - raportul de trecere în producție faza II; Pagina 154 din 171

- rapoartele de status săptămânal”. În consecință, Consiliul reține că, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea sarcinilor personalului implicat, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Graficul Gantt include roluri și specialiști responsabili pentru fiecare activitate, dar nu sunt asignați responsabili și pentru elaborarea livrabilelor”. Consiliul va respinge, ca nefondată, și critica x) de la punctul 1.1 deoarece la liniile 42 si 73 din graficul Gantt nu este menționat decât expertul Specialist ORACLE EBS HCM, fără a fi implicat și expertul Architect de sistem ORACLE EBS, astfel cum s-a solicitat prin cerința din Caietul de sarcini, de la cap. 5.1.2.2 Cerințe personal tehnic de specialitate, la pag. 8: „(3) Arhitect de sistem Oracle EBS (1 expert) Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade- ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”. Astfel, prin cerința anterior reprodusă se menționează că rolul Arhitect de sistem Oracle EBS este responsabil de optimizarea și upgrade-ul sistemului de operare și a Oracle HR. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la detalierea sarcinilor personalului implicat, comisia de evaluare a ofertelor a apreciat, în mod justificat că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În graficul Gantt, sarcinile: Design soluție optimizată și upgrade-ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources) și Actualizarea sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR (liniile 42 și Pagina 155 din 171

73) sunt asignate doar rolului Specialist în implementarea de tehnologii Oracle EBS HCM 2, fără a fi implicat și rolul Arhitect de sistem Oracle EBS”. Critica xi) de la punctul 1.1, privind justificarea „Etapele din GANTT sunt prezentate consecutiv și nu în ordinea cronologică, adică să fie prezentate activitățile pentru Faza 1, după care activitățile pentru Faza 2”, urmează a fi respinse, ca nefondate, având în vedere că, astfel cum susține, în mod corect, entitatea contractantă, Graficul Gantt se presupune a fi un instrument structurat care să faciliteze înțelegerea și urmărirea derulării implementării, în special de către managerii de proiect, oferind o vizualizare clară a cronologiei proiectului, și nu doar o transpunere a cerințelor și livrabilelor din Caietul de sarcini. Reprezentarea cronologică a activităților este o caracteristică fundamentală a graficului Gantt, permițând o planificare, urmărire a progresului și comunicare eficientă a activităților proiectului în timp. Având în vedere că cele două faze ale proiectului se vor desfășura consecutiv, graficul Gantt (reprezentarea grafică a planului de implementare, parte din acesta) ar fi trebuit să permită identificarea clară și ușoară a activităților din cele 2 faze ale implementării, inclusiv a celor critice, în vederea analizei din punct de vedere al completitudinii (toate activitățile necesare execuției fazei sunt prevăzute, cu dependențe și constrângeri între ele), duratelor și resurselor alocate. Analiza planului de implementare și a graficului Gantt asociat incluse în ofertă este consumatoare de timp și necesită mijloace suplimentare, forma prezentată fiind foarte dificil de verificat. În plus, forma prezentată nu va putea fi utilizată în urmărirea derulării proiectului, deoarece nu permite identificarea automată, utilizând instrumente de planificare consacrate (Microsoft Project, Primavera), a stadiului de realizare a fazei II. În consecință, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențele interne și externe, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „În graficul Gantt sunt menționate dependențe între activități, însă etapele sunt prezentate consecutiv și nu în ordine cronologică (toate activitățile fazei I, urmate de toate activitățile fazei II)”. Urmare a solicitării formulată de contestator, Consiliul, în temeiul art. 26 alin. (8) din Legea nr. 101/2016, va lua act de renunțarea la critica xii) de la punctul 1.1. Cu privire la lipsa prezentării activităților care revin beneficiarului (critica xiii de la punctul 1.1), Consiliul va reține că, în graficul Gantt Pagina 156 din 171

sunt incluși responsabili și echipa de proiect a beneficiarului doar la activitățile de la liniile 87 și 120, iar acestea rezultă direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. Echipa de proiect a beneficiarului nu este inclusă în nicio activitate de testare din cap. 1.1.3 Etapa de configurare, testare și acceptanță pe mediul de test din Anexa 3 (parte a propunerii tehnice din oferta contestatorului), motiv pentru care, în cadrul factorului de evaluare F2.1 a) Gradul de detaliere al planului de proiect și al metodologiei de implementare, cu privire la dependențele interne și externe, comisia de evaluare a ofertelor a apreciat, în mod corect, că „gradul de detaliere al planului de proiect și a metodologiei facilitează limitat înțelegerea modului de abordare a proiectului, de monitorizare a stadiului de derulare, de tratare a riscurilor, a sarcinilor personalului implicat și a dependențelor interne și externe” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Nu sunt prezentate dependențe externe: nu au fost prevăzute activități în sarcina SNN, care însă pot afecta durata proiectului (de exemplu: corecții de date, pregătire utilizatori finali, analiză de business)”. În stabilirea acestei finalități, Consiliul apreciază drept pertinente și susținerile entității contractante, din concluziile scrise, care menționează că, potrivit metodologiei OUM prezentate și bunelor practici în domeniul managementului de proiect, graficul Gantt trebuie să includă activități atât pentru furnizor, cât și pentru beneficiar, fiind o reprezentare fidelă a întregului efort al proiectului, prin integrarea contribuțiilor și dependențelor ambelor părți. Proiectele de implementare Oracle sunt, prin natura lor, eforturi colaborative, iar, multe activități ale furnizorului (cum ar fi dezvoltarea sau configurarea) depind de intrări și decizii din partea Beneficiarului (cum ar fi aprobarea cerințelor, furnizarea datelor, participarea la sesiuni de testare, pregătirea utilizatorilor finali). Ignorarea activităților beneficiarului în graficul Gantt creează un tablou incomplet și nerealist al dependențelor proiectului. Includerea activităților ambelor părți asigură transparență totală cu privire la stabilirea responsabilităților clare și reduce riscul de apariție a întârzierilor. Vizibilitatea acestor activități în graficul Gantt permite identificarea timpurie a riscurilor și elaborarea unor planuri de atenuare. Dacă graficul Gantt conține doar activitățile furnizorului, durata totală a proiectului este subestimată. Timpul necesar pentru revizuiri, aprobări, pregătirea datelor, instruire utilizatori finali și testare din partea beneficiarului poate fi semnificativ și trebuie planificat explicit. Beneficiarul este esențial în fiecare etapă a proiectului, prin următoarele activități: definirea cerințelor, validarea viziunii, aprobarea arhitecturii, design, revizuiri de prototipuri pentru noile module, pregătirea datelor, Pagina 157 din 171

testarea de acceptanță, migrarea datelor, trecerea în producție, operarea și administrarea sistemului, dar și suportul post-implementare. Consiliul va reitera faptul că algoritmii de acordare a punctajului pentru factorii de evaluare tehnici nu au ca scop depunctarea sau, altfel spus, reducerea punctajului pentru anumite lipsuri ale ofertelor, astfel cum răzbate din contestația formulată de ............................SRL, în care este menționat, în mod repetat, această sintagmă, ci, are ca rol punctarea unor oferte conforme, în măsura în care acestea sunt superioare cerințelor minime din caietul de sarcini, cu alte cuvinte, în măsura în care aduc entității contractante anumite avantaje în plus față de cerințele minime de conformitate. Or, astfel cum s-a reținut anterior, conformitatea ofertei Asocierii ............................SRL – ............................SRL a fost, pe alocuri, verificată cu o evidentă generozitate, situație în care susținerile respectivului ofertant că ar fi fost dezavantajat nu reflectă, în mod obiectiv, realitatea. Continuând

analiza

contestației

formulată

de ............................SRL, Consiliul reține că entitatea contractantă a acordat 3 puncte, corespunzător calificativului „bine”, la sub-factorul de evaluare „Corelarea planului de proiect cu cerințele din caietul de sarcini”, menționând că a identificat următoarele puncte slabe: „Documentația bazei de date și Documentația despre arhitectura sistemului nu sunt livrabile pentru faza I și nu sunt documente diferite pentru faza I și faza II (sistemul presupune o singură bază de date și o singură arhitectură)”. În coloana destinată justificărilor, comisia de evaluare a menționat următoarele aspecte: „corelare între cerințele din caietul de sarcini și planul de proiect propus: - Asistență tehnică și mentenanță la cerere – cap. 1.1.7 (Anexa 3, pag. 63-65); - Garanție post-implementare, cu incidente în JIRA – cap. 1.1.8 (Anexa 3, pag. 65-69); -Planul de proiect (Anexa 3) face referire la elaborarea documentului Plan de integrare a versiunilor, care nu are corespondent în Caietul de sarcini sau în graficul Gantt; - Planul de implementare conține roluri suplimentare pentru activitățile de testare, care nu se regăsesc în Caietul de sarcini și nici în graficul Gantt; corelare între livrabilele din caietul de sarcini și planul de proiect propus: - Livrabilele sunt prezentate în graficul Gantt; - Planul de instruire și materialele de pregătire pentru faza I (liniile 169-170) ar trebui să fie acceptate înainte de începerea sesiunilor de Pagina 158 din 171

instruire (liniile 163-166), iar elaborarea acestor documente ar putea fi inițiată în etapele de Analiză și Proiectare; similar pentru faza II; - Livrabilelor Manual de utilizare a aplicației și Manual de administrare a soluției ar trebui să le corespundă activități de elaborare, iar acestea să fie anterioare sesiunilor de instruire; - Documentația bazei de date și Documentația despre arhitectura sistemului nu sunt livrabile pentru faza I și nu sunt documente diferite pentru faza I și faza II (sistemul presupune o singură bază de date și o singură arhitectură)”. Consiliul urmează să respingă, ca nefondată, critica i) de la punctul 1.2, deoarece, includerea în graficul Gantt a Documentației bazei de date și a Documentației despre arhitectura sistemului ca livrabile pentru faza I demonstrează faptul că ofertantul nu are viziunea corectă asupra sistemului aflat în producție la CNE și nici a soluției care urmează a fi implementată, motivat de faptul că baza de date este deja creată și nu este necesară livrarea unei documentații a bazei de date doar pentru faza I, ci doar la finalul fazei II, după ce vor fi realizate și noile module ale soluției. De asemenea, graficul Gantt nu include și activități de elaborare a acestor documentații, cu responsabili asignați, iar livrabilele nu au desemnați responsabili. Totodată, este indubitabil faptul că sistemul presupune o singură bază de date și o singură arhitectură. În acest sens, Consiliul apreciază drept pertinentă susținerea entității contractante, potrivit căreia elaborarea documentației despre baza de date și a documentației despre arhitectura sistemului ar trebui planificată de la inițierea implementării proiectului prin descrierea situației actuale, urmând ca documentele să fie revizuite în etapele de analiză și proiectare (și de fiecare dată când apare o modificare în etapele de testare sau chiar la trecerea în producție), însă se va livra doar versiunea finală, conform, cerința 18.3.3 Etapa de trecere în producție faza II, aflată la pag. 47 din caietul de sarcini: „Procesul verbal va avea anexate: - manualul de utilizare a aplicației (destinat utilizatorilor generali și administratorilor aplicației); - manualul de administrare a soluției (destinat administratorilor de sistem și care include și procedura de instalare, strategia de backup, procedură de recuperare în caz de dezastru, documentația bazelor de date, documentația despre arhitectura sistemului); - raportul de trecere în producție faza II; - rapoartele de status săptămânal”. În consecință, în cadrul factorului de evaluare F2.1 b) Corelarea planului de proiect cu cerințele din caietul de sarcini, cu privire la corelarea între livrabilele din caietul de sarcini și planul de proiect propus, comisia de evaluare a ofertelor a apreciat, în mod justificat, că „există corelare cu deviații minore între cerințele și Pagina 159 din 171

livrabilele solicitate prin caietul de sarcini și planul de proiect propus” și a calificat ca „Bună” îndeplinirea cerințelor, justificând, printre altele, că: „Documentația bazei de date și Documentația despre arhitectura sistemului nu sunt livrabile pentru faza I și nu sunt documente diferite pentru faza I și faza II (sistemul presupune o singură bază de date și o singură arhitectură)”. Urmare a solicitării formulată de contestator, Consiliul, în temeiul art. 26 alin. (8) din Legea nr. 101/2016, va lua act de renunțarea la critica ii) de la punctul 1.2. Critica iii) de la punctul 1.2 urmează a fi respinsă, ca nefondată, deoarece, astfel cum a constatat, în mod corect, entitatea contractantă, în Anexa 3 se face referire la elaborarea documentului Plan de integrare a versiunilor însă acest înscris nu se regăsește nici în caietul de sarcini și nici în graficul Gantt. Totodată, se reține că în cadrul Metodologiei OUM nu se specifică niciun detaliu cu referire la modul cum va arăta Planul de integrare a versiunilor, ce va conține acesta, activitatea prin care acesta este elaborat și de către cine. Consiliul reține că, astfel cum susține, în mod corect, entitatea contractantă, prin evaluarea corelării dintre planul de proiect și cerințele din caietul de sarcini nu s-a urmărit conformitatea ofertei tehnice, prin urmare, nu este relevant faptul că documentul Plan de integrare a versiunilor nu este solicitat printr-o cerință a caietului de sarcini (aspect invocat de contestator în concluziile scrise), ci, faptul că acesta a fost menționat în Anexa 3 (din oferta tehnica) la cap. 1.1, fără a se prezenta necesitatea sau utilitatea acestuia (cine îl elaborează, ce conține) și nici corelarea cu metodologia din cap. 1 sau cu Graficul Gantt. Mai mult, activitatea de integrare (a versiunilor) nu este menționată nici în metodologia din cap. 1 și nici în Graficul Gantt. Prin urmare, entitatea contractantă a considerat, în mod corect, că „detalierea excesivă” prin includerea în cap. 1.1 al Anexei 3, fără motivație și fară menționarea corespondențelor în Graficul Gantt, a unor documente precum Plan de integrare a versiunilor (dar și: Plan general de testare sau Arhitectură Testare Automată), „încarcă nejustificat oferta tehnică”, situație în care Asocierii ............................SRL – ............................SRL nu i se cuvine punctaj suplimentar. Situația este similară și în cazul criticii iv) de la punctul 1.2, deoarece în Planul de proiect din Anexa 3 la cap.1.1.3 sunt menționate rolurile de manager de testare, analist de testare, designer de testare, proiectant de testare, tester și manager configurație, fără a fi reprezentate și în graficul Gantt iar legătura cu factorul de evaluare „Corelarea planului de proiect cu cerințele din caietul de sarcini” rezidă în faptul că cele 6 roluri nu au fost solicitate expres în caietul de sarcini. Pagina 160 din 171

Prin urmare, entitatea contractantă a sesizat, în mod corect, lipsa de corelare a informațiilor, situație în care nu a punctat suplimentar oferta contestatorului. Critica v) de la punctul 1.2 urmează a fi respinsă, ca nefondată deoarece este corectă constatarea entității contractante, potrivit căreia, în graficul Gantt, acceptarea livrabilelor pentru sesiunile de instruire, liniile 169 - 170 pentru faza I, la data de 29 august 2025, ar trebuie să se realizeze înainte de începerea sesiunilor de instruire, liniile 163-166 pentru faza I, care însă sunt planificate în perioada 30 iulie - 26 august 2025, aceeași observație fiind valabilă și pentru faza II. Cu alte cuvinte, în oferta tehnică se propune începerea sesiunilor de instruire înainte de livrarea planului de instruire și a suportului de curs. În ceea ce privește sub-factorul tehnic 2.1.c, intitulat „corelarea planului de proiect cu metodologia de management de proiect”, Consiliul reține că entitatea contractantă a acordat 1 punct, situație asociată calificativului „Acceptabil”, cu explicația „Corelarea intre planul de proiect si metodologia utilizata in cadrul proiectului este cu deviatii majore”. În acest sens, entitatea contractantă a menționat, drept puncte slabe, faptul că „În graficul Gantt etapele nu sunt prezentate în ordine logică”, cu următoarea explicație: „- Planul de implementare și graficul Gantt sunt în mică măsură corelate cu metodologia de management de proiect, care este detaliată foarte general; - În graficul Gantt etapele nu sunt prezentate în ordine logică, de exemplu Trecerea în producție este înaintea Instruirilor (cu toate că estimările de date pentru Start și Finish pe activități sunt în ordine cronologică); - Nu este marcat corect drumul critic, activitatea Management Proiect este singura critică; - În metodologia de management de proiect este prezentat managementul riscului (cap. 3.3.8), însă riscuri specifice nu sunt tratate în planul de proiect”. Consiliul reține că explicațiile reproduse anterior sunt pertinente și justifică încadrarea ofertei contestatorului în situația „Corelarea intre planul de proiect si metodologia utilizata in cadrul proiectului este cu deviatii majore”. Astfel cum argumentează, în mod corect, entitatea contractantă în concluziile scrise, contestatorul a ales pentru graficul Gantt din propunerea sa tehnică un mod de reprezentare care nu urmărește nici cele două faze de implementare ale proiectului și uneori nici succesiunea logică între etape (Trecerea în producție este afișată înainte de Instruiri, iar Rapoartele de status săptămânal sunt adăugate toate la finalul graficului), prin urmare, în această formă, graficul este un instrument dificil de utilizat pentru monitorizarea progresului proiectului. Pagina 161 din 171

În ceea ce privește drumul critic, Consiliul reține discrepanța dintre metodologia de management de proiect, secțiunea 3.3.3 Managementul Timpului, paragraful „secvențierea activităților”, în care se menționează explicit că secvențierea activităților poate fi executată prin metoda drumului critic, respectiv că estimarea activităților se face utilizând metodologia drumui critic și graficul Gantt din propunerea tehnică, parte a ofertei contestatorului, în care nu se regăsește drumul critic. Mai mult, Consiliul reține că, chiar și în graficul Gantt retransmis urmare a solicitărilor de clarificări, contestatorul a figurat drumul critic doar la activitatea de la linia 391. Susținerile contestatorului, potrivit cărora nu s-ar fi solicitat prin documentația de atribuire prezentarea drumului critic nu pot fi considerate relevante cu privire la acordarea punctajului, ci, doar cu privire la conformitatea ofertei sale. Or, comisia de evaluare a considerat conformă oferta contestatorului, însă, lipsa corelării anterior menționată se încadrează perfect în descrierea „Corelarea intre planul de proiect si metodologia utilizata in cadrul proiectului este cu deviații majore” situație în care, chiar dacă oferta este conformă, nu i se cuvine punctaj suplimentar. Astfel cum menționează entitatea contractantă în concluziile scrise, este de notorietate că aplicațiile software de management de proiect evidențiază automat drumul critic al proiectului, în funcție de duratele activităților, dependențele între acestea, rezervele de timp prevăzute și resursele alocate. În formatul prezentat este marcată cu roșu (în legendă apare sintagma „Critical”) doar activitatea de la linia 391 – Activități de management de proiect, ceea ce denotă lipsa de corectitudine, omisiuni și neconcordanțe în conceperea graficului Gantt. În fine, Consiliul apreciază că este justificat și ultimul argument de la sub-factorul 2.1.c „corelarea planului de proiect cu metodologia de management de proiect”, motivat de faptul că riscurile nu sunt menționate în graficul planul de proiect și nici în Anexa 3 - Metodologia OUM. In Anexa 2 - Metodologia de management al proiectului este inclus cap. 3.3.8 Managementul Riscului, care conține bune practici, iar în Formularul IV.4.1.a este detaliată cerința 24.2 Riscuri din Caietul de sarcini, fară analiza calitativă a riscurilor identificate de Entitatea Contractantă sau de Ofertant. Prin urmare, riscurile specifice implementării proiectului nu simt tratate în planul de proiect. În ceea ce privește sub-factorul de evaluare Subfactorul de evaluare nr. F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, Consiliul reține că entitatea contractantă a consemnat, drept puncte slabe, faptul că „Estimarea duratei nu este realistă pentru activitățile prezentate în graficul Gantt”, cu următoarea justificare: Pagina 162 din 171

„Duratele activităților detaliate în planul de proiect sunt parțial corespunzătoare complexității activităților și nu sunt în mod realist estimate: - Din graficul Gantt rezultă că etapa de analiză pentru cele 6 noi module ale fazei II se va realiza secvențial, într-o perioadă de doar 2 luni; - Din graficul Gantt rezultă că etapa de analiză pentru modulul de Pontaj se va realiza în doar 4 zile; - Din graficul Gantt rezultă că activitatea de upgrade Oracle Linux pe cele 4 medii se va realiza în doar 4 zile de către unul dintre experții cu rol de Specialist în implementarea de tehnologii Oracle EBS HCM, fără implicarea rolului Arhitect de sistem Oracle EBS; - Durata pentru pregătirea trecerii în producție nu este corect dimensionată, graficul nu include activitatea de pregătire a utilizatorilor finali, în sarcina SNN; - Planul de implementare nu prezintă toate resursele implicate (alți specialiști în echipa de proiect), ci doar experții cheie solicitați prin Caietul de sarcini; - Nu sunt prezentate roluri și sarcini pentru echipa SNN (echipa de proiect a beneficiarului este asignată doar pe sarcinile de testare de acceptanță)”. Cu privire la primul argument, respectiv faptul că etapa de analiză pentru cele 6 noi module ale fazei II se va realiza secvențial, într-o perioadă de doar 2 luni, Consiliul apreciază pertinente susținerile autorității contractante, potrivit cărora, din experiența acumulată în sesiunile de analiză de business internă în vederea elaborării caietului de sarcini, din cadrul documentației de atribuire a acestui proiect, entitatea contractată poate aprecia că durată de 2 luni nu va fi suficientă pentru activități de analiză de business realizate secvențial. Spre deosebire de modelul tradițional Waterfall, abordarea Agile, pe care se bazează metodologia OUM, presupune că cerințele, costul și perioada nu pot fi toate fixe (Triple Constraint). Prin urmare, dacă ținem cont de faptul că cerințele și costul proiectului sunt fixe. atunci singura variabilă ar trebui să fie perioada. Pentru a se încadra totuși în perioada deja stabilită a proiectului, singura soluție viabilă ar fi planificarea activităților în paralel, cu suplimentarea echipei de implementare (și desemnarea de experți non-cheie). Referitor la cea a de 2-a justificare, privind faptul că etapa de analiză pentru modulul de pontaj se va realiza în doar 4 zile, Consiliul reține că prin caietul de sarcini a fost solicitat un singur expert pentru rolul de Analist de business HR, iar ofertantul a inclus 2 experți pentru a satisface cerințele minime de conformitate: „(2) Analist de business HR (1 expert) Analistul de business va fi responsabil cu desfășurarea și documentarea etapei de analiză detaliată, descrierea proceselor de Pagina 163 din 171

business HR, elaborarea specificațiilor tehnice și funcționale pentru implementarea produselor software Oracle EBS HCM, dar va participa și la etapele de testare, instruire utilizatori, acceptanță, garanție și suport tehnic. Cerințe minime: - studii superioare absolvite cu diplomă de licență sau echivalent; - competențe privind analiza de business dovedite prin cel puțin o certificare recunoscută la nivel național sau internațional; - experiență profesională specifică constând în activități de analiză de business, în cadrul a cel puțin 1 proiect finalizat de upgrade/migrare/implementare produse software Oracle EBS, în ultimii 5 ani. Este imperios necesar ca experiența profesională de analist de business HR să fie dobândită în proiecte derulate în ultimii 5 ani raportat la data limită de depunere a Ofertelor, având în vedere că în domeniul IT, în special în cazul produselor software Oracle, progresul tehnologic este foarte rapid și sunt emise noi versiuni frecvent”. Prin urmare, cei 2 experți desemnați în oferta tehnică urmează a fi responsabili împreună de execuția activităților de analiză de business. În ofertă au fost desemnați experții: - .............., pentru care au fost îndeplinite cerințele de calificare, mai puțin cea referitoare la experiența în analiză de business pentru soluții Oracle EBS în HR în ultimii 5 ani; - ............., pentru care a fost prezentat 1 proiect cu experiență relevantă pentru conformitate. Cu toate acestea, planificarea din graficul Gantt nu prevede distribuirea sarcinilor de analiză între cei 2 experți, după cum se poate vedea la activitatea de la linia 27, în care sunt menționați ambii expertți, ale căror nume sunt despărțite prin simbolul „/”, având în limba română semnificația conjuncției alternative „sau”. În plus, ținând cont de motivele prezentate mai sus, în motivarea de la subfactorul F2.1 d) punctul ii), Consiliul apreciază pertinentă observația entității contractante, potrivit căreia nu ar fi indicată o astfel de abordare de analiză în paralel pentru cerințele aceluiași modul (în acest caz pentru Pontaj), activitate în care ar trebui să fie implicați și responsabilii de Pontaj din partea Entității Contractante și cel puțin unul dintre experții desemnați pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM. Având în vedere aceste aspecte, precum și complexitatea cerințelor solicitate prin cap. 5.2.4 din caietul de sarcini referitoare la customizările și dezvoltările necesare pentru particularitățile Entității Contractante, prin comparație cu funcționalitățile standard oferite de modulul Oracle Time and Labor, Consiliul apreciază ca fiind veridică susținerea entității contractante, că modulul de pontaj va necesita o perioadă mai mare de 4 zile pentru analiza de business. Pagina 164 din 171

Cu privire la justificarea „Din graficul Gantt rezultă că activitatea de upgrade Oracle Linux pe cele 4 medii se va realiza în doar 4 zile de către unul dintre experții cu rol de Specialist în implementarea de tehnologii Oracle EBS HCM, fără implicarea rolului Arhitect de sistem Oracle EBS”, se reține că, prin caietul de sarcini, la cap. 5.1.2.2 Cerințe personal tehnic de specialitate, pag. 8, s-a solicitat: „(3) Arhitect de sistem Oracle EBS (1 expert) Expertul Arhitect de sistem Oracle EBS va fi responsabil cel puțin de prezentarea de soluții de optimizare a arhitecturii existente, upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources, de proiectarea noilor module și de integrarea cu sistemele externe, administrarea sistemului, coordonarea cu echipa tehnică și transpunerea în elemente și componente funcționale a cerințelor detaliate în etapele de analiză, avizarea documentelor de natură tehnică elaborate de echipa Prestatorului”. Având în vedere cerința anterior reprodusă, prin care se solicită ca rolul Arhitect de sistem Oracle EBS să fie responsabil de optimizarea și upgrade-ului sistemului de operare Oracle Linux și a Oracle HR, Consiliul apreciază drept întemeiată susținerea entității contractante că în graficul Gantt, pentru activitatea de upgrade Oracle Linux pe cele 4 medii, ar fi trebuit repartizați experții de pe rolurile de Specialist în implementarea de tehnologii Oracle EBS HCM și Arhitect de sistem Oracle EBS. Or, în graficul Gantt, sarcinile corespunzătoare upgrade-ului de Oracle Linux sunt repartizate, astfel: - La linia 42, activitatea de Design soluție optimizată și upgrade- ata (upgrade-ul sistemului de operare Oracle Linux, actualizarea versiunii produsului Oracle Human Resources) este menționat Specialist în implementare de tehnologii Oracle EBS HCM 2 – ...........; - La Linia 73, activitatea de Actualizare a sistemului de operare Oracle Linux de la versiunea 7.9 la ultima versiune stabilă disponibilă, pe mediile de dezvoltare, test, producție și DR este menționat Specialist în implementare de tehnologii Oracle EBS HCM 1 – .............. Prin urmare, este pertinentă observația entității contractante, că ar fi fost mai potrivit să fie repartizat același expert atât pentru proiectarea cât și pentru actualizarea Oracle Linux și este justificată motivarea entității contractante că durata și rolul repartizat pentru această activitate nu au fost planificate corespunzător. În ceea ce privește justificarea „Durata pentru pregătirea trecerii în producție nu este corect dimensionată, graficul nu include activitatea de pregătire a utilizatorilor finali, în sarcina SNN”, din graficul Gantt rezultă că perioada pentru pregătirea trecerii în producție este de doar 4 zile: Pagina 165 din 171

Faza I: - Acceptanță pe mediul de test: 14 august 2025 - Activare licențe pe mediul de producție: 15 august 2025 - Începere trecere în producție: 18 august 2025 Faza II: - Acceptanță pe mediul de test: 17 iulie 2026 - Activare licențe pe mediul de producție: 20 iulie 2026 - Începere trecere în producție: 21 iulie 2026 și nu sunt incluse activitățile de instruire a utilizatorilor finali (toți angajații entității contractante) de către echipa entității contractante. Serviciile de instruire în sarcina contractorului nu presupun cursuri pentru toți angajații beneficiarului, ci conform Caietului de sarcini, cap. 5.1.3 Cerințe instruiri, pag. 15-16, fiecare sesiune se adresează la maxim 15 angajați: „Furnizorul este responsabil pentru instruirea personalului desemnat de către SNN, după ce soluția este funcțională pe mediul de test. Pregătirea trebuie să permită utilizatorilor înțelegerea tuturor funcționalităților și operarea aplicației, precum și transferul informațiilor despre mentenanța de rutină care urmează a fi efectuată de către administratorii aplicației și de către cei de sistem. Sesiunile de instruiri vor cuprinde toate funcționalitățile soluției HR Management, astfel: Faza I: - 1 sesiune pentru administratorii de sistem (soluția Oracle HR Core extinsă și integrări); - 3 sesiuni pentru administratorii de aplicație (câte o sesiune pentru fiecare entitate a SNN: soluția Oracle HR Core extinsă și rapoarte). Faza II: - 1 sesiune pentru administratorii de sistem (module noi și integrări); - 3 sesiuni pentru administratorii de aplicație (câte o sesiune pentru fiecare entitate a SNN: module noi și rapoarte); - 3 sesiuni pentru rolurile speciale (câte o sesiune pentru fiecare entitate a SNN, de exemplu pentru rolurile de gestionare conflict de interese, responsabil de gestionarea informărilor și acordurilor privind prelucrarea datelor cu caracter personal, responsabil audit GDPR etc); - 3 sesiuni „train the trainer” (câte o sesiune pentru fiecare entitate a SNN: funcționalități ale modulelor noi pentru utilizatori: Self- Service, Pontaj, Evaluarea Performanțelor). [...] - fiecare sesiune va dura cel mult 5 zile și se va adresa către un număr de maxim 15 participanți; Pagina 166 din 171

[...] - ca urmare a numărului mare de utilizatori, sesiunile de instruire pentru utilizatori vor avea structura „train the trainer” și vor fi dedicate utilizatorilor-cheie, viitori instructori de utilizatori, cu următoarele obiective: modul de realizare a operațiilor uzuale pentru fiecare modul al soluției și prezentarea erorilor uzuale la operarea interfețelor aplicației”. Metoda de shadowing al experților implementatorului nu a fost prezentată în cadrul ofertei tehnice și nu este aplicabilă utilizatorilor finali, fiind mai potrivită pentru administratorii de aplicație și de sistem, în plus, față de sesiunile de instruire. În consecință, în cadrul factorului de evaluare F2.1 d) Realismul planului prin corelarea efortului estimat cu complexitatea activităților, comisia de evaluare a ofertelor a apreciat, în mod corect, că „duratele activităților detaliate în planul de proiect sunt în mică măsură corespunzătoare complexității activităților și nu sunt realist estimate” și a calificat ca „Acceptabilă” îndeplinirea cerințelor, justificând, printre altele, că: „Durata pentru pregătirea trecerii în producție nu este corect dimensionată, graficul nu include activitatea de pregătire a utilizatorilor finali, în sarcina SNN”. Referitor la lipsa prezentării tuturor resurselor în planul de proiect (în speță, a experților non-cheie), Consiliul apreciază pertinente susținerile entității contractante, potrivit cărora, în Formularul IV.4.1.a, care este menționat de contestator, nu este inclusă o strategie de management al riscurilor și nici nu sunt nominalizate resursele alocate, ca rol sau ca specialist, ci, doar îndeplinește cerința 24.2 din caietul de sarcini. Consiliul reține că, în evaluarea realismului planului de implementare prin corelarea efortului estimat cu complexitatea activităților entitatea contractantă a ținut cont de repartizarea responsabililor pe activități în Graficul Gantt (doar experți cheie, despre care susține că ar fi insuficienți relativ la complexitatea și durata sarcinilor, aspect care nu este negat de contestator, ci confirmat prin susținerile din contestație și concluziile scrise, în care menționează necesitatea implicării altor tipuri de experți decât experții cheie) și de rolurile menționate pe activitățile detaliate în cap. 1.1 din Anexa 3, însă, aici detaliile sunt inconsistente, atât cu privire la roluri, cât și la activități. Prin urmare, entitatea contractantă a considerat, în mod corect, că, o analiză a impactului și probabilității riscurilor ar fi rezultat într-o estimare și planificare eficientă a resurselor încă din momentul ofertării și nu după ce vor apărea întârzieri în implementare. Referitor la motivarea „Nu sunt prezentate roluri și sarcini pentru echipa SNN (echipa de proiect a beneficiarului este asignată doar pe sarcinile de testare de acceptanță)”, Consiliul reține că activitățile de la liniile 87 și 120 din graficul Gantt sunt singurele care fac referire la activități care includ la responsabili și echipa de proiect a beneficiarului, Pagina 167 din 171

iar acestea rezultă direct din cerințele de testare din cap. 10 al Caietului de sarcini, pag. 42: „Testele de acceptanță se vor efectua pe mediul de test pus la dispoziție de Entitatea Contractantă, cu asistență din partea Furnizorului”. În acord cu entitatea contractantă, Consiliul apreciază că responsabili din partea entității contractante ar trebui să fie desemnați cel puțin pe activitățile de analiză de business, instruire utilizatori finali, validare documentație, corecții de date. Totodată, se reține că, pentru obținerea punctajului suplimentar, graficul Gantt ar fi trebuit să conțină activitățile tuturor părților implicate, nefiind identificat niciun motiv pentru care versiunea inclusă în propunerea tehnică să difere substanțial față de versiunea graficului care se va agrea la inițierea implementării sau de actualizările inerente din perioada de derulare a contractului. În ceea ce privește sub-factorul de evaluare F2.1 e) „Optimizarea utilizării resurselor în cadrul proiectului și flexibilitate pentru situații neprevăzute”, Consiliul reține că entitatea contractantă a consemnat punctele slabe „Planificarea activităților este secvențială”, cu următoarea motivare: „în planul de proiect nu este optimizată utilizarea resurselor: - Activitățile sunt planificate secvențial (de ex. pentru analiză și pentru configurare module în faza II), chiar dacă sunt desemnați 2 experți pe rolul de Specialist în implementarea de tehnologii Oracle EBS HCM planificarea activităților nu permite flexibilitate pentru situații neprevăzute: - Activitățile sunt planificate secvențial, nu se suprapun; - Activitatea de Proiectare a soluției tehnice începe după activitatea de Analiză din faza I (în graficul Gantt, linia 41 este condiționată de linia 20), însă etapa de Proiectare poate fi inițiată la începutul fazei I prin propuneri de optimizare a soluției existente”. Critica cu privire la lipsa optimizării urmează a fi respinsă, ca nefondată, deoarece, cont de motivarea contestatorului de la subfactorul F2.1 d) punctul iii) privind distribuirea sarcinilor între 2 experți desemnați pe același rol, cum ar fi cel de Specialist în implementarea de tehnologii Oracle EBS HCM, pe care au fost solicitați 2 experți prin Caietul de sarcini, considerăm că activitățile de analiză de business și de configurare, în special pentru modulele din faza II, se pot desfășura în paralel cu aplicarea metodelor și mijloacelor de gestionare a proiectului (ex.: identificarea corectă a dependințelor și constrângerilor între activități), pentru optimizarea alocării resurselor și a timpului de implementare și asigurarea unei rezerve de resurse pentru situații neprevăzute. Pagina 168 din 171

flexibilitate” menționată în cuprinsul contestației nu este inclusă ca element de descriere în propunerea tehnică, ci, doar în contestație. Prin urmare, comisia de evaluare nu avea cum să țină cont de această informație în timpul activității de evaluare a propunerii tehnice raportat la algoritmul de acordare a punctajului. Critica cu privire la discrepanța dintre procedura ORACLE, în care activitatea de proiectare se realizează în paralel cu activitatea de analiză și graficul Gantt, în care activitatea de proiectare începe după activitatea de analiza (Linia 41 din Gantt este condiționată de realizarea liniei 20 din GANTT) urmează a fi respinsă, ca nefondată, deoarece, din analiza ofertei, se constată că planificarea activităților nu respectă principiile metodologiei selectate (OUM), activitățile fiind planificate exclusiv secvențial. Mai mult, Consiliul apreciază pertinentă observația entității contractante, potrivit căreia în planul de implementare nu au fost incluse activități de îmbunătățire a soluției existente, la începutul fazei I, care puteau include și activități din etapa de proiectare în paralel cu cele de analiză, cu scopul de optimizare a alocării resurselor și timpului de implementare și asigurarea calității livrabilelor proiectului. În ceea ce privește ultimul sub-factor criticat, respectiv subfactorul de evaluare F2.1 f) „Optimizarea duratei proiectului (scurtarea termenului de livrare) cu încadrarea în bugetul alocat”, se reține că entitatea contractantă a consemnat drept punte slabe faptul că „Nu a fost propusă optimizarea perioadei de implementare”, cu următoarele justificări: „în planul de proiect nu este optimizată durata proiectului (scurtarea termenului de prestare) cu încadrarea în bugetul alocat: - În graficul Gantt este depășit termenul de finalizare contract, 24.01.2027, pentru mai multe activități (data de 24.01.2027 a fost confirmată prin răspuns la solicitare de clarificări ca dată de finalizare contract); - Activitățile nu sunt relaționate astfel încât să se realizeze o suprapunere a unor activități chiar dacă tehnic se pot executa în paralel și metodologia prevede această practică; cu mici excepții, activitățile au un singur predecesor, activitatea anterioară, iar relația este FS (Finish to Start)”. Criticile contestatorului vizează doar cel de-al doilea motiv, respectiv, lipsa de relaționare și ne-realizarea suprapunerii unor activități care s-ar putea executa în paralel, precum și faptul că activitățile au un singur predecesor, activitatea anterioară, iar relația este FS (Finish to Start). Pagina 169 din 171

analiză, proiectare, configurare și deployment, în opoziție cu implementările de tip Waterfall în care etapele sunt parcurse secvențial, fără a se reveni la analiză și proiectare și fără optimizare prin distribuirea către mai multe sub-echipe. Totodată, se reține că, astfel cum indică, în mod corect, entitatea contractantă, motivarea din contestație și din concluziile scrise nu se regăsește în propunerea tehnică și nici nu demonstrează cum se asigură optimizarea perioadei de implementare și flexibilitatea în cadrul proiectului, aplicând procedura aleasă. Raportat la cele evocate și ținând seama că, printre atribuțiile comisiei de evaluare, sunt și cele de evaluarea propunerilor tehnice ale ofertanților în conformitate cu criteriile de atribuire așa cum este prevăzut la art. 133 alin. (1) lit. g) din HG nr. 394/2016, Consiliul constată că această verificare s-a făcut, în cazul ofertei Asocierii ............................SRL – ............................SRL cu rigurozitatea impusă de legislația în domeniu și, pe cale de consecință, criticile privind nelegalitatea evaluării propunerii sale tehnice sunt neîntemeiate, urmând să fie respinse. Pentru considerentele anterior expuse, în temeiul dispozițiilor art. 26 alin. (6) din Legea nr. 101/2016, Consiliul va respinge, ca nefondată, contestația formulată de ............................SRL în contradictoriu cu entitatea contractantă ......... SA. Pentru aceste motive în baza documentelor depuse de părți, CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR DECIDE: Respinge,

ca

nefondată,

contestația

formulată de

............................SRL

în

contradictoriu

cu

entitatea contractantă ......... SA. Obligatorie. Împotriva prezentei decizii se poate formula plângere în termen de 10 zile de la comunicare. Complet de soluționare a contestațiilor în domeniul achizițiilor publice: Consilier de soluționare ............... PREȘEDINTE .................. Consilier de soluționare ................... Pagina 170 din 171

Redactat practicaua deciziei ............ Redactată în 4 (patru) exemplare originale, conține 162 (osutășaizecișidouă) pagini Pagina 171 din 171